> From: owner-openssl-us...@openssl.org On Behalf Of Tage Korsdal Nielsen
> Sent: Friday, 01 February, 2013 03:19

> New to OpenSSL, but designing a PC application that must encrypt a 
> stream of 48 bytes message blocks to a USB device with aes128.The iv's 
> gets generated and synchronized when the connection with the device is 
> established, and I would like to keep the same cipher context going 
> until the the device is disconnected.
> 
> I wrote some test code <snip>
> The first encryption/decryption is ok, but then it starts altering the 
> order of the individual cipher blocks in my message, and on the first 
> decryption it reports that only 32 bytes have been decrypted, although 
> the entire 48 byte output buffer is correct.
> 
EVP_ for a block cipher by default uses PKCS#5 padding. This is 
added on the Encrypt side (only) when you do Final, and checked 
and removed on the Decrypt side. To do this, the Decrypt side 
must run 1 block "behind" the ciphertext. I'm not sure why 
(apparently-correct) data is written beyond the returned count 
in this case, but any data beyond the count is not valid. 
Padding is the default because it supports arbitrary-length 
data which is usually what people want.

If you want padding, you can't "keep the context going". 
If you don't want padding, and if your plaintext is chosen 
as a multiple of the cipher blocksize likely you don't:
  EVP_CIPHER_CTX_set_padding (ctx, 0);
Or use the low-level AES_* routines; they don't do padding 
(but do do most modes, like CBC). Note without padding 
your data *must* be a multiple of the blocksize.

Your "odd_length" does do Final on each side and looks like 
it would work if you were using a context not already messed up 
by your previous code. But per below it isn't what you want.

> I then tried with RC4, here everything was ok.
> 
RC4 is a stream cipher and doesn't need padding.

> Since I need the above functionallity with AES, I did the following 
> "hack", in evp_enc.c line 478: <snip: basically munged padding>
> Then it worked for my streamed block sized aligned messages, but of 
> course not for the odd length test (which I will never use anyway).
> 
> Strangely (for me anyway) RC4 code still works after the hack, both 
> block size aligned stream and odd length.
> 
See above.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to