Subject: Re: Suggested changes for DSA2, take 4

From: [email-masked] ("Hal Finney")
Date: Wed, 29 Mar 2006 10:45:30 -0800 (PST)

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.

Hal Finney

---

From: Ben Laurie <[email-masked]>
Date: Wed, 29 Mar 2006 22:22:55 +0100

> 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