SRP: 'M' computation does not match RFC5054/RFC2945

[awakecoding]

RFC5054 refers to RFC2945 for the computation of the 'M' value. However, this implementation does not seem to be following the standard.

'M' should be computed as: M = H(H(N) XOR H(g) | H(U) | s | A | B | K)

But instead, it is computed as: M1 = H(A, B, K)
https://github.com/RustCrypto/PAKEs/blob/master/srp/src/client.rs#L170
https://github.com/RustCrypto/PAKEs/blob/master/srp/src/server.rs#L132

I am not an expert of SRP, but am I missing something? The samples on the wikipedia page match the RFC, but I can't figure out why this implementation differs in that regard.

Thanks for clarifying this portion of the code!

[awakecoding]

I've done a bit more research on the topic, trying to figure out what the standard really is. When following RFC2945, it should be "M = H(H(N) XOR H(g) | H(U) | s | A | B | K)", but it turns out that in practice, there are a lot of SRP-6a implementations that use "M1 = H(A, B, K)", which appears to be the original formula from SRP-3.

Here are some interesting references:
https://www.scottbrady91.com/PAKE/SRP-in-CSharp-and-dotnet-core
https://crypto.stackexchange.com/questions/18528/implementation-and-testing-of-srp-6a

I'm a bit confused about the variability in the SRP protocol, it's standard, but there's a lot that can potentially be changed or swapped. It's nice, but not so nice for interoperability. Instead of replacing the code and breaking compatibility, I suggest adding an option to select the M formula for RFC2945 compatibility.

[newpavlov]

As was stated in the crate docs, compatibility with other implementation was not tested, so it should not be assumed. IIRC I was using the SRP whitepaper, though it concatenates S, not K (i.e. pre-hashed value, not resulting shared key). I think I will change API in the next version to allow configurability of proofs computation.

[awakecoding]

I saw the comment about the lack of interoperability testing, I just didn't want to assume anything. I'm in the process of making this crate interoperate with a C implementation of SRP that conforms to RFC5054/RFC2945: https://github.com/cocagne/csrp/tree/rfc5054_compat

We've managed to make it work on our side after modifying the M computation to match RFC2945. I should note that we originally made the mistake of using the master branch from the csrp project, which is unfortunately not compliant with RFC5054. I opened a ticket on the csrp github about it: cocagne/csrp#13

I think making it configurable is the best way to approach this, but if possible, I think we should probably be RFC5054/RFC2945 compliant by default, rather than leave the current non-compliant 'M' computation the default. Even if we document it, I'd suspect most people integrating this crate in a new project would use the defaults, and only notice later on about possible compatibility issues. In my case, I integrated the csrp code back in 2017, and I don't think the warning was very explicit back then. I only realized the interoperability problem this week while trying to make it work with this crate.

In the meantime, I'll create a branch to add configurability for the 'M' computation, and submit a pull request. Let's make this create interoperable :)

[brndnmtthws]

I bumped into this recently, so I drafted a PR to address it (#27). The change is (obv.) not backwards compatible, but it sounds like some effort is underway to make the computation configurable anyway.