4
$\begingroup$

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 ?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
5
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ @ Ilmari Karonen: Perfectly clear; as indicated answer & explanations given by Archie in previous post were also quite clear, and in fact I realize that I incorrectly understood EAX2 rather as a reference construction aimed to define EAX and demonstrate its security proof, than a candidate AEAD composition. So now the choice appears clearly between trusted EAX or (Key derivation plus) trusted EAX2 . Thanks to all. $\endgroup$
    – william_fr
    Jul 3, 2013 at 7:02
1
$\begingroup$

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.

Improve this answer
$\endgroup$
6
  • $\begingroup$ i understand and i really don't aim to tinker with internal design of any trusted mode it's not my rôle. i have to design a solution using EAX which will have to pass Common Criteria evaluation and one of my applicable security requirement indicates explicitely use or separate keys for authentication and for encryption. I can of course use gcm mode with derived ghash key but i am interested with eax and embedded robust omac for authentication. $\endgroup$
    – william_fr
    Jul 2, 2013 at 19:49
  • $\begingroup$ @william_fr, what is the source of the requirement to use separate keys for authentication and encryption? That sounds like it might be a well-intentioned requirement that is rendered irrelevant by EAX and thus not applicable to your situation. (If you were using generic composition, e.g., encrypt-then-authenticate, it would be a good suggestion: but when using EAX it is no longer necessary.) I think you should do some requirements analysis to backtrace where the requirements are coming from and what their purpose is. $\endgroup$
    – D.W.
    Jul 2, 2013 at 20:09
  • $\begingroup$ the source is the french équivalent of nist fips-140-2 that is applicable to my application covering various reqts about crryptographic fonctions and keys handling for solutions that will be then subject to Common Criteria security évaluation. $\endgroup$
    – william_fr
    Jul 2, 2013 at 20:36
  • $\begingroup$ @william_fr, OK, in that case I don't have any helpful suggestions. Sorry. You might need to focus on compliance rather than technical security issues. It's possible that compliance concerns might force you to choose, say, generic composition (encrypt-then-authenticate) instead of EAX, even though there are no valid security reasons to do so -- just so you can comply with the standard. If so, that's a flaw in the standard, but hey, what can you do? If you gotta comply, you gotta comply. $\endgroup$
    – D.W.
    Jul 2, 2013 at 20:43
  • $\begingroup$ i agree of course . solution is either a generic ctr then cmac composition with key dérivation or reuse of gcm which only raised a warning in previous application to the concerned reqt because of partial key derivation (K and H used from input K). still thanks for your precise explanations. $\endgroup$
    – william_fr
    Jul 2, 2013 at 21:03

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.