WEBVTT 00:00.000 --> 00:11.400 Hi everyone, I'm Aron and I am the lead author on the OpenPGP specification for post-cranting 00:11.400 --> 00:17.440 cryptography and I'll introduce also him because sorry if microphone we got only one and 00:17.440 --> 00:22.000 he is the cryptotim lead at Protomew. 00:22.000 --> 00:31.800 He's also the maintainer of OpenPGPJS and GoPenPGP to fairly well known libraries of OpenPGP. 00:31.800 --> 00:37.560 Today we're here to talk about post-cranting cryptography, he had a buzzword as he says and 00:37.560 --> 00:43.800 we're going to first have a little brief look at what is OpenPGP, who knows what is OpenPGP. 00:43.800 --> 00:48.120 That's great, please, next slide. 00:48.120 --> 00:58.360 So this year we just released RFC9580 that is the update, a long-due update to OpenPGP that 00:58.360 --> 01:05.400 deprecates pretty much whatever is in 4880 and introduces new cryptography, it formalizes 01:05.400 --> 01:10.680 a little curves and all of this, it was a random protocol but they were added into certain 01:10.680 --> 01:19.120 side specifications not really clearly and it does a good job and Daniel have the presentation 01:19.120 --> 01:25.560 about this cryptorift flash last year here at Phosem, but everything that is in it is still 01:25.560 --> 01:31.360 classical cryptography, so mostly it focuses on elliptic curves. 01:31.360 --> 01:37.880 Now we have this issue that is quantum computers may be coming, so please we have a nice 01:37.920 --> 01:44.480 picture of a quantum computer that as of now do pretty much nothing and everyone doesn't 01:44.480 --> 01:51.280 know when are they coming, so I we've seen from 2006, well 10 years away is still a little 01:51.280 --> 01:58.280 bit too short, the other day, January 8 I don't know if you can read it probably not, and 01:58.280 --> 02:04.080 VDSC years says they are 20 years away, we don't know whether they're coming, we don't 02:04.120 --> 02:09.440 know when are they coming, but they exactly is like nuclear fusion always stand 02:09.440 --> 02:17.800 years away, next lifeless, so but they might be coming eventually I hope I don't know 02:17.800 --> 02:23.680 may hope not, so we look at the progress of the cubits and effectively it seems like 02:23.680 --> 02:30.720 they are increasing, now a quantum relevant computer to break cryptography it requires 02:30.720 --> 02:38.480 at least 10 to the 9 cubits, we're looking at a very high number, very far away from today, 02:38.480 --> 02:43.520 it might be actually a little bit further away than a practical quantum computer that might 02:43.520 --> 02:49.680 be already able to solve quantum only issues already much earlier, but we also can't wait 02:49.680 --> 02:55.920 till these two lines touch, because at that point it would be too late, you got to think 02:55.920 --> 03:02.480 open PGP is low protocol, I mean we're all here for email so we know that it takes a while 03:02.480 --> 03:08.560 to deploy things, it takes a while to standardize things, it takes a while and once everything 03:08.560 --> 03:13.680 is standardized we still have to encrypt our email with it, and our emails may be sensitive 03:13.680 --> 03:18.720 information for the next 5, 10 years, we don't know depends on the content of the email, so what 03:18.720 --> 03:24.720 we want to do is act now, it's not because I said, so if you want to hear more about quantum 03:24.720 --> 03:32.320 computers, go tomorrow in room K4401, I think it's like the next room, and they are going 03:32.320 --> 03:36.320 to talk about quantum computers, and I think there's a very good question why we'll read 03:36.320 --> 03:42.640 building software for them if we don't even have one, or at least a practical one, but here 03:42.640 --> 03:47.360 we're here to talk about how to build software against them, to protect from this, and that is 03:47.360 --> 03:55.040 something we should start to do right now, so this project actually started in, oh yeah, sorry, 03:55.040 --> 04:02.240 I missed this light, so now what are we focusing on is post-quanting cryptography, post-quanting 04:02.240 --> 04:08.480 cryptography is the cryptography that runs in classical computers and can be, and there's no 04:08.480 --> 04:18.000 known algorithm that can break it onto quantum computers next, so semedagraphography is first of all 04:18.000 --> 04:22.160 just partial effected, this means there's group of algorithm, most of you might have heard about it, 04:22.720 --> 04:29.680 I personally don't really believe in it, but it's not a belief, but it's still very 04:29.680 --> 04:35.840 practical, so I think that it's also where we have a solution doubling key signs, so I don't think 04:35.840 --> 04:42.960 it is that bad, so like I don't think we need to do anything about it, now in passing method 04:42.960 --> 04:48.800 cryptography the game is different because there are polynomial algorithms that would solve 04:48.800 --> 04:56.320 elliptic curves, for instance, so we do have a few a tractor problems that are good, and we know 04:56.320 --> 05:02.800 that so far they they're safe, and the mostly lattice error correction multivariate or hash-based, 05:02.800 --> 05:14.560 so they all of them are significantly lower, have much, much bigger artifacts than elliptic 05:14.560 --> 05:22.640 curves nowadays, maybe with the exception of some lattice problems, so next in fact these 05:22.640 --> 05:30.240 are standardized three algorithms, ML can ML DSA and SLH DSA, ML can ML DSA are structural 05:30.320 --> 05:36.640 lattice-based, they are actually fairly comparable to RSA, let's say, in size and speed, 05:37.760 --> 05:48.080 while it's that SLH DSA is hash-based and it is a monster, it signatures are in the tens of 05:48.080 --> 05:55.200 kilobytes, 200 kilobytes, it takes seconds to generate them, and why should we care about even 05:55.280 --> 06:01.680 why should we care about it is because it gives a much stronger security guarantee than ML algorithms 06:01.680 --> 06:13.200 can, like the security proof is almost bomb proof, next slide, so we started this project in 06:13.200 --> 06:20.640 March 2022, so already two years, three years ago, damn it, three years ago we started this project, 06:20.640 --> 06:27.760 and if you look at it, we are right now with the complete draft, so it takes a very three years 06:27.760 --> 06:31.840 just for the standardization part, clearly, according to computer we're out there, we would act a 06:31.840 --> 06:38.720 little bit faster, but standardization is a pain, we do have an open PGB working group draft that 06:38.720 --> 06:47.440 implements ML can, hybrid with x to ff199 and x for for eight, that's as much as ML DSA as well, 06:47.520 --> 06:54.560 the reason is the trust that we have in these algorithms is good, but partial still, and open PGB 06:54.560 --> 07:00.080 as much as ML, you might have heard that you send an email today, you've stored for the next 20 years, 07:00.080 --> 07:07.120 so what happens if ML DSA or ML can actually broken in the in the future, what we do is 07:07.120 --> 07:14.560 use it hybrid with curves, and then we do have SLH DSA, a standalone, we do trust this security, 07:14.560 --> 07:22.560 and the reason why we decide to embed it is more for software signing, reason is several agencies 07:23.200 --> 07:31.200 in Europe requires hash-based scripted to sign, and open PGB is really big, there, 07:32.240 --> 07:40.240 next thing, so our aim is not to break open PGB, not to break anything, while we deploy this, 07:40.320 --> 07:47.360 we will break something, looking at the delta chat guys, if you try to put an SLH DSA signature 07:47.360 --> 07:53.120 into a delta chat environment, we'll talk about it, we'll see each other outside there, 07:54.400 --> 08:02.160 so I think we do have to investigate what is going to break, but at least for ML can and ML DSA, 08:02.240 --> 08:12.000 they seem to be fairly good substitutions for what we have nowadays, at least comparable to RSA, 08:15.680 --> 08:22.320 but yeah, so this is the we do have three implementations right now, open source, 08:22.320 --> 08:29.280 running with this code, and one, two of them are open PGB and open PGB, that we maintain it 08:29.920 --> 08:35.840 and the third one is RMP, that is the implementation that a Thunderbird is using to do 08:37.040 --> 08:44.560 pre-term, to do open PGB, and this has been done by MTAG and funded by the German security office in German, 08:47.680 --> 08:52.160 these three implementations implement all the task factors that are in the draft, and it seems like 08:53.680 --> 08:58.000 it's looking good, it's looking green as you see, we've filtered out all the ones that don't support it, 08:58.000 --> 09:04.160 that's why it looks so nice, so we will urge, like I think right now we're at the step where we should 09:04.160 --> 09:11.840 ask implementers to actually adopt this to to interoperate with it and uses of mail agents to see 09:12.880 --> 09:17.920 basically what changes do they need to do to the specifications, sorry today, today, 09:17.920 --> 09:24.640 user interface to fit in the specifications because some operations, key generation for an SLHDSA, 09:24.640 --> 09:32.320 key is 17 seconds, so think about it, but the game does not end here because not everything is a 09:32.320 --> 09:37.200 bad news as there are also some good news from Daniel, and the good news come from instead of the 09:37.200 --> 09:48.720 symmetric side, please, thanks, I will stay here too, yes, so Aaron talked about the asymmetric 09:49.680 --> 09:56.800 cryptography, that we're working on adopting an open picture piece, that's kind of the exciting 09:56.800 --> 10:07.280 part that everybody is interested in is the post-quantum, it's the buzzwords, and so on, but we don't actually 10:07.280 --> 10:16.240 always need asymmetric cryptography, and there are cases, for example, in email, if you want to store 10:16.320 --> 10:21.840 something just for yourself, so let's say you're drafting an email and you want to store it 10:21.840 --> 10:30.480 encrypted or your email archive, if you want to store it encrypted on a server for backup purposes, 10:30.480 --> 10:39.360 for example, you can actually encrypt it symmetrically, since you're the only one that needs access to it, 10:39.600 --> 10:49.840 and in that case, using symmetric cryptography is actually much better because it's typically faster, 10:50.800 --> 11:00.880 and as Aaron said before, it's not so much affected by the arrival of cryptographically relevant 11:01.680 --> 11:10.560 quantum computers, so if it's so much faster and so much better, why don't we use it? 11:10.560 --> 11:16.560 Well, until now, open BGP keys have typically only stored asymmetric 11:17.600 --> 11:25.600 key material because they were primarily intended to communicate with other people, and if you are 11:25.600 --> 11:35.520 sending an email out, then yes, you do need asymmetric key material. However, now, we are 11:35.520 --> 11:44.880 proposing to also store symmetric key material in open BGP keys such that, especially in, in those cases, 11:44.880 --> 11:52.160 I was saying before, if you're storing a draft or your email archive, you can still encrypt them 11:52.800 --> 11:59.360 with an open BGP keys, exactly the same as you're doing today, but you can use the symmetric 11:59.360 --> 12:08.000 key material that's stored in there instead, and it can happen almost transparently if you 12:08.000 --> 12:16.000 encrypt with your own private key, it can use the symmetric key material and it will be faster and 12:16.000 --> 12:23.120 smaller and so on, and instead if you're using a certificate or a public key from someone else 12:23.120 --> 12:30.080 to encrypt an email, then the implementation can automatically use the asymmetric 12:30.080 --> 12:36.240 public key in there to encrypt, which is what you need when you actually need to go and send the email. 12:37.680 --> 12:45.280 So, we have a draft describing this, it's not very exciting, but it tells you how to store 12:46.080 --> 12:53.280 the key material in an open BGP key packet and so on, and this draft was adopted in the open BGP 12:53.280 --> 13:01.200 working group last year, and since then we've been discussing it there and working together on 13:01.200 --> 13:09.840 how this should be done, and we have implemented it in our implementations, open BGP.js and 13:09.840 --> 13:18.560 open BGP, so this table is even more selective than the one you saw before, since it has 13:18.560 --> 13:26.400 only two implementations instead of three, but RMP has, I believe, expressed some interest in 13:27.280 --> 13:34.000 implementing it as well, so hopefully also this table can reach a size of three in the future, 13:34.000 --> 13:42.560 and more generally my hope is that all the implementations that are thinking about implementing 13:43.360 --> 13:48.800 both quantum cryptography, given that it's the buzzword and so on, will also think of 13:48.800 --> 13:57.280 implementing good old symmetric cryptography just because it's faster and smaller in the cases 13:57.360 --> 14:06.800 where asymmetric cryptography is not needed. So yeah, in conclusion, quantum computers are coming, 14:06.800 --> 14:14.240 maybe probably possibly, we don't know when, we don't know how good they will be, 14:15.920 --> 14:24.880 and whether they can break the cryptography that we're using today at some point, but it might 14:24.960 --> 14:33.520 happen, so therefore we are working on post quantum cryptography just in case, so post quantum cryptography 14:33.520 --> 14:41.440 is definitely coming, we should be using it to make sure that the emails that people are sending 14:41.440 --> 14:49.440 today are still protected in 20 years, 10 years, 30 years, who knows, but it shouldn't be the 14:49.520 --> 14:57.120 case that they can be decrypted by a three letter agency or whoever happens to record 14:58.240 --> 15:05.920 your emails once they acquire a cryptographically relevant quantum computer, so that's why we're 15:05.920 --> 15:12.960 working on that, it will have some downsides, typically post quantum cryptography is a little bit slower 15:12.960 --> 15:19.200 and the artifacts are a little bit bigger. However, there is also good case, in the case where you can 15:19.280 --> 15:25.440 use symmetric cryptography, it will actually become faster and smaller hopefully instead. 15:27.600 --> 15:32.480 So yeah, that's roughly the conclusion of our talk, so thanks a lot. 15:32.480 --> 15:46.560 So if we go on to this data that I can merely say and how these people see a word of 15:46.560 --> 15:52.480 food for us and everything, so all the email communication until that point that I'm writing 15:52.480 --> 16:00.240 anything are, like, forward to package power and decrypted data, so as soon as possible. 16:00.320 --> 16:05.520 Yes, so the question I will repeat was, if we don't switch to these post quantum algorithms, 16:05.520 --> 16:12.480 such as MLK and MLDSA, all of the emails that you sent today will be vulnerable to the harvest 16:12.480 --> 16:19.920 now decrypted data attack, then there's yes, unfortunately, all the emails if they are recorded by 16:20.800 --> 16:28.240 either the mail transport agents or, like, some three letter agency or whoever records the 16:28.320 --> 16:34.800 start protects of the emails and if they then get a strong enough quantum computer to be able to 16:34.800 --> 16:42.240 break the key, then yes, they would be able to decrypt them at that point, so yes, it is the reason 16:42.240 --> 16:51.520 that we should switch to post quantum cryptography as soon as possible. I would wait until the standard 16:51.520 --> 16:57.280 is finalized and the implementations are rolled out, but yes, it should happen in a near future. 16:58.240 --> 17:04.560 I think like the deadline or complex, like it will be quite easy to move from east or 17:04.560 --> 17:11.440 this CNSA, there's some guidelines from the BSI, there are some guidelines out there from, sorry, 17:11.440 --> 17:17.840 I did forgot to repeat the question, if there's any guideline from any agency that requires 17:17.840 --> 17:24.560 as moving, there are some guidelines they tend to be fairly conflicting, but all aligned at 17:24.640 --> 17:27.760 by 2030, we should be definitely there. 17:27.760 --> 17:37.840 Yes, I did explain a lot with your question, and I mean try it while you didn't, while you 17:37.840 --> 17:43.680 did what the site will implement as soon as I say, yes, and I will tell you. 17:43.680 --> 17:48.400 Sorry, you mentioned that you have implemented, so? 17:48.400 --> 18:01.920 Yes, so the question is, after what happened with the SIDH that was breached in a laptop in 18:01.920 --> 18:09.600 a minute, why didn't we also implement, why did you also re-entimate LCHDSA in a high 18:09.680 --> 18:20.480 profession? So the security proof of SLSDSA is like really, really solid, the other issue that 18:20.480 --> 18:27.360 can happen is an implementation by, so someone who implemented poorly so that it can be recovered 18:27.360 --> 18:36.480 or it can be broken. Our long term idea is to not have hybrids, so the idea is there is clearly 18:36.480 --> 18:43.360 someone thinking you could even make two hybrids out of two different, to different post-Quand 18:43.360 --> 18:52.640 to algorithms, but I think we are aiming at keeping it simple, and therefore we judge that 18:52.640 --> 18:59.120 that algorithm is a may, so it is not a must implement for this draft, and we thought that 18:59.840 --> 19:08.320 whoever trusts it, whoever thinks that it is ready, can use it, but for the must algorithms, 19:08.320 --> 19:16.160 we require the hybrids still. By the way, I wanted to actually something earlier to your question, 19:16.160 --> 19:20.480 and that was the fact that you will need to rotate your certificate, so you will need to generate 19:20.480 --> 19:26.000 a full-inuse certificate deployed on the internet, and it will need to be these six as of now, 19:26.000 --> 19:30.800 so like there is before, is what we are using nowadays, and V6 is what is standardized in the 19:30.800 --> 19:36.880 newer FC, so there will be a transition period as well, where you will need something like two 19:36.880 --> 19:41.280 certificates out there, for people who are legacy and people who understand already in use standard. 19:46.160 --> 19:53.280 Is there already a standard? Yes, V6 is already standardized, PQC, we are trying to get it through 19:53.280 --> 20:02.080 the working group right now, like, sorry, yeah, please, go. 20:02.080 --> 20:30.160 Yeah, the question is what a group is, the implementation of group G and our implementation of post-quantum is interoperable, 20:32.160 --> 20:36.560 apparently personally mentioned into the group G specification as in the acknowledgments, 20:36.560 --> 20:44.160 and I am medium-happy about it, because what happened is that they took an early version of the draft, 20:44.960 --> 20:56.400 and changed a few parameters, and what did, I would say, a type a code, an algorithm ID 29, 20:57.200 --> 21:03.200 and effectively we now switch to algorithm ID 13 instead, because they will not be interoperable, 21:04.240 --> 21:09.200 not only is an older version of the draft, but also has a few design modifications that were 21:09.200 --> 21:17.920 just implemented. Yeah, if you have anything to do with that. So there is some unfortunate history 21:17.920 --> 21:24.000 there, because even already during the crypto refresh, which became the new RFC that 21:24.080 --> 21:34.400 are mentioned, RFC 950, new PG sort of halfway through the process dropped out of collaborating 21:35.120 --> 21:42.720 in this process, because they were unhappy about certain things, and I mean, they were discussed 21:42.720 --> 21:50.880 at length on the working group mailing list, and also in private, and, you know, we tried many 21:50.960 --> 21:58.400 times to reach some kind of compromise, but in the end, we're unable to, which I think is rather 21:58.400 --> 22:05.200 unfortunate, but yeah, the end result is that the group G is at the moment not implementing V6, 22:05.200 --> 22:14.240 which is the version that is defined in a new draft, and they made a fork of the OpenPG standard, 22:14.320 --> 22:23.600 which they call LiPRPGP. So I still remain hopeful that hopefully we can reconsider it, 22:23.600 --> 22:33.040 and maybe, you know, try to get back to being interoperable, but at the moment, it's the case that 22:33.040 --> 22:40.880 KnoPG won't be interoperable with most of the other implementations that we mentioned. 22:44.240 --> 22:51.040 How do you see the clearest path of interoperability with its consensus of which not 22:51.040 --> 22:55.920 going to be used, what parameters you said? So being stubborn, or you mean stubborn, or you 22:55.920 --> 23:01.680 need to re-pote me up? Right. So yeah, so I'll repeat the question, what's the clearest path 23:01.680 --> 23:08.720 to interoperability, and who's at fault, who is being stubborn, right? So the first answer to 23:08.800 --> 23:15.600 the first part in my view is the best would be for everybody to implement everything, which is 23:15.600 --> 23:22.320 not technically very nice solution, but for the user it would probably be the most convenient 23:22.320 --> 23:29.680 if, like, everything worked with every implementation, right? And there is a clear path to that, 23:29.680 --> 23:37.360 it's just a matter of doing the work, right? Well, and also the political agreement, of course, 23:38.080 --> 23:49.040 and we do actually implement some of the things that KnoPG has specified in our libraries for 23:49.040 --> 23:58.080 compatibility reasons. So our hope is that, you know, one day KnoPG will reciprocate and also 23:58.160 --> 24:10.240 implement this stuff. Today, it seems unlikely, but yeah, that is my view, and I think if KnoPG were 24:10.240 --> 24:16.240 open to that, in principle, we would also be open to implementing the other stuff that they specified. 24:16.960 --> 24:22.960 I can't speak for everyone in the OpenPG working group, but that would be my view. 24:23.920 --> 24:31.040 Briefly, the algorithms that are inside, so MLKM, and like the Lipticurves hybrid are the same, 24:31.040 --> 24:37.120 so effectively, we would not need to duplicate the crypto itself, but we just need to duplicate 24:37.120 --> 24:41.120 the whole wrappers around it. That is still bothering, but less. 24:44.720 --> 24:48.000 One minute, can we take one more? It's covered, okay. 24:52.960 --> 25:19.040 Yeah, so this is a good CFRG question, the crypto forum research group at ATF, but I also need to repeat it. 25:20.000 --> 25:26.080 So, TLS is doing things differently, especially when it comes to hybrid camps, why. 25:27.680 --> 25:34.400 I would say that protocols have different requirements, like we do have a long term archival storage 25:34.400 --> 25:40.560 requirement. TLS can just replicate anything right now, and be say, okay, tomorrow these things 25:40.560 --> 25:45.840 doesn't exist anymore, and in a matter of weeks, months it would be disappeared. We would have to 25:45.840 --> 25:54.000 deal it with an ATF 30 years probably. So, I think that that's the main, and also TLS has a 25:54.000 --> 26:00.320 much higher focus on performance. If you look at X-wing, that is one of the combiners that was 26:00.320 --> 26:08.240 proposed in the TLS working group, effectively it is, or we can save our hashing cycle here, 26:09.200 --> 26:14.640 OpenPGP is a monster. As I have you ever seen, have you ever tried to work with it? It will just 26:14.720 --> 26:21.280 be much slower than this. So, effectively, you could argue that we don't need that critic, 26:21.280 --> 26:25.920 it's not that critical in our path, and the constructions that we can allow can include 26:26.560 --> 26:34.240 a broader security proof, because we can afford it into the. I was also in the camcombiner 26:34.240 --> 26:39.680 working group at CFRG, we didn't manage to get to any, and anywhere close to an agreement 26:39.680 --> 26:47.200 on to how does a camcombiner look like? I would have a time question probably for the end. 26:48.240 --> 26:53.360 So, as a crypto dummy, so you had this bar mentioned like, you know, which might be reached at 26:54.800 --> 27:01.440 any ongoing given time. So, now, if I would start using post quantum encryption, obviously, 27:01.440 --> 27:07.520 that bar would, there would be a second bar at a certain time, right? It's there. So, is there any 27:07.520 --> 27:14.160 anticipation of maybe also from the history of classic non-crandom cryptography? Will the first 27:14.160 --> 27:19.280 algorithms to be recommended here be probably vulnerable? Because the immature or something like that, 27:19.280 --> 27:23.840 or will, will that be a safe thing? Because so many experiences have been going into that. 27:25.840 --> 27:32.160 The question, I think the answer goes into more of the algorithms that we have here, 27:32.160 --> 27:38.880 will we find a way to crack them on a quantum computer? If we do, they will, as probably, 27:38.880 --> 27:44.320 we don't know how hard will it be. So, it might be actually that with this bar or even a lower bar. 27:44.320 --> 27:50.160 If we look at a, as a psych, what happened is they even broke it on a normal laptop. So, 27:50.160 --> 27:54.640 the risk is affected. These algorithms are new or each, some are newer, some are older. 27:55.280 --> 28:00.640 And the question is whether they will be broken at all. So, in that regard, we don't know where 28:01.360 --> 28:10.800 if a second bar exists and where would it be? And I don't know. My personal opinion is that 28:10.800 --> 28:17.680 we will not, like, this might actually be quantum resistant for real, but I am happy to have 28:17.680 --> 28:24.800 a more more choice. So, I would be happy to see nest also standardized or other entities, standardized, 28:24.880 --> 28:32.000 other algorithms, so that in OpenPGB we might offer MLKM and also ML, sorry, something, 28:32.000 --> 28:36.240 something else can, that is based on a different problem.