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 List openssl-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.teslamotors.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
