Explain the constuction better and what it achieves

Explain the constuction better and what it achieves

Remove incorrect sentence that context is in first block

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

@@ -520,7 +520,7 @@ In new deployments, where side-channel and fault injection attacks are a concern
 
 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.
+{{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., https://eprint.iacr.org/2017/975.pdf), 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}}.
 
 Another countermeasure to fault attacks is to force the signer to verify the signature in the last step of the signature generation or to calculate the signature twice and compare the results. These countermeasure would catch a single fault but would not protect against attackers that are able to precisely inject faults several times {{RP17}} {{PSSLR17}} {{SB18}}. Adding an additional sign or verification operation would also significantly affect performance, especially verification which is a heavier operation than signing in ECDSA and EdDSA.