0
$\begingroup$

This is a question sparked purely by curiosity, wanting to understand a little more about cryptography and authentication. Thanks in advance to anybody taking their time to answer.

Instead of salting and hashing a password, sending it to the server to authenticate yourself, could something like this work? A client generates a private/public key pair from a password and random salt. The public key and salt is stored by the server. For each login the server sends the salt, and a randomly generated value for the client to sign. The client regenerates the private key from the password and salt, then signs the randomly generated value and sends that to the server. The server verifies the signature with the corresponding public key.

To slow down a brute force attack, a key must be derived from the password and salt using a slow KDF, before generating the private/public keys.

Alternatively the server can require the client to derive a key from the randomly generated value, using some slow KDF, before it is signed – although this, to me, seems less ideal than just slowing down the key derivation. To save on server resources when verifying the signature, one can use a Proof of Work style mechanism instead of a slow KDF where the client must find a nonce such that hash(randomly_generated_value + nonce) > some_set_difficulty, then the nonce is signed and sent to the server to be verified. The server may even vary the difficulty, say increasing the difficulty for each unsuccessful login attempt.

What would be some advantages and disadvantages of such a scheme? I suspect exposing the salt on every login attempt would be an issue.

Improve this question
$\endgroup$
3
  • $\begingroup$ While it would work, I can't see the benefits of using this vs. using a slow hashing algorithm such as bcrypt? $\endgroup$
    – limeeattack
    Apr 4, 2022 at 10:34
  • 2
    $\begingroup$ Using password + good PBKDF to encrypt your private key and storing it in a safe place, as in SSH does essentially the same thing, without exposing your salt to potentially unsafe network. Storing it in a trusted place which you can access via a secure network and using that to authenticate to this server over insecure channel would be better $\endgroup$
    – Manish Adhikari
    Apr 4, 2022 at 11:27
  • $\begingroup$ One problem with this is that generating a private key from any random seed is remarkably non-trivial. If you never change the deterministic algorithm then you're OK, but that means that 1. the RNG doesn't change, that 2. the bit extraction never changes and 4. that the key generation doesn't change and 4. that the bits are retrieved from the RNG always in the same manner. Some of this might seem trivial, but remember that e.g. RSA key pair generation requires 2 random primes, and that there are many ways to generate those. $\endgroup$
    – Maarten Bodewes - on strike ♦
    Apr 5, 2022 at 15:01

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.