WEBVTT 00:00.000 --> 00:10.040 So, even though I've given a lot of talks in the last 20 years or so, I'm always 00:10.040 --> 00:14.560 a remain kind of nervous a little bit, just want to convey this. 00:14.560 --> 00:24.440 And also, this is a somewhat big milestone in some circles, and I'm very happy to tell 00:24.440 --> 00:33.080 you about AutoCrip 1 was like 2018 or so, and there was a lot of activity and also, you 00:33.080 --> 00:38.120 know, everybody talks about forward secrecy, but before we start the talk, I'd like to 00:38.120 --> 00:45.120 know who of you is actually using a discipline on signal, I mean, who is using signal? 00:45.120 --> 00:52.160 Very good, who is using a default disappearing message for all chats? 00:52.160 --> 01:00.000 Okay, this is for people, out of, you can count. 01:00.000 --> 01:07.480 So these people are one who are profiting most from what is called forward secrecy, because 01:07.480 --> 01:16.600 there's a big difference, not just the magic property, but actually what it does is a 01:16.600 --> 01:21.520 text deletion, and that's why you have on the title reliable deletion, which is kind 01:21.520 --> 01:27.360 of a synonym for forward secrecy, and you see in the spec a little bit why we talk 01:27.360 --> 01:30.760 about this, and I will also talk about it in this talk. 01:30.760 --> 01:34.920 So what is AutoCrip B2? 01:34.920 --> 01:41.080 It's the modern OpenPGP certificate, in case you didn't know last year, there was like 01:41.080 --> 01:48.080 RFC 9580, which is also called like, you know, Crypto Refresh sometimes, was finalized, 01:48.080 --> 01:54.320 it introduces a new framing, it's called V6 keys, and this specification is fully based 01:54.320 --> 01:57.520 on that, and fully interpretable. 01:57.520 --> 02:05.680 It introduces post-plantum and corruption, and it does that by also using the ongoing 02:05.680 --> 02:13.040 TQC, ITF drafts that are also, I don't know, somewhat finalizing soon, and what it 02:13.040 --> 02:19.760 also does, it increments what we call reliable deletion, because that is what forward secrecy 02:19.760 --> 02:27.160 is actually about, and as an additional constraint, because several of us, and I'm very 02:27.160 --> 02:32.640 involved in projects that actually try to work in very bad network conditions, like 02:32.640 --> 02:39.640 even worse than at first game, even when network conditions were part of the internet 02:39.640 --> 02:44.720 it's a completely shut off, and you cannot reach certain servers, you know, so any kind 02:44.720 --> 02:50.240 of central server architecture for doing something also is out of like AutoCrip B2 is more 02:50.240 --> 02:54.240 about that. 02:54.240 --> 02:57.880 What does it protect against? 02:57.880 --> 03:04.400 We shortly, it's store now decrypt later, so basically you think that basically you have 03:04.400 --> 03:10.440 an adversary that sits at the transport layer, even at the server itself, sees all passing 03:10.440 --> 03:20.440 traffic of end-to-end encrypted messages, stores all of that later gets access to a device, 03:20.440 --> 03:25.320 you know, sometime later, just some weeks or whatever, and then can decrypt all of the 03:25.320 --> 03:30.600 traffic that has flowed through the server, even if the user, if the four users here, 03:30.600 --> 03:35.880 had used disappearing messages by default everywhere. 03:35.880 --> 03:45.080 So if you don't delete messages, if you don't delete messages on your device, then you're 03:45.080 --> 03:50.080 not benefiting from following secrecy, because as somebody gets your device, they just 03:50.080 --> 03:53.400 have all the messages, not just that secret key. 03:53.480 --> 03:59.160 The whole thing is just about reliable division, and then you have like the even further thread, 03:59.160 --> 04:04.040 where, you know, there's lots of discussions when these quantum computers arrive, maybe somebody 04:04.040 --> 04:10.680 can wipe code them or so, but it will be sometime, I mean, there's various things that you can 04:10.680 --> 04:15.080 follow in the last year that it's not very close, but anyway, it can happen, and then all of 04:15.080 --> 04:21.320 our current, you know, very important communication would be decrypted in 10 years from now. 04:21.560 --> 04:26.280 If somebody really manages to store all the data, and this is actually these decrypt 04:26.280 --> 04:32.840 data attacks are what autocryptly two protects against. So why it matters for you as well? 04:32.840 --> 04:36.920 You want to be sure that if you delete something, or you have a disappearing chat, 04:38.120 --> 04:42.840 that there's basically no way to recover it for somebody, if it's gone from your device, 04:42.840 --> 04:48.120 then after some time it's also, doesn't matter what somebody collected, like it's gone, you know, 04:48.840 --> 04:56.200 and the particular part that is, it needs to be reliable and completely fragmented network 04:56.200 --> 05:01.480 situations, means you cannot introduce a remote dependency, I first have to ask somewhere, 05:01.480 --> 05:11.960 something like a pre-keyservant like what signal of us, and so if you look at current implementations 05:12.040 --> 05:20.920 in the last 10 years, I think signal was introduced 2013, and at the, at the various attempts from 05:20.920 --> 05:29.560 messengers, implementing reliable deletion. They require networks, they require pre-keys to be 05:29.560 --> 05:34.600 available, what is the current pre-keys from this? There's pre-keys exhaustion attacks, 05:35.240 --> 05:39.480 you just kind of hammer the server, give me all the pre-keys you have until it's exhausted, 05:39.480 --> 05:44.760 and then what? You cannot encrypt anymore, somebody else, and so on, so it's like an attack vector, 05:44.760 --> 05:50.280 you have this network sync, and usually it's central servers, you know, there are attempts to make 05:50.280 --> 05:56.040 this decentralized, talk about this later, and then there's a third complexity, which is, and you know 05:56.040 --> 06:01.880 this, from if you follow the history of the last eight years, is multidivis, like how well 06:01.880 --> 06:07.560 do multidivisers actually synchronize because they need to agree on which keys to drop, 06:08.440 --> 06:13.960 which decryption keys to drop, if they do it too early, they cannot decrypt, you know, 06:13.960 --> 06:19.880 some messengers have this unable to decrypt problem. Out of grip, the two actually does this 06:19.880 --> 06:24.840 different, like it's a completely different approach to doing a reliable deletion, and it's 06:24.840 --> 06:31.320 clock time based. It's a synchronization that is relatively reliable worldwide. There's a whole 06:31.320 --> 06:38.360 section in the drafts back about this, and therefore it doesn't require any network configuration, 06:38.360 --> 06:43.320 any network interaction. It works offline, cannot be exhausted or something like this, 06:44.120 --> 06:50.920 and both between the multidivisers and between any potential servers, there's simply no coordination 06:50.920 --> 06:59.880 required. Everything can be computed offline locally. So there's a big change that would fill 06:59.960 --> 07:05.080 its own bigger talk. Tomorrow there's a checkman architecture talk that is coming from the 07:05.080 --> 07:14.760 literature project that will be about this also this kind of V2 approach. So AutoCrip 1 was 07:14.760 --> 07:21.240 focused just like other traditional ways to do end-to-end encryption on managing a binding, 07:21.240 --> 07:28.040 managing a binding from an inner address to a key or signal from a phone number to a key. 07:30.520 --> 07:35.880 And this binding actually needs to be managed. It's a techable, and V2 actually says, 07:35.880 --> 07:42.280 no, we just do pure cryptographic identity. You can use any transport. You can use email, 07:42.280 --> 07:47.720 you can use XMPP, you can use peer-to-peer, and so on the certificate works, the spec actually is 07:47.720 --> 07:59.400 made for that. So a bit down to the details because some of you will be interested, 08:00.840 --> 08:13.960 post-puntum is using kind of a state-of-the-art combination of MLKm768 and the 25519 encryption. 08:13.960 --> 08:22.120 Hybrid reliable deletion is done by kind of clock-based automatic destruction of secret keys. 08:23.000 --> 08:34.600 It's unlike the massive flexibility that past OpenPGP efforts offered, where the actual PGP structure 08:34.600 --> 08:42.280 can be all kinds of things, all kinds of algorithms. This is like using a modern approach and 08:42.280 --> 08:47.720 it says, no, the certificate is one thing, it has very particular algorithms carefully chosen, 08:47.800 --> 08:55.400 you cannot change them, and it's a fixed size certificate. It's 2,938 bytes always. 08:57.080 --> 09:02.840 It is completely interpretable, there's nothing you need to do, you can use it with any V6 implementation. 09:04.760 --> 09:11.320 And there's PGP, Rust PGP, and Python examples already doing the certificate with some tests. 09:11.720 --> 09:21.320 So how does it look like? This is the 2,938-9 bytes. As a primary key, it has a direct key signature, 09:22.120 --> 09:28.120 and then, and that's the interesting part, it has these two time-based encryption keys. 09:28.920 --> 09:32.920 The one, and that makes it always working, is the fallback key. 09:34.120 --> 09:40.440 That's the key you can always use, like if you don't have any kind of rotated key that is like, 09:40.520 --> 09:45.560 you know, smaller time, you just use the fallback, so encryption always succeeds, 09:45.560 --> 09:51.960 if you happen to be offline somewhere and need to write a message. And then, this is the part that 09:51.960 --> 09:58.600 changes all the time. This is like the rotating safety, currently it's rotating at, I think, 09:58.600 --> 10:05.640 five days, and the spec, petty fault. But, you know, implementations can find ways to change this, 10:05.720 --> 10:13.320 if they like, and it will be discussed in the next time. The schedule is basically in the spec, 10:13.320 --> 10:19.880 if you look at it, it's, it's, the how long is the key valid? Let's say it's valid 10 days, 10:20.840 --> 10:29.880 so we rotate it every five days. Every five days we provide a new key, and basically, the old 10:29.960 --> 10:36.920 P is still also valid for five days, you know, so it's like this overlap, and that makes it also, 10:36.920 --> 10:43.800 like the idea there is to have always the nearest expiring keys, if you chat. So you only 10:43.800 --> 10:52.920 write messages that can be very reliably deleted, like, immediately. The rotating algorithm, 10:53.880 --> 11:00.120 you know, but P-wetting, which is basically carrying a secret, like a decryption key 11:00.120 --> 11:07.160 forward, and generating a new from it. That's what signal does, basically also. And this is also 11:07.160 --> 11:15.000 happening here, so the secret key material is forward, retrojected, but time-based, not 11:15.080 --> 11:23.960 networks and synchronization based, not per message. And that also works, if everybody has the right 11:25.800 --> 11:30.680 worklock, works across devices, they don't even need to talk with each other, they will 11:30.680 --> 11:40.360 deterministically, bitwise, generate the next retrojecting key. How does it work, like the 11:40.360 --> 11:46.840 retrojecting itself is also a relatively standard way to do it? You have some inputs, and you see 11:46.840 --> 11:52.680 there's this sub-p-secret. This is the most important part, this is the input T material. This 11:52.680 --> 11:59.480 actually goes into the T derivation function, you know, and with very particular fixed values, 11:59.480 --> 12:06.040 so there's no flexibility, very easy to analyze. And from these 160 bytes, you know, you split it, 12:06.120 --> 12:12.440 and this becomes the next key. And this contraction actually means that you cannot go back, 12:12.440 --> 12:18.360 that's guaranteed by the T derivation function. It's a pretty standard, it's not. The difference 12:18.360 --> 12:23.800 here is that it is using time, and you can look at the algorithm in this specification to 12:24.600 --> 12:32.840 and the code actually that works to see the details. So how it, I mentioned this, you have the 12:32.840 --> 12:38.840 far back key that always works. If you don't have a time window key, basically, that is currently 12:38.840 --> 12:43.560 valid, you only have the far back key to use that. And the answer comes, you might actually have 12:43.560 --> 12:53.160 the expiring ones, and then it just turns reliable, debatable. And the rotating sub-p, the spec says, 12:53.160 --> 12:59.560 if you have a valid encryption sub-p, you must use it. You cannot use the far back key. If you have a 12:59.560 --> 13:06.200 valid key. And it rotates currently in the spec by default every five days. And it's out of the 13:06.200 --> 13:13.080 stride, like if the key is expired in your local key store, then after some time, you just destroy it. 13:13.080 --> 13:18.360 And that is what guarantees you the reliable deletion. Because then even if they get your device, 13:19.160 --> 13:24.120 the key is not there, and they cannot reverse the key derivation function, just like with 13:24.120 --> 13:34.200 a signal. So how does a PM manage this? It only gets this incoming 2938 byte certificate. 13:34.840 --> 13:40.520 But the peer that receives it actually has might have a few more keys. It sees one key, and then it 13:40.520 --> 13:45.080 sees the next key, and they're both valid, currently, because it's like an overlapping rotation 13:45.800 --> 13:51.400 scheme. And that's fine. And maybe you get a third one, because you don't throw once the others 13:51.480 --> 13:57.480 too fast, because there might be delivery delays in the message thing. And you don't want to get 13:57.480 --> 14:02.760 an important message, like five days later, and you can't decrypt it. You know, this is very 14:02.760 --> 14:09.240 important for people to not have this situation. So if you have a valid one, let's the algorithm. 14:09.240 --> 14:15.880 If you have a valid one, use it. Use any of them. And at best, pick the earliest, with the earliest 14:15.960 --> 14:22.920 expiry. You know, so you get reliable deletion very fast. And never use the far back key if you 14:22.920 --> 14:36.440 have ever taken valid encryption key. So we are talking about reliable deletion, and it is, if you 14:36.440 --> 14:43.960 actually think about it from the UX site of a messenger deletion, you know, there's various deletion 14:44.760 --> 14:51.400 disappearing messages. You can maybe delete something in the history. You can, and then there's 14:51.400 --> 14:57.480 like, in a group chat of like 10 people, and they have like multiple devices, you overall have like 14:57.480 --> 15:04.200 18 devices, actually having a copy of the message. And if you want to be sure that the message 15:04.200 --> 15:11.240 was really deleted, then these devices need to coordinate deletion. This is what the disappearing 15:11.400 --> 15:21.400 messages mode does. And that is outside the scope of this certificate definition. There's 15:21.400 --> 15:27.480 this pure cryptography, and how basically you coordinate on a higher level that the actual 15:27.480 --> 15:33.640 applications running on this really delete their stuff, that's different. Like, you know, probably 15:33.640 --> 15:39.800 if you have heard of that chat, that, you know, they do this, they do this coordinated deletion, 15:40.600 --> 15:46.600 and yeah, but you have to think about this. Just having reliable deletion in your works 15:46.600 --> 15:52.520 on your one device, but you can't remove the copies everywhere else. It's not, you know, 15:52.520 --> 16:01.000 but people actually won from a deletion message. And the hybrid cryptography is just state of the 16:01.000 --> 16:12.440 ad, you mix like a 2551919 and an MLKm768, cryptography scheme, so that an attacker needs to 16:14.440 --> 16:21.080 needs to hack both, like they need to be able to hack both algorithms at the same time to 16:22.680 --> 16:30.040 be able to decrypt. And this basically provides them both 16:30.760 --> 16:38.200 the current security plus the post-frontal one. And again, the OpenPGPS certificate 16:38.920 --> 16:46.760 modern based on RFC 9580 is fixed. It fixes these algorithms. There's no choice. So when we do 16:46.760 --> 16:52.280 the security audits, they will just need to have to look at this, and not like a wide range of possible 16:52.360 --> 17:02.280 things you could possibly do with like half-broken implementations. So what we get for the user, 17:02.280 --> 17:07.080 and that's why we are actually saying in the spec reliable deletion, very strongly, 17:08.040 --> 17:14.200 delete messages are gone forever. Some of us think that the kind of talking about forward 17:14.200 --> 17:19.560 secrecy is too magic. People think, oh yeah, it's very, very important, but it's very hard to 17:19.560 --> 17:24.440 understand, like why? It's just like some experts say, ah, it's very important. But reliable deletion 17:24.440 --> 17:30.200 actually ties it to a user visible feature. You know, this scheme allows to actually delete stuff, 17:30.200 --> 17:39.960 and it's really gone. Nobody can recover it. And the second usability goal also, that was already an 17:39.960 --> 17:46.680 autocrine one, is no user action. You don't need to do anything. Like it's completely 17:46.840 --> 17:54.680 managed by the messaging agent. Comparisons, everybody loves, loves comparisons. 17:55.720 --> 18:01.240 And here we look at the actual kind of cryptographically and architecturally important things, 18:01.240 --> 18:10.920 you know, that there ever ought to be too actually tries to address. So we talked about the 18:10.920 --> 18:18.280 bindings. So if you look at minimal metidata, you'll see that signal matrix and MLS have like, 18:19.320 --> 18:24.120 you know, they have this either they have servers that need to be there, or they have a 18:24.120 --> 18:29.000 manager binding or both. Like signal also a manager is this phone number key binding and you can 18:29.000 --> 18:34.600 attack the SMS channel to actually overtake and you can protect against that real pin and, 18:34.600 --> 18:39.400 you know, end into the secure in-class and whatnot. But there is a binding. 18:40.120 --> 18:45.720 You know, and that makes minimal metidata tricky. I can't, there's only a few minutes. 18:48.520 --> 18:56.040 Decentralized. Well, signal key, matrix, yes. MLS, I think, still trying to figure out how to do the 18:56.680 --> 19:02.920 decodination there. And form a specification, you know, signal has never really specified 19:02.920 --> 19:07.400 but they're really doing their F like some articles and documentation but it's not a specification. 19:08.120 --> 19:15.320 And the simplicity of implementation is something that we value very highly because we need 19:15.320 --> 19:21.160 to maintain the things with very few resources. You don't have 50 million per year. You need to 19:21.160 --> 19:26.440 find schemes that actually are workable that are reliable. And that's why the simple implementation 19:26.440 --> 19:31.320 for us is not just like a, oh yeah, that's nice. It's actually the reason why we took so long 19:31.320 --> 19:38.040 to get some where we now pay this is actually simple. So it's as simple that we actually want to 19:39.480 --> 19:46.120 roll this out this year. And currently it's in the IAPF data tracker. We have some discussions 19:46.120 --> 19:52.120 already and like basically in spring. We are moving towards, we is in this case the kind of data 19:52.200 --> 19:59.160 to a treadmill group towards implementation. And then, you know, because there's some testing phase 20:00.600 --> 20:05.800 rolling out the six certificates and then it will be in all end user releases. That's our 20:08.280 --> 20:16.440 2026 plan. I mean, 2026 is a complicated year already. So you'll see. But I think it's, it's quite 20:16.920 --> 20:25.080 cool. I mean, the implementations already are in parts there. So, yes. So this is out of prep v2. 20:34.360 --> 20:39.000 All right. All right. All right. All right. All right. All right. All right. All right. All right. 20:39.000 --> 21:08.600 All right. So, yeah. All right. All right. Your 21:08.600 --> 21:13.800 have a cryptographic key of someone, then you can encrypt it. 21:13.800 --> 21:18.800 The question is always, since a very long time, how do you get to this key? 21:18.800 --> 21:22.240 And you can query a central C server and says, 21:22.240 --> 21:23.600 I have this email address. 21:23.600 --> 21:27.000 So there's, like, for example, keys.openpgp.org. 21:27.000 --> 21:29.600 And you can say, OK, for this email address, what do you have? 21:29.600 --> 21:32.680 What kind of key is certificate? 21:32.680 --> 21:38.280 And this kind of, I think Rust implemented server actually 21:38.280 --> 21:39.280 makes email verification. 21:39.280 --> 21:41.400 So when you upload this, it actually checks that you really 21:41.400 --> 21:44.000 control these email addresses, so it has a certain, 21:44.000 --> 21:45.520 but you have to trust them. 21:45.520 --> 21:47.400 You have to trust that they actually 21:47.400 --> 21:49.560 manage this binding nicely. 21:49.560 --> 21:52.760 And the binding is like a dictionary in Python, 21:52.760 --> 21:55.400 like a key value, look up or something like this. 21:55.400 --> 21:57.080 I have this thing, a phone number. 21:57.080 --> 21:58.880 I have this thing in email address. 21:58.880 --> 22:01.280 Now, give me the key. 22:01.280 --> 22:04.240 And there's a whole class of systems that work like this. 22:04.240 --> 22:06.840 And a whole tradition around this. 22:06.840 --> 22:09.840 But autocrib V2 is like a different thing. 22:09.840 --> 22:11.400 It's cryptography first. 22:11.400 --> 22:13.760 You say, no, you somehow need to have the key. 22:13.760 --> 22:15.280 We don't care how. 22:15.280 --> 22:18.600 And now we tell you how to do reliable deletion in post-quanto. 22:18.600 --> 22:21.080 You just just use this search. 22:21.080 --> 22:24.360 So you can actually be compatible across various messaging 22:24.360 --> 22:27.680 schemes, because it doesn't talk about the transport. 22:27.680 --> 22:29.720 There is a relation to autocrib V1 and email, 22:29.720 --> 22:33.600 but that's more like a bit a little bit of a side topic. 22:33.600 --> 22:38.240 And this kind of like not doing it with your bindings, 22:38.240 --> 22:40.600 like a new approach that also some other people 22:40.600 --> 22:42.920 have been doing in other systems. 22:42.920 --> 22:48.240 And well, to us, as implementers of end user-usable applications, 22:48.240 --> 22:51.000 it seems it's very worthwhile to go further. 22:55.640 --> 22:58.080 So thanks, Volga. 22:58.080 --> 22:59.680 Hi, Kai. 22:59.760 --> 23:02.680 I see that as a policy. 23:02.680 --> 23:06.040 Autocrib V2 is about an autocrib V2 policy 23:06.040 --> 23:08.160 that's very important to it. 23:08.160 --> 23:10.320 That the recipient must be guaranteed 23:10.320 --> 23:12.200 to follow this policy of deletion. 23:12.200 --> 23:12.880 Yes. 23:12.880 --> 23:18.680 So how do you ensure that the sender can be certain 23:18.680 --> 23:21.760 that the recipient will follow the policy? 23:21.760 --> 23:25.160 If you use email transport, it could 23:25.160 --> 23:28.880 in theory be sent to an email client that doesn't support. 23:28.880 --> 23:33.440 Do you do something like marking it in the certificate? 23:33.440 --> 23:36.320 That's an order of autocrib V2. 23:36.320 --> 23:38.800 I mean, promising to implement the policy 23:38.800 --> 23:43.360 or how do you envision that to get this guarantee? 23:43.360 --> 23:51.360 Yeah, there is a question is, how do you guarantee 23:51.360 --> 23:55.240 and solve the Byzantine's general's problem? 23:55.240 --> 24:00.840 Which is a very kind of deep underlying network issue. 24:00.840 --> 24:03.840 How do you guarantee that another end user app that receives 24:03.840 --> 24:06.040 this and decrypts the message actually deletes it 24:06.040 --> 24:11.000 when I want to, and actually performs the thing? 24:11.000 --> 24:16.240 First, the key and your own kind of transport 24:16.240 --> 24:17.560 that you're connected with, like let's say, 24:17.560 --> 24:22.680 your own email service, your own XMPP, whatever, peer-to-peer, 24:22.680 --> 24:26.560 it protects you and your server because you are deleting 24:26.560 --> 24:31.080 on your device, the decrypting keys. 24:31.080 --> 24:36.440 And if somebody has kind of hacked your server, 24:36.440 --> 24:38.680 you're safe yourself. 24:38.680 --> 24:42.280 But what other people do with their NP-wise 24:42.280 --> 24:45.360 is kind of, you cannot control that. 24:45.360 --> 24:47.160 That's a very nice saying from Heinz von Förster 24:47.160 --> 24:50.480 from, I think, he opened the first conference in 1959 24:50.480 --> 24:53.280 on self-organized systems, where he said, 24:53.280 --> 24:55.840 it's always the receiver of a message 24:55.840 --> 25:00.080 who determines the meaning, you know? 25:00.080 --> 25:03.280 So you can send whatever you want, key flags, whatever. 25:03.280 --> 25:05.000 If the other device is hacked and just say, 25:05.000 --> 25:08.960 I take screenshots, I'm an AI, I just record everything. 25:08.960 --> 25:10.160 Then what? 25:10.160 --> 25:11.480 Then you're at cannot even do anything. 25:11.480 --> 25:14.480 You're running on some AI and you're done. 25:14.480 --> 25:16.600 So the guarantee, basically, of what you'll receive 25:16.600 --> 25:18.960 has actually do with it, is always limited, 25:18.960 --> 25:23.080 by conceptually, fundamentally, you cannot control it. 25:23.080 --> 25:28.360 So only, you know, do trusted chefs with people who don't do this. 25:28.360 --> 25:29.360 You know what I mean? 25:29.360 --> 25:30.360 You know what I mean? 25:30.360 --> 25:31.360 You know what I mean? 25:31.360 --> 25:32.360 You know what I mean? 25:32.360 --> 25:33.360 You know what I mean? 25:33.360 --> 25:34.360 You know what I mean? 25:34.360 --> 25:35.360 You know what I mean? 25:35.360 --> 25:36.360 You know what I mean? 25:36.360 --> 25:37.360 You know what I mean? 25:37.360 --> 25:38.360 You know what I mean? 25:38.360 --> 25:39.360 You know what I mean? 25:39.360 --> 25:40.360 You know what I mean? 25:40.360 --> 25:41.360 You know what I mean? 25:41.360 --> 25:42.360 You know what I mean? 25:42.360 --> 25:43.360 You know what I mean? 25:43.360 --> 25:44.360 You know what I mean? 25:44.360 --> 25:45.360 You know what I mean? 25:45.360 --> 25:46.360 You know what I mean? 25:46.360 --> 25:47.360 You know what I mean? 25:47.360 --> 25:48.360 You know what I mean? 25:48.360 --> 25:49.360 You know what I mean? 25:49.360 --> 25:50.360 You know what I mean? 25:50.360 --> 25:51.360 You know what I mean? 25:51.360 --> 25:52.360 You know what I mean? 25:52.360 --> 25:53.360 You know what I mean? 25:53.360 --> 25:54.360 You know what I mean? 25:54.360 --> 25:55.360 You know what I mean? 25:56.360 --> 26:10.360 Where was it? 26:10.360 --> 26:11.360 It was here, right? 26:11.360 --> 26:13.360 You were talking about this structure basically? 26:13.360 --> 26:17.360 And then, say the question exactly? 26:17.360 --> 26:18.360 There's only one. 26:18.360 --> 26:21.360 There's an unchanging for that key. 26:21.360 --> 26:22.360 What key is this actually? 26:22.360 --> 26:24.360 Like how is this used? 26:24.360 --> 26:29.720 only one for the key that never changes is long-term permanent. That can always be used 26:29.720 --> 26:35.560 like even in a year from now, even in two years from now, you know, and this is the only 26:35.560 --> 26:41.480 one that actually rotates and kind of injects new keys. And on the receiving side to just keep 26:41.480 --> 26:48.120 a stash of expiring keys and you choose the soonest expiring one, while the fallback never, 26:48.120 --> 26:54.120 they always stay there. It's the only in this part of the certificate that changes. 26:54.120 --> 26:58.120 Ever? 26:58.120 --> 27:07.480 If you leak, if you leak this whole certificate like your secret key and so on, our recommendation 27:07.480 --> 27:13.720 also for real world users is create to profile, like do a new identity. It's done, 27:13.720 --> 27:18.040 like if you leak your private key, yes, there is something like post-crumpromise security, 27:19.240 --> 27:23.800 but in real world situations, you don't recommend that. If somebody is like in a dangerous situation 27:23.800 --> 27:29.560 and they got their identity taken, they will re-establish. This is the recommendation like, 27:29.560 --> 27:33.000 it doesn't matter what some cryptographic maybe you could recover also.