# Tag Info

9

The first protocol for password authenticated key exchange that appeared in the crypto community was the Bellovin-Merritt scheme (see also this survey page 4). This protocol is very simple, and might actually suit your need: is is exactly a Diffie-Hellman key exchange, in which the flows are encrypted with a block cipher (using the common password as the key ...

9

As has already been commented: The fact that you can intercept and relay all messages does not actually constitute an attack on the protocol because you do not know the shared key afterwards. If the protocol partners encrypt their traffic with that key you cannot eavesdrop on it. If this was an attack on the protocol none of the network hardware that is ...

8

Issues are that SRP is only useful with a trusted implementation of it on the side where the password is keyed-in. And when you start bringing that by HTTPS from the server, then two things become weak security links: unwarranted hope that the user won't key-in the password unless the green lock is there at the left of the appropriate domain name; the ...

6

One of the design goals of SRP is that it should be a zero-knowledge authentication protocol. This is to say, even the legitimate server should not be able to learn anything about the user's password (other than what it could learn using a generic brute force attack on the verifier). SRP also assumes that the user may not be able to remember anything ...

6

Building upon Geoffroy Couteau's answer, there are possible fixes to the issues addressed there. The Bellovin-Merrit (from section 3: EKE using exponential key exchange) scheme is roughly like this: - Alice and Bob agree on a safe prime modulus and a generator of the group (which has a problem of leaking its Legendre symbol) - Alice and Bob do a normal DH ...

5

Solving a 256-bit discrete log is absolutely doable, and quite quickly, these days; there are public tools that can do it, though they may require some expertise to use. On that note, even a 1024-bit modulus is not particularly conservative: it is generally agreed that well-funded organizations today could break logs of that size as well, but at a very ...

5

In SRP, v = g^x means $v = g^x \mod p$, i.e. exponentiation modulo a large prime $p$.

5

Perhaps it is not widely used in TLS, but it is actually deployed in Apple iCloud (Page 49 in Apple security whitepaper), 1PassWord (Page 57 in 1PassWord security whitepaper), ProtonMail (In this blog) etc. for authentication purpose.

5

This is a good question, but I would consider hardcoding a known good group. There does not seem to be an advantage to letting the server decide if you can afford to use high enough parameter values. The SRP paper lists the following checks: "n is a large safe prime" (this is your first three points) "g is a primitive root of GF(n)" (your next point) "A > ...

5

I see three main reasons why PAKEs are not widely used yet: The lack of IETF standards. SRP has limitations discussed in the link @fgrieu posted above. Many PAKE protocols have been designed, but they lack a convincing security proof, or properties some applications may expect. This is being solved as we speak. The CFRG is currently having a selection ...

4

SRP with the user's key = 0 is identical to DH. SRP with a publicly known key is identical to DH with a constant multiplier. For private key $x$, user ephemeral value $a$, server ephemeral value $b$, and $u$ derived from shared values, SRP ends up calculating the value $g^{ab + uxa}$ (which is then typically hashed to get the shared key). If $x$ is zero, ...

4

RFC 2945 By Tom Wu the SRP inventor uses x = H(s, H(I, ":", p)) where I is the username demonstrating that can do anything you like to the stretch the password such as prefixing the username then hashing it. So stretching the user entered password before putting it into function using PBKDF2 would increase the time taken for a dictionary attack with no ...

4

When using a Discrete Logarithm based scheme, such as SRP, the rule of thumb is to always use private exponents with a bit length twice the desired security strength. Hence, a 128 bit exponent $a$ will at most give you 64 bits of security. If you want 128 bit security, you need (at least) a 256 bit exponent. This is because the algebraic structure of the ...

3

You can pre-compute and hardcode N and g into your client and server. There's no harm in doing this. I do not believe that using per-user N will provide any additional security. It is common practice to define SRP parameters for a particular application or (larger) protocol, see e.g. RFC 5054.

3

The purpose is to prevent a two-for-one guessing attack, where an active adversary, impersonating the server, can test two password guesses per attempt. The attack and why the multiplier prevents it is described in Section 2 of the SRP-6 paper (ps). (According to MacKenzie, it was discovered by Bleichenbacher.) In brief, the attack goes like this: Instead ...

3

I don't see how the server can directly learn $x$; what a server would be able to is perform a single exchange with the client (recording the initial parts of the protocol), and then go through a dictionary, and test various passwords (that is, various possible $x$ values), and realize when he finds the right one. The idea here would be to select a prime ...

3

In the introduction of the Logjam paper, it is stated that After a week-long precomputation for a specified 512-bit group, we can compute arbitrary discrete logs in that group in about a minute. So it seems that what it actually does is attack the discrete logarithm problem, so any discrete-logarithm-based system which uses a common prime should be ...

3

As pointed by the question, in SRP an attacker knowing the verifier can impersonate the server. That's not against the security objectives of SRP. To carry the attack, the attacker also needs to know the salt, but it is public and can be obtained from the server. With both verifier and salt, the attacker then behaves with respect to the client just as the ...

3

Yes (and it is an explicit goal of SRP; perhaps not as advertised as such) The only attack that SRP allows is for the faux server to take a guess at the password, and then attempt to allow the client to login based on that guess (and if the client thinks he succeeds, the guess was correct). Given that we assume that the password was strong enough to make ...

3

The server's data is public That assumption makes the idea of a PAKE undoable. If the attacker has access to all the server's data, here's what he can do: clone the server, place the clone in his lab, and then have his client perform attempted negotiations based on all the passwords in his dictionary. Because the clone works exactly like the original ...

2

There is an explicit RCF 5054 which uses SRP to negotiate a shared key for a TLS connection. There are also hooks for OpenSSL to be able to use SRP to setup an SSL connection without using certificates using the SRP generated shared session key.

2

While I think this is changing very recently with expiration of additional patents and SRP included with OpenSSL one of the central problems is compatibility with existing authentication databases. NT OWFs, unix crypts, directory server hashes..etc everything but plaintext passwords (e.g. plaintext reversibly encrypted on disk) are incompatible with SRP. ...

2

To be useful, it needs to be implemented in browsers, so that the user types in their password in an area that is not accessible to JavaScript, like the URL bar. And nobody had done that. There is also a huge industry that tries to prevent and deal with phishing. Phishing is by far the greatest source of security problems today. SRP would kill phishing ...

2

Most likely, the answer is ROI. Implementing SRP costs time and money. What do you get for what you pay? You could as well ask why SCRAM (RFC 7677) is not used, while we're at it. Or why client X.509 certificates are not more widely used. I believe you need to perform a bit of threat analysis to understand this. (From now on, I am assuming secure network ...

2

Yes, it's okay. This is actually mentioned in passing in the SRP 6 design paper. Previous versions used a random $u$ where an attacker who saw (or could predict) it before revealing $A$ could compute $A = g^a v^{-u}$ and use this to effectively cancel out the long term secret. With $u$ derived from a hash, even if the attacker saw $B$, the dependence of $u$ ...

2

PBKDF2 can produce output of arbitrary length. With HMAC/SHA-512 it does so in 512-bit chunks, but it is not restricted to 512 bits. If you need more bits then you can have more. If you want to use the same password for authentication and for encryption, then the proper way is to "isolate" them from each other. I suggest the following: for the user password ...

2

Suppose the server did not include $v$ in the computation of $B$. In such case the following events have happened: The server has sent a salt value $s$ to the client. We might assume it is authentic (because it is easy for the fake server to get it from the real server). The client re-calculates its long term private key $x$ such that $v = g^x$. The client ...

2

It seems like a better solution would be to have the server that is providing the Javascript file, also provide a random seed. The Javascript can then use that random seed (and anything other maybe-random bits it can scrounge up, such as the output from Math.random()) to see a cryptographic PRNG, and then use the output of that crypto-PRNG for generating s, ...

2

Being able to solve the discrete logarithm in SRP-6 allows an eavesdropping attacker to dictionary attack the password. It will not directly reveal a strong password or its hash. It requires the attacker to observe a successful authentication, $B$ alone does not suffice. The attacker eavesdrops $s$, $A = g^a$, $B$ and $M_1$. The attacker solves $a$ from $A$....

Only top voted, non community-wiki answers of a minimum length are eligible