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]
