This repository has been archived by the owner on May 13, 2022. It is now read-only.
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.
PKCS7 padding has the form: 01 or 0202 or 030303 etc. For a correctly entered password and a correct decryption, there will be a full block of padding at the end of the data: 1010... (16 times, hex). This obviously cannot happen by chance, which is why entering an incorrect password throws a ValueError which the current code then interprets as decryption failure and requests the user to try again.
However, in the case where an entered password is incorrect, it is possible that the decrypted data (before stripping the padding) ends with ..01. This would be interpreted as correctly pkcs7 padded, the 01 would be stripped, and a decrypted seed of length 32+15 = 47 bytes would be returned. No ValueError would be thrown and then a bip 32 master seed would be correctly (but randomly) generated. Note that the bip32 master key generation uses an hmac of the seed data, and so the seed data length is ignored.
So in summary we have a slightly bigger than 1 in 256 chance of a wrong password being accepted here, so this PR insists that the decrypted data has a length of 32 bytes, making this error impossible.
I don't consider this a big deal really, but it's as well to fix it of course. I was 'inspired' by #190 , but there seems to be no chance that this was the cause of the strange behaviour described there.