CRYPTO AND PRIVACY VILLAGE - Implementing a Library for Pairing-based Transform Cryptography
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 |
| |
| Serientitel | ||
| Anzahl der Teile | 322 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: 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/39876 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | |
| Genre |
DEF CON 26104 / 322
18
27
28
40
130
134
164
173
177
178
184
190
192
202
203
218
219
224
231
233
234
235
237
249
252
255
268
274
287
289
290
295
297
298
299
302
306
309
312
315
316
00:00
SpeicherabzugKryptologieSinguläres IntegralProgrammbibliothekMathematikKryptologieProgrammbibliothekComputeranimation
00:37
SpeicherabzugPunktwolkeKryptologieProgrammbibliothekSpeicherabzugTransformation <Mathematik>PunktwolkeFacebookAutomatische DifferentiationHypermediaWeb SiteE-MailBenutzerbeteiligungRechenzentrumBit
02:03
ChiffrierungSpeicherabzugPunktwolkePublic-Key-KryptosystemChiffrierungTablet PC
02:41
SpeicherabzugChiffrierungApp <Programm>QuaderGruppenoperationKartesische KoordinatenElement <Gruppentheorie>ChiffrierungApp <Programm>
03:33
ChiffrierungGruppenkeimSpeicherabzugEinhüllendeChiffrierungPublic-Key-KryptosystemGruppenoperationKryptologieMultiplikationsoperatorMailing-ListeSchlüsselverwaltungOrthogonalitätPhysikalisches SystemEinhüllendeElektronische PublikationGamecontroller
05:22
GruppenkeimSpeicherabzugPhysikalisches SystemGruppenoperationGruppoidStochastische AbhängigkeitZugriffskontrolleOrthogonalitätElement <Gruppentheorie>SystemverwaltungDatenfeldGruppenoperationNichtlinearer OperatorPhysikalisches SystemZahlenbereichSystemverwaltungBeobachtungsstudieKonstanteElektronische PublikationMathematikElement <Gruppentheorie>MultiplikationsoperatorKryptologieProgrammfehlerOrthogonalitätSchlüsselverwaltungGamecontrollerProgrammierung
06:27
ChiffrierungKryptologieAlgorithmusMessage-PassingSpeicherabzugProxy ServerGruppenoperationBeobachtungsstudieProxy ServerE-MailPublic-Key-KryptosystemAlgorithmusToken-RingKryptologieDatenfeldServerOrthogonalitätMessage-PassingTransformation <Mathematik>MathematikKategorie <Mathematik>GamecontrollerChiffrierung
08:17
Singuläres IntegralAlgorithmusChiffrierungTransformation <Mathematik>SpeicherabzugProxy ServerChiffrierungTransformation <Mathematik>Elliptische KurveGenerator <Informatik>SchlüsselverwaltungNichtlinearer OperatorAlgorithmusElektronische PublikationWärmeübergangPrimitive <Informatik>Computeranimation
08:55
SpeicherabzugPublic-Key-KryptosystemChiffrierungWeg <Topologie>SchlüsselverwaltungProxy ServerMessage-PassingMathematikModallogikComputeranimation
09:57
SpeicherabzugGruppenkeimChiffrierungZugriffskontrolleOrthogonalitätPublic-Key-KryptosystemSchlüsselverwaltungTransformation <Mathematik>Elektronische PublikationAlgorithmusGruppenoperationNichtlinearer OperatorOrdnung <Mathematik>SystemverwaltungRegelkreisOrthogonalitätPunktGamecontrollerComputeranimation
11:15
SpeicherabzugGruppenkeimWechselsprungPublic-Key-KryptosystemGruppenoperationSystemverwaltungNeuroinformatikElektronische PublikationZahlenbereich
11:59
SpeicherabzugGruppenkeimPublic-Key-KryptosystemGruppenoperationElektronische PublikationProxy ServerMereologieAlgorithmusOrthogonalitätRegelkreisChiffrierungComputeranimation
12:45
Atomarität <Informatik>SchlüsselverwaltungComputersicherheitGruppenoperationBrowserPublic-Key-KryptosystemAlgorithmusMAPProxy ServerMultiplikationsoperatorOrdnung <Mathematik>Notebook-ComputerKategorie <Mathematik>SchlüsselverwaltungRechter WinkelChiffrierung
14:03
SpeicherabzugProxy ServerChiffrierungPublic-Key-KryptosystemAlgorithmusMultipliziererPhysikalisches System
14:38
SpeicherabzugAdditionPhysikalisches SystemProxy ServerGruppenkeimDemo <Programm>DezimalzahlGruppenoperationHierarchische StrukturPhysikalisches SystemSchlüsselverwaltungChiffrierungTransformation <Mathematik>Proxy ServerKette <Mathematik>Computeranimation
15:37
GruppenoperationKonstanteGruppoidSchlüsselverwaltungSkalierbarkeitChiffrierungSpeicherabzugChiffrierungKonstanteDynamisches SystemGruppenoperationMultiplikationsoperatorWärmeübergangSchlüsselverwaltungDienst <Informatik>Service providerRechter WinkelDatenmissbrauchProxy ServerFramework <Informatik>BitInformation
17:17
ProgrammbibliothekQuellcodeSpeicherabzugSoftware Development KitFunktion <Mathematik>Proxy ServerTransformation <Mathematik>DokumentenserverSoftwareentwicklerPhysikalisches SystemKryptologieAlgorithmusEllipseStandardabweichungPrimitive <Informatik>Open SourceProgrammbibliothekSchlüsselverwaltungMereologieDokumentenserverSoftware Development KitDienst <Informatik>Proxy ServerKryptologieMathematikEllipseNichtlinearer OperatorElliptische KurveBitComputeranimation
18:14
Textur-MappingBilineare AbbildungParametersystemGruppenkeimVorzeichen <Mathematik>SpeicherabzugNichtlinearer OperatorElement <Gruppentheorie>GruppenoperationFunktionalBilineare AbbildungSchnittmengePunktOrdnung <Mathematik>Elliptische KurveDatenfeldKryptologieMultiplikationSkalarfeldNebenbedingungKategorie <Mathematik>Zwei
19:07
GruppenkeimEinsWurzel <Mathematik>GruppenoperationPunktSpeicherabzugSchnittmengeOrdnung <Mathematik>MathematikElement <Gruppentheorie>PunktMaßerweiterungElliptische KurveGruppenoperationMinimalgradZweiZahlenbereichDatenfeldBitEinheitswurzelAggregatzustandKurvenanpassung
20:06
InstantiierungSkalarfeldPunktSpeicherabzugKryptologieSchlüsselverwaltungMessage-PassingChiffrierungPunktMultiplikationElliptische KurveMultiplikationsoperatorProxy ServerChiffrierungRechter WinkelKryptologieGruppenoperationPublic-Key-KryptosystemSchlüsselverwaltungNegative ZahlMultipliziererMessage-PassingServerZweiElement <Gruppentheorie>
21:19
SpeicherabzugChiffrierungPublic-Key-KryptosystemMultiplikationsoperatorMessage-PassingTermersetzungssystemBitProgrammbibliothekMinimumPunktLinearisierung
22:04
SchlüsselverwaltungDiskrete UntergruppeKryptologieComputersicherheitKurvenanpassungEllipseGruppenkeimUnendlichkeitPunktSpeicherabzugStandardabweichungDatenfeldPublic-Key-KryptosystemKryptologieElliptische KurveComputersicherheitSchlüsselverwaltungMereologiePunktNP-hartes ProblemGruppenoperationComputeranimation
22:53
SpeicherabzugZahlenbereichDatenfeldMaßerweiterungComputersicherheitÄquivalenzklasseDiskrete UntergruppeAnalysisSiebmethodeBitComputersicherheitCASE <Informatik>Formation <Mathematik>SchätzfunktionPrimzahlNeuroinformatikMaßerweiterungKryptologieAlgebraischer ZahlkörperMinimalgradOrdnung <Mathematik>DatenfeldElliptische KurveZwölfZahlenbereichRechter WinkelProgrammbibliothek
25:02
SpeicherabzugGruppenoperationProgrammbibliothekDifferenteCodeServerRechenschieberDatenverwaltungTransformation <Mathematik>AdressierungSchlüsselverwaltungPublic-Key-KryptosystemSelbst organisierendes SystemPhysikalisches SystemFolge <Mathematik>InformationsspeicherungComputeranimation
26:02
SpeicherabzugSchlüsselverwaltungProzess <Informatik>Selbst organisierendes SystemDatenverwaltungUntergruppeSchreib-Lese-KopfGruppenoperationMultiplikationsoperatorComputeranimation
26:50
SpeicherabzugWhiteboardMultiplikationsoperatorWhiteboard
27:29
SpeicherabzugFunktionalRandomisierungTypentheorieKryptologieMathematikProgrammbibliothekTransformation <Mathematik>Rechter WinkelPublic-Key-KryptosystemVektorraumKlasse <Mathematik>SchlüsselverwaltungElement <Gruppentheorie>GruppenoperationChiffrierungServerVorzeichen <Mathematik>SystemplattformGenerator <Informatik>WärmeübergangMultiplikationsoperatorFehlermeldungBrowserSchnittmengeProgrammverifikationZufallsgeneratorEinsCodePunktEin-AusgabeStichprobenumfangProxy Server
31:05
SpeicherabzugSchlüsselverwaltungPublic-Key-KryptosystemSchlüsselverwaltungStichprobenumfangUntergruppeNummernsystemSelbst organisierendes SystemGruppenoperationGenerator <Informatik>TypentheoriePhysikalisches System
32:01
GruppenkeimChiffrierungSpeicherabzugGruppenoperationSchlüsselverwaltungProgrammbibliothekPublic-Key-KryptosystemVorzeichen <Mathematik>AlgorithmusCodeInformationsspeicherungMessage-PassingDatenbankTLSGrenzschichtablösung
33:32
SpeicherabzugAvatar <Informatik>Public-Key-KryptosystemDokumentenserverInformationGruppenoperationSchlüsselverwaltungWärmeübergang
34:07
SpeicherabzugPublic-Key-KryptosystemGruppenoperationNichtlinearer OperatorTransformation <Mathematik>TypentheorieFunktionalShape <Informatik>ChiffrierungProxy ServerMultiplikation
35:49
SpeicherabzugKryptologieVererbungshierarchieVorlesung/KonferenzComputeranimation
36:24
SpeicherabzugRepository <Informatik>SpeicherabzugSoftwaretestKategorie <Mathematik>ChiffrierungMAPErweiterte Realität <Informatik>UntergruppeSchlüsselverwaltungCASE <Informatik>Offene MengeVorlesung/Konferenz
37:02
SpeicherabzugGruppenkeimSchlüsselverwaltungGüte der AnpassungUntergruppeSchlüsselverwaltungInverser LimesKreisbewegungGruppenoperationSpieltheorieProxy ServerMultiplikationsoperatorDatenbankKryptologieTransformation <Mathematik>MathematikRechter WinkelFreewareChiffrierungVorlesung/Konferenz
38:33
SystemplattformWellenlehreGruppenoperationSinguläres IntegralElement <Gruppentheorie>SchlüsselverwaltungGruppenkeimIdentitätsverwaltungBenchmarkSystemplattformTransformation <Mathematik>TermCodeMereologieSchlüsselverwaltungIdentitätsverwaltungPublic-Key-KryptosystemOpen SourceWärmeübergangGruppenoperationRepository <Informatik>
39:29
SpeicherabzugGruppenoperationPublic-Key-KryptosystemAutomatische HandlungsplanungEinhüllendeChiffrierungQuick-SortSchlüsselverwaltungProxy ServerElement <Gruppentheorie>Transformation <Mathematik>Secret-SharingMultiplikationAutorisierungErweiterte Realität <Informatik>Physikalisches SystemArithmetisches MittelSchreib-Lese-KopfKontrollstrukturInformationsspeicherungSelbst organisierendes SystemSystemverwaltungComputersicherheitProgrammbibliothekNichtlinearer OperatorHardwareMultiplikationsoperatorPrivate-key-KryptosystemFrequenzAbgeschlossene MengeSymmetrische MatrixÄquivalenzklasseUntergruppeComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:00
Please welcome our next speaker, Bob Wall and Colt Pedrickson on implementing a library for pairing-based transformed cryptography. Thanks everyone. Thanks for sticking around to the bitter end, almost the bitter end.
00:25
I imagine some of you might have been out partying last night. I'll try not to assault anyone's hangover, but special warning, there is some math in here, so consider yourself warned. So, Colt and I both worked together at a company called Ironcore Labs.
00:42
So, we'll talk about this transformed cryptography library that we've implemented and some of the background about it. So, obviously, we've known the answer to this question for quite a while before Facebook got face-palmed. But you can maybe tell by my gray hair that I've actually got to watch the World Wide Web get started.
01:01
And it took off and then the cloud stuff started and it seemed like, hey, this might be really pretty cool. You know, especially people that were doing IT and setting up data centers, like, wow, this might be great. And then we started getting some breach notifications. We heard about Yahoo. We heard about Anthem. We heard about the Office of Personnel Management or the OMB.
01:23
We heard about Facebook. I imagine at least a few of you out there have gotten a breach notification from some company. So, started to get a little bit iffier about the cloud. And even if you disregard the breaches and think about the weird things that happen when somebody sends you an email or you send somebody an email,
01:42
and then you go to some social media site or Google and look at the ads that get presented to you. It's like, it's a little creepy. I find it a little creepy anyway. So, maybe the cloud has some downsides after all. So, what can we do about that? What are some things that we can do to start fighting back against that?
02:04
And one of the obvious answers is end-to-end encryption. So, if I've got a device, a browser, a phone, a tablet, and I want to generate some data and I want to make it available to someone else, well, if I can use public key cryptography, I get their public key encrypted on the device, send it off,
02:23
and it stays encrypted until it gets to their device and they can decrypt it. So, hopefully, their private key that unlocks it stays on their device. And in between, it doesn't matter. We don't have to trust anyone. We don't have to believe that somebody's going to be upstanding in the middle.
02:41
So, including cloud vendors, if we send that stuff through, we store it on Dropbox or Box, it doesn't matter if they want to look at it or not. They're not going to be able to. So, we've seen kind of a take-off of end-to-end encryption apps, and there are a few of them that are more popular, maybe.
03:01
And you'll notice that most of these end-to-end encrypted applications now have something in common, and that is that they're primarily designed for messaging and they're mostly designed for person-to-person channels. So, they're not really designed for something where you might want to send something to a group of people,
03:22
and they're especially not designed for something where that group of people might be big and or very dynamic, the membership of the group changing a lot. And there's a reason for that because it's just not that easy. If you think about, say you're a masochist and you want to encrypt some data to a group of people
03:41
and you want to use GPG to do it, you get all of those people's public keys, you stuff those all into the GPG command line and say, hey, encrypt this document. It does it. And every one of those people can use their private key to decrypt it. Okay, that's pretty good. And just kind of a side note here, and this will be kind of important as we talk through this,
04:02
what we're talking about what GPG does and what everything that does public key crypto pretty much does is envelope encryption. So, they don't actually use public key crypto to encrypt that whole document because it's slow and painful. They generate a random key, probably an AES key, they encrypt a document with that,
04:22
and then they take that random key and they encrypt it with each of those public keys and stuff that on the start of the document or at the end of the document or somewhere in that file. So, I've got this file now. I've encrypted it to say three or four people. Everything's good. But now suppose I want to add another person.
04:42
Well, that means that one of the people that can unlock the document needs to decrypt it and get those list of public keys that were already used to get the list of the extra public key that they want to add and re-encrypt the document and save it back out there. So, that's not tremendously convenient and it's really not convenient if the group is changing fast.
05:03
You wouldn't want to have to do that 20 times a day for sure. Removing the access is pretty much the same thing. You have to go get the document, you have to decrypt it, re-encrypt it with a list of keys that excludes the people you want to remove access from. So, obviously that is not scalable.
05:22
So, we want to build a system that has what we call orthogonal access control. And that just means that we would like users to decide which groups of people should be able to access their data without knowing who belongs to the group. And then independently from that, the administrators of those groups should be able to add or remove members without me knowing about it.
05:45
And so, this is obviously not a new idea. I mean, Unix groups are essentially this. But we want something that relies on cryptographic access control instead of policy. So, it's harder to break it, harder to mess it up. If somebody makes a programming error, it will matter a lot less because unless you have the keys, you can't unlock it.
06:07
And we want a system where each change in group membership or an access grant or revocation is basically a very fast, a constant time operation that's independent of the number of users that we're managing or the number of documents, the number of files, or the number of groups that we have.
06:25
So, what's a way to do that? There's a field of study in cryptography called proxy re-encryption. It's been around for around 20 years. It hasn't really gotten too widespread of an adoption, but it provides a lot of these properties that we need to do this orthogonal access control.
06:46
So, most of the proxy re-encryption algorithms are based on public key cryptography, and almost all of them are actually based on pairings, which we'll talk about in a little more detail. And that's where the math might start to sneak in. Proxy re-encryption was originally designed to allow someone who receives encrypted messages
07:06
to delegate the ability to decrypt those messages to someone else, without having to give them her private key. So, you can imagine, say we've got a mail server that's running with proxy re-encryption, and we've got a group of people that are using it.
07:21
So, Alice has a public-private key pair she's set up on the mail server, and she's getting encrypted mails and she decrypts them, and then she's going to go on vacation. She wants Bob to take over for her while she's gone, but she would really rather not give Bob her public key, because he's kind of a doofus and he will probably lose it. So, with proxy re-encryption, she says,
07:45
okay, I'm going to delegate to Bob, she calculates this re-encryption token and sends it to the proxy server, the email server, and then when the email server sees emails coming in encrypted to Alice, it can apply that transform key and do a transformation that makes that data encrypted to Bob without decrypting it.
08:04
The mail server never saw the plain text. It only had this token that allowed it to transform from encrypted to Alice to encrypted to Bob. So, that's what proxy re-encryption was designed to do. Proxy re-encryption algorithms usually have five primitives.
08:20
Key generation, and again, almost everyone I've seen is just straight-up elliptic curve key generation. Transform key generation, which is a little more involved, encryption and transformation re-encryption. We've taken to calling this transform encryption and calling this step transformation instead of re-encryption, because typically, when I think of re-encryption,
08:42
I think of what I talked about with GPG. It's like, oh, I have to go take the file, decrypt it, get a new key and encrypt it with a new key. And this is not that. So, we call it transformation instead. And then the decryption operation. So, transform key generation with proxy re-encryption takes the private key of the person that wants to delegate the access,
09:02
the public key of the person that they want to delegate the access to, and runs some math, and it comes out with this transform key. So, this transform key, again, doesn't allow anyone to decrypt any data. It can only be used to take data that's encrypted to the delegator and re-encrypt it or transform it so it's encrypted to the delegatee.
09:23
And then, you know, once you get that done, you can send it to a proxy that's gonna keep track of it and it's going to apply it as necessary. And the fortunate thing is, because it can't decrypt anything, you don't really have to trust the proxy when you send that key to it. You can't use it to do anything except what you basically told it it could do,
09:41
which is transform messages that are encrypted to you so they're encrypted to someone else. And the nice thing is that you are the only one who can do that because it takes your private key to do that. So, as long as you're not Bob who, like, leaves his private key on the desk, you should be good. So, if you want to delegate access,
10:00
it's as simple as taking a file that's encrypted to the delegator, applying the key and running the transformation algorithm, and sending the transformed file or data to the new recipient. They take their private key and they decrypt it pretty much the same way they would have decrypted something that was encrypted directly to them.
10:23
So, how can we use this to build this orthogonal access control system? We just use groups. We create a group and we encrypt documents to the group and then independently of that operation, the person who is kind of an administrator or owner of the group can create transform keys from the group
10:40
to each of the users that's going to be a member. Once they add a member to the group, immediately that member can decrypt anything that's been encrypted to the group in the past, anything that will be encrypted to the group in the future, and at some point are removed from the group that also immediately revokes access.
11:02
The nice thing is that both of those operations don't require you to go and find all of the documents that were encrypted to the group and mess with them. You don't ever have to touch any of the documents. You just do these transform keys. So, creating a group is simple. You create a public-private key pair for the group.
11:21
What we do usually is take the group's private key and we encrypt it to the user that created it and that makes that person essentially an administrator for the group. So, an administrator is just someone who can access the private key of the group, which means they can add new people to the group when they want to.
11:41
Again, adding a member to the group is as simple as computing that transform key and that's why the administrator needs access to the private key. Granting access. If you've got a file and you want to let a group access that file, you just encrypt it to that group's public key. Very simple. If a group member wants access, they request the file that's been encrypted to the group.
12:06
They give that to this proxy server that's got the transform key. It applies the transform to make the file so that it's encrypted to them. It sends that transform file back and then I've got a private key on my device that unlocks the data and recovers the plain text.
12:23
Removing a member from a group is as simple as just forgetting the transform key. You just throw it away. As soon as it's gone, that user can no longer decrypt anything that's encrypted to the group. Now we've got all of the pieces and parts that we need to put together an orthogonal access control system
12:42
using a proxy re-encryption algorithm. We noticed that really users don't use one device. I don't always use the same browser on my laptop to access things. I don't always use my cell phone to access things. We can make this better.
13:03
If we wanted to do that, we would basically have to do the thing that you do a lot of times now. It's like, okay, I've got my private key and I want to use three or four different devices. I have to figure out a way to get my private key onto all of those devices. You can do that, but that's not the greatest experience. If we basically add another level here of delegation,
13:22
we can treat a user as a group of devices and just do another transform from a user to a device. That means every device gets their own private key. You don't have to share them. You don't have to copy them around. If somebody drops their phone in the toilet, they can just basically revoke access to that phone and they don't have to worry about if somebody had somehow hacked their phone
13:42
and gotten the private key for the phone. As soon as that transform key is gone, that phone can't access their data. Maybe you left it on the conveyor in the airport. The private keys for the devices are always on the device. It gives you this nice revocation property. In order to do this, the proxy re-encryption algorithm
14:02
needs to have a special property that's typically referred to as multi-use or multi-hop. We already talked about if you had a data that's encrypted to a user and there's a transform key to another user, you can transform the document and then the other user can unlock it. With multi-hop proxy re-encryption, you can take that transformed document
14:22
and you can apply a second transform to it, maybe to another user, Carol, and produce this doubly transformed document. Send that to Carol and she takes her private key and the decrypt algorithm and gets the plain text back. This multi-hop proxy re-encryption allows you to build this hierarchical system.
14:41
In fact, you could build a hierarchy deeper if you wanted. You could have groups of groups. Adding a device to a user is the same as adding a user to a group. You just create a transform key. If I'm logged into one of my devices and I want to access a document, the proxy, I say, hey, I've got this document and I want to unlock it.
15:03
The proxy figures out the best way to get the transformation from something that document's encrypted to to the device that I'm using to request it. That might be because the document was actually shared with me, my user directly, and then there's one transform between me and my device and that will work.
15:22
Maybe it was shared with a group that I belong to, so if there's a path from a group to me to my device, the proxy can take those two transforms and apply them in a chain, transform it twice and return it to me so I can decrypt it. So, we now have scalable end-to-end encryption.
15:42
It can handle arbitrarily large groups of users and it can handle dynamic groups of users. We can grant and revoke access to documents and to groups in constant time. It doesn't matter how many documents, doesn't matter how many groups, doesn't matter how many users, and we got rid of the need to copy private keys around
16:00
if we're trying to manage multiple devices. So, just one place that this could be useful is, say you want to be able to protect someone's PII, Personally Identifiable Information, and I imagine there are more than a few of you out here who have been thinking about this a little bit in the last six months or so in the GDPR framework, right?
16:23
So, if you could take a user's private data and just encrypt it to that user, and then say that user is going to decide, hey, I'm going to provide consent for this company to use my private data. It's as simple as creating a transform, if the company's got a public key, maybe the company is considered to be one of these groups,
16:41
I create a transform key between me and that group that will allow that group to read my data, and then maybe a couple months down the road, or a year down the road, I decide I don't want that company to continue to have access to my data, I want to invoke my right to be forgotten, so I just tell the proxy service
17:02
that's holding these transform keys, hey, throw that one away, and that means that that company or people that belong to that company no longer can access that if they haven't already accessed it. So that's an example of what we can do with this. So we have implemented the primitives in the Scala library,
17:22
we use ScalaJS to generate a client-side JavaScript library, it's open source, we actually built a JavaScript SDK around it, that talks to a service that is the public key repository and the transform proxy. We've got it out there, that part isn't open source, but we let people do free signups
17:42
and play around with it. The library is open source, but it doesn't have some of the things around it to make it easy to manage the keys and stuff. So now I wanted to talk a little bit about, like under the hood, some of the math stuff that makes this work, I said is pairing-based cryptography, and pairings are built on top of elliptic curves,
18:02
so elliptic curves, crypto is pretty standard, but pairings are less standard, although I did, I think I heard two or three different talks in here this weekend so the basic operation that pairing-based crypto is based on is called the bilinear pairing, or sometimes called the bilinear mapping,
18:22
and that mapping, that pairing is simply a function that takes an element from some group and an element from some other group and combines them together and produces an element in yet another group. So, you know, the first group, spoiler alert, might be the set of points on an elliptic curve
18:42
or a time field. So, in order for this thing to be a bilinear pairing, it needs to satisfy some constraints, it needs to provide some properties, I won't read these to you, but that last one in particular is important because it allows you to basically swap
19:02
scalar multiples of points, and we'll see why that's useful in a second. So, how we use pairings, that first group that we talk about is exactly the set of points on an elliptic curve over a prime field. The second group is related to that, it's the same elliptic curve changed a little bit,
19:22
it's called the twisted curve, and it's defined over a set of points in the second degree extension of that field, and so the math for that gets a little deeper, and I won't go into that, but when you do the pairing, you produce values that are in another group, this G sub T group, and that group is not a set of points,
19:40
it's actually a set of values in the sense of unity, and those values are all contained in the degree 12 extension of that prime field, so these things are basically numbers that consist of 12 different values that are between zero and prime minus one, so it's a big number that the pairing produces.
20:01
All of these groups have the same number of elements in the group, they all have the same order. So, the reason pairings work for crypto, and there might be other ways to use them, but the way that we use them, and the way most of the proxy encryption stuff does, is it allows you, like I said, it allows you to swap scalar multiples,
20:20
so if you think of a public key, it's just some generator point in your group, your elliptic curve group, times some randomly chosen private key, or secret key, right? So, that's just a scalar multiple of some point that you know. So, if Alice and Bob have key pairs
20:40
that are computed that way, they both picked a random secret key, they compute a public key, they send that out there to a key server, Alice can encrypt a message to Bob by using a pairing, where she takes Bob's public key and pairs it with her secret key times this generator point that's predefined in that second group of elements for the pairing.
21:02
And then she takes that pairing value and multiplies it by the message, and it gets an encrypted message. So, Bob can recover that by basically taking Alice's public key, pairing it with the negation of his secret key times that second point, G2. I won't go into this,
21:21
but basically, you can prove that this works by just doing simple arithmetic rewrites. It's like, well, okay, if I rewrite the public key as the secret key times the generator point, and then I remember that because of bilinearity, I can swap these two things, and then if I get down to the bottom,
21:40
this is the zero. It basically returns one. That shows you that I do, in fact, get out my original message when I decrypt it. So, this is how pairings are used to make encryption work. So, I'm gonna make one more side note, and then I'll turn it over to Colt to talk about the library and some cooler,
22:01
a little bit less theoretical ways to use it. But a note on the security of this stuff. The security of pairing-based cryptography relies on two different hard problems. The first is the standard elliptic curve Diffie-Hellman problem that protects all elliptic curve crypto, and that problem is what keeps you
22:21
from being able to recover a secret key even though you know the public key and you know the generator point. So, that's a hard problem that protects the elliptic curve part of this. The other hard problem is the straight and discrete log problem, and that's what protects the pairing part of that because remember, the pairing produces a value
22:41
that's not an elliptic curve group. It's just in a field, a big field. So, it's the just straight discrete log problem that protects that part of the work. Recent advances in the use of number field sieves have improved the ability to solve
23:00
the discrete log problem. It's still hard, but it's not as hard as we thought it was a while ago. So, in the past, the kind of conventional wisdom was that if you used a 256-bit private key, the elliptic curve discrete log problem would provide you with roughly 128 bits of security,
23:23
and if you're doing the discrete log problem in the 12th degree extension of that field, that would also provide you roughly 128 bits of security against the straight discrete log problem. They've been working on this number field sieve, and that improves the ability to solve the discrete log problem,
23:42
and some researchers have been grinding away on this and concluded that in the start of this year and the end of last year, that if you have a degree 12 extension of a 256-bit prime, that really only provides you with right around 100 bits of security instead of 128.
24:01
So, if you want to go and tell everybody, hey, my crypto is 128 bits secure, some people kind of expect that. You actually need more bits in your prime number in your field, and so getting back up to 128-bit equivalent security, you actually need a prime that's 400.
24:22
These are all estimates, and the computations are really complicated and involved, and you kind of have to do it for each different case, but the estimates are that you would have to have at least 461 bits in your prime in order to get back to 128 bits of security for the discrete log problem. So, we've been playing around with this a little bit,
24:42
and it's probably something that everyone should be aware of in the future, that you're probably going to have to start bumping up the size of the prime pretty soon because of these advances. So, now I want to turn it over to Colt, and he'll kind of talk about the library. Sure. So, first, all this code,
25:07
I'm just going to show, basically, code snippets from the Recrypt library. As Bob pointed out, Recrypt, I mean, the library itself doesn't do all the storing of transform keys and all that stuff, so everything on this slide is like,
25:20
well, I'm just doing this in sequence in code, but some of it would be done by servers, some of it would be done by devices, so I'll just kind of talk to that as I go. So, obviously, there should be private keys everywhere, and just pretend that they're on different devices for now. So, who here has used GPG to try to keep secrets encrypted,
25:42
to different people? All right. Almost everybody. This is a very common thing we do. IT organizations use complicated, expensive key management systems to have groups and try to make this slightly less painful, but it's really a pain in the ass.
26:03
So, we have Bob. He's in charge, and I'm not just saying that because he's sitting behind me and he just hit me on the head, but Bob's in charge, and he's the IT manager, so his job is to keep all these secrets encrypted to his IT organization. Some keys he wants encrypted to the whole organization,
26:22
some keys he wants subgroups, whatever he wants. So, these are one of his groups that he's working with, and sadly for him, the turnover in IT organization is high, and every day he's re-encrypting things or removing people. He's doing all this work to try to just keep the same secrets
26:45
encrypted to his organization, taking up a severe amount of his time. So, he's using GPG to do that right now, and so every time he adds somebody like Charlie here, he has to go through and do what Bob talked about, where you decrypt it, you re-encrypt it to everybody, and you send it back out there.
27:06
Alice brings Alice on board, same thing. So, hiring is painful. Unfortunately, Alice is also a quitter, so she quit, and now he has a problem again. He has to go through and do it again.
27:21
So, both hiring and people quitting is a major ordeal. So, we can solve that. So, let's talk about, I'm just going to show some of the code from ReCrypt here. This is Scala code. So, if you've never seen Scala before, or you haven't read it,
27:43
types are on the right side of colons, and values are on the left side. So, we've got a class API that takes the random byte vector and a thing that does signing. So, it's a little weird. We had to do this because we wanted to cross-compile the JavaScript. Has anybody tried to do cryptography in JavaScript?
28:04
It's not great. So, yeah, the problem with cryptography in JavaScript is how do you get random numbers, cryptographically secure random numbers? Well, that depends on the platform you're on. Are you in the browser? Are you on node? So, we wanted to allow this to be more flexible. So, this thing they pass in, this IO,
28:23
you can just think of it as a function that every time you invoke it, it basically could return you a different value. So, basically, anywhere you see IO, you can just replace it with a function in your brain. We won't get into IOs today and the kind of talk we're in.
28:41
So, every time you call that, you're going to get a different set of random, cryptographically secure random values and the signing is just a pair of functions, sign and verify. And we did that with the ED25519 because it's fast, it's known to be secure and we didn't want to use the same set of keys for both encryption and signing
29:01
because that's generally considered not the best practice. So, we take these things because of platform nonsense. So, generate key pair. It's a pretty simple thing. We basically just take the random bytes and we map them over, multiply it times generator point
29:20
to create a public key. So, that's pretty simple and that parentheses syntax is just a two tuple. So, generate plain text. So, when you are doing pairings like Bob was talking about, you have to have these elements that are in different groups
29:41
and that have to be our fruits of unity and all kinds of other math jargon. Otherwise, it doesn't work. So, we, instead of having to push that jargon onto the user of the library, we just said we'll just write a function that generates you a plain text. It returns us this type that is, it says it's a plain text. So, it is and just trust me,
30:02
that way you don't have to worry about how to generate it. So, it's using that random byte vector under the hood as well. Basically, this is the thing that delegates. So, this is the function that delegates from one private key to a public key.
30:25
Transform, that's the thing that actually takes a transform key and does that transformation for you. So, this is the thing that like a server would do or somebody, whoever is the proxy in all of Bob's terminology, the person that has access to these transform keys
30:42
and the public keys and all that stuff, that would be where this runs. Encrypt, pretty straightforward, encrypting a plain text to a public key. And decrypt. So, it either returns an error message or the plain text.
31:03
All right, so, let's go through like a little sample here. So, we're basically going to go through the sample that we were talking about earlier. We were talking about Charlie and Bob and Alice and this IT type organization. So, this is basically just generating
31:20
two different key pairs over here. So, Bob's key pair and the IT group's key pair. The reason I voted out at all because key pair generation is boring is because it's really important in the scheme to remember that groups and users are really the same. So, users can be treated as groups.
31:41
Groups can be treated as subgroups. So, public private keys and especially with our system, you can use these things for many purposes and you can delegate to people, you can delegate to groups. There's all kinds of fancy stuff you can do. So, don't get stuck in your brain about like, oh, well, this is a user key because you can treat it as a group.
32:03
Okay, so, encrypting a value to the IT group. I mean, our goal with this library is to make the public API as simple as possible. Anybody who's used OpenSSL or any other cryptographic library is god-awful to try
32:20
to figure out what's going on. You're passing in mutable values that they're going to fill out and pass back. It's just bad. We want it to read exactly like the pseudocode algorithm should read. So, here we just generate a plain text. We encrypt that plain text and yield the encrypted value. So, it reads like pseudocode and we're encrypting to the group public key.
32:42
And so, a little note about signing keys. I kind of pointed out earlier, but because we did the signing keys separate from keys, we use ED25519. That means we pass in these signing keys to detect if somebody's screwed with the encrypted values.
33:02
So, it makes the API a little messier, but I think it's still pretty straightforward. So, another thing to note here is that this encrypted value never has to change ever. You can put it on the blockchain. You can put it in a database. Kafka, immutable key value stores, whatever you want to do, you can do that
33:22
and you never, ever, ever have to change the encrypted value. So, no matter who you want to share it with or add to the group later with, you never have to change that. Okay, so, we hire Charlie. So, we generate Charlie's key pair so that would happen on her device.
33:40
So, that piece would happen on her device. And then Bob takes her public key and he just generates a transform key from the IT group private key to Charlie's public key and that's it. So, he generates that transform key and he sends it off to the public key repository that's holding on to all this information.
34:00
So, now we have, basically this is how Charlie gets added to the group. She's now in the group. So, hiring again, just to show that it's the same no matter what. Alice, the same thing. She generates key pairs. You generate a transform key and you send it off. So, this is what you would call out.
34:23
It also doesn't matter how many documents are shared with the group. This operation is constant time. Just the one thing. It doesn't matter how many millions of AWS secrets you have encrypted. But, what if Alice quits?
34:41
Sorry, what if Alice wants to decrypt this? Sorry, so, Alice comes in and basically needs the transform value. So, this transform function that's happening at the top I think that would happen on the proxy server. So, we'll just pretend that that has happened there and then the transformed data would be sent back
35:01
to Alice and her request. So, the important thing here is that the transformed data and the original encrypted data have the same shape. That's what Bob was talking about when he was talking about multi-hop. So, if you wanted to transform that data again,
35:23
that transformed data and transform it again to give it access to a device or give access to a subgroup or whatever. So, it's important when you look at the, like I put all the types on the left side there, that encrypted value is the same thing we got out of the encrypt function.
35:41
So, it could be encrypted or it could be already one step transformed and you could do it over and over again. So, if Alice quits, we don't need to do anything special. All we need to do is forget her transform key and we just walk away. Now, that's what a lot of people
36:01
are starting to call this, like, crypto shredding or cryptographically erasing things. All these terminology that just means, well, they can't decrypt it anymore. So, I don't know why this is a new thing that we're doing as an industry, but I guess we are.
36:20
So, as you can see, this API is super approachable. There's nothing crazy here. So, if you're at all interested in this, we have a ton of property-based tests in our core API tests on the GitHub repo and it goes through, like, two and three and four level re-encryption steps
36:40
with different, like, devices and subgroups and all kinds of augmentations of keys and there's some really neat stuff that you can do there. If you have any questions at all, like, feel free to open an issue, like, test case or what about this other thing that I'd like to do. I'm wide open to, like, answering any questions on that,
37:01
but I think the property-based tests give a pretty good overview of that. So, what else? Like, Bob mentioned quite a few of these things, but just to bring it back around again, multi-hop proxy re-encryption is super, super, super cool because you can treat users as groups and groups as subgroups
37:21
and there's just really no limit to the things you could do with that kind of stuff. Every hop makes things slower. So, that is one thing that happens when you do all these transformations. Obviously, you have to unroll them, like, math isn't free. So, that's a struggle there,
37:42
but it's really some pretty, there's some pretty cool stuff you could do and he mentioned the GDPR, which is a big deal. So, the right to forget and being able to just say like, oh, well, we, quote-unquote, crypto shredded this data and we can't unlock it anymore,
38:00
so we forgot who you are. Like, being able to do that in a constant time instead of, you know, sending your IT guy off to just, like, search through databases for three days, like, that's a game changer in my opinion. Key rotation could also be encoded with an extra hop. So, if you wanted to say, like, oh, I want to, like, get a new key
38:20
you could make your old key, just delegate to your new key and you could not have to re-encrypt all your old data. There's some caveats there, but we'll just leave it at that. So, it is all out there on GitHub. So, we just open sourced it pretty recently.
38:40
It's only on the JVM and in JavaScript, so it's pretty limiting as far as platforms are concerned, but we have some other stuff coming that's pretty exciting, but we're not ready to talk about it yet. It's also not that fast yet. We have a benchmarks thing in the repo, so feel free to clone it and, like, see the benchmarks,
39:01
but it certainly could use some work there. We are working on it and are open to any suggestions or anything like that. And really, managing the groups, managing the public keys, managing the transform keys and identities, like, that's where the struggle comes in here. I showed the code and the code is super simple.
39:20
But, like, all the identity management is really the harder part of this in terms of getting it right. So, with that, questions?
39:43
I actually have two questions. The first one is about the transform key storage. As far as I can tell, mathematically speaking, possession of the transform key and the destination private key is equivalent to holding the original private key, because once you have them both, you can just transform and decrypt.
40:01
So, you clearly need to store these transform keys in some way that's secure. You know, you don't want somebody who has a transform key issued, breaks into the proxy server, takes the transform key and then you can never revoke them. So, I mean, is there any plan to implement this on secure hardware or secure elements, things like that, so that a proxy can securely store these transform keys?
40:23
So, yeah, if you have the private key of the person that has been transformed to and you have the transform key, you're right. That's equivalent to having access to all the data. The transform key is only stored in the proxy, but you're right, you could break in there.
40:41
We don't have plans to do anything special there, at least not in the very near future. It is basically the compromising of multiple systems, including, you know, their device, and that could actually be revoked.
41:01
We can use some key augmentation tricks to make sure that values that are encrypted to a certain user can't be unlocked by their private key and can only be unlocked by devices, and that's something I didn't get into here. But I think, I guess the short answer to your question is no.
41:20
And, yeah, that's a problem, but not as big a problem as… The other question I had was, so the issuance of transform keys requires the private key. Is it possible to use the same trick to delegate that authority so I could use my private key to generate a transform key that I then transform into another transform key?
41:42
I'm sorry if your head explodes. No, I'd have to think about that a little more. Yeah, let's talk about… I'm just thinking of a group of people that are the admins, you know. So, that might be possible, but I think a lot easier approach than that, and one that we haven't implemented but we're going to,
42:00
is basically doing a key splitting idea. So, if I've got a group of admins that have access to the private key for a group, and it's an important group like the IT group for my organization, I take that private key and I basically split it M ways. I've got M employees and then I require that some subgroup of them that's more than one
42:22
have to work together to put the key back together before they can use it. I think that accomplishes, maybe not exactly the same things, but close to the same things, and it's a significantly easier thing to think about in your head. Thanks. Thank you for the amazing talk.
42:42
Thank you. I have some questions about the performance of this proxy server as it is applying these transform keys because it can't give out the transform keys. So, when doing this transform, that would basically, that's a computationally expensive operation, correct?
43:03
Yeah. Would there potentially be any downsides to taking a play out of GNU PG, this book, the initial encryption with a symmetric key that is very fast
43:22
and then only doing a transform on the encryption of that symmetric key? That's what we're doing. Yeah, I mean, this is envelope encryption, so the only thing we're encrypting is the AES key. Oh, cool. That makes it move. The transform is expensive,
43:41
so the performance of the library is not where we want it to be, but we're focused on making it faster and working on that. And there's another thing that the proxy server can actually cache those transformed values if it wants to because every time it asks for one,
44:01
it's going to get, well, not quite the same answer, but almost the same answer every time. So you could actually cache those if you were worried about performance. You could cache the transformed value for some period of time if somebody was just asking over and over and over again for that same value. That was my next question. Thank you. Any other questions?
44:25
Thank you.