New subject: gitlab-ci builds (was: Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks)

30 Nov 2018


      A release candidate for nettle-3.4.1 is now available, as
https://www.lysator.liu.se/~nisse/archive/nettle-3.4.1rc1.tar.gz
  https://www.lysator.liu.se/~nisse/archive/nettle-3.4.1rc1.tar.gz.sig
Corresponding changes are also pushed to the branch
https://git.lysator.liu.se/nettle/nettle/tree/release-3.4-fixes
Release timing is prompted by the publication of http://cat.eyalro.net/.
Nettle and GnuTLS authors (as well as developers of other TLS
implementations) were notified by the research team a few months ago.
Related CVE ids:
CVE-2018-16868 gnutls: Bleichenbacher-like side channel leakage in
  PKCS#1 1.5 verification and padding oracle verification
CVE-2018-16869 nettle: Leaky data conversion exposing a manager oracle
For Nettle, the RSA code, which I wrote some 15 years ago, have seen an
overhawl. Not only making the handling of PKCS#1 on decryption
side-channel silent (the vulnerabilities that could be exploited by the
methods of the above paper), but also ensuring that we use side-channel
silent functions for the needed bignum arithmetic.
This has been a lot of work, and most of it not done by me, but by Simo
Sorce, at Red Hat Inc. Without this help, it would have been difficult
to get a good release out on time.
Testing of the release candidate is highly appreciated. I intend to make
and announce the non-candidate release soon, possibly as early as
tomorrow morning (i.e., December 1, in European timezone). A GnuTLS
release, depending on the new rsa_sec_decrypt function in Nettle-3.4.1,
is also being made about now.
My understanding is that there's no need to panic. The attack directly
affects RSA decryption, not signatures. And it requires some resources
to be pulled off. As far as I understand, a successful attack lets the
attacker decrypt or sign a targeted message, e.g., compromising the TLS
"premaster secret", corresponding session keys, and any transmitted
passwords or login cookies sent in a single TLS session, but it does not
expose the private key itself.
However, if you operate a TLS server, you should consider if you can
completely disable key exchange based on RSA decryption. If you need to
keep it for backwards compatibility, it is *strongly* encouraged to use
a separate RSA key for this purpose, *not* reused or authorized for any
other purpose.
Regards,
/Niels
NEWS for the Nettle 3.4.1 release
This release fixes a few bugs, and makes the RSA private key
    operations side channel silent. The RSA improvements are
    contributed by Simo Sorce and Red Hat, and include one new
    public function, rsa_sec_decrypt, see below.
All functions using RSA private keys are now side-channel
    silent, meaning that they try hard to avoid any branches or
    memory accesses depending on secret data. This applies both to
    the bignum calculations, which now use GMP's mpn_sec_* family
    of functions, and the processing of PKCS#1 padding needed for
    RSA decryption.
Nettle's ECC functions were already side-channel silent, while
    the DSA functions still aren't. There's also one caveat
    regarding the improved RSA functions: due to small table
    lookups in relevant mpn_sec_* functions in GMP-6.1.2, the
    lowest and highest few bits of the secret factors p and q may
    still leak. I'm not aware of any attacks on RSA where knowing
    a few bits of the factors makes a significant difference. This
    leak will likely be plugged in later GMP versions.
Changes in behavior:
* The functions rsa_decrypt and rsa_decrypt_tr may now clobber
      all of the provided message buffer, independent of the
      actual message length. They are side-channel silent, in that
      branches and memory accesses don't depend on the validity or
      length of the message. Side-channel leakage from the
      caller's use of length and return value may still provide an
      oracle useable for a Bleichenbacher-style chosen ciphertext
      attack. Which is why the new function rsa_sec_decrypt is
      recommended.
New features:
* A new function rsa_sec_decrypt. It differs from
      rsa_decrypt_tr in that the length of the decrypted message
      is given a priori, and PKCS#1 padding indicating a different
      length is treated as an error. For applications that may be
      subject to chosen ciphertext attacks, it is recommended to
      initialize the message area with random data, call this
      function, and ignore the return value. This applies in
      particular to RSA-based key exchange in the TLS protocol.
Bug fixes:
* Fix bug in pkcs1-conv, missing break statements in the
      parsing of PEM input files.
* Fix link error on the pss-mgf1-test test, affecting builds
      without public key support.
Performance regression:
* All RSA private key operations employing RSA blinding, i.e.,
      rsa_decrypt_tr, rsa_*_sign_tr, the new rsa_sec_decrypt, and
      rsa_compute_root_tr, are significantly slower. This is
      because (i) RSA blinding now use side-channel silent
      operations, (ii) blinding includes a modular inversion, and
      (iii) side-channel silent modular inversion, implemented as
      mpn_sec_invert, is very expensive. A 60% slowdown for
      2048-bit RSA keys have been measured.
Miscellaneous:
* Building the public key support of nettle now requires GMP
      version 6.0 or later (unless --enable-mini-gmp is used).
The shared library names are libnettle.so.6.5 and
    libhogweed.so.4.5, with sonames still libnettle.so.6 and
    libhogweed.so.4. It is intended to be fully binary compatible
    with nettle-3.1.
-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.