IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: SSH non-compliance with FIPS 186



pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann) writes:

> It's 3072 bits, with a corresponding subgroup size of 256 bits (I guess they
> were nervous about SHA-512 and so stopped there :-).

Now I've looked (fairly quickly) through FIPS-186-3
(http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf). It
specifies four variants for different key sizes. L is the bitsize of
p, and N is the bitsize of q and also the digest size (in bits) of the
underlying hash function.

L = 1024, N = 160
L = 2048, N = 224
L = 2048, N = 256
L = 3072, N = 256

As far as I understand, intermediate keysizes are not allowed at all
(in contrast to the original dsa, which allowed keysizes 512, 576,
640,..., 1024 with 64 bit increments.

The hash function to use is *not* specified explicitly, it is only
stated that it should be an "approved" hash function.

For N = 160, one ought to use sha1 (as this ought to be intended to
be backwards compatible).

For N = 224, one might use either SHA-224 or truncated SHA-256 (the
way SHA-224 is constructed, the only difference between these two
alternatives is the initial state), and for N = 256, one ought to use
SHA-256.

Before implementing larger DSA, I'd like to see a specification that
also specifies explicitly the hash function to use, and which provides
some test vectors. Where should I look?

Implementation-wise, I think I'd prefer to first parametrize dsa with
respect to the hash function, e.g., define "dsa-sha256" to use SHA-256,
which implies a value for N above, and then be somewhat more liberal
when it comes to allowed key size L.

Regards,
/Niels



Home | Main Index | Thread Index | Old Index