Update draft-irtf-cfrg-det-sigs-with-noise.md

emanjon · web-flow · commit b49b18b92b0a · 2024-02-28T06:53:09.000+01:00
diff --git a/draft-irtf-cfrg-det-sigs-with-noise.md b/draft-irtf-cfrg-det-sigs-with-noise.md
@@ -47,14 +47,14 @@ normative:
   RFC8174:
   RFC8692:
 
-  FIPS-186-4:
-    target: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
+  FIPS-186-5:
+    target: https://doi.org/10.6028/NIST.FIPS.186-5
     title: Digital Signature Standard (DSS)
-    seriesinfo: "NIST FIPS PUB 186-4"
+    seriesinfo: "NIST FIPS PUB 186-5"
     author:
       -
         ins: "National Institute of Standards and Technology, U.S. Department of Commerce"
-    date: July 2013
+    date: February 2023
 
   SHA3:
     target: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
@@ -430,7 +430,7 @@ Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA ha
 
 # Introduction
 
-In Elliptic-Curve Cryptography (ECC) signature algorithms, the per-message secret number has traditionally been generated from a random number generator (RNG). The security of such algorithms depends on the cryptographic quality of the random number generation and biases in the randomness may have catastrophic effects such as compromising private keys (see e.g., {{Bernstein19}}). Repeated per-message secret numbers have caused several severe security accidents in practice. As stated in {{RFC6979}}, the need for a cryptographically secure source of randomness is also a hindrance to deployment of randomized ECDSA {{FIPS-186-4}} in architectures where secure random number generation is challenging, in particular, embedded IoT systems and smartcards. {{ABFJLM17}} does however state that smartcards typically have a high-quality RNG on board, which makes it significantly easier and faster to use the RNG instead of doing a hash computation.
+In Elliptic-Curve Cryptography (ECC) signature algorithms, the per-message secret number has traditionally been generated from a random number generator (RNG). The security of such algorithms depends on the cryptographic quality of the random number generation and biases in the randomness may have catastrophic effects such as compromising private keys (see e.g., {{Bernstein19}}). Repeated per-message secret numbers have caused several severe security accidents in practice. As stated in {{RFC6979}}, the need for a cryptographically secure source of randomness is also a hindrance to deployment of randomized ECDSA {{FIPS-186-5}} in architectures where secure random number generation is challenging, in particular, embedded IoT systems and smartcards. {{ABFJLM17}} does however state that smartcards typically have a high-quality RNG on board, which makes it significantly easier and faster to use the RNG instead of doing a hash computation.
 
 In deterministic ECC signatures schemes such as Deterministic Elliptic Curve Digital Signature Algorithm (ECDSA) {{RFC6979}} and Edwards-curve Digital Signature Algorithm (EdDSA) {{RFC8032}}, the per-message secret number is instead generated in a fully deterministic way as a function of the message and the private key. Except for key generation, the security of such deterministic signatures does not depend on a source of high-quality randomness. This makes verification of implementations easier. As they are presumed to be safer, deterministic signatures have gained popularity and are referenced and recommended by a large number of recent RFCs {{RFC8037}} {{RFC8080}} {{RFC8225}} {{RFC8387}} {{RFC8410}} {{RFC8411}} {{RFC8419}} {{RFC8420}} {{RFC8422}} {{RFC8446}} {{RFC8463}} {{RFC8550}} {{RFC8591}} {{RFC8608}} {{RFC8624}} {{RFC9053}}.
 
@@ -442,7 +442,7 @@ Government agencies are clearly concerned about these attacks. In {{Notice-186-5
 
 Note that deriving per-message secret number deterministically, is also insecure in a multi-party signature setting {{I-D.irtf-cfrg-frost}}.
 
-One countermeasure to  entropy failures, side-channel attacks, and fault injection attacks recommended by {{Langley13}} {{RP17}} {{ABFJLM17}} {{SBBDS17}} {{PSSLR17}} {{SB18}} {{AOTZ19}} {{FG19}} and implemented in {{OpenSSL13a}} {{OpenSSL13b}} {{XEdDSA}} {{libSodium}} {{libHydrogen}} is to generate the per-message secret number from a random string, a secret key, and the message. This combines the security benefits of fully randomized per-message secret numbers with the security benefits of fully deterministic secret numbers.  Such a construction protects against key compromise due to weak random number generation, but still effectively prevents many side-channel and fault injection attacks that exploit determinism. Such a construction require minor changes to the implementation and does not increase the number of elliptic curve point multiplications and is therefore suitable for constrained IoT. Adding randomness to EdDSA is not compliant with [RFC8032]. {{Kampanakis16}} describes an alternative {{FIPS-186-4}} compliant approach where message specific pseudo-random information is used as an additional input to the random number generation to create per-message secret number. {{Bernstein14}} states that generation of the per-message secret number from a subset of a random string, a secret key, the message, and a message counter is common in DSA/ECDSA implementations.
+One countermeasure to  entropy failures, side-channel attacks, and fault injection attacks recommended by {{Langley13}} {{RP17}} {{ABFJLM17}} {{SBBDS17}} {{PSSLR17}} {{SB18}} {{AOTZ19}} {{FG19}} and implemented in {{OpenSSL13a}} {{OpenSSL13b}} {{XEdDSA}} {{libSodium}} {{libHydrogen}} is to generate the per-message secret number from a random string, a secret key, and the message. This combines the security benefits of fully randomized per-message secret numbers with the security benefits of fully deterministic secret numbers.  Such a construction protects against key compromise due to weak random number generation, but still effectively prevents many side-channel and fault injection attacks that exploit determinism. Such a construction require minor changes to the implementation and does not increase the number of elliptic curve point multiplications and is therefore suitable for constrained IoT. Adding randomness to EdDSA is not compliant with [RFC8032]. {{Kampanakis16}} describes an alternative {{FIPS-186-5}} compliant approach where message specific pseudo-random information is used as an additional input to the random number generation to create per-message secret number. {{Bernstein14}} states that generation of the per-message secret number from a subset of a random string, a secret key, the message, and a message counter is common in DSA/ECDSA implementations.
 
 This document updates {{RFC6979}} and {{RFC8032}} to recommend constructions with additional randomness for deployments where side-channel and fault injection attacks are a concern. The updates are invisible to the validator of the signature. Produced signatures remain fully compatible with unmodified ECDSA and EdDSA verifiers and existing key pairs can continue to be used. As the precise use of the noise is specified, test vectors can still be produced and implementations can be tested against them.
 
@@ -503,7 +503,7 @@ In new deployments, where side-channel and fault injection attacks are a concern
 
 # Security Considerations
 
-The constructions in this document follows the high-level approach in {{XEdDSA}} to calculate the per-message secret number from the hash of the private key and the message, but add additional randomness into the calculation for greater resilience. This does not re-introduce the strong security requirement of randomness needed by randomized ECDSA {{FIPS-186-4}}. The randomness of Z does not need to be perfect, but SHALL be generated by a cryptographically secure pseudo random number generator (PRNG) and SHALL be secret. Even if the same random number Z is used to sign two different messages, the security will be the same as deterministic ECDSA and EdDSA and an attacker will not be able to compromise the private key with algebraic means as in fully randomized ECDSA {{FIPS-186-4}}. With the construction specified in this document, two signatures over two equal messages are different which prevents information leakage in use cases where signatures but not messages are public. The construction in this document place the additional randomness before the message to align with randomized hashing methods.
+The constructions in this document follows the high-level approach in {{XEdDSA}} to calculate the per-message secret number from the hash of the private key and the message, but add additional randomness into the calculation for greater resilience. This does not re-introduce the strong security requirement of randomness needed by randomized ECDSA {{FIPS-186-5}}. The randomness of Z does not need to be perfect, but SHALL be generated by a cryptographically secure pseudo random number generator (PRNG) and SHALL be secret. Even if the same random number Z is used to sign two different messages, the security will be the same as deterministic ECDSA and EdDSA and an attacker will not be able to compromise the private key with algebraic means as in fully randomized ECDSA {{FIPS-186-5}}. With the construction specified in this document, two signatures over two equal messages are different which prevents information leakage in use cases where signatures but not messages are public. The construction in this document place the additional randomness before the message to align with randomized hashing methods.
 
 {{SBBDS17}} states that {{XEdDSA}} would not prevent their attack due to insufficient mixing of the hashed private key with the additional randomness. {{SBBDS17}} suggest a construction where the randomness  is padded with zeroes so that the first 1024-bit SHA-512 block is composed only of the hashed private key and the random value, but not the message. The construction in this document follows this recommendation and pads with zeroes so that the first block is composed only of the hashed private key and the random value, but not the message.
 
