Tag Info

Hot answers tagged

5

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 ...


5

Using EAX with a 64-bit block cipher is problematic, because the short block size causes some weaknesses due to internal collisions. I do not recommend it. Use a 128-bit block cipher. Indeed, the world has moved away from 3DES and towards AES exactly because of these fundamental problems with a 64-bit block size: the internal collision effect means that, ...


5

GCM mode already incorporates any params that could affect the outcome of the decryption. The associated authenticated data is there to allow you to rely on context for your decryption. For example, say you are encrypting some records associated with a user. You may want to include the user's database ID as the authenticated data. If a user found a way to ...


4

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 ...


3

In RFC 4764, the ciphertext does not include the authentication tag created by EAX (which is treated separately); you can see this in figure 1, where they show the ciphertext (of length L) and the tag separately. In contrast, the test vectors do include the authentication tag, and that additional length make the ciphertexts look longer.


3

While the EAX mode permits truncating the tag to any length $\tau$ between 0 and $n$ bits, where $n$ is the block size of the underlying block cipher, this should only be taken as a statement that truncating the tag in EAX mode does not introduce any security issues beyond the obvious (an attacker only needs $2^\tau$ attempts to froge a $\tau$-bit tag by ...


2

So you want to use EAX with a block cipher with a 56-bit key. Presumably, this is for a good reason. Your idea is to include a (long!) fixed string in the OMAC to slow down nonce creation. Since the attacker must know the nonce to test if a key is correct, this should also slow down a brute force attack. Instead of modifying EAX, you could use EAX in a ...


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 ...



Only top voted, non community-wiki answers of a minimum length are eligible