No evidence of communication and implementing a protocol: Off-the-Record protocol version 4
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 561 | |
| Autor | ||
| Lizenz | CC-Namensnennung 2.0 Belgien: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/44442 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
VersionsverwaltungProtokoll <Datenverarbeitungssystem>TelekommunikationDatensatzInformationstechnikDigitalsignalEmulationInstantiierungTermKonfiguration <Informatik>ImplementierungProgrammverifikationZahlzeichenUmwandlungsenthalpieArithmetisches MittelSoftwareAggregatzustandTermClientImplementierungDatenmissbrauchMultiplikationsoperatorZentrische StreckungAlgorithmusPunktKugelElektronische UnterschriftComputersicherheitProtokoll <Datenverarbeitungssystem>MereologieKryptologieRatsche <Physik>Kategorie <Mathematik>InformationDelisches ProblemDifferenteElliptische KurveVersionsverwaltungTelekommunikationKartesische KoordinatenKonfiguration <Informatik>Wort <Informatik>National Institute of Standards and TechnologyReelle ZahlInverser LimesPhysikalisches SystemPerfekte GruppeKonfigurationsraumKurvenanpassungProgrammierungGrenzschichtablösungDatenfeldBildverstehenSeitenkanalattackeOrdnung <Mathematik>ComputerspielVorzeichen <Mathematik>UnrundheitZweiDatensatzSchnittmengeUmsetzung <Informatik>ProgrammverifikationFeuchteleitungBitComputervirusPuls <Technik>InformationstechnikQuantisierung <Physik>E-MailBildschirmmaskeChatten <Kommunikation>SpieltheorieSoftwareentwicklerCoxeter-GruppeExpertensystemMessage-PassingGleitendes MittelComputeranimation
09:20
Protokoll <Datenverarbeitungssystem>Sigma-AlgebraPunktDualitätstheorieKryptologieSmith-DiagrammTypentheorieCAN-BusVersionsverwaltungAffiner RaumURLTypentheorieMomentenproblemSchlüsselverwaltungDifferenteZweiAuthentifikationElektronischer FingerabdruckKategorie <Mathematik>BitUmsetzung <Informatik>SystemidentifikationProgrammverifikationPunktMessage-PassingArithmetisches MittelMAPIdentitätsverwaltungElektronische UnterschriftSchaltnetzCASE <Informatik>MereologieUmwandlungsenthalpieTermComputersicherheitInternetworkingOrdnung <Mathematik>BeweistheorieVersionsverwaltungChiffrierungATMPaarvergleichTLSProtokoll <Datenverarbeitungssystem>Elliptische KurveFitnessfunktionKontrollstrukturAlgorithmusKryptologieQuantencomputerKlassische PhysikInformationOffice-PaketPrimitive <Informatik>EindeutigkeitSchlüsselverteilungGruppenoperationService providerMultiplikationsoperatorsinc-FunktionBenutzerbeteiligungProgrammfehlerSigma-AlgebraVideokonferenzDefaultLokales Minimum
18:33
VersionsverwaltungFreier LadungsträgerMessage-PassingDatenmodellTelekommunikationGruppenkeimE-MailImplementierungKryptologieROM <Informatik>Protokoll <Datenverarbeitungssystem>HalbleiterspeicherSchreib-Lese-KopfProtokoll <Datenverarbeitungssystem>AdressraumServerCompilerBenchmarkZahlenbereichMessage-PassingInformationsspeicherungUmwandlungsenthalpieEndliche ModelltheorieKryptologieElliptische KurveImplementierungQuellcodeZweiSchlüsselverteilungPeer-to-Peer-NetzSchnittmengeInverser LimesBitKlassische PhysikComputersicherheitQubitProgrammierspracheChiffrierungProgrammbibliothekMAPCodeMultiplikationsoperatorReelle ZahlClientDelisches ProblemTermSoftwaretestHydrostatikMereologieKategorie <Mathematik>SchlüsselverwaltungRechter WinkelEindeutigkeitElement <Gruppentheorie>AusnahmebehandlungAlgorithmusKurvenanpassungRatsche <Physik>VererbungshierarchiePrimitive <Informatik>QuantencomputerNichtlinearer OperatorATMGruppenoperationArithmetische FolgeUmsetzung <Informatik>Ordnung <Mathematik>VersionsverwaltungInstant MessagingTelekommunikationVerschlingungTransportproblemHash-AlgorithmusCASE <Informatik>DoS-AttackeQuantisierung <Physik>Software Development KitMinimalgradMathematikMetropolitan area networkWinkelSystem FPrimidealArithmetisches MittelPlug inInformationDeskriptive StatistikGreen-FunktionGeradeComputeranimation
27:27
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:11
I have to show like up to 25 minutes. Okay, perfect. If you enter earlier, it's something for questions. Okay. It's up to you. So, hello everyone.
00:22
Welcome our next speaker, Sofia Celi and Ola Bini, and their talk about no evidence communication and implementing a protocol of the record protocol version 4.
00:40
Hello, hello. Thank you very much. I'm Ola, and yes, as we just said we're going to be talking about OTR version 4. I think we might be winning a prize for the longest title. We are actually here from an NGO called Centro de Autonomia de Guital in Quito, Ecuador. So, we have come pretty far, and we're super happy to be here,
01:01
both me and my colleague Sofia. Okay. Hello, my name is Sofia, and as Ola said already, the title of the presentation, I think we don't need introduction around that. But we also wanted to talk a little bit about, in this talk a little bit, why we need the secure messaging, and why is this a problem until this day.
01:21
So, for this we first wanted to start with a quote of one of the most famous papers in cryptography by Philip Rogaway, which is called The Moral Character of Cryptographic Work. And he states, most academic cryptographers seems to think that a field is a fun, deep, and political neutral game, a set of puzzles involving communicating parties and notion as adversities. This vision of who we are animates a field whose work is
01:42
intellectually impressive and rapidly produced, but also quite inbred and aborts from real world concerns. It is what cryptography should be like, is this is how we should spend the bulk of our intellectual capital. The reason why we decided to build this quote here is because when we are trying to design a protocol, a cryptographic algorithm, a primitive, or whatever it is,
02:02
or actually trying to implement it, we oftentimes forget that we are making this for real world users, for people who are going to use it. And sometimes the reason why we create these cryptographic algorithms is because they mean the difference between the life or death of a political activist or a journalist. Something that Philip Rovaway continues in his paper is that
02:23
while the cryptographic community have researched a lot around all the kinds of ideas, they have a little bit, not researched so much onto the secure messaging sphere. And we think this is something that we should start thinking in a more crucial way, because one of the reasons why people use the internet and use the digital world is actually to communicate
02:40
with each other. They use chat, bloopers, email, and those are all forms of communication. So giving users, clients that are actually not secure, is something that we shouldn't do because actually that's what people are using most of the times. Around this, of course, we also wanted to talk about why we need protocols, because of course you can have
03:00
a secure chat messaging application, but if you don't state to the user exactly what is being used, then it's no use for them because they don't know exactly what kind of software they are being given. We need protocols because we need options that actually work. We need to show to the user actually what is happening, what cryptographic algorithm has been chosen, why it's been used, why it was chosen this way.
03:23
We need further specification because it's not enough to say that we use elliptic curve cryptography, we use a certain algorithm. We need to state exactly how we use that elliptic curve cryptography, how we take into account several configurations that elliptic curve cryptography takes into account. I don't know, cofactual issues, timing issues,
03:41
side channel attacks. We need to also state exactly how different cryptographic algorithms interact with each other. It's not enough to say that you use the double ratchet algorithm in your protocol. It should be stated how the double ratchet algorithm works with the other algorithms your protocol has. We also need probabilities, limitations, and requirements.
04:01
Of course we need that because we need to define to the users exactly what we are giving them. If we're going to give a protocol that says that we are giving them an end-to-end point security, then of course we should state in what manner we're giving this. If we're going to say to a user that we're going to give them the ability properties, then we should state which kind of the ability properties and in that what way.
04:22
We should also tell them the limitations that our protocol has. For example, in OTR before we had the limitation that we didn't use any post-quantum algorithm because actually any of the post-quantum algorithms that have been chosen in the second round of candidates by the NIST competition has not been actually implemented in a worldwide way. So we shouldn't strive to create a protocol
04:41
that says this has a post-quantum algorithm when none of the post-quantum algorithms that exist right now can be deployed at a worldwide scale. And we should also state to them which requirements do they need in order to have the protocol. We also need protocols that update existing definition because big terms get to better define.
05:01
Sometimes in the cryptographic community you don't have a term that is well defined. But years later you will have it defined. So you always need to update protocols. The reason that a protocol exists doesn't mean that it's the best protocol or it's the last word of a protocol. It's just said that it matches up with existing cryptographic literature
05:20
that exists at that point. And of course we need reviews and verifications. We need ideas from different places and we need implementations. This is all related because we need when we create a protocol not to say that I created and it should be perfect because I created. It should have reviews and verifications from other parties, from different parties, from the software developers, from implementers,
05:41
from the cryptographers, from the security experts, et cetera. And we need ideas from different places and this is something that we try to emphasize in OTR before because it's not enough to say that we have protocols that oftentimes always come from the global north. We also need solutions that come from the global south because if you're giving us software for the whole world then the whole world also means the global south.
06:01
This is something that we are also very proud actually OTR before was mainly developed in Brazil and Ecuador. And yeah, we need implementations because if you are developing a protocol then of course you need it to show that it actually can be implemented. So actually going back to two points that I think I really want to emphasize and the first one is that this question
06:22
of specification is quite interesting. I don't know if anyone in this room has spent any time looking at the specifications that underlie the applications that are used today. For example, typical example would be signal. If anyone tried to implement the signal specification you will find that actually exactly this
06:41
is a real problem. It's actually really hard to implement signal and as far as I know most of the people that have tried to implement signal ends up using one of the existing implementations because the specifications that are out there simply doesn't give enough information to specify it. And another part of this is the reason why we need the properties and limitations
07:01
and requirements really deeply specified in the specification is that we want it to be possible for the academic community to review the work we have done. And if we don't specify what properties we're actually seeking to achieve, if we're not specific enough about these things it will be very hard for the academic community to look at the work we have done
07:21
and tell us hey, you actually do this. You actually do what you set out to do. And this is also one of the things that you will find if you look at the security audits and reviews of many of the existing programs and systems out there such as Telegram, such as Signal and many other that actually it's hard for the academic community to contribute because they can't actually
07:41
look at the specifications and see what they're trying to do. Half the work that academics have to do, researchers have to do is to look at the implementations to see wait, okay, they say, I don't know, forward secrecy here but actually they mean something completely different. And at the end of the day that makes it much, much harder and the barrier to entry
08:01
for review much trickier. So we forgot to say in the introduction we should have mentioned that we're actually we're leading the current team implementing OTR version four as well. So we're representing the full OTR team and we're implementing it. Now we've talked about a bunch of stuff and maybe we should actually talk a little bit about what OTR is.
08:21
So OTR is a protocol that stands for off the record messaging. It was created in 2004 by a team of academics, Ian Goldberg, Nikita Borisov, and Eric Brewer. And the idea was that basically when we're having a conversation in the real world, assuming that there are no recording devices, we can have a conversation, just me and another person.
08:44
And you and I, we know that we were talking to each other and we know that the other person said what they said but there is no way for that other person to go away and claim to a third person, hey, Ola said this, and prove it. Of course they can say that I said something but they can't actually prove it.
09:01
However, in our current world we have two different situations. We have situations where plain text is being thrown around and of course plain text means that anyone can read it so there is no privacy in those conversations. Or we have situations like with PGP where we're signing all of our stuff in a way that means that anyone can forward a signature to someone else.
09:20
And at that point it becomes very, very hard to deny that you said anything. So the idea of OTR is actually that we want something that takes back this middle ground. We want conversations to be like in the real world instead of making them more problematic by giving more evidence that something actually was said.
09:41
So OTR gives you authentication, meaning that we know who the other person is that we're talking to. It gives you encryption so that we know that someone else can't actually intercept what we're talking about. And the authentication is done in a deniable way. And we're gonna come back to deniability in a second. In version two there was also another
10:01
kind of step forward introduced called the Socialist Millionaires Protocol that allows us to actually verify that the other person is who we think they are by using another means instead of comparing fingerprints. Now comparing fingerprints is still possible but SMP is also another way of doing authentication. Now OTR, since OTR is quite old,
10:21
was kind of a trailblazer and inspired many other protocols because this idea of combining authentication with deniability was quite new at that point in time. And we are now in a situation where OTR version three has existed for roughly eight or 10 years and at that point we decided a few years ago
10:42
that version four needed to be created for a lot of reasons. We're gonna come back to the reasons why. So basically we have three different parts of this that I've already talked about. We have authentication. In OTR version three it's using an authenticated key exchange using a variant
11:00
of something called the Sigma Protocol which is a combination of signatures and MACs to be able to do this deniability. With verification I already mentioned SMP and fingerprint comparison. And finally we have end-to-end encryption where all messages are encrypted but all messages are also authenticated in a deniable way. Okay.
11:22
Okay, so around the properties that OTR in general wanted to attain. So of course OTR wanted to attain forward secrecy which means that you should have unique keys with encryption of its message. Yeah, which is break back wall protection which means that forward secrecy is quite related to post compromised security
11:41
or what was called in the past backward secrecy which means that even if you compromise one of the message keys, one of the unique keys that was used to encrypt a message you will not be able to decrypt previous or future messages. And why is this important and why does the academics that created OTR decided to have it? Because of course for example in PGP
12:01
if you get hold of the long term secret key then people will be able to actually decrypt future and past messages. And we didn't want it to have that in OTR so we did so. A lot of people decided that there will be unique keys for each message and if you get hold of one of them then you will not be able to decrypt past the future messages.
12:21
This is post compromised secrecy which I already talked about. Of course, and then of course what is OTR mainly known about? OTR is mainly known about a thing called inability. As all of us already said, this is a quite important property and why it's important to have it in a digital world is because in real conversations you have this property granted by default.
12:40
No one can actually say that you said anything unless you are recorded by video and audio. On most countries, not on all countries, but in most countries you will have to get, you will have to accept that you will be recorded by video or by audio if you're saying something into a conversation. But we don't have this in the digital world because actually all over the world when you use the internet you're always recorded.
13:02
Some data will exist that will link you to a certain conversation and we don't want that. So that's basically the inability in the terms of OTR. Well it's a common goal for secure messaging. Consider as in you were both accused as Alice of sending a specific message. Just in the judge must decide whether or not he believes that Alice actually did so.
13:21
If both can provide evidence that Alice sent the message such as a bi-link cryptographic signature of the message under Alice's long-term key, then we say that the action is non-reputable. Of course this happens in GPG because you actually authenticate the message and anyone can say, oh this digital signature is actually linked to your identity so whatever you said in this is actually you.
13:41
We don't want that in OTR. In OTR what we want is that you will have the same identifications you have in GPG but in a way that you can also deny it. There's different types of deniability and this is something we wanted to update it in OTR. We have only an offline message and participation deniability. Message and participation deniability are the easiest to explain because that actually means
14:02
that you can deny having sent a message or that you can deny having participated into a conversation. Now online and offline deniability are quite interesting in the sense that offline deniability is the classical deniability we knew from past versions of OTR. Basically means that after a conversation has happened
14:20
you can actually deny having said anything because anyone could have forged a transcript afterwards. Online deniability is a new property that is quite important in the sense that during the conversation someone can actually someone can actually try to collude with you in order to make someone say something for you.
14:43
So for example something that actually happens with people like me that come from the global south is that you will go to a border and a patrol of the border, an officer of the border will actually ask you to surrender your phone and unlock it. And what they often do is that something they open up your chat application and start messaging with someone else.
15:02
This is actually colluding with something you have on your phone to make someone say something that they otherwise would not say. So for example let's say that I'm an activist and that the border is surrounding my phone and they started to talk to other activists so they can get information about these other activists or make them say something
15:20
so they can get later prosecuted. So actually giving online deniability means that during that moment that person actually has during that moment a proof that he actually can deny whatever he said during that moment, not after the conversation ended. Okay. Okay, so why version four, right?
15:44
As we mentioned already there is a bunch of stuff in OTR version three and everything we've said up until the deniability stuff was in version three. The biggest difference when it comes to deniability just to make this clear is that OTR version three does not have participation deniability and version three does not have online deniability.
16:02
Now Sophie just explained online deniability and it's a little bit of a strange concept. It takes a while reading through the papers to understand what it actually means. Participation deniability is a little bit easier. Basically it just means that you can deny that you said anything specific but you cannot deny that you had a conversation.
16:21
So if I've had an OTR conversation with Sophie using OTR version three there is digital proof that I actually had that conversation. But there is no digital proof that can't be denied that I said anything specific. Now in some cases this can be important because in some cases having a conversation with a specific individual might be dangerous
16:40
or might be something that you can be prosecuted for by itself in certain regimes. So we want all these types of deniability. We've already talked about forward and post-compromise secrecy. These are very important properties that every single property, if you don't have a very specific reason to not have them, every protocol should have them.
17:01
This is actually really true, forward secrecy, the last five years has become accepted in most of the world and TLS 1.3, if I remember correctly, actually deprecates the key exchange modes that are not forward secure, which is great. It's a great step forward. But post-compromise security and secrecy is also an important property.
17:21
We want to create a higher security level. OTR version 3 is roughly at a level of 80 bits and that's primarily because of the DSA keys used that use a 1,536-bit Diffie-Hellman key as the main key and that's simply too low for comfort at this point. So we are raising the security level
17:41
quite significantly to 224 bits. We also needed to update some of the other cryptographic primitives like OTR version 3 has SHA-1 in some places using classic Diffie-Hellman, it's using DSA. All of these algorithms are not really a great fit for 2019.
18:00
We also have this a little bit weird situation where we really want elliptic curves because elliptic curves are great. At the same time, elliptic curves can be not so great because there are specific... Okay, so assuming that quantum computers arrive and assuming that they arrive and it takes some time
18:22
in how they progress in terms of speed of breaking cryptographic algorithms, you can get into this weird situation where elliptic curves will be faster to break than Diffie-Hellman, classic Diffie-Hellman. And the reason for this is because elliptic curve keys are significantly smaller than classic Diffie-Hellman.
18:41
So assuming that the progress of creating qubits is slow enough, we actually could be in a situation where elliptic curves could be broken five years before classic Diffie-Hellman. So we have also added what we call this limited quantum computing transcript description, which kind of helps a little bit for a few years,
19:01
hopefully, assuming some of our assumptions are correct. And yeah, we also need a new communication model. When OTR was created, OTR, the first plug-in for OTR was created for a chat client called GAIM. I don't know if anyone remembers it. That was the previous name for Pidgin.
19:22
And in 2004, that was kind of like great. There were many protocols, and you could run OTR on top of any one of these protocols. All of these protocols had a few things in common, meaning, for example, all of them were in order. And in general, you could kind of be okay with everything being online. In our world right now, a lot of people use cell phones
19:42
and a lot of people come online and offline all the time. And we have transports that are not necessarily guaranteeing in order. So we need OTR to support out of order. We need it to support offline conversations. This has some consequences. Offline conversations lower some of the security properties, specifically when it comes to online deniability.
20:02
It's not much, but it's slightly different. And if you want more information, it's all in the specification for that. We also have different modes, which means that for people that really want only the highest secure version of OTR, there is a possibility of implementing that specific restricted mode that actually allows that. And then finally, OTR has always been serverless.
20:25
OTR version four will require servers if you want offline capability. For online capability, you don't need servers, but for offline, of course, you need to trust the server to some degree. Actually, this is an interesting situation because obviously, if you're gonna send an offline message,
20:41
there has to be some kind of server to store that message. We don't really trust these servers. We're using a pre-key model that is quite similar to what Signal is doing. So the server is only trusted to store these things and then give them out when someone is asking for them. So this server is trusted to not be an asshole
21:02
and do denial of service, but except for that, it's not really trusted because it can't actually do anything else. All of these messages are signed and there is no way to actually attack a user using these pre-key messages. Okay, just a little bit about the design, which I will go very fast because we don't have a lot of time.
21:20
So yeah, we use a deniable authenticated key exchange. What does this mean? This basically means that you will have a way in which you authenticated each one of the parties in the conversation, the two parties in the conversation, but in a deniable way. We use for these two primitives that is called the XZ and XZDH, the first one for online, the second one for offline.
21:42
Of course, we use elliptic curve cryptography and we use ET448 Goldilocks, where we decided to use that and have Daniels burn since 25,119. We decided to go with my hamburger's curve because it gave us a higher security level, the one that we needed. We use also a difficulty element of a size of 3,072
22:02
because as Ola already said, we wanted to also have a little bit of extra security in case that elliptic curve cryptography gets broken faster with a quantum computer. We decided to use SHAKE and also XALSA, SHAKE as the hash function, XALSA as encryption algorithm. We use the double ratchet algorithm to derive the unique message keys per each message.
22:26
And of course, we have already talked a little bit about this, why we didn't want to post quantum algorithms. Of course, we also have a thing that is called the toolkit. The toolkit is basically a toolkit that actually proves that all of the deniability properties
22:41
are actually happening. Why we don't want group chat? Because we wanted to attain certain deniability properties and right now, all of the cryptographic literature has not really attained that deniability properties in a group chat setting. So I just want to expand on the toolkit for one second. You will find a lot of people talking about deniability
23:01
and there are specifications out there that talk about these properties in the abstract. That's not really good enough. The idea of the toolkit is to give you a command line tool that will allow you to forge messages. Basically, the idea here is that we don't just say in the specification, hey, it's possible to forge messages. We make it so you have a command line tool
23:21
that will allow you to forge messages as simply as using the tool itself. So we can actually show this is actually true. Anyone can do this and by having this toolkit, we're putting it into the real world that anyone can forge messages and that this deniability we're talking about is not just academic. It's real world and anyone in this room could pick up the toolkit and forge messages
23:41
for anyone else. It's great fun. Okay, real world implementation super fast. Of course, we're doing the implementations that we first did of OTA before. We did it in C. And of course, implementing something in C has its thoughts.
24:01
We also need, during the implementation also, the design of the protocol, we also collaborated along with all of the cryptographers, with Ian Goldberg, with Nick Hunger, with Mike Humber because sometimes we didn't know exactly about some cryptographic algorithms so we needed some kind of advice on that. As I said, we implemented in C.
24:21
Why in C? Well, most of the libraries, oftentimes the protocols get implemented in C so later all the libraries in other programming languages can actually be implemented by having the inspiration in C. Of course, working in C has its problem. Of course, you have the memory handling so we have to be very, very careful with that. We used a lot of compiler flags, a lot of address sanitizers from the LLVM foundation.
24:45
Of course, we did a static testing client ID and we used Splint. We used Balgrind and various sanitizers. But something that we also tried to incorporate is the idea of the code that has to be readable because sometimes on libraries what happens is the code is huge as spaghetti code
25:00
and we try to create actually a code that can be readable and that people can later use it as an inspiration to implement it in whatever, all the programming language. Should we jump to the questions? Yes, and I'm very sorry but we run out of time so questions. In the meantime, links. Whoa, sorry. Here.
25:20
Yes, links for anyone that wants to look at the source code and I think maybe we would have time for maybe one or two questions maybe.
26:02
Do we have benchmarks in terms of like a peer-to-peer messaging protocol for example? Well, okay. So first of all, we do have messages for, sorry, we have benchmarks in the paper for the AKEs because the authenticated key exchange are kind of the most significant part of this.
26:20
They're much more costly and how much time they take. The paper from Nick Unger that actually establishes these has benchmarks comparing lots of the different existing dates in terms of operational costs. In terms of sizes, we know how big the messages are gonna be. That's easy to calculate. I don't have that in my head. And in terms of the actual ratcheting algorithm,
26:44
the ratcheting for each message is quite inexpensive in general. I don't have numbers in my head right now but it's quite easy to find out and that's something that we should definitely do. Of course, we also have the benchmarks of the library of the elliptic curve that we're using by my humble.
27:01
He already has benchmark from what I remember. And one of the reasons why you use elliptic curve cryptography is actually because this is faster than using a large prime Diffie-Hellman. So by giving the same security level that we wanted to attain. So it's a little bit faster for us in that way. And we're out of time. Thank you. Thank you.