2018-08-18 21:50 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005328GNUnetutil librarypublic2018-06-07 00:24
ReporterChristian Grothoff 
Assigned ToChristian Grothoff 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product VersionSVN HEAD 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0005328: GNUNET_CRYPTO_eddsa_ecdh() fails "randomly"
DescriptionThe routine is supposed to do a DH between an EdDSA key and an ECDHE key. It usually works fine, but sometimes the derived secrets differ. The chance is more like 1:100, and so far we see it _always_ happen for 1% of the EdDSA keys (and then seemingly with any ECDHE key).

The very low failure rate suggests it is not a simple bit-flip error, as the chance for this seems to be a bit too low. Jeff suspects it may be a bug on an obscure code path in libgcrypt.
Steps To ReproduceChange the #define CRYPTO_BUG to 0 in crypto_bug.c to disable the mitigation in Git. Then run test_crypto_ecdh_eddsa. It may not fail every time, but given the new number of iterations should fail most of the time.
Additional InformationThe crypto_bug code adds a mitigation to GNUnet which tests if an EdDSA key is affected by the bug and then simply creates a fresh one (if possible). For peers where a previously generated hostkey is affected, the mitigation will prevent it from even starting up properly, and users will have to manually delete them using:

$ rm `gnunet-config -f -s peer -o private_key`

(mind the BACK-ticks).
TagsNo tags attached.
Attached Files

-Relationships Relation Graph ] Dependency Graph ]



Christian Grothoff (manager)

This was seen using libgcrypt 1.7.6 (gnunet.org) and 1.8.2 (Julius).


ng0 (developer)

Same for lgcrypt 1.8.2 here.


Christian Grothoff (manager)

NIIBE Yutaka writes:

With the change of following, it fails at the first invocation of

diff --git a/src/util/test_crypto_ecdh_eddsa.c b/src/util/test_crypto_ecdh_eddsa.c
index 356c64bf1..41a1d0777 100644
--- a/src/util/test_crypto_ecdh_eddsa.c
+++ b/src/util/test_crypto_ecdh_eddsa.c
@@ -40,6 +40,7 @@ test_ecdh()
   /* Generate keys */
   priv_dsa = GNUNET_CRYPTO_eddsa_key_create ();
+ priv_dsa->d[0] = 0;
   GNUNET_CRYPTO_eddsa_key_get_public (priv_dsa,
   for (unsigned int j=0;j<10;j++)

Just in case if my explanation was not clear enough, here is a possible
patch to fix the issue I found. I don't claim any copyright for that.

It is possible that we are looking different bugs, but I think that
this fix is needed, at least. gnunet/src/util/test_crypto_ecdh_eddsa.c
goes well after the fix (even with adding a line of priv_dsa->d[0] = 0).

diff --git a/src/util/crypto_ecc.c b/src/util/crypto_ecc.c
index 1abf0fddc..a05f6a107 100644
--- a/src/util/crypto_ecc.c
+++ b/src/util/crypto_ecc.c
@@ -1281,6 +1281,13 @@ eddsa_d_to_a (gcry_mpi_t d)
                  gcry_mpi_print (GCRYMPI_FMT_USG,
                  rawmpi, rawmpilen, &rawmpilen,
+ if (rawmpilen < 32)
+ {
+ memmove (rawmpi + 32 - rawmpilen, rawmpi, rawmpilen);
+ memset (rawmpi, 0, 32 - rawmpilen);
+ rawmpilen = 32;
+ }
   hvec[0].data = digest;
   hvec[0].off = 0;
   hvec[0].len = b > rawmpilen ? (b - rawmpilen) : 0;


Christian Grothoff (manager)

Setting priv_dsa->d[0]=0 seems to _always_ trigger the bug on 64-bit systems, but it remains random (with low probability) on 32-bit systems even with this modification.

But, the memmove() seems to fix the issue _always_ on both 32-bit and 64-bit systems.

So libgcrypt seems to be inconsistent in the need for the memmove between 32-bit and 64-bit systems, but at least for GNUnet this fix seems to work.

-Issue History
Date Modified Username Field Change
2018-05-17 13:14 Christian Grothoff New Issue
2018-05-17 13:40 Christian Grothoff Note Added: 0012929
2018-05-22 13:26 ng0 Note Added: 0012946
2018-05-28 13:01 Christian Grothoff Note Added: 0012963
2018-05-28 13:02 Christian Grothoff Assigned To => Christian Grothoff
2018-05-28 13:02 Christian Grothoff Status new => assigned
2018-05-30 11:00 Christian Grothoff Note Added: 0012970
2018-05-30 11:00 Christian Grothoff Status assigned => resolved
2018-05-30 11:00 Christian Grothoff Resolution open => fixed
2018-05-30 11:00 Christian Grothoff Fixed in Version => 0.11.0pre66
2018-06-07 00:24 Christian Grothoff Status resolved => closed
+Issue History