Open Stack

AES block size is 16 bytes. I don't understand why the padding size 
would > 16.
cipher.block_size should equal to 16.

- Jeff

On 6/5/2014 12:06 PM, Robert Clark wrote:
> In the case of 128 bit AES would this not send twice as much padding as
> needed or is the schema such that padding is always to the nearest 256 ?
>
>> -----Original Message-----
>> From: bounces at canonical.com [mailto:bounces at canonical.com] On
>> Behalf Of Robert Clark
>> Sent: 04 June 2014 23:11
>> To: Clark, Robert Graham
>> Subject: [Bug 1326474] Re: crypto/utils.py may use too much padding
>>
>> Thanks for the clarification guys, this makes sense to me, fwiw I did
>> ask
>> about this in the oslo room first and the suggestion was that I log a
>> bug to
>> get it double checked.
>>
>> Cheers
>> -Rob
>>
>> ** Changed in: oslo
>>         Status: New => Invalid
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1326474
>>
>> Title:
>>    crypto/utils.py may use too much padding
>>
>> Status in Oslo - a Library of Common OpenStack Code:
>>    Invalid
>>
>> Bug description:
>>    I've been reviewing some of the crypto code available in OpenStack and
>>    noticed something interesting in the padding of
>>    common/crypto/utils.py.
>>
>>
>>    If the message length is the same as the cipher block size an entire
>> extra
>> block of padding is sent along with the message, I'm not sure if this is
>> desired behaviour (if it is, this bug is invalid) but it certainly
>> doesn't seem
>> quite right.
>>
>>    If the message length is ever the same as the boundary size ( % 256)
>>    then an entirely extra block of padding will be applied:
>>
>>    ---code---
>>       r = len(msg) % self.cipher.block_size
>>            padlen = self.cipher.block_size - r - 1
>>            msg += b'\x00' * padlen
>>            msg += bchr(padlen)
>>    ---/code---
>>
>>    So if our msg length is 256,512,,, then 'r' will be 0
>>    padlen will be 256-0-1 or 255
>>    msg gets 255 * b'\x00' added and then the number 255 tagged on the
>> end.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions