f



aes-128-CBC

Hi,
I know how the aes-128 CBC works (thanks to some animation provided on
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/).
However I still have the following problem, which I will appreciate if
someone can throw some light on:

1. I have a file with exactly 100 bytes of data which i would like to
encrypt using openssl.

2. I use the command
#>openssl aes-128-cbc -in 1.dat -out 2.dat -pass pass:abcd1234 -p
salt=12AEA9A1446459C2
key=4469335882CE72FFD70290941F60BED10D609660E613D4C1D4C088C283F698CB
iv =258A57BA87ADAF7619E0389C016EC5F1

3. The output file 2.dat is 128 bytes in length. I don't understand where
the extra 28 bytes come from, and will appreciate if someone can
correct my below understanding:

a. I guess the openssl enc commad uses PBKDF2 (according to RFC 2898) to
derive the 16Byte key from the 8Byte salt, and some iteration count.
DFK= PBKDF2 (P, S, c, dkLen)
where P=> password (shared betweeb two parties,
S==>8Byte Salt, taken using some pseudo-random device.
c=> Iteration count (defaulted to some value)
dkLen => 16Byte (=128 bits)

b.  The 16Byte Key is used with the aes-128-byte cipher.. Since the input
data is 100 bytes, the cipher algorithm will add 12bytes padding
to make it a block of 112 bytes.
Thus the output will be a encrypted text of 112 bytes.

c. Since the receiver needs to know the salt(8Bytes), iteration count (??)
and dklen(??), some more things need to be appended to the files so that
it can be decrypted.. (I don't know what these may be.. any ideas?)


Thanks for any input.






-- 
Regards
Shashank
http://mia.ece.uic.edu/~papers


-1
shashank8 (15)
6/30/2003 6:00:01 PM
comp.security.ssh 4228 articles. 0 followers. terra1024 (490) is leader. Post Follow

12 Replies
1017 Views

Similar Articles

[PageSpeed] 56

> >
> >c. Since the receiver needs to know the salt(8Bytes), iteration count
(??)
> >and dklen(??), some more things need to be appended to the files so that
> >it can be decrypted.. (I don't know what these may be.. any ideas?)
> >
>
> Yes but no.  The receiver _will_ need the salt to derive the key, but
> that is _not_ where the extra 128-bits (16 bytes) comes from.
>
> The 128-bit (16-byte) IV must be added in the clear to the ciphertext
> so that the decrypt process can start correctly.
>
> So 12 bytes padding plus 16 bytes IV equals 28 bytes.
>
> You will also have to find some way (like handing it to them in
> person) to securely provide the receiver both the salt and the key in
> order for them to decrypt.
I have some reservations about your comments as below:

I thought that maybe the 16 Byte overhead was as follows:
(8 Byte for the salt, 4 byte for the Iteration count, 4 byte for the Key
Length)

I think logically, there has to be some mechanism to pass the salt to the
receiver unencrypted (alogwith the encrypted message).

In RFC2898, it is mentioned that the salt can be sent in the clear, as it
would be computationally impossible for the intruder to
guess the key from the salt and a guessed password (using a dictionary type
of attack).

"A general approach to password-based cryptography, as described by
   Morris and Thompson [8] for the protection of password tables, is to
   combine a password with a salt to produce a key. The salt can be
   viewed as an index into a large set of keys derived from the
   password, and need not be kept secret. Although it may be possible
   for an opponent to construct a table of possible passwords (a so-
   called "dictionary attack"), constructing a table of possible keys
   will be difficult, since there will be many possible keys for each
   password.  An opponent will thus be limited to searching through
   passwords separately for each salt.
"

As for the initialization vector, I think it might not be necessary to pass
the initialization vector, as the same can be derived from a combination of
salt and the shared  secret password. (correct me if you think I am wrong)

Comments are welcome.

Shank




0
shashank8 (15)
6/30/2003 8:16:50 PM
There is no reason to be cross-posting this to comp.security.ssh; SSH and
SSL have nothing to do with one another.

-- 
  Richard Silverman
  res@qoxp.net

0
res49 (1410)
6/30/2003 9:58:17 PM
On Mon, 30 Jun 2003 15:16:50 -0500, "Shashank Khanvilkar"
<shashank@evl.uic.edu> wrote:

>> >
>> >c. Since the receiver needs to know the salt(8Bytes), iteration count
>(??)
>> >and dklen(??), some more things need to be appended to the files so that
>> >it can be decrypted.. (I don't know what these may be.. any ideas?)
>> >
>>
>> Yes but no.  The receiver _will_ need the salt to derive the key, but
>> that is _not_ where the extra 128-bits (16 bytes) comes from.
>>
>> The 128-bit (16-byte) IV must be added in the clear to the ciphertext
>> so that the decrypt process can start correctly.
>>
>> So 12 bytes padding plus 16 bytes IV equals 28 bytes.
>>
>> You will also have to find some way (like handing it to them in
>> person) to securely provide the receiver both the salt and the key in
>> order for them to decrypt.

>I have some reservations about your comments as below:
>
>I thought that maybe the 16 Byte overhead was as follows:
>(8 Byte for the salt, 4 byte for the Iteration count, 4 byte for the Key
>Length)
>
>I think logically, there has to be some mechanism to pass the salt to the
>receiver unencrypted (alogwith the encrypted message).

Yes.  They will need it unencrypted in order to "derive" the session
key.

Yes you need to get the salt to them, just like they need the key.

In this case they are leaving it to you to figure out how to get the
salt (and the key) to the intended receiver.

You _could_ agree with your receiver prepend the salt to the
IV+ciphertext after using openssl and your receiver could remove the
64-bits of salt prior to using openssl to decrypt.  But that is up to
you.

Perhaps you have a hex viewer so you can take a look at the first 16
bytes of the ciphertext to get a look at exactly what is there.

>
>In RFC2898, it is mentioned that the salt can be sent in the clear, as it
>would be computationally impossible for the intruder to
>guess the key from the salt and a guessed password (using a dictionary type
>of attack).

Yes it can be sent in the clear.

>
>"A general approach to password-based cryptography, as described by
>   Morris and Thompson [8] for the protection of password tables, is to
>   combine a password with a salt to produce a key. The salt can be
>   viewed as an index into a large set of keys derived from the
>   password, and need not be kept secret. Although it may be possible
>   for an opponent to construct a table of possible passwords (a so-
>   called "dictionary attack"), constructing a table of possible keys
>   will be difficult, since there will be many possible keys for each
>   password.  An opponent will thus be limited to searching through
>   passwords separately for each salt.
>"
>
>As for the initialization vector, I think it might not be necessary to pass
>the initialization vector, as the same can be derived from a combination of
>salt and the shared  secret password. (correct me if you think I am wrong)

I think you are wrong in this small area.  The IV, or intialization
vector is always added in the clear to the ciphertext in CBC mode.

The IV (in CBC mode) is always the same size as the block size AFAIK.

The block size is 128-bits (16 bytes) and so the IV is 128-bits.

Now.  I have seen schemes where the salt is transmitted in the clear
along with the IV and also some bytes describing the algortihm used
and the mode.  But that is probably _not_ what is going on here.

There are not enough bytes in the output (I'm assuming no
pre-compression of cleartext) to allow for this.

12 bytes padding plus 16 bytes IV equals 28 bytes.

Get a hex viewer program.  It will be most helpful.  I use win32
environment so I use UltraEdit or Hex Workshop to view them.

I hope this is helpful.

0
clem4632 (4)
6/30/2003 10:10:12 PM
> There is no reason to be cross-posting this to comp.security.ssh; SSH and
> SSL have nothing to do with one another.

I don't understand.. AFAIK SSH was built on SSL .. So it has everything to
do with SSL..
(please correct me if I am wrong).
Shank

>
> -- 
>   Richard Silverman
>   res@qoxp.net
>


0
shashank8 (15)
6/30/2003 10:19:55 PM
> >
> >As for the initialization vector, I think it might not be necessary to
pass
> >the initialization vector, as the same can be derived from a combination
of
> >salt and the shared  secret password. (correct me if you think I am
wrong)
>
> I think you are wrong in this small area.  The IV, or intialization
> vector is always added in the clear to the ciphertext in CBC mode.
>
> The IV (in CBC mode) is always the same size as the block size AFAIK.
>
> The block size is 128-bits (16 bytes) and so the IV is 128-bits.
>
> Now.  I have seen schemes where the salt is transmitted in the clear
> along with the IV and also some bytes describing the algortihm used
> and the mode.  But that is probably _not_ what is going on here.
>
> There are not enough bytes in the output (I'm assuming no
> pre-compression of cleartext) to allow for this.
>
> 12 bytes padding plus 16 bytes IV equals 28 bytes.
>
> Get a hex viewer program.  It will be most helpful.  I use win32
> environment so I use UltraEdit or Hex Workshop to view them.
>
> I hope this is helpful.

Thanks for the comment.. As u have mentioned i used a hex viewer on linux
(shed).. and i found out that the first 8 bytes for a salted encrption is
always "Salted--", followed  by 8 bytes of salt. However there is no IV
(assuming the the IV would have been sent unencrypted)..
Hopefully I will be able to find out what these guys use.
Thanks for your time;
shank

>


0
shashank8 (15)
6/30/2003 10:40:45 PM
On Mon, 30 Jun 2003 17:40:45 -0500, "Shashank Khanvilkar"
<shashank@evl.uic.edu> wrote:

>> >
>> >As for the initialization vector, I think it might not be necessary to
>pass
>> >the initialization vector, as the same can be derived from a combination
>of
>> >salt and the shared  secret password. (correct me if you think I am
>wrong)
>>
>> I think you are wrong in this small area.  The IV, or intialization
>> vector is always added in the clear to the ciphertext in CBC mode.
>>
>> The IV (in CBC mode) is always the same size as the block size AFAIK.
>>
>> The block size is 128-bits (16 bytes) and so the IV is 128-bits.
>>
>> Now.  I have seen schemes where the salt is transmitted in the clear
>> along with the IV and also some bytes describing the algortihm used
>> and the mode.  But that is probably _not_ what is going on here.
>>
>> There are not enough bytes in the output (I'm assuming no
>> pre-compression of cleartext) to allow for this.
>>
>> 12 bytes padding plus 16 bytes IV equals 28 bytes.
>>
>> Get a hex viewer program.  It will be most helpful.  I use win32
>> environment so I use UltraEdit or Hex Workshop to view them.
>>
>> I hope this is helpful.
>
>Thanks for the comment.. As u have mentioned i used a hex viewer on linux
>(shed).. and i found out that the first 8 bytes for a salted encrption is
>always "Salted--", followed  by 8 bytes of salt. However there is no IV
>(assuming the the IV would have been sent unencrypted)..
>Hopefully I will be able to find out what these guys use.

Perhaps your original example wasn't CBC mode.

That may explain why there was no transmitted IV.  But in CBC mode
there is _always_ an IV sent in the clear and it is always block size.


0
clem4632 (4)
7/1/2003 3:01:16 AM
>>>>> "SK" == Shashank Khanvilkar <shashank@evl.uic.edu> writes:

    >> There is no reason to be cross-posting this to comp.security.ssh;
    >> SSH and SSL have nothing to do with one another.

    SK> I don't understand.. AFAIK SSH was built on SSL .. So it has
    SK> everything to do with SSL..  (please correct me if I am wrong).

You are wrong.  There's not much else to say; they are separate, unrelated
protocols.

-- 
  Richard Silverman
  res@qoxp.net

0
res49 (1410)
7/1/2003 4:11:40 AM
clem wrote:
> That may explain why there was no transmitted IV.  But in CBC mode
> there is _always_ an IV sent in the clear and it is always block size.

I don't know what OpenSSL does, but from a cryptographic point of view I 
see no reason for using an explicit IV with PBE encryption. If the Salt 
is large and random enough for the number of files encrypted with that 
particular password, it would be secure enough to encrypt the first 
block using ECB mode and use that as IV for the following blocks (which 
is equivalent to using 0 as IV).

0
7/1/2003 10:06:21 AM
On Mon, 30 Jun 2003 17:40:45 -0500, "Shashank Khanvilkar"
<shashank@evl.uic.edu> wrote:

>> >
>> >As for the initialization vector, I think it might not be necessary to
>pass
>> >the initialization vector, as the same can be derived from a combination
>of
>> >salt and the shared  secret password. (correct me if you think I am
>wrong)
>>
>> I think you are wrong in this small area.  The IV, or intialization
>> vector is always added in the clear to the ciphertext in CBC mode.
>>
>> The IV (in CBC mode) is always the same size as the block size AFAIK.
>>
>> The block size is 128-bits (16 bytes) and so the IV is 128-bits.
>>
>> Now.  I have seen schemes where the salt is transmitted in the clear
>> along with the IV and also some bytes describing the algortihm used
>> and the mode.  But that is probably _not_ what is going on here.
>>
>> There are not enough bytes in the output (I'm assuming no
>> pre-compression of cleartext) to allow for this.
>>
>> 12 bytes padding plus 16 bytes IV equals 28 bytes.
>>
>> Get a hex viewer program.  It will be most helpful.  I use win32
>> environment so I use UltraEdit or Hex Workshop to view them.
>>
>> I hope this is helpful.
>
>Thanks for the comment.. As u have mentioned i used a hex viewer on linux
>(shed).. and i found out that the first 8 bytes for a salted encrption is
>always "Salted--", followed  by 8 bytes of salt. However there is no IV
>(assuming the the IV would have been sent unencrypted)..
>Hopefully I will be able to find out what these guys use.
>Thanks for your time;
>shank
>
>>
>

I tried on an earlier win32 binary version of openssl and aes-128-cbc
was not available.  Only 64-bit block ciphers like Cast5 etc.

The salt argument was not available either, but the IV argument was.

I encrypted a 100 byte file using a 64-bit IV argument and it did
_not_ add the IV to the outfile, but it did add the 4 byte pad to get
the block boundary.  So I got a 104 byte outfile.

At this point, I'm going to stop and hope you post the hex viewer
results as my previous explanation may be bogus for openssl.

Good luck.

0
clem4632 (4)
7/1/2003 8:11:57 PM
On Tue, 01 Jul 2003 10:06:21 GMT, Henrick Hellstr´┐Żm
<henrick.hellstrm@telia.com> wrote:

>clem wrote:
>> That may explain why there was no transmitted IV.  But in CBC mode
>> there is _always_ an IV sent in the clear and it is always block size.
>
>I don't know what OpenSSL does, but from a cryptographic point of view I 
>see no reason for using an explicit IV with PBE encryption. If the Salt 
>is large and random enough for the number of files encrypted with that 
>particular password, it would be secure enough to encrypt the first 
>block using ECB mode and use that as IV for the following blocks (which 
>is equivalent to using 0 as IV).

OK.  I agree.  And I don't know what OpenSSL does either.

But if they are taking a 128-bit IV argument as part of the encryption
command line (and if you look at the OP, they are), that suggests to
me that they intend to use it.  Maybe I'm missing a lot here.


0
clem4632 (4)
7/1/2003 8:17:40 PM
Again: please take this off comp.security.ssh, as it has nothing to do with SSH.

-- 
  Richard Silverman
  res@qoxp.net

0
res49 (1410)
7/2/2003 3:02:42 AM
In article <bdqde8$im8$1@newsx.cc.uic.edu>,
Shashank Khanvilkar <shashank@evl.uic.edu> wrote:
>I don't understand.. AFAIK SSH was built on SSL .. So it has everything to
>do with SSL..

One common SSH implementation (OpenSSH) happens to use crypto functions
in the crypto library of a common SSL implementation (OpenSSL).

Apart from that, the similarities are they both do crypto and both start
with the letter "S".

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
0
dtucker (551)
7/2/2003 8:33:15 AM
Reply: