randombit
Add Entropy Source and DRNG Manager (ESDM) RNG support
ESDM is a Linux-based user-space PRNG daemon, with configurable entropy sources.
See: https://github.com/smuellerDD/esdm
It currently gets used, when a high level of control over entropy sources is desirable, e.g. for VPN appliance solutions.
In order to use this source, the ESDM server daemon has to be running and botan must be configured --with-esdm.
ESDM currently works only on Linux.
I tested the FFI-Bindings against https://github.com/thillux/botan-rs/tree/esdm-rng.
e.g. the following worked as expected:
let mut rng = RandomNumberGenerator::new_esdm_pr().unwrap();
for _ in 0..10 {
let bytes = rng.read(32);
println!("{bytes:x?}");
}
@reneme I reformatted the code with clang-format, after looking at the CI results.
coverage: 91.257% (-0.01%) from 91.271% when pulling 8a5a8ccc8cb2ee8d1ece350027b0fb67ba5992b7 on thillux:esdm-rng into ac23bcb4e3f783e860daf85df0ff874843526e34 on randombit:master.
I reformatted the code with clang-format, after looking at the CI results.
Thanks! FYI: There are some Emacs, VS Code and .editorconfig config files in src/editors. In case you use any of this, you might want to symlink them into the repo's root dir and benefit from things like "format on save".
So the change already looks pretty good, I think reneme already hit most of the points I would raise on it, but I am going to have to be a downer here and ask
Can you expand more on where and how ESDM is used? It does not seem to be widely distributed, eg per https://repology.org/project/esdm/versions it is only included in AUR and nix (the Debian experimental listing is a name collision with another package). In general our integrations with other systems have been for very widely deployed (eg TPM, PKCS11, OS provided interfaces, or widely deployed libs like zlib or sqlite3) and I'm hesitant to accept something that is so niche.
I'm pretty sure it doesn't work on Mac, for example. No idea if it runs on Windows.
So the change already looks pretty good, I think reneme already hit most of the points I would raise on it, but I am going to have to be a downer here and ask
Can you expand more on where and how ESDM is used? It does not seem to be widely distributed, eg per https://repology.org/project/esdm/versions it is only included in AUR and nix (the Debian experimental listing is a name collision with another package). In general our integrations with other systems have been for very widely deployed (eg TPM, PKCS11, OS provided interfaces, or widely deployed libs like zlib or sqlite3) and I'm hesitant to accept something that is so niche.
You're right with ESDM being niche from a major Linux distribution point of view. I cannot weaken/invalidate this argument.
ESDM is currently mostly used under the public radar I would say. My company uses it to provide randomness in a regulated/certified market, on an installed base of >= 100k Linux-based notebooks and plans to use ESDM in more products in the future.
For such a usage in a regulated market or for governmental customers, it offers the following key benefits from my point of view:
- In combination with ESDM Botan can offer a NIST SP800-90B/C compatible RNG
- ESDM offers more control over configured entropy sources, when needed, without the need for a developer to change Botan
- ESDM can also use Botan for its internal cryptographic primitives, so less certification/code review work necessary for the developer
- ESDM is currently the only way to conform to the upcoming NTG.1 definition of the AIS 20/31 2024 from BSI in Germany
- It is easier to comply with changing governmental requirements in user-space in ESDM, than in kernel space (e.g. change /dev/random)
I'm pretty sure it doesn't work on Mac, for example. No idea if it runs on Windows.
That's correct, it runs on Unix/Linux.
I started working on your suggestions and will squash them together again, when finished.
This seems interesting and the code looks good already. Thanks for the contribution! I've left a few suggestions down below.
Is there a way to test this in CI? I'd hope that we could just install and configure the daemon in
src/scripts/ci/setup_gh_actions.shand run a few basic smoke tests against it in the unit tests.
How can I test this by myself? I think I'll need some iterations to get this running.
How can I test this by myself? I think I'll need some iterations to get this running.
The repository policy doesn't let first-time contributors run the CI pipeline. You could iterate in a branch on your private fork, though. For a full end-to-end test, unfortunately the process is commit->push->fail->fix->commit :cry:
You can, however, run the underlying CI script locally (that assumes that setup_gh_actions.sh -- or something else -- has already prepared the environment). Simply run: src/scripts/ci_build.py shared to run most things the CI would for the 'shared' (library) target.
That's correct, it runs on Unix/Linux.
Does Botan aim to only run on Linux? And at that, on one (possibly major) distribution of Linux?
That's correct, it runs on Unix/Linux.
Does Botan aim to only run on Linux? And at that, on one (possibly major) distribution of Linux?
The ESDM_RNG class is added as optional dependency. On Windows and/or MacOS it just can't be used. This PR does not limit Botan to only Linux.
I'm maybe too stupid to get esdm-server started for the coverage and sanitizer targets. I'll pushed a fix that hopefully works.
@reneme @randombit Is there something left in this PR which I have to adapt to and was not aware of?
I applied your suggestions and squashed them together with my last commit as suggested. Thanks for your review @reneme!
@randombit Thanks for your feedback! If you can live with the current state, I'll squash the WIP commit. I just left it for now, in order to make it easier to look at the changes related to your suggestions.
Thanks @thillux LGTM pending a final squash
Thanks for your review, squash is now pushed.