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

[Anthony]

How much padding is already inherent in HTTPS?  Does the protocol pad to
the size of the blocks in the block cipher?

Seems to me that any amount of padding is going to give little bang for the
buck, at least without using some sort of pipelining.  You could probably
do quite a bit if you redesigned Mediawiki from scratch using all those
newfangled asynchronous javascript techniques, but that's not exactly an
easy task.  :)


On Fri, Aug 2, 2013 at 3:45 PM, Marc A. Pelletier <marc at uberbox.org> wrote:

> On 08/02/2013 01:32 PM, James Salsman wrote:
> > Padding each transmission with a random number of bytes, up to say 50
> > or 100, might provide a greater defense against fingerprinting while
> > saving massive amounts of bandwidth.
>
> It would slightly change the algorithm used to make the fingerprint, not
> make it any significantly higher, and you'd want to have some fuzz in
> the match process anyways since you wouldn't necessarily want to have to
> fiddle with your database at every edit.
>
> The combination of "at least this size" with "at least that many
> secondary documents of at least those sizes in that order" is probably
> sufficient to narrow the match to a very tiny minority of articles.
> You'd also need to randomize delays, shuffle load order, load blinds,
> etc.  A minor random increase of size in document wouldn't even slow
> down the process.
>
> -- Marc
>
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request at lists.wikimedia.org?subject=unsubscribe>
>