No Subject

[David Koontz]

>From: "David LANDGREN, PUB         " <David.D.L.LANDGREN at pub.oecd.fr>
>To: cypherpunks at toad.com
>Subject: ... long live DES (sic)
>Importance: Normal
>Status: R
>
>>>>This chip takes a single plaintext/ciphertext pair and quickly tries
>>>>DES keys until it finds one that produces the given ciphertext from the
>>>>given plaintext.
>
>It's all very well to be able to crack DES in 3.5 hours, but I don't know
>of too many people who obligingly send out the plaintext and cyphertext of
>a message together, or in some other way combinable.  If U can get the
>plaintext of a DES-encrypted msg then U don't need to dick around with DES
>anyway.  No-one ever said it was bulletproof; a direct consequence is that
DES users change their keys awful frequently.

The way to get plaintext is through what is known as revealed-plaintext,
where you can with a high degree of accuracy 'guess' part of the plaintext
of a message, such as "From: Col. Dimwitt" in a message format, or the
title of a paper or document, which is usally unclassified and knowable
from another source.

Fearing such, our illustrious 3 letter governmental organization implemented
with the advent of electronic crypto gear (set your way back machine, sherman)
something called traffic flow security, where on a radio net or dedicated
line a cryptographic stream continously runs.  The idea is to make it
hard to distinguish boundaries of messages, and thus revealed-plaintext.

This also allows the use of the caveat - EFTO (Encrypted For Transmission Only)
seen on unclassified messages, hey the line was otherwise idle, waiting for
classified traffic, right?

Modern communications are swinging toward the use of packets, which beside
allowing traffic analysis unless the transmission medium is denied (Such
as using link encryption as a super encryption, or dedicated lines, etc.).

The way to offset to offset the vulnerability to revealed-plaintext attacks
is to use filling where some random data followed by a sync or start of
message symbol preceeds the the actual message.  All message traffic should
be encrypted in general, making it hard to separate the wheat from the
chaff.  Ideally the only unencrypted data should be that required for
operating the communications protocol, including denial of packet ordering
if possible.

There's a paper found on the NIST anonymous ftp site entitled 'Security in
ISDN' by William E. Burr that can be informative.  Its available in PostScript
and is around 70 pages long.