pgut001 at cs.auckland.ac.nz (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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.