Revise use of GnuPG 1.4.x

[druimalban]

It would be useful to have a newer version of GnuPG, or to include different options.
By using the latest stable series, we can make use of cv25519 keys, which have smaller key sizes for equivalent security as RSA-2048, and produce smaller signatures.

Some thoughts:

• We can reduce some space in the initramfs, although I'm not sure if this is really valid, because GnuPG 2.x may be more bloated than the savings in key size. It may depend on the configuration of GnuPG.
• We can sign and verify signatures more quickly, which may be useful for reducing boot-time, especially on lower-end devices, should we employ the set-up in such contexts.
• We can take advantage of ECC on certain experimental cryptographic tokens, such as devices implementing the Gnuk token (http://www.fsij.org/doc-gnuk/intro.html), and certain Java cards implementing the OpenPGP Card version 3 standard. (These may or may not be of the same standard of security as the Yubikey, it should be noted - I know that in the case of Gnuk token, they make use of a generic microcontroller. It's useful as a reference platform, I think, though.)

I understand there are problems in that there are more dependencies with GnuPG 2.x.
Other options might be:

• The NeoPG fork (https://github.com/das-labor/neopg- this is an experimental fork of GnuPG that changes perceived problems in the program being spun out into multiple components. It may or may not be suitable.
• OpenBSD's signify program (https://www.openbsd.org/papers/bsdcan-signify.html) - this is purely for signing, and makes compact signatures, and the program is very small. I'm not sure how well it supports smartcards, though, if at all. However, for some setups that don't want to install the entire GnuPG program, this could be very desirable.

[osresearch]

The dependencies for Gnupg 2.x were quite large, especially when we were trying to fit entirely in the 4MB upper flash of the x230. Now that we've abandoned that goal and are using both chips (and on servers have upwards of 64 MB), it might be reasonable to revisit.

I'm hesitant to use signify since it is a different tool than the "normal" gpg (and didn't support yubikey when I looked at it).

Can you build the newer gnupg version and figure out how much space is required?

[druimalban]

I played with the build system somewhat, and was able to make it build. Unfortunately, libgcrypt is not cross-compiling correctly, and I don't know why.
GnuPG 2.2 depends on the following components:

• libgpg-error: 349KB
• libgcrypt: a massive 4.0MB!
• libassuan: 404KB
• libksba: 845KB
• libnpth: 42KB

It installs the following components:

• gpg: 3.8MB
• gpg-agent: 1.6MB
• gpgconf: 492KB
• gpg-error and gpg-error-config: 66KB and 2.2KB respectively
• gpgscm: 802KB
• gpgsm: 2.0MB
• gpg-zip: 3.3KB
• ksba-config, libassuan-config, libgcrypt-config, npth-config: 2.6KB, 2.5KB, 3.9KB, 3.1KB respectively
• watchgnupg: 28KB

[tlaurion]

I have some issues with gpg provided with Heads and i'm not sure if it is a problem with Nitrokey firmware or with GnuPG 1.4.21 per se, provided through Heads or Heads problem.
Actually, there were no advertised changes in GnuPG that would resolve gpg --card-edit since 1.4.21.

Also, GnuPG 1.4.21 cannot generate 4096 keys nor take advantage of other crypto options.

When calling: gpg --card-edit and generating keys following the wiki page I get:

gpg: ccid_transceive failed: (0x1000a)
gpg: apdu_signal_simple(0) failed: card I/O error
gpg: generating key failed
gpg: key generation failed: general error
Key generation failed: general error

Any thought?

Can somebody confirm that generating keys from Heads works on a Yubikey?
@osresearch @kylerankin @kakaroto @flammit ?

[tlaurion]

Having gpg2 would fit inside 8mb, permit use of recovery shell to generate his keys directly on the Nitrokey Pro v2/Librem Key/Yubikey Neo (4096 bits too instead of 2048 currently) or offline and move subkey/private key to the smartcard, all of it being done from a trustworthy environment, flashed from a reproducible build.

Some users might want to generate their keys offline and move them inside Yubikey/Nitrokey. It is a more complicated process, documented at many places like this one .

The user should not have to trust another computer to enroll his own computer.

[tlaurion]

Actual passage to GnuPG2 is stopped because of pinentry not being called correctly. Any help welcomed.

[tlaurion]

Merged. Needs size reduction though.