On Mar 28, 2013, at 4:21 PM, ianG <i...@iang.org> wrote:
> On 27/03/13 22:13 PM, Ben Laurie wrote:
>> On 27 March 2013 17:20, Steven Bellovin <s...@cs.columbia.edu> wrote:
>>> On Mar 27, 2013, at 3:50 AM, Jeffrey Walton <noloa...@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?
>
If a block is garbled in transmission, you either accept it (look at all the
verbiage on error propagation properties of different block cipher modes)
or retransmit at a higher layer. If a key is garbled, you lose everything.
Error detection in communications is a very old idea; I can show you telegraph
examples from the 1910s involving technical mechanisms, and the realization
that this was a potential problem goes back further than that, at least as
early as the 1870s, when telegraph companies offered a "transmit back" facility
to let the sender ensure that the message received at the far end was the one
intended to be sent.
The mental model for DES was computer->crypto box->{phone,leased} line,
or sometimes {phone,leased} line->crypto box->{phone, leased} line. Much
of it was aimed at asynchronous (generally) teletype links (hence CFB-8),
bisync (https://en.wikipedia.org/wiki/Bisync) using CBC, or (just introduced
around the time DES was) IBM's SNA, which relied on HDLC and was well-suited
to CFB-1. OFB was intended for fax machines. Async and fax links didn't
need protection as long as error propagation of received data was very limited;
bisync and HDLC include error detection and retransmission by what we'd now
think of as the end-to-end link layer. (On the IBM gear I worked with in the
late 1960s/early 1970s, the "controller" took care of generating the bisync
check bytes. I no longer remember whether it did the retransmissions or
not; it's been a *long* time, and I was worrying more about the higher layers.)
In the second mental model for bisync and SNA, the sending host would have
generated a complete frame, including error detection bytes. These bytes
would be checked after decryption; if the ciphertext was garbled, the error
check would fail and the messages would be NAKed (bisync, at least, used
ACK and NAK) and hence resent. If they keying was garbled, though, nothing
would flow.
It is not entirely clear to me what keying model IBM, NIST, or the NSA had
in mind back then -- remember that the original Needham-Schroeder paper didn't
come out until late 1978, several years after DES. One commonly-described model
of operation involved loading master keys into devices; one end would pick
a session key, encrypt it (possibly with 2DES or 3DES) with the master key,
and send that along. From what I've read, I think that the NSA did have KDCs
before that, but I don't have my references handy. Multipoint networks
were not common then (though they did exist in some sense); you couldn't
go out to a KDC in real-time. (I'll skip describing the IBM multipoint
protocol for the 2740 terminal; I never used them in that mode. Let it
suffice to say that given the hardware of the time, if you had a roomful
of 2740s using multipoint, you'd have a single encryptor and single key
for the lot.)
Anyway -- for most of the intended uses, error correction of the data was
either done at a different layer or wasn't important. Keying was a
different matter. While you could posit that it, too, should have been
wrapped in a higher layer, it is quite plausible that NSA wanted to guard
against system designers who would omit that step. Or maybe it just
wasn't seen as the right way to go; as noted, layering wasn't a strong
architectural principle then (though it certainly did exist in lesser
forms).
--Steve Bellovin, https://www.cs.columbia.edu/~smb
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
