> > If you are really paranoid and don't want any collisions in the next
> > 10 years: don't let strangers in your venti.
>
> Which, to close the circle, as Tim points out, you are always doing,
> each time you receive an email :-)
not all email is from strangers.
in mbox format, messages are co
On Tue, Feb 9, 2010 at 5:13 AM, hiro <23h...@googlemail.com> wrote:
> If you are really paranoid and don't want any collisions in the next
> 10 years: don't let strangers in your venti.
Which, to close the circle, as Tim points out, you are always doing,
each time you receive an email :-)
ron
>I feel compelled to add that hardware
>uncorrectable bitflips are still reported as erasures, whereas venti
>collisions are reported as success and only caught if somebody's doing
>checksumming at larger granularity.
Uncorrectable bitflips can also be unreported.
If you are really paranoid and d
On Sun, Feb 07, 2010 at 10:08:39PM +, matt wrote:
> not only has someone got to find a collision during a tiny timeframe,
> they also have to fit it in 8k
MD5 collisions can, apparently, be constructed in 24 hours on a laptop these
days. Yes, it's a constraint, but.
Venti supports larger b
About a year ago i wrote a (kind of vapourware) backup system called Baccus,
based on content addressed storage. Most ideas are stolen from Plan9/venti,
but for the here discussed reasons i used the Salsa family of hashes
from Dan
Bernstein:
http://cr.yp.to/chacha.html
Respectively the Rumba-"
not only has someone got to find a collision during a tiny timeframe,
they also have to fit it in 8k
1. the sender can't control email headers. many
transfer agents add a random transfer-id which
would confound this attack.
If you know the size of the transfer id, you can pad out
to the next full block size.
2. if the rcpt uses mbox format, the sender can't
control how your message is fit
On Sun, Feb 07, 2010 at 12:44:52PM -0500, erik quanstrom wrote:
> 1. the sender can't control email headers. many
> transfer agents add a random transfer-id which
> would confound this attack.
>
> 2. if the rcpt uses mbox format, the sender can't
> control how your message is fit into venti blo
The e-mail trick is just an example, but the scenario is still valid.
Consider an alternative scenario where an attacker is able to upload
files to your server (perhaps jpg, gif, etc) via a web application or
FTP server. Or perhaps, if someone were able to contribute source or a
tarball by uploadin
> OK, lets assume that the attacker has the most powerful attack
> against a hash available in which he can construct a garbage
> block of data (perhaps with some control of its content) that
> hashes to a value of his choosing. Now he predicts some data
> that is likely to be written to your file
Sorry, this is all bunk. You shouldn't be worried about
an accidental collision. You should be worried about
an intentional collision. Especially if your filesystem
stores data that is under the attackers control such as
email messages, web page caches, etc. So what you need
to analyze isn't h
> Sorry, this is all bunk. You shouldn't be worried about
> an accidental collision. You should be worried about
> an intentional collision. Especially if your filesystem
> stores data that is under the attackers control such as
> email messages, web page caches, etc. So what you need
> to anal
http://www.c0t0d0s0.org/archives/6349-Perceived-Risk.html
Sorry, this is all bunk. You shouldn't be worried about
an accidental collision. You should be worried about
an intentional collision. Especially if your filesystem
stores data that is under the attackers control such as
email messages
http://www.c0t0d0s0.org/archives/6349-Perceived-Risk.html
14 matches
Mail list logo