[Wikimedia-l] Disinformation regarding perfect forward secrecy for HTTPS

[Anthony]

On Fri, Aug 2, 2013 at 11:09 PM, James Salsman <jsalsman at gmail.com> wrote:

> Anthony, padding in this context means adding null or random bytes to the
> end of encrypted TCP streams in order to obscure their true length. The
> process of adding padding is entirely independent of the choice of
> underlying cipher.
>

My point is that if the stream is encrypted using a block cipher (at least,
in CBC mode), then it's already padded to the block size of the cipher.

That's the more complete answer to my question of "How much padding is
already inherent in HTTPS?"  HTTPS itself does not have any inherent
padding, but when used with certain block ciphers, it does.

By the way, for most hours it's around 2.1-2.3 million, not 4.3 million.
 Wikimedia has been kind enough to give us a list of which pages are viewed
each hour of the day, along with the size of each page:
http://dumps.wikimedia.org/other/pagecounts-raw/

In this case, however, we have been discussing perfect forward secrecy,
> which is dependent on the particular cypher. ECDHE-RSA-RC4-SHA is an
> example of a PFS cipher and TLS key exchange protocol choice widely
> supported by Apache supporting PFS.
>

PFS is the method of key exchange.  You can use it with various different
ciphers.  From what I'm reading it can be used with AES and CBC, which
would be a block cipher which pads to 128 or 256 bytes.