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.