Camellia project proposal

[Greg Hudson]

I believe the options on the table are:

  1. CTS mode
  2. Padded CBC mode, with or without an indication of the pad length
  3. CCM mode
  4. GCM mode

Anything other than (1) would likely be done using MIT resources, as I
understand the situation.  Sam has pointed out some issues associated
with padded CBC mode.

If we do CTS or CBC mode, we have to decide whether to continue using
SHA-1 or introduce a different hash (I would guess SHA-256), and also
whether to continue truncating the hash value to 96 bits.  If we do CCM
or GCM, we don't need a hash function.

Luke has previously done an implementation of AES-CCM which could
probably be adapted to the current crypto library and Camellia without
too much effort.  That option would require more careful theoretical
review than a CBC or CTS mode enctype, because of our lack of
familiarity with AEAD modes.  (For instance, I didn't see any key
derivation going on in the aescbc keyhash provider in Luke's code, and
Sam didn't think that was safe.)

GCM has some advantages over CCM but would probably require more coding
time as well as the same careful review CCM would require.

>From a process perspective: obviously, this would not be an
IETF-standardized enctype if we implement it in 1.8.  I believe the plan
is to publish an informational RFC matching our implementation, similar
to what Microsoft did for RC4, and possibly declare the enctype as
experimental.  I am personally concerned about supplying an enctype in
1.8 which we know would be quickly superceded (for instance, because of
SHA1), because it can be hard to desupport features even when we've
advertised them as experimental.