libgcrypt: random source via library on Linux?

Steffen Nurpmeso steffen at sdaoden.eu
Fri May 29 22:21:34 CEST 2020


Hello Werner, all.

Steffen Nurpmeso wrote in
<20200529155411.TgyU1%steffen at sdaoden.eu>:
 |Werner Koch wrote in
 |<87sgfjrqf1.fsf at wheatstone.g10code.de>:
 ||On Thu, 28 May 2020 14:43, Steffen Nurpmeso said:
 ...
 |out for NAME_OF_DEV_*RANDOM at all .. hmm .. i must admit
 |random/rndlinux.c:_gcry_rndlinux_gather_random() seems strange to
 |me.  :)  Two possible calls to getpid, could be "((apid = XPID) !=
 ...
 |I still would not do it like that, because if software cannot rely
 ...
 |Anyhow, unless i am mistaken from this five minute looking, that
 |random/random-csprng.c:getfnc_gather_random()
 |
 |  #if USE_RNDLINUX
 |    if ( !access (NAME_OF_DEV_RANDOM, R_OK)
 |         && !access (NAME_OF_DEV_URANDOM, R_OK))
 |      {
 |        fnc = _gcry_rndlinux_gather_random;
 |        return fnc;
 |}
 |  #endif
 |
 |i would change, maybe with a new call-in to rndlinux.c which
 |should be made responsible for Linux-only environmental detections
 |imho.  Like that it could solely depend on getrandom, and make all
 |the FDs optional, maybe by testing for NOSYS with a one byte read
 |or what at first, or by later aborting if collecting random fails
 |if that is possible.  (For my MUA i use this for seeding only
 |anyhow.)
 |
 ||Are you running in FIPS mode?
 ||
 ||Can you run the Libgcrypt test suite?  In particular
 ||
 ||$ libgcrypt/tests/version
 ||$ libgcrypt/tests/random --verbose --debug

So with the attached patch libgcrypt solely relies upon getentropy
if available, no FD handling is done no more if at all possible.
The test suite passes, a short review makes me think it is alright.

- The setup could block when the OS cannot serve 1 byte of strong
  entropy.  This is different to before, access(2) does not.

  (On the other hand neither on OpenBSD nor on newer Linux (5.4 or
  5.6 i think) this should matter.  And it is likely it does not
  elsewhere, either people seem to have used things like my
  entropy-saver or even hammers like haveged which reveal how
  strange entropy counting was, imho.)

- Some tests aka code places directly reach into
  _gcry_rndlinux_gather_random() and thus only give errors in
  open_device() not the warning that initiated this ML thread.
  This i did not get at first, the tests suite passed nonetheless.

- P.S.: even if this patch is not used, i would suggest an audit
  of this file.

- RANDOM_CONF_ONLY_URANDOM lost its meaning in the past, and this
  patch does not reinstantiate that.  It cannot be done portably,
  except for OSs which provide getrandom(2).

- I shortly thought about using "extern", but i think doing so in
  an isolated fashion is surely wrong.

Ciao,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcrypt-linux.diff
Type: text/x-diff
Size: 11006 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200529/69d718ea/attachment-0001.diff>


More information about the Gnupg-users mailing list