AES encryption block size

[Alex Chen]

When the padding is disabled by setting the padding size to 0 in EVP_CIPHER_CTX_set_padding(), is the output data block size the same as the input block size?
Will this reduce the encryption strength?

Alex

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

[Jakob Bohm]

On 3/28/2012 11:49 PM, Alex Chen wrote:
> When the padding is disabled by setting the padding size to 0 in EVP_CIPHER_CTX_set_padding(), is the output data block size the same as the input block size?
> Will this reduce the encryption strength?

Padding doesn't change the block size at all.

Padding changes the number of plain text bytes so any number
of bytes can be encrypted with an algorithm that can only
encrypt a multiple of its block size.

For example AES has a block size of 16 bytes, so without
padding, it can only encrypt 0, 16, 32, 48, 64, ... bytes.
Padding allows you to encrypt 0, 1, 2, 3, ... bytes by
adding 1 to 16 bytes extra, which are then removed after
decryption (only if you tell the decryption that padding
was used).

Because a plain text of 16 bytes could be the same 16 bytes
as what OpenSSL creates when padding a shorter plain text,
OpenSSL has to also add padding to a 16 byte plain text
when padding is enabled, so the decryption can tell the
difference between such a 16 byte plain text and a shorter
plaintext padded to 16 bytes.

The same principle applies to any other multiple of the
block size (0, 32, 48, 64, ...)

For DES, 3DES, Blowfish etc. the block size is 8 bytes,
but the principle is the same.

The above padding description is for modes that can only
encrypt a whole number of blocks by themselves, such as
CBC, ABC, ECB etc.

Some other modes have their own way to encrypt arbitrary
number of bytes and don't need additional padding.

Thus the "padding" option tells EVP if you want a kind
of encryption that can encrypt any number of bytes, or
one that can only encrypt a multiple of the block size.
And you need to set it the same when decrypting, so this
is something that must be decided at protocol/file
format design time.

P.S.

Next time, please start a new thread by using the
"new mail" button, not the "reply" button.


--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
<call:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Dave Thompson]

> From: owner-ope...@openssl.org On Behalf Of Alex Chen
> Sent: Wednesday, 28 March, 2012 17:50

> When the padding is disabled by setting the padding size to 0
> in EVP_CIPHER_CTX_set_padding(), is the output data block
> size the same as the input block size?
> Will this reduce the encryption strength?
>

You don't set the *size* only a *flag*. zero=no padding,
nonzero=padding. If padding is enabled, its size is determined
by the blocksize of the 'cipher', really the cipher+mode.

The blocksize is always the same for a given cipher. If you mean
the size of the plaintext (input to encryption) or of the ciphertext
(output from encryption), those are separate from the blocksize.

AES-ECB* or AES-CBC have a blocksize of 128 bits = 16 bytes.
Without padding, the (total) plaintext must be a multiple of
the blocksize, and the ciphertext is the same size.
With padding, the ciphertext will always be at least one byte
longer, and may be up to a block longer. Specifically, the
ciphertext size will be the least multiple of the blocksize
strictly greater than the plaintext size.

(* Some naive uses of ECB have proven insecure. Unless you
know the risks and have avoided or mitigated them, don't use it.
Actually, improper uses of other modes have caused trouble also,
but naive uses of ECB have caused *more* trouble.)

AES-OFB or AES-CFB or AES-OFB are stream modes, with an effective
blocksize of 1 byte. (The actual modes can go down to 1 bit, but
the OpenSSL implementation cannot.) Even if padding is enabled
in EVP, it is not actually done here. The ciphertext is the same
size as the plaintext (except if you count the IV as part of the
ciphertext, as is sometimes done, also for CBC).

Padding doesn't alter the 'strength'. However, when padding is used
(i.e. for block modes) if the decryptor gives a different response
to a sender (and presumed encryptor) for an attempted decrypt that
finds bad padding than it does for other errors, that can aid an
attacker who can submit tampered or forged ciphertexts. So don't
do that. Note that if the decryptor checks padding errors before
doing some time-consuming processing of the decrypted data,
merely the difference between a quicker error response or a
slower error response constitutes 'different'; this is a
'timing attack', part of the category of 'side-channel' attacks.

A perfect countermeasure is to give no response at all, ever.
But often that doesn't provide the functionality desired.

A generic countermeasure is to authenticate the ciphertext
(a.k.a. encrypt-then-authenticate). Assuming the attacker can't
break the authentication (and if he can, you're in deep trouble)
the error response gives no usable information about the decrypt
and its putative plaintext. Of course authentication further
increases the size of the ciphertext, and requires additional
key management (*don't* use the same key for both, because that
also has led to successful attacks).

[Dave Thompson]

> From: owner-ope...@openssl.org On Behalf Of (me)
> Sent: Wednesday, 28 March, 2012 20:45

> AES-OFB or AES-CFB or AES-OFB are stream modes [with no padding]

Sorry; I meant to write -OFB or -CFB or -CTR.

While I'm correcting, -GCM is also a (new) stream mode,
implemented in 1.0.1; it doesn't *pad* the encryption
as such, but does add an authenticator value.