From: "David LANDGREN, PUB " <David.D.L.LANDGREN@pub.oecd.fr> To: cypherpunks@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.