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

please add Argon2 #18

Open
RDP1974 opened this issue Feb 15, 2021 · 5 comments
Open

please add Argon2 #18

RDP1974 opened this issue Feb 15, 2021 · 5 comments

Comments

@RDP1974
Copy link

RDP1974 commented Feb 15, 2021

please add Argon2
it's the default now

@MHumm
Copy link
Owner

MHumm commented Feb 15, 2021

If somebody helps implementing this, things will get worked out quicker.

...my next planned hash target would have been SHA3. But that can take time as I got stuck
a bit on adapting an existing Pascal version I have.

Another thing regarding Argon2: it is internally based on blake2 and that one is based
on ChaCha internally. So it might be good to get those implemented first...

@RDP1974
Copy link
Author

RDP1974 commented Feb 15, 2021

https://github.com/JackTrapper/argon2-for-delphi
maybe this can be ok, I will check the quality of the code

@jaclas
Copy link

jaclas commented Feb 15, 2021

https://github.com/JackTrapper/argon2-for-delphi
maybe this can be ok, I will check the quality of the code

Warning: This implementation is incomplete. There are items in the Argon2 specification that are undocumented.

@MHumm
Copy link
Owner

MHumm commented Feb 16, 2021

I would welcome contributions if they fit and the quality is ok.
Some points to note:

  1. Such new classes (Aragon2 has several variants and they inherit from a common base as the code referenced shows) should inherit from the otherwise still unused TPasswordHash class.
  2. Everything which is of more common nature (means: doesn't strictly belong to Aragon2) should go in that parent class if possible so other classes can benefit from this
  3. The Base64 stuff contained in there should be replaced with the Base64 implementation from DECFormats if possible
  4. Unit tests should be submitted as well. At least 2-3 test vectors per algorithm.
  5. I wouldn't mind if for the start only those variants which look ok in the referenced code are contributed
  6. It might be good to contribute stuff stepwise so I don't get lost when reviewing and integrating this. Bear in mind that my Git knowledge is still rough...
  7. Code should be properly XMLDOC commented and those long comments in the referenced code should be looked at. Some might be candidates for removal and many others are candidates for formatting them more compact.
  8. Code must of course be adapted in such a way that it meets the general current interface of DEC. We might need to talk about how to specify these additional parameters the algorithm has, but in doubt for a first start make constants out of them until we got everything working again and then we decide how to do it or suggest a way.

So if you try to follow these points fire up your IDE and start to adapt that referenced code! I'd be happy if we can get it into some fitting form...

@MHumm
Copy link
Owner

MHumm commented Feb 18, 2021

Has any work about that already started?

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

No branches or pull requests

3 participants