Skip to content
This repository has been archived by the owner on Aug 26, 2022. It is now read-only.

New API PoC #4

Open
wants to merge 48 commits into
base: calc_x
Choose a base branch
from
Open

New API PoC #4

wants to merge 48 commits into from

Conversation

Ptico
Copy link

@Ptico Ptico commented Dec 7, 2016

This is very early prototype (contain bugs and untested code) of proposed API changes. Just for discussion.

For now it looks like this:

user = { username: 'xxx', verifier: 'xxx', salt: 'xxx' }
aa = 'xxx'
start = SIRP::Server::Start.new(user, aa)

challenge = start.challenge
proof = start.proof

finish = SIRP::Server::Finish.new(proof, mm)
finish.success?
finish.match #=> H(A, M, K)

grempe added 30 commits May 19, 2016 18:31
…Drop securer_randomer in favor of direct use of RbNaCl RNG
… the protocol spec or the wikipedia sample code
…ng nil quietly. Also allows stricter type checking.
@Ptico
Copy link
Author

Ptico commented Dec 7, 2016

Related to #3

@coveralls
Copy link

coveralls commented Dec 7, 2016

Coverage Status

Coverage decreased (-36.4%) to 63.636% when pulling 71250e5 on Ptico:new_api into 96355fe on grempe:calc_x.

@grempe
Copy link
Owner

grempe commented Dec 8, 2016

Hi @Ptico

Thanks for taking this challenge on. Your ideas are good.

Before we get into the API changes there are a couple of things that probably need to be addressed.

Your work is based off of my experimental fork with the intention to make the library even more secure. In the interim there has been a new release on the master branch and this work-in-progress branch is out of date. I think it needs to be rebased off of master and get it back in sync again.

My biggest concern is that the new branch represents breaking changes with the Javascript SRP client that this ruby code works with. This is a library that I don't own and I imagine that the owner would be reluctant to take on the necessary changes since they would be breaking changes. This means I would likely need to fork and maintain that tool as well, which is possible, but I am a bit reluctant to take on.

I can take on the rebase, but that means your significant work will be out of date.

What are your thoughts on the best approach to tackle these issues?

Cheers.

@Ptico
Copy link
Author

Ptico commented Dec 8, 2016

Hi, this is just a PoC, and needs a lot of work, so I can merge changes manually, but some of them may need your assistance or opinions in IRC or something like this.

My team got it working with another JS library for our internal project, but I have a plan to implement the better one with my guys.

So, if you have some time for this, please, mail me your preferred IM contact to andriy@aejis.eu and let's discuss

@grempe
Copy link
Owner

grempe commented Dec 8, 2016

Hi. I've rebased the calc_x branch against the master branch and added one small additional commit to consistently use the sysrandom gem for random numbers. You should also rebase your changes against that branch.

Do you have a pointer to the JS lib you got working?

I'll send you contact info in email and we can chat sometime this week.

@Ptico
Copy link
Author

Ptico commented Mar 7, 2017

Hi @grempe
It takes much more time than planned, but I completed the low-level API for server and got it working with modified JS client. Also, I created adapter for v2 (SHA) compatibility, but it doesn't tested with JSRP yet

Next steps is:

  • Documentation for server code
  • Create high-level API for server (see below)
  • Improve test coverage
  • Test SIRP::Backend::Digest with JSRP and automate testing for both JS libs
  • Create SIRP::Client

Things i want to discuss:

  1. I moved generate_userauth functionality out of Server namespace to SIRP::Register because IMO it can be used in both Server and Client side. What do you think about this?

  2. High-level API: I want to have an ability to preconfigure things like backend, hash function and prime once, but don't want to do this globally (for cases, where we have our own auth, but also have 3rd-party service with different primes). So, the possible API may look like:

Auth = SIRP::Factory(prime_length: 1024, hash: Digest::SHA256)

credentials = Auth.register(username, password)
start = Auth::Server.start(user, aa)
finish = Auth::Server.finish(proof, mm)

With defaults: Prime[2048], Digest::SHA256 and Backend::SCryptHMAC

  1. YARD format is pretty poor. For example, it doesn't allow to document hash params well. What about to move to TomDoc or something like this?

Also, I want you to review changes in this PR as a basis for later work.

Thanks

@grempe
Copy link
Owner

grempe commented Mar 7, 2017

I'll try to take a look at this and make comments this weekend.

@Jman420
Copy link

Jman420 commented Nov 1, 2018

Any updates on this PR? I am looking for a Ruby Implementation of SRP-6a and would like to be using SHA256 for hashing. Will those changes be integrated into the project in the foreseeable future?

@Ptico
Copy link
Author

Ptico commented Nov 2, 2018

I’ve started another, more modular version of this PR https://github.com/esrp/ruby The development temporary stalled and lacks high level API, but low level API is fully working (including all SHA versions), so feel free to contact me if you need assistance with it.

However, I would be happy to finish my work with this PR

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants