Some%20Comments%20on%20OCB%20and%20CCM

1
Some Comments onOCB and CCM

• Phil Rogaway
• UC Davis and Chiang Mai Univ.

rogaway_at_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
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 Im told that OCB is in jeopardy in 802.11.
• So Ive come to clarify cryptographic questions
  and address whatever else has given people pause.
  

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
  encryptauthenticate M (nblock length).
  About half of what alternatives use.
• Provably secure if you break OCB-E
  privacy/authenticity with advantage gt 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.

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.

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 lt 2-53 chance of
  forgery. So gathering data at 1 Gbit/sec for
  one million years will give chance of forgery lt 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 n128.

6
The Real Issue Patents

• From FHW01
• IEEE 802 has long history with patentsBottom
  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 OCBs 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)

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

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.

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

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.

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.

12
OCB vs. CCM
Published, peer-reviewed work from an experienced team of cryptographers. Proof under standard complexity assumption, getting standard bounds. Stable algorithm. Unpublished algorithm. Still evolving. Designed specifically for 802.11. Does not follow well-understood enc-then-mac generic composition paradigm. Unlikely to be used outside of 802.11.
éM / n ù 2 block cipher calls 2 éM / n ù 2 block cipher calls
Yes. Letters of assurance on file None known
Not significantly differentiated for 802.11 purposes differences are overly assumption-dependent and likely in the noise Not significantly differentiated for 802.11 purposes differences are overly assumption-dependent and likely in the noise

Assurance
SW speed
Patents
HW/SW size HW speed Power use Ciphertext expansion
. . .