Camellia project proposal

[Sam Hartman]

I personally wouldn't mind another CTS enctype, although I see Love's
point.

However, I would strongly object to an enctype that did not have
self-describing tokens--that is, an enctype where the plaintext length
cannot be inferred from the decrypted token.
rc4 and AES have the property that the plaintext length can be inferred;
DES and 3DES have the property that it cannot.

Ways of doing this include:
* CBC with some sort of self-describing padding[1]
* CTS
* CCM, GCM

[1] I suspect that Microsoft cannot implement a cipher with potentially
more than 8 bytes of padding per block or for which 8 byte aligned PDUs
would require padding.  Remember that encryptMessage does in-place
encryption.  There is a pad chunk type that can be included, and that is
included by most applications.  However if I'm remembering correctly,
applications need only allocate 8 bytes for the pad chunk. Also, DCE
handles its own padding rather than including a pad chunk.  I think that
means that DCE always makes its packets a multiple of 8.  

Our APIs could handle a padded token.  However, There would be
complexities.  First, I think the CFX IOV code padding logic has been
very minimally tested if at all.  Secondly, the DCE style would need to
be adjusted somewhat.

Making the corresponding changes would be significantly more difficult
for Microsoft.

for this reason, after reflecting for a bit, I'm strongly against a new
CBC mode cipher.