Cryptographic vulnerabilities: Key as IV, insecure HMAC comparison #58
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I defined
AES_new
as a function that returns an AES cipher object and a new secure random IV if None was specified. If an attacker can exhibit control over any ciphertext fed to the decrypter, recovering the secret key is a trivial exercise as described in Key as Initialization Vector.See the following gist for an example showing how this can be exploited.
I also noticed
compare()
provides a contant-time comparison function for comparing HMAC signatures, however was never called anywhere. This patch updates thesecure_loads()
function to usecompare()
when comparing HMAC signatures.