> From: owner-openssl-us...@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). ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
