Is this the normal way it's done? I thought it was normal to try to implement x25519 and then implement Ed25519 as a hack on top of it. If the hacky way isn't normal then it's probably less of a concern.
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
-
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?
- 2 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.