Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
As far as I can tell from reading about SCRAM and OPAQUE is that Wikipedia puts both of them in the category of challenge-response authentication.
It's clear to me that SCRAM has an IETF RFC, whereas OPAQUE only has a draft.
However, what are some practical differences between them? For example, are both suitable for use in an SASL mechanism? What do each of them leak to the other party? What are their strengths and weaknesses?
The goal of SCRAM is to determine whether the two endpoints share a common secret. SCRAM achieves this by having both parties compare/exchange $\textrm{HMAC}(s,i)$ where $s$ is the secret and $i$ is a counter/nonce. There is more to it than this, but this is the main essence. If $s$ is a high-entropy cryptographic secret, then this is fine: seeing some HMAC outputs doesn't help an eavesdropper/impostor guess other HMAC outputs.
But if the shared secret is low-entropy like a password, I would say that SCRAM by itself is not suitable. The protocol transcript of a SCRAM interaction gives an eavesdropper enough information to test offline whether their guess for $s$ is correct. So SCRAM is susceptible to offline dictionary attacks. My understanding is that usually SCRAM is run inside of some encrypted tunnel, to protect from external eavesdroppers. But if I am a passive man-in-the-middle of that encrypted tunnel (which seems reasonable since there would be no need for SCRAM if we've already authenticated the endpoints!), I'll learn enough from the SCRAM transcript to allow offline dictionary attack.
SCRAM only does authentication, but OPAQUE is a full-fledged PAKE, which gives much more functionality:
key agreement: the endpoints establish a key in the presence of an eavesdropper, if their secrets match. Note that SCRAM uses a hash function (in HMAC) as its only cryptography. it is well known that secure key agreement is not possible from hash functions alone. This fact justifies why PAKEs are more expensive / use public-key crypto techniques.
designed for low-entropy secrets: a PAKE must resist offline dictionary attacks on the shared secret. The only way that an attacker can test a guess for $s$ is to interactively run the PAKE with one of the parties (online dictionary attack).
