-1

Is it possible to generate random bits (or any bits we decide) to be imported as a private key and then deducting his public key please?

Ideally with a supported Javascript WebCrypto algorithm ( ECDSA, RSASSA-PKCS1-v1.5 or RSA-PSS) or if it's not possible any other algorithm that could be implemented manually.

EDIT (after a downvote):

I don't understood the downvote, if someone want to exprime me his feeling... We are on crypto part, I'm asking a serious question, I believed the private key can't be random and should respect some sort of mathematical curves, and so, can't be what we want. Sorry if this question is a newbie question, but I believed to be on the good part of the StackExchange to ask it, no?

For a more long explanation, the main goal is to generate a private key based on a the user's password derivation, creating(deducing) the public key to send to the server. Then to authenticate, the server send a challenge, the client re-create the private key on the fly and sign the challenge, then the server can be sure it's the good password. In case where the server DB is leaked, it's not possible to brute-force the password. I've explained that in another question.

lakano
  • 51
  • 6

1 Answers1

2

What you are thinking would work (mostly).

Every public key algorithm includes a public/private key generation algorithm; this algorithm takes a source of random bits, and produces a public/private key pair. This algorithm is deterministic, and so using those same random bits a second time will produce the same public/private key pair. So, if you take your password, and feed that as the seed to an RNG (or key derivation function), you can use that output to generate your public/private key, and you're good to go.

My opinion: if you go with this approach, I wouldn't use RSA; its public/private key generation algorithm takes a variable amount of time; I'd use ECDSA (DSA would also work), and if that's too fast, expand the password with scrypt or argon-2 (both of which are designed to be slow password hashing functions, and have parameters to make the password hashing process take the appropriate length of time).

However, there is a problem with the overall protocol; if there is a man-in-the-middle (that is, someone sitting between the valid client and the valid server), he can pass the challenge from the server to the client, and pass the response from the client to the server; at this point, the client is authenticated, and the man-in-the-middle is still listening in (and so later in the conversation, is able to modify traffic without being detected).

My suggestion would be to not use this approach, but instead use something like SRP; that is an authentication protocol that also provides protection for the server database leakage (which you are looking for), and in addition, the valid client and server generates the same key at the end (which the man-in-the-middle does not know); this key can be used to protect (encrypt and integrity check) later traffic, protecting it from the man-in-the-middle.

poncho
  • 154,064
  • 12
  • 239
  • 382