Talking at PETCon2018 in Hamburg, Germany and OpenPGP Email Summit in Brussels, Belgium

Just like last year, I managed to be invited to the Privacy Enhancing Technologies Conference to talk about GNOME. First, Simone Fischer-Huebner from Karlstadt University talked about her projects which are on the edge of security, cryptography, and usability, which I find a fascinating area to be in. She presented outcomes of her Prismacloud project which also involves fancy youtube videos…

I got to talk about how I believe GNOME is in a good position make a safe and secure operating system. I presented some case studies and reported on the challenges that I see. For example, Simone mentioned in her talk that certain users don’t trust a software if it is too simple. Security stuff must be hard, right?! So how do measure the success of your security solution? Obviously you can test with users, but certain things are just very hard to get users for. For example, testing GNOME Keysign requires a user not only with a set up MUA but also with a configured GnuPG. This is not easy to come by. The discussions were fruitful and I got sent a few references that might be useful in determining a way forward.

OpenPGP Email Summit

I also attended the OpenPGP Email Summit in Brussels a few weeks ago. It’s been a tiny event graciously hosted by a local company. Others have written reports, too, which are highly interesting to read.

It’s been an intense weekend with lots of chatting, thinking, and discussing. The sessions were organised in a bar-camp style manner. That is, someone proposed what to discuss about and the interested parties then came together. My interest was in visual security indication, as triggered by this story. Unfortunately, I was lured away by another interesting session about keyserver and GDPR compliance which ran in parallel.

For the plenary session, Holger Krekel reported on the current state of Delta.Chat. If you haven’t tried it yet, give it a go. It’s trying to provide an instant messaging interface with an email transport. I’ve used this for a while now and my experience is mixed. I still get to occasional email I cannot decrypt and interop with my other MUA listening on the very same mailbox is hit and miss. Sometimes, the other MUA snatches the email before Delta.chat sees it, I think. Otherwise, I like the idea very much. Oh, and of course, it implements Autocrypt, so your clients automatically encrypt the messages.

Continuing the previous talk, Azul went on to talk about countermitm, an attempt to overcome Autocrypt 1.0‘s weaknesses. This is important work. Because without the vision of how to go from Autocrypt Level 1 to Level 2, you may very well question to usefulness. As of now, Emails are encrypted along their way (well. Assuming MTA-STS) and if you care about not storing plain text messages in your mailbox, you could encrypt them already now. Defending against active attackers is hard so having sort of a plan is great. Anyway, countermitm defines “verified groups” which involves a protocol to be run via Email. I think I’ve mentioned earlier that I still think that it’s a bit a sad that we don’t have the necessary interfaces to run protocols over Email. Outlook, I think, can do simple stuff like voting for of many options or retracting an email. I would want my key exchange to be automated further, i.e. when GNOME Keysign sends the encrypted signature, I would want the recipient to decrypt it and send it back.

Phil Zimmermann, the father of PGP, mentioned a few issues he sees with the spec, although he also said that it’s been a while that he was deeply into this matter. He wanted the spec to be more modern and more aggressively pushing for today’s cryptography rather than for the crypto of the past. And in fact, he wants the crypto of tomorrow. Now. He said that we know that big agencies are storing message today for later analyses. And we currently have no good way of having what people call “perfect forward secrecy” so a future key compromise makes the messages of today readable. He wants post quantum crypto to defeat the prying eyes. I wonder whether anybody has implemented pq-schemes for GnuPG, or any other OpenPGP implementation, yet.

My takeaways are: The keyserver network needs a replacement. Currently, it is used for initial key discovery, key updates, and revocations. I think we can solve some of these problems better if we separate them. For example, revocations are pretty much a fire and forget thing whereas other key updates are not necessarily interesting in twenty years from now. Many approaches for making initial key discovery work have been proposed. WKD, Autocrypt, DANE, Keybase, etc. Eventually one of these approaches wins the race. If not, we can still resort back to a (plain) list of Email addresses and their key ids. That’s as good or bad as the current situation. For updates, the situation is maybe not as bad. But we might still want to investigate how to prevent equivocation.

Another big thing was deprecating cruft in the spec to move a bit faster in terms of cryptography and to allow implementers to get a compliant program running (more) quickly. Smaller topics were the use of PQ safe algorithm and exploitation of backwards incompatible changes to the spec, i.e. v5 keys with full fingerprints. Interestingly enough, a trimmed down spec had already been developed here.

New OpenPGP key

PSA: I’ve rolled over my OpenPGP Key.

The old key F289F7BA977DF4143AE9FDFBF70A02906C301813 is considered to be too short by some and it’s sufficiently old to retire it.

My new key is F98D03D7DC630399AAA6F43826B3F39189C397F6.

It’s been a while since I did that last. And GnuPG still makes it hard to use an expired key, I cannot sign this transition statement with both keys as suggested by this document. Also, I might consider using a service such as https://www.expirybot.com/ for telling me when it’s time to think of a strategy for the next roll-over. It’s a shame we don’t have such tooling in place for the desktop.

Anyway, feel free to grab the new from the WebPKI protected resource here.

sec   dsa1024 2008-12-03 [SC] [expired: 2018-02-28]
      F289F7BA977DF4143AE9FDFBF70A02906C301813
uid           [ expired] Tobias Mueller 

sec   dsa3072 2018-03-17 [SC] [expires: 2023-03-16]
      F98D03D7DC630399AAA6F43826B3F39189C397F6
uid           [ultimate] Tobias Mueller 
ssb   elg3072 2018-03-17 [E] [expires: 2023-03-16]

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGiBEk21OkRBAC5XDJFPbA2WhhvbKdu51ZOL3iPwMPSp8k1U5qEY0uChuI5eekL
VUHhsQJP+mNSwPMKJuyAZgMtdeG+YHEo06Rh9beOxCRtR1Y4Jzl1iP2jslHUu/r9
O0DLXUOdbsi0oSfNGJt4nxdZheIr/eH18w8Sp/P1l3YooRcyC3wa/lwR2wCgps+U
nBLN5JbQaz4NeoDXROhwDNkD/0mPTNX7WyPWJoEpFwSSKD1ZPaF46fFDhlK6pdyv
120TYoRAtQBYew3XkiW+ZoW4OZiqVJLTqqI8bADSeZ4AaJEgRyKb99tRrpyWFhpk
vMoxtfw2qXDGidcsaeJfqzSw3+qjfjQJMGEkADW5+7d8URTU2I4GURoUUNVYRr+O
lVdUA/4qdHe2E5pkYXlQZAuq8DjUqvqKtay7uCCMFv0NZtXWNn+sPTq108tMfoQ9
QdS74NlbS4Hh/ttMzTZi1z7AEI4Kf74qY77xBjyhPFPSyThxPRH8WjRQLqrZHe0I
G1MtoEFeRfixqCCDtQyTrhQomEgYgSx7phQUTMrCP3wC8uTB6LQkVG9iaWFzIE11
ZWxsZXIgPHRvYmlhc211ZUBnbm9tZS5vcmc+iGYEExECACYCGwMGCwkIBwMCBBUC
CAMEFgIDAQIeAQIXgAUCVtxYfQUJEV+2xwAKCRD3CgKQbDAYE+7uAJ9KEPe5Qqmb
uQBQND8lL89kjBaHZQCeL4lji4/Pxu1wZK+2M1HgXh9dvNK5BA0ESTbU6RAQAK2Q
cpYuL/ieNSzVcXOCLzPMs+jL+nx7GLINoRdTZkK1394bPu4ZUrcUfsfE/Ehm1209
kzD4kXSqbtMCZ0QLo5Ohvzq/TS/d+5kavYiVs0V9UCnjdu0zl/MHjOZ3aghvGKJo
YB+eQNIVoCTLmZIWSE3tHdy+ocoRCPYXLOLZJgewkRmtfOrfg9n+YisLwVryDO4V
kzNZGe+lXf8JKbEXXnL55g+P6gkfDp6IRPm8QetJQ7j6o7xzFGDA+0oJLHc2NgMV
QdZAVZuZwOUJtHkv+HuH88b2mUBAkVLUv1pgyEjEqV45I+OiFdcy9BluzTtXMw00
3oovmmHTLCOars/GGK+tBS6uFMNX59V2lb0QycLwzg6lnedShvl0ivr//khZ2kJ1
avyInTGUdMy5CGM4YB84X8p63EbhrapkM3JmqlZrR71t5GM4nk3IumGCZY1LzO/7
mVbegtYvBc6vcYJqPjwPSLlBdcquQjD49I2UlDI5EfO91rEwkpvVo9RKigKes4yZ
kEP4bzOaXbMrNYuC3ssrbS/zH9w+TPlMSW1w97D2V5mTHsjbaGEgjzPZY3zWklrq
RnHlGEThTsHL0OsdQ0OI7cWUiZn2fMqGSofdeqFAf/o2IAlHGcyAK6MCRNR802dC
8M5XDh1d67QDA2lWL/axMjqgxHKwIR/ufU4EDlTzAAMFEACYnYVIjmfG2eitMowG
21GhIbAyyKjj+xBWeCjB1BVw3ir04fw5I/xaEd5VP3NTY+yv7TZWPdf3myN1SbhT
xeu0YVyzEDs7y2ekpDe6YNiTSRAOoWeb1YObiY6UGTa/vvHtK++Kx+wq7hbdaCaK
AUW2NZ8T9M8p/wX0jxx+CyV/iIfJuhdl9Q08bqRdlnWH+zfHaxq1syUQBMVPVrU/
Gi+IOwo6qcQiW5BI9mZ9WRLQKE5gbvlbzLL49TKcFRq4bCnQXtj6gVCYUIT+wm7I
aNYXl3NcWNWL6GkmuvSxfoF8z/R5Iw+4LUlngSYscXE9c+rFVzp9gfOOqlCbyFRx
1WCHtyLhZfzZub2MmJHQ0+MuYbcP4bG7rGq2QqpYpKYTuqVhhHx8S2EpOOTlx0ys
vLbbGoRdF29i6L4UFl6Tfy1j2S+FSAmug/iv7KbYj4FVeGBh1Rrt+cF//sUXBO6p
OefLSbXRMt7kZNnIyhNfWrM62n03R2nKucTE8oLlFrwZtZ+VTQZicirvwMsC965a
3a3YSX5VD8Ix3/+nYsDeTC8QUTWgK3wmth3gLy1I6ElU5yiSUHMfbFwmI4RFVh5b
fDnoompIAiINvM6KXSxwFfQ1Zwwkxw0iOx7rQ2F/HgTTpXkVA5bISCPChkfIp/WF
S9L5aiwvjo8rXPhb2ChWm1GvpIhPBBgRAgAPAhsMBQJW3FiZBQkRX7bHAAoJEPcK
ApBsMBgTjcIAoJG4JYCcs0RtH8/khWE1nxZzfhgqAJ9DTOJGHUNVqVBg+GtULiuY
wE7HxpkErgRarZOvEQwAnl8+RVZd1Ly24jGPGPW+P57ASaYlwGMj0ifQTvVAfKOE
NCQjcW7njMywLbhFOgDUpR0OfCiK/TJBqLXIa1G2KN2yMQfCCJdrL6bOTT1catMK
vTw9yTjiRnguk6HbM0IuQSbIlTNsLPwUGDQ1NMe3KckcRuLEjdTpubBTRtpYDM50
4Uexua5DS99MTuc+Mgm1S0o9Zft6yu7rpFjf18klqOqqoP+87FM9BQFm1WctLR02
n0e4NY7akryVH7/W0uDJkV4n5Ye7j8F98VAagoxCSrk8lX3AhAaMBzrbFjzstxJw
o8Vlt3ZTC1d7L8wbgFTEZtErmBKruTRV3BqOEhu9aiao2uwPe2Jhb0D5rjuHCvcF
DqmIhODWsfxuoy5uHy0wL4oSjttEfF8x5jtB3DBVrEBN+tReed5asNMfeQAZQqSZ
fIJ9gXbVE6FTJz8MrLHsn0dculG3lQezddYbc0TMPxg4f0v8sj2xk/LV2lXdTV/o
eB4VbRqkwiT+J/+SHE+TAQDcQCw44rbOCuZx8rzyvwD1W+Jw0IUIIvNwnB7y2HBX
uQwAnLbEC6D8dvYXJc1ltV3eBYiCwneO4S/WX4C9Yp1y0kQLILybbRaOyF41L9OE
7xeFnmr9xnNfS7MgKjdVAm6P99xuZic1S6uC7r8oaL3/R69coO/nwOEN5eVMwpwp
x2tt/Nhig2QT8kyjlVIZe7oppDpf/PWk8SxAXZgwWSa23nawMtp4P9L4VaPbwnPw
kT0nY4RI60jAZmG00GC0cYjomPGnfkg1vfJoGnSMghz7f7+syXGOEIE6SZLCKE1m
hssJmh390x6gAPQjKohU62micEm0VVGEax+fUN0jTnCpp8BXYSWbY66FB1dL4Mtl
o+2i1+7O5hJvnylrLCfRheETazlW/xqxS4ZBk2olaC8FZF1Tqo66rBlFDPVOm8de
rlACppC/px+apDDTZju3UaWPhMIPlhP9M3vkgouJgHRhqvAH9ZgwtlFV9v1wvyOn
91cQFC1y0YKkptIn6X2mlgiZIoizq8no5X0Eq+RtffCJlqDsfj9WncKlk4Oh5Bk6
FFfJC/sGlv7BkhORO1kHZZTHD7arCI3vOSJu8b+W9FnbKLho1/So9wnjQoFe6PO/
Q6PbNvNJnTCSwCEvxm1L7XBLIJtO5uOrrKge5BXNT9a/+oUMem702UU9bydcTF2m
Ux4TbLlstnXa4C+9821aZltSb+pnGPkNBGwprpP6cOTx1TIb6rUmpPqKdVDTMpeg
kDVeSDltOJShTstXH1y3h39WwRuH9c/tnW+m7lpyGmz2yVL4itU7qadygO6u06/2
SuLiyg+WSNh/s6LBsS+Qx+6MwXqs69JXcB13/BK5uqP2ub1ilBN/7aqTIMoESK2l
GHO+g8m3q1Cn0JSZ/ohMC8HMqU8NaHcv4jAh5yRds+UQ7YkxuwIpoxNgawNkW2rk
22JKkuCQWAb04Iiq5sBQSijlfkJoPVLiDW4mMhvrUs7ru1bu+mFS5G3vV/xem7xC
dDxLvIYslX8onZsVqxuzHmZLEXFstz/rfVQMH03I6rqt82Ogf9boNGYxvPUi+WqB
EwmdoFe0JFRvYmlhcyBNdWVsbGVyIDx0b2JpYXNtdWVAZ25vbWUub3JnPoh/BBMR
CAAnBQJarZOvAhsDBQkJZgGABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJECaz
85GJw5f2jcoBAIxZr3oM7QObsHgXE3Aawi3oqsC3KYKv+u431WPsmM1UAQCZpc2F
fVHEa+4234cTmCnQbbFrCXxIeB8k2myZ76Hg+rkDDQRarZOvEAwAkwSKzWkK6pYk
sa6LgZdRKjGghFcwCFprptDyAv9iLfs/s+8zfUhHD2stliStDNtuGvhYeN0/o7T/
F6TJ9JZX0QhI/+LqeQTWvRsZ9KoevSpTp0SpNfQa66b+WCfeGIw9BwKnNn+p5SNc
kxjP3DZvyH57CzctoA8yFiAXK0OTijNiBO89llyCLCdmMHR/BANwg/Lv1AWL/M0a
4oibQR6+GR8T+3ydzaZvkxn+hNdTE50YslWFzXXR0brivparCWijUUpnn3Prgaus
wKvOz8QFfe8Qz037ydd8XXd40S3IA4/GYnuVn+opaxGVMsjMNh1yhYp5AiYU1VD4
FTXdKLZRMXtDr+TTB1qSN6KCJ7EQ/O/tWY704ldIE3zLKQV4dYXDhau4jKx1j9yz
xkb4PpJD+b6NBvwNGoTvw4iBsRNXwRho0WMYo304Dh64edBhMC/h3lhj+wCQONR7
yYv0l3hY8pmJXY409uCGwWUoQ9yr+ynk+fM7vNfOeZA6mVoJCuQbAAMFC/98wKAL
VNTDpmsQvZNebGkYUB2QxEeGtcqUaRly/DcKveb3SpJ4CRrxTVBsZQVVeHYbOQPH
5cKOWprV5RUV08urNVxY5Dlu3PCZTMHT2L2otPGiInxk0CRFOWheo5lu7LRdQMSI
i8m+1iP5heQrfTVt+2vS/ogkMtWbjWRaj1gzHQ0wEEtz+bF8t4f6pjQSUKU7R35g
z4GqTbDG+BsW5yD5tMG+2+Ide/c0dl4aGSmBHwJdhL/78Zi//z2VNt1h89rk8zyL
pfZVl6sq78ukqy30or9LWRkDSYrl8WKrLGXWzQgWLgN97Srd7dXRVqRZqVG7/3mG
6PbQzUiYj+pcItJfhGCp8oVwOBpnhNnywxsAGk5f2G4B9XUWv21aE4ZzaQLi0DnA
3+kzTLULI6yd6LfdhjEJaj1TcW8gxWgRGkyU/5mva9pXvYr5yZzNGxXAyLFliuNU
QHfPbuokGlr/ERy9J8CMmT2LYY+eocCeMpN/oyaZX9j2C4pqei41/Ich5M2IZwQY
EQgADwUCWq2TrwIbDAUJCWYBgAAKCRAms/ORicOX9rrnAQDBKBceDhsxXKWZQvuR
Me/juPtunEHhxSiPQa1i61djCgD5ATxw0MjcM/bRHiPFj8JJmvKeRfrZLMZsdNCA
BkK1L5A=
=Aij5
-----END PGP PUBLIC KEY BLOCK-----

First OpenPGP.conf 2016 in Cologne, Germany

Recently, I’ve attended the first ever OpenPGP conference in Cologne, Germany. It’s amazing how 25 years of OpenPGP have passed without any conference for bringing various OpenPGP people together. I attended rather spontaneously, but I’m happy to have gone. It’s been very insightful and I’m really glad to have met many interesting people.

Werner himself opened the conference with his talk on key discovery. He said that the problem of integrating GnuPG in MUAs is solved. I doubt that with a fair bit of confidence. Besides few weird MUAs (mutt, gnus, alot, …) I only know KMail (should maybe also go into the “weird” category 😉 ) which uses GnuPG through gpgme, which is how a MUA really should consume GnuPG functionality. GNOME’s Evolution, while technically correct, supports gnugp, but only badly. It should really be ported to gpgme. Anyway, Werner said that the problem of encryption has been solved, but now you need to obtain the key for the party you want to communicate with. How can you find the key of your target? He said that keyservers cannot map a mail address to a key. It was left a bit unclear what he meant, but he probably referred to the problem of someone uploading a key for your email address without your consent. Later, he mentioned the Web of Trust, which is meant for authenticating the other user’s key. But he disliked the fact that it’s “hard to explain”. He didn’t mention why, though. He did mention that the WoT exposes the global social graph, which is not a desirable feature. He also doubts that the Web of Trust scales, but he left the audience wondering why. To solve the mapping problem, you might imagine keyservers which verify your email address before accepting your key. These, he said, “harm the system”. The problem, he said, is that this system only works with one keyserver which would harm the decentralised nature of the OpenPGP system and bring us back in to the x.500 dark age. While I agree with the conclusion, I don’t fully agree with the premise. I don’t think it’s clear that you cannot operate a verifying server network akin to how it’s currently done. For example, the pool of keyservers could only accept keys which were signed by one of the servers of the pool within the last, say, 6 months. Otherwise, the user has to enrol by following a challenge-response protocol. The devil may be in the details, but I don’t see how it’s strictly impossible.

However, in general, Werner likes the OpenSSH approach better. That is, it opportunistically uses a key and detects when it changes. As with the Web of Trust, the key validation happens on your device, only. Rather than, say, have an external entity selling the trust as with X.509.

Back to the topic. How do you find a key of your partner now? DANE would be an option. It uses DNSSEC which, he said, is impossible to implement a client for. It also needs collaboration of the mail provider. He said that Posteo and mailbox.org have this feature.

Anyway, the user’s mail provider needs to provide the key, he said. Web Key Directory is a new proposal. It uses https for key look-up on a well known name on the domain of the email provider. Think .well-known/openpgp/. It’s not as distributed as DNS but as decentralised as eMail is, he said. It still requires collaboration of the email provider to set the Web service up. The proposal trusts the provider to return genuine keys instead of customised ones. But the system shall only be used for initial key discovery. Later, he mentioned to handle revocation via the protocol™. For some reason, he went on to explain a protocol to submit a key in much more detail rather than expanding on the protocol for the actual key discovery, what happens when the key gets invalid, when it expired, when it gets rolled over, etc.
—-

Next up was Meskio who talked about Key management at LEAP, the LEAP Encryption Access Project. They try to provide a one-stop solution to encrypting all the things™. One of its features is to transparently encrypt emails. To achieve that, it opens a local MTA and an IMAPd to then communicate via a VPN with the provider. It thus builds on the idea of federation the same way current email protocols do, he said. For LEAP to provide the emails, they synchronise the mailbox across devices. Think of a big dropbox share. But encrypted to all devices. They call it soledad which is based on u1db.

They want to protect the user from the provider and the provider from the user. Their focus on ease of use manifests itself in puppet modules that make it easy to deploy the software. The client side is “bitmask“, a desktop application written in Qt which sets everything up. That also includes transparently getting keys of other users. Currently, he said, we don’t have good ways of finding keys. Everything assumes that there is user intervention. They want to change that and build something that encrypts emails even when the user does not do anything. That’s actually quite an adorable goal. Security by default.

Regarding the key validation they intend to do, he mentioned that it’s much like TOFU, but with many many exceptions, because there are many corner cases to handle in that scheme. Keys have different validation levels. The key with the highest validation level is used. When a key roll-over happens, the new key must be signed by the old one and the new key needs to be at least of a validation level as the old one. Several other conditions need to also hold. Quite an interesting approach and I wish that they will get more exposure and users. It’s promising, because they don’t change “too” much. They still do SMTP, IMAP, and OpenPGP. Connecting to those services is different though which may upset people.


More key management was referred on by Comodo’s Phillip Hallam-Baker who went then on to talk about The Mathematical Mesh: Management of Keys. He also doesn’t want to change the user experience except for simplifying everything. Every button to push is one too many, he said. And we must not write instructions. He noted that if every user had a key pair, we wouldn’t need passwords and every communication would be secured end-to-end. That is a strong requirement, of course. He wants to have a single trust model supporting every application, so that the user does not have to configure separate trust configurations for S/MIME, OpenPGP, SSH, etc. That again is a bit of a far fetched dream, I think. Certainly worth working towards it, but I don’t believe to experience such a thing in my lifetime. Except when we think of single closed system, of course. Currently, he said, fingerprints are used in two ways: Either users enter them manually or they compare it to a string given by a secure source.

He presented “The Mesh” which is a virtual store for configuration information. The idea is that you can use the Mesh to provision your devices with the data and keys it needs to make encrypted communication happen. The Mesh is thus a bit of a synchronised storage which keeps encrypted data only. It would have been interesting to see him relate the Mesh to Soledad which was presented earlier. Like Soledad, you need to sign up with a provider and connect your devices to it when using the Mesh. His scheme has a master signature key which only signs a to be created administration key. That in turn signs application- and device keys. Each application can create as many keys as it needs. Each device has three device keys which he did unfortunately not go into detail why these keys are needed. He also has an escrow method for getting the keys back when a disaster happens: The private keys are encrypted, secret shared, and uploaded. Then, you can use two out of three shares to get your key back. I wonder where to upload those shares to though and how to actually find your shares back.

Then he started losing me when he mentioned that OpenPGP keyservers, if designed today, would use a “linked notary log (blockchain)”. He also brought (Proxy-) reencryption into the mix which I didn’t really understand. The purpose itself I think I understand: He wants the mesh to cater for services to re-encrypt to the several keys that all of one entity’s devices have. But I didn’t really understand why it’s related to his Mesh at all. All together, the proposal is a bit opportunistic. But it’s great to have some visions…

Bernhard Reiter talked about getting more OpenPGP users by 2017. Although it was more about whitewashing the money he receives from German administration… He is doing gpg4win, the Windows port of GnuPG. The question is, he said, how to get GnuPG to a large user base and to make them use it. Not surprisingly, he mentioned that we need to improve the user experience. Once he user gets in touch with cryptography and is exposed to making trust decisions, he said, the user is lost. I would argue otherwise, because the people are heavily exposed to cryptography when using whatsapp. Anyway, he then referred to an idea of his: “restricted documents”. He wants to build a military style of access control for documents. You can’t blame him; it’s probably what he makes money off.

He promised to present ideas for Android and the Web. Android applications, he said, run on devices that are ten times smaller and slower compared to “regular” machines. They did actually conduct a study to find this, and other things, out. Among the other things are key insights such as “the Android permission model allows for deploying end to end encryption”. Genius. They also found out that there is an OpenPGP implementation in Bouncy Castle which people use and that it’s possible to wrap libgcrypt for Java. No shit!!1 They have also identified OpenKeychain and K9 mail as applications using OpenPGP. Wow. As for the Web, their study found out that Webmail is a problem, but that an extension to a Web browser could make end to end encryption possible. Unbelievable. I am not necessarily disappointed given that they are a software company and not a research institute. But I’m puzzled in what reality these results are interesting to the audience of OpenPGP.conf. In any case, his company conducted the study as part of the public tender they won and their results may have been biased by his subcontractors who are deeply involved in the respective projects (i.e. Mailvelope, OpenKeychain, …).

As for his idea regarding UX, his main idea is to implement Web Key Directory (see Werner’s opening talk) discovery mechanism. While I think the approach is good, I still don’t think it is sufficient to make 2017 the year of OpenPGP. My concerns revolve about the UX in non straight-forward cases like people revoking their keys. It’s also one thing to have a nice UX and another to actually have users going for it. Totally unrelated but potentially interesting: He said that the German Federal Office for Information Security (“BSI”) uses 500 workstations with GNU/Linux with a Plasma desktop in addition to Windows.

—-

Holger Krekel then went on to refer about automatic end to end encrypted emails. He is working on an EU funded project called NEXTLEAP. He said that email is refusing to die in favour of Facebook and all the other new kids on the block. He stressed that email is the largest open social messaging system and that many others use it as an anchor of identity. However, many people use it for “SPAM and work” only, he said. He identified various usability problems with end to end encrypted email: key distribution, preventing SPAM, managing secrets across devices, and handle device or key loss.

To tackle the key distribution problem, he mentioned CONIKS, Werner’s Webkey, Mailvelope, and DANE as projects to look into. With these, the respective providers add APIs to find public keys for a person. We know about Werner’s Webkey proposal. CONIKS, in short, is a key transparency approach which requires identity providers to publicly testify your key. Mailvelope automatically asks a verifying key server to provide the recipient’s key. DANE uses DNS with DNSSEC to distribute keys.

He proposed to have inline keys. That means to attach keys and cryptographic information to your emails. When you receive such a message, you would parse the details and use them for encryption the next time you create a message. The features of such a scheme, he said, are that it is more private in the sense that there is no public key server which exposes your identity. Also, it’s simpler in the sense that you “only” need to get support from MUAs and you don’t need to care about extra infrastructure. He identified that we need to run a protocol over email if we ever want to support that scheme. I’m curious to see that, because I believe that it’s good if we support protocols via email. Much like Outlook already does with its voting. SPAM prevention would follow naturally, he said. Because the initial message is sent as plain text, you can detect SPAM. Only if you reply, the other party gets your key, he said. I think it should be possible to get a person’s key out of band, but that doesn’t matter much, I guess. Anyway, I couldn’t really follow that SPAM argument, because it seems to imply that we can handle SPAM in the plain text case. But if that was the case, then we wouldn’t have the SPAM problem today. For managing keys, he thinks of sharing your keys via IMAP, like in the whiteout proposal.

—-

Stefan Marsiske then talked about his concerns regarding the future directions of GnuPG. He said he did some teaching regarding crypto and privacy preserving tools and that he couldn’t really recommend GnuPG to anyone, because it could not be used by the people he was teaching. Matt Green and Schneier both said that PGP is not able to secure email or that email is “unsecurable”. This is inline with the list that secushare produced. The saltpack people also list some issues they see with OpenPGP. He basically evaluated gpg against the list of criteria established in the SoK paper on instant messaging which is well worth a read.

Lutz Donnerhacke then gave a brief overview of the history of OpenPGP. He is one of the authors of the initial OpenPGP standard. In 1992, he said, he read about PGP on the UseNet. He then cared about getting PGP 2.6.3(i)n out of the door to support larger keys than 1024 and fix other bugs that annoyed him. Viacrypt then sold PGP4 which was based on PGP2. PGP5 was eventually exported in books and were scanned back in during HIP97 and CCCamp99, he said. Funnily enough, a bug lurked for about five years, he said. Their get_random always returned 1…

Funnily enough he uses a 20 years old V3 key so at least his Key ID is trivially forgeable, but the fingerprint should also be easy to create. He acknowledges it but doesn’t really care. Mainly, because he “is a person from the last century”. I think that this mindset is present in many people’s heads…

The next day Intevation’s Andre Heinecke talked about the “automated use of gpg through gpgme“. GPGME is the abbreviation of “GnuPG made easy” and is meant to be a higher level abstraction for gpg. “gpg is a tool not a library”, he said. For a library you can apply versioning while the tool may change its output liberally, he said. He mentions gpg’s machine interface with --with-colons and that changes to that format will break things. GpgME will abstract that for you and tries to make the tool a library. There is a defined interface and “people should use it”. A selling point is that it works with all gpg versions.

When I played around with gpgme, I found it convoluted and lacking basic operations. I think it’s convoluted because it is highly stateful and you need to be careful with calling (many) functions in the correct order if you don’t want it to complain. It’s lacking, because signing other people’s keys is a weird thing to do and the interface is not designed with that in mind. He also acknowledged that it is a fairly low level API in the sense that every option has to be set distinctly and that editing keys is especially hard. In gpgme, he said, operations are done based on contexts that you have to create. The context can be created for various gpg protocols. Surprisingly, that’s not only OpenPGP, but also CMS, GpgConf, and others.

I don’t think GNOME Software is ported to gpgme. At least Evolution and Seahorse call gpg directly rather than using gpgme. We should change that! Although gpgme is a bit of a weird thing. Normally™ you’d have a library build a tool with it. With gpgme, you have a tool (gpg) and build a library. It feels wrong. I claim that if we had an OpenPGP library that reads and composes packets we would be better off.

Vincent and Dominik came to talk about UX decisions in OpenKeychain, the Android OpenPGP implementation. It does key management, encryption and decryption of files, and other OpenPGP operations such as signing keys. The speakers said that they use bouncy castle for the crypto and OpenPGP serialisation. They are also working on K9 which will support PGP/MIME soon. They have an Open Tech Fund which finances that work. In general, they focused on the UX to make it easy for the consumer. They identified “workflows” users possibly want to carry out with their app. Among them are the discovery and exchange of keys, as well as confirming them (signing). They gave nice looking screenshots of how they think they made the UI better. They probably did, but I found it the foundations a bit lacking. Their design process seems to be a rather ad-hoc affair and they themselves are their primary test subjects. While it’s good work, I don’t think it’s easily applicable to other projects.

An interesting thing happened (again): They deviate from the defaults that GnuPG uses. Unfortunately, the discussions revolving about that fact were not very elaborate. I find it hard to imagine that both tools have, say, different default key lengths. Both tools try to prevent mass surveillance so you would think that they try to use the same defaults to achieve their goal. It would have been interesting to find out what default value serves the desired purpose better.

Next up was Kritian Fiskerstrand who gave an update on the SKS keyserver network. SKS is the software that we trust our public keys with. SKS is written in OCaml, which he likes, but of which he said that people have different opinions on. SKS is single threaded which is s a problem, he said. So you need to have a reverse proxy to handle more than one client.

He was also talking about the Evil32 keys which caused some stir-up recently. In essence, the existing OpenPGP keys were duplicated but with matching short keyids. That means that if you lookup a key by its short key ID, you’re screwed, because you get the wrong key. If you are using the name or email address instead, then you also have a problem. People were upset about getting the wrong key when having asked the keyserver to deliver.

He said that it’s absolutely no problem because users should verify the keys anyway. I can only mildly agree. It’s true that users should do that. But I think we would live in a nicer world where we could still maintain a significantly high security level of such a rigorous verification does not happen. If he really maintains that point of view then I’m wondering why he is allowing keys to be retrieved by name, email address, or anything else than the fingerprint in first place.

—-

Volker Birk from pretty Easy privacy talked about their project which aims at making encrypted email possible for the masses.
they make extensive use of gpgme and GnuNet, he said. Their focus is “privacy by default”. Not security, he said. If security and privacy are contradicting in some cases, they go for privacy instead of security. For example, the Web of Trust is a good idea for security, but not for privacy, because it reveals the social graph. I really like that clear communication and the admission of security and privacy not necessarily going well together. I also think that keyservers should be considered harmful, mainly because they are learning who is attempting to communicate with whom. He said that everything should be decentralised and peer-to-peer. Likewise, a provider should not be responsible for binding an email address to a key. The time was limited, unfortunately, so the actual details of how it’s supposed to be working were not discussed. They wouldn’t be the first ones to attempt a secure or rather privacy preserving solution. In the limited time, however, he showed how to use their Python adapter to have it automatically locate a public key of a recipient and encrypt to it. They have bindings for various other languages, too.

Interestingly, a keysigning “party” was scheduled on the first evening but that didn’t take place. You would expect that if anybody cared about that it is the OpenPGP hardcore hackers, all of which were present. But not a single person (as in nobody, zero “0”, null) was interested. You can’t blame them. It’s probably been a cool thing when you were younger and GnuPG this was about preventing the most powerful targetted attacks. I think people realised that you can’t have people mumble base16 encoded binary strings AND mass adoption. You need to bring at least cake to the party… Anyway, as you might be aware, we’re working towards a more pleasant key signing experience 🙂 So stay tuned for updates.

OpenPGP Key Rollover from D3492A2A to 1BF98D6D

Public Service Announcement: I am deprecating my old key 0xD3492A2A in favour of a newly generated key 0x1BF98D6D. I have uploaded a copy here. It is signed with my old key, too. FTR: It involved exporting the old secret key and the new public key to a temporary directory, change the expiry date of the old key, sign the new key and import the new signed key *sigh*. It’s only 11 years that --allow-expired-keys was discussed.

The new fingerprint is:

$ gpg --fingerprint --list-key 1BF98D6D
pub   3072D/1BF98D6D 2012-05-10 [expires: 2017-05-09]
      Key fingerprint = FF52 DA33 C025 B1E0 B910  92FC 1C34 19BF 1BF9 8D6D
uid                  Tobias Mueller tobias.mueller2  mail.dcu.ie
uid                  Tobias Mueller 4tmuelle  informatik.uni-hamburg.de
sub   3072g/3B76E8B3 2012-05-10 [expires: 2017-05-09]
$

It’s 2012 already and apparently there ain’t such a thing as best practices for rolling over your OpenPGP key. I’m thinking about something that discusses whether or how to

  1. create a new key
  2. adding old UIDs to the new key
  3. sign the new key with the old one
  4. sign the old key with the new one
  5. probably sign the new key with other secret keys in your keyring
  6. preparing a small text file stating the rollover
  7. sign that so that you can upload it to the public
  8. inform people that have signed your old key that a new one is in place

I do think the steps mentioned make sense and should be implemented to easy the key transition. I started with something very simple; you can find the code here. You are welcome to discuss what’s needed in order to properly move from one key to another.

Keysigning BoF at GUADEC

For this year’s GUADEC I like to have a place and time to do some keysigning. I think the last official Keysigning Party was held during the GUADEC in Gran Canaria. So I reserved something on the official BoF wiki, we’ll meet on 30.07 at 16:00 in Room 2.7.

To strengthen the Web of Trust we will have a small Keysigning Party. While we are unfortunately not very good at using OpenPGP, we luckily don’t need to prepare much. So there is no need to send your key to anyone or do anything else, really. We just meet up, exchange key material and convince ourselves about our identities.

Key Rollover

I have deprecated my OpenPGP Key 0xAA208D9E in favour of a new key 0x059B598E. So please use this new key which you can find, i.e. here.

muelli@bigbox ~ $ gpg --fingerprint --list-key 0x059B598E
pub   1024D/059B598E 2010-06-23 [expires: 2015-06-22]
      Key fingerprint = 610C B252 37B3 70E9 EB21  08E8 9CEE 1B6B 059B 598E
uid                  Tobias Mueller
sub   4096g/C71F0BE4 2010-06-23 [expires: 2015-06-22]

muelli@bigbox ~ $

If you’ve signed my old key, you might as well sign my new one (verifying that it’s correctly signed with the old key), assuming that my identity hasn’t changed. I recommend using caff to do so.

Creative Commons Attribution-ShareAlike 3.0 Unported
This work by Muelli is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported.