Hot answers tagged

16

SRP needs more than a group, it requires a field. See the specification: second user sends $B = v + g^b$. This requires two operations, addition and multiplication. You cannot trivially slap that onto a group which provides only one operation, such as elliptic curves. Variants of SRP which use elliptic curves have been proposed, but do not seem to have ...


15

If k is a constant, such as 3, it becomes possible to select a pair (N,g) such that the discrete log of k to the base g is known, which would enable the two-for-one guessing attack again.


9

When I learned about SRP we were told it wasn't seeing much deployment due to possibly infringing on EKE patents. Network Computing had this to say in 2002: Standards groups have made several attempts to induce Lucent to talk about its EKE patent -- to no avail. Even with Lucent's silence on the topic, few vendors have been willing to use SRP. To further ...


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 ...


7

The SRP paper has this point in its list of security properties:   6. If the user's password itself is compromised, it should not allow the intruder to determine the session key K for past sessions and decrypt them. Even present sessions should at least be protected from passive eavesdropping. The following section is titled Reduction to Diffie-...


6

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

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


5

Yes, you can and use a slow hashing function when constructing the verifier. I would recommend using PBKDF2, as it is designed for this purpose. In fact, Wikipedia says: $v$ is the host's password verifier, $v = g^x$, $x = H(s,p)$. Using of functions like PBKDF2 instead of $H$ for password hashing is highly recommended. Thus, you could use $x=\text{...


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

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 > ...


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

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

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 ...


4

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 ...


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

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.


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

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

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

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

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 ...


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