5

I've been trying out the new ECC keys that have been added to GnuPG 2.1.

I created a primary key, then added an ed25519 signing subkey. So I know get this:

➜  ~  gpg2 -K
/Users/jonny/.gnupg/pubring.kbx
-------------------------------
sec   brainpoolP384r1/0x4E8DDC0EDE5D23A6 2015-01-09 [expires: 2016-01-09]
     Key fingerprint = EB55 21A4 5B8D 7310 53A6  E5DE 4E8D DC0E DE5D 23A6
uid                 [ultimate] Jonny Barnes <jonny@jonnybarnes.uk>
ssb   brainpoolP384r1/0xAE4F07A02E2C8780 2015-01-09 brainpoolP384r1 [expires: 2016-01-09]
ssb   ed25519/0xCDE84418F36C7F7B 2015-01-09 ed25519 [expires: 2016-01-09]

Then I ran gpg2 --send-keys 0x4E8DDC0EDE5D23A6, but this is what I see when looking for my key on the keyserver:

pub   384E/DE5D23A6 2015-01-09            
 Fingerprint=EB55 21A4 5B8D 7310 53A6  E5DE 4E8D DC0E DE5D 23A6 

uid Jonny Barnes <jonny@jonnybarnes.uk>
sig  sig3  DE5D23A6 2015-01-09 __________ 2016-01-09 [selfsig]

sub   384e/2E2C8780 2015-01-09            
sig sbind  DE5D23A6 2015-01-09 __________ 2016-01-09 []

It only shows one subkey? Where's my second signing subkey?

3

The normal pool.sks-keyservers.net contains a bunch of SKS software versions, requiring at least 1.1.2. SKS only fully supports ECC keys since the most current version 1.1.5, so some servers are not able to work with your keys, and they will omit what they don't understand, thus throw away some packets of your key.

Use subset.pool.sks-keyservers.net instead, which is limited to servers running the 1.1.5 release, and thus fully ECC compliant.

Update based on the mailing list reply: ed25519 OpenPGP keys have only been standardized after release of SKS version 1.1.5. As of January 2015, only prerelease-versions of the SKS key server will print the key without missing packets (with newer versions supporting it by defualt), but will already be fully retrieved by appending &clean=off to the URL with servers running version 1.1.5.

  • My gpg.conf contains the line keyserver subset.pool.sks-keyservers.net, I then re-ran gpg2 --end-keys <key-id>, but this search still doesn't show my ed25519 subkey: subset.pool.sks-keyservers.net:11371/pks/… – Jonny Barnes Jan 10 '15 at 14:16
  • And its defintely been uploaded to an SKS server running 1.1.5: subset.pool.sks-keyservers.net:11371/pks/… – Jonny Barnes Jan 10 '15 at 14:17
  • It might be that the server you uploaded to, and the one you used to look up are different ones, and only synchronize with some older versions in-between. Waiting for some time might resolve the issue. You could try to select a specific 1.1.5 key server, send to him and verify a correct upload. If this also fails, you'd probably be better of on the SKS dev mailing list and report the problem. – Jens Erat Jan 10 '15 at 14:27
  • With a little digging around with gpg2 --list-packets if I manually export my public key, it has the ed25519 subkey, the public key that is residing on the keyservers definitely doesn't. I've even gone to pgpkeys.eu which is running 1.1.5, and pasted in my ASCII public key into their web form. As you said, it must be throwing away the packets it can't understand – Jonny Barnes Jan 10 '15 at 14:59
  • I'd ask for help on the SKS devel list: <lists.nongnu.org/mailman/listinfo/sks-devel>, possibly directly adding the exported public key as attachment. – Jens Erat Jan 10 '15 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.