Messages in this thread | | | Date | 15 Apr 2005 16:50:36 -0000 | From | linux@horizon ... | Subject | Re: Fortuna |
| |
> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |