From 19bd6f14cf74a3b089aa9460085baf2f8dbea8d7 Mon Sep 17 00:00:00 2001 From: larabr <7375870+larabr@users.noreply.github.com> Date: Wed, 22 Nov 2023 13:57:43 +0100 Subject: [PATCH] Add EdDSA signature verification step to prevent outputting faulty signatures EdDSA is known to be vulnerable to fault attacks which can lead to secret key extraction if two signatures over the same data can be collected. Randomly occurring bitflips in specific parts of the computation might in principle result in vulnerable faulty signatures being generated, hence we add the option to verify the signatures before outputting them. --- src/crypto/public_key/elliptic/eddsa.js | 14 ++++++++++++++ src/crypto/public_key/elliptic/eddsa_legacy.js | 14 ++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/src/crypto/public_key/elliptic/eddsa.js b/src/crypto/public_key/elliptic/eddsa.js index e38cbb96fe..33649c4e43 100644 --- a/src/crypto/public_key/elliptic/eddsa.js +++ b/src/crypto/public_key/elliptic/eddsa.js @@ -68,6 +68,20 @@ export async function sign(algo, hashAlgo, message, publicKey, privateKey, hashe case enums.publicKey.ed25519: { const secretKey = util.concatUint8Array([privateKey, publicKey]); const signature = nacl.sign.detached(hashed, secretKey); + if (!nacl.sign.detached.verify(hashed, signature, publicKey)) { + /** + * Detect faulty signatures caused by random bitflips during `crypto_sign` which could lead to private key extraction + * if two signatures over the same message are obtained. + * See https://github.com/jedisct1/libsodium/issues/170. + * If the input data is not deterministic, e.g. thanks to the random salt in v6 OpenPGP signatures (not yet implemented), + * then the generated signature is always safe, and the verification step is skipped. + * Otherwise, we need to verify the generated to ensure that no bitflip occured: + * - in M between the computation of `r` and `h`. + * - in the public key before computing `h` + * The verification step is almost 2-3 times as slow as signing, but it's faster than re-signing + re-deriving the public key for separate checks. + */ + throw new Error('Transient signing failure'); + } return { RS: signature }; } case enums.publicKey.ed448: diff --git a/src/crypto/public_key/elliptic/eddsa_legacy.js b/src/crypto/public_key/elliptic/eddsa_legacy.js index 63929ea7c3..83e1b84609 100644 --- a/src/crypto/public_key/elliptic/eddsa_legacy.js +++ b/src/crypto/public_key/elliptic/eddsa_legacy.js @@ -51,6 +51,20 @@ export async function sign(oid, hashAlgo, message, publicKey, privateKey, hashed } const secretKey = util.concatUint8Array([privateKey, publicKey.subarray(1)]); const signature = nacl.sign.detached(hashed, secretKey); + if (!nacl.sign.detached.verify(hashed, signature, publicKey)) { + /** + * Detect faulty signatures caused by random bitflips during `crypto_sign` which could lead to private key extraction + * if two signatures over the same message are obtained. + * See https://github.com/jedisct1/libsodium/issues/170. + * If the input data is not deterministic, e.g. thanks to the random salt in v6 OpenPGP signatures (not yet implemented), + * then the generated signature is always safe, and the verification step is skipped. + * Otherwise, we need to verify the generated to ensure that no bitflip occured: + * - in M between the computation of `r` and `h`. + * - in the public key before computing `h` + * The verification step is almost 2-3 times as slow as signing, but it's faster than re-signing + re-deriving the public key for separate checks. + */ + throw new Error('Transient signing failure'); + } // EdDSA signature params are returned in little-endian format return { r: signature.subarray(0, 32),