Rui, His point is valid. You have a valid point but use an invalid argument
to support it.
Cheers,
Peter
- Original Message -
From: Rui Correia correia@gmail.com
To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org
Sent: Thursday, August 01, 2013 11:19 PM
Subject: Re:
On Aug 1, 2013, at 10:07 PM, Ryan Lane rl...@wikimedia.org wrote:
Also,
our resources are delivered from a number of urls (upload, bits, text)
making it easier to identify resources. Even with padding you can take the
relative size of resources being delivered, and the order of those sizes
Journalist = professional troll
Explains but does not justify.
Peter
- Original Message -
From: Rui Correia correia@gmail.com
To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org
Sent: Thursday, August 01, 2013 10:55 PM
Subject: Re: [Wikimedia-l] Why the WP will never be a
Hey, what about writing the White people self-centered writings
article? ;P
Le 2013-08-01 22:22, Rui Correia a écrit :
Dear Colleagues at the Foundation
I just came across an artecle called White Africans of European
ancestry.
What is that even supposed to mean? Who would be any other white
George William Herbert wrote:
...
It would also not be much more effort or customer impact
to pad to the next larger 1k size for a random large fraction
of transmissions.
Padding each transmission with a random number of bytes, up to say 50
or 100, might provide a greater defense against
On Fri, Aug 2, 2013 at 1:32 PM, James Salsman jsals...@gmail.com wrote:
George William Herbert wrote:
...
It would also not be much more effort or customer impact
to pad to the next larger 1k size for a random large fraction
of transmissions.
Padding each transmission with a random
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
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
Marc A. Pelletier wrote:
...
A minor random increase of size in document wouldn't even slow
down [fingerprinting.]
That's absolutely false. The last time I measured the sizes of all
9,625 vital articles, there was only one at the median length of
30,356 bytes but four articles up to 50 bytes
On 08/02/2013 05:06 PM, James Salsman wrote:
Marc, I note that you have recommending not keeping the Perl CPAN
modules up to date on Wikimedia Labs:
http://www.mediawiki.org/w/index.php?title=Wikimedia_Labs/Tool_Labs/Needed_Toolserver_featuresdiff=678902oldid=678746
saying that out of date
On 08/02/2013 05:50 PM, Matthew Flaschen wrote:
It seems from the context better tested meant something like people
are using this in practice in real environments, not only automated
testing.
And, indeed, given the constraints and objectives of the Tool Labs
(i.e.: no secrecy, all open source
... random padding without (at least) pipelining and
placards *is* worthless to protect against traffic analysis
No, that is not true, and
http://www.ieee-security.org/TC/SP2012/papers/4681a332.pdf
explains why. Padding makes it difficult but not impossible to distinguish
between two HTTPS
On 08/02/2013 08:15 PM, James Salsman wrote:
No, that is not true, and
http://www.ieee-security.org/TC/SP2012/papers/4681a332.pdf
explains why. Padding makes it difficult but not impossible to distinguish
between two HTTPS destinations. 4,300,000 destinations is right out.
... have you
Marc A. Pelletier wrote:
...
http://www.ieee-security.org/TC/SP2012/papers/4681a332.pdf
...
have you actually /read/ that paper?
Of course I have. Have you read the conclusions at the bottom right of page
344? What kind of an adversary trying to infer our readers' article
selections is going to
Anthony wrote:
How much padding is already inherent in HTTPS?
None, which is why Ryan's Google Maps fingerprinting example works.
Citation needed.
... Seems to me that any amount of padding is going to give little
bang for the buck
Again, can we please procure expert opinions
On Fri, Aug 2, 2013 at 10:07 PM, Anthony wikim...@inbox.org wrote:
Anthony wrote:
How much padding is already inherent in HTTPS?
None, which is why Ryan's Google Maps fingerprinting example works.
Citation needed.
Also please address
please address
https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding
Sure. As soon as someone creates
http://en.wikipedia.org/wiki/Sunset_Shimmerso I can use an appropriate
example.
___
Wikimedia-l mailing list
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.
In this case, however, we have been discussing perfect forward
On Fri, Aug 2, 2013 at 11:09 PM, James Salsman jsals...@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
On Fri, Aug 2, 2013 at 11:33 PM, Anthony wikim...@inbox.org wrote:
AES and CBC, which would be a block cipher which pads to 128 or 256 bytes.
I mean bits, of course.
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe:
http://www.technologyreview.com/news/517781/math-advances-raise-the-prospect-of-an-internet-security-crisis/
is another example of a very highly placed secondary news source casting
fear, uncertainty, and doubt on the value of industry-standard encryption
practices which is not only based on the
21 matches
Mail list logo
