CBCrypt: Encrypt from the client rather than send passwords to servers

Re:CBCrypt: Encrypt from the client rather than send passwor... by tptacek on Tuesday October 06, 2015 @01:44PM (#10340783)

It looks like the client generates:

    S <- scrypt(zeroes, 
           SHA2(name, pw, host))

    secureSrand(s)

    keypair <- keygen(ecdh, secureRandom)

The client sends the pubkey to the server, the sever sends nonce challenges to the client.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by dchest on Tuesday October 06, 2015 @02:47PM (#10341349)

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.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by tptacek on Tuesday October 06, 2015 @02:52PM (#10341386)

Yes, "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.)

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by dchest on Tuesday October 06, 2015 @03:02PM (#10341459)

I 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).

[ Parent | on HN ]