Need padding for compatibility with RFC 5054

[maffoo]

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]

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 [email protected]
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.