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
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
-
Do we have a good analysis of the behavior of HMAC DRBG when it isn't properly seeded? I know that Hash DRBG actually has/had problems when it was not properly seeded and then secret stuff is put into the additional data, which is exactly the scenerio we're concerned about here.
-
Good question. In this case I was looking for "good if properly seeded, and no worse than H(key || message) if badly seeded". I don't have a good analysis to show this, but even Hash DRBG should achieve this property, shouldn't it?
-
IDK. I found https://crypto.stackexchange.com/a/19277 before and I also found another thing, that I can't find now, that said Hash DRBG has problems when entropy is provided only through "additional info".
@matthew_d_green wrote that answer & co-wrote the HMAC-DRBG proof paper so maybe he knows. -
Obviously, RFC 6979 itself is the worst-case scenerio (other than an actively malicious seed) for a poorly-seeded HMAC DRBG, so I guess analysis of RFC 6979 would be good to read. Still, w/o the need for backtracking/prediction resistance it seems overkill adding ~5-10% overhead.
End of conversation
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.