4

I am currently investigating use of EAX mode for a dedicated application and following useful clarifications received from my previous post , to consider according to my applicable input security requirements (separate keys for encryption and authentication) either :

  • the Baseline solution where EAX is used in strict respect of its specification and so with one unique key K
  • or an eventual (only if it has a sense) alternate solution with insertion before EAX, of a key derivation function allowing to generate from the unique input key K, one KA key for OMAC functions and one KE key for CTR function

Can such alternate solution be envisaged or may it violate EAX mode specification and associated security proof ?

Community
  • 1
william_fr
  • 653
  • 5
  • 15

2 Answers2

5

As noted in archie's answer to your earlier question, the EAX paper first defines a generic encrypt-then-MAC composition method called EAX2, with separate keys for the encryption and MAC components, and proves its security (Appendix C). It then defines EAX as EAX2 instantiated with CTR mode and OMAC, and with the same key used for both components, and then uses an additional result about OMAC (Appendix D) to prove that this composition remains secure even with the key reuse (Appendix E).

Anyway, what all this amounts to is that if you take EAX mode and modify it so that the OMAC key is independent from the CTR mode key, and make no other changes, then what you get is an instance of EAX2 (with CTR mode as the encryption method and OMAC as the PRF). If you trust the proof that EAX is secure, then, by the same argument, you should also trust the sub-proof that shows EAX2 to be secure.

That said, there do exist some potential disadvantages to this change. For example, even though the security proof of EAX2 is essentially a part of the security proof of EAX, that does not necessarily mean that authorities that have certified EAX to be secure necessarily accept EAX2 as certified as well. Also, more practically, verifying the correctness of your implementation of EAX2 might be more difficult, since AFAIK there's no standard set of test vectors available for EAX2.

All in all, if at all possible, I'd recommend sticking with EAX and using an existing, known-to-be-good implementation of it. However, if you do need to use generic encrypt-them-MAC composition with separately derived keys for regulatory or other reasons, EAX2 is a pretty good way to implement it.

Community
  • 1
Ilmari Karonen
  • 46,700
  • 5
  • 112
  • 189
1

No, you definitely shouldn't change the internal guts of EAX. That would invalidate the security proof and might introduce subtle security problems. (You can look at EAX', a minor tweak to EAX which was suggested for standardization -- but was eventually discovered to have a serious but non-obvious flaw that was introduced by the tweak.)

My suggestion would be to articulate what problem you are trying to solve: what's the application requirement that makes you want to tinker with the internals of EAX? That might enable folks on this site to brainstorm about the best way to meet that requirement.

D.W.
  • 36,982
  • 13
  • 107
  • 196