Page MenuHome GnuPG

New entropy gatherer using the genentropy system call.
Closed, ResolvedPublic


Although the rndlinux.c gatherer can make use of getentropy, that gatherer has grown to quite some complexity. Thus for easier evaluation a new simple entropy gathering module should be implemented.

Event Timeline

werner triaged this task as Normal priority.Nov 15 2021, 7:29 PM
werner created this task.

Reading through the changes, the content and usage of the getentropy looks good.

But still, I have a couple of questions/comments in regards to random/rndlinux.c:

  • Does it still need the complexity of the getentropy syscall? I understand that it is more universal and might be useful in some platforms where the getentropy might be available but might not work. But then it is not a Linux anymore.
  • Would it make sense to rename it to something like random/rnddevices.c (we probably need a better name), to avoid confusion that this should not be used on linux anymore?
  • I see there also couple of conditions for mac/iphone -- are these going to use the new getentropy in the new rndgetentropy.c or the hybrid rndlinux.c (regardless the name?)?

Thank you for comments on random/rndlinux.c.

(1) I would like to avoid changes of the implementation of random/rndlinux.c, because of following reason.

  • the use cases of GNU/Linux is wide. There are some systems/architectures where the system still keeps using old GNU C library.
    • for those systems, I'd like to keep random/rndlinux.c, as-is, so that they can use it.
    • typical example: Network Attached Storage devices users want to upgrade libgcrypt (only) for new public key cipher, but not to want to replace glibc on the system.

(2) I agree that renaming would be good. It might be random_modele="oldlinux"

(3) For macOS, I think that when it's build on a system with getentropy available, it will use new rndgetentropy.c. When it's build on/for old system, it will use rndlinux.c as before (despite the name), with runtime check of getentropy in the C library and fallback to use of device. It's somehow complicated, in old macOS, getentropy is available as an API, but not as an implementation.

We talked today about the renaming the current "linux" entropy module to "oldlinux" would make sense.

I just also noticed the getentropy module is not yet mentioned in the doc/gcrypt.texi along with the rest of the modules.

One of the FIPS requirement is also the documentation so it would be great if you can review if it is up to date. Found couple of references to random-fips.c and the selftests information is also not up-to-date. We can bring it into the separate issue though if you prefer.

For the record, there is a new report on the mailing list about this module on MacOS:

gniibe removed a project: Restricted Project.