RE: Integrity check

I think that supporting use of an algorithm that provides BOTH integrity and
encryption in one go is a good idea.
 
I think that trying to devise a scheme out of hash functions and the like is
a very bad idea.
 
We already support the first, we just define a URI for AES in
Confidentiality and Integrity Mode, or AES with SHA-1 checksum. This stops
someone from combining a linear cipher and a linear checksum which while
both can be components of a secure scheme are chronically insecure together.
 
        Phill

-----Original Message-----
From: Jim Schaad [mailto:jimsch5@home.com]
Sent: Thursday, January 18, 2001 3:24 AM
To: 'Philip Hallam-Baker'; 'Sanjeev Hirve'; 'xml-enc'
Subject: RE: Integrity check


An additional reason that this should be part of the algorithm is that the
checksum should not appear in the clear.  Knowing the checksum and knowing
the possible texts means you can make good guesses as to which text was
encrypted.  This means that the check sum needs to be part of the encrypted
code and needs to be seperated out.  Or it needs to be encrypted seperately.
 
jim

-----Original Message-----
From: xml-encryption-request@w3.org [mailto:xml-encryption-request@w3.org]On
Behalf Of Philip Hallam-Baker
Sent: Wednesday, January 17, 2001 11:19 PM
To: 'Sanjeev Hirve'; Philip Hallam-Baker; xml-enc
Cc: Raju Nadakaduty; Marcus A Cuda; Michael Sakhatsky
Subject: RE: Integrity check


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.