Camellia project proposal
hartmans at MIT.EDU
Fri Dec 11 09:46:42 EST 2009
>>>>> "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
Tom> As in assuming that decryption recovers the exact length of the
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.
More information about the krbdev