Re: padding and compression

On Mon, 24 Feb 2014 20:53:38 +0100, Roberto Peon <grmocg@gmail.com> wrote:

> Anyway, security is a big and long discussion in and of itself. The  
> guidance here should probably be to follow recommendations set by a  
> >different group and spec entirely :)
> -=R

If padding strategy isn't coordinated though, it becomes a means for  
fingerprinting implementations.

/Martin Nilssons


>
>
>
> On Mon, Feb 24, 2014 at 11:39 AM, Martin Thomson  
> <martin.thomson@gmail.com> wrote:
>> On 24 February 2014 00:48, Cory Benfield <cory@lukasa.co.uk> wrote:
>>> My understanding is that you pad any HEADERS or CONTINUATION frame out
>>> to some implementation-defined size, preventing an attacker from
>>> telling how large the compressed header block actually is. For
>>> instance, if I chose 100 bytes, I would take any compressed header
>>> block and split it into 100 byte chunks, and then pad the last frame
>>> out to 100 bytes.
>>
>> Almost.  Padding is a sharp tool.
>>
>> An attacker that controls part of the plaintext can still force you to
>> reveal information by counting the chunks.
>>
>> However, here's an example that might* not leak information.  Say you
>> have a secret in a header field.  That secret is fixed size
>> originally, but consequently variably compressed (e.g., Huffman).  You
>> might want to allow for compression of the remaining fields, but then
>> pad to account for the specific effect of compression on that field.
>>
>> * Never take my word for anything in this regard.  And who knows what
>> else you are leaking as a result.  For example, the conditionals you
>> execute in assembling this information result in different computation
>> times, providing an attacker with timing information that might reveal
>> something despite your best effort to avoid the leak.
>>
>



-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/