- From: Philip Hallam-Baker <pbaker@verisign.com>
- Date: Mon, 8 Jan 2001 14:37:54 -0800
- To: "'Sanjeev Hirve'" <shirve@cyberelan.com>, xml-enc <xml-encryption@w3.org>
- Cc: Raju Nadakaduty <praju@cyberelan.com>, Marcus A Cuda <mcuda@cyberelan.com>, Michael Sakhatsky <msakhatsky@cyberelan.com>
- Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154C77F@vhqpostal.verisign.com>
XML Signature already allows Message Authentication codes to be used. There have been a number of recent proposals for 'encrypt and hash' functions. In particular the (patented) IBM scheme and the (presumably unpatented because it was proposed in the open AES forum) Rogaway scheme. Essentially the advantage of hash and encrypt is that by careful choice of the cipher block chaining mode you get encryption and authentication for free. Unfortunately there are a bunch of nasty pitfalls here to be aware of: 1) The cipher block chaining function may mean that the last block is a function of the last two blocks of plaintext and the key alone. This is the Kerberos mistake, the wrong chaining function was used, DES (CBC ???) which by design minimises the impact of a single mistransmitted block. 2) Use of stream ciphers and checksums. This is a major flaw in the IEEE 802.11B security scheme amongst others. The encryption cipher is RC4 which is simply a means of generating a 'had-better-be-used-only-once-time-if-this-is-to-be-secure' pad from a 128 bit key. The outpus of the stream cipher is then XOR'd with the plaintext to produce the ciphertext. If the RC4 output is actually used but once this is secure for confidentiality but not for integrity since a party knows that flipping a bit in the ciphertext will cause the same bit to be flipped in the plaintext. This has two side effects, first the authenticity check is only secure if the plaintext is secret. If the attacker knows (or correctly guesses) the plaintext being transmitted it is possible to perform an integrity attack since the attacker can recover the RC4 output stream ( = ciphertext XOR plaintext ) and then substitute any message of choice ( = ciphertext XOR plaintext XOR substitued plaintext ). Adding an SHA-1 checksum does nothing against this attack since the attacker knows the checksum of the substituted text. The IEEE 802.11B scheme makes it even easier by using a linear checksum. This means that it is not even necessary to have the entire message. Given the history I think that authentication and encryption in one operation needs to be considered as a separate algorithm rather than supporting mix 'n match schemes. Most authentication with encryption schemes will fail with RC4 and similarly constructed ciphers. Phill -----Original Message----- From: Sanjeev Hirve [mailto:shirve@cyberelan.com] Sent: Monday, January 08, 2001 3:41 PM To: xml-enc Cc: Raju Nadakaduty; Marcus A Cuda; Michael Sakhatsky Subject: Integrity check I would like to propose introducing an optional integrity check in the XML encryption standard. Specifically, an optional attribute or child element in DataReference and KeyReference. The check can be the SHA-1 digest of the cleartext. The checksum may be used in the following situation: - the decrypting party does not have access to only part of the document - it is considered too expensive to appy PK signatures on individual parts of the doc - the party that can decrypt the encryption-key, does not have access to the encrypted data. The party that has access to the encrypted data cannot decrypt the encryption-key. This can provide a cheap and secure alternative to PK signatures, to protect against intentional tampering of the ciphertext. regards SSH
Received on Monday, 8 January 2001 17:38:01 UTC