Hello Everyone, I am a cryptographer, a hacker, and exploit developer. I am an accomplished security engineer, and I've even hacked Majordomo2, the maling list we are using now (CVE-2011-0049). It is highly unusual that /dev/random is allowed to degrade the performance of all other subsystems - and even bring the system to a halt when it runs dry. No other kernel feature is given this dispensation, and I wrote some code to prove that it isn't necessary. Due to a lockless design this proposed /dev/random has much higher bandwidth for writes to the entropy pool. Furthermore, an additional 8 octets of entropy is collected per syscall meaning that the random source generated will be difficult to undermine. This is an experimental subsystem that is easy to compile and to verify: https://github.com/TheRook/KeypoolRandom Should compile right after cloning, even on osx or windows - and feedback is welcome. I'm making it easy for people to verify and to discuss this design. There are other cool features here, and I have a detailed writeup in the readme. A perhaps heretical view is that this design doesn't require handle_irq_event_percpu() to produce a NIST-compliant CSPRNG. Which is a particularly useful feature for low power usage, or high performance applications of the linux kernel. Making this source of entropy optional is extremely interesting as it appears as though Kernel performance has degraded substantially in recent releases, and this feature will give more performance back to the user who should be free to choose their own security/performance tradeoff. Disabling the irq event handler as a source of entropy should not produce an exploitable condition, A keypool has a much larger period over the current entropy pool design, so the concerns around emptying the pool are non-existent in the span of a human lifetime. All the best, Micahel Brooks https://stackoverflow.com/users/183528/rook https://stackoverflow.com/tags/cryptography/topusers #9 https://stackoverflow.com/tags/security/topusers #4
