Hot answers tagged

11

CCM (Counter with CBC-MAC) Message authentication (via CBC-MAC) is done on the plaintext not the ciphertext. (This is generally not a desireable feature.) On the encrypt operation, the encryption and MAC could happen in parallel, but generally do not (typically because there is just one AES engine in a chip, just one AES thread at a time, etc.). Similar ...


4

Yes, if the client and the server use the same key to encrypt their messages (instead of having separate keys for client-to-server and server-to-client communication), then you need to ensure that they cannot ever use the same nonce. One way to do that would be to, say, let the client use only even nonce values, and let the server use only odd nonce values. ...


3

CCM mode uses CTR mode the encryption and CBC-MAC for the authentication. For a security proof you can refer to On the Security of CTR + CBC-MAC. With CTR the fact that AES is a PRP rather than PRF starts to show after $2^{64}$ blocks have been encrypted. In practice this does not lead to a very effective attack even then. After a similar number of blocks ...


3

Regarding GCM mode and the uniqueness of the nonce, it should be noted that EAX mode and OCB mode also require unique nonces. One potential problem EAX mode has, which neither GCM or CCM have, is that it is hard to implement it in such way that you can guarantee that the probability of nonce collisions is zero; only that it is acceptably low. OCB mode has ...


2

Is this recommendation given because of user temptation to use unverified data without checking the MAC? Yes. Note the word "released" instead of "stored". Or are there deeper ramifications? That should not be possible; CCM uses CBC-MAC with known length and CTR mode encryption. There are - to my knowledge - no known plaintext attacks possible on ...


2

For any $k$-bit MAC, an attacker blindly guessing a tag has a one-in-$2^k$ chance of successfully forging a message. Thus, the expected number of attempts needed to forge a message by brute force is $2^{256}$ for a 32-byte tag, $2^{128}$ for a 16-byte tag, and $2^{64}$ for an 8-byte tag. In practice, attempting $2^{128}$ forgeries is far beyond the reach ...


2

The CTR part of CCM is basically the last for loop in the _ctrMode function: for (i=0; i<l; i+=4) { ctr[3]++; enc = prf.encrypt(ctr); data[i] ^= enc[0]; data[i+1] ^= enc[1]; data[i+2] ^= enc[2]; data[i+3] ^= enc[3]; } i.e. CTR is simply: encrypt a counter block with a block cipher, xor the encrypted block into the data, ...


2

No. The attacker cannot easily recover the secret key. The attacker cannot modify the ciphertext to something that decrypts to some other plaintext. This remains true even if the attacker can encrypt an arbitrary number of chosen plaintexts. This is known as "IND-CCA2 security" (security against adaptive chosen plaintext/ciphertext attack). CCM ...


2

Like Ilmari Karonen wrote, you can ensure that nonces picked by two senders do not collide by reserving one bit (like the lowest) to differentiate them. If you use random nonces this is not required, since the probability that a random nonce collides depends only on the total number of nonces generated, not who generates them. In fact, reserving a bit would ...


1

There are different "brute force" attacks related to CBC-MAC: Key search, which depends on key size and not the length of the authentication tag. Tag guessing, where you just try a random tag for a modified message succeeds with probability $2^{-t}$ if the tag is $t$ bits long. The first is not related to the tag length at all and even if you use AES-128 ...



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