http://www.c0t0d0s0.org/archives/6349-Perceived-Risk.html
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
> 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
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
> 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
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
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
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
not only has someone got to find a collision during a tiny timeframe,
they also have to fit it in 8k
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-"
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
>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 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
> > 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
14 matches
Mail list logo
