# Tag Info

## Hot answers tagged eax

9

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

7

First, the fact that the data is "easy" to guess (in the sense that an attacker has a one-in-2^32 or a one-in-2^64 chance of guessing correctly) doesn't mean much if the attacker has no way of checking if his guess is correct. Or at least, it's not a problem with the cryptography. Second, even if he does have that ability, the problem of protecting your ...

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

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

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

2

CMAC (or OMAC1) is the underlying MAC algorithm that provides authentication and integrity for EAX. Is stated in NIST SP 800-38B: Because CMAC is based on an approved symmetric key block cipher, such as the Advanced Encryption Standard (AES) algorithm that is specified in Federal Information Processing Standard (FIPS) Pub. 197 [3], CMAC can be ...

1

Wrapping my (now deleted) comments into an answer… OMAC, as described in the OMAC spec and its addendum, is what Rogaway et al provide security proofs for in their EAX paper. If you take a quick look at RFC 4493, you’ll notice that it states: The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message ...

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