Skip to content

[th/bad-random-bytes] glib-aux: rework fallback random generator to use sha256

Thomas Haller requested to merge th/bad-random-bytes into main

nm_utils_random_bytes() tries to get good randomness. If it fails, we still try our own approach, but also signal that the returned numbers are bad. In practice, none of the callers cares about the return value, because they wouldn't know what to do in case of bad randomness (abort() is not an option and retry is not expected to help and sending an email to the admin isn't gonna help either). So the fallback case really should try its best.

The fallback case depends on a good random seed and a good pseudorandom number generator.

Getting a good seed is in reality impossible, after kernel let us down. That is part of the problem, but we try our best.

The other part is to use a cryptographic pseudorandom number generator. GRand uses a Mersenne Twister, so that is not good enough. In this low level code we also cannot call gnutls/nss, because usually we don't have that dependency. Maybe we could copy&paste the chacha20 implementation, it's simple enough and a compatible license. That might be good, but instead cock our own by adding some sha256 into the mix. This is fallback code after all, and we want to try hard, but not that hard to add chacha20 to NetworkManager.

So, what we do is to use a well seeded GRand instance, and XOR that output with a sha256 digest of the state. It's probably slow, but performance is not the issue in this code path.

Merge request reports

Loading