Crypto

GPG public key signing post-party automation with KMail

This past Ubucon's key signing party was my first key signing party. One thing I noticed--signing keys after a key signing party is a boring repetitive task. Summarized from the Ubuntu wiki entry on typical key signing post-party protocol:

  1. Retrieve all public keys of key signing party participants, using gpg –-recv-key
  2. Compare the hardcopy fingerprint from the keysigning party to the fingerprint of the retrieved public keys, using gpg –-fingerprint
  3. Sign the key, using gpg –-sign Send the signed key back, either by
    • E-mail: export the key, then e-mail it to the key owner, using gpg –-export -a | mail -s “Your signed key” user@example.com
    • Key server: send the key to a public keyserver, using gpg –send-keys

This is incredibly monotonous—and people have to wonder why Web of Trust-based encryption is not more popular?

The Debian signing-party package provides the utility caff to automate some of this. It's not very friendly to “desktop” users, however:

  • it's a CLI application
  • it requires a local MTA (/usr/sbin/sendmail in particular), or an “open” SMTP server, with no support for authenticated SMTP or SMTP/SSL
  • the configuration file syntax is Perl and confusing; there are also few examples on the Internet

You could add authenticated SMTP or SMTP/SSL support to the script, but having to know how to hack Perl definitely disqualifies caffe from being a desktop-friendly application.

So, I hacked together my own key signing party script in Python that would send signed keys back to people via KMail. To use it, create a text file listing all key IDs you wish to sign, one per line. Pipe the contents of this list into the script:

cat list-of-ids.txt | key-signing-party-batch-process-via-kmail.py

The script will download each key, ask you to verify the fingerprint, and then sign it. It then will open a KMail composer window, pre-filled with the key owner's e-mail address, a friendly template message (customizable in the script), and attached key. Review each e-mail to make sure it is kosher, and click send. Other than continuing to be a CLI program, I think this is much friendlier--the only manual work done is the creation of list of keys to sign, comparing fingerprints (this could be automated, but it seems in the spirit of the Web of Trust-based systems not to), and clicking send in a familiar desktop e-mail client.

Now for some notes...

It uses the DCOP automation features of KDE's Kmail to send messages. You could similarly use Evolution and D-Bus, but I don't use Evolution so I can't contribute that bit of functionality. Mozilla's Thunderbird unfortunately does not yet support any kind of automation features (as far as I know, anyway), so you're completely out of luck if you use it.

DCOP with Python is a complete, utter, pain. The easy way to drag-and-drop boiler-plate code with kdcop did not work, as it appears the APIs have changed. A problem with KDE/Python dcopext's module and multiple identically-named-functions sealed the deal for me and I gave up trying to use DCOP with Python, and instead settled for a hack of using the shell instead. I'm looking forward the one Linux desktop IPC protocol to rule them all, D-Bus, to debut in KDE4.

My script does not provide all the functionality of caffe. It, for example, does not encrypt the messages and their keys back to their owners. There doesn't appear to be an easy way to do this with KMail and DCOP, so it's a feature that will have to wait.

Cryptographic keys

GnuPG

You can get my GPG public key by looking for key ID 1A1993D3 on public keyservers, such as MIT's PGP keyserver. My key's fingerprint is:

F12C A688 3EFD A07C 84F3 5E4F 9ECE 0D53 1A19 93D3

The ASCII-armored public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.3 (GNU/Linux)

mQGiBEVvyIsRBACIksDwU7rgBNE7FhGO6MNYHWwOUJiGAdB65de1YpFqnXa5Ovnq
BklYWSqzWulu63U8ydu6lA7gG1BI5oB/oAT0TJ3RJfVFJ3sjGrFBF5C0rIwipD8f
4WM+c4jvF7osBWlygh+WonBA9p+2nTy5JbGrEunguborbMDkll5CghwZIwCgr0hD
UcjTksLNXL3r/XV/9c/YIFUD/3QZ7+AW2dACQYAB0FXloxCBqQ2ybmr2ZnDGCcvO
UNFNUehpem6g3BrWYGigGx19ZQniElerV6De1br2dRMbu0la9rTIoljV/Boq1kRK
JfazubEYOUb6pCEbNSgWA+aMKforL6V2IJZK4OhWXs+6on33QOaO4n5NMRBrFHeX
zOzAA/9JQig1jWf7Ypw27ShDmD1g5H/5DO3bk5vOSepM4hBcCvAkDkIU4cRO6QTC
HksfZiSQ4Iuo6onK1ejXndQZ/K3yRw4vgf3MwI19fLbrf3PoSoYjugh8RT5KIaKL
x1399qH7STuSHUu1enI9bMGcBAvx4UwRemLjeA5Bn5tSJ8inr7QeU2FtYXQgSmFp
biA8c2FtYXRAcmhvbWJpYy5uZXQ+iGYEExECACYFAkVvzIUCGwMFCQlmAYAGCwkI
BwMCBBUCCAMEFgIDAQIeAQIXgAAKCRCezg1TGhmT07OxAKCsegf9NIZU9OmzItxf
aVRXJ7cKjwCfVYCSW4tQohVfeTe+toa24nuGAji0HFNhbWF0IEphaW4gPHNhbWF0
QHNhbWF0Lm9yZz6IaQQTEQIAKQIbAwUJCWYBgAYLCQgHAwIEFQIIAwQWAgMBAh4B
AheABQJFb8zpAhkBAAoJEJ7ODVMaGZPT7QIAn1jQ7RLbBQ/ND9Y1MTihdrmTAp8C
AJ9LeCaUttbLvvE/mnWtyxZCRni0cbQpU2FtYXQgSmFpbiA8c2FtYXQuamFpbkBk
Ym1pLmNvbHVtYmlhLmVkdT6IZgQTEQIAJgUCRW/MaAIbAwUJCWYBgAYLCQgHAwIE
FQIIAwQWAgMBAh4BAheAAAoJEJ7ODVMaGZPTFLwAnjJ0PPqsN3YeaX7ul+kl+rhx
2p1qAJ9ieqzOQaJZgDyYjSVBx/Pai2F8ZLkCDQRFb8ioEAgA6LNORiX5Q57axZmv
+QeMHsQe9hRUZzUZk2pULiLu1CzBwyN5fu4fYo8ZJ1RWDzrda4Re6KYeWjvu04u5
Eka/U3pH4bGGHFpuZdw29ayFJALRsBOMmQL1oag5kPuoaK7ZycfJ6l9yE50OnpvD
sH+QX3S70nwMLNDsHecEm6fYsCWmdXTTNjcc1XQ9vqAV6DpiA7JK4s75qa3qbxKT
w8rXdStsm12XJlCcP/UHVUmB79CzEaF+IhzCd7dCqrOXLhxo3Xi9qL5SZNF9irxI
ZTj1RX5qDHhnTSW8QzpgdATA584SrUln9h0lb4NW8IFD2YDT+XBvjRKaAgrrsHdX
bvM3iwADBQgA2tMvTmBStZ5xf+4eB3MgCO7u/osWaUB3MV2qtv2Yme5j3QE4sFF2
0+IPma9snatDXJuc9AhUIl/S2hzBM5Qc5zdl7xVULBtVDhCNTV4RHn3YfcPQGxiU
OfcbDSqz9MPdFy/paNN++elP4QZS7Ykihe5c0SDp77p5Kor3dxMX+AVIr6ddQciD
pdONshDEOAypU0D50ccEv0qoUNm2ssKf0hyFWws4W/OqO5rhZJTTWgoxxk9dirAx
mdgctFSa7BnUn+ptabuhx88Vca92UxEZVt46zvkoZirYJKFHeHl2F2ro2ApFtcFk
ArEkCfRcbH4ZkAS/EtPNvR80lrPdEnPYcohPBBgRAgAPBQJFb8ioAhsMBQkJZgGA
AAoJEJ7ODVMaGZPTBaYAoKrjmKzhfcrnoocclTd84FRx9wXVAJoDWowiw1bajajF
KklHhsD7OPf8UQ==
=j+RM
-----END PGP PUBLIC KEY BLOCK-----
Syndicate content