0

This is DSA parameters length from NIST.FIPS.186-4 and NIST.FIPS.186-3:

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

And this is code for parameters initialization from OpenJDK

protected void engineInit(int strength, SecureRandom random) {
    if ((strength >= 512) && (strength <= 1024) && (strength % 64 == 0)) {
        this.valueN = 160;
    } else if (strength == 2048) {
        this.valueN = 224;
//  } else if (strength == 3072) {
//      this.valueN = 256;
    } else {
        throw new InvalidParameterException
            ("Prime size should be 512 - 1024, or 2048");
    }
    this.valueL = strength;
    this.seedLen = valueN;
    this.random = random;
}

My questions:

  1. AFAIK strength of DSA is equals to length of used hash function and hash function length is N. Maybe this init function should take strength argument like 160, 225 and 256, and not 512-1024, 2048?

  2. Am I right in saying that in this implementation of DSA situation with L = 2048, N = 256 is completly ignored?

EDIT

Well, it looks like code from OpenJDK uses parameters of old DSA standard FIPS.186-2. But javadoc for DSA.java clearly says that this implementation uses FIPS.186-3 as standard source. Is it possible that developers just forgot to update this part of code while upgrading java DSA implementation or something like that? Could this be a security vulnerability?

Feedforward
  • 4,521
  • 4
  • 22
  • 34
  • 1
    `strength` is the name of a variable, not necessarily consistent with some external document. The name of the parameter in the KeyGeneratorSpi class is `keysize`. Yes, there is no way to obtain L = 2048, N = 256 *using this implementation* – President James K. Polk Jan 14 '17 at 14:11
  • Actual _strength_ of DSA is the minimum of half the subgroup size N/2 (generic attack) _or_ the strength of the hash which is usually half the hash size which is normally matched to N but not always see 4.6 _or_ the resistance of Zp to discrete log which is not exact but the permitted L-N combinations are designed to roughly match these, but that belongs on crypto.SX. Remember lots of software was written, and keys and signatures created, in the years before 186-3 or even 186-2cn1, so JCE still allows them although e.g. JSSE for SSL/TLS can be configured to reject too-small DSA or RSA keys. – dave_thompson_085 Jan 14 '17 at 19:39

0 Answers0