Hacker News Reader

ECDH by itself just gives an /unauthenticated/ session key, and from a 30-second look at the code, CBCrypt appears to be trivially vulnerable to a replay attack in which a malicious server A convinces a standard client to give it a valid authenticator for a session to a different server B.

Nice catch! This looks like a trivial (and thus educationally useful) instance of an unknown keyshare attack.

Take a closer look. The server has a copy of the client's public key on record before the authentication session begins. The server needs to authenticate the client. The server generates an ephemeral ECDH keypair. Now if an attacker manipulates the challenge or key sent to the client, the attacker has neither the server's private ephemeral key, nor the client's private key. So the attacker cannot provide a valid challenge response to the server. The worst the attacker might do is to generate a new ephemeral ECDH keypair and send that to the client instead of the keypair that the server generated - in which case the challenge response would be useless.

Also, "prove you know something secret without exposing it" instantly suggests Zero Knowledge Proofs. That is precisely the problem they solve, and it's a problem orthogonal to encryption.

If you don't know what the PRNG (DRBG more appropriately) is for, you didn't watch the tech video. An asymmetric key generation algorithm can't work from a fixed length seed. You need to stretch the seed to an arbitrary length, because the asymmetric key generator requires a random stream.

Your 30-second look at the code needs more than 30 seconds. If a client connects to malicious server A, the private key it would use for that connection is different from the private key it would use on server B. So malicious server A cannot replay an authentication session on a different server.

If you don't know what the PRNG (DRBG more appropriately) is for, you didn't watch the tech video.

Video is not suited for technical details.

It's not easy to quote / excerpt, to quickly refer back to previous (or later) parts, to take more time over parts that need it, etc; not the way text is.

My default reaction to "you'll understand if you just watch the video", is that someone is peddling bullshit and doesn't want me thinking too deeply.

It's also a really convenient way to deflect when, and this is just a hypothetical here, you were wrong and jumped to conclusions.

> An asymmetric key generation algorithm can't work from a fixed length seed. You need to stretch the seed to an arbitrary length, because the asymmetric key generator requires a random stream.

That may or may not be true for traditional DH. For ECDH it's false. A Curve25519 ECDH private key, for example, is quite literally a handful of random bits. (Depending on how you look at it, it's a 256-bit number with some fixed bits or just 252-ish bits. I say "ish" because I don't remember the exact number of fixed bits off the top of my head.)

Edit: Fixed bogus EdDSA reference. Also, I just looked it up. A Curve25519 private key (http://cr.yp.to/ecdh.html) indeed requires exactly 252 random bits (or the 252-bit output of a secure KDF).

More typically you would use a KDF and simply request the number of bytes that you require directly from there.

Note, however, PBKDF2 has a bug where each additional block of output bytes is recomputed independently, which means the work factor (iteration count of the underlying hash algorithm) is applied separately for each block of output generated. So if you ask for, say, 1,000,000 iterations of PBKDF2-HMAC-SHA256 with 64 bytes of output, you are actually running two separate independent runs of 1,000,000 HMAC-SHA512 under the hood. This allows attackers to derive the output block-by-block instead of having to compute all or nothing, which can increase cracking speed in some cases (see 1Password writeup [1])

More simply, you can use a hash/KDF to produce a single block of seed with all your desired work factor imputed into that one value, and then stretch the seed simply as: for 1..n { hash(seed || n) } to get however many bytes you need to produce your privKey. In other words, 1,000,000 iterations of work for the seed, and a single iteration of work for each final block -- effectively all or nothing.

This will let you reduce the number of primitives to the single hash function you choose, which personally I think is much cleaner than introducing a whole PRNG into the mix.

[1] - http://blog.agilebits.com/wp-content/uploads/2013/07/playing...

> ECDH by itself just gives an /unauthenticated/ session key, and from a 30-second look at the code, CBCrypt appears to be trivially vulnerable to a replay attack in which a malicious server A convinces a standard client to give it a valid authenticator for a session to a different server B.

From looking at their tests and the PowerPoint file in their repo, they mention confirming that the hostname provided by the server in the challenge matches the SSL Certificate. Asking as someone who knows very little about crypto, under the assumption that they validate the hostname and are using TLS would it still be vulnerable to a replay attack?

That's a good question. Are they validating the SSL certificate? Are they willing to predicate the security of the protocol on the soundness of SSL certificate validation? Are they willing to assume that the malicious server and the attacked server have different host names or aren't covered by the same wildcard certificate?

All of these seem like pointless assumptions to have to make when a better protocol wouldn't have this problem in the first place.

In any case, I'm having a little bit of trouble understanding why this thing is useful at all. It helps against an attacker that compromises a server but isn't willing to inject malicious code into the JavaScript served up by the attacker, and attackers who want to target everyone without being detected might actually have that limitation, but more targeted attackers will just modify the JavaScript (unless they have some other deployment scenario in mind).

(Minor correction to my first post: I didn't actually mean "replay attack" -- I meant "relay attack". Whoops, silly typo. Although, now that I think about it, they might be vulnerable to replay attacks, too -- I make no effort to check for that.)

You say that as if existing authentication mechanism aren't predicated on the soundness of SSL certificate validation.

I'm not saying it's right, but as people keep reminding me there's a lot of grey area between 'bad' and 'perfect' and most of the time we don't get anywhere near perfect. 'Better' would be something for a lot of people.

When the SRP code was going around people kept saying "Hey use the javascript library" and for reasons similar to yours I said, "No thanks, when will the browsers support it?"

Because if we're going to use keypairs for authentication, it really should be integrated into the user agent, where it's extremely hard (and hopefully impossible most days) to inject code.

Ad networks get hacked all the time. Probably better than half the sites I visit will pop up a login prompt over the top of the ads, which means somewhere I'm logging in, an ad could very well be trying to get my credentials, and it only takes once for the UA to fail to prevent it and I'm in hot water.

PAKE only authenticates the password and generates a random session key. It doesn't enable the user to encrypt their data for a later session.

If you don't know what the PRNG is for, perhaps a cursory 30 second lookover and then crap all over wasn't enough. ;-) Watch the 9 minute Tech Video, which explains, the asymmetric key generator can't use a fixed length seed; it needs to be a random stream. Also, there's a challenge/response which can only be answered by knowledge of the client's private key, so your comment about the replay attack (I think you meant relay attack) is also incorrect - whichever you actually meant, you're wrong either way.

> PAKE only authenticates the password and generates a random session key. It doesn't enable the user to encrypt their data for a later session.

PAKE can be used to construct all kinds of things. You can generate a key for one session, you can generate a persistent key, you can run a PAKE to authenticate an existing session, etc.

While true, the risk of exposure is significantly smaller if the derived key is different for every site.

The algo can work by the site sending the user their personal salt. The algo will then encrypt the password, use the salt, and send the derived key.

This DOES remove the burden on the user of trusting every site with their password. The problem is quickly the password is only but one of a lot of data hackers look for.

That's not necessarily true; If it can generate multiple outputs for the same input, it could mean that the derivation function exposes something about the secret in the degree or nature of the variation.

It's hard to quantify risk.

Do you rely on the server to play nice, and not present you with fake login boxes, then all bets are off.