Skip to content
  1. Jul 12, 2018
  3. Jul 06, 2018
  5. Jun 29, 2018
  7. Jun 20, 2018
  9. Jun 19, 2018
  11. Jun 18, 2018
  13. Jun 08, 2018
  15. Jun 03, 2018
  17. Apr 17, 2018
  19. Apr 13, 2018
    • Matt Caswell's avatar
      Add support for the SRP base64 alphabet · 3fd59700
      Matt Caswell authored 
      Historically we used to implement standalone base64 code for SRP. This
was replaced by commit 3d3f21aa

 with the standard base64 processing code.

However, the SRP base64 code was designed to be compatible with other SRP
libraries (notably libsrp, but also others) that use a variant of standard
base64. Specifically a different alphabet is used and no padding '='
characters are used. Instead 0 padding is added to the front of the string.
By changing to standard base64 we change the behaviour of the API which may
impact interoperability. It also means that SRP verifier files created prior
to 1.1.1 would not be readable in 1.1.1 and vice versa.

Instead we expand our standard base64 processing with the capability to be
able to read and generate the SRP base64 variant.

Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5925)
      3fd59700
    • Matt Caswell's avatar
      Change SRP functions to use EVP_EncodeUpdate/EVP_DecodeUpdate functions · c0804614
      Matt Caswell authored 
      

Previously they were using EVP_EncodeBlock/EVP_DecodeBlock. These are low
level functions that do not handle padding characters. This was causing
the SRP code to fail. One side effect of using EVP_EncodeUpdate is that
it inserts newlines which is not what we need in SRP so we add a flag to
avoid that.

Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5925)
      c0804614
  21. Apr 03, 2018
  23. Apr 02, 2018
  25. Mar 29, 2018
  27. Mar 28, 2018
  29. Mar 21, 2018
  31. Mar 20, 2018
  33. Mar 19, 2018
  35. Mar 15, 2018
  37. Mar 02, 2018
  39. Feb 28, 2018
  41. Feb 27, 2018
    • Dr. Matthias St. Pierre's avatar
      bio_b64.c: prevent base64 filter BIO from decoding out-of-bound data · d070b4ae
      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)
      d070b4ae
    • Matt Caswell's avatar
      Update copyright year · 0d664759
      Matt Caswell authored 
      

Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      0d664759
  43. Feb 23, 2018
  45. Feb 14, 2018
    • Viktor Dukhovni's avatar
      Avoid fragile aliasing of SHA224/384 update/final · babab8e7
      Viktor Dukhovni authored 
      

This is purported to save a few cycles, but makes the code less
obvious and more brittle, and in fact breaks on platforms where for
ABI continuity reasons there is a SHA2 implementation in libc, and
so EVP needs to call those to avoid conflicts.

A sufficiently good optimizer could simply generate the same entry
points for:

        foo(...) { ... }
    and
        bar(...) { return foo(...); }

but, even without that, the different is negligible, with the
"winner" varying from run to run (openssl speed -evp sha384):

    Old:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
    sha384           28864.28k   117362.62k   266469.21k   483258.03k   635144.87k 649123.16k

    New:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
    sha384           30055.18k   120725.98k   272057.26k   482847.40k   634585.09k 650308.27k

Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      babab8e7
  47. Feb 06, 2018
  49. Jan 23, 2018