If you care about fault injection attacks then I don't know that any variant of Ed25519 is good to use, because Ed25519 is usually implemented using x-coordinate only multiplication so you can't verify that the result is on the curve. (IDK if that's necessary or sufficient yet.)
-
-
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 …
-
I have implemented a version that does that too. I think it makes more sense if all the randomness needs of the library/app go through the DRBG. I might end up doing that eventually, but it requires more work in other parts of the library & I want to explore at least 1 alt 1st.
-
Right, I was designing for a case where there's one common DRBG. But even if not, I'd probably just seed a DRBG off of the provided RNG and then use that, with the idea being to keep the code paths as simple and similar as possible.
-
Yeah, that's what I originally implemented. But, then we'd waste a lot of digest operations on prediction resistance and/or backtracking resistance that isn't helpful (IIUC). I looked at doing the Hash DRBG too but the way the state is combined with bignum addition annoyed me.
-
(Why isn't prediction resistance and backtracking resistance helpful: In that situation the DRBG state is sitting right next to the private key, so if you can steal the private key as easily as you could steal the DRBG state.)
-
I can see situations where I'd want to optimize this, but in my case, the actual point multiplication is by far dominant on my little MCUs, and I'm happy to burn a few extra cycles on a known, well-analyzed DRBG construction
- 4 more replies
New conversation -
-
-
The thing I don’t understand in this discussion is why randomizing the nonce (by inserting random data into the hash) is insufficient?
-
Ideally the library implementing EdDSA would implement countermeasures that work regardless of the message content, and which are 100% compatible with the standard.
-
Doesn’t Trevor’s suggestion meet those properties? The randomness is independent of the message, and only used to generate the nonce, which is known only to the signer.
-
The standard says the signatures are deterministic so you have to generate the same signature given the same inputs.
-
I see. Do you know of any higher-level protocols/systems that rely on this property?
-
You can take a look at our paper, https://eprint.iacr.org/2017/1014.pdf , Section 7. There we analyze different protocols and their usage of EdDSA. tl;dr: Most of the protocols generate fresh random values which are signed along with the message, so you cannot enforce signature "re-computation"
-
If you can flip buts with Rowhammer then depending on PRNG implementation you might be able to reset PRNG state to replay the same output twice in a row, e.g. many ChaCah20-based PRNGs are used. This would create problems both for randomized EdDSA and for apps w/ nonces in msgs.
-
Further, if you can flip a bit with Rowhammer then you could flip the "TLS handshake is complete" flag and cause the app to accept unauthenticated/unencrypted input and/or write unencrypted output. https://bugzilla.mozilla.org/show_bug.cgi?id=919877 … shows such a magic bit exists/existed in real life.
- 5 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.