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
(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.