-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Description
On Linux, we use /dev/urandom as a source of cryptographically random data in minipal_get_cryptographically_secure_random_bytes
runtime/src/native/minipal/random.c
Lines 102 to 107 in 14c80b0
| #if HAVE_O_CLOEXEC | |
| fd = open("/dev/urandom", O_RDONLY | O_CLOEXEC); | |
| #else | |
| fd = open("/dev/urandom", O_RDONLY); | |
| fcntl(fd, F_SETFD, FD_CLOEXEC); | |
| #endif |
This is perfectly fine for getting cryptographically random data.
Linux has, for a time now, supported getrandom(2) as a means of generating cryptographically random data.
This particular API has also been a focus of performance lately, and it is expected to get faster with a vDSO implementation.
Even using getrandom today on Ubuntu 24.04 yield some performance improves in Guid.NewGuid. A quick spike shows some promising performance improvements, such as in Guid.NewGuid
| Method | Job | Toolchain | Mean | Error | StdDev | Ratio | Allocated | Alloc Ratio |
|---|---|---|---|---|---|---|---|---|
| Guid_NewGuid | Job-FLNCIL | pr | 256.0 ns | 1.02 ns | 0.95 ns | 0.87 | - | NA |
| Guid_NewGuid | Job-PIPFED | .NET 9.0 | 295.9 ns | 0.82 ns | 0.76 ns | 1.00 | - | NA |
Indicating an improvement of about 13%.
Perhaps we should consider using getrandom(2), if it is available, for acquiring cryptographically random data.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status