2

If I understood SRP correctly, its weakpoint is during the registration of a user when sending the verifier to the server.

Let's say the Server knows the PubKey(User) of the User and the User knows the PubKey(Server) of the Server. For authentication the Server sends a random secret encrypted with the PubKey(User) to the user. The user decrypts the secret with his PrivKey(User) and the encrypts the secret with the PubKey(Server) an send it back. After doing so, the Server decrypts the secret with its PrivKey(Server) compares it to the one sent to the User, if correct, user is authenticated.

Would that be more secure than SRP and giving you the same advantage (not storing user passwords) as SRP?

PKEvsSRP
  • 21
  • 1
  • It would probably be better to have the server sign user certificates that it trusts. Then when a user connects the server it checks to see if the user's certificate is trusted. If not then the request is denied. – RoraΖ Oct 06 '15 at 11:51
  • FIDO alliance has the protocols U2F and UAF that does this, public key based challenge-response protocols – Natanael Oct 08 '15 at 15:46
  • Thanks Natanael, that's exactly what i was thinking about. – PKEvsSRP Oct 23 '15 at 10:20

2 Answers2

2

When you say,

Let's say the Server knows the PubKey(User) of the User and the User knows the PubKey(Server) of the Server.

you are presenting a much easier problem than SRP needs to solve. Quite simply, if each party already knows the other party's public keys, then we are done. All mutual authentication and key exchange is then easy. No secrets (such as the SRP verifier) would ever need to be transmitted nor would any secrets beyond ones own private keys would need to be stored.

SRP and other PAKEs (Password-based Authenticated Key Exchange) systems become unnecessary in a world in which communicating parties already know each others public keys.

Jeffrey Goldberg
  • 5,839
  • 13
  • 18
  • What i don't get is, why one needs SRP then. Every Service should be able to provide his publicKey during Registration, isn't it? If we assume that the client is able to generate a KeyPair from a Passphrase, SRP should not be the choice for Auth, right? – PKEvsSRP Oct 23 '15 at 09:26
  • 1
    @PKEvsSRP HomeKit makes good use of it - the user may be prompted to type an 8 digit passcode - ~26.6 bits of entropy. SRP is used to stretch that entropy to prove a shared low entropy secret for pairing. You might want to ask that as a question on this site for a better or more complete answer. – Iiridayn Jan 22 '19 at 00:25
  • @PKEvsSRP Okay, so you client generates a KeyPair from a passphase. Then what? You still need registration. The server needs to agree on which keys to use, which is essentially "password-authenticated key agreement" (PAKE). SRP is just one way of doing PAKE. – stewSquared Oct 23 '21 at 04:26
2

The whole point of Password-Authenticated Key Exchange mechanism is to enable establishment of a shared secret when the two parties do not have better mutual authentication mechanism than a shared low-entropy secret (the password).

If the client can know, with decent certainty, the server's public key, then the client can simply use that knowledge to open a secure tunnel with the server and send the password in that tunnel. This is what happens all the time when some human user with a Web browser connects to a HTTPS server, and types his password: the client authenticates the server thanks to its certificate, and that's enough to power up a SSL, at which point the password can be sent "as is" since the client has some guarantee that it is talking to the expected server.

Thus, if you begin by assuming that the client knows the server's public key, then there is no need to use SRP at all. Moreover, if you assume that the server also knows the client's public key, then you no longer have to use a password at all.

Consider password registration: prior to that operation, there is no "shared secret" between client and server. Yet, the client will thereafter use that knowledge of the shared secret to authenticate the server. This means that there must be some other authentication method to be used at registration time, by which the client can make sure that it is setting things up with the genuine server.

You may envision the case of a client who registers through a SSL-powered Web interface (server certificate is used by the client, to make sure that it talks to the genuine server); then the registered password will be used thereafter, e.g. from a client device where certificate validation cannot be done conveniently.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • So if a Server provides his publicKeyS during registration and a client generates his keypair, sending her publicKeyU encrypted with publicKeyS to the Server (via https for extra security) we can build up an authentication without sharing any secrets, right? Because after this form of registration, the user can generate his privateKeyU inside the Client with his Passphrase and as the Server knows the publicKeyU he can check if the User is the one he is claiming. – PKEvsSRP Oct 23 '15 at 09:18
  • What i don't get is, why one needs SRP then. If we assume, that every Server could just provide his publicKey during Registration and every Client is able to generate a KeyPair from a Passphrase. – PKEvsSRP Oct 23 '15 at 09:23
  • You will need a way to _deterministically_ generate a keypair from a passphrase, and you will need all of the machinery of public keys. SRP and other PAKEs are "public key lite" and so are simpler than using general PK mechanisms. – Jeffrey Goldberg Oct 23 '15 at 21:20