Hot answers tagged

13

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


12

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.


10

Oh, and while you did not specifically ask about this, there is another point I believe that is important to highlight; DH and SRP are different protocols, and have different requirements on the generator they use. In particular, taking a generator that is designed to be used securely within DH can void the security properties of SRP. Here's what's going ...


10

Well, yes, that is generally good advice about DH. Here is some background on this: support you were given a value $g^x \bmod p$, and you were also told that $1 \le x \le A$ for some value $A$. If so, then there are several known attacks (such as Big Step/Little Step and Pollard's Rho) that can recover $x$ in about $\sqrt A$ steps. If we have as our ...


7

The security goal behind SRP is that an attacker that could either pretend to be a client (and attempt to log into a server that knows the key), pretend to be a server (and allow clients that know the key to attempt to log in), or actively monitor (and modify) the communications between a valid client and a valid server, would learn nothing from an exchange, ...


6

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


5

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


5

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


5

No, since finding $a$ allows offline checking of passwords. $\:$ No, although I can't back this part up.


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


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

From the RFC: SRP also supplies a shared secret at the end of the authentication sequence that can be used to generate encryption keys. It seems from my quick look over the RFC that that shared secret is the premaster secret, so you are correct.


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

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


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

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


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


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

SRP protocol is quite abstract so to provide matching implementation for version 6a you need to know following: N, g - group parameters H - hash function, there can be different hash functions used for different values how is private key x calculated how is shared session key K calculated how are evidence messages (M1, M2) calculated In addition you need ...


2

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


2

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.


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

"Would it be possible for an attacker to launch an offline dictionary/brute-force attack on the B public key: ..." That is possible if and only if the attacker can distinguish b's distribution from the uniform distribution on {0,1,2,3,...,N-3,N-2}. $\:$ If so, an attacker could compute verifiers v for candidate passwords, subtract kv from B mod N, and ...


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


2

I know PBKDF2 is essentially "useless" against anyone with a GPU rig and I have read that bcrypt is "useless" to anyone with an FPGA setup. Neither is useless. Newer alternatives like scrypt and the eventual PHC winner make better use of the defenders' resources, but even a thousand iterations of PBKDF2 is useful, compared to doing nothing. If you ...


2

The property of SRP is that: If the attacker is a passive listener to an exchange between a client and a server, he learns nothing about the shared password If the attacker is a participant in the exchange with either a client or a server with the password (or modifies the exchange between the client and the server), the attacker learns nothing except for ...


2

As mentioned in the comments this is a standard problem not unique to SRP and not really about the cryptography of SRP. So this question would probably be better posted on 'security.stackexchange.com' as it is more of a generic problem. Fundamentally setting a shared secret like a regular password or a password verifier over a public network has its ...


1

Look at where $a$ is used in the protocol: The user calculates the public $A = g^a$ using it. The user computes the session key as $K = H(S)$, with $S = (B - kg^x) ^ {a + ux}$. An attacker should never find out $S$, because even if the session key $K$ leaks due to e.g. a flawed encryption algorithm, she would only know the hashed value. So knowing or ...


1

The multiplier parameter $k$ is different between SRP 6 and 6a. You can see that RFC 5054 calculates it using a hash of the domain parameters (modulus $N$ and generator $g$), so it is using SRP 6a, as opposed to SRP 6 where $k$ is constant. Likewise, in section 6.2.1 of IEC 11770-4 – the October 2005 draft at least – the equivalent value $c$ is defined as a ...



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