Hot answers tagged

45

TL;DR if you're reading this in 2020, applications should be using GCM mode. 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 ...


15

The rationale goes this way: On a "big" system like a PC or a smartphone, ChaCha20+Poly1305 or AES/GCM are very efficient; the latter is fast because the hardware provides dedicated opcodes that implement both AES itself (aesenc, aesenclast on x86 CPU) and the GHASH part of GCM, which is used for the integrity check (pclmulqdq opcode on x86 CPU). On much ...


10

This additional 32 bit nonce acts as a salt, and makes multicollision attacks $2^{32}$ times harder. In this attack, the attacker collects a huge number of TLS sessions, each with a record encrypted with the same nonce. He then selects a random key, and generates the counter mode keystream for the key (and the fixed nonce); he then checks if that key ...


5

CCM puts together two different modes of operation (at least in the name). Does it mean data is encrypted using counter mode and then encrypted using CBC; kind of a double encryption? Yes, kinda. With the CCM mode of operation, you authenticate your data first using CBC-MAC which is, well, basically CBC on the data to be authenticated. Now on the ...


5

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


4

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


4

It (GCM) requires a 96-bit IV which is usually split into a 32-bit explicit nonce and a 64-bit counter. GCM uses a 96 bit IV internally, but the size of the IV is actually configurable (implementations may vary, of course). From the specification: $1 ≤ \operatorname{len}(IV) ≤ 2^{64}-1$. however, the same specification also indicates: For IVs, it ...


4

Basically you should never reuse a key and neither should you use CBC-MAC. CCM is considered secure because the designer knew about the issues of reusing a key and CBC-MAC length extension issues. The scheme is designed to be secure regardless of these issues. In a general sense you should always use two keys unless you can prove your scheme to be secure ...


4

AES - CCM, why not use CMAC inside instead of CBC-MAC? So in their original suggestion of the mode for 802.11i (for WPA2) the only reason given by Whiting, Housley and Fergueson is: A combination of counter mode encryption and CBC-MAC authentication is proposed here. These modes have been used and studied for a long time, with well-understood ...


3

Yes, you are correct, as long as it really only is the AES part which could dysfunction. Quoting another source, for example Wikipedia's CCM page: These two primitives are applied in an "authenticate-then-encrypt" manner, that is, CBC-MAC is first computed on the message to obtain a tag t; the message and the tag are then encrypted using counter mode....


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

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


3

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


3

However, if data is encoded with a nonce that's clearly visible (one common implementation prepends the ciphertext with a nonce), then it is possible to replace the entire ciphertext with a previously valid ciphertext (since the nonce is known). This is known as a 'replay attack', and is typically handled at a higher level. One easy way is the TLS approach;...


2

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


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

In draft 14, which is not the latest draft at the time of writing there are two places where a hash is used: the one for signature generation / verification using the private key / public key pair of the leaf certificate and the one used as configuration parameter for HKDF (session key derivation) For signature generation / verification ...


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


2

NIST SP800-38C (PDF) has four examples in Appendix C. I'll copy the first example here: In the following example, Klen = 128, Tlen=32, Nlen = 56, Alen = 64, and Plen = 32. K: 40414243 44454647 48494a4b 4c4d4e4f N: 10111213 141516 A: 00010203 04050607 P: 20212223 B: 4f101112 13141516 00000000 00000004 ...


2

Let $M_k$ be CBC-MAC under the key $k$: for blocks $b_1, b_2, \dots, b_\ell$, $$M_k(b_1 \mathbin\| b_2 \mathbin\| \cdots \mathbin\| b_\ell) = E_k(\cdots E_k(E_k(b_1) \oplus b_2) \cdots \oplus b_\ell).$$ The message $m = m_1 \mathbin\| m_2$ collides with the message $m' = M_k(m_1) \oplus m_2$ under $M_k$, since \begin{align} M_k(m_1) &= E_k(m_1), \\ ...


2

In general the authentication tag size is indeed generated by simply using the first (leftmost, in most byte array representation) bits. In general Tlen - the length of the tag - is supposed to be a multiple of eight, so a tag size of 64 bits results in the leftmost 8 bytes. You cannot just change the block size of a block cipher. AES is only supporting a ...


2

No, there is no black-box type way of increasing the security strength of the tags of CCM and GCM. Because in this case you would apply a deterministic function which couldn't bring you any increases in security as a collision on the input would still lead to a collision on the output. For CCM there is also no non-black box type of way, at least if you want ...


2

The additional 8 bytes are the Message authentication code (MAC), which is called the Message integrity check (MIC) in Bluetooth terminology. For more info, see here.


2

You can't change AES's block size—it's always 16 bytes. But you can use AES to conceal messages, and prevent forgery of messages, of other sizes, and AES-CCM is one way to do just that. Provided you only ever use a key exactly once, or have a unique (say) sequence number called a nonce for each message transmitted under the key, AES-CCM can encrypt a ...


2

Is there any probability that channel errors make the change in a frame go un-detected through CBC-MAC? For any Message Authentication Code, there is always a probability [1] that the modified message will just happen to verify against the modified tag. In your extreme "worse possible case" scenario, it's quite simple to compute; your ...


2

The standard definition of CCM is NIST SP800-38C. Not all of the symbols you cited appear in NIST SP800-38C. If you're using a different reference, you'll need to cite it to get a more specific answer. [C]an anyone explain what the difference is between $B_i$'s and $m$? The $B_i$ are the blocks of input for CBC-MAC, derived from encoding the nonce, ...


2

It seems you're worried about two distinct attacks: replay attack (attacker reads a packet and re-sends it later), and a "delay attack" (attacker intercepts a packet, blocks it, and sends it later). The replay attack can be avoided with counters or timestamps; as you mentioned, timestamps can be easier. The hard part is keeping clocks synchronized. The ...


1

There are multiple ways you can get the key in attacking AES. Let's say you have the known cipher-text, $ct$, and a list of all S-box lookups used in the last round of AES (maybe from a cache-attack). We know that $ct$ is equal to $k \oplus y$, where $y$ is the intermediate state after the last S-box computation. Now, we can go through each byte of $ct$, ...


1

See RFC 3610, 2.2 Authentication (page 3): The message blocks are formed by splitting the message $m$ into 16-octet blocks, and then padding the last block with zeroes if necessary.


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