Skip to content
  1. Apr 05, 2018
    • Matt Caswell's avatar
      Pick a q size consistent with the digest for DSA param generation · 3e5f19a3
      Matt Caswell authored 
      

There are two undocumented DSA parameter generation options available in
the genpkey command line app:
dsa_paramgen_md and dsa_paramgen_q_bits.

These can also be accessed via the EVP API but only by using
EVP_PKEY_CTX_ctrl() or EVP_PKEY_CTX_ctrl_str() directly. There are no
helper macros for these options.

dsa_paramgen_q_bits sets the length of q in bits (default 160 bits).
dsa_paramgen_md sets the digest that is used during the parameter
generation (default SHA1). In particular the output length of the digest
used must be equal to or greater than the number of bits in q because of
this code:

            if (!EVP_Digest(seed, qsize, md, NULL, evpmd, NULL))
                goto err;
            if (!EVP_Digest(buf, qsize, buf2, NULL, evpmd, NULL))
                goto err;
            for (i = 0; i < qsize; i++)
                md[i] ^= buf2[i];

            /* step 3 */
            md[0] |= 0x80;
            md[qsize - 1] |= 0x01;
            if (!BN_bin2bn(md, qsize, q))
                goto err;

qsize here is the number of bits in q and evpmd is the digest set via
dsa_paramgen_md. md and buf2 are buffers of length SHA256_DIGEST_LENGTH.
buf2 has been filled with qsize bits of random seed data, and md is
uninitialised.

If the output size of evpmd is less than qsize then the line "md[i] ^=
buf2[i]" will be xoring an uninitialised value and the random seed data
together to form the least significant bits of q (and not using the
output of the digest at all for those bits) - which is probably not what
was intended. The same seed is then used as an input to generating p. If
the uninitialised data is actually all zeros (as seems quite likely)
then the least significant bits of q will exactly match the least
significant bits of the seed.

This problem only occurs if you use these undocumented and difficult to
find options and you set the size of q to be greater than the message
digest output size. This is for parameter generation only not key
generation. This scenario is considered highly unlikely and
therefore the security risk of this is considered negligible.

Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5884)
      3e5f19a3
    • Matt Caswell's avatar
      Don't crash if an unrecognised digest is used with dsa_paramgen_md · 5068cfbd
      Matt Caswell authored 
      

Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5884)
      5068cfbd
  3. Apr 03, 2018
  5. Mar 28, 2018
  7. Mar 27, 2018
  9. Mar 26, 2018
  11. Mar 25, 2018
  13. Mar 21, 2018
  15. Mar 20, 2018
  17. Mar 15, 2018
  19. Mar 14, 2018
  21. Mar 12, 2018
  23. Mar 11, 2018
  25. Mar 08, 2018
  27. Mar 07, 2018
  29. Mar 05, 2018
  31. Mar 04, 2018
  33. Mar 03, 2018
  35. Mar 02, 2018
  37. Mar 01, 2018
  39. Feb 26, 2018
    • Dr. Matthias St. Pierre's avatar
      bio_b64.c: prevent base64 filter BIO from decoding out-of-bound data · b3f9b401
      Dr. Matthias St. Pierre authored 
      Fixes #5405, #1381

The base64 filter BIO reads its input in chunks of B64_BLOCK_SIZE bytes.
When processing input in PEM format it can happen in rare cases that

- the trailing PEM marker crosses the boundary of a chunk, and
- the beginning of the following chunk contains valid base64 encoded data.

This happened in issue #5405, where the PEM marker was split into
"-----END CER" and "TIFICATE-----" at the end of the first chunk.

The decoding of the first chunk terminated correctly at the '-' character,
which is treated as an EOF marker, and b64_read() returned. However,
when called the second time, b64_read() read the next chunk and interpreted
the string "TIFICATE" as valid base64 encoded data, adding 6 extra bytes
'4c 81 48 08 04 c4'.

This patch restores the assignment of the error code to 'ctx->cont', which
was deleted accidentally in commit 5562cfac

 and which prevents b64_read()
from reading additional data on subsequent calls.

This issue was observed and reported by Annie Yousar.

Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5422)
      b3f9b401
  41. Feb 22, 2018