Re: Suggested changes for DSA2, take 4

[Ben Laurie <[e-mail]>]

Hal Finney wrote:
> Ben Laurie writes:
>> Slightly late to the party here, but I should note that hash truncation
>> is not an operation that is thoroughly approved of. In particular I
>> would worry that if it is permitted a cunning attacker might be able to
>> choose a new q s.t. the signature still validated on a much shorter
>> version of the hash, and thus show a valid signature on the wrong
>> document. I would therefore suggest that we do _not_ permit arbitrary
>> truncation of hashes.
> 
> I don't understand what you are proposing here.  To choose a new q means
> to create a new key: a new (p, q, g, x, y) tuple.  Then you are worried
> that an existing (r, s) signature could be made to work with this new key?
> I don't see why this would be a concern even if it worked; and it could be
> eliminated by checking that r and s are < q, which you should do anyway.
> 
> The NIST standard supports arbitrary truncation of (strong) hashes, and
> if it were that risky I doubt very much that it would have gotten in.
> John Kelsey at NIST is one of the top people in the field today and I
> am sure this has been reviewed by him and other cryptographers.

OK, you are right, I guess I'll count this nebulous concern as void.

Certainly the language proposed accords with 186-3 on hash truncation.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff