A new C++ random number generation library featuring WELL (Well Equidistributed Long-period Linear) generators has ignited passionate discussions in the programming community about whether cryptographically secure random number generators should be the default choice for all applications.
The library, which focuses on high-performance pseudo-random number generation with features like cross-platform reproducibility and optimized distribution algorithms, has become the center of a broader philosophical debate about security versus performance in software development.
WELL Generator Family Comparison
- WELL44497b vs WELL19937a show "reversed" results in TestU01 across different programming languages
- State space size optimization depends primarily on TBit and MASK values
- Additional parameters (K, J) provide constraints but don't significantly impact test battery performance
The Security-First Argument Faces Strong Pushback
One of the most contentious points emerged when a developer argued that there are vanishingly few use cases for non-crypto RNGs and suggested that all random number generation should be cryptographically secure by default. This position, advocating for algorithms like Randen that provide provable security guarantees, met with significant resistance from the community.
Critics quickly pointed out the massive performance implications of this approach. Multiple developers highlighted that numerous industries including science, neural networks, simulation, gaming, rendering, weather modeling, nuclear research, robotics, and signal processing require billions to trillions of random numbers quickly. For these applications, the overhead of cryptographically secure generators would be prohibitive.
Security Considerations
- ChaCha CSPRNG implementation may have insufficient seed entropy (32-64 bits)
- Output stream wraps after 2^32 blocks, could be expanded
- Randen algorithm provides provable security based on AES primitives
- Linux vDSO getrandom() offers fast cryptographically secure random numbers (merged July 2024)
API Design Philosophy Sparks Technical Discussion
The conversation also delved into fundamental API design principles, particularly around seeding mechanisms. Developers debated whether convenience functions should allow manual seeding or always use entropy sources. The discussion revealed a classic tension between backward compatibility and security improvements, with references to how legacy systems like glibc's rand() function remain stuck with outdated algorithms due to API contracts.
One interesting technical solution proposed involved using thread-local storage to provide both convenience and proper seeding, demonstrating how modern C++ features can address traditional random number generation challenges.
Performance Claims Draw Skepticism
The library's performance benchmarks, showing some generators running at 100-105% of standard library performance, raised eyebrows among experienced developers. Some questioned the believability of these figures, while others focused on more practical concerns like the library's approach to floating-point number generation and cross-platform consistency.
The discussion also touched on emerging kernel-level solutions like Linux's vDSO getrandom(), which provides fast access to cryptographically secure random numbers, though developers noted this is still significantly slower than specialized pseudo-random generators for high-throughput applications.
Performance Comparison Claims
- std::minstd_rand: 100% baseline performance
- std::mt19937: 105% of baseline performance
- Library claims faster uniform/normal distributions with cross-platform sequence consistency
- Fast normal distribution using popcount-based binomial approximation for gaming/fuzzing applications
The Verdict: Context Matters
The debate ultimately reinforced a key principle in software development: choosing the right tool for the job. While cryptographically secure generators are essential for security-sensitive applications, the vast majority of random number usage in scientific computing, gaming, and simulation work requires the speed and determinism that specialized pseudo-random generators provide.
Use the right tool for the job. Widen your view of what things are used for.
The discussion highlighted how different domains have vastly different requirements, and that blanket recommendations for always using cryptographically secure generators fail to account for the diverse needs of the programming community.
Reference: well-random