I have been seeing code using "AES/EAX/NoPadding" but I'm also aware that padding schemes are supported for AES-EAX. I would like to know if choosing NoPadding as a padding scheme has security implications for EAX mode of operation. Thanks!
1
-
1$\begingroup$ May we assume a Java security provider for the answers? If so, which provider are you targeting specifically? Strings like "AES/EAX/NoPadding" only make sense in specific context. $\endgroup$– Maarten Bodewes ♦Commented Aug 18, 2016 at 17:17
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
5
The EAX mode of operation is defined for 128 bit block ciphers. It consists of a combination of CTR mode for confidentiality and OMAC for authentication and nonce derivation. CTR mode does not require padding, but OMAC does, since it is based on CBC-MAC, when the length of the plain text is not a multiple of 128 bits.
Hence, such specifications might mean one of two things.
- It means that standard OMAC padding is implied and doesn't have to be specified twice.
- It means that the plain text will always be an integer multiple of 128 bits, meaning that the OMAC padding algorithm would never have to be invoked.
Hence, if the API doesn't require you to explicitly specify the OMAC padding specified in the EAX paper, NoPadding will comply with the security claims in the EAX paper.
That said, in some cases there are additional security requirements for hiding the length of the plain text, by padding each message to a fixed length, but that falls outside of the scope of EAX, as well as most (all) other AEAD modes as well.
answered Aug 17, 2016 at 8:46
-
$\begingroup$ For Java it is almost certainly the first one, although technically it may still rely on the provider implementing EAX (Bouncy probably). Note that OMAC is also known as CMAC and that CTR is actually called SIC (Segmented Integer Counter) in Bouncy itself. Oh, and you're missing the conclusion: (
NoPaddingis secure). $\endgroup$– Maarten Bodewes ♦Commented Aug 17, 2016 at 22:05 -
$\begingroup$ CMAC is based on OMAC, but EAX uses OMAC in both CMAC conformant and non-conformant ways. SIV mode, on the other hand, uses only CMAC. $\endgroup$ Commented Aug 17, 2016 at 22:47
-
$\begingroup$ Hmm. If I remember correctly then CMAC is identical to the first version of OMAC. But I could be mistaken. $\endgroup$– Maarten Bodewes ♦Commented Aug 17, 2016 at 22:50
-
1$\begingroup$ No, you are right, but EAX mode also defines a function $OMAC^{\tau}_K(M)$ which is basically OMAC with pre-padding. $\endgroup$ Commented Aug 17, 2016 at 23:01
-
$\begingroup$ Thanks for the answers, that's exactly what I was after. $\endgroup$– twrchCommented Aug 18, 2016 at 17:37
$\begingroup$
$\endgroup$
Assuming this is in Java, then EAX represents the entire algorithm, including the specific padding that is always performed for OMAC. The internal CTR (counter mode) encryption doesn't need padding. So the entire cipher doesn't need to be specified any padding at all.
As EAX certainly doesn't require padding to be used before the algorithm is applied, the answer is most certainly "no".
Even if it would, the padding mode for symmetric modes of operation (such as CBC) are not required for the mode to be secure. This differs from padding modes such as OAEP, which are required to make RSA secure.
Actually, it's rather the opposite: PKCS#7 compatible padding for CBC ("/PKCS5Padding" in Java) may introduce vulnerabilities against padding oracle attacks.
Padding for block cipher modes of operation may somewhat alleviate issues with side channel attacks based on the ciphertext length. The length of a ciphertext may leak quite a lot of information about the plaintext that was encrypted. In general you may need additional security measures above standard padding such as implemented for the cipher, if you want to protect against such side channel attacks.
answered Aug 18, 2016 at 17:14