You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: