Tag Info

Hot answers tagged

11

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


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

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


2

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


1

Short: SRP. For encrypted key exchange you need to add key confirmation to get challenge-response authentication. These all are password-authenticated key exchange (PAKE) mechanisms. These mechanisms end-up into peers sharing an agreed key, which is only the same if the password agreement was successful. Challenge-response authentication is usually ...


1

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


1

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


1

But this proof value must be something both the client and the (legitimate) server can compute, and thus it must be entirely determined by: values chosen by the client and sent to the server during the authentication process, values chosen by the server and sent to the client during the authentication process, and the password and/or the ...


1

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



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