This library provides three functions:
generate_digestdecrypt_digestvalidate_digest
This is a multi-arity function that will generate a digest using either a password-based key derivation function (KDF) or a PBKDF2 depending on the input given.
If a password argument is provided, then KDF will be used (along with a random salt) to generate a non-deterministic digest.
If a salt is provided, then a PBKDF2 will be used to generate a deterministic digest.
Note: salts should be a minimum of 128bits (~16 characters) in length.
It's recommended you use KDF (i.e. provide a password argument to the generate_digest function), this is because they're designed to be more computationally intensive than standard hashing functions and so are harder to use dictionary or rainbow table style attacks (as they would require a lot of extra memory resources and become more unfeasible as an attack vector).
By default the KDF will have a maximum computational time of 0.5, but this can be overridden using the maxtime argument.
A PBKDF2 is able to provide deterministic output (and the ability to specify an explicit salt value). The internal implementation will repeat its process multiple times, thus reducing the feasibility of automated password cracking attempts.
Note: when specifying a maxtime with
generate_digest, ensure you include that same value when decrypting withdecrypt_digestor validating viavalidate_digest.
The decrypt_digest and validate_digest functions only apply to digests that have been generated using a password (i.e. KDF). Given the right password decrypt_digest will return the original message, and thus is considered more a form of symmetrical encryption than a straight one-way hash function. The validate_digest function will return a boolean true or false if the given password was able to decrypt the message.
See the tests for examples of how to use these functions.
See tests.
We have two dependency files:
requirements.txtrequirements-to-freeze.txt
The latter should contain both 'explicit' versions (i.e. versions of dependencies our service is known to support) and 'non-explicit' versions (e.g. no versions defined), where as the former (requirements.txt) simply acts as a lockfile.
If we execute pip freeze the output will include dependencies that have the explicit versions we requested and the latest version for those dependencies where we defined no explicit version. We can direct that output to a new file called requirements.txt.