> And the argument that "random.c doesn't rely on the strength of crypto
> primitives" is kinda lame, though I see where you're coming from.
> random.c's entropy mixing and output depends on the (endian incorrect)
> SHA-1 implementation hard coded in that file to be pre-image resistant.
> If that fails (and a few other things) then it's broken.
/dev/urandom depends on the strength of the crypto primitives.
/dev/random does not. All it needs is a good uniform hash.
Do a bit of reading on the subject of "unicity distance".
(And as for the endianness of the SHA-1, are you trying to imply
something? Because it makes zero difference, and reduces the code
size and execution time. Which is obviously a Good Thing.)
As for hacking Fortuna in, could you give a clear statement of what
you're trying to achieve?
Do you like:
- The neat name,
- The strong ciphers used in the pools, or
- The multi-pool reseeding strategy, or
- Something else?
If you're doing it just for hack value, or to learn how to write a
device driver or whatever, then fine. But if you're proposing it as
a mainline patch, then could we discuss the technical goals?
I don't think anyone wants to draw and quarter *you*, but your
code is going to get some extremely critical examination.
-
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]
