Skip to content
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

Need padding for compatibility with RFC 5054 #11

Open
maffoo opened this issue Jul 31, 2015 · 1 comment
Open

Need padding for compatibility with RFC 5054 #11

maffoo opened this issue Jul 31, 2015 · 1 comment

Comments

@maffoo
Copy link

maffoo commented Jul 31, 2015

The implementation here seems to be incompatible with the specification of SRP in RFC 5054 which requires padding in various places that is not applied here. For example, in section 2.6 on computing the premaster secret, the server k value is defined as k = SHA1(N | PAD(g)) where the PAD function means pad with zeros to match the byte length of N. The code here by contrast just computes k = HASH(N | g) with no padding. It seems like compatibility with TLS-SRP would be a nice feature to have here.

@cocagne
Copy link
Owner

cocagne commented Aug 1, 2015

Thanks for the comments Matt,

RFC 5054 comparability was not one of my initial goals but several people
have expressed interest in this capability and have sent multiple patches
to that effect.... it's gotten to the point that I'm considering switching
the default implementation over to it. It's been a while since I've looked
at this so I can't recall off hand but I think the padding issue was one of
the first points addressed in the rfc5054_compat branch of pysrp. I haven't
advertised it anywhere so you probably haven't noticed it so, if not, take
a look and let me know if you prefer that approach.

I've been dragging my feet on switching the default implementation over to
that branch because it'd break backwards compatibility. The aggravating
part is that I have absolutely no idea how many people are using pysrp so I
can't accurately determine whether the benefits for switching over outweigh
the potential irritation to existing users....

Tom

On Fri, Jul 31, 2015 at 4:25 PM, Matthew Neeley notifications@github.com
wrote:

The implementation here seems to be incompatible with the specification of
SRP in RFC 5054 which requires padding in various places that is not
applied here. For example, in section 2.6
https://tools.ietf.org/html/rfc5054#section-2.6 on computing the
premaster secret, the server k value is defined as k = SHA1(N | PAD(g))
where the PAD function means pad with zeros to match the byte length of N.
The code here by contrast just computes k = HASH(N | g) with no padding.
It seems like compatibility with TLS-SRP would be a nice feature to have
here.


Reply to this email directly or view it on GitHub
#11.

@dvj dvj mentioned this issue Mar 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants