-1
$\begingroup$

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.

Improve this question
$\endgroup$
  • $\begingroup$ Not only is it possible, that's basically how the key generation algorithm for any encryption scheme works. $\endgroup$ – fkraiem Nov 8 '17 at 3:11
  • $\begingroup$ I'm assuming you mean "deducing" rather than "deducting"? $\endgroup$ – Kritner Nov 8 '17 at 13:23
  • $\begingroup$ @Kritner Yes surely, sorry for my level of english. I create the private key and want to guess the public key associated to this private key. $\endgroup$ – lakano Nov 8 '17 at 14:13
  • $\begingroup$ just wanted to make sure, cuz that could potentially really change someone's understanding of the question :) $\endgroup$ – Kritner Nov 8 '17 at 14:14
  • 1
    $\begingroup$ I can only guess, but the downvote might be because you clearly don't know much about public key cryptography, because that is part of the key generation process. If you don't know that, then you probably have not studied the algorithm at all. $\endgroup$ – tylo Nov 8 '17 at 14:41
2
$\begingroup$

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.

Improve this answer
$\endgroup$
  • $\begingroup$ Thank you @poncho for your answer. I already uses SRP, but it's not enough. I've already planned to use Argon2id in browser ( but may be switch to multiples loop of PBKDF2 ) , also I have some knowledge to mitigate the MITM risks (HTTPS + HSTS + HPKP + TLS v1.2 minimum). We also have users with U2F devices, and working on the Web AuthN API to use FIDO UAF/U2F. $\endgroup$ – lakano Nov 8 '17 at 14:50
  • $\begingroup$ SRP is not good because we can brute force a user password if our DB is leaked. My goal is to prevent this. $\endgroup$ – lakano Nov 8 '17 at 14:51
  • $\begingroup$ About ECDSA P-256, it's exactly the algorithm where I'm trying to execute my idea, because it's fast and short. But the Web Crypto API doesn't accept to import my generated JWK private key ( I can't deal with RAW format, it's may be the problem ), the browser only answer the error « Data provided to an operation does not meet requirements » ... It's the reason of my question. But if you're sure it's possible, then my problem is my code, and not the ECDSA algorithm. $\endgroup$ – lakano Nov 8 '17 at 14:56
  • $\begingroup$ You are not going to avoid that unless you have some other way of limiting access to the verifier. The one you are talking about now doesn't allow for verifying the public key and seems to rely solely on the server. $\endgroup$ – Maarten Bodewes♦ Nov 8 '17 at 14:56
  • $\begingroup$ @MaartenBodewes Limiting access to the verifier is of course what every sysadmin working on, but just look Yahoo!, Equifax,LinkedIn etc, every month there is DB leaked. So, my idea permit to only store a public key on the server side to solve this problem. $\endgroup$ – lakano Nov 8 '17 at 14:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.