Re: SSH non-compliance with FIPS 186

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

nisse%lysator.liu.se@localhost (Niels =?iso-8859-1?Q?M=F6ller?=) writes:

>people seem to be using large out-of spec DSA keys with ssh-dss.

Ahh, good point.  The precise reason why GPG doesn't support DSA2 by default
is out of concern over users who want to make a fashion statement with
stupidly large keys that nothing on the receiving end will be able to verify,
but in the case of SSH since it's negotiated interactively this won't be such
a problem since the other side can simply choose to decline that option.

>As a practical matter, if we want to have larger dsa, I'd suggest adopting
>"dsa-sha256", specified to a use 256-bit q, SHA-256, and with more or less
>arbitrary size of p (but recommended in the range 2048 to 3072).

Yup, I'd agree with choosing that as the universal-to-support standard, the
larger hashes get a bit messy on 32-bit architectures, the combination of
SHA-256 with 2K-3K keys is a nice balance.

>I'm surprised and disappointed if NIST really haven't published any official
>test vectors. I thought everybody agreed that that's an essential part of any
>specification for a cryptographic algorithm.

They tend to lag the drafts by a long, long time, so you have to scrape them
together wherever you can find them.  Usually you end up with pulling
something out of whatever the latest version of the CAVS software is on the
assumption that it must be OK.  Testing against a consensual hallucination
seems to be a somewhat unsound practice though.

>I think putty uses a clever trick to avoid that dependency, by generating the
>"random" number involved in DSA signing using hashing of the secret key and
>the message being signed.

AFAIK this was first done by the commercial PGP some years ago.  It works a
bit better for that because what's being hashed is also encrypted, so an
attacker won't have access to the preimage.

Peter.