warning: Creating default object from empty value in /home/gwolf/drupal6/modules/taxonomy/ on line 33.

Key migration: rsa4096/0x673A03E4C1DB921F → ed25519/0x2404C9546E145360

Submitted by gwolf on Fri, 11/22/2019 - 20:08

Oh, the joys of life... I see myself forced to do a key migration.

No, no — Don't worry! My key didn't land in any hostile party's hands. And I still kinda-sorta-have access to it.

Let me explain. I was quite a happy user of a Yubikey, kindly given to me in mid-2018. As the recommendation goes, I backed up my master key's secret material to an offline media, and kept the relevant subkeys in the Yubikey; I love knowing my computer does not have access to the private keys although it can use them — The Yubikey provides just the needed interfaces for them. And here they are:

$ gpg --list-secret-keys 
sec#  rsa4096/0x673A03E4C1DB921F 2009-07-09 [SC] [expires: 2020-12-19]
      Key fingerprint = AB41 C1C6 8AFD 668C A045  EBF8 673A 03E4 C1DB 921F
uid                   [ultimate] Gunnar Eyal Wolf Iszaevich 
uid                   [ultimate] Gunnar Eyal Wolf Iszaevich 
uid                   [ultimate] Gunnar Eyal Wolf Iszaevich (Instituto de Investigaciones Económicas UNAM) 
ssb>  rsa4096/0x92853D8CF7F6543F 2009-07-09 [E] [expires: 2020-12-19]
ssb>  rsa4096/0x80382A731F474556 2018-07-31 [E] [expires: 2020-12-19]
ssb>  rsa4096/0xA5F64FDEB981CD8C 2018-07-31 [S] [expires: 2020-12-19]
ssb>  rsa4096/0x49DD2A4E4979619C 2018-07-31 [S] [expires: 2020-12-19]
$ gpg --card-status 
Signature key ....: FA42 3AA0 6D8F E9ED 5D6C  5E42 A5F6 4FDE B981 CD8C
      created ....: 2018-07-31 03:29:09
Encryption key....: 0DE6 49DF 2778 E904 94B6  7952 9285 3D8C F7F6 543F
      created ....: 2009-07-09 23:20:40
Authentication key: 7C79 5E53 9968 8DDF 66F7  D620 49DD 2A4E 4979 619C
      created ....: 2018-07-31 03:31:16
General key info..: sub  rsa4096/0xA5F64FDEB981CD8C 2018-07-31 Gunnar Eyal Wolf Iszaevich 
sec#  rsa4096/0x673A03E4C1DB921F  created: 2009-07-09  expires: 2020-12-19
ssb>  rsa4096/0x92853D8CF7F6543F  created: 2009-07-09  expires: 2020-12-19
                                  card-no: 0006 05009847
ssb>  rsa4096/0x80382A731F474556  created: 2018-07-31  expires: 2020-12-19
                                  card-no: 0006 05009847
ssb>  rsa4096/0xA5F64FDEB981CD8C  created: 2018-07-31  expires: 2020-12-19
                                  card-no: 0006 05009847
ssb>  rsa4096/0x49DD2A4E4979619C  created: 2018-07-31  expires: 2020-12-19
                                  card-no: 0006 05009847

Until... One sad day, I discovered I could not decrypt documents sent to me anymore. While signing and encrypting do work:

$ date | gpg --encrypt --recipient 0x673A03E4C1DB921F --armor

$ date | gpg --clearsign 
gpg: using "C1DB921F" as default secret key for signing
Hash: SHA256

Fri 22 Nov 2019 06:31:42 PM CST


trying to decrypt the message does not get me very far:

$ date | gpg --encrypt --recipient 0x673A03E4C1DB921F --armor | gpg --decrypt
gpg: encrypted with 4096-bit RSA key, ID 0x80382A731F474556, created 2018-07-31
      "Gunnar Eyal Wolf Iszaevich "
gpg: public key decryption failed: Hardware problem
gpg: decryption failed: No secret key

And although the message is quite clear (public key decryption failed: Hardware problem), I spent far too many attempts at putting things upside down, trying and trying and trying to fix the issue. But no: Hardware problem means hardware problem. My Yubikey is somehow dead.

But it seems that... Even if I was able to bring it back from the dead, I would be doomed anyway: The USB key where I kept the backup for the master key material refuses to be read. Of course, I also gave it several attempts... All failed ☹ And, of course, I had it on just a single media ☹ So even getting the Yubikey decryption back to life would only allow me to use my key until 2020-12-19.

So... What's left for me to do? I just generated a shiny new elliptic-curve key, and will as soon as possible migrate my Debian credentials to use it. Please note, I am not able to sign my new key with the old one, as only the master key has Certification ability. So, the next best thing is a migration statement. I am inlining it here for convenience; if you want to check it, you can either:

$ wget -O - | gpg --verify

Or just run gpg --verify and paste as its input the following text:

Hash: SHA256

I am Gunnar Wolf, and I am transitioning away from my
rsa4096/0x673A03E4C1DB921F key, to ed25519/0x2404C9546E145360. The
reason for this transition is two simultaneous cases(!) of broken

My old key is still usable until its expiry date, but I am unable to
use it for decryption; please use only my new key.

If you have signed my old key, please consider signing the new one;
this file is signed with both keys as a proof I do have control over
them. Please note my old key is unable to certify the new one, so it
is not yet signed.

 -={ Old key, which I am transitioning _away_ from }=-

pub   rsa4096/0x673A03E4C1DB921F 2009-07-09 [SC] [expires: 2020-12-19]
      Key fingerprint = AB41 C1C6 8AFD 668C A045  EBF8 673A 03E4 C1DB 921F
uid                   [ultimate] Gunnar Eyal Wolf Iszaevich 
uid                   [ultimate] Gunnar Eyal Wolf Iszaevich 
uid                   [ultimate] Gunnar Eyal Wolf Iszaevich (Instituto de Investigaciones Económicas UNAM) 

 -={ New key, which I am transitioning to }=-

pub   ed25519/0x2404C9546E145360 2019-11-22 [SC] [expires: 2022-11-21]
      Key fingerprint = 4D14 0506 53A4 02D7 3687  049D 2404 C954 6E14 5360
uid                   [ unknown] Gunnar Wolf 
uid                   [ unknown] Gunnar Eyal Wolf Iszaevich 
uid                   [ unknown] Gunnar Wolf 

The new key has been uploaded to If you
decide to sign my new key, I'd prefer if you mail it to me via
(i.e. using caff).

Thank you very much,

      - Gunnar


I will be soon meeting with two DDs, so in any case, this key will be in shape to enter our keyring. Thank you very much for following so far!

(...And yes — This time I made two separate offline media backups for my master key material :-Þ)


Submitted by gwolf on Thu, 08/01/2019 - 10:25

I started running an SKS keyserver a couple of years ago (don't really remember, but I think it was around 2014). I am, as you probably expect me to be given my lines of work, a believer of the Web-of-Trust model upon which the PGP network is built. I have published a couple of academic papers (Strengthening a Curated Web of Trust in a Geographically Distributed Project, with Gina Gallegos, Cryptologia 2016, and Insights on the large-scale deployment of a curated Web-of-Trust: the Debian project’s cryptographic keyring, with Victor González Quiroga, Journal of Internet Services and Applications, 2018) and presented several conferences regarding some aspects of it, mainly in relation to the Debian project.

Even in light of the recent flooding attacks (more info by dkg, Daniel Lange, Michael Altfield, others available; GnuPG task tracker). I still believe in the model. But I have had enough of the implementation's brittleness. I don't know how much to blame SKS and how much to blame myself, but I cannot devote more time to fiddling around to try to get it to work as it should — I was providing an unstable service. Besides, this year I had to rebuild the database three times already due to it getting corrupted... And yesterday I just could not get past of segfaults when importing.

So, I have taken the unhappy decision to shut down my service. I have contacted both the SKS mailing list and the servers I was peering with. Due to the narrow scope of a single SKS server, possibly this post is not needed... But it won't hurt, so here it goes.

( categories: )

DebConf17 Key Signing Party: You are here↓

Submitted by gwolf on Fri, 08/04/2017 - 19:23

I ran my little analysis program written last year to provide a nice map on the DebConf17 key signing party, based on the . What will you find if you go there?

  • A list of all the people that will take part of the KSP
  • Your key's situation relative to the KSP keyring

As an example, here is my location on the map (click on the graph to enlarge):

Its main use? It will help you find what clusters are you better linked with - And who you have not cross-signed with. Some people have signed you but you didn't sign them? Or the other way around? Whom should you approach to make the keyring better connected? Can you spot some attendees who are islands and can get some help getting better connected to our keyring? Please go ahead and do it!

PS— There are four keys that are mentioned in the DebConf17 Keysigning Party Names file I used to build this from: 0xE8446B4AC8C77261, 0x485E1BD3AE76CB72, 0x4618E4C700000173, E267B052364F028D. The public keyserver network does not know about them. If you control one of those keys and you want me to run my script again to include it, please send it to the keyservers and mail me. If your key is not in the keyservers, nobody will be able to sign it!

( categories: )

Status of the OpenPGP keyring: 1024D is a thing of the past!

Submitted by gwolf on Fri, 01/02/2015 - 12:25

Having seen the end of December and the beginning of January, this is the time of year where we say "Happy new year!"

But this is a very interesting new year: We have also went past our much announced deadline for the <2048 bit keys to be removed from the Debian keyrings. And yes, our highly efficient keyring-maint team managed to deliver on the promised time — And, I'd say, with much success. Lets see the numbers — Only before that, refer to Jonathan's mail to debian-devel-announce for further, fuller information.

So, first of all, how do overall numbers look? Just remember, the following are not the number of DDs, just the number of active keys. That is, the holders to the 252 DD and 35 DM keys we removed are still valid Debian Developers/Maintainers, but have to get a new key accepted to perform many of their tasks in the project.

The graph above shows the sharp change between tags 2014.12.31 and 2015.01.01. But my definition of success is that we managed to get the number down to just 252+35=287 from what we had back in August, when we did our DebConf presentation and started the aggressive push: 490 DD keys and 49 DM keys. Since then, 34 DDs requested their retirement, becoming emeritus, and practically all of the rest managed to get their key transition done!

So, lets go again easiest-to-hardest. First, the Non-uploading Debian Developers keyring:

As this is the newest keyring in existence, and is also the smallest one, we were already without <2048 keys since 2011. Nothing to see, move along.

Then, as for the Debian Maintainers:

We did have a sensible migration from weaker to stronger keys, but it was not as sharp as I'd have liked. That makes sense, after all, since DMs have less involvement and compromise in the project in regard to DDs. So, we only processed 15 DM keys since August, which is almost a third of the keys we needed to process to reach the ideal 100% migration.

Now, as for our biggest and oldest keyring, and the one that denotes more project involvement, here is the graph for the uploading Debian Developers:

And yes, here you can see the sharp turn we saw in the second half of this year: By DebConf time, we were happy because the red and yellow lines had just crossed. But we were still sitting at 490 DD keys needing to be migrated. Half of the DD keys (compared to almost a fourth for the DM keys).

I'm almost sure we anticipated in our presentation (I know, I should check the video) that, by January 1st, we would have to retire around 300 keys. And I'm very, very happy and proud that we managed to get the number down to 252.

And, yes, people leave things to the end: We already have some more pending requests in the Request Tracker to introduce new keys for our fellow friends who were disabled. We will be working to make keyring pushes more frequent than our usual monthly uploads until requests go back to a sane level.

So, if everything runs smoothly, this will probably be the last of my posts in this regard. This has been quite an interesting (and exhausting!) experience!

( categories: )

Status of the Debian OpenPGP keyring — November update

Submitted by gwolf on Fri, 11/21/2014 - 13:29

Almost two months ago I posted our keyring status graphs, showing the progress of the transition to >=2048-bit keys for the different active Debian keyrings. So, here are the new figures.

First, the Non-uploading keyring: We were already 100% transitioned. You will only notice a numerical increase: That little bump at the right is our dear friend Tássia finally joining as a Debian Developer. Welcome! \o/

As for the Maintainers keyring: We can see a sharp increase in 4096-bit keys. Four 1024-bit DM keys were migrated to 4096R, but we did have eight new DMs coming in To them, also, welcome \o/.

Sadly, we had to remove a 1024-bit key, as Peter Miller sadly passed away. So, in a 234-key universe, 12 new 4096R keys is a large bump!

Finally, our current-greatest worry — If for nothing else, for the size of the beast: The active Debian Developers keyring. We currently have 983 keys in this keyring, so it takes considerably more effort to change it.

But we have managed to push it noticeably.

This last upload saw a great deal of movement. We received only one new DD (but hey — welcome nonetheless! \o/ ). 13 DD keys were retired; as one of the maintainers of the keyring, of course this makes me sad — but then again, in most cases it's rather an acknowledgement of fact: Those keys' holders often state they had long not been really involved in the project, and the decision to retire was in fact timely. But the greatest bulk of movement was the key replacements: A massive 62 1024D keys were replaced with stronger ones. And, yes, the graph changed quite abruptly:

We still have a bit over one month to go for our cutoff line, where we will retire all 1024D keys. It is important to say we will not retire the affected accounts, mark them as MIA, nor anything like that. If you are a DD and only have a 1024D key, you will still be a DD, but you will be technically unable to do work directly. You can still upload your packages or send announcements to regulated mailing lists via sponsor requests (although you will be unable to vote).

Speaking of votes: We have often said that we believe the bulk of the short keys belong to people not really active in the project anymore. Not all of them, sure, but a big proportion. We just had a big, controversial GR vote with one of the highest voter turnouts in Debian's history. I checked the GR's tally sheet, and the results are interesting: Please excuse my ugly bash, but I'm posting this so you can play with similar runs on different votes and points in time using the public keyring Git repository:

  1. $ git checkout 2014.10.10
  2. $ for KEY in $( for i in $( grep '^V:' tally.txt |
  3. awk '{print "<" $3 ">"}' )
  4. do
  5. grep $i keyids|cut -f 1 -d ' '
  6. done )
  7. do
  8. if [ -f debian-keyring-gpg/$KEY -o -f debian-nonupload-gpg/$KEY ]
  9. then
  10. gpg --keyring /dev/null --keyring debian-keyring-gpg/$KEY \
  11. --keyring debian-nonupload-gpg/$KEY --with-colons \
  12. --list-key $KEY 2>/dev/null \
  13. | head -2 |tail -1 | cut -f 3 -d :
  14. fi
  15. done | sort | uniq -c
  16. 95 1024
  17. 13 2048
  18. 1 3072
  19. 371 4096
  20. 2 8192

So, as of mid-October: 387 out of the 482 votes (80.3%) were cast by developers with >=2048-bit keys, and 95 (19.7%) were cast by short keys.

If we were to run the same vote with the new active keyring, 417 votes would have been cast with >=2048-bit keys (87.2%), and 61 with short keys (12.8%). We would have four less votes, as they retired:

  1. 61 1024
  2. 14 2048
  3. 2 3072
  4. 399 4096
  5. 2 8192

So, lets hear it for November/December. How much can we push down that pesky yellow line?

Disclaimer: Any inaccuracy due to bugs in my code is completely my fault!

( categories: )

One month later: How is the set of Debian keyrings faring?

Submitted by gwolf on Mon, 09/22/2014 - 13:13

OK, it's almost one month since we (the keyring-maintainers) gave our talk at DebConf14; how are we faring regarding key transitions since then? You can compare the numbers (the graphs, really) to those in our DC14 presentation.

Since the presentation, we have had two keyring pushes:

First of all, the Non-uploading keyring is all fine: As it was quite recently created, and as it is much smaller than our other keyrings, it has no weak (1024 bit) keys. It briefly had one in 2010-2011, but it's long been replaced.

Second, the Maintainers keyring: In late July we had 222 maintainers (170 with >=2048 bit keys, 52 with weak keys). By the end of August we had 221: 172 and 49 respectively, and by September 18 we had 221: 175 and 46.

As for the Uploading developers, in late July we had 1002 uploading developers (481 with >=2048 bit keys, 521 with weak keys). By the end of August we had 1002: 512 and 490 respectively, and by September 18 we had 999: 531 and 468.

Please note that these numbers do not say directly that six DMs or that 50 uploading DDs moved to stronger keys, as you'd have to factor in new people being added, keys migrating between different keyrings (mostly DM⇒DD), and people retiring from the project; you can get the detailed information looking at the public copy of our Git repository, particularly of its changelog.

And where does that put us?

Of course, I'm very happy to see that the lines in our largest keyring have already crossed. We now have more people with >=2048 bit keys. And there was a lot of work to do this processing done! But that still means... That in order not to lock a large proportion of Debian Developers and Maintainers out of the project, we have a real lot of work to do. We would like to keep the replacement slope high (because, remember, in January 1st we will remove all small keys from the keyring).

And yes, we are willing to do the work. But we need you to push us for it: We need you to get a new key created, to gather enough (two!) DD signatures in it, and to request a key replacement via RT.

So, by all means: Do keep us busy!

( categories: )
Syndicate content