Welcome everyone. I hope you can hear me well. I am Daniel Huygens. I am the cryptography
team lead at Proton and I will be talking about modernizing email encryption today,
primarily about the new version of the OpenBGP standard, but also about the OpenBGP standard
more generally and sorry, the OpenBGP ecosystem more generally and how it has evolved in recent
times. And I will in fact start with the latter because OpenBGP has a rather bad reputation
at least as far as it comes to the user experience. And you might remember having to generate a
key manually using KnoopaG in the comment line and that used to be basically the only way to use
PGP. But it's no longer the case. So my employer would like to tell you that obviously Proton
made everything better and you know it's so much easier now, but it's not only Proton also
Thunderbird has OpenBGP support built in now. You still have to click a few buttons, but it's
much easier than before. And also other applications like FlowCrypt make it much easier to use
encrypted email. And for a technical audience like this one, you might think well it's not a big
deal, I can use the comment line or I even prefer it and that's perfectly reasonable and fine. But
for a wider audience, this is really important. And also for us it's important because you want to
write encrypted emails not only to yourself, but also to your friends. So the more people that use
encrypted email, the more reason there is in fact to use it. And so the user experience is also very
important and it has improved over the past decade or so. Then regarding the libraries, there used to
be basically only one open source, open PGP implementation which is GNUMPG. And of course
GNUMPG is still around, but there are many more implementations nowadays. So for example,
OpenBGP and OpenBGP.js are two implementations that Proton maintains and uses. And then there's
PGP English which is specifically designed to be easy to use and it's a Java implementation,
a wrapper on Balty Castle. Then there's PGPI, a Python implementation, RMP, a C++ implementation
that's used in Thunderbird. And there is Zekoya which is a new implementation in Rust which Neil
presented on in the main track earlier today. If you happen to have come across that, it aims to
provide a modern implementation of OpenBGP also for the comment line, basically providing a drop
in replacement for GNUMPG. And then key distribution. You might remember that back in the day,
you might have to export your key manually and then attach it to your emails or upload it to a
key server manually. All of that is also not really necessary anymore today. So there is the
key server protocol. Well, it has been around for a while but it's more widely used now and can be
used by applications to automatically upload keys and also automatically fetch public keys
of your friends. If you want to send an encrypted email to someone, your email application can
automatically fetch keys to do so. And WebKey directory can do something similar but instead
of fetching from a key server, you can fetch the public key from the domain of the email address
that you're sending to. So if your provider supports that or if you're self-hosting your email,
it can serve your public keys that way. And then finally, there's AutoCrypt which is a way to send
public keys in email headers so that also again, the user doesn't have to worry about it and
everything should work automatically hence the name. So slightly diving into HP key server,
I won't dive into it very much because the presentation is not primarily about that. But
so as you can see, you can simply make an HP request to fetch a public key for a given email
address and you get an open HP key back if there is one and then you can use that. And WKD is very
similar except instead of making a request to a key server, you make a request to the domain of the
email address as I said before. All right, then talking a bit about key verification, you might
remember that FOSSTEM used to host very cool key signing parties. And as you can see, these people
are having a lot of fun and although the party hats have been photoshopped on, but nevertheless,
it can be fun but admittedly, most people don't want to spend their time doing this in 2024.
At least the average user probably doesn't. So there is an alternative to that as well,
which is called key transparency. And I've presented about it at a previous FOSSTEM but just
summarizing briefly, the idea behind key transparency is that we publish all the public
keys of our users or of the provider's users or the key servers, public keys or whatever
to an append-only transparency log somewhat similar to a certificate transparency. For example,
if you heard of it, it's a concept where TLS certificates are published to a central
transparency log that's an append-only log and everyone can verify that the TLS certificates
that you are getting are in that log and therefore are probably not malicious. And the basic idea
here is the same. We publish the openBGP certificates to a transparency log and then in this case,
all the owners of the public keys need to check their own keys because they're the ones that
then generated them and know whether it's the correct public key or not. So they go and check
in the key transparency log whether the public key for their email address is correct. And then
everybody else who fetches the public key can be certain that it's the correct public key
given that everyone sees the same keys. So it's roughly similar to a blockchain in a way. I know
it's a dirty word, but the concept is vaguely similar. Everyone has the same view over the data
and if everyone checks the keys, everyone can be sure that all the keys are correct. And we have
shipped this at Proton. There is also a working group at the ITF to standardize key transparency,
not specifically for OpenBGP, but the general concept. And we would also like to standardize
the use of key transparency for OpenBGP so that not only Proton users can benefit from this, but
all OpenBGP email can be protected in this way because the advantage of this again is that all
of that is fully automatic. So the OpenBGP implementation or the email client, let's say,
can verify the keys without the user having to do anything. So it makes the use of
end-to-end encrypted email much simpler. All right, so then getting to the actual OpenBGP standard.
First, a short history. The current OpenBGP standard stems from 2007, believe it or not,
so it's new for an update. Although it's not the case that nothing has happened since then,
so there was an RFC for adding the Chamelea Cipher and also for adding Elliptic Curve
cryptography using the NIST curves in 2009 and 2012, respectively. But that's the last RFC
related to OpenBGP that was published. After that, there have been a number of drafts,
one for adding EDDSA that has been widely implemented and also adding Curve25519 has
been fairly widely implemented, but nevertheless has never been standardized. And there are a
number of other things that were kind of overdue. So the RFC 480 BIS draft was in fact intended to be
become an RFC as well, but that never happened. And then the CryptoRefresh is the most recent draft
and that will become an RFC very soon. It's currently in the editor's queue,
so it should become an RFC in the coming weeks, hopefully. So what is actually in the CryptoRefresh?
Well, a lot of things, since it's been so long since we had an update, there were a lot of things
that needed to be updated or that we wanted to update. So first of all, it merges the previous
RFCs for Camelia and ECC. Then it standardizes finally Curve25519 as well as Curve4Fraight and
the Brain Pool Curves, which are commonly used by the German government and they like them.
But they are not mandatory to implement. Curve25519 is mandatory to implement Curve4Fraight,
recommended to be implemented. Brain Pool is fully optional, so they can use it. Everybody
else doesn't have to. Then it also adds modern AAD encryption, authenticated encryption,
which was also fairly overdue, so it adds the use of OCB, EX, and GCM. GCM was slightly
controversial, so I'll dive slightly into that. So first, OCB is the mandatory to implement
algorithm. EX and GCM are fully optional. The reason that they're there is because even though
OCB, in theory, should be fastest. In practice, in our testing, particularly GCM is usually
fastest because it often has assembly implementations, for example. That's part of the reason why
it's there. Another reason is because GCM is standardized by NIST, and so it's FIPS-approved.
So for the people that care about that, they can use that. But again, it's fully optional. So
for those that want to use the theoretically fastest, or once it becomes actually fastest,
everyone can use OCB. Then also a memory hard password hashing function was added,
Argon2. The previous password hashing function in OpenBGP was very weak, so this was also very,
very necessary. This means that if you, for example, encrypt your keys with a password,
they're protected much more strongly. Of course, it's still important to choose a strong password,
but it has become much more expensive to do brute force attack on that password.
Then it deprecates a number of legacy algorithms, such as RSA with weak keys, DSA,
Algomal, and so on. All of those things that we really shouldn't be using in 2024 have been
deprecated. Then it prevents a number of key overriding attacks that we discovered in collaboration
with ETH Turic a few years ago, that we worked around in our implementations, but the workaround
was fairly expensive. So now they've been fixed in the spec, which is a much cheaper way to do it.
So for the implementations that worked around those issues, they should provide essentially
a free performance improvement. And by the way, the AAD algorithms also essentially improve the
performance as well. So it's not just, the main focus was about improving the security,
but improving the performance is basically an added benefit.
Then finally, it's not quite finally, it also protects against future vulnerabilities in
hash algorithms by sorting signatures such that if for example, SHA2 ever becomes broken in a way
that SHA1 was, even though we don't expect that today, but it provides some protection against
that. And then finally, it adds a padding packet, which means that if you want to hide the size of
your files or the size of your message when you're sending an email or of your attachments,
you can do that by adding a padding packet to hide the size of the unencrypted data.
All right, then for what's next, you might think, well, what about this? So the obvious one is
post quantum cryptography, which we have also been working on, but is not yet in the crypto refresh
yet. But there is a separate draft for the use of post quantum cryptography in OpenPGP,
so that will come relatively soon as well. And then finally, we are, again, quite finally,
we also would like to start working on forward secrecy. That's not quite as far along yet,
but perfect forward secrecy is obviously something that Signal, for example, has been
championing and is a good security property to have in an encryption standard, although it's
slightly more difficult to achieve in an email context since you're storing emails basically
forever usually, but still there are some improvements that we can and would like to make.
And then, as I mentioned before, we would also like to standardize key transparency for OpenPGP.
So then as to the implementation status, here you can see a graph. Some of the implementations
are already very far along. Some of them not quite yet. Also, notably for its absence is
Gnupig. Unfortunately, it seems like Gnupig does not want to implement the crypto refresh and
rather would like to stick with the previous drafts, RFC 480B, which they have rebranded Libra
PGP, which is a rather shrewd marketing move, I would say, since Libra Office is better than Open
Office, so clearly Libra PGP should be better than OpenPGP, right? But actually it's not the case,
it's more or less a rebranded version of the old standard. And there is a lot of controversy
about it at the moment, so I felt like I couldn't really get around that. So I've here included
a short comparison. In the interest of time, I won't go through all of the points, but
I would say the technical differences are very minor and in my personal opinion,
should not have led to such a big schism in the community. And in fact, I still am somewhat
hopeful that we can find some sort of resolution, particularly if you consider that RFC 480B
originally was intended to become an RFC. If it had become an RFC and people had implemented that,
then the crypto refresh would have been an update to that and we would have basically
had to implement both anyway. And my proposed resolution is essentially that, I would argue that
everyone should implement both. If you're going to implement the crypto refresh, implementing Libra
PGP as well as not that much added effort, the other way around, there is a bit more effort. I
haven't heard any objections from any of the other implementations to implementing crypto refresh,
so I still hope that GNU-BG eventually will do so as well, although it seems unlikely at the moment.
But let's see. So in conclusion, we're trying to drag OpenBGP into the 21st century. Hopefully,
we've succeeded. Thank you. And my other point that I would like you to take away is it's becoming
more and more possible to build modern email encryption applications using OpenBGP. It doesn't
have to have the UX of 10, 20 years ago. And finally, I hope that everyone will implement
and use the crypto refresh. Thanks a lot. Thank you very much.
I see one straight hand immediately, so this needs to be rewarded instantly.
Hi. First question that comes to my mind, especially when you compared GNU-BG to other
implementations, is what about hardware support? Because in my mind, and this is why I haven't used
either of these implementations, especially those JavaScript based, is that I'd like to keep
these keys in my hand on a device. So what about it? Yes. So there is an open pull request for
OpenBGP.js to add support for hardware based keys, although in full disclosure, it has been a bit
idle in the last while. But I still hope that someone will do the work to support it also in
other implementations. I'm not fully up to date on what's the status for the support in all the
libraries, but certainly it would be good to add support elsewhere as well. Yes.
Another question, actually. I wanted to congratulate you hard to felt for not having the
suckful user interfaces that PGP used to have. This sounds hopeful. Thanks. Thank you.
I'm very excited about your approach to key transparency, well, or protons, not yours personally.
I think it's very good. Do you have any thoughts on the relocation transparency to make that more?
Yes. So in our implementation of key transparency, we do include, for example, when the user marks a
key as compromised or obsolete, it is included in key transparency. So this means that once that's
included, other people shouldn't use the key anymore, right? And I would imagine that in the
standardized version, you would similarly include revocations in key transparency such that
when you revoke a key, you can be sure that others won't use it anymore.
The way I don't, you just get a new record for the mapping, which is not the relocation.
Yes. So we always support updates to the key. So the key transparency always provides a snapshot
in time. So we repeatedly publish all the keys, conceptually speaking. And also when you generate
a new key, the keys are updated, but also when you revoke a key. So essentially it will be the same
thing. When you were going through your list of new changes in OpenGBT, you were talking a lot
about these optional features. But does it make sense to have optional features when both ends
kind of need to implement them in order to be able to communicate with the... Sorry, I didn't
fully hear what kind of features were you saying? The optional features like the... Optional features,
I see. So there is a lot of new mandatory features as well. Curve 25519 is mandatory to
implement. OSEB is mandatory to implement. But to be perfectly honest, a standard doesn't have that
much power over implementations just by existing. Every implementation in the end can choose what
they implement, even if we write that it's mandatory in the spec. We hope that everyone will
implement the mandatory parts and the optional parts as well, usually. But we can't force anyone,
right? All right. Thank you again, Daniel, for that interesting talk.