RE: hash (digest) of the plaintext in the clear

Hi Amir,

Jim brought up some concerns at the last f2f meeting, where I believe he had
some reservations regarding the secrecy of the plaintext if the hash of the
plaintext remains in the clear (to facilitate signature verification). I'll
give some of my own thoughts, which hopefully align with Jim's.

Since practical hash functions are presumed to be "one-way", there shouldn't
be a concern that the plaintext could be recovered from its hash.  Maybe Jim
was worried that a "plaintext guess" could be validated against the hashed
value. For example, if based on additional information known to an attacker,
the value that is protected is of low entropy (e.g. maybe it's a dollar
value between $1 and $1,000,000), then an attacker can determine what this
value is, by checking against the hash (that is maintained in the clear).
This seems like a real concern. 

I understand the purpose of technically allowing signature verification of a
hash value. I'm a little unclear as to how useful this is though. In
particular, what benefit is there to validate the hash, without confirming
the value of the plaintext used to produce the hash?

Cheers,
Mike


> -----Original Message-----
> From: Amir Herzberg [mailto:AMIR@newgenpay.com]
> Sent: Wednesday, September 05, 2001 5:02 AM
> To: Xml Encrypt (E-mail)
> Subject: hash (digest) of the plaintext in the clear
> 
> 
> Joseph said, 
> 
> ...
> > Once Don sends text for reverting back to not using 
> > DigestMethod/DigestValue 
> > in the clear (I hope you saw Schaad's arguments [1]), 
> ...
> > [1] 
> http://www.w3.org/Encryption/2001/Minutes/0720-Redwood/minutes.html
> 
> No, I didn't notice the proposal below (I'll blame my 
> vacation...). Sorry!!
> 
> I thought the importance of keeping the hash (digest) of the 
> plaintext in
> the clear is understood: it allows authentication (signatures 
> or MAC) of
> messages including the encrypted data. In fact, signatures 
> (not MAC) should
> preferably be computed ONLY on the hashed plaintext and not on the
> ciphertext, to allow changing the encryption without invalidating the
> signature. I'll gladly explain it in more details if needed. 
> 
> When the plaintext contains sufficient randomness (e.g. via nonce),
> providing the cryptographic hash of it in the clear should 
> not be a security
> problem. 
> 
> Has there been a detailed counter proposal or argument? 
> 
> Best, Amir Herzberg
> 
> > Proposal: DigestMethod/DigestValue Removal, Jim Schaad
> > 
> > Schaad: believes Herzberg wanted integrity, and something 
> > about the plaintext 
> > as it was before encryption. For the same reasons that Finney 
> > raised earlier 
> > about signature over plaintext, Schaad doesn't like plaintext 
> > being in the 
> > clear, should be encrypted as part of the CipherData; 
> > otherwise it allows for 
> > guessing of the original text if insufficient randomness exists.
> > 
> > Group: discussion of earlier approach of having integrity be 
> > part of the 
> > algorithm URI, people felt this led to too many algorithms 
> > identifiers. 
> > Present approach not liked for reasons stated.
> > 
> > Reagle: a poll was taken for Jim?s proposal: 5 supported 
> > Jim?s proposal and 2 
> > supported the current status. Eastlake suggested the proposal 
> > to be further 
> > discussion in the list.
> > 
> > Schaad: Proposed this as an optional element: If one wants 
> > integrity checks, 
> > then provide a new URI. Action Schaad: send proposal for 
> > integrity to list 
> > within the week with the necessary changes. Otherwise, need a 
> > use case 
> > (Herzberg engage Schaad in discussion) of the initial problem 
> > was, so we can 
> > understand the application where it applies (understanding 
> > now that it was 
> > wanted to have the digest value outside)
> > 
>