In message <[EMAIL PROTECTED]>, "Perry E. Metzger" writes: >
>Unfortunately, those parts are rather dangerous to omit. > >0) If you omit the message authenticator, you will now be subject to a > range of fine and well documented cut and paste attacks. With some > ciphers, especially stream ciphers, you'll be subject to far worse > attacks still. >1) If you omit the IV, suddenly you're going to be subject to a > second new range of attacks based on the fact that fixed blocks > will always encrypt the exact same way. > >We went through all that, by the way, when designing IPSec. At first, >we didn't put in mandatory authenticators, because we didn't >understand that they were security critical. Then, of course, we >discovered that they were damn critical, and that most of the text >books on this had been wrong. We didn't understand lots of subtleties >about our IVs, either. One big hint: do NOT use IVs on sequential >packets with close hamming distance! Better yet, don't use predictable IVs; the threat is much clearer. Perry is right -- a number of us learned the hard way about cryptographic protocol complexity. I led the fight to remove sequence numbers from the early version of ESP, since no one could elucidate a threat model beyond "the enemy could duplicate packets". My response was "so what -- packet duplication is always possible per the IP datagram model". (A while back, my ISP fulfilled that part of the model; I was seeing up to 90% duplicate packets. But I digress.) But then I wrote a paper where I showed lots of ways to attack IPsec if you didn't have both sequence numbers and integrity protection, so I led the fight to reintroduce sequence numbers, and to make integrity protection part of ESP rather than leaving it to AH. We all learn, even in embarrassing ways. My first published cryptographic protocol, EKE, has had an interesting history. One version of it is still believed secure: encrypt both halves of a DH exchange with a shared secret. (Ironically enough, that was the very first variant we came up with -- I still have the notebook where I recorded it.) We came up with lots of variations and optimizations that all looked just fine. We were wrong... Someone has already alluded to the Needham-Schroeder protocol. It's instructive to review the history of it. The original protocol was published in 1978; it was the first cryptographic protocol in the open literature. Presciently enough, it warned that cryptographic protocol design seemed to be a very suble art. Three years later, Denning and Sacco showed an attack on the protocol under certain assumptions; they suggested changes. In 1994, Abadi and Needham published a paper showing a flaw in the Denning-Sacco variant. In 1996, Lowe published a new attack on the *original* Needham-Schroeder paper. Translated into modern terms -- the first paper was published before certificates were invented -- the faulty protocol was only three lines long! Three lines of protocol, in the oldest paper in the literature, and it took 18 years to find the flaw... No, we're not a guild. To me, "guild" has connotations of exclusivity and closed membership. Anyone can develop their own protocols, and we're quite happy -- *if* they understand what they're doing. That means reading the literature, understand the threats, and deciding which you need to counter and which you can ignore. In IPsec, Steve Kent -- who has far more experience with cryptographic protocols than most of us, since he has access to, shall we say, more than just the open literature -- was a strong proponent of making integrity checks option in ESP. Why, when I just finished saying that they're important? Integrity checks can be expensive, and in some situations the attacks just don't apply. The trick is to understand the tradeoffs, and *to document them*. Leave out what you want, but tell people what you've left out, why you've left it out, and under what circumstances will that change get them into trouble. --Steve Bellovin, http://www.research.att.com/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]