Re: [Cfrg] Hash substitution in PSS

I believe we are in agreement. Any policy put in place by the signer to require use of the strong hash when signing is useless unless the verifier also has a policy to not accept messages signed using the weak hash. Like CRLs and patches, it takes a worrisomly long time for such changes to propogate to every verifier. During the chage over period the signer is vulnerable  to having one of their benign messages "hijacked" and an evil version fed to an "unpatched" verifier.

Having the policy be part of the cert sounds like a prudent precaution, but doesn't that implicitly require the policy to be authenticated to stop Eve from meddling with it?  I suppose the bottom line is that if a commonly used hash fails disasterously then even people who have not been using that hash are vulnerable. 

This seems to say designing a protocol that allows for the use of several different hashes actually increase everyones vulnerability. That certainly is counter intuitive. Of course the discussion above assumes a truly disasterous flaw. If the flaw more mundane, supporting more than one hash helps in recovering from the discovery of this flaw.

----- Original Message -----
From: Dan Brown [mailto:dbrown@certicom.com]
Sent: Thursday, April 11, 2013 02:28 PM Eastern Standard Time
To: Igoe, Kevin M.; 'cfrg@irtf.org' <cfrg@irtf.org>
Subject: RE: Hash substitution in PSS

Doesn't the signer need to have a policy to avoid signing with a weak hash?

Otherwise, if Alice the signer does not have such a policy, then she could sign with a weak hash.  Then Eve the adversary, under your scenario (*), could take the hash value from any message that Alice signed, and find an evil message with the same hash, and fool Bob the verifier.  What am I missing?

It seems impossible to avoid having a good policy for the signer.  I agree that it would be fantastic to avoid such a policy on algorithms, via some algorithm. 

Surely, the verifier would be able to use the same policy as the signer.  Maybe this violates the principle of being "generous in what you receive", but how appropriate is that particular principle when verifying a signature?

Why not embed the signer's policy into the signer's certificate?  That would somewhat ease the burden on the verifier, and place responsibility for the policy upon the signer, where the burden probably belongs.

Best regards,

Dan

(*) Your scenario sounds like this to me: the hash is "weak" in the sense that evil pre-images of any hash can be found.  That is what I am assume above.  (Or, you can take second preimages ...)

A more elaborate scenario would be that the "weak" hash is still strong in the sense that it 1st and 2nd preimage resistant, but it is not 2nd preimage resistant given a 1st preimage under the strong hash.  In other words, it fails to be second cross-preimage resistant.  This scenario is theoretically possible, but seems unlikely for most conventional hash functions.  The policy-necessity argument I make above does not apply to this scenario. 

> -----Original Message-----
> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
> Igoe, Kevin M.
> Sent: Thursday, April 11, 2013 1:42 PM
> To: 'cfrg@irtf.org'
> Subject: [Cfrg] Hash substitution in PSS
> 
> On 4 August Jim Schaad pointed out that the choice of hash algorithm in
> PSS is not authenticated and asked if this was a security problem.
> 
> The good news is that if all of the hash algorithms in use are
> "secure", the only risk is the "birthday problem", and the aVailability
> of more than one hash does not a priori result in a cheaper attack.
> 
> The bad news is that if one of the hashes is broken, so broken that an
> adversary has a non-trivial chance of finding an "evil" message that
> has the same hash value as a benign message formed with a hash that is
> "secure", they can substitute the evil message under the weak hash for
> the benign message under the strong hash. Preventing this requires
> either that (1) the have a policy to reject all messages with the weak
> hash or (2) the choice of hash algorithm be authenticated. Personally I
> trust a cryptographic authentication over policy.
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.