Security of authenticated encryption modes gcm & ccm

I have two questions for Clarification for AE mode choice criteria

• GCM : it appears to be actually the most popular and widely used AE mode of operation. however it is also well-known to be highly sensitive (more than other AE modes ?) to IV uniqueness requirement and completely fails if such requirement is not respected'. I personnaly in regard with planned target domain of application consider this as a weakness . So such weakness should'not weight in the criteria for AE mode selection ? Remain GCM the one of most powerful AE mode despite this weakness ? isn't EAX or OCB if no more patented a more efficient & secure choice ?

• CCM : I understood via such mode review that it is based on MacThenEncrypt procedure (CBC-MAC then CTR ) . So why is such mode always presented as candidate AE mode if only Encrypt-Then-Mac procedure seems actually recommended by cryptography experts ?
-
Are you asking why GCM and CCM are NIST approved, while EAX and OCB are not? csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf csrc.nist.gov/publications/nistpubs/800-38C/… –  Henrick Hellström Jun 15 at 14:30
If robustness is more important than performance, then I prefer HMAC+encryption in a encrypt-then-MAC scheme over GCM and the like. –  CodesInChaos Jun 15 at 16:07
response to Hendrick comment –  william_fr Jun 15 at 18:05
The mode that's least sensitive to IVs is SIV mode. $\;$ –  Ricky Demer Jun 16 at 1:48
Another issue - completely unrelated to security - is that CCM is simply hard to implement and use, because it does not use static data sizes. This is especially true regarding generation of the NONCE, especially regarding size. I've already met an implementation that was correct but slightly incompatible with mine. –  owlstead Jun 24 at 11:33

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 been revised a number of times due to attacks such as this one against one of the earliest versions of OCB mode.

Regarding the security of CCM mode, this paper provides a security proof that explains the use of a CTR-encrypted CBC-MAC, with the conjecture that it is stronger against birthday attacks, compared to an unencrypted CBC-MAC. Hence, as a consequence CBC-MAC-then-CTR-Encrypt is actually stronger than (naive) CTR-Encrypt-then-CBC-MAC. The security of EtA versus AtE is consequently a rather complex matter. Generally it is probably best to regard dedicated proofs for a specific mode, as trumping proofs for the generic compositions. The security properties of CCM are well understood, so I doubt many security experts rule against it just because it is not EtA. A better argument against CCM is that it requires two AES operations per block, while other AE modes only require one.

-
It's my understanding that the different versions of OCB were motivated by desires to improve performance, simplify the proof, support associated data --- basically everything but security concerns. The "attack" you mention basically says that if you encrypt several gigabytes of data under the same key, an attacker can create a forgery with probability 2^-64; i.e., there is roughly a one-in-a-quintillion chance that the attacker will succeed. I doubt this is much of a concern for practioners. –  Seth Jun 17 at 0:31
I think you are mistaken. If you need 128 bit of security in a IND-CCA2 model, you clearly can't use a mode that allows you to create forgeries with significantly better than $2^{-128}$ probability with realistic amounts of data. You do need IND-CCA2 security for online data transmission protocols, so with OCB mode you have to rekey long before you reach even MB of data transmitted using a key. –  Henrick Hellström Jun 17 at 7:16
The modification made in the OCB1 mode otoh results in a different security proof: cs.ucdavis.edu/~rogaway/papers/offsets.pdf –  Henrick Hellström Jun 17 at 7:31