You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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....
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.
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 thePAD
function means pad with zeros to match the byte length ofN
. The code here by contrast just computesk = HASH(N | g)
with no padding. It seems like compatibility with TLS-SRP would be a nice feature to have here.The text was updated successfully, but these errors were encountered: