gitlab-ci builds (was: Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks)
ni...@lysator.liu.se (Niels Möller) writes: > I'm also considering adding a few more configurations to the ci, > including "CC=gcc -std=c89", CPPFLAGS=-DNODEBUG and --disable-assembler. Done (but with -DNDEBUG, not -DNODEBUG). Seems to pass. For the fat builds, it would make some sense to run make check with some different settings for the NETTLE_FAT_OVERRIDE environment variable. What's available on the gitlab build machines? Fat builds are of interest for: x86_64 (native), where recognized keywords are vendor:intel/amd (used to select sse-based memxor), aesni and sha_ni, and arm, (32-bit, user-level qemu), where recognized keywords are arch: (distinction between armv6 and earlier) and neon. When I run qemu locally, all variants seem to be supported. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
On Sat, 2019-01-12 at 17:47 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > I attach a patch which moves everything to the latest images used > > by > > gnutls (i.e., in addition to your patch, it also moves the x86 > > builds > > to debian). > > Merged now. And I've deleted eratosthens.c. We'll see how to deal > with > the static analalyzer's remaining complaints on eccdata.c. > > I'm also considering adding a few more configurations to the ci, > including "CC=gcc -std=c89", CPPFLAGS=-DNODEBUG and --disable- > assembler. > Anything I have to keep in mind (e.g., limits on builder resources?) As an open source project in gitlab there are no limits. The only limit is your running time expectations. regards, Nikos ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
Jeffrey Walton writes: > My bad, I was speaking to the proposed -DNODEBUG macro presented earlier: Sorry for that typo; I intended to use the standard assert.h facility, i.e., -DNDEBUG. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
On Sat, Jan 12, 2019 at 6:01 PM Niels Möller wrote: > > Jeffrey Walton writes: > > > I recommend making folks explicitly ask for a debug build with > > -DNETTLE_DEBUG or similar. > > "Debug build" vs "release build" is a bit alien to the way GNU packages > are usually built, and I suspect it partly dates to times where > optimization and useful debugging info were mutually exclusive. > Default builds include both optimization and debugging symbols (and I > think that's still what GNU coding standards recommend, perhaps with the > option to strip debug symbols at install time). > > Regarding asserts, I generally recommend to build with asserts enabled. > I know you disagree about that, but I really do *not* want any of us to > repeast arguments on that topic on this list. Don't go that way. > > I'm happy to support builds with asserts turned off (that's the only > reason I'm considering adding a ci builds for that configuration), but > it's not going to be the default config. > > Not sure a --disable-asserts configura option is that useful, if it's > only an alias for -DNDEBUG. What other effects do you suggest > --disable-debug or --disable-assert should have? > > > Don't define it in terms of "not Posix NDEBUG " or "not Nettle > > NODEBUG". > > I'm not following. As far as I understand, assert.h and NDEBUG are part > of the C language, not Posix. > > (To go out on a tangent, there may be some projects where it's useful to > include a *lot* of extra sanity code, and then have a way to exclude it > for a "release" build. I think that's a bit rare, though, and I don't > think Nettle is that type of project. I seem to recall one of the > openbsd developers advocating always deleting the extra sanity check > code and debug printfs after the code is in working state, before > checking it in, to not distract from the actual code. In contrast to the > fairly common practice to leave it in in under some #ifdef under the > theory that it might be nice to have in some future debugging session. > If it's really motivated to have that sanity check code in at all, > because bugs are expected to have particularly subtle and hard-to-debug > effects, one may well want that extra correctness assurance also when > using the installed program in a "release" build). My bad, I was speaking to the proposed -DNODEBUG macro presented earlier: > I'm also considering adding a few more configurations to the ci, > including "CC=gcc -std=c89", CPPFLAGS=-DNODEBUG and --disable-assembler. > Anything I have to keep in mind (e.g., limits on builder resources?) Jeff ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
Jeffrey Walton writes: > I recommend making folks explicitly ask for a debug build with > -DNETTLE_DEBUG or similar. "Debug build" vs "release build" is a bit alien to the way GNU packages are usually built, and I suspect it partly dates to times where optimization and useful debugging info were mutually exclusive. Default builds include both optimization and debugging symbols (and I think that's still what GNU coding standards recommend, perhaps with the option to strip debug symbols at install time). Regarding asserts, I generally recommend to build with asserts enabled. I know you disagree about that, but I really do *not* want any of us to repeast arguments on that topic on this list. Don't go that way. I'm happy to support builds with asserts turned off (that's the only reason I'm considering adding a ci builds for that configuration), but it's not going to be the default config. Not sure a --disable-asserts configura option is that useful, if it's only an alias for -DNDEBUG. What other effects do you suggest --disable-debug or --disable-assert should have? > Don't define it in terms of "not Posix NDEBUG " or "not Nettle > NODEBUG". I'm not following. As far as I understand, assert.h and NDEBUG are part of the C language, not Posix. (To go out on a tangent, there may be some projects where it's useful to include a *lot* of extra sanity code, and then have a way to exclude it for a "release" build. I think that's a bit rare, though, and I don't think Nettle is that type of project. I seem to recall one of the openbsd developers advocating always deleting the extra sanity check code and debug printfs after the code is in working state, before checking it in, to not distract from the actual code. In contrast to the fairly common practice to leave it in in under some #ifdef under the theory that it might be nice to have in some future debugging session. If it's really motivated to have that sanity check code in at all, because bugs are expected to have particularly subtle and hard-to-debug effects, one may well want that extra correctness assurance also when using the installed program in a "release" build). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
On Sat, Jan 12, 2019 at 11:47 AM Niels Möller wrote: > > Nikos Mavrogiannopoulos writes: > ... > I'm also considering adding a few more configurations to the ci, > including "CC=gcc -std=c89", CPPFLAGS=-DNODEBUG and --disable-assembler. > Anything I have to keep in mind (e.g., limits on builder resources?) I recommend making folks explicitly ask for a debug build with -DNETTLE_DEBUG or similar. Don't define it in terms of "not Posix NDEBUG " or "not Nettle NODEBUG". The typical use case is folks untar, config, and make. Eventually they want to install locally, perhaps as part of a collection of packages. Those who perform a straight release build should not have to do something special. Also, it depends on each person reading the manual and things just don't work that way in real life. Folks who want a debug build should do something special. They will notice right away they have an optimized build missing symbols under the debugger. They will know to investigate more, like running './configure --help'. The debug build use case also means `--with-debug` or similar that adds -DNETTLE_DEBUG or similar is probably a good idea. If you chose to make the debug builds the default case then be sure to tell folks about it after configure runs. Also tell them the options needed to perform a release build since many folks will want a release build. (This is the part of security engineering that offends almost everyone. You have to identify use cases and then acknowledge one as the dominant case. Then, others have to do something special and you have to tell them how to ensure they can shoot themselves in the foot, if desired). Jeff ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
Nikos Mavrogiannopoulos writes: > I attach a patch which moves everything to the latest images used by > gnutls (i.e., in addition to your patch, it also moves the x86 builds > to debian). Merged now. And I've deleted eratosthens.c. We'll see how to deal with the static analalyzer's remaining complaints on eccdata.c. I'm also considering adding a few more configurations to the ci, including "CC=gcc -std=c89", CPPFLAGS=-DNODEBUG and --disable-assembler. Anything I have to keep in mind (e.g., limits on builder resources?) Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
On Sat, 2018-12-29 at 10:40 +0100, Niels Möller wrote: > Nikos Mavrogiannopoulos writes: > > > I am not at home to check but most likely a newer openssl is > > needed. You can use fedora:29 or fedora:latest > > Ok, I'm trying I attach a patch which moves everything to the latest images used by gnutls (i.e., in addition to your patch, it also moves the x86 builds to debian). The gnutls build now passes but the static analyzers fail as you also saw. A quick fix would be to leave the static analyzers to use f28 though that would need to be solved eventually. regards, Nikos From 76ef226e8c309a3aacb1cfa52edf7d90e1f3d070 Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos Date: Wed, 2 Jan 2019 10:31:08 +0100 Subject: [PATCH] .gitlab-ci.yml: updated to new images by gnutls Signed-off-by: Nikos Mavrogiannopoulos --- .gitlab-ci.yml | 30 ++ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 166de71b..96a007e7 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -1,8 +1,8 @@ variables: BUILD_IMAGES_PROJECT: gnutls/build-images DEBIAN_CROSS_BUILD: buildenv-debian-cross - FEDORA_BUILD: buildenv-f28 - FEDORA_X86_BUILD: buildenv-f28-x86 + FEDORA_BUILD: buildenv-f29 + DEBIAN_X86_CROSS_BUILD: buildenv-debian-x86-cross GET_SOURCES_ATTEMPTS: "3" # remove any pre-installed headers from nettle @@ -20,16 +20,6 @@ build/x86-64: - shared except: - tags -build/x86: - image: $CI_REGISTRY/$BUILD_IMAGES_PROJECT:$FEDORA_X86_BUILD - script: - - ./.bootstrap && -PKG_CONFIG_PATH="/usr/lib/pkgconfig/" CFLAGS="-O2 -g -m32" LDFLAGS="-m32" ./configure --build=i686-redhat-linux --enable-fat --disable-documentation && make -j4 && -make check -j4 - tags: - - shared - except: - - tags build/mini-gmp: image: $CI_REGISTRY/$BUILD_IMAGES_PROJECT:$FEDORA_BUILD script: @@ -98,6 +88,22 @@ build/gnutls: - gnutls-git/*.log - gnutls-git/tests/*/*.log - gnutls-git/tests/suite/*/*.log +Debian.cross.x86: + image: $CI_REGISTRY/$BUILD_IMAGES_PROJECT:$DEBIAN_X86_CROSS_BUILD + before_script: + - apt-get remove -y nettle-dev:i386 + script: + - build=$(dpkg-architecture -qDEB_HOST_GNU_TYPE) + - host=i686-linux-gnu + - export CC_FOR_BUILD="gcc" + - export CC="$host-gcc" + - ./.bootstrap && +CFLAGS="-O2 -g" ./configure --build=$build --host=$host --enable-fat --disable-documentation && make -j4 && +make check -j4 + tags: + - shared + except: + - tags .Debian.cross.template: _cross_template image: $CI_REGISTRY/$BUILD_IMAGES_PROJECT:$DEBIAN_CROSS_BUILD before_script: -- 2.19.2 ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
On 29.12.18 12:36, Nikos Mavrogiannopoulos wrote: > For x86 builds the new image uses debian because it has a simpler and has a > reproducible way to generate it. The x86 fedora image will remain though. > > With the current nettle master oss fuzz still fails to compile (does link > statically) due to cnd_memcpy not found: > > https://oss-fuzz-build-logs.storage.googleapis.com/log-8fca2d38-422a-47bf-84b5-e6fe3b6a9c73.txt I had the same problem with wget and wget2. Fixed it by changing -lnettle -lhogweed` to `-lhogweed -lnettle`. The current clang linker on oss-fuzz changed the way it works, at least for static linking. Regards, Tim signature.asc Description: OpenPGP digital signature ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
For x86 builds the new image uses debian because it has a simpler and has a reproducible way to generate it. The x86 fedora image will remain though. With the current nettle master oss fuzz still fails to compile (does link statically) due to cnd_memcpy not found: https://oss-fuzz-build-logs.storage.googleapis.com/log-8fca2d38-422a-47bf-84b5-e6fe3b6a9c73.txt On December 29, 2018 9:40:48 AM UTC, ni...@lysator.liu.se wrote: >Nikos Mavrogiannopoulos writes: > >> I am not at home to check but most likely a newer openssl is needed. >You can use fedora:29 or fedora:latest > >Ok, I'm trying > >diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml >index 166de71b..f4ed3496 100644 >--- a/.gitlab-ci.yml >+++ b/.gitlab-ci.yml >@@ -1,7 +1,7 @@ > variables: > BUILD_IMAGES_PROJECT: gnutls/build-images > DEBIAN_CROSS_BUILD: buildenv-debian-cross >- FEDORA_BUILD: buildenv-f28 >+ FEDORA_BUILD: buildenv-f29 > FEDORA_X86_BUILD: buildenv-f28-x86 > GET_SOURCES_ATTEMPTS: "3" > >(Also changing FEDORA_X86_BUILD in a similar way failed). > >I've also added needed asserts in eccdata, to satisfy the static >analyzer (and I guess eccdata's validation of command line args isn't >that robust even efter these changes, but it doesn't really need to >be). > >Ouch, and it seems the static analyzer now has even more warnings on >eccdata. Maybe more asserts needed to tell it that accesses are within >the allocated and initialized table size. > >Besides that, there's one remaining warning from the static analyzer, >on >examples/eratosthenes.c. I'm considering just deleting that file. > >It was used for generating tables used by bignum-next-prime.c, but that >file was deleted a few years ago. It was unused since prime generation >was rewritten in 2010. The new (in 2010) code in nettle_random_prime >uses a smaller table of the 171 odd primes < 1024, and some auxillary >tables to aid trial division. I'm afraid I don't recall what tools were >used to prepare those tables. > >Regards, >/Niels -- Sent from my mobile. Please excuse my brevity. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
Nikos Mavrogiannopoulos writes: > I am not at home to check but most likely a newer openssl is needed. You can > use fedora:29 or fedora:latest Ok, I'm trying diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 166de71b..f4ed3496 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -1,7 +1,7 @@ variables: BUILD_IMAGES_PROJECT: gnutls/build-images DEBIAN_CROSS_BUILD: buildenv-debian-cross - FEDORA_BUILD: buildenv-f28 + FEDORA_BUILD: buildenv-f29 FEDORA_X86_BUILD: buildenv-f28-x86 GET_SOURCES_ATTEMPTS: "3" (Also changing FEDORA_X86_BUILD in a similar way failed). I've also added needed asserts in eccdata, to satisfy the static analyzer (and I guess eccdata's validation of command line args isn't that robust even efter these changes, but it doesn't really need to be). Ouch, and it seems the static analyzer now has even more warnings on eccdata. Maybe more asserts needed to tell it that accesses are within the allocated and initialized table size. Besides that, there's one remaining warning from the static analyzer, on examples/eratosthenes.c. I'm considering just deleting that file. It was used for generating tables used by bignum-next-prime.c, but that file was deleted a few years ago. It was unused since prime generation was rewritten in 2010. The new (in 2010) code in nettle_random_prime uses a smaller table of the 171 odd primes < 1024, and some auxillary tables to aid trial division. I'm afraid I don't recall what tools were used to prepare those tables. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
Thank you, Niels ! On 26.12.18 15:28, Niels Möller wrote: > Tim Rühsen writes: > >> Are you going to merge all of those into your master branch, so that >> e.g. latest GnuTLS can be build it ? > > I've now done a merge from the release-3.4-fixes branch to master. The > gnutls build on gitlab still fails one test, > > FAIL: testcompat-tls13-openssl.sh > > See https://gitlab.com/gnutls/nettle/pipelines/41333133. > > But at least it seems to build fine now. > > Regards, > /Niels > signature.asc Description: OpenPGP digital signature ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
On 12/3/18 9:09 AM, Nikos Mavrogiannopoulos wrote: > On Sun, 2018-12-02 at 17:46 +0100, Tim Rühsen wrote: > Currently I see a several automated builds breaking. It's those with the latest GnuTLS (from git master) as dependency. They normally pull in all dependencies (nettle and others) in their latest version from git repos (mostly branch 'master'). >>> >>> There's both a branch "release-3.4-fixes", and a tag >>> "nettle_3.4.1rc1". >>> Could you use either of them for the Nettle dependency in the mean >>> time? >> >> That's an option, but needs manual work (testing, PR/MRs, review, >> etc). >> So for my part I would just wait until the merge is done. > > Was it oss-fuzz you had in mind? Indeed it's unfortunate that our > automation breaks on such situations, but I guess if that's temporary, > that's ok. OSS-Fuzz and some Gitlab CI images (Debian based MinGW) where I have to build all MinGW dependencies. And yes, I am pretty relaxed knowing the break is temporary. Regards, Tim signature.asc Description: OpenPGP digital signature ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
On Sun, 2018-12-02 at 17:46 +0100, Tim Rühsen wrote: > > > Currently I see a several automated builds breaking. It's those > > > with > > > the latest GnuTLS (from git master) as dependency. They normally > > > pull in > > > all dependencies (nettle and others) in their latest version from > > > git > > > repos (mostly branch 'master'). > > > > There's both a branch "release-3.4-fixes", and a tag > > "nettle_3.4.1rc1". > > Could you use either of them for the Nettle dependency in the mean > > time? > > That's an option, but needs manual work (testing, PR/MRs, review, > etc). > So for my part I would just wait until the merge is done. Was it oss-fuzz you had in mind? Indeed it's unfortunate that our automation breaks on such situations, but I guess if that's temporary, that's ok. regards, Nikos ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
Tim Rühsen writes: > Are you going to merge all of those into your master branch, so that > e.g. latest GnuTLS can be build it ? I will, but not with urgency. And possibly with slightly different organization (but the implementation and the new rsa_sec_decrypt api will be the same). And I'll be a bit busy both coming week and next weekend. And naturally, getting the 3.4.1 release out has the highest priority, which should happen in a day or two. I would have hoped for a bit more testing, but I'll have to make release very soon regardless. > Currently I see a several automated builds breaking. It's those with > the latest GnuTLS (from git master) as dependency. They normally pull in > all dependencies (nettle and others) in their latest version from git > repos (mostly branch 'master'). There's both a branch "release-3.4-fixes", and a tag "nettle_3.4.1rc1". Could you use either of them for the Nettle dependency in the mean time? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Re: Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
Hi Niels, thank you (and all involved) for the fixes ! Are you going to merge all of those into your master branch, so that e.g. latest GnuTLS can be build it ? Reason: Currently I see a several automated builds breaking. It's those with the latest GnuTLS (from git master) as dependency. They normally pull in all dependencies (nettle and others) in their latest version from git repos (mostly branch 'master'). Latest nettle master would need the fixes *and* a version 3.4.1 tag (or higher) to build with GnuTLS here. Thank you ! Regards, Tim On 30.11.18 17:41, Niels Möller wrote: > 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 > ... signature.asc Description: OpenPGP digital signature ___ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
Nettle-3.4.1rc1, addressing PKCS#1 side-channel leaks
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
