libgcrypt: random source via library on Linux?

Steffen Nurpmeso steffen at sdaoden.eu
Fri May 29 17:54:11 CEST 2020


Hello.

Werner Koch wrote in
<87sgfjrqf1.fsf at wheatstone.g10code.de>:
 |On Thu, 28 May 2020 14:43, Steffen Nurpmeso said:
 |>     ./configure \
 |>         --prefix=/usr \
 |>         --disable-padlock-support \
 |>         --enable-static=yes
 |>     make
 |>     make DESTDIR=$PKG install
 |
 |That is pretty standard except for the --disable-padlock-support - why
 |do you use this?  Padlock is only used on VIA CPUs and has an auditable
 |design in contrast to RDRAND (which is used by Libgcrypt be default).

I am overasked why this is done.  I have not looked for how RDRAND
bugs are handled by libgcrypt either, Werner.  Wait.  Sigh.

Looking at the source it seems libgcrypt knows about the Linux
getrandom systemcall.  Yet it does not seem to know about glibc's
getrandom library function.

Hm, so why does random/random-csprng.c:getfnc_gather_random() look
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) !=
my_pid || !add)"; ah i see the FDs could become cached (until
fork), .. and then the getrandom syscall is tried even though FDs
have been opened despite its presence.  This, excuse me ;),
i would change quite a bit.  I would not do any FD related thing
at all if getrandom is available, and i, for the MUA i maintain,
simply look for getrandom, library or syscall (the latter came
first; users can explicitly specify via VAL_RANDOM what they want,
though).

Looking at the development version now it finally seems to me that
the library call is supported.

I still would not do it like that, because if software cannot rely
on what has been detected at configuration time all bets are off.
I must admit i do the NOSYS check myself for this thing, but only
for it, not for anything else.  Also not for "system calls" which
change behaviour dependent on library symbol version
(realpath(2/3) comes to mind, exclusively).

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

Well i could.  Is this still of interest?

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)



More information about the Gnupg-users mailing list