View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005328 | GNUnet | util library | public | 2018-05-17 13:14 | 2018-06-07 00:24 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | ||
| Priority | urgent | Severity | block | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | Git master | ||||
| Target Version | 0.11.0pre66 | Fixed in Version | 0.11.0pre66 | ||
| Summary | 0005328: GNUNET_CRYPTO_eddsa_ecdh() fails "randomly" | ||||
| Description | The 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 Reproduce | Change 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 Information | The 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). | ||||
| Tags | No tags attached. | ||||
|
|
This was seen using libgcrypt 1.7.6 (gnunet.org) and 1.8.2 (Julius). |
|
|
Same for lgcrypt 1.8.2 here. |
|
|
NIIBE Yutaka writes: With the change of following, it fails at the first invocation of test_ecdh. 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, &id1); 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, d)); + 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; -- |
|
|
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. |
| 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 | nikita | 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 |
