W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2001

RE: Integrity check

From: Philip Hallam-Baker <pbaker@verisign.com>
Date: Mon, 8 Jan 2001 14:37:54 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154C77F@vhqpostal.verisign.com>
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>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:18 GMT