The obvious go-to for PFS is DHE (or ECDHE).

But I'm wondering if using tls-srp but with fixed (and therefore can be considered publicly known) credentials can achieve PFS as well. I suspect this is the case, since one of the features of SRP is that you cannot re-compute the session key even if you know the secret.

Background info:

  • I'm working on server and client code using OpenSSL.

  • It already uses tls-srp for its intended purpose: establishing an encrypted channel after authentication.

  • There's now a requirement for an additional PFS only channel, where we explicitly do not want authentication, we just need the encrypted data for each session to be protected.

We could go with DHE, but it would be simpler if we could just re-use tls-srp, but with fixed credentials to bypass the authentication. We control both server and client, we don't have to worry about third party, so there's no problem there. By not going with DHE I believe we also don't have to worry about certificates.

Please let me know if this is not a good idea. Any comments welcome. Thank you very much.


This is not a good idea. But that's not a problem of SRP.

SRP is a Password-Authenticated Key Exchange protocol by which two parties establish a shared secret with mutual authentication through another shared secret. The beauty of the thing is that the initial shared secret may be weak (i.e. a password that human users can remember), and yet the new shared secret is not susceptible to offline dictionary attacks.

A dictionary attack is a brute force attack on a human-compatible secret. The attacker tries "potential passwords" until the right one is found. An offline dictionary attack is a dictionary attack where the attacker has obtained enough information to test passwords at home, without interacting any further with the target systems; e.g., if the attacker has a hash of the password, then he can try passwords by hashing them and comparing with the known hash value. Offline dictionary attacks are powerful because nothing prevents the attacker from throwing more power at the task, through dedicated hardware (GPU, FPGA, ASIC...), rented systems (commercial clouds), or even "borrowed power" (idle machines in a University network, botnets...).

A contrario, if an offline dictionary attack is not possible, then the attacker must use an online dictionary attack, and then things begin to look better because the honest systems can limit the rate at which they respond, or even stop responding after too many failure. This is the behaviour of a smart card with a PIN: after a few wrong PIN, it just locks itself.

The whole point of PAKE is to avoid offline dictionary attacks. Attackers MUST talk with either the genuine client or the genuine server whenever they want to test a potential password. This has a few consequences for your case:

  • PAKE protocols, in particular SRP, naturally provide forward secrecy (also known as PFS). Forward secrecy is about preserving confidentiality of past communications even against attackers who later on manage to steal long-term stored secret values of either or both parties. In the case of TLS-SRP, the only long-term stored secret value is the shared password.

    Suppose that there is a procedure P by which an attacker, after having recorded (passively) a connection, and having later on stolen the shared secret (the password x), can unravel the contents of the connection. Forward secrecy is achieved if such a procedure P does not exist. However, if P exists, then the attacker can turn it into an offline dictionary attack: the attacker just has to "guess" the password x, and try procedure P using that guessed value of x. If it works, then the guessed password x was correct.

    In other words, if a PAKE protocol does not provide forward secrecy, then, mechanically, it does not provide protection against offline dictionary attacks either, so it is not a "true" PAKE protocol. Conversely, good PAKE protocols like SRP necessarily provide forward secrecy.

  • The explanation above naturally extends to the case of a public password. A public password is just a password for which dictionary attacks are really efficient (attackers get it right on first try...). Thus, you still get forward secrecy even if the password is known to everybody.

  • However, all of this relies on important details. The "forward secrecy" property is about an attacker who passively recorded a connection, and tries to decrypt it afterwards. In particular, it says nothing about active attackers.

    If the password is known to everybody, then the attacker may pose as a fake server, or a fake client, or both at the same time; notably, the attacker may run a Man-in-the-Middle attack. Such an active attacker can then intercept connections and see all the data as it flows. Since the MitM still forwards data both ways, the genuine clients and servers will be none the wiser.

This explains why I used emphasis on the "mutual" word at the start of this answer. When you say:

we explicitly do not want authentication, we just need the encrypted data for each session to be protected

then this is a kind of contradiction in terms. What you really mean is either of the following:

  1. you do not want client authentication (but the client must still have some guarantee that it talks to the right server);

  2. your usage context is such that attackers cannot be active.

Passive-only attacker contexts are, in fact, extremely rare, and most people who just assume that attackers can not alter data in transit are merely delusional, and primed for a rude awakening at some point. So we are back to point 1: the client should still be able to know whether it talks to the right server. In SRP, the shared password is the basis for mutual authentication. By making it public, you remove authentication in both directions, and that's too much removal.

There cannot be any notion of authentication if everything is known to everybody. But SRP is based on the idea that the only secret is the shared password. So you cannot get server authentication if that only secret is not, in fact, secret.

If you want an "unauthenticated" communication (server does not know who the client is; but the client still knows who the server is), then SRP is not the way to go. Rather, you will have to use the "normal" SSL/TLS in which the server has a public/private key pair, and the client knows the public key, or learns it dynamically through the server's certificate (the latter implies certificate validation, which is what Web browsers do, but maybe you would have preferred to avoid certificates altogether).

Summary: yes, SRP provides forward secrecy, even if the password is public. But no, this is not a good idea, because forward secrecy is not the only thing you really want; you also need normal secrecy, and that one cannot be maintained against active attackers if you use SRP with a public password.

  • Thank you very much for taking the time for his detailed post. So my understanding is this: While SRP guarantees that the session key cannot be re-computed from the open password, the verifier can. So someone can pretend to be the server on one end, pretend to the the client on the other end, and listen in. PFS is only part of the equation, I can't only depend on that. – evilquesadilla Nov 11 '15 at 19:26


I've reworded the question somewhat and broken it down to "Will OpenSSL's TLS-SRP still provide PFS if all credentials are public?" Let me know if this is contrary to your intentions.

And the answer to that question is "Yes".

The reason is that this question is really the same as asking "Does OpenSSL's TLS-SRP provide PFS?"

Because Forward Secrecy (and AFAIK PFS and FS are synonyms) is defined (by Wikipedia) as:

In cryptography, forward secrecy (FS; also known as perfect forward secrecy[1]) is a property of secure communication protocols: a secure communication protocol is said to have forward secrecy if compromise of long-term keys does not compromise past session keys.

What this does NOT defend you against is an active attacker. If the credentials are public, then you can easily be man-in-the-middled at any time the attacker wishes. But if somebody finds a backuptape of old tcpdumps for example they won't be able to decrypt it, because the long-term key does not disclose the session keys.

Disclaimer: Now I don't know much about SRP. Basically all I know is that it exists.

And this is pretty much an argument from authority here: Knowledgeable people (TM) have said that SRP provides FS. And if it does, then by definition of FS, it MUST be safe from the attack you want to defend against: passive eavesdropping.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.