edit: ignore below, I misinterpreted what q meant in this context and thought it was the private key.
>The clever trick is to compute a secure hash whose input includes the message to be signed and also the private key [...]
> PuTTY's technique worked by making a SHA-512 hash, and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY's technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later) it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.
I know hindsight is 20/20, but why did PuTTY implement it this way to begin with? Given the description in the first paragraph, I'd naively implemented it as
SHA-512(message || private_key)[:number_of_bits_required]
or if I was being paranoid I would have done
SHA-512(SHA-512(message) || SHA-512(private_key))[:number_of_bits_required]
Moduloing it by q makes no sense unless you're trying to save a few cycles.
>The clever trick is to compute a secure hash whose input includes the message to be signed and also the private key [...]
> PuTTY's technique worked by making a SHA-512 hash, and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY's technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later) it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.
I know hindsight is 20/20, but why did PuTTY implement it this way to begin with? Given the description in the first paragraph, I'd naively implemented it as
or if I was being paranoid I would have done Moduloing it by q makes no sense unless you're trying to save a few cycles.