[Announce] The maybe final Beta for GnuPG 2.1

[Pete Stephenson]

On Fri, Oct 3, 2014 at 4:35 PM, Werner Koch <wk at gnupg.org> wrote:
> Hello!
>
> I just released another *beta* version of GnuPG *2.1*.  It has been
> released to give you the opportunity to check out new features and to
> help fixing bugs.

Hi all,

I had a few minor issues/questions with GnuPG 2.1 beta895 that I
thought would be good to report/ask here:

1. Default key prefs[1] don't seem to permit encrypting+signing a
message to a brainpoolP512r1 key. Evidently that curve requires SHA512
only for signatures, and all other algorithms will fail. Since SHA256
and SHA384 are prioritized over SHA512 by default in the key prefs, an
error occurs.

Here's an excerpt of the terminal output, where AF25682B is a primary
test key using brainpoolP512r1 while D74B165F is a test encryption
subkey using the same curve:

=====
pete at kaylee:~/gpg/gnupg-2.1.0-beta895/PLAY/inst/bin$ ./gpg2 --homedir
~/gnupg/ --encrypt --armor --sign -r AF25682B
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Hello world!
gpg: ECDSA key D74B165F requires a 512 bit or larger hash (hash is SHA256)
gpg: checking created signature failed: General error
gpg: signing failed: General error
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

hL4DWouX3RbM7L4SBAMEbW91unR/0/0QZ9fxeeIo9StkO2c90E9RQT9Cxy4yM7pI
dz3siYcAgzEtohdCcpy8BWCPRscqyUcD9iX/QDcxpj3CGG3RHJWdq8ezXVg2m460
ONeb1SnkQGxKsU7oDOo5lu6qQ+pAsvEqhKooyBxlIXPu/qqrtkx3DTvmCudld+Aw
od3AWiOPPQOSAzkRDSfk12/FhrWsZUz/q7mq0W/DlYem+B0OvOD+n1dcPDuAJAXR
gpg: [stdin]: sign+encrypt failed: General error
=====

Is it normal/desired for 512-bit curves to only work with SHA512? If
so, shouldn't a newly-minted key have default prefs appropriate for
that key so it will work as expected?

If a 512-bit digest is required for a 512-bit ECC key, shouldn't the
signing system know that and be able to override the key prefs that
might specify a non-512-bit digest?

Similarly, brainpoolP512r1 curves seem unable to make a signature
using digest algorithms other than SHA512. For example, if a
brainpoolP512r1 key is encrypting+signing a message to another key
with the default prefs, it uses SHA512. Is this intended?

Signing/clearsigning a message with a brainpoolP512r1 curve also uses
SHA512, even if one tries to override it. In this example, I try to
override it by using SHA1 instead of SHA512:

pete at kaylee:~/gpg/gnupg-2.1.0-beta895/PLAY/inst/bin$ ./gpg2 --homedir
~/gnupg/ --armor --clearsign -u AF25682B --personal-digest-preferences
SHA1
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Test.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Test.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJ4EARMKAAYFAlRTekYACgkQRgJQM68laCuoDwH+KNKsSm01h6lJ659FDEGDoorM
/TpWvaVyVbvRa4+8Xya6+c73jt6jSDAeJZMEFBBQYIx3tJy7T6eowYgx3P2eUAIA
gvlSuuFVLqiV2Iujd0oa46PEnZZnxIz8Di6vUWqDq/WhhASDuQiidqc1zQ2VexP8
ET23riihBSBDTdTTR8Dp2Q==
=sUNG
-----END PGP SIGNATURE-----

2. While Curve25519-based keys can be used for signing using Ed25519,
there doesn't seem to be any way to use Curve25519 for encryption.
While one could use non-Curve25519 subkeys for encryption, that seems
a little sub-optimal. I assume this is known already and will be
resolved prior to the production release.

3. Curve25519 has a security level of 128-bits. In addition to the
Brainpool curves, are there any plans to add other curves with higher
security levels like Curve41417 (>200-bits)? I ask simply because
having various components (e.g. the symmetric, asymmetric, and hash
algorithms) at similar security levels is logical: it wouldn't make
sense to, for example, use 1024-bit RSA with SHA512 due to the wide
difference in security levels, but using a 3072-bit RSA key with
SHA256 would be logical.

4. Are there any plans to add user-specified arbitrary curves in
addition to "baked-in" curves like the NIST, Brainpool, and Curve25519
curves? I realize that using arbitrary curves is something that is not
for the faint of heart, but having options is nice.

5. Why are so many key-generating options hidden behind the
"--full-gen-key" flag? The regular "--gen-key" flag makes a 2048-bit
RSA key, which is fine. I understand hiding the ECC options, as
support is not widespread, but why hide "traditional" algorithms like
DSA/ELG?

Cheers!
-Pete

[1] Cipher: AES256, AES192, AES, 3DES
     Digest: SHA256, SHA384, SHA512, SHA224, SHA1
     Compression: ZLIB, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify

-- 
Pete Stephenson