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

RE: Integrity check

From: Philip Hallam-Baker <pbaker@verisign.com>
Date: Wed, 17 Jan 2001 23:19:20 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154C7A1@vhqpostal.verisign.com>
To: "'Sanjeev Hirve'" <shirve@cyberelan.com>, Philip Hallam-Baker <pbaker@verisign.com>, xml-enc <xml-encryption@w3.org>
Cc: Raju Nadakaduty <praju@cyberelan.com>, Marcus A Cuda <mcuda@cyberelan.com>, Michael Sakhatsky <msakhatsky@cyberelan.com>
No misunderstanding. Authentication is a different matter entirely.
 
Encryption + checksum does not provide an Integrity check
 
There are secure Integrity & Encryption modes presented at AES. In general
however they are very bad news for the reasons I gave. In particular mix 'n
match is not a good plan at all.
 
        Phill

-----Original Message-----
From: Sanjeev Hirve [mailto:shirve@cyberelan.com]
Sent: Wednesday, January 17, 2001 1:12 PM
To: Philip Hallam-Baker; xml-enc
Cc: Raju Nadakaduty; Marcus A Cuda; Michael Sakhatsky
Subject: Re: Integrity check



>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,
     I am not a crypto expert so, maybe there is a misunderstanding. 
 
What I am proposing is not an authentication scheme.  It is simply an
message digest of the cleartext to detect tampering of the encrypted text.
And it is useful in the very specific scenario as follows:
- 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.
The above scenario exists in a system where a separate central authorization
server controls access to encrypted distributed data 
 
Your suggestion for MAC will also work but has the following (minor)
diadavantages:
- the encryption key must be reused for the MAC or a separate secret key
must be used
- the Signature element is relatively verbose.
 
Received on Thursday, 18 January 2001 02:19:25 GMT

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