1

I've been considering switching from SRP to OPAQUE, because I like the idea that verifiers (which can be subject to dictionary attacks) are never communicated over the protocol, even during registration. However, I don't particularly like the idea that the OPRF needs to be rate-limited separately from the actual authentication attempts. I mean, it's hardly a problem that can't be overcome, but it feels more complex and error-prone to tune rate-limiting values and whatnot to a process that can be abandoned before actual authentication takes place (which is where I'd normally perform rate-limiting, logging and so on in other authentication schemes).

That got me thinking, however -- what is the purpose of the envelope checksums/tags, really? Just to ensure that I haven't misunderstood anything, the purpose of the checksum/tag is really just to ensure the client that it has decrypted the inner envelope correctly, no? Is there a need to do this? The central question then being:

  • If I removed the envelope checksum, and considering that ECC private keys are just random numbers without any particular structure anyway, wouldn't it be true that the client would just decrypt a private key from the envelope and use it for the AKE phase, not knowing if it's the correct key or not, where the wrong key would be detected, logged, rate-limited and reported just like any other authentication mechanism?

In this case, I could just not bother rate-limiting the OPRF. Would this compromise security in some other way? I'm aware that some OPAQUE schemes store the server's public key in the envelope to enable mutual authentication, which would interact poorly with this idea, but in my case I'm not really interested in mutual authentication anyway (the server being assumed to be authenticated via TLS to begin with), so I could just not do that.

Are there any other issues with omitting the checksum that I'm not seeing? And would doing so make the client truly oblivious of whether it has performed a correct decryption or not?

Improve this question

1 Answer 1

Reset to default
1

The authentication tag of the envelope binds the envelope content (i.e., the envelope_nonce which most client keys are derived from) to the server's public key as well as the server and client identities. See the definition of the Store function which the client uses to create the Envelope structure for the server: The tag is calculated over the envelope_nonce and the CleartextCredentials structure consisting of server_public_key, server_identity and client_identity.

Without this binding, the client cannot validate the server's public key during the Authenticated Key Exchange. So a man-in-the-middle attacker could wait for the client's KE1 message, forward it to the actual server to get a valid KE2 message, inject their own public key and server_public_keyshare and forward the manipulated message to the client. As a result, the attacker can calculate the session_key and impersonate the server.

If you have some other mechanism for checking the server's public key (e.g., a TLS connection), you could omit the envelope authentication tag. However, in general, I strongly recommend against any nonstandard implementations, because it's very easy to make fatal mistakes. It might also be too early to adopt OPAQUE, because the IETF standardization is still work in progress, and new drafts get submitted all the time.

Improve this answer
8
  • Forgive me, but even if we do include the server's public key in the envelope, I'm not sure why the tag is needed to evaluate it properly. A malicious server would not be able to encode its proper public key into the envelope without the tag anyway, would it? As I see it, worst case, the envelope is misdecrypted, the public key thus decrypted is invalid, and the AKE fails, is that not so? Commented Apr 16 at 20:27
  • My concern with including the public key in the envelope was more to do with the public key potentially being harder to encode in such a way that the client would be oblivious of whether it was correctly decrypted or not, since the public key tends to be a point on the elliptic curve, which can be validated to be correct (or not), unlike the private key. Commented Apr 16 at 20:28
  • And to be clear, I also agree that I'd like to not deviate from the standard, but I would also like to emphasize how much I dislike the fact that the client can tell whether the password was correct or not without checking its guess with the server. Commented Apr 16 at 20:45
  • Hm, looking at your links, I also realize that the protocol seems to have changed a fair bit since I last looked at it, so I'll probably have to refamiliarize myself with it before thinking more about it. :/ Commented Apr 16 at 20:57
  • 1
    @Dolda2000: The public key is not included in the envelope. In fact, the envelope contains nothing but the nonce and the tag. You get the public key from the server during the authentication stage, but this key can be wrong (due to a man-in-the-middle attack). So you need a way to check if it matches the server key from the registration. In the OPAQUE protocol, this check is done by feeding the nonce, public key and identities into a MAC and comparing the result with the authentication tag. Commented Apr 16 at 22:35

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.