Camellia project proposal

[Sam Hartman]

>>>>> "Tom" == Tom Yu <tlyu at MIT.EDU> writes:

    Tom> Sam Hartman <hartmans at MIT.EDU> writes:
    >>>>>>> "Ken" == Ken Raeburn <raeburn at MIT.EDU> writes:
    >> 
    Ken> On Dec 8, 2009, at 14:35, Sam Hartman wrote:
> >> 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.
    >> 
    Ken> I think it'd be a nice property to have, but given the
    Ken> existence of DES and 3DES, we've already lost the ability to
    Ken> take advantage of it in any real way (we need the
    Ken> self-describing ASN.1 DER encoding), so I'm not sure what it
    Ken> buys us now.
    >> 
    >> CFX and some out-of-tree code I've seen treats DES as a special
    >> case and tries to make simplifying assumptions about other
    >> things.

    Tom> As in assuming that decryption recovers the exact length of the
    Tom> plaintext?

Well, CFX requires that EC be used to construct a token with no
"trailing crypto garbage."  Our code makes assumptions about how to
accomplish that; I think that design model is likely to be common in
other code.  So, I think introducing an enctype that produces trailing
crypto garbage makes things hard for everyone.


--Sam