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