cocagne / pysrp

Python implementation of the Secure Remote Password protocol (SRP)
MIT License
113 stars 42 forks source link

Compatible JS library? #21

Closed SthPhoenix closed 2 weeks ago

SthPhoenix commented 8 years ago

Hi! Sorry if this is offtopic, but have anyone used pysrp with JavaScript? I'm currently fiddling with Thinbus-srp Spring demo. Managed to make both implementations communicate with each other, using pysrp with Flask as server-side, but can't make them to authenticate to each other (both sides using 2048 N and sha256). All I can figure out so far is:

They have a bit different logic. In pysrp the dataflow expected during authentication is:

While in Thinbus:

Since flask is stateless by default, managed to overcome this issue by re-initializing srp.Verifier() at fourth step with actual A, while passing s,b,v stored from second step

  1. Thinbus sending it's A,M,s,v in hex format, so I used binascii.hexlify() to send data to client and binascii.unhexlify() to recieve it back, but it often fails with "Odd padding" when using unhexlify() on v and s values

I've tried to compare both implementations, but I have no much experience with such math at JS side, and for me everything seems ok. Could someone point me out where to look at? Or does anyone know any JS library compatible with pysrp?

cocagne commented 8 years ago

Give the rfc5054_compat branch of pysrp a shot. RFC5054 is written for SRP specifically for TLS but that seems to be the de-facto standard for all other SRP implementations these days as well. I've been thinking about switching the mainline implementation over to that approach for a while now but it'd break backward compatibility.

Tom

On Fri, Aug 26, 2016 at 12:03 PM, SthPhoenix notifications@github.com wrote:

Hi! Sorry if this is offtopic, but have anyone used pysrp with JavaScript? I'm currently fiddling with Thinbus-srp Spring demo https://bitbucket.org/simon_massey/thinbus-srp-spring-demo. Managed to make both implementations communicate with each other, using pysrp with Flask as server-side, but can't make them to authenticate to each other (both sides using 2048 N and sha256). All I can figure out so far is:

They have a bit different logic. In pysrp the dataflow expected during authentication is:

  • Client -> Server: username, A
  • Server -> Client: s, B
  • Client - > Server: M
  • Server - > Client : H(A,M,K)

While in Thinbus:

  • Client -> Server: username
  • Server -> Client: s, B
  • Client - > Server: M, A
  • Server -> Client: H(A,M,K)

Since flask is stateless by default, managed to overcome this issue by re-initializing srp.Verifier() at fourth step with actual A, while passing s,b,v stored from second step

  1. Thinbus sending it's A,M,s,v in hex format, so I used binascii.hexlify() to send data to client and binascii.unhexlify() to recieve it back, but it often fails with "Odd padding" when using unhexlify() on v and s values

I've tried to compare both implementations, but I have no much experience with such math at JS side, and for me everything seems ok. Could someone point me out where to look at? Or does anyone know any JS library compatible with pysrp?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cocagne/pysrp/issues/21, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrLfOnYKqSubrYvdGpX6ZDaZwE38u05ks5qjxxogaJpZM4JuRgb .

SthPhoenix commented 8 years ago

Thanks! I'll give it a try at monday (left all my code at work), also it seems that for some reason hex values from Thinbus for some reason have wrong padding, which sometimes make it impossible to decode, may it be caused by rfc5054 padding, or I should look somewhere else?

cocagne commented 8 years ago

Rfc5054 definitely uses different padding. That's most likely the cause.

On Aug 26, 2016 12:18 PM, "SthPhoenix" notifications@github.com wrote:

Thanks! I'll give it a try at monday (left all my code at work), also it seems that for some reason hex values from Thinbus for some reason have wrong padding, which sometimes make it impossible to decode, may it be caused by rfc5054 padding, or I should look somewhere else?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cocagne/pysrp/issues/21#issuecomment-242796005, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrLfF8SF_99iLxoY2R5Pk6lzj3s3Jgoks5qjx_qgaJpZM4JuRgb .

SthPhoenix commented 8 years ago

Update: looks like thinbus calculate M value as: M= H(A,B,K) While in pysrp: M=H(H(N) XOR H(g), H(I),s,A,B,K) So here pysrp is much closer to original specs than thinbus

SthPhoenix commented 8 years ago

Ok, I beat it. In short:

cocagne commented 8 years ago

Hmm. You might want to ask Simon if he followed RFC5054 for compatibility with other SRP implementations. i went my own route at first and he may have done the same. I do know that the 5054 branch of pysrp is compatible with a couple other implementations so it should work with thinbus if it's following the same set of rules. Which, come mostly down to the hashing algorithm, I think.

On Mon, Aug 29, 2016 at 1:06 PM, SthPhoenix notifications@github.com wrote:

Still no luck trying to figure out what's wrong. I have tried to create salt and verifier with JS and than feed them to code from pysrp usage example in User class instance. Salt left in hex form, while verifier is: v = verifier.decode('hex') For some reason with this verifier it won't authenticate too

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cocagne/pysrp/issues/21#issuecomment-243204772, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrLfHLeRUOhJvGi18gM54LOfGuBX267ks5qkx-wgaJpZM4JuRgb .

SthPhoenix commented 8 years ago

I have actually used the 5054 branch, but still had to change some calculations in order to made two libs communicate. I made all changes on server side, since I know python better than JS: u is calculated as: h= hash_class(); h.update(bn_to_bytes(self.A).encode('hex')); h.update(bn_to_bytes(self.B).encode('hex')); bytes_to_bn(self.u, h.digest()); And M is calculated as: h= hash_class(); h.update(bn_to_bytes(self.A).encode('hex')); h.update(bn_to_bytes(self.B).encode('hex')); h.update(bn_to_bytes(self.S).encode('hex')); self.M = h.digest(); A,B,M are sent and received in hex form during communication, and decoded from hex when passing into Verifier instance

Also have to add get_ephemeral_secret() and check for bytes_b in verifier class from main branch to use it in Flask. I haven't find anywhere in SRP's specs direct recommendations which representations of values should be used for hashing, so I think both approaches of pysrp and thinbus are kind of valid.

cocagne commented 8 years ago

Ahhh. Interesting. I agree that both approaches are valid since the SRP specification provides little guidance with respect to how the hash is preformed. For 5054 compliance though, I'm pretty sure the hash must be done on the raw byte stream as opposed to the hex-encoded variant. Did you ultimately get it working and stable?

On Tue, Aug 30, 2016 at 5:10 AM, SthPhoenix notifications@github.com wrote:

I have actually used the 5054 branch, but still had to change some calculations in order to made two libs communicate. I made all changes on server side, since I know python better than JS: u is calculated as: h= hash_class(); h.update(bn_to_bytes(self.A).encode('hex')); h.update(bn_to_bytes(self.B).encode('hex')); bytes_to_bn(self.u, h.digest()); And M is calculated as: h= hash_class(); h.update(bn_to_bytes(self.A).encode('hex')); h.update(bn_to_bytes(self.B).encode('hex')); h.update(bn_to_bytes(self.S).encode('hex')); self.M = h.digest(); A,B,M are sent and received in hex form during communication, and decoded from hex when passing into Verifier instance

Also have to add get_ephemeral_secret() and check for bytes_b in verifier class from main branch to use it in Flask. I haven't find anywhere in SRP's specs direct recommendations which representations of values should be used for hashing, so I think both approaches of pysrp and thinbus are kind of valid.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cocagne/pysrp/issues/21#issuecomment-243394773, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrLfGj_I0Ed6Wy8YdRC7Zb1NnLutTndks5qlAGwgaJpZM4JuRgb .

SthPhoenix commented 8 years ago

Still testing, got some issues with authentication from time to time. Approximately 3 out of 10 tries generates wrong keys. Seems that it's something connected to trimming leading zeroes on thinbus side, added code to cope with that, but still no luck.

SthPhoenix commented 7 years ago

Got it fully working and stable, also added simple safe prime config generator, to simply export server side configs into thinbus client. I'll tidy up a code a little and will try to upload fork with demo page on github soon )

SthPhoenix commented 7 years ago

Created fork here: pysrp_thinbus

cocagne commented 7 years ago

Nicely done :) Thanks for putting in the effort to implement this.

On Sat, Sep 3, 2016 at 8:38 AM, SthPhoenix notifications@github.com wrote:

Created fork here: pysrp_thinbus https://github.com/SthPhoenix/pysrp_thinbus

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cocagne/pysrp/issues/21#issuecomment-244547045, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrLfLON5dYEcIrcaFpUg-OC8FkDqh3Yks5qmXhrgaJpZM4JuRgb .

Xavier59 commented 1 year ago

Unfortunate that you didn't merge and that it now felt way behind master :( I'm trying to make this module work with https://github.com/midonet/tssrp6a without success so far. Since tssrp6a has been tried against thinbus / nimbus, I expect your change to work for tssrp6a. I may give it a try later.

Xavier59 commented 1 year ago

Giving up. Tried to use @SthPhoenix fork and migrate it to Python3 and to get it to work with tssrp6a. Unfortunately I wasn't successful ... Bad credentials :'(

cocagne commented 2 weeks ago

Cleaning up old issues