> 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/
