Re: [TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))

["Paterson, Kenny" <[e-mail]>]

On 14/11/2013 04:15, "Michael D'Errico" <[e-mail]> wrote:

>Nikos Mavrogiannopoulos wrote:
>> On Tue, 2013-11-12 at 23:29 +0100, Martin Rex wrote:
>>> You proposal adds the padding at the beginning only.  Since the
>>> problem exhibited by RC4 is inherent to any XOR-encryption with
>>> a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an
>>> extension use random fraction, random content, authenticated padding
>>> on both sides of the plaintext, with a combined minimum padding length
>>>of
>>> at least 16 bytes, in order to mitigate statistical attacks on
>>> any bias that may be found in the pseudo-random-pad.
>> 
>> The above draft does:
>> 1. prevent padding oracle attacks
>> 2. hide the length of the plaintext
>> 
>> What you propose there is having the plaintext appear and finish in an
>> unpredictable position. That's an interesting approach, not handled by
>> the draft above.
>> 
>> In simple terms you're asking for more bells and whistles :)
>
>If I recall correctly from DJB's paper, the problem with RC4 is bias in
>the first 256 or so bytes of the key stream.

You recall incorrectly. Re-read sections 4.2, 5.2, 5.3.3 and 7 of the
paper:

http://www.isg.rhul.ac.uk/tls/RC4biases.pdf


>Would it be possible to
>"fix" RC4 using this extension? Simply insert a random amount (at
>least 256 bytes) of pseudo-random padding at the beginning of the first
>record sent using an RC4 cipher suite?

No.

Please read Section 7 of the paper. This idea, and variants of it, are
specifically addressed and dismissed.

Regards,

Kenny