From: Matt Mackall <[email protected]>
Date: Sat, 6 May 2006 23:59:20 -0500
> First, since the existence of /dev/random's entropy accounting scheme
> is predicated on the assumption that we can break the hash function at
> will, I'll replace SHA1 with, oh, say, CRC-16. This'll be illustrative
> until someone has a nice preimage attack against SHA1.
I don't understand why you're changing one of the preconditions
in order to "prove" that what we have now can be broken. This
is more swiss cheese theory.
We use SHA1 right now, so you have to use SHA1 in your reproducable
attack. Since there is no preimage attack for SHA1 you can't
prove that it can be done.
> Then I'll run my test on one of the various arches where HZ=~100 and
> we don't have a TSC. Like Sparc?
>
> /* XXX Maybe do something better at some point... -DaveM */
> typedef unsigned long cycles_t;
> #define get_cycles() (0)
You're really stretching things here, using a platform that is
basically in almost no usage at all. Sure if you use a silly
example, almost anything is possible. CRC-16 and sparc 32-bit,
give me a break.
And the remote person has to know that the machine is a 32-bit sparc
box, good luck with that. And this is yet another variable amongst
all of the highly variable and unpredictable delays between packet
visibility on the wire and the actual interrupt being serviced, which
you have not addressed at all.
You haven't addressed the real case that matters, the ones on
platforms that have a TSC that works and with SHA1.
Until you prove that can be broken, you are simply still spewing
more of your incredible swiss cheese theory. Don't give me any
crap about an almost entirely abandoned architecture that doesn't
implement TSC, and using algorithms other than SHA1. The real code
uses SHA1, so that's what you have to prove can be broken.
You're just circling around the real issues and trying to be "right"
and this is what I dislike so much about theoretical people. They
show you what can be done theoretically, yet never in practice with
what we really have now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
