Skip to content
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

Open
stdweird opened this issue Sep 18, 2018 · 4 comments
Open

explain working of crypt padding #19

stdweird opened this issue Sep 18, 2018 · 4 comments

Comments

@stdweird
Copy link
Contributor

@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))

@stdweird
Copy link
Contributor Author

@theferrit32 see 2af6f37 (part of #18)

@theferrit32
Copy link
Member

theferrit32 commented Sep 18, 2018

@stdweird since the type of de_encr is bytes the statement on Line 52 will do an automatic type conversion to numeric from byte when it indexes the array using a byte type.
https://github.com/heliumdatacommons/auth_microservice/blob/master/token_service/crypt.py#L52

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 ord explicitly in that commit looks good, thanks. I will work on testing the changes in #18 when I get a chance either later today or some time tomorrow.

@stdweird
Copy link
Contributor Author

@theferrit32 i tried it on py3 too, but it also failed for me

[stdweird@gast039e ~]$ python3
Python 3.6.6 (default, Jul 19 2018, 16:29:00) 
[GCC 7.3.1 20180303 (Red Hat 7.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a=bytes(10)
>>> -a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: bad operand type for unary -: 'bytes'
>>> b='1'*20
>>> b[:-a]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: bad operand type for unary -: 'bytes'

anyway, thanks for considering the PR 👍

@theferrit32
Copy link
Member

@stdweird that uses bytes type which is an array, while pad_n is a singular byte:

>>> a = bytes('abcdefg','ascii')
>>> b = [x for x in range(0,200)]
>>> n = a[-1]
>>> b[:-n]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96]
>>> ord('g')
103

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants