Hi everyone, I'm Aron and I am the lead author on the OpenPGP specification for post-cranting
cryptography and I'll introduce also him because sorry if microphone we got only one and
he is the cryptotim lead at Protomew.
He's also the maintainer of OpenPGPJS and GoPenPGP to fairly well known libraries of OpenPGP.
Today we're here to talk about post-cranting cryptography, he had a buzzword as he says and
we're going to first have a little brief look at what is OpenPGP, who knows what is OpenPGP.
That's great, please, next slide.
So this year we just released RFC9580 that is the update, a long-due update to OpenPGP that
deprecates pretty much whatever is in 4880 and introduces new cryptography, it formalizes
a little curves and all of this, it was a random protocol but they were added into certain
side specifications not really clearly and it does a good job and Daniel have the presentation
about this cryptorift flash last year here at Phosem, but everything that is in it is still
classical cryptography, so mostly it focuses on elliptic curves.
Now we have this issue that is quantum computers may be coming, so please we have a nice
picture of a quantum computer that as of now do pretty much nothing and everyone doesn't
know when are they coming, so I we've seen from 2006, well 10 years away is still a little
bit too short, the other day, January 8 I don't know if you can read it probably not, and
VDSC years says they are 20 years away, we don't know whether they're coming, we don't
know when are they coming, but they exactly is like nuclear fusion always stand
years away, next lifeless, so but they might be coming eventually I hope I don't know
may hope not, so we look at the progress of the cubits and effectively it seems like
they are increasing, now a quantum relevant computer to break cryptography it requires
at least 10 to the 9 cubits, we're looking at a very high number, very far away from today,
it might be actually a little bit further away than a practical quantum computer that might
be already able to solve quantum only issues already much earlier, but we also can't wait
till these two lines touch, because at that point it would be too late, you got to think
open PGP is low protocol, I mean we're all here for email so we know that it takes a while
to deploy things, it takes a while to standardize things, it takes a while and once everything
is standardized we still have to encrypt our email with it, and our emails may be sensitive
information for the next 5, 10 years, we don't know depends on the content of the email, so what
we want to do is act now, it's not because I said, so if you want to hear more about quantum
computers, go tomorrow in room K4401, I think it's like the next room, and they are going
to talk about quantum computers, and I think there's a very good question why we'll read
building software for them if we don't even have one, or at least a practical one, but here
we're here to talk about how to build software against them, to protect from this, and that is
something we should start to do right now, so this project actually started in, oh yeah, sorry,
I missed this light, so now what are we focusing on is post-quanting cryptography, post-quanting
cryptography is the cryptography that runs in classical computers and can be, and there's no
known algorithm that can break it onto quantum computers next, so semedagraphography is first of all
just partial effected, this means there's group of algorithm, most of you might have heard about it,
I personally don't really believe in it, but it's not a belief, but it's still very
practical, so I think that it's also where we have a solution doubling key signs, so I don't think
it is that bad, so like I don't think we need to do anything about it, now in passing method
cryptography the game is different because there are polynomial algorithms that would solve
elliptic curves, for instance, so we do have a few a tractor problems that are good, and we know
that so far they they're safe, and the mostly lattice error correction multivariate or hash-based,
so they all of them are significantly lower, have much, much bigger artifacts than elliptic
curves nowadays, maybe with the exception of some lattice problems, so next in fact these
are standardized three algorithms, ML can ML DSA and SLH DSA, ML can ML DSA are structural
lattice-based, they are actually fairly comparable to RSA, let's say, in size and speed,
while it's that SLH DSA is hash-based and it is a monster, it signatures are in the tens of
kilobytes, 200 kilobytes, it takes seconds to generate them, and why should we care about even
why should we care about it is because it gives a much stronger security guarantee than ML algorithms
can, like the security proof is almost bomb proof, next slide, so we started this project in
March 2022, so already two years, three years ago, damn it, three years ago we started this project,
and if you look at it, we are right now with the complete draft, so it takes a very three years
just for the standardization part, clearly, according to computer we're out there, we would act a
little bit faster, but standardization is a pain, we do have an open PGB working group draft that
implements ML can, hybrid with x to ff199 and x for for eight, that's as much as ML DSA as well,
the reason is the trust that we have in these algorithms is good, but partial still, and open PGB
as much as ML, you might have heard that you send an email today, you've stored for the next 20 years,
so what happens if ML DSA or ML can actually broken in the in the future, what we do is
use it hybrid with curves, and then we do have SLH DSA, a standalone, we do trust this security,
and the reason why we decide to embed it is more for software signing, reason is several agencies
in Europe requires hash-based scripted to sign, and open PGB is really big, there,
next thing, so our aim is not to break open PGB, not to break anything, while we deploy this,
we will break something, looking at the delta chat guys, if you try to put an SLH DSA signature
into a delta chat environment, we'll talk about it, we'll see each other outside there,
so I think we do have to investigate what is going to break, but at least for ML can and ML DSA,
they seem to be fairly good substitutions for what we have nowadays, at least comparable to RSA,
but yeah, so this is the we do have three implementations right now, open source,
running with this code, and one, two of them are open PGB and open PGB, that we maintain it
and the third one is RMP, that is the implementation that a Thunderbird is using to do
pre-term, to do open PGB, and this has been done by MTAG and funded by the German security office in German,
these three implementations implement all the task factors that are in the draft, and it seems like
it's looking good, it's looking green as you see, we've filtered out all the ones that don't support it,
that's why it looks so nice, so we will urge, like I think right now we're at the step where we should
ask implementers to actually adopt this to to interoperate with it and uses of mail agents to see
basically what changes do they need to do to the specifications, sorry today, today,
user interface to fit in the specifications because some operations, key generation for an SLHDSA,
key is 17 seconds, so think about it, but the game does not end here because not everything is a
bad news as there are also some good news from Daniel, and the good news come from instead of the
symmetric side, please, thanks, I will stay here too, yes, so Aaron talked about the asymmetric
cryptography, that we're working on adopting an open picture piece, that's kind of the exciting
part that everybody is interested in is the post-quantum, it's the buzzwords, and so on, but we don't actually
always need asymmetric cryptography, and there are cases, for example, in email, if you want to store
something just for yourself, so let's say you're drafting an email and you want to store it
encrypted or your email archive, if you want to store it encrypted on a server for backup purposes,
for example, you can actually encrypt it symmetrically, since you're the only one that needs access to it,
and in that case, using symmetric cryptography is actually much better because it's typically faster,
and as Aaron said before, it's not so much affected by the arrival of cryptographically relevant
quantum computers, so if it's so much faster and so much better, why don't we use it?
Well, until now, open BGP keys have typically only stored asymmetric
key material because they were primarily intended to communicate with other people, and if you are
sending an email out, then yes, you do need asymmetric key material. However, now, we are
proposing to also store symmetric key material in open BGP keys such that, especially in, in those cases,
I was saying before, if you're storing a draft or your email archive, you can still encrypt them
with an open BGP keys, exactly the same as you're doing today, but you can use the symmetric
key material that's stored in there instead, and it can happen almost transparently if you
encrypt with your own private key, it can use the symmetric key material and it will be faster and
smaller and so on, and instead if you're using a certificate or a public key from someone else
to encrypt an email, then the implementation can automatically use the asymmetric
public key in there to encrypt, which is what you need when you actually need to go and send the email.
So, we have a draft describing this, it's not very exciting, but it tells you how to store
the key material in an open BGP key packet and so on, and this draft was adopted in the open BGP
working group last year, and since then we've been discussing it there and working together on
how this should be done, and we have implemented it in our implementations, open BGP.js and
open BGP, so this table is even more selective than the one you saw before, since it has
only two implementations instead of three, but RMP has, I believe, expressed some interest in
implementing it as well, so hopefully also this table can reach a size of three in the future,
and more generally my hope is that all the implementations that are thinking about implementing
both quantum cryptography, given that it's the buzzword and so on, will also think of
implementing good old symmetric cryptography just because it's faster and smaller in the cases
where asymmetric cryptography is not needed. So yeah, in conclusion, quantum computers are coming,
maybe probably possibly, we don't know when, we don't know how good they will be,
and whether they can break the cryptography that we're using today at some point, but it might
happen, so therefore we are working on post quantum cryptography just in case, so post quantum cryptography
is definitely coming, we should be using it to make sure that the emails that people are sending
today are still protected in 20 years, 10 years, 30 years, who knows, but it shouldn't be the
case that they can be decrypted by a three letter agency or whoever happens to record
your emails once they acquire a cryptographically relevant quantum computer, so that's why we're
working on that, it will have some downsides, typically post quantum cryptography is a little bit slower
and the artifacts are a little bit bigger. However, there is also good case, in the case where you can
use symmetric cryptography, it will actually become faster and smaller hopefully instead.
So yeah, that's roughly the conclusion of our talk, so thanks a lot.
So if we go on to this data that I can merely say and how these people see a word of
food for us and everything, so all the email communication until that point that I'm writing
anything are, like, forward to package power and decrypted data, so as soon as possible.
Yes, so the question I will repeat was, if we don't switch to these post quantum algorithms,
such as MLK and MLDSA, all of the emails that you sent today will be vulnerable to the harvest
now decrypted data attack, then there's yes, unfortunately, all the emails if they are recorded by
either the mail transport agents or, like, some three letter agency or whoever records the
start protects of the emails and if they then get a strong enough quantum computer to be able to
break the key, then yes, they would be able to decrypt them at that point, so yes, it is the reason
that we should switch to post quantum cryptography as soon as possible. I would wait until the standard
is finalized and the implementations are rolled out, but yes, it should happen in a near future.
I think like the deadline or complex, like it will be quite easy to move from east or
this CNSA, there's some guidelines from the BSI, there are some guidelines out there from, sorry,
I did forgot to repeat the question, if there's any guideline from any agency that requires
as moving, there are some guidelines they tend to be fairly conflicting, but all aligned at
by 2030, we should be definitely there.
Yes, I did explain a lot with your question, and I mean try it while you didn't, while you
did what the site will implement as soon as I say, yes, and I will tell you.
Sorry, you mentioned that you have implemented, so?
Yes, so the question is, after what happened with the SIDH that was breached in a laptop in
a minute, why didn't we also implement, why did you also re-entimate LCHDSA in a high
profession? So the security proof of SLSDSA is like really, really solid, the other issue that
can happen is an implementation by, so someone who implemented poorly so that it can be recovered
or it can be broken. Our long term idea is to not have hybrids, so the idea is there is clearly
someone thinking you could even make two hybrids out of two different, to different post-Quand
to algorithms, but I think we are aiming at keeping it simple, and therefore we judge that
that algorithm is a may, so it is not a must implement for this draft, and we thought that
whoever trusts it, whoever thinks that it is ready, can use it, but for the must algorithms,
we require the hybrids still. By the way, I wanted to actually something earlier to your question,
and that was the fact that you will need to rotate your certificate, so you will need to generate
a full-inuse certificate deployed on the internet, and it will need to be these six as of now,
so like there is before, is what we are using nowadays, and V6 is what is standardized in the
newer FC, so there will be a transition period as well, where you will need something like two
certificates out there, for people who are legacy and people who understand already in use standard.
Is there already a standard? Yes, V6 is already standardized, PQC, we are trying to get it through
the working group right now, like, sorry, yeah, please, go.
Yeah, the question is what a group is, the implementation of group G and our implementation of post-quantum is interoperable,
apparently personally mentioned into the group G specification as in the acknowledgments,
and I am medium-happy about it, because what happened is that they took an early version of the draft,
and changed a few parameters, and what did, I would say, a type a code, an algorithm ID 29,
and effectively we now switch to algorithm ID 13 instead, because they will not be interoperable,
not only is an older version of the draft, but also has a few design modifications that were
just implemented. Yeah, if you have anything to do with that. So there is some unfortunate history
there, because even already during the crypto refresh, which became the new RFC that
are mentioned, RFC 950, new PG sort of halfway through the process dropped out of collaborating
in this process, because they were unhappy about certain things, and I mean, they were discussed
at length on the working group mailing list, and also in private, and, you know, we tried many
times to reach some kind of compromise, but in the end, we're unable to, which I think is rather
unfortunate, but yeah, the end result is that the group G is at the moment not implementing V6,
which is the version that is defined in a new draft, and they made a fork of the OpenPG standard,
which they call LiPRPGP. So I still remain hopeful that hopefully we can reconsider it,
and maybe, you know, try to get back to being interoperable, but at the moment, it's the case that
KnoPG won't be interoperable with most of the other implementations that we mentioned.
How do you see the clearest path of interoperability with its consensus of which not
going to be used, what parameters you said? So being stubborn, or you mean stubborn, or you
need to re-pote me up? Right. So yeah, so I'll repeat the question, what's the clearest path
to interoperability, and who's at fault, who is being stubborn, right? So the first answer to
the first part in my view is the best would be for everybody to implement everything, which is
not technically very nice solution, but for the user it would probably be the most convenient
if, like, everything worked with every implementation, right? And there is a clear path to that,
it's just a matter of doing the work, right? Well, and also the political agreement, of course,
and we do actually implement some of the things that KnoPG has specified in our libraries for
compatibility reasons. So our hope is that, you know, one day KnoPG will reciprocate and also
implement this stuff. Today, it seems unlikely, but yeah, that is my view, and I think if KnoPG were
open to that, in principle, we would also be open to implementing the other stuff that they specified.
I can't speak for everyone in the OpenPG working group, but that would be my view.
Briefly, the algorithms that are inside, so MLKM, and like the Lipticurves hybrid are the same,
so effectively, we would not need to duplicate the crypto itself, but we just need to duplicate
the whole wrappers around it. That is still bothering, but less.
One minute, can we take one more? It's covered, okay.
Yeah, so this is a good CFRG question, the crypto forum research group at ATF, but I also need to repeat it.
So, TLS is doing things differently, especially when it comes to hybrid camps, why.
I would say that protocols have different requirements, like we do have a long term archival storage
requirement. TLS can just replicate anything right now, and be say, okay, tomorrow these things
doesn't exist anymore, and in a matter of weeks, months it would be disappeared. We would have to
deal it with an ATF 30 years probably. So, I think that that's the main, and also TLS has a
much higher focus on performance. If you look at X-wing, that is one of the combiners that was
proposed in the TLS working group, effectively it is, or we can save our hashing cycle here,
OpenPGP is a monster. As I have you ever seen, have you ever tried to work with it? It will just
be much slower than this. So, effectively, you could argue that we don't need that critic,
it's not that critical in our path, and the constructions that we can allow can include
a broader security proof, because we can afford it into the. I was also in the camcombiner
working group at CFRG, we didn't manage to get to any, and anywhere close to an agreement
on to how does a camcombiner look like? I would have a time question probably for the end.
So, as a crypto dummy, so you had this bar mentioned like, you know, which might be reached at
any ongoing given time. So, now, if I would start using post quantum encryption, obviously,
that bar would, there would be a second bar at a certain time, right? It's there. So, is there any
anticipation of maybe also from the history of classic non-crandom cryptography? Will the first
algorithms to be recommended here be probably vulnerable? Because the immature or something like that,
or will, will that be a safe thing? Because so many experiences have been going into that.
The question, I think the answer goes into more of the algorithms that we have here,
will we find a way to crack them on a quantum computer? If we do, they will, as probably,
we don't know how hard will it be. So, it might be actually that with this bar or even a lower bar.
If we look at a, as a psych, what happened is they even broke it on a normal laptop. So,
the risk is affected. These algorithms are new or each, some are newer, some are older.
And the question is whether they will be broken at all. So, in that regard, we don't know where
if a second bar exists and where would it be? And I don't know. My personal opinion is that
we will not, like, this might actually be quantum resistant for real, but I am happy to have
a more more choice. So, I would be happy to see nest also standardized or other entities, standardized,
other algorithms, so that in OpenPGB we might offer MLKM and also ML, sorry, something,
something else can, that is based on a different problem.