-
Notifications
You must be signed in to change notification settings - Fork 5
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
explain working of crypt padding #19
Comments
@theferrit32 see 2af6f37 (part of #18) |
@stdweird since the type of Based on a quick test I did in python2, this appears to be only true in python3. Since this is not very clear for python3 and doesn't work at all in python2, the change to use |
@theferrit32 i tried it on py3 too, but it also failed for me
anyway, thanks for considering the PR 👍 |
@stdweird that uses
In this case the pad characters are just encoded 1 byte integers so the difference between ascii and utf-8 unicode character length for the actual data segment of the encrypted block does not impact the decryption. |
@theferrit32 i have a traceback in py27 and i'm trying to understand how things went wrong
afaik In https://github.com/heliumdatacommons/auth_microservice/blob/master/token_service/crypt.py#L27 the padding is set en it's length is encoded in the padding character.
however, in decryption, https://github.com/heliumdatacommons/auth_microservice/blob/master/token_service/crypt.py#L51 the reverse never happens (i expected an
ord(de_encr[-1])
)also, you should add a check that AES blocksize is never > 255, otherwise stuff will go very wrong (py2 gives exception, py3 uses unicode chars (but those are large than one byte))
The text was updated successfully, but these errors were encountered: