Re:Show HN: ccPing, a secure messenger
by KMag on Friday December 13, 2013 @10:58AM
(#6901136)
Oh, and the right way for Alice and Bob to prove to each other that the holders of their public keys both know the secret password is to use an Augmented PAKE [1] (Password Authenticated Key Exchange) protocol, replacing the password with Scrypt( Concatenate(Alice's public key, Bob's public key), Password ). (The concatenation of the public keys is used for the Scrypt salt.) That way, at the successful conclusion of the Augmented PAKE exchange, Alice and Bob haven't proved to each other knowledge of the password, but rather have tied the proof to their two public keys, and each can be assured that the holder of the other public key knows the password. If there's later a flaw found in the Augmented PAKE algorithm you choose that leaks the "password" used for the Augmented PAKE protocol, at least you've only leaked a memory-hard password hash of the real Password.
Don't get creative and start rolling your own zero-knowledge proof of passwords here. It's really easy to get wrong. Use a very-well peer-reviewed Augmented PAKE algorithm.
THE NAIVE WRONG WAY for Alice to prove to Bob that she knows the Password (but might look good at first glance) is for Alice to send to Bob HMAC(Password, Alice's Public Key) because then if Bob doesn't know Password, he can still start bruit-forcing guesses without further interaction with Alice. On average, it will take the Stasi an afternoon to bruit-force Password after pretending once to be Bob, and after that they can impersonate Alice when talking to Bob. It's very unlikely Alice will ever mention to Bob the one failed authentication, and nearly impossible that she'll mention it within the window of time they have before the Stasi bruit-force the password.
Use an Augmented PAKE instead of a balanced PAKE, because you should use an Augmented PAKE for users to authenticate themselves to you, and that way you can share one implementation for both purposes and expose yourself to half the potential bugs. With a Balanced PAKE, if an attacker gets read-only access to your server's password store, they could immediately authenticate themselves to your service and upload more public keys as the user. An Augmented PAKE in this case would slow down an attacker by forcing the attacker to bruit-force the passwords, and would completely save the 1% of your users who use passwords with 80 or more bits of entropy.
[1] http://en.wikipedia.org/wiki/Password-authenticated_key_agre...
Don't get creative and start rolling your own zero-knowledge proof of passwords here. It's really easy to get wrong. Use a very-well peer-reviewed Augmented PAKE algorithm.
THE NAIVE WRONG WAY for Alice to prove to Bob that she knows the Password (but might look good at first glance) is for Alice to send to Bob HMAC(Password, Alice's Public Key) because then if Bob doesn't know Password, he can still start bruit-forcing guesses without further interaction with Alice. On average, it will take the Stasi an afternoon to bruit-force Password after pretending once to be Bob, and after that they can impersonate Alice when talking to Bob. It's very unlikely Alice will ever mention to Bob the one failed authentication, and nearly impossible that she'll mention it within the window of time they have before the Stasi bruit-force the password.
Use an Augmented PAKE instead of a balanced PAKE, because you should use an Augmented PAKE for users to authenticate themselves to you, and that way you can share one implementation for both purposes and expose yourself to half the potential bugs. With a Balanced PAKE, if an attacker gets read-only access to your server's password store, they could immediately authenticate themselves to your service and upload more public keys as the user. An Augmented PAKE in this case would slow down an attacker by forcing the attacker to bruit-force the passwords, and would completely save the 1% of your users who use passwords with 80 or more bits of entropy.