So, even though I've given a lot of talks in the last 20 years or so, I'm always
a remain kind of nervous a little bit, just want to convey this.
And also, this is a somewhat big milestone in some circles, and I'm very happy to tell
you about AutoCrip 1 was like 2018 or so, and there was a lot of activity and also, you
know, everybody talks about forward secrecy, but before we start the talk, I'd like to
know who of you is actually using a discipline on signal, I mean, who is using signal?
Very good, who is using a default disappearing message for all chats?
Okay, this is for people, out of, you can count.
So these people are one who are profiting most from what is called forward secrecy, because
there's a big difference, not just the magic property, but actually what it does is a
text deletion, and that's why you have on the title reliable deletion, which is kind
of a synonym for forward secrecy, and you see in the spec a little bit why we talk
about this, and I will also talk about it in this talk.
So what is AutoCrip B2?
It's the modern OpenPGP certificate, in case you didn't know last year, there was like
RFC 9580, which is also called like, you know, Crypto Refresh sometimes, was finalized,
it introduces a new framing, it's called V6 keys, and this specification is fully based
on that, and fully interpretable.
It introduces post-plantum and corruption, and it does that by also using the ongoing
TQC, ITF drafts that are also, I don't know, somewhat finalizing soon, and what it
also does, it increments what we call reliable deletion, because that is what forward secrecy
is actually about, and as an additional constraint, because several of us, and I'm very
involved in projects that actually try to work in very bad network conditions, like
even worse than at first game, even when network conditions were part of the internet
it's a completely shut off, and you cannot reach certain servers, you know, so any kind
of central server architecture for doing something also is out of like AutoCrip B2 is more
about that.
What does it protect against?
We shortly, it's store now decrypt later, so basically you think that basically you have
an adversary that sits at the transport layer, even at the server itself, sees all passing
traffic of end-to-end encrypted messages, stores all of that later gets access to a device,
you know, sometime later, just some weeks or whatever, and then can decrypt all of the
traffic that has flowed through the server, even if the user, if the four users here,
had used disappearing messages by default everywhere.
So if you don't delete messages, if you don't delete messages on your device, then you're
not benefiting from following secrecy, because as somebody gets your device, they just
have all the messages, not just that secret key.
The whole thing is just about reliable division, and then you have like the even further thread,
where, you know, there's lots of discussions when these quantum computers arrive, maybe somebody
can wipe code them or so, but it will be sometime, I mean, there's various things that you can
follow in the last year that it's not very close, but anyway, it can happen, and then all of
our current, you know, very important communication would be decrypted in 10 years from now.
If somebody really manages to store all the data, and this is actually these decrypt
data attacks are what autocryptly two protects against. So why it matters for you as well?
You want to be sure that if you delete something, or you have a disappearing chat,
that there's basically no way to recover it for somebody, if it's gone from your device,
then after some time it's also, doesn't matter what somebody collected, like it's gone, you know,
and the particular part that is, it needs to be reliable and completely fragmented network
situations, means you cannot introduce a remote dependency, I first have to ask somewhere,
something like a pre-keyservant like what signal of us, and so if you look at current implementations
in the last 10 years, I think signal was introduced 2013, and at the, at the various attempts from
messengers, implementing reliable deletion. They require networks, they require pre-keys to be
available, what is the current pre-keys from this? There's pre-keys exhaustion attacks,
you just kind of hammer the server, give me all the pre-keys you have until it's exhausted,
and then what? You cannot encrypt anymore, somebody else, and so on, so it's like an attack vector,
you have this network sync, and usually it's central servers, you know, there are attempts to make
this decentralized, talk about this later, and then there's a third complexity, which is, and you know
this, from if you follow the history of the last eight years, is multidivis, like how well
do multidivisers actually synchronize because they need to agree on which keys to drop,
which decryption keys to drop, if they do it too early, they cannot decrypt, you know,
some messengers have this unable to decrypt problem. Out of grip, the two actually does this
different, like it's a completely different approach to doing a reliable deletion, and it's
clock time based. It's a synchronization that is relatively reliable worldwide. There's a whole
section in the drafts back about this, and therefore it doesn't require any network configuration,
any network interaction. It works offline, cannot be exhausted or something like this,
and both between the multidivisers and between any potential servers, there's simply no coordination
required. Everything can be computed offline locally. So there's a big change that would fill
its own bigger talk. Tomorrow there's a checkman architecture talk that is coming from the
literature project that will be about this also this kind of V2 approach. So AutoCrip 1 was
focused just like other traditional ways to do end-to-end encryption on managing a binding,
managing a binding from an inner address to a key or signal from a phone number to a key.
And this binding actually needs to be managed. It's a techable, and V2 actually says,
no, we just do pure cryptographic identity. You can use any transport. You can use email,
you can use XMPP, you can use peer-to-peer, and so on the certificate works, the spec actually is
made for that. So a bit down to the details because some of you will be interested,
post-puntum is using kind of a state-of-the-art combination of MLKm768 and the 25519 encryption.
Hybrid reliable deletion is done by kind of clock-based automatic destruction of secret keys.
It's unlike the massive flexibility that past OpenPGP efforts offered, where the actual PGP structure
can be all kinds of things, all kinds of algorithms. This is like using a modern approach and
it says, no, the certificate is one thing, it has very particular algorithms carefully chosen,
you cannot change them, and it's a fixed size certificate. It's 2,938 bytes always.
It is completely interpretable, there's nothing you need to do, you can use it with any V6 implementation.
And there's PGP, Rust PGP, and Python examples already doing the certificate with some tests.
So how does it look like? This is the 2,938-9 bytes. As a primary key, it has a direct key signature,
and then, and that's the interesting part, it has these two time-based encryption keys.
The one, and that makes it always working, is the fallback key.
That's the key you can always use, like if you don't have any kind of rotated key that is like,
you know, smaller time, you just use the fallback, so encryption always succeeds,
if you happen to be offline somewhere and need to write a message. And then, this is the part that
changes all the time. This is like the rotating safety, currently it's rotating at, I think,
five days, and the spec, petty fault. But, you know, implementations can find ways to change this,
if they like, and it will be discussed in the next time. The schedule is basically in the spec,
if you look at it, it's, it's, the how long is the key valid? Let's say it's valid 10 days,
so we rotate it every five days. Every five days we provide a new key, and basically, the old
P is still also valid for five days, you know, so it's like this overlap, and that makes it also,
like the idea there is to have always the nearest expiring keys, if you chat. So you only
write messages that can be very reliably deleted, like, immediately. The rotating algorithm,
you know, but P-wetting, which is basically carrying a secret, like a decryption key
forward, and generating a new from it. That's what signal does, basically also. And this is also
happening here, so the secret key material is forward, retrojected, but time-based, not
networks and synchronization based, not per message. And that also works, if everybody has the right
worklock, works across devices, they don't even need to talk with each other, they will
deterministically, bitwise, generate the next retrojecting key. How does it work, like the
retrojecting itself is also a relatively standard way to do it? You have some inputs, and you see
there's this sub-p-secret. This is the most important part, this is the input T material. This
actually goes into the T derivation function, you know, and with very particular fixed values,
so there's no flexibility, very easy to analyze. And from these 160 bytes, you know, you split it,
and this becomes the next key. And this contraction actually means that you cannot go back,
that's guaranteed by the T derivation function. It's a pretty standard, it's not. The difference
here is that it is using time, and you can look at the algorithm in this specification to
and the code actually that works to see the details. So how it, I mentioned this, you have the
far back key that always works. If you don't have a time window key, basically, that is currently
valid, you only have the far back key to use that. And the answer comes, you might actually have
the expiring ones, and then it just turns reliable, debatable. And the rotating sub-p, the spec says,
if you have a valid encryption sub-p, you must use it. You cannot use the far back key. If you have a
valid key. And it rotates currently in the spec by default every five days. And it's out of the
stride, like if the key is expired in your local key store, then after some time, you just destroy it.
And that is what guarantees you the reliable deletion. Because then even if they get your device,
the key is not there, and they cannot reverse the key derivation function, just like with
a signal. So how does a PM manage this? It only gets this incoming 2938 byte certificate.
But the peer that receives it actually has might have a few more keys. It sees one key, and then it
sees the next key, and they're both valid, currently, because it's like an overlapping rotation
scheme. And that's fine. And maybe you get a third one, because you don't throw once the others
too fast, because there might be delivery delays in the message thing. And you don't want to get
an important message, like five days later, and you can't decrypt it. You know, this is very
important for people to not have this situation. So if you have a valid one, let's the algorithm.
If you have a valid one, use it. Use any of them. And at best, pick the earliest, with the earliest
expiry. You know, so you get reliable deletion very fast. And never use the far back key if you
have ever taken valid encryption key. So we are talking about reliable deletion, and it is, if you
actually think about it from the UX site of a messenger deletion, you know, there's various deletion
disappearing messages. You can maybe delete something in the history. You can, and then there's
like, in a group chat of like 10 people, and they have like multiple devices, you overall have like
18 devices, actually having a copy of the message. And if you want to be sure that the message
was really deleted, then these devices need to coordinate deletion. This is what the disappearing
messages mode does. And that is outside the scope of this certificate definition. There's
this pure cryptography, and how basically you coordinate on a higher level that the actual
applications running on this really delete their stuff, that's different. Like, you know, probably
if you have heard of that chat, that, you know, they do this, they do this coordinated deletion,
and yeah, but you have to think about this. Just having reliable deletion in your works
on your one device, but you can't remove the copies everywhere else. It's not, you know,
but people actually won from a deletion message. And the hybrid cryptography is just state of the
ad, you mix like a 2551919 and an MLKm768, cryptography scheme, so that an attacker needs to
needs to hack both, like they need to be able to hack both algorithms at the same time to
be able to decrypt. And this basically provides them both
the current security plus the post-frontal one. And again, the OpenPGPS certificate
modern based on RFC 9580 is fixed. It fixes these algorithms. There's no choice. So when we do
the security audits, they will just need to have to look at this, and not like a wide range of possible
things you could possibly do with like half-broken implementations. So what we get for the user,
and that's why we are actually saying in the spec reliable deletion, very strongly,
delete messages are gone forever. Some of us think that the kind of talking about forward
secrecy is too magic. People think, oh yeah, it's very, very important, but it's very hard to
understand, like why? It's just like some experts say, ah, it's very important. But reliable deletion
actually ties it to a user visible feature. You know, this scheme allows to actually delete stuff,
and it's really gone. Nobody can recover it. And the second usability goal also, that was already an
autocrine one, is no user action. You don't need to do anything. Like it's completely
managed by the messaging agent. Comparisons, everybody loves, loves comparisons.
And here we look at the actual kind of cryptographically and architecturally important things,
you know, that there ever ought to be too actually tries to address. So we talked about the
bindings. So if you look at minimal metidata, you'll see that signal matrix and MLS have like,
you know, they have this either they have servers that need to be there, or they have a
manager binding or both. Like signal also a manager is this phone number key binding and you can
attack the SMS channel to actually overtake and you can protect against that real pin and,
you know, end into the secure in-class and whatnot. But there is a binding.
You know, and that makes minimal metidata tricky. I can't, there's only a few minutes.
Decentralized. Well, signal key, matrix, yes. MLS, I think, still trying to figure out how to do the
decodination there. And form a specification, you know, signal has never really specified
but they're really doing their F like some articles and documentation but it's not a specification.
And the simplicity of implementation is something that we value very highly because we need
to maintain the things with very few resources. You don't have 50 million per year. You need to
find schemes that actually are workable that are reliable. And that's why the simple implementation
for us is not just like a, oh yeah, that's nice. It's actually the reason why we took so long
to get some where we now pay this is actually simple. So it's as simple that we actually want to
roll this out this year. And currently it's in the IAPF data tracker. We have some discussions
already and like basically in spring. We are moving towards, we is in this case the kind of data
to a treadmill group towards implementation. And then, you know, because there's some testing phase
rolling out the six certificates and then it will be in all end user releases. That's our
2026 plan. I mean, 2026 is a complicated year already. So you'll see. But I think it's, it's quite
cool. I mean, the implementations already are in parts there. So, yes. So this is out of prep v2.
All right. All right. All right. All right. All right. All right. All right. All right. All right.
All right. So, yeah. All right. All right. Your
have a cryptographic key of someone, then you can encrypt it.
The question is always, since a very long time, how do you get to this key?
And you can query a central C server and says,
I have this email address.
So there's, like, for example, keys.openpgp.org.
And you can say, OK, for this email address, what do you have?
What kind of key is certificate?
And this kind of, I think Rust implemented server actually
makes email verification.
So when you upload this, it actually checks that you really
control these email addresses, so it has a certain,
but you have to trust them.
You have to trust that they actually
manage this binding nicely.
And the binding is like a dictionary in Python,
like a key value, look up or something like this.
I have this thing, a phone number.
I have this thing in email address.
Now, give me the key.
And there's a whole class of systems that work like this.
And a whole tradition around this.
But autocrib V2 is like a different thing.
It's cryptography first.
You say, no, you somehow need to have the key.
We don't care how.
And now we tell you how to do reliable deletion in post-quanto.
You just just use this search.
So you can actually be compatible across various messaging
schemes, because it doesn't talk about the transport.
There is a relation to autocrib V1 and email,
but that's more like a bit a little bit of a side topic.
And this kind of like not doing it with your bindings,
like a new approach that also some other people
have been doing in other systems.
And well, to us, as implementers of end user-usable applications,
it seems it's very worthwhile to go further.
So thanks, Volga.
Hi, Kai.
I see that as a policy.
Autocrib V2 is about an autocrib V2 policy
that's very important to it.
That the recipient must be guaranteed
to follow this policy of deletion.
Yes.
So how do you ensure that the sender can be certain
that the recipient will follow the policy?
If you use email transport, it could
in theory be sent to an email client that doesn't support.
Do you do something like marking it in the certificate?
That's an order of autocrib V2.
I mean, promising to implement the policy
or how do you envision that to get this guarantee?
Yeah, there is a question is, how do you guarantee
and solve the Byzantine's general's problem?
Which is a very kind of deep underlying network issue.
How do you guarantee that another end user app that receives
this and decrypts the message actually deletes it
when I want to, and actually performs the thing?
First, the key and your own kind of transport
that you're connected with, like let's say,
your own email service, your own XMPP, whatever, peer-to-peer,
it protects you and your server because you are deleting
on your device, the decrypting keys.
And if somebody has kind of hacked your server,
you're safe yourself.
But what other people do with their NP-wise
is kind of, you cannot control that.
That's a very nice saying from Heinz von Förster
from, I think, he opened the first conference in 1959
on self-organized systems, where he said,
it's always the receiver of a message
who determines the meaning, you know?
So you can send whatever you want, key flags, whatever.
If the other device is hacked and just say,
I take screenshots, I'm an AI, I just record everything.
Then what?
Then you're at cannot even do anything.
You're running on some AI and you're done.
So the guarantee, basically, of what you'll receive
has actually do with it, is always limited,
by conceptually, fundamentally, you cannot control it.
So only, you know, do trusted chefs with people who don't do this.
You know what I mean?
Where was it?
It was here, right?
You were talking about this structure basically?
And then, say the question exactly?
There's only one.
There's an unchanging for that key.
What key is this actually?
Like how is this used?
only one for the key that never changes is long-term permanent. That can always be used
like even in a year from now, even in two years from now, you know, and this is the only
one that actually rotates and kind of injects new keys. And on the receiving side to just keep
a stash of expiring keys and you choose the soonest expiring one, while the fallback never,
they always stay there. It's the only in this part of the certificate that changes.
Ever?
If you leak, if you leak this whole certificate like your secret key and so on, our recommendation
also for real world users is create to profile, like do a new identity. It's done,
like if you leak your private key, yes, there is something like post-crumpromise security,
but in real world situations, you don't recommend that. If somebody is like in a dangerous situation
and they got their identity taken, they will re-establish. This is the recommendation like,
it doesn't matter what some cryptographic maybe you could recover also.