Skip to content

Commit

Permalink
Update draft-irtf-cfrg-det-sigs-with-noise.md
Browse files Browse the repository at this point in the history
#2 added security considerations for re-using Z in the two steps of Hedged ECDSA, added ack to Håkan and Niklas.
  • Loading branch information
ethorm authored Mar 14, 2024
1 parent fdb9f05 commit 30a1d47
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion draft-irtf-cfrg-det-sigs-with-noise.md
Original file line number Diff line number Diff line change
Expand Up @@ -525,7 +525,7 @@ In new deployments, where side-channel and fault injection attacks are a concern

The constructions in this document follow 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 need not be perfect but SHALL be generated by a cryptographically secure pseudo random number generator (CSPRNG) 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}}.
{{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}}. The random bytes Z are re-used in step d and f of Hedged ECDSA to align with HMAC_DRBG (see Section 3.3 of {{RFC8391}}). This may make certain DPA attacks easier than if randomness had been sampled fresh for each respective step. Note however that V is updated between the steps and that the secret key x is processed in a new input block of the hash function after processing V and Z in each respective step.

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.

Expand Down Expand Up @@ -593,9 +593,11 @@ The authors would like to thank
{{{Carsten Bormann}}},
{{{Taylor R Campbell}}},
{{{Quynh Dang}}},
{{{Håkan Englund}}},
{{{Janos Follath}}},
{{{Phillip Hallam-Baker}}},
{{{Chelsea Komlo}}},
{{{Niklas Lindskog}}},
{{{Ilari Liusvaara}}},
{{{Danny Niu}}},
{{{Jim Schaad}}},
Expand Down

0 comments on commit 30a1d47

Please sign in to comment.