Ahhh!
So, a 15 byte block (or ends with a 15 byte after multiples of 16 bytes) would use a 0x01 in the last position...?
And a whole multiple of 16 blocks would have an extra block filled with 0x0f's...?
My initial testing now looks like I can get it to work.
Thanks!
-Scott Weber
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org-------- Original Message --------
Subject: RE: Looking for (easy) help.
From: "Dave Thompson" <dthomp...@prinpay.com>
Date: Fri, May 11, 2012 3:45 pm
To: <openssl-users@openssl.org>
>From: owner-openssl-us...@openssl.org On Behalf Of scott...@csweber.com
>Sent: Friday, 11 May, 2012 17:09
>I manually padded the input in the C code with spaces. Then I
>manually padded the input file with spaces. Now both cleartexts
>are exactly 16 bytes long.
>The output from the openssl executable is now 32 bytes...?
>Where did it decide to do that?
>So, what do I decide how to pad? How far out do I pad it?
The padding most cryptography uses and openssl commandline
(and EVP_*) does is NOT spaces, it is a count of unused octets
repeated. It was popularized by PKCS#5, see RFC 2898 6.1.1-2.
Because the padding is always nonempty to avoid ambiguity,
if the cleartext is an exact multiple of the blocksize,
padding adds an extra block (and unpadding removes it).
Marek showed you an example, although it's ambiguous because
by coincidence his last plaintext byte was 0a (newline)
and his padding bytes were also 0a (16-6=10).
When you call AES_* (or DES_* etc) directly, you must add
the padding on encrypt and remove it on decrypt yourself.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
