Page MenuHome GnuPG

rsa: Add exponent blinding.
ClosedPublic

Authored by marcus on Jul 5 2017, 7:21 PM.

Details

Summary
  • cipher/rsa.c (secret_core_crt): Blind secret D with randomized

nonce R for mpi_powm computation.

Backport of libgcrypt 8725c99ffa41778f382ca97233183bcd687bb0ce.

Signed-off-by: Marcus Brinkmann <mb@g10code.com>

Test Plan

I ran "make check" and all tests passed.

Diff Detail

Repository
rG GnuPG
Branch
STABLE-BRANCH-1-4
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

We don't like to add this to 1.4. blinding requires random and more secure memory. Thus gpg may run out of secure memory and won't be able to do its j

The problem I see is two-fold:

  • The CVE, as well as the international press and the announcement on gnupg-announce only mention libgcrypt, and there is no indication anywhere that I can see so far that GPG 1.4 is equally affected. We have to assume that GPG 1.4 is still in widespread use. At the very least it is included in some of the RHEL versions indicated in the CVE.
  • Our download page offers GPG 1.4.21 for download, which is affected, and carries the note: "GnuPG 1.4 is the old, single binary version which still support the unsafe PGP-2 keys. This branch has no dependencies on the above listed libraries or the Pinnetry. However, it lacks many features and will receive only important updates." Given the public attention the vulnerability in libgcrypt has gotten in the international press, I'd expect that this issue counts as "important".

Comments (and complaints to academic paper :-) were at jabber, yesterday. My point is that their claims are for their community to be accepted as a good paper, I have my own view.

I think that we should port all of related changes to gpg1.4, and possibly improve libgcrypt more.

(1) Apply reducing signal fixes in libgcrypt (of mpi_powm).
(2) While I review the patch, I think that we can reduce the pressure of secure memory as same as before, if we can do that, it would be OK to apply exponent blinding patch. Because:

  • Maintenance will be easier.
  • It can add some noise to side channel, even if not much.
  • It gives some people relief as same/similar patch is applied to gpg1.4 (give them the sign of gpg1.4 is maintained still).

I mean, we can release the memory of H and RR before calling mpi_powm, if matters.
(3) For libgcrypt, we can also implement fixed-window right-to-left algo for mpi_powm, and fix USE_ALGORITHM_SIMPLE_EXPONENTIATION implementation.

  • It gives some people relief as same/similar patch is applied to gpg1.4 (give them the sign of gpg1.4 is maintained still).

I can agree to that reasoning. This is easier that to write lots of mails explaining that we still care about 1.4.

OK, I'm going to apply this patch to gpg1.4 and then, to modify a bit to lower the secmem pressure.

This revision is now accepted and ready to land.Jul 7 2017, 3:01 PM