Re: [hybi] AES-128-CTR not much safer, but not fast either

[Adam Barth <[e-mail]>]

Or we could just use AES-128-CTR like everyone else in the known
universe and not worry about whether we've shaved exactly the right
number of hairs off our home-brew pseudo crypto.

Adam


On Sun, Jan 9, 2011 at 10:36 PM, Willy Tarreau <[e-mail]> wrote:
> On Mon, Jan 10, 2011 at 10:21:16AM +0800, Thomson, Martin wrote:
>> On 2011-01-10 at 11:09:08, Willy Tarreau wrote:
>> > willy@pcw:~/c$ time ./aes-128-ctr-get
>> > Found the 'GET\n' pattern on the wire after 1608425803 bytes
>>
>> You might also find the collected works of Shakespeare in the byte stream had you waited a little longer.
>
> I know, that's just a matter of defining "a little longer", as none of us
> will live long enough for that.
>
>>  I'm not sure what you are hoping to prove by searching.
>
> What I'm just showing is that we have the following points :
>  1) it was reported by an experiment that some caching intermediaries
>     were waiting for an HTTP request after the HTTP handshake was over
>
>  2) it was speculated that some lazy intermediaries might possibly skip
>     over whatever they did not understand to resync on an HTTP request
>     they understand and execute it, hence the need for masking the
>     stream or payload. Please note that no such intermediary has even
>     been remotely detected, and that several people here who have
>     already been involved with server code expressed that making them
>     capable of doing so would be much more difficult than doing the
>     right thing and would not even respect the principle of laziness.
>
>  3) it has been suggested that a simple 32-bit XOR was not enough and
>     that stronger cryptography was needed, because after a certain
>     number of attempts, the server might get the client to send a
>     request that such an intermediary can parse.
>
>  4) it was reported that at least one intermediary (Apache) accepts
>     an HTTP/0.9 request as simple as "GET\n".
>
>  5) it was shown that whatever algorithm we used to address the third
>     point was not enough to cover the second point for the supposedly
>     lazy intermediaries from #2 acting like Apache.
>
> So now, we have a choice :
>  - either we agree that #2 above is not that much of a risk such that
>    we don't need #3 to address it ;
>
>  - or we agree that #2 is still much of a concern, but as #4 is real,
>    then #3 is not a valid solution, as was proven with #5, and we
>    must use another one.
>
> But right now we're just complicating the protocol and removing some
> possibilities of later extensions without addressing the reason why
> we did that in the first place.
>
> Thanks,
> Willy
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>