[cryptography] Key Checksums (BATON, et al)

ianG iang at iang.org
Thu Mar 28 16:21:35 EDT 2013

On 27/03/13 22:13 PM, Ben Laurie wrote:
> On 27 March 2013 17:20, Steven Bellovin <smb at cs.columbia.edu> wrote:
>> On Mar 27, 2013, at 3:50 AM, Jeffrey Walton <noloader at gmail.com> wrote:
>>> What is the reason for checksumming symmetric keys in ciphers like BATON?
>>> Are symmetric keys distributed with the checksum acting as a
>>> authentication tag? Are symmetric keys pre-tested for resilience
>>> against, for example, chosen ciphertext and related key attacks?
>> The parity bits in DES were explicitly intended to guard against
>> ordinary transmission and memory errors.

Correct me if I'm wrong, but the parity bits in DES guard the key, which 
doesn't need correcting?  And the block which does need correcting has 
no space for parity bits?

>> Note, though, that this
>> was in 1976, when such precautions were common.  DES was intended
>> to be implemented in dedicated hardware, so a communications path
>> was needed, and hence error-checking was a really good idea.
> And in those days they hadn't quite wrapped their heads around the
> concept of layering?

Layering was the "big idea" of the ISO 7 layer model.  From memory this 
first started appearing in standards committees around 1984 or so?  So 
likely it was developed as a concept in the decade before then -- late 
1970s to early 1980s.

> That said, I used to work for a guy with a long history in comms. His
> take was that the designers of each layer didn't trust the designers
> of the layer below, so they added in their own error correction.
> Having seen how crypto has failed lately, perhaps we should have more
> of the same distrust!

It's still the same.  This is why websites have a notice on them "don't 
push the PAY NOW button twice!"  Strict layering makes the separation 
between skill specialties easier to conceptualise but it does not 
necessarily make architectural sense.  It works well enough if security 
isn't an issue.


More information about the cryptography mailing list