4
$\begingroup$

I am actually checking use of EAX AEAD mode, and following EAX spec review (scheme definition for my part), my question is: what about the derivation of the authentication and encryption keys? In the described scheme the same input key $K$ appears used on all OMAC (authentication) & CTR functions. Did I miss something important as it would be surprising that the requirement of distinct authentication/encryption keys is not respected with EAX ?

I also have two other questions, but of less importance:

  • When comparing with GCM, I noted that C/AD length parameters are not taken into account in MAC calculation. Does it have real importance for security (message extension attack)?

  • Initial counter ICB for CTR function results from one OMAC operation; so as ICB LSBits are not set to 0 value, it means to handle incrementation of a 128 bits word at each block cipher call by CTR function?

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ GCM is patent-free, isn't it? $\endgroup$
    – pg1989
    Jun 25, 2013 at 18:00
  • $\begingroup$ of course . i think to eax as alternate mode to gcm among two passes & patent free ae modes. post updated according to your remark. $\endgroup$
    – william_fr
    Jun 25, 2013 at 18:25
  • $\begingroup$ Welcome to Crypto.SE, william_fr! In the future, I encourage you to split your questions apart (one question per question). This helps keep things straight. Don't feel bad about posting three different questions on the same day; if they're all good, on-topic questions, that's perfectly fine! $\endgroup$
    – D.W.
    Jun 27, 2013 at 18:04
  • $\begingroup$ OK thanks for your feedback. I feel during that first week on present forum (that i strongly appreciate)to have experimented (not intentionnaly of course) all kinds of errors (post title, post content, comment missed with answers, ..) so I note all your remarks to correct it. $\endgroup$
    – william_fr
    Jun 28, 2013 at 5:52

1 Answer 1

Reset to default
5
$\begingroup$

The same key is indeed used in EAX to key both the CTR mode and the underlying OMAC (which is actually used in 3 distinct phases: randomising the CTR nonce, authenticating the Additional Authenticated Data, and authenticating the Ciphertext). This is explicitly acknowledged in the security proof.

Where EAX differs from a naive reuse of the key is that it initialises each use of OMAC with a distinct parameter, and initialises the CTR mode cipher with one of the OMAC outputs, effectively randomising that as well. The security proof of this single key approach is (to quote the authors) "novel and involved" and "surprisingly complex", but seems to have stood up to peer review.

It's worth noting that in the EAX paper, 3 modes are actually defined:

  • EAX2 is a general composition method for combining a cipher and a MAC to produce an authenticated cipher using two keys Key1 != Key2.
  • EAX1 is a composition of EAX2 with one Key == Key1 == Key2
  • EAX is a composition of EAX1 with CTR and OMAC

The security proofs in the EAX paper are provided for EAX2 and EAX, but not EAX1 (the proof of EAX relies on the properties of OMAC, and so doesn't extend to general use of EAX1).

The lengths of the Ciphertext and AAD are not explicitly handled in EAX, which allows EAX to operate as an online mode (processing data as it arrives without buffering more than one block). The authentication in EAX is simply processing the entire sequence of AAD and Ciphertext with OMAC, and the security proof for that (and any other secure MAC) naturally excludes any message extension attacks - any message extension resulting in the same MAC would be a forgery, and instantly invalidate the scheme as a secure MAC.

CTR mode has to handle incrementation of the nonce/counter value in any implementation - the starting value of the counter is arbitrary (and in the case of EAX pseudo-random). This isn't difficult (BouncyCastle for example does it in one line of code).

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ As an aside, EAX was proposed as a replacement for CCM, and CCM uses the same key for encryption and authentication, too. (So going back to the wording of the original question, it was not a requirement or precedent that different keys must be used for the encryption and authentication functions.) $\endgroup$
    – B-Con
    Jun 26, 2013 at 9:28
  • $\begingroup$ Great thanks for detailed & pertinent answer which comforts me in the idea that EAX with OMAC is a very interesting solution when considering GHASH relative fragility with GCM . Two precisions: A/ I referred to security requirements for distinct A/E Keys that always apply for security solutions to be certified / evaluated (NIST FIPS-140, or Common Criteria) -B/ For CTR counter incrementation I uniquely thought to the case of a hardware implementation (FPGA or ASIC) and eventual impacts of handling a complete 128 bits word incrementation rather than a 32 bits word with CTR32 classical scheme $\endgroup$
    – william_fr
    Jun 26, 2013 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.