Pretty good thread . Thanks for the chat @lvh.https://twitter.com/lvh/status/1005085612607787009 …
OK, let's jump ahead to the thing I want to verify: For these kinds of fault attacks, what is the value of checking that the result is on the curve? If the bit flipping is actually modifying the private key scalar itself then it doesn't help AFAICT, but how about otherwise?
-
-
EdDSA signing requires two scalar mults, one to compute the public key (which can be cached) and another to compute R. If adversary can cause any faults in these computations, and also learn the correct value of the public key or R, they can compute the private key
-
Point-on-curve check can detect certain faults, but it doesn't help if the adversary can actually flip a single bit of any scalar
-
Something to think about: suppose there's a deterministic carry mispropagation bug that can be triggered with 1% of the scalar values. Is it possible to extract the private key?
-
Point-on-curve check can detect mispropagation bugs, but I'm not sure whether these bugs leak the Ed25519 private key. Since the bugs are deterministic, the adversary cannot obtain two different R values for the same nonce and message.
@jurajsomorovsky thoughts? -
I think this is probably something beyond what's reasonable to solve on Twitter. What I'm really wondering is what are the near-zero-cost countermeasures that can reduce the likelihood of a Rowhammer-like attack the most, ideally without randomization the scalar mult.
-
We spent a lot of time on this question, and concluded that randomization is safest. Other options: 1/ sign then verify (expensive, detect many, but not all faults) 2/ sign twice and compare sigs (cheaper than 1/, but detect fewer faults)
-
3/ Design the protocol to take signatures out of the critical path w.r.t. performance and then do #1. Anyway, how did you randomize the nonce? I'm doing it the BN_generate_dsa_nonce way for now, e.g. https://github.com/briansmith/ring/pull/662 … for ECDSA.
-
FWIW my take on this was to provide the private key and message as additional input to the HMAC-DRBG, which ends up being pretty similar to the RFC6979 path:https://github.com/naniteproject/sweet-b/blob/master/src/sb_sw_lib.c#L1330 …
- 9 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.