+1 to what @bmastenbrook said. @BRIAN_____, people usually convert public keys from X25519 to Ed25519, to use a single key pair for both encryption and signature (I never am comfortable with this idea)
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
-
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.