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

Investigate Argon2 as KDF #26

Open
GlenRSmith opened this issue Sep 4, 2020 · 2 comments
Open

Investigate Argon2 as KDF #26

GlenRSmith opened this issue Sep 4, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@GlenRSmith
Copy link
Owner

GlenRSmith commented Sep 4, 2020

It seems like Argon2 has been the preferred KDF for several years now, but of course pbkdf2_hmac is built in to (core) hashlib, where AFAICT the available sources for Argon2 are argon2-cffi and pynacl, both of which have dependencies on non-python binary packages.
Edit: there is also Passlib which also has a non-python binary dependency.

@GlenRSmith GlenRSmith added the enhancement New feature or request label Sep 4, 2020
@GlenRSmith
Copy link
Owner Author

I have a POC using argon2-cffi.

I may introduce it soon, but as an experimental method (i.e. registering it but not as the default method).

#27 does include addition of a CryptIfc registration system, including "fallback" specification, so I could register this method and specify e.g. AES+SHA512 as the fallback, making sure that the argon2 implementation failed 1) in a way that is caught and reverts to the fallback and 2) before any stored data is affected.

The concern about the implementation not being available on some installations is about more than creation, though. If data is shared between devices, some devices may not be able to read from existing lockers. At a minimum, I think, there would need to be a workaround where the user could convert their locker to another encryption method on a supporting device before argon2 gets advanced beyond experimental stage.

@GlenRSmith
Copy link
Owner Author

In the way PBKDF2 uses the number of rounds of hashing to allow scaling (i.e. increasing the computational expense as more available hardware decreases time per computation), Argon2 has three relevant parameters - memory cost (the memory usage of the algorithm), time cost (the execution time of the algorithm and the number of iterations), and parallelism factor (the number of parallel threads).

It seems to me the production-ready version would provide some tuning support - determine on the available system the tolerable values for those parameters. You could even say that capability should be available for determination of the number of rounds for PBKDF2; indeed, maybe the use cases for that should be designed around PBKDF2 before adding the complexity of a new KDF.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant