fix DSA dependency to SHA2

[sjaeckel]

DSA had a hard dependency to the basic sha2 operations.
In case one wanted to compile e.g. only with sha256 this lead to a
compilation error.

While working on this I thought whether it wouldn't make sense to use sha3 there or at least give the possibility.

[sjaeckel]

@karel-m Would something speak against implementing this as follows?

  hash = -1;
#if defined(LTC_SHA3)
  hash = register_hash(&sha3_512_desc);
#elif defined(LTC_SHA512)
  hash = register_hash(&sha512_desc);
#elif defined(LTC_SHA384)
  hash = register_hash(&sha384_desc);
#elif defined(LTC_SHA256)
  hash = register_hash(&sha256_desc);
#endif
  if (hash == -1) {
    return CRYPT_INVALID_ARG; /* no appropriate hash function found */
  }
  if (N > hash_descriptor[hash].hashsize * 8) {
    return CRYPT_INVALID_ARG; /* group_size too big */
  }

[karel-m]

I am looking at:

  if (group_size >= LTC_MDSA_MAX_GROUP || group_size < 1 || group_size >= modulus_size) {
    return CRYPT_INVALID_ARG;
  }

plus:

#define LTC_MDSA_MAX_GROUP 512

Which makes me think that sha512 case cannot happen. Maybe we should change: group_size > LTC_MDSA_MAX_GROUP

[karel-m]

Looks good. Before merge just check my last commit.

[sjaeckel]

I'm a bit uncertain whether this is even according to the standard what we do here ...

The implementation is according to FIPS 186-4 A.1.1.2, which states in the first step "Check that the (L, N) pair is in the list of acceptable (L, N pairs) (see Section 4.2)."

Section 4.2 says valid pairs are only

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

LTC_MDSA_MAX_GROUP is 512 but according to the standard this should be (256/8)=32 as we do N = (unsigned long)group_size * 8;.
Then we should maybe also add a check for L...

or is this all intentionally left open?

... writing all this while also keeping in mind that FIPS 186-5 (which is still in draft) forbids signing with the DSA algorithm and only allows verification of DSA signatures!

[karel-m]

Yes, 4096bit DSA is "out of FIPS". On the other hand OpenSSL is able to generate 4096 dsaparam and according my observation they use: L = 4096, N = 256 (although I have not find any paper recommending these values).

OpenSSL supports even 8192 dsaparam generation (with L = 8192, N = 256).

Our doc recommends: group_size = 40 and modulus_size = 512 (these are in bytes)

(EDITED) Ad L (a.k.a. modulus_size) checking - i removed my previous comment as it was wrong.

[karel-m]

I am not sure whether LTC_MDSA_MAX_GROUP = 512 should not be rather 64 (which corresponds to SHA512)

[karel-m]

And maybe we should introduce LTC_MDSA_MAX_MODULUS = 512 (or 640).

[sjaeckel]

OpenSSL supports even 8192 dsaparam generation (with L = 8192, N = 256).

alright, so it's intentional and we should also keep it open.

I am not sure whether LTC_MDSA_MAX_GROUP = 512 should not be rather 64 (which corresponds to SHA512)

OK

And maybe we should introduce LTC_MDSA_MAX_MODULUS = 512 (or 640).

OK

[karel-m]

Check my last commit

[sjaeckel]

Is LTC_MDSA_DELTA still correct?

IIUC it would prevent usage of keys generated by OpenSSL with L = 8192, N = 256.

[karel-m]

You mean something like this?

/* Max diff between group and modulus size in bytes (max case: L=8192bits, N=256bits) */
#define LTC_MDSA_DELTA 992

/* Max DSA group size in bytes */
#define LTC_MDSA_MAX_GROUP 64

/* Max DSA modulus size in bytes (the actual DSA size, max 8192 bits) */
#define LTC_MDSA_MAX_MODULUS 1024

[sjaeckel]

You mean something like this?

/* Max diff between group and modulus size in bytes (max case: L=8192bits, N=256bits) */
#define LTC_MDSA_DELTA 992

/* Max DSA group size in bytes */
#define LTC_MDSA_MAX_GROUP 64

/* Max DSA modulus size in bytes (the actual DSA size, max 8192 bits) */
#define LTC_MDSA_MAX_MODULUS 1024

yep, that looks better

[sjaeckel]

👍