From daw@blowfish.isaac.cs.berkeley.edu Tue Dec 14 15:28:49 PST 1999 Article: 123496 of sci.crypt Path: agate.berkeley.edu!agate!not-for-mail From: daw@blowfish.isaac.cs.berkeley.edu (David Wagner) Newsgroups: sci.crypt Subject: Re: An attack on the WTLS SHA_XOR_40 MAC algorithm Date: 13 Dec 1999 19:16:17 -0800 Organization: A poorly-installed InterNetNews site Lines: 42 Message-ID: <834cq1$up3$1@blowfish.isaac.cs.berkeley.edu> References: <38544B18.36FF924E@zetnet.co.uk> NNTP-Posting-Host: joseph.cs.berkeley.edu X-Trace: agate.berkeley.edu 945141508 1569 128.32.37.122 (14 Dec 1999 03:18:28 GMT) X-Complaints-To: abuse@berkeley.edu NNTP-Posting-Date: 14 Dec 1999 03:18:28 GMT Bcc: daw@cs.berkeley.edu Xref: joseph.cs.berkeley.edu sci.crypt:123496 Good catch. Yeah, I agree: the so-called WTLS `XOR MAC' is seriously flawed, and definitely should be eliminated with all possible haste. Submitting your result to WAP might be useful, to keep them honest. Last I heard, they were a semi-secret design committee, and one always has to wonder about the effects of secrecy & politics on the resulting standards. You might also be interested in the following paper: Markku-Juhani Saarinen, ``Attacks against the WAP WTLS protocol.'' 1999 Communications and Multimedia Security conference. This paper shows some different attacks on the `XOR MAC', and also describes several other security misfeatures of WTLS. Finally, here is a third observation on the `XOR MAC', not mentioned in the above paper or in your post. Take any ciphertext block and replace it with 10n+1 repetitions of itself, for any n>0; then the MAC will remain unchanged. This presents yet another easy forgery attack. For example, modifying ciphertext X Y Z into X (11 Y's) Z will not be detected by the MAC, if X,Y,Z each represent a single (8-byte) ciphertext block. This has a very easily predicted effect on the resulting plaintext: it inserts 10n copies of the plaintext block Decrypt(Y) xor Y. If you repeat a ciphertext block that corresponds to some known plaintext block (perhaps because it is part of a predictable TLS header or guessable HTTP request or somesuch), you can even control the inserted plaintext block to some extent. You can also apply similar tricks to any sequence of consecutive ciphertext blocks, if you like. You can use this trick to do cut-and-splice attacks, a la Bellovin's IPSEC work. For instance, suppose we have the ciphertext U V W that we want to get decrypted for us. We wait until we get ahold of the channel, perhaps using an echo feature in some application like suggested in M.-J. Saarinen's paper. Then, when we see ciphertext X Y Z, we modify it to become X (10 copies of U V W X) Y Z. This attack will not be detected by the XOR MAC, and it lets us read any traffic we like. At this point I would claim it should be clear that the `XOR MAC' is fatally and fundamentally flawed.