Re: New Version Notification for draft-thomson-http-encryption-00.txt

In message <>, Willy Tarreau writes:

>> >Note that if a client supporting an encrypted response payload sets gzip in
>> >Accept-Encoding, it probably means it's willing to decompress *after*
>> >decryption, [...]
>> That be an information leak.  We shouldn't say anything which tells
>> anybody anything about what the encrypted data means.
>Good point, which brings back the header fields encryption. Thus maybe
>as was suggested, if any header is to be encrypted it should be moved
>to the payload part (mime or so).

It's very simple:  You have an envelope everybody can see (the headers)
and you have the content (the body).

Anything you want to keep secret goes in the body.

>That said, a correct encryption algorithm would not be weakened
>by knowing that the first 3 bytes are expected to be 0x1f8b08.

Which is why really good crypt always has initial and trailing non-sense.

And you non-sense had better be good:

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Tuesday, 12 May 2015 13:48:41 UTC