introduce a thread-local Cryptographically Secure Pseudo Random Number Generator for general use #6704
Comments
andrewrk
added
standard library
The space requirement for the Gimli rng are negligible as it only uses 48 bytes of memory. Fetching entropy at startup is also needed to initialize the stack canaries (not yet implemented, we need a way to tell LLVM not to emit the stack protector sequence in the early startup functions). On Linux you get 16 bytes of good ™️ entropy for free via the |
16 bytes is sufficient (cryptographically); it would be safe to extend. See #6622 (comment) for further discussion.
It comes straight out of the kernel CSPRNG via |
I was talking of the idea of stretching the 16 (or 8, if we don't want to reuse the first 8) bytes of
I'll take your word on this. |
std.crypto.random * cross platform, even freestanding * can't fail. on initialization for some systems requires calling os.getrandom(), in which case there are rare but theoretically possible errors. The code panics in these cases, however the application may choose to override the default seed function and then handle the failure another way. * thread-safe * supports the full Random interface * cryptographically secure * no syscall required to initialize on Linux (AT_RANDOM) * calls arc4random on systems that support it `std.crypto.randomBytes` is removed in favor of `std.crypto.random.bytes`. I moved some of the Random implementations into their own files in the interest of organization. stage2 no longer requires passing a RNG; instead it uses this API. Closes #6704
std.crypto.random * cross platform, even freestanding * can't fail. on initialization for some systems requires calling os.getrandom(), in which case there are rare but theoretically possible errors. The code panics in these cases, however the application may choose to override the default seed function and then handle the failure another way. * thread-safe * supports the full Random interface * cryptographically secure * no syscall required to initialize on Linux (AT_RANDOM) * calls arc4random on systems that support it `std.crypto.randomBytes` is removed in favor of `std.crypto.random.bytes`. I moved some of the Random implementations into their own files in the interest of organization. stage2 no longer requires passing a RNG; instead it uses this API. Closes #6704
std.crypto.random * cross platform, even freestanding * can't fail. on initialization for some systems requires calling os.getrandom(), in which case there are rare but theoretically possible errors. The code panics in these cases, however the application may choose to override the default seed function and then handle the failure another way. * thread-safe * supports the full Random interface * cryptographically secure * no syscall required to initialize on Linux (AT_RANDOM) * calls arc4random on systems that support it `std.crypto.randomBytes` is removed in favor of `std.crypto.random.bytes`. I moved some of the Random implementations into their own files in the interest of organization. stage2 no longer requires passing a RNG; instead it uses this API. Closes #6704
std.crypto.random * cross platform, even freestanding * can't fail. on initialization for some systems requires calling os.getrandom(), in which case there are rare but theoretically possible errors. The code panics in these cases, however the application may choose to override the default seed function and then handle the failure another way. * thread-safe * supports the full Random interface * cryptographically secure * no syscall required to initialize on Linux (AT_RANDOM) * calls arc4random on systems that support it `std.crypto.randomBytes` is removed in favor of `std.crypto.random.bytes`. I moved some of the Random implementations into their own files in the interest of organization. stage2 no longer requires passing a RNG; instead it uses this API. Closes ziglang#6704
@jedisct1 writes in #6622 (comment):
The idea behind it being thread-local is that it would not cause any contention or syscalls when multiple threads simultaneously want to use a CSPRNG. However, I do think we should use comptime logic to detect if
arc4randomwill be available, and use that as the backing function call instead of duplicating RNG code in the runtime binary. This should be handled transparently so that a higher level interface does not have to care about these details.There are several calllsites right now that use
std.crypto.randomByteswhich would be improved to use this API because it would prevent unnecessary syscalls. Even the initial seed syscall can be elided in some cases; for example it would be appropriate for zig start code to use AT_RANDOM from the linux "auxval" to perform the initial seed in the main thread.One thing to consider is, optimally, we would not want to pay the cost of initializing the RNG before main() and with the spawn of each thread, and the cost of the Thread Local Storage, and the cost of the binary bloat, if the RNG does not end up being used. It is unclear how this could be accomplished, however, I am OK with proceeding on this now and trying to solve this optimization problem later.
The text was updated successfully, but these errors were encountered: