oduwsdl
Check for encryption method and fail if unsupported in replay
In #445 @ibnesayeed said:
If in future we extend more encryption methods and someone tries to reply a newer index with an older replay, the server might crash due to incompatible key passed to a different encryption method. I think the safe way would be to put that check in place and return an error to the client while logging the issue as unsupported encryption method if the method is anything but aes. This will be forward-safe.
When we used XOR for encryption prior to this PR, we checked the CDXJ for the respective key and assigned the Cipher class to be instantiated. This check was removed with the move to AES.
We should have conditional checks for different encryption types supported, used, and expected in the CDXJ. A base case can be found in the sample CDXJ files that specify XOR. Despite this specification, the current version of ipwb will use AES, which will cause gibberish to be display.
We can no longer support what we originally expected from XOR-based records, as the assumptions from pycrypto (variable length key/value) are not maintained in pycryptodome.
- [ ] Write a test case for ipwb to fail with old CDXJ files using XOR
- [ ] Add conditions to report an error if an unsupported encryption method is used
We can no longer support what we originally expected from XOR-based records, as the assumptions from pycrypto (variable length key/value) are not maintained in pycryptodome.
Does this part add anything in this context that I am unable to understand?
@ibnesayeed Pycrypto allowed us to specify variable length key and target string. The implementation in Pycryptodome requires equal length strings. I have yet to look into the (assumed) padding method that Pycrypto was using. This information is needed to ensure a consistent interpretation from Pycryptodome if records were previously created with the ipwb indexer using (XOR, the only method available then) encryption.
The point of this ticket is to check for the method used for encryption and only attempt to decrypt if the method is known (which for now is AES). This ticket has nothing to do with providing a guarantee that previously supported XOR method continues to work.