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