I am using EAX AEAD with an 8-byte message header which carries a 32-bit sequence number, a message length, and some other bits that I don't mind exposing. Assuming the sequence number never repeats for the same key, is there any security difference between treating that as a 4-byte nonce with 4 bytes of "associated data" or just calling it an 8-byte nonce and skipping any MAC calculations on the header?
$\begingroup$
$\endgroup$
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
7
The following picture shows EAX:
As you can see there is a OMAC calculation (or CMAC as it is usually called) over both $N$ (the nonce) and $H$ (the header / associated data). With regards to security it doesn't matter where you place the nonce and the other data in the header.
I'll not go into the security of XOR'ing the calculated OMAC values for nonce, header and ciphertext. EAX has a security proof, as long as that holds the cipher should be secure.
It would be best to treat the nonce and the rest of the header separately, as that would be the expected way of treating the input data. It also allows you to pre-calculate the header's OMAC value if it remains static. Note that you could remove the size of the plaintext from the OMAC calculation. You could calculate size of ciphertext + tag, and verify that.
answered Jul 16, 2015 at 10:02
-
$\begingroup$ Yes, picture is good, thanks. I get your point about separating nonce and header in an api. But, each OMAC seems to require at least 1 AES block encryption. So, if header size + nonce size is less than block size in a given application there is some efficiency in merging the header into the nonce. $\endgroup$ Jul 16, 2015 at 13:18
-
$\begingroup$ I would only perfrom micro optimalizations when they are really required. EAX is not the most speedy authenticated mode of encryption, choosing GCM or (even) OCB may make more sense if speed is that important to you. $\endgroup$– Maarten Bodewes ♦Jul 16, 2015 at 13:51
-
$\begingroup$ I will have a lot of small messages, sometimes header only, so 1 extra AES per message is not negligible. My objection to GCM is the implementation I looked at required a lot more memory than EAX. I will have many 1000's of active sessions, and want to minimize memory footprint. EAX needs only about 300 bytes per key context. Possibly I will investigate whether there are more memory efficient implementations of GCM if EAX proves too slow. $\endgroup$ Jul 16, 2015 at 15:46
-
1$\begingroup$ OK. Note that I don't see any change in the general algorithm even if H is empty. Precalculating H is still advisable. If you don't have too many separate, changing bits you could precalculate it for each possible header. $\endgroup$– Maarten Bodewes ♦Jul 16, 2015 at 19:10
-
1$\begingroup$ The implementation I am looking at by Brian Gladman sets the H OMAC to 0 when there are no header bits, bypassing an AES block encrypt. $\endgroup$ Jul 16, 2015 at 19:21