-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
This use case does not work #29
Comments
I tried the reverse (encryption) process and the data I got are slightly different from what I expected in fact the encrypted data are: |
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.
|
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). |
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]
)The text was updated successfully, but these errors were encountered: