Open GlenRSmith opened 4 years ago
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).
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.
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.
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.