Re: Either a bug or a misunderstanding or Spyders in the code
Hello, > On Wed, Oct 18, 2006 at 11:35:13AM +0200, Marek Marcola wrote: > > Hello, > > > the block size is always the same as the key length in AES (and the most > > > block > > > ciphers, I think). You are using 128-AES -> 128 bits key == 16 bytes > > > block size > > > (q.e.d). > > Not exactly: > > > > AES128: block_size: 16 bytes, key_size: 16 bytes > > AES192: block_size: 16 bytes, key_size: 24 bytes > > AES256: block_size: 16 bytes, key_size: 32 bytes > >DES: block_size: 8 bytes, key_size: 8 bytes > > DES3: block_size: 8 bytes, key_size: 24 bytes (3*8 bytes) > > > The way block ciphering works is by first deriving a key schedule from the > key. Different ciphers have different ways of deriving enough entropy for > each of the schedule keys. > > I believe (correct me if I am wrong) that for each round a different key is > used. And this key is one of the keys in the schedule. > > The way the input block interacts with the round key therefore is not a one > to one relationship... > > Sorry my knowledge stops there as things are misty right now. It is close to > 6 years since I took an interest in these things. :-) Yes, I agree. For example in AES128 from 128 bit key (16 bytes) with key expansion algorithm 10 round keys are generated (128 bit long each) for each round. In AES192 there are 12 rounds and 12 round keys (128 bit long too) are generated from 192 bits of input key. And in AES 256 there are 14 rounds with 14 rounds key generated each 128 bit long from 256 bits of input key. In DES, from 64 bit key (8 bytes) 16 round keys are generated each 48 bits long. Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Either a bug or a misunderstanding or Spyders in the code
On Wed, Oct 18, 2006 at 11:35:13AM +0200, Marek Marcola wrote: > Hello, > > the block size is always the same as the key length in AES (and the most > > block > > ciphers, I think). You are using 128-AES -> 128 bits key == 16 bytes block > > size > > (q.e.d). > Not exactly: > > AES128: block_size: 16 bytes, key_size: 16 bytes > AES192: block_size: 16 bytes, key_size: 24 bytes > AES256: block_size: 16 bytes, key_size: 32 bytes >DES: block_size: 8 bytes, key_size: 8 bytes > DES3: block_size: 8 bytes, key_size: 24 bytes (3*8 bytes) > The way block ciphering works is by first deriving a key schedule from the key. Different ciphers have different ways of deriving enough entropy for each of the schedule keys. I believe (correct me if I am wrong) that for each round a different key is used. And this key is one of the keys in the schedule. The way the input block interacts with the round key therefore is not a one to one relationship... Sorry my knowledge stops there as things are misty right now. It is close to 6 years since I took an interest in these things. :-) Best, Girish __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Either a bug or a misunderstanding or Spyders in the code
Hello, > the block size is always the same as the key length in AES (and the most > block > ciphers, I think). You are using 128-AES -> 128 bits key == 16 bytes block > size > (q.e.d). Not exactly: AES128: block_size: 16 bytes, key_size: 16 bytes AES192: block_size: 16 bytes, key_size: 24 bytes AES256: block_size: 16 bytes, key_size: 32 bytes DES: block_size: 8 bytes, key_size: 8 bytes DES3: block_size: 8 bytes, key_size: 24 bytes (3*8 bytes) Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Either a bug or a misunderstanding or Spyders in the code
Hi,
the block size is always the same as the key length in AES (and the most block
ciphers, I think). You are using 128-AES -> 128 bits key == 16 bytes block size
(q.e.d).
Good luck,
Sebastian
Eric S. Eberhard wrote:
Kyle,
Thank you ... I thought I was missing something (actually the
behavior told me what you told me, I just wanted to confirm it was
correct). I won't actually use ECB, it was randomly selected from
the test file ...
A follow-up then ... if I have 37 bytes I would call Update twice and
Final once? If I have 32 bytes I would call Update once and Final
once? Or two Updates?
Is there a call to get the block size, or is that always 16? (I know
it is in the ctx but I was hoping to get it sooner than that).
Thank you again!
Eric
At 06:27 PM 10/13/2006, you wrote:
>OpenSSL does not store the plaintext size in block protocol usage.
>That's an application-layer issue.
>
>ECB mode, by the way, is REALLY discouraged.
>
>Padding doesn't come into play until the second-to-last and last
>blocks. You should get 16*(3 blocks of data +1 block for the
>EncryptFinal()) == 64 bytes.
>
>If you're writing less than a multiple of the block size, you should
>call EncryptFinal() on that write, not follow it up. This is arguably
>a bug in the block logic (the expected behavior you seem to want would
>be: you should get 32 bytes from the write of 37 bytes, with the final
>5 bytes stored in a buffer until you call EncryptFinal, which would
>pad to the appropriate block length and then finish the encryption),
>but I'm not certain it should be changed -- SSL and TLS have a need
>for an "application data flush" feature that forces data to be flushed
>without the encryption state being reset.
>
>Every EncryptFinal() ciphertext block that you get from it, though, is
>going to be the same (at least in ECB mode). Personally, I regard the
>fact that OpenSSL supports ECB mode without a Configure option (or at
>least a warning when it's used) a bug.
>
>So, to answer your questions in order:
>
>1) The second-to-last block is not an "extra block". It contains
>application data. I believe that you can expect to get that last
>block.
>
>2) No.
>
>3) I think you're missing something.
>
>4) Padding doesn't happen until a short block occurs anyway, so
>turning padding off until the final block won't change anything. Look
>at the source code to the command-line utility to see what it does, if
>you want to get identical results.
>
>Cheers,
>
>-Kyle H
>
>On 10/13/06, Eric S. Eberhard <[EMAIL PROTECTED]> wrote:
>>I am trying to do encryption using the "evp" APIs. For testing I am
>>using "AES-128-ECB" as the cypher. I have no problem encrypting and
>>decrypting, rather I am having problems with the sizes of the buffers.
>>
>>When encrypting a string of 37 bytes and passing as such:
>>
>> if (!EVP_EncryptUpdate(&ctx,out,&outl,plaintext,37)) {
>>
>>outl becomes 48 at this point (which is the expected size since this
>>alogrithm appears to block at 16 bytes). However, the next call as
such:
>>
>> if (!EVP_EncryptFinal(&ctx,out+outl,&outl2)) {
>>
>>this sets outl2 to 16 ... meaning it padded one more additional block.
>>
>>If I send decrypt 64 bytes it gives the desired answer (e.g. my text
>>is what I expect it to be). This is what I send:
>>
>>if (!EVP_DecryptUpdate(&ctx,out,&outl,ciphertext,64)) {
>>
>>outl is set to 48 (I would really like it to be 37 ...)
>>
>>if (!EVP_DecryptFinal(&ctx,out+outl,&outl2)) {
>
>[...]
>
>>
>>1) Should I always count on up to 2 extra blocks (1 for the remainder
>>if any, one for no reason I can tell)?
>>2) When decrypting, is there a way to find out the original size (in
>>my case 37)?
>>3) Am I missing something or is there a bug around here?
>>4) If I am going to handle large files that require multiple calls to
>>the Encrypt routines, I presume I would turn the padding off until
>>the very last block of data? Same with decrypt? My goal would be to
>>be able to encrypt a file and get the exact same results as command
>>line openssl. And the reverse.
>>
>>Thanks,
>>
>>Eric
>__
>OpenSSL Project http://www.openssl.org
>User Support Mailing Listopenssl-users@openssl.org
>Automated List Manager [EMAIL PROTECTED]
>
This email sent by:
Eric S. Eberhard
(928) 567-3727 Voice
(928) 567-6122 Fax
928-301-7537 -- you may call any time day or night, I turn it off
when I sleep :-) Please try to use a land line first (reception often
poor).
Note the change in the domain from vicspdi.com to vicsmba.com
For Metropolis support and VICS MBA Support
http://www.vicsmba.com
Completely updated web site of personal pictures with many new
pictures! Includes horses, dogs, Corvairs, and more.
http://www.vi
Re: Either a bug or a misunderstanding or Spyders in the code
Kyle,
Thank you ... I thought I was missing something (actually the
behavior told me what you told me, I just wanted to confirm it was
correct). I won't actually use ECB, it was randomly selected from
the test file ...
A follow-up then ... if I have 37 bytes I would call Update twice and
Final once? If I have 32 bytes I would call Update once and Final
once? Or two Updates?
Is there a call to get the block size, or is that always 16? (I know
it is in the ctx but I was hoping to get it sooner than that).
Thank you again!
Eric
At 06:27 PM 10/13/2006, you wrote:
OpenSSL does not store the plaintext size in block protocol usage.
That's an application-layer issue.
ECB mode, by the way, is REALLY discouraged.
Padding doesn't come into play until the second-to-last and last
blocks. You should get 16*(3 blocks of data +1 block for the
EncryptFinal()) == 64 bytes.
If you're writing less than a multiple of the block size, you should
call EncryptFinal() on that write, not follow it up. This is arguably
a bug in the block logic (the expected behavior you seem to want would
be: you should get 32 bytes from the write of 37 bytes, with the final
5 bytes stored in a buffer until you call EncryptFinal, which would
pad to the appropriate block length and then finish the encryption),
but I'm not certain it should be changed -- SSL and TLS have a need
for an "application data flush" feature that forces data to be flushed
without the encryption state being reset.
Every EncryptFinal() ciphertext block that you get from it, though, is
going to be the same (at least in ECB mode). Personally, I regard the
fact that OpenSSL supports ECB mode without a Configure option (or at
least a warning when it's used) a bug.
So, to answer your questions in order:
1) The second-to-last block is not an "extra block". It contains
application data. I believe that you can expect to get that last
block.
2) No.
3) I think you're missing something.
4) Padding doesn't happen until a short block occurs anyway, so
turning padding off until the final block won't change anything. Look
at the source code to the command-line utility to see what it does, if
you want to get identical results.
Cheers,
-Kyle H
On 10/13/06, Eric S. Eberhard <[EMAIL PROTECTED]> wrote:
I am trying to do encryption using the "evp" APIs. For testing I am
using "AES-128-ECB" as the cypher. I have no problem encrypting and
decrypting, rather I am having problems with the sizes of the buffers.
When encrypting a string of 37 bytes and passing as such:
if (!EVP_EncryptUpdate(&ctx,out,&outl,plaintext,37)) {
outl becomes 48 at this point (which is the expected size since this
alogrithm appears to block at 16 bytes). However, the next call as such:
if (!EVP_EncryptFinal(&ctx,out+outl,&outl2)) {
this sets outl2 to 16 ... meaning it padded one more additional block.
If I send decrypt 64 bytes it gives the desired answer (e.g. my text
is what I expect it to be). This is what I send:
if (!EVP_DecryptUpdate(&ctx,out,&outl,ciphertext,64)) {
outl is set to 48 (I would really like it to be 37 ...)
if (!EVP_DecryptFinal(&ctx,out+outl,&outl2)) {
[...]
1) Should I always count on up to 2 extra blocks (1 for the remainder
if any, one for no reason I can tell)?
2) When decrypting, is there a way to find out the original size (in
my case 37)?
3) Am I missing something or is there a bug around here?
4) If I am going to handle large files that require multiple calls to
the Encrypt routines, I presume I would turn the padding off until
the very last block of data? Same with decrypt? My goal would be to
be able to encrypt a file and get the exact same results as command
line openssl. And the reverse.
Thanks,
Eric
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
This email sent by:
Eric S. Eberhard
(928) 567-3727 Voice
(928) 567-6122 Fax
928-301-7537 -- you may call any time day or night, I turn it off
when I sleep :-) Please try to use a land line first (reception often poor).
Note the change in the domain from vicspdi.com to vicsmba.com
For Metropolis support and VICS MBA Support
http://www.vicsmba.com
Completely updated web site of personal pictures with many new
pictures! Includes horses, dogs, Corvairs, and more.
http://www.vicsmba.com/ourpics/index.html
Corvair pictures including the Judson setup on our 62 Sedan and lots
of pictures of Cheryl's 62 Monza Wagon and our 62 Spyder convertible.
http://www.vicsmba.com/ourpics/corvairs.html
My younger brother Martin has started a very serious car company. A
hot rod (very fast) electric roadster is the first offering. The
chassis is built by Lotus to their specs. Check it
out: http://www.teslam
Re: Either a bug or a misunderstanding or Spyders in the code
OpenSSL does not store the plaintext size in block protocol usage.
That's an application-layer issue.
ECB mode, by the way, is REALLY discouraged.
Padding doesn't come into play until the second-to-last and last
blocks. You should get 16*(3 blocks of data +1 block for the
EncryptFinal()) == 64 bytes.
If you're writing less than a multiple of the block size, you should
call EncryptFinal() on that write, not follow it up. This is arguably
a bug in the block logic (the expected behavior you seem to want would
be: you should get 32 bytes from the write of 37 bytes, with the final
5 bytes stored in a buffer until you call EncryptFinal, which would
pad to the appropriate block length and then finish the encryption),
but I'm not certain it should be changed -- SSL and TLS have a need
for an "application data flush" feature that forces data to be flushed
without the encryption state being reset.
Every EncryptFinal() ciphertext block that you get from it, though, is
going to be the same (at least in ECB mode). Personally, I regard the
fact that OpenSSL supports ECB mode without a Configure option (or at
least a warning when it's used) a bug.
So, to answer your questions in order:
1) The second-to-last block is not an "extra block". It contains
application data. I believe that you can expect to get that last
block.
2) No.
3) I think you're missing something.
4) Padding doesn't happen until a short block occurs anyway, so
turning padding off until the final block won't change anything. Look
at the source code to the command-line utility to see what it does, if
you want to get identical results.
Cheers,
-Kyle H
On 10/13/06, Eric S. Eberhard <[EMAIL PROTECTED]> wrote:
I am trying to do encryption using the "evp" APIs. For testing I am
using "AES-128-ECB" as the cypher. I have no problem encrypting and
decrypting, rather I am having problems with the sizes of the buffers.
When encrypting a string of 37 bytes and passing as such:
if (!EVP_EncryptUpdate(&ctx,out,&outl,plaintext,37)) {
outl becomes 48 at this point (which is the expected size since this
alogrithm appears to block at 16 bytes). However, the next call as such:
if (!EVP_EncryptFinal(&ctx,out+outl,&outl2)) {
this sets outl2 to 16 ... meaning it padded one more additional block.
If I send decrypt 64 bytes it gives the desired answer (e.g. my text
is what I expect it to be). This is what I send:
if (!EVP_DecryptUpdate(&ctx,out,&outl,ciphertext,64)) {
outl is set to 48 (I would really like it to be 37 ...)
if (!EVP_DecryptFinal(&ctx,out+outl,&outl2)) {
[...]
1) Should I always count on up to 2 extra blocks (1 for the remainder
if any, one for no reason I can tell)?
2) When decrypting, is there a way to find out the original size (in
my case 37)?
3) Am I missing something or is there a bug around here?
4) If I am going to handle large files that require multiple calls to
the Encrypt routines, I presume I would turn the padding off until
the very last block of data? Same with decrypt? My goal would be to
be able to encrypt a file and get the exact same results as command
line openssl. And the reverse.
Thanks,
Eric
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Either a bug or a misunderstanding or Spyders in the code
I am trying to do encryption using the "evp" APIs. For testing I am
using "AES-128-ECB" as the cypher. I have no problem encrypting and
decrypting, rather I am having problems with the sizes of the buffers.
My program is largely the same as evp_test.c function "test1" with
the release /openssl-0.9.8c/test, however this program does not
handle the padding -- all the test cases have even block-count bytes
and the padding is turned off. I removed the call to turn off the
padding in my program. My program is also like a sample program I
found on-line which handles the padding the same as I
do: http://tldp.org/LDP/LG/issue87/vinayak.html
When encrypting a string of 37 bytes and passing as such:
if (!EVP_EncryptUpdate(&ctx,out,&outl,plaintext,37)) {
outl becomes 48 at this point (which is the expected size since this
alogrithm appears to block at 16 bytes). However, the next call as such:
if (!EVP_EncryptFinal(&ctx,out+outl,&outl2)) {
this sets outl2 to 16 ... meaning it padded one more additional block.
If I send decrypt 64 bytes it gives the desired answer (e.g. my text
is what I expect it to be). This is what I send:
if (!EVP_DecryptUpdate(&ctx,out,&outl,ciphertext,64)) {
outl is set to 48 (I would really like it to be 37 ...)
if (!EVP_DecryptFinal(&ctx,out+outl,&outl2)) {
outl2 is set to zero ...
It would seem that the first encrypt SHOULD set 32, the final encrypt
should set 16 and the final result should then be 48 bytes.
It would also seem that the first decrypt should set 32, the final
decrypt should set 5, and the final result should be 37 bytes.
At a bare minimum, it would seem that the "total" from the two
encrypt statements should be 48 and the total from the two decrypt
statement should be 37 or 48, depending on your taste, but I find 37
more useful. Last, I should not have to store 64 bytes of encrypted
data to successfully encrypt and decrypt 37 bytes of data.
I have noticed that if I simply don't do the "final" calls for both
encrypt and decrypt that everything appears to work on the encrypt
and I save 48 bytes ... but when I decrypt it I only get back 32
bytes. And if I do a final decrypt on data that did not have a final
encrypt I get an error.
I suspect I am missing something because using openssl to encrypt the
bytes from a file and in to a file yields a 64 byte file ... just
like my program :-) But I don't understand why.
1) Should I always count on up to 2 extra blocks (1 for the remainder
if any, one for no reason I can tell)?
2) When decrypting, is there a way to find out the original size (in
my case 37)?
3) Am I missing something or is there a bug around here?
4) If I am going to handle large files that require multiple calls to
the Encrypt routines, I presume I would turn the padding off until
the very last block of data? Same with decrypt? My goal would be to
be able to encrypt a file and get the exact same results as command
line openssl. And the reverse.
Thanks,
Eric
This email sent by:
Eric S. Eberhard
(928) 567-3727 Voice
(928) 567-6122 Fax
928-301-7537 -- you may call any time day or night, I turn it off
when I sleep :-) Please try to use a land line first (reception often poor).
Note the change in the domain from vicspdi.com to vicsmba.com
For Metropolis support and VICS MBA Support
http://www.vicsmba.com
Completely updated web site of personal pictures with many new
pictures! Includes horses, dogs, Corvairs, and more.
http://www.vicsmba.com/ourpics/index.html
Corvair pictures including the Judson setup on our 62 Sedan and lots
of pictures of Cheryl's 62 Monza Wagon and our 62 Spyder convertible.
http://www.vicsmba.com/ourpics/corvairs.html
My younger brother Martin has started a very serious car company. A
hot rod (very fast) electric roadster is the first offering. The
chassis is built by Lotus to their specs. Check it
out: http://www.teslamotors.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
