This pull request adds an optional "preview" decrypt before attempting to decrypt the entire remaining data.
For example, let's say you're looking for the magic string "abcd". You decrypt the first 4 bytes and they're "wxyz". At this point, you know you don't need to decrypt the rest of the file. However, if the decrypted data does start with "abcd", decrypt the rest of the file to verify PKCS padding, validity, etc.
In the case of character frequency analysis, the first N (default 1024) bytes are decrypted and checked. If they meet the valid_data check, then decrypt and check the rest of the file. This can potentially result in false negatives, hence why the value can be tuned.
As for performance comparison, I was attempting to brute force a 32MB encrypted file. Before the tweak I was getting 250 words/sec regardless of magic string or not. After the tweak I am getting over 200,000 words/sec without a magic string and almost 500,000 words/sec with one.
This pull request adds an optional "preview" decrypt before attempting to decrypt the entire remaining data.
For example, let's say you're looking for the magic string "abcd". You decrypt the first 4 bytes and they're "wxyz". At this point, you know you don't need to decrypt the rest of the file. However, if the decrypted data does start with "abcd", decrypt the rest of the file to verify PKCS padding, validity, etc.
In the case of character frequency analysis, the first N (default 1024) bytes are decrypted and checked. If they meet the
valid_datacheck, then decrypt and check the rest of the file. This can potentially result in false negatives, hence why the value can be tuned.As for performance comparison, I was attempting to brute force a 32MB encrypted file. Before the tweak I was getting 250 words/sec regardless of magic string or not. After the tweak I am getting over 200,000 words/sec without a magic string and almost 500,000 words/sec with one.