MS Word grammar suggestions

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

@@ -446,7 +446,7 @@ Note that deriving per-message secret number deterministically, is also insecure
 
 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.
+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.
 
 # Conventions Used in This Document
 
@@ -518,7 +518,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-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.
+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. The construction in this document aims to mitigate fault injection attacks that leverage determinism in deterministic ECDSA and EdDSA signatures (see e.g., {{ABFJLM17}}), by randomizing nonce generation. Fault injection attacks that achieve instruction skipping as in e.g., Section 3.4 of {{ABFJLM17}} are not necessarily stopped. It seems to be possible to, at the same time, also mitigate attacks that use first order differential power analysis (DPA) against the hash computation of deterministic nonces in EdDSA and ECDSA (see e.g., {{ABFJLM17}}{{SBBDS17}}). The mitigation in this document agrees with one mentioned in {{ABFJLM17}} and appears to be as effective against the referenced first order DPA attacks as the one in {{SBBDS17}}.