Skip to content
GitLab
  1. 07 Apr, 2018 1 commit
  3. 05 Apr, 2018 3 commits
    • Matt Caswell's avatar
      Update the genpkey documentation · 0ac1a7ea
      Matt Caswell authored 
      

Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5884)
      0ac1a7ea
    • 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
  5. 03 Apr, 2018 3 commits
  7. 28 Mar, 2018 1 commit
  9. 27 Mar, 2018 7 commits
  11. 26 Mar, 2018 2 commits
  13. 25 Mar, 2018 1 commit
  15. 21 Mar, 2018 4 commits
  17. 20 Mar, 2018 1 commit
  19. 15 Mar, 2018 5 commits
  21. 14 Mar, 2018 1 commit
  23. 12 Mar, 2018 2 commits
  25. 11 Mar, 2018 1 commit
  27. 08 Mar, 2018 1 commit
  29. 07 Mar, 2018 1 commit
  31. 05 Mar, 2018 1 commit
  33. 04 Mar, 2018 1 commit
  35. 03 Mar, 2018 1 commit
  37. 02 Mar, 2018 1 commit
  39. 01 Mar, 2018 1 commit
  41. 26 Feb, 2018 1 commit
    • 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