Closed shijimasoft closed 11 months ago
I tried the reverse (encryption) process and the data I got are slightly different from what I expected in fact the encrypted data are: 9f2707bc98bb5781d4e7b461bffe6270b419f11edb920f94f6a1b6ec8e469926
(32 bytes) and not the expected 9f2707bc98bb5781d4e7b461bffe6270
(16 bytes).
This is because padding (PKCS7) is always included, hence for a 16-byte input, its padding will be another 16-byte padding, leading to total 32 bytes.
pycrypto
is different in a way that padding is handled separately and require the user to add padding when needed.
Is it possible to implement a flag for manual padding management? (For encryption as well as decryption)
Is it possible to implement a flag for manual padding management? (For encryption as well as decryption)
Yes it's possible. I've opened a PR #30 to do that. Would you have time to try out the PR's branch and see it works for you?
I just checked the PR, everything seems to be working correctly (I also tried other use cases and they are all correct). Thank you for being so quick to help me!
Thanks for verifying! I've merged the PR. Will post a new release soon.
Okk! Thank you for your work!
I open this issue because I ran into a somewhat strange situation: I am rewriting a python code in rust using libaes for AES decryption, below is the code I use:
Using
pycrypto
instead works correctly, returning the expected result:59f96218d8eccab277ed477a33dcb7f3
(expected byte array translated into an hex string)Maybe I'm doing something wrong or just forgetting some padding things or the data format is incorrect (literal
hex!
returns a decimal format byte array i.e:[159, 39, 7, 188, 152, 187, 87, 129, 212, 231, 180, 97, 191, 254, 98, 112]
)