site  contact  subhomenews

Auto-generated gnupg signed-key pair

June 15, 2018 — BarryK

I posted yesterday about getting Flatpaks working in EasyOS. This required a signed-key pair in /root/.gnupg, which is created using the 'gpg' utility.

I wanted to automate this, so that it is something that the user will not have to bother with setting up. I want Flatpak apps installation to "just work".

To this end, I compiled 'gpg' statically in OE, with the musl library. I used version 1.4.23, not the 2.x series of gnupg. The old 1.4.x series is still being maintained, due to its usefulness in embedded systems. The 'gpg' utility in gnupg 1.4.23 has less dependencies, but the static stripped executable was still big, at 850KB.

In the gnupg source package, the 'configure' script has the '--enable-minimal' option, to build a very small executable, however, it was so cut-down as to be broken. Instead, I configured as follows, which actually created a smaller executable:

# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=x86_64-pc-linux-gnu --with-tar=/bin --disable-nls --disable-keyserver-path --disable-mailto --disable-finger --disable-hkp --disable-ldap --disable-keyserver-helpers --disable-photo-viewers --disable-bzip2 --disable-twofish --disable-blowfish --disable-idea --disable-agent-support --disable-card-support --disable-gnupg-iconv --disable-asm --enable-dev-random --enable-static-rnd=linux --without-readline --without-libusb --disable-camellia

Now for something contentious...

Prior to compiling, I edited 'config.h' and set NAME_OF_DEV_RANDOM to "/dev/urandom" instead of "/dev/random". The reason is, the kernel feeds activity to /dev/random, and when gpg is generating the signed-keys, it can suck everything from /dev/random and then block, waiting for the kernel to feed more random activity to /dev/random. On a running distro, this random activity is generated by usage, such as running an application, using the mouse, just about anything.

At bootup in the initrd, the situation is bleak if blocking happens. The way around it is for gpg to use /dev/urandom, which is like /dev/random except that it does not stop. If it runs out of random data, the kernel repeats whatever has already been sent. So no blocking occurs, and gpg generates the keys fast.

However, it must be understood that the generated keys are not as secure.

At first bootup, after the password is asked for, to encrypt folders in the working-partition, the same password is used as the passphrase to generate signed keys. The "real name" of the user is auto-generated as "EasyOS user $RANDOM". After bootup, look in /root/.gnupg and there they are, the signed-keys.

Note, there is /dev/hwrng, which apparently generates random data from the hardware, however, I do not know if it will work on all PCs, nor whether it is usable so early in the bootup.

Tags: easy