Hot answers tagged

12

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

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

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


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


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

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


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

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

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


2

The point of SRP is to remove the need for the SSL/TLS certificates. With SRP integrated into SSL/TLS (as per RFC 5054), you get mutual client/server password-based authentication and can do without any of the dreadful certificate business; and yet the protocol is still resilient to offline dictionary attacks. If your SSL/TLS still uses a server certificate ...


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

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

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

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

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

tl;dr don't trust HTTPS alone use it as one part of layered security and do use SRP always. bcrypt the password as input to SRP for additional protection. AES encrypt the verifier in the database for additional protection of the offsite backups. Hashing the password with bcrypt on the client only makes it harder to recover the password if the servers ...



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