On Thu, Feb 16, 2012 at 8:45 PM, <[email protected]> wrote: > Nico Williams wrote: > >> Applications (in the Unix sense) should not be the ones seeding the > system's PRNG. The system should ensure that there is enough entropy > and seed its own PRNG (and mix in new entropy). > > Exactly the opposite. > > Application creator/maintainer is always in the trust chain; this can not > be avoided. As the well-known Debiandebacle demonstrated, there is > every good reason to remove the operating system creator/maintainer > from the trust chain. There is a reasonable chance that a security-critical > application is constructed and maintained by someone who is skilled > in security programming; there is very low chance this is the case with > the operating system.
Debian was a distribution, and its maintainers had the responsibility to put the system together correctly. They're failure is no more an indictment of all operating systems than any one application bug is an indictment of all applications. Just what is an operating system anyways? Just a kernel? What about the boot loader? Or the C library, or the utilities needed to get to a running system? Is OpenSSL part of the system if it's shipped with the OS? And if you can't trust the OS for entropy, why trust it to run the application at all? Who knows what side channels a poor OS might result in. Or a VM environment. My rationale for the above statement is that an application by itself has no entropy. Entropy has to be gathered from something else. The application might be able to gather some, or not. As a user it's hard to say, but the operating system can definitely see to it that it has some entropy, and the OS maintainers had better see to it that the OS can and does gather entropy (/dev/*random is clearly evidence that OS developers agree). I can understand *portable* applications (and libraries) having entropy gathering code on the argument that they may need to run on operating systems that don't have a decent entropy provider. Nico -- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
