Open courteous opened 5 years ago
We have to follow the current flow in order to implement TLS-SRP.
It might be ok to modify SRP in order to allow this alternative message flow. But I am unlikely to take this on since SRP is these days very long in the tooth, it would be better to spend development time on a newer PAKE such as OPAQUE or SPAKE2+.
My vote is on OPAQUE.
Yeah I like OPAQUE as well but waiting on CFRG to figure it out
Currenly the SRP code is structure in a way that the client is waiting for the server to send his Public Value "B", which gives the attacker a chance to implement an attack described in:
SRP-6: Improvements and Refinements to the Secure Remote Password Protocol Thomas Wu from Otober 29, 2002
Section: Message ordering:
In this case it will be required to calculate A separately form S. i.e. here I am referring to method srp6_client_agree from the file srp6.cpp
i.e. the idea here is to require from client to send his A before the server has revealed his B. Currently the implementation does not allow this.
Does it make sense to change this?