Some Comments on OCB and CCM

1. Some Comments onOCB and CCM Phil Rogaway UC Davis and Chiang Mai Univ. rogaway@cs.ucdavis.edu http://www.cs.ucdavis.edu/~rogaway * This talk corresponds to contribution: “Some Comments on WHF Mode”, doc.: IEEE 802.11-02/156r0 Rogaway

2. Why is Phil here? • I came in July 2001 to describe OCB. • At that time, OCB was quite new. • The paper had not even appeared! • Since then, OCB (and auth enc in general) has continued to do well. • The papers have appeared. Nice follow-on work. Lot of implementations. Lots of interest. • But I’m told that OCB is in jeopardy in 802.11. • So I’ve come to clarify cryptographic questions and address whatever else has given people pause. Rogaway

3. What is OCB ? • Auth enc mode by Bellare, Black, Krovetz, Rogaway. Appears in ACM CCS 01 + a proposal to NIST. • Follow-on work to early version of [Jutla01]. • Uses any block cipher (eg, AES). • Uses é|M| / nù + 2 block cipher calls to encrypt+authenticate M (n=block length). About half of what alternatives use. • Provably secure: if you break OCB-E privacy/authenticity with advantage > 1.5 m2/2n then you break E with the “excess” advantage (m = # ciphertext blocks you get hold of). • Adopted for the draft 802.11i standard. Rogaway

4. Why the move away from OCB? • Some specious technical issues. • [FHW01] non-issues:size of SW implementation, size of HW implementation, power consumption, HW speed, crypto confidence, … Only valid issue: plaintext integrity coverage; addressed. • [Fe02] non-issue:m2/ 2n security bound. • Main issue for [FHW01, Fe02] appears to be patent avoidance. Rogaway

5. What is this Ferguson attack? • [Fe02] points out: if you have m blocks of ciphertext (and its plaintext) you can forge with probability » m2 / 2n • Right. This is obvious, well-known to the OCB authors, and the same as other popular modes. A non-issue for 802.11. • In general, when security upper bounds are available (as with OCB), you should always use them, and not attacks, to assess security. • Numerical example: 241.2 bytes of encrypted data (max possible) gives < 2-53 chance of forgery. So gathering data at 1 Gbit/sec for one million years will give chance of forgery < 1 in 4 million. • Has nothing to do with tag length. • m2 / 2n security degradation perhaps more significant for privacy than authenticity, but still of no practical importance when n=128. Rogaway

6. The “Real” Issue: Patents • From [FHW01] • “IEEE 802 has long history with patents—Bottom line: Avoid patents when there are viable unencumbered alternatives” • “Fair, non-discriminatory, and non-onerous are subjective (especially after standard is done)” • From [Fe02] • “OCB mode has been patented. This last reason has been the main reason for the author … not to spend any time on OCB. Spending time on OCB will only help the patent-holders sell their licenses without any further compensation to the cryptanalyst… Given that OCB’s computational advantage over the patent-free modes is at most a factor of 2, … [we] expect OCB only to be used in niche applications” • From the Chief Scientist at RSA • Lovely algorithm, but RSA just cannot support this because of the patents… (my paraphrase) Rogaway

7. Why the Patent Bashing? • Take your pick. • Dislike of crypto patents; uncomfortable with non-corporate patent holder; possibility of more than one party to deal with; fear of my/Virgil/IBM avarice; fear of my/Virgil licensing inexperience; … • Phil doesn’t exactly understand. • Phil, IBM, and VDG have all sent in their letters of assurance. • Already licensed under very simple & inexpensive terms. • All owners of auth enc IP are focused on auth enc succeeding beyond 802.11; none of us have any interest for this to be costly or difficult. Rogaway

8. CCM Mode • An OCB alternative by [WHF02]. • New, unpublished, still evolving. • Invented specifically for 802.11. • Twice the # of block cipher calls. • Positioned as generic composition, but it is not. • A new writeup, [Jo02], abstracts out the mode (does excellent job of this) and drafts a proof. • Generic composition (with encrypt-then-mac taken over proven primitives) would be safer. Rogaway

9. More on Generic Compostion • Studied by [BN00]. • encrypt-then-mac: always achieves the desired security property (“auth of ciphertexts” [BR00,KY00]) under the customary assumptions. • mac-then-encrypt, encrypt-and-mac: doesn’t. • No known results establish that one gets a better bound (in special cases) with mac-then-encrypt. • Landscape unchanged by [Kr01]. • Known results become inapplicable if one uses a common key. Rogaway

10. More on the MAC within CCM • CCM uses a kind of length-prepend CBC MAC. • [BKR94] suggested an approach for analyzing the length-prepend CBC MAC. • [PR97] claimed a more general result, for prefix-free message spaces, but gave no proof (they referred to [BKR94] instead). • Single key of CCM means that one cannot appeal to the [PR00] claim even if one regards it as proven. Rogaway

11. Is CCM more secure than OCB(wrt authenticity) ? • Currently there is no publshed or independently verified proof of CCM. • [Fe02, Jo02] suggest that CCM might have better Advauth than m2/2n. Who knows! One should focus on security bounds, not attacks. • Statements like: • “[CCM] can be used for any amount of data up to 264 blocks” [Fe02] • “[CCM] is secure against attackers limited to 2128 steps of operation if the key K is 256 bits” [WHF02] have no basis in results. • Overall, an interesting academic question, but of limited practical significance. Rogaway

12. OCB vs. CCM Assurance SW speed Patents HW/SW size HW speed Power use Ciphertext expansion . . . Rogaway