Mailing List Archive

On Tue, 26 May 2020 15:35, Steffen Nurpmeso said:

> Fatal: no entropy gathering module detected

Which version of libgcrypt is that and what build options were used?


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Hello!

Werner Koch via Gnupg-users wrote in
<875zcgtizp.fsf@wheatstone.g10code.de>:
|On Tue, 26 May 2020 15:35, Steffen Nurpmeso said:
|> Fatal: no entropy gathering module detected
|
|Which version of libgcrypt is that and what build options were used?

Oh, sorry. That is on CRUX-Linux 3.5

#?0|kent:$ prt-get info libgcrypt
Name: libgcrypt
Path: /usr/ports/opt
Version: 1.8.5
Release: 1
Description: A general purpose cryptographic library based on GnuPG
URL: http://www.gnupg.org
Maintainer: Thomas Penteker, tek at serverop dot de
Dependencies: libgpg-error
#?0|kent:$ cat /usr/ports/opt/libgcrypt/Pkgfile
# Description: A general purpose cryptographic library based on GnuPG
# URL: http://www.gnupg.org
# Maintainer: Thomas Penteker, tek at serverop dot de
# Depends on: libgpg-error

name=libgcrypt
version=1.8.5
release=1
source=(ftp://ftp.gnupg.org/gcrypt/libgcrypt/$name-$version.tar.bz2)

build() {
cd $name-$version

./configure \
--prefix=/usr \
--disable-padlock-support \
--enable-static=yes
make
make DESTDIR=$PKG install

rm -r $PKG/usr/share/info
}

Our C library is

#?0|kent:$ prt-get info glibc
Name: glibc
Path: /usr/ports/core
Version: 2.28
Release: 2
Description: The C library used in the GNU system
URL: http://www.gnu.org/software/libc/
Maintainer: CRUX System Team, core-ports at crux dot nu
Files: post-install

and it is configured in essence via

--with-headers=$PKG/usr/include \
--enable-kernel=4.9 \
--enable-add-ons \
--enable-static-nss \
--enable-stack-protector=strong \
--enable-obsolete-rpc \
--enable-obsolete-nsl \
--disable-profile \
--disable-werror \
--without-gd \
--enable-multi-arch

He is a busy Siemens security guy i think, but the ArchLinux
libgcrypt comes on over with the same recipe?

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)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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).

Are you running in FIPS mode?

Can you run the Libgcrypt test suite? In particular

$ libgcrypt/tests/version
$ libgcrypt/tests/random --verbose --debug


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Hello.

Werner Koch wrote in
<87sgfjrqf1.fsf@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)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hello Werner, all.

Steffen Nurpmeso wrote in
<20200529155411.TgyU1%steffen@sdaoden.eu>:
|Werner Koch wrote in
|<87sgfjrqf1.fsf@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)

Steffen Nurpmeso wrote in
<20200529202134.6LZBJ%steffen@sdaoden.eu>:
|Steffen Nurpmeso wrote in
|<20200529155411.TgyU1%steffen@sdaoden.eu>:
||Werner Koch wrote in
||<87sgfjrqf1.fsf@wheatstone.g10code.de>:
|||On Thu, 28 May 2020 14:43, Steffen Nurpmeso said:
...
|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.

Maybe, but it was not.
Please find attached a second one to be applied on top, it fixes
some preprocessor problems.

Please just feel free to take those, and commit under your name or
any way you like it. Joining them into one would be nice...

Thank you, and 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)

Steffen Nurpmeso wrote in
<20200530145210.EwnnE%steffen@sdaoden.eu>:
|Steffen Nurpmeso wrote in
|<20200529202134.6LZBJ%steffen@sdaoden.eu>:
||Steffen Nurpmeso wrote in
||<20200529155411.TgyU1%steffen@sdaoden.eu>:
|||Werner Koch wrote in
|||<87sgfjrqf1.fsf@wheatstone.g10code.de>:
||||On Thu, 28 May 2020 14:43, Steffen Nurpmeso said:
| ...
||So with the attached patch libgcrypt solely relies upon getentropy

I realized i am in fact subscribed to -devel and moved this over.
Thank you, and 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)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Fri, 29 May 2020 17:54, Steffen Nurpmeso said:

> 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.

Which was not available back then when I implemented support for
getrandom. Further; there is no guarantee that getrandom(2) is
supported on all machines. We care a lot about backward compatibility
and can't simply demand a certain Linux kernel or glibc version.


> i would change, maybe with a new call-in to rndlinux.c which
> should be made responsible for Linux-only environmental detections

You don't change audited RNG code if there is not a very good reason for
that.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.