3 ms·
I don't understand the second line of your pseudocode -- I read the description as not having any ("external") random bytes, just the PRNG initialized from the
by dchest 11y ago
I don't understand the second line of your pseudocode -- I read the description as not having any ("external") random bytes, just the PRNG initialized from the seed derived from scrypt:
"CBcrypt combines publicly known authentication factors (typically username and server id) with secret factors (password), applies a rate-limiting work function such as scrypt or pbkdf2, to deterministically generate a random seed. This seed is then used in a pseudo-random number generator (prng), and the prng is used as the basis for generating a public/private keypair."
EDIT: ah, got it (libc! :), secureSrand means "initialize PRNG with seed", so we're talking about the same thing.
- tptacek 11y agoYes, "srand" was my shorthand for that, but since I just invented that shorthand, I'm not surprised it was confusing. Also: is it safe to use a secret-seeded DRBG as a CSPRNG for ECDH keygen? The time it will take to generate the ECDH key will be secret-dependent, right? (I'm sure it doesn't matter in this case. Just curious about the general case.)
- dchest 11y agoI think it's safe, but we need real cryptographers to figure this out (does Matthew Green approving miniLock count?). With proper Curve25519 implementations key generation timing shouldn't be secret-depended: it's the same scalar multiplication (crypto_scalarmult_base).