Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Why does openssl still pad data for aes-128-cbc encrypting when the file-size%16==0?
892 views
Skip to first unread message
Nicle
Mar 19, 2012, 12:26:34 PM3/19/12
to
Hi all,
I can understand if file-size%16 != 0, openssl will pad data.
But it will also pad 16bytes for those file size exactly 16 times.
For example: original file size 16 bytes, cipher file size: 32 bytes.
Any help will be so appreciated.
Best Regards
Neo
Jakob Bohm
Mar 19, 2012, 1:24:42 PM3/19/12
to
say "the block size of the algorithm you select, e.g. 8
for DES, IDEA, 3DES and Blowfish, 16 for AES and TwoFish
etc."
OpenSSL is using the same padding rule as specified for
SSL connections:
Pad with bytes whose value is the number of padding bytes,
so decryption can see how many bytes to remove to get the
actual file data without padding.
To make this work for file-size%16 == 0, it is necessary
to pad with 16 bytes whose value are all 16, otherwise,
decryption could not tell the difference between a 16
byte file whose last byte was 1 and a 15 byte file.
Some beginners have suggested only padding with 16 x 16
if the last bytes of plain text happens to be one of the
16 padding patterns, but this would cause the size of the
encrypted file to reveal if the last bytes of the plain
text file was one of those values or not, which was
supposed to be hidden by the encryption.
So the rule is to pad with 1 to 16 bytes, each of which is
the number of bytes in the padding.
There is one more rule: If decryption sees a result which
does not end with a valid padding, it must not return an
error message any different from what it would have
returned for any other corrupt file, as otherwise an
attacker can use the error message to tell how close she
is to guessing the secret key.
Of cause if you are just using the "openssl enc" command
line command as a way to access the raw encryption with
your own padding and security around it, then you can
just feed it a multiple of 16 bytes, and then throw away
the 16 bytes of encrypted padding at the end of the result.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Ken Goldman
Mar 19, 2012, 4:11:36 PM3/19/12
to
It makes the response unambiguous.
If a 16 byte file was not padded, how does the receiver know whether the
file was 16 bytes or 1-15 bytes plus padding.
By having at least one byte of padding, and (in some padding schemes)
having the padding itself define the number of padding bits, one can
always recover the length of the file.
On 3/19/2012 12:26 PM, Nicle wrote:
> I can understand if file-size%16 != 0, openssl will pad data.
>
> But it will also pad 16bytes for those file size exactly 16 times.
>
> For example: original file size 16 bytes, cipher file size: 32 bytes.
If a 16 byte file was not padded, how does the receiver know whether the
file was 16 bytes or 1-15 bytes plus padding.
By having at least one byte of padding, and (in some padding schemes)
having the padding itself define the number of padding bits, one can
always recover the length of the file.
On 3/19/2012 12:26 PM, Nicle wrote:
> I can understand if file-size%16 != 0, openssl will pad data.
>
> But it will also pad 16bytes for those file size exactly 16 times.
>
> For example: original file size 16 bytes, cipher file size: 32 bytes.
Dave Thompson
Mar 19, 2012, 9:43:28 PM3/19/12
to
> From: owner-ope...@openssl.org On Behalf Of Jakob Bohm
> Sent: Monday, 19 March, 2012 13:25
> On 3/19/2012 5:26 PM, Nicle wrote:
> > Hi all,
> >
and length (1 byte) are defined as separate fields, so each
padding byte AND the count byte contains the count of the
padding bytes not including the count byte! And TLS allows
'extra' padding -- up to 255 bytes even when the cipher
blocksize doesn't need it. OpenSSL doesn't choose that.
And no padding is required or done for a stream cipher
(pretty much only RC4) or a stream mode (only GCM).
<snip why padding must always be nonempty>
> So the rule is to pad with 1 to 16 bytes, each of which is
> the number of bytes in the padding.
>
That is the rule for PKCS#5 padding, used by default by EVP
and (thus) commandline enc which is apparently the OP's question.
> Of cause if you are just using the "openssl enc" command
> line command as a way to access the raw encryption with
> your own padding and security around it, then you can
> just feed it a multiple of 16 bytes, and then throw away
> the 16 bytes of encrypted padding at the end of the result.
>
Or better just specify -nopad. Also on decrypt, where just
adding a guess block wouldn't work well at all, unless
you're implementing the padding oracle attack.
Commandline enc also by default uses password-based with salt,
which adds another 16 bytes (8 label and 8 salt, regardless
of cipher blocksize) to the file. You can disable that with
-nosalt (but then you have to be careful about passphrase reuse)
or skip PB entirely with -K and -iv (then you must transmit
the IV, either added to the file or along with it).
> Sent: Monday, 19 March, 2012 13:25
> On 3/19/2012 5:26 PM, Nicle wrote:
> > Hi all,
> >
> > I can understand if file-size%16 != 0, openssl will pad data.
> >
> > But it will also pad 16bytes for those file size exactly 16 times.
> >
> >
> > But it will also pad 16bytes for those file size exactly 16 times.
> >
> The following description says 16, when it should really
> say "the block size of the algorithm <snip>"
>
> OpenSSL is using the same padding rule as specified for
> SSL connections:
>
> Pad with bytes whose value is the number of padding bytes,
> so decryption can see how many bytes to remove to get the
> actual file data without padding.
>
Note TLS uses a slightly modified rule: the padding (N bytes)
> OpenSSL is using the same padding rule as specified for
> SSL connections:
>
> Pad with bytes whose value is the number of padding bytes,
> so decryption can see how many bytes to remove to get the
> actual file data without padding.
>
and length (1 byte) are defined as separate fields, so each
padding byte AND the count byte contains the count of the
padding bytes not including the count byte! And TLS allows
'extra' padding -- up to 255 bytes even when the cipher
blocksize doesn't need it. OpenSSL doesn't choose that.
And no padding is required or done for a stream cipher
(pretty much only RC4) or a stream mode (only GCM).
<snip why padding must always be nonempty>
> So the rule is to pad with 1 to 16 bytes, each of which is
> the number of bytes in the padding.
>
and (thus) commandline enc which is apparently the OP's question.
> Of cause if you are just using the "openssl enc" command
> line command as a way to access the raw encryption with
> your own padding and security around it, then you can
> just feed it a multiple of 16 bytes, and then throw away
> the 16 bytes of encrypted padding at the end of the result.
>
adding a guess block wouldn't work well at all, unless
you're implementing the padding oracle attack.
Commandline enc also by default uses password-based with salt,
which adds another 16 bytes (8 label and 8 salt, regardless
of cipher blocksize) to the file. You can disable that with
-nosalt (but then you have to be careful about passphrase reuse)
or skip PB entirely with -K and -iv (then you must transmit
the IV, either added to the file or along with it).
Nicle
Mar 20, 2012, 12:04:06 AM3/20/12
to
Dear All,
Thanks for reply.
And I have more question. For example, the actual file size is 16B, and it will be encrypted to 32B.
Then, how does decrypt side know its actual size is 16B or 17B?
2012/3/20 Dave Thompson <dtho...@prinpay.com>
Ken Goldman
Mar 19, 2012, 1:13:34 PM3/19/12
to
It makes the response unambiguous.
If a 16 byte file was not padded, how does the receiver know whether the
file was 16 bytes or 1-15 bytes plus padding.
By having at least one byte of padding, and (in some padding schemes)
having the padding itself define the number of padding bits, one can
always recover the length of the file.
On 3/19/2012 12:26 PM, Nicle wrote:
>
If a 16 byte file was not padded, how does the receiver know whether the
file was 16 bytes or 1-15 bytes plus padding.
By having at least one byte of padding, and (in some padding schemes)
having the padding itself define the number of padding bits, one can
always recover the length of the file.
On 3/19/2012 12:26 PM, Nicle wrote:
>
> I can understand if file-size%16 != 0, openssl will pad data.
>
> But it will also pad 16bytes for those file size exactly 16 times.
>
>
> But it will also pad 16bytes for those file size exactly 16 times.
>
> For example: original file size 16 bytes, cipher file size: 32
> bytes.
> bytes.
Ken Goldman
Mar 20, 2012, 10:15:26 AM3/20/12
to
It depends on the padding scheme.
E.g., PKCS#7 / RFC2630 pads with k bytes, all with value k. So you
decrypt the 32 bytes and look at the pad bytes. If the pad values are
16, the actual size is 16. If they're 15, the actual size is 17.
On 3/20/2012 12:04 AM, Nicle wrote:
>
> And I have more question. For example, the actual file size is 16B, and
> it will be encrypted to 32B.
>
> Then, how does decrypt side know its actual size is 16B or 17B?
>
E.g., PKCS#7 / RFC2630 pads with k bytes, all with value k. So you
decrypt the 32 bytes and look at the pad bytes. If the pad values are
16, the actual size is 16. If they're 15, the actual size is 17.
On 3/20/2012 12:04 AM, Nicle wrote:
>
> And I have more question. For example, the actual file size is 16B, and
> it will be encrypted to 32B.
>
> Then, how does decrypt side know its actual size is 16B or 17B?
>
Nicle
Mar 21, 2012, 10:15:14 PM3/21/12
to
0 new messages