-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should the Generator
(g
) be padded in the M
calculation for SrpServer?
#19
Comments
Hello Mark, thanks for posting your workaround. This library aims to be interoperable with other standard-compliant implementations. Srp.net is compatible with Swift SRP which is able to connect to Apple's servers. |
The python API is open source, it's the main We could consider making it easier to configure the padding of What do you think? |
Hello Mark, sorry for my late response. SRP protocol has several obsolete revisions, and of course it makes sense to support them
It would be great if you add a couple of lines to the readme about your workaround and when Or maybe implementations repo is a better place to mention partially-compatible libraries. Thank you! |
Sounds like a plan. When I get some downtime I'll update the docs. |
I migrated from `pysrp` to `srp.net` and confirmed interoperability (assuming the caveats in the footnote). For more details, see secure-remote-password/srp.net#19
I'm trying to port an SRP implementation over to C# from python. The client is legacy and I cannot change it, so I'm just implementing a compatible server side of the protocol.
It was failing using this library until I noticed that the library doesn't
Pad
theg
value here:https://github.com/secure-remote-password/srp.net/blob/master/src/srp/SrpServer.cs#L130
(It doesn't pad in the SrcClient either. So it's consistent. But I'm wonder if we should update both?)
The python SRP library does pad this value when enabling support for
rfc5054
:https://github.com/cocagne/pysrp/blob/master/srp/_pysrp.py#L205-L208
I tried jumping through the
rfc5054
docs, but it doesn't even mention theM
proof calculation so it's unclear if the padding should also apply there. It mentions paddingk
andu
(which this library does) but doesn't claim one way or the other forM
:https://datatracker.ietf.org/doc/html/rfc5054
I was able to workaround this issue by doing the following:
It works for my needs. But I guess the larger question for this issue is: Should this library actually be padding
g
in theM
calculation? Or is the python srp implementation incorrect?The text was updated successfully, but these errors were encountered: