Modern key distribution with ClaimChain
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 167 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/34864 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
34th Chaos Communication Congress128 / 167
1
2
3
4
5
6
7
10
11
12
14
15
25
26
29
30
31
33
34
39
40
42
43
45
46
49
50
53
58
59
61
63
65
68
69
71
73
77
78
79
81
82
83
85
86
87
88
91
92
94
99
100
101
102
108
109
110
113
114
115
116
118
119
122
124
125
126
127
129
130
131
132
133
134
136
138
139
140
141
145
147
148
150
151
152
153
154
157
159
160
161
163
164
165
166
167
00:00
Hacker (term)Key (cryptography)ChainElectronic signatureDuality (mathematics)Physical systemService (economics)Probability density functionServer (computing)Roundness (object)Computer animationLecture/Conference
01:10
Game theoryDescriptive statisticsHacker (term)Goodness of fitPublic-key infrastructureCollaborationismCommunications protocolDistribution (mathematics)WordKey (cryptography)Formal verificationUniverse (mathematics)CausalityCoefficient of determinationMechanism designLecture/ConferenceComputer animation
01:54
Type theoryCategory of beingProof theoryCartesian coordinate systemPublic-key infrastructureINTEGRALComputer animation
02:21
Sign (mathematics)MiniDiscQuicksortPhysical systemMechanism designProof theoryDatabase transactionAuthenticationElectric generatorComputer animation
03:13
Block (periodic table)Stack (abstract data type)Database transactionHash functionPointer (computer programming)TimestampIdentity managementAbstractionNamespaceMechanism designChainBlock (periodic table)Proof theoryStatisticsChainIdentity managementPower (physics)AbstractionComputer animation
03:46
Pointer (computer programming)Block (periodic table)AbstractionDatabase transactionNamespaceMechanism designChainStack (abstract data type)Hash functionIdentity managementMechanism designDatabase transactionNamespaceInformation privacyLatent heatPhysical systemNumberProof theoryLink (knot theory)Validity (statistics)Block (periodic table)Key (cryptography)Group actionPublic-key cryptographyType theoryElectric generatorComputer animation
04:57
ChainNetwork topologyGroup actionKey (cryptography)Internet service providerBitConic sectionEmailNetwork topologyBlock (periodic table)Database transactionComputer animation
05:35
Point (geometry)Position operatorKey (cryptography)Single-precision floating-point formatInternet service providerProof theoryMultiplication signServer (computing)Conic sectionGraph (mathematics)Ising-ModellExtension (kinesiology)Public-key infrastructureData structureDemonLevel (video gaming)Lecture/Conference
06:47
Formal verificationRootFunction (mathematics)Random numberBinary fileBinary codeNetwork topologyFunctional (mathematics)Different (Kate Ryan album)Function (mathematics)Public-key cryptographySocial classOrder (biology)Service (economics)ResultantLecture/ConferenceComputer animation
07:52
Formal verificationFunction (mathematics)Random numberBinary fileInternet service providerConic sectionCategory of beingChainBinary codeNetwork topologyComputer animation
08:18
ChainIdentity managementContent (media)Block (periodic table)ChainSequenceState of matterIdentity managementSign (mathematics)Block (periodic table)Computer animationLecture/Conference
08:59
ChainIdentity managementContent (media)Block (periodic table)Control systemContent (media)SequenceKey (cryptography)Sign (mathematics)Validity (statistics)Different (Kate Ryan album)Point (geometry)Block (periodic table)Distribution (mathematics)ChainComputer animation
10:00
Point (geometry)Block (periodic table)Statement (computer science)Key (cryptography)State of matterMechanism designPropagatorDistribution (mathematics)Physical systemChainLecture/Conference
10:44
Identity managementContent (media)Block (periodic table)Information privacyChainSign (mathematics)TheoryMechanism designGroup actionClique problemState of matterView (database)Key (cryptography)Real numberCryptographyComputer animation
11:10
Hash functionChainBlock (periodic table)Content (media)Information privacyTerm (mathematics)ZugriffskontrolleLatent heatMechanism designCryptographySource codeMultiplication signCategory of beingSoftware testingGraph (mathematics)Web 2.0Validity (statistics)Information privacyChainMechanism designData structureSign (mathematics)BitState of matterPropagatorGame controllerInformationView (database)Time zoneCartesian coordinate systemAdditionDifferent (Kate Ryan album)CausalityPublic-key infrastructureDemoscenePlanningContent (media)Block (periodic table)Key (cryptography)Lecture/ConferenceComputer animation
13:00
Proof theoryInformationChainBand matrixKey (cryptography)High availabilityBlock (periodic table)EmailTerm (mathematics)BlogData storage deviceSystem callAreaMultiplication signSource codePhysical systemLecture/Conference
14:06
ChainLatent heatMechanism designZugriffskontrolleInformation privacyCryptographyTerm (mathematics)Electronic signatureData structureBlock (periodic table)Network topologyPointer (computer programming)Virtual memoryIdentity managementRevision controlPrice indexBlock (periodic table)TimestampProof theoryDifferent (Kate Ryan album)Social classCartesian coordinate systemPublic-key cryptographyNetwork topologyIdentity managementSequenceMetadataElement (mathematics)Machine visionInformationCore dumpSubject indexingInclusion mapBlogLevel (video gaming)Operator (mathematics)Key (cryptography)Communications protocolFunctional (mathematics)Data structureMultiplication signTwitterMereologyComputer animation
15:20
InformationComputer wormField (computer science)Form (programming)Block (periodic table)Pointer (computer programming)Data storage deviceNetwork topologyElectronic signatureMathematical analysisEmailLecture/Conference
16:02
AdditionPrice indexCalculationSubject indexingKey (cryptography)Functional (mathematics)Content (media)Symmetric-key algorithmRandomizationProof theoryNumberString (computer science)Data storage deviceMathematical analysisNetwork topologyAdditionSemantics (computer science)System callPublic-key cryptographyCondition numberConsistencyComputer animation
17:27
Network topologyCorrespondence (mathematics)Casting (performing arts)Mathematical analysisNormal (geometry)Social classDigital electronicsCircleKey (cryptography)Reading (process)Lecture/ConferenceComputer animationDiagram
18:15
Block (periodic table)Subject indexingPattern languageOrder (biology)Key (cryptography)Symmetric-key algorithmNetwork topologyPoint cloudComputer animation
18:46
EncryptionProcess (computing)Mathematical analysisDigital electronicsNetwork topologySymmetric-key algorithmKey (cryptography)Computer animation
19:23
Block (periodic table)NumberCorrespondence (mathematics)NeuroinformatikSymmetric-key algorithmKey (cryptography)Electronic program guide
19:56
EncryptionBlock (periodic table)Open innovationCollaborationismSimulationField (computer science)Information privacyInformation securityGame theoryImplementationNumberProof theoryPublic-key cryptographyNetwork topologyKey (cryptography)Block (periodic table)Inclusion mapInformation retrievalSlide ruleInformationOrder (biology)Computer configurationExtreme programmingLocal ringPoint (geometry)Computer animation
21:39
Block (periodic table)EncryptionOpen innovationCollaborationismSimulationField (computer science)Information privacyInformation securityGame theoryImplementationSelf-organizationCollaborationismFamilyProfil (magazine)Closed setCartesian closed categoryField (computer science)Projective planeComputer animation
22:48
Cartesian coordinate systemComputer simulationConnectivity (graph theory)Functional (mathematics)Internet service providerLeakReal numberSystem callCategory of beingGodShared memoryPhysical systemInformation securityTorusInformation privacySuite (music)Network topologyGame theoryRepository (publishing)CodeBlock (periodic table)Directory serviceCryptographyImplementationEmailLecture/ConferenceMeeting/Interview
24:12
Open innovationSimulationCollaborationismField (computer science)ImplementationInformation privacyInformation securityGame theoryCommunications protocolEncryptionTelecommunicationKey (cryptography)Goodness of fitData managementPlanningState of matterUsabilityPattern languageNeuroinformatikCartesian coordinate systemEmailComputer simulation
25:32
Data structureSource codeCategory of beingInformation privacySystem callInformation securityDatabaseProjective planeCartesian coordinate systemOpen innovationCryptographyType theoryRule of inferenceWhiteboardForcing (mathematics)TelecommunicationChainMultiplication signBitTraffic reportingLecture/ConferenceMeeting/Interview
27:07
InternetworkingPhysical systemSequenceSign (mathematics)Lecture/Conference
27:33
MereologyMechanism designKey (cryptography)Graph (mathematics)Sign (mathematics)Reading (process)ChainRight angleLecture/Conference
28:24
Band matrixEmailEncryptionKey (cryptography)EmailGoodness of fitMereologyData conversionView (database)MaizeComputer animationDiagram
29:08
NumberRight angleEndliche ModelltheorieExpressionGroup actionCommunications protocolElectric generatorKey (cryptography)Block (periodic table)ChainRevision controlEvent horizonMathematicsSemantics (computer science)Meeting/InterviewLecture/Conference
30:07
Block (periodic table)Pointer (computer programming)MetadataIdentity managementRevision controlLevel (video gaming)Price indexTimestampElectronic signatureData structureNetwork topologyBlock (periodic table)Data structureKey (cryptography)Process (computing)Derivation (linguistics)BitCryptographyNumberFunctional (mathematics)ChainHash functionComputer animationLecture/Conference
30:49
RootCalculationPrice indexAdditionInformation privacyInternetworkingMultiplication signGraph (mathematics)Computer animationLecture/Conference
31:37
RootCalculationPrice indexAdditionContent (media)EncryptionContent (media)NumberGraph (mathematics)InformationInformation privacyNetwork topologyLatent heatMechanism designSocial classComputer animation
32:16
Multiplication signLecture/ConferenceComputer animation
32:44
Computer clusterJSONXMLUMLComputer animation
Transcript: English(auto-generated)
00:16
I guess many of you are using PGP here. If you do, raise your hand.
00:23
Go, hackers. So if you want an introduction to someone new that you know someone else has a key to, you usually have to do the little dance, ask for a key, do you have a key to that and that person, because that's, well, let's admit it, pulling keys off key servers is boring, but that's the way you usually do it.
00:42
What if I told you there is a better way? What if your friends and friends of friends can attest that a certain key actually belongs to someone in a more nicer way than just attaching signatures to PGP keys? Our next speaker will introduce you to ClaimChains, a system aiming to solve
01:02
this problem. Please give a warm round of applause to doctoral researcher, Mariusz Itakayas. Take it away. Hello, good hackers. So he has given a great description of what we will be talking about.
01:20
It's called ClaimChains. It's a modern key distribution mechanism, protocol and implementation, that we've done in collaboration with Bogdan Kulinic and Carmela Troncoso from EPFL, and George Zanez is from University College London. I'm Marius Itakayas again from University College London. So in a few words, ClaimChain is a decentralized public key infrastructure
01:44
that supports privacy-friendly social verification. And if you've read the description of our talk, you know that we will be mentioning a lot the word blockchain. So it is a hype, of course.
02:02
Blockchains have been used in many applications. But actually, they provide some very good properties that might be useful for public key infrastructures. For example, they provide high integrity for the data that we store. Past data become tamper-proof.
02:20
It's very difficult to modify them without changing, overwriting the history. And we can also be sure of the authenticity of the data because of all this cryptographic signing and hashing going on. And by definition, blockchains are decentralized, so they can provide good availability. You can go to any Bitcoin full node, for example,
02:43
and verify your transactions. They are censorship resistant. If you want to bring Bitcoin down, you have to go and bring every full node down. And they've solved the problem of global consensus through this lottery mechanism of proof-of-work.
03:01
The more resources you contribute to the systems, then the more ballots you get in the lottery, the more tickets you get. So the first generation of blockchain-based public infrastructures are based on such proof-of-work blockchains.
03:24
For example, Namecoin and Blockstack. They have replaced the kind of use the Bitcoin token, the cryptocurrency tokens, for identities. Therefore, you can buy identities, you can sell them to others, etc.
03:41
And they belong to you. So this is a more powerful abstraction for identities compared to PZP keys, as we use them today. And they also provide you with a global namespace. If you have this identity in Namecoin, it is you. Everybody will recognize you as the owner of that identity.
04:04
On the other side, they provide no mechanism for social validation. If somebody claims to be, for example, Alice in that system, how can we know, out of all the people who claim to be Alice, that this person is actually Alice? There is no type of trust mechanism. All transactions are public, and this has some privacy implications.
04:23
For example, you might be able to through the transactions to infer that some identities are linked to each other. There are some inherent fees that users have to pay for buying coins and for all the transaction fees.
04:41
And of course, it's very resource-expensive with the proof-of-work. There is a 10-minute latency for every block to be a specific number of transactions that can be included. And so on. Then came the next generation of public infrastructures on blockchains with keybays and conics that can be deployed by email providers.
05:06
For example, for example, XAMPP and Xmail. So what they did, they replaced the transactions block with a Merkle prefix tree. I'm going to describe in a bit what this is. And what they achieve is accountability for the providers
05:22
with regards to the keys they publish about their users. So imagine, for example, that Xmail is using conics. You could go and retrieve the public key material for a Xmail user from their conic server, and you also get some proof that this is the same key
05:41
that everybody is getting at that specific time. So you also have easy discovery because you know, for example, that Alice at Xmail belongs to the Xmail provider. You go directly there, and it's very efficient because it's only Google that maintains and constructs the structures, and they can provide you with very efficient proof in a few kilobytes
06:02
that actually this is the right data that you get. On the other side, they do not prevent a key vocation. They just make it detectable at a later state, which might be already too late. And to an extent, they are centralizing the public key infrastructure, which opens them to attacks, for example,
06:22
because they are a single point of failure. If the Xmail conic server is down, then you won't be able to get the PGP key material for the Xmail users, and also puts the providers in this privileged position to perform surveillance with regard to who is trying to communicate,
06:46
revealing the social graph that the users would like to hide, etc. So the Merkle binary prefix tree that I mentioned before is a Merkle binary tree, as you see. But the difference is that in order to sort the leaf nodes
07:04
when we are inserting them, we are using a verified random function. Instead of a hash, we use this verified random function. It is a function that produces a unique output given a private key. So imagine that I have a private key that is compatible with this verified random function.
07:24
I can produce an output that looks random to everybody. You cannot guess it. But if I give you the public key, you can verify that this is the unique output. And this, as a result when applied to Merkle trees, assures us that everybody who will search for a specific label
07:47
will end up to the same leaf node in the Merkle tree, therefore achieving non-equivocation. I cannot, if two people come to Conic's Xmail provider
08:00
and ask for Alice's Xmail, because of these properties, they will both get the same leaf node. Now, claim chains. How are we using the Merkle binary prefix trees and what are we doing different compared to key-based Conics, for example? What we do different is we push for decentralization
08:23
by having the users host the claim chain by themselves. So we have a claim chain for each user, or for each of their devices, or for each of their identities that they don't want to connect. For example, you have Alice who has her own chain, Bob, his own chain,
08:42
and Guy Fox, who could be anyone in the Internet, even Alice, has a different chain. There is no consensus, there is no global consensus, blocks are updated as needed. You just generate the structure, sign it with a signing key, and that's it. Everybody can verify that this sequence is valid.
09:04
Imagine now that at some point there is a fork in a chain, because two valid blocks originate from a given block, then this can be interpreted as a compromise, because somebody has got my signing key and published something different,
09:23
or it could be that I've tried to key-vocate to one of the readers. Finally, we've also added a fine-grained access control mechanism based on capabilities that allows the claim chain owners to select who can read a specific claim,
09:43
and through the non-equivocation of the Merkle prefix trees, we assure that all readers get the same content. Yet, we need a way to propagate this information, because how do we know of updates of our friends, how do we find out how the key distribution works?
10:05
We've introduced this mechanism of cross-hassing, where we include a vouch, a stamp, of the latest state of the claim chains of our friends. So you see here, for example,
10:21
that Alice includes an attachment for Bob's latest block and Guy Fawkes' latest block, and Bob also includes a statement, but at a previous point that he was aware of. It might be stale a bit, but that's how consensus and propagation works in these systems.
10:43
So we have propagation of key updates in clicks of users, in groups of users. This is how gossiping works in the real world, between real humans anyway. We don't just append cryptographic signs on keys of other users,
11:01
but we also vouch for the latest state of their view of the world. And we can use this cross-hassing mechanism for introducing friends, for social validation a la Web of Trust, while at the same time preserving the privacy of the social graph of the claim chain owners.
11:22
An overview of the claim chain properties. So claim chains are high-integrity authenticated data stores, high-integrity because of the blockchains and the Merkle prefix tree, authenticated because of all the signing going on, that can support generic claims.
11:40
So we've decided to use this for a public key infrastructure. You can use the claim chain structure for building access control delegation, or command and control for your botnets, or whatever you might come up with. At the same time, we assert privacy of the claims that are published, even though everything goes public.
12:00
We do not reveal any information about the content of the claims, or about the readers of the claims. And we do that via capability mechanism, that I'm going to describe in a bit. Privacy sometimes can mean a key vocation.
12:21
I could encrypt different things to different readers. We again prevent that. All readers get the same view. The cross-housing mechanism enables the propagation and vouching of the latest state of linked claim chains. I've mentioned that the key vocation attempts and compromises
12:42
produce non-reputable cryptographic evidence, the claim chain forks. Non-reputable cryptographic evidence means that we can take them. They are self-sustained evidence that we can share with the world, that we've observed two blocks originating from a specific block in time. Therefore, something is wrong with that claim chain.
13:03
Now, with regard to deployment, we've done lots of work in evaluating how claim chain can scale, and how effective it is with regards to key propagation, etc., and what are the bandwidth requirements, how long does it take to compute the structs, etc.
13:20
You can find all this information on the claimchains.github.io page, where we have our paper. Claimchains is very flexible in terms of deployment. It can work in the federated scenario, like in Conix, or it can work with high availability online data stores, when we just go on and upload all of our blocks. Or it can even work in a gossiping ad hoc scenario,
13:43
when we just append... Do you want to... How do you say this word? So anyway, when you just include the proofs in the emails that you want... When you attach the evidence that you want in the emails you send with your friends,
14:01
we can do that in a very efficient way, by including only the claims that we want to include for that reader, plus some evidence that these claims are actually part of the claim chain, and all the proof of inclusion in the Merkle tree, etc.
14:23
Now the internals of claimchains. We still have some time for that. The block structure has some claimchain protocol information, like the version, of course the times tab, the block sequence index, some knowns that we use for achieving an linkability between the claims and the capabilities across different blocks.
14:45
Claimchain metadata. All the connected identities, may they be other claimchains, or a Twitter handle, or an email, that the user wants to connect into this claimchain. And some public keys that are needed for the operation of claimchain.
15:02
We need the public key for signing new blocks, the public key for the verifiable random function that we use for the Merkle prefix tree, and the Diffie-Hellman key that we use for the capabilities technique. Then, the core element of the block is the blockmap,
15:21
is where we store all the claims and the capabilities in the form of a Merkle prefix tree. Of course, pointers to previous blocks, that's how we connect the blocks into the blockchain. Now, if we consider all of the fields on the left as the payload of the block,
15:41
we sign it, and we attach the signature, and this is a self-sustained piece of information that we can attach to an email, or we can store in an online data store that we do not trust, and still be sure that no one can tamper that information. If we want to add a claim, for example,
16:03
we are in analysis Merkle prefix tree, and we want to add a crosshatch for Bob. First, we need to define the label that we will be using for Bob from now on. It's going to be bob.isop.net,
16:20
and let's imagine that the claim is the latest yet. So first, we're going to compute the claim key with a very fun random function using Alice's private key, and then we're going to put inside bob.isop.net, plus the nonce, so that we can achieve only capabilities I've mentioned before.
16:41
Then we can calculate the index of the leaf node, how we're going to store that leaf node in the tree, simply by taking the claim key and passing it with a string lookup, and we're going to generate a symmetric encryption key, again, by taking the claim key k from step one
17:03
and appending encryption, and then passing it all together. So we encrypt the claim content with the symmetric encryption key that we got in step number three, and we also include the VRF proof
17:20
that people can go and get to be sure that the claim key that we've computed in step number one is actually the correct and the only one. So that's how we get the leaf node that corresponds to the crosshass for Bob's claim scene.
17:43
We store that in the tree. Next scenario. We want to add the capability for Guy Fawkes to read Bob's crosshass into Alice's claim scene. First step. We use the Diffie-Hellman to establish a third secret S
18:02
between Alice and Guy Fawkes. So we use that third secret into a hash, again, along with nonce and with a lookup to generate the capability lookup key. That will be the index of the lookup key
18:22
of the capability claim as we're going to store it in the tree. Nonce is here in order to achieve an leakability and to hide the patterns of how capabilities are added and revoked. We're going to derive a symmetric encryption key as we did before,
18:41
and we're going to encrypt the claim key from the blue leaf node that we've added before without the symmetric encryption key from step three so that Guy Fawkes can decrypt it in the future.
19:01
So we generate that leaf node and we store it in the tree. Now, if Guy Fawkes wants to find out the latest update for Bob in Alice's tree, he's going to do the reverse process.
19:21
He's going to establish a Diffie-Hellman third secret S between Alice and Guy Fawkes and get the capability lookup key and the symmetric key in the same way that Alice computed it. And he's going to go to Alice's claim tree,
19:42
a medical prefix tree, and retrieve the corresponding leaf node. He's going to decrypt it with the symmetric key K from step number three, and he will be able to get the claim key for Bob's claim. So far, if you remember,
20:05
the claim key for Bob's claim includes the house of a VRF. So he's going to retrieve Bob's claim from Alice's medical prefix tree and decrypt it using...
20:27
Again, he can compute the VRF key because of step number four. And are we done? Not really. He needs to use the VRF proof that is embedded into the decrypted claim
20:47
in order to verify that actually the VRF proof that he gets is the only one that Alice could have produced with her VRF private key. We went through that very fast,
21:01
but again, all this information is in the paper, and you can take a look at it, or please come find me after we're done. I have more slides that explain how proof of inclusion works, how proof of absence works, etc. One thing I should have mentioned is that in step number four, if Guy Fawkes tries to retrieve a capability block
21:23
and cannot find it, it means that Alice has not given to Guy Fawkes the capability to read the claim about Bob. At that point, Guy Fawkes cannot know whether a capability for Bob exists at all.
21:46
Now, we've submitted this talk for the CCC Resilience track, and we understand that this is academic work to an extent, but we do care about resilience, and we would like to share some of why we decided to do that.
22:07
First of all, we started with field research to understand user needs. This was done by some researchers in Paris. Later on, projects that care about resilience need to be open to collaborations
22:26
with communities that are already working on these problems. We've done that, for example, with another organization in Germany, and we're in close collaboration with Autocrypt with that.
22:43
And we've used techniques that are actually, again, very well used.
23:02
Okay, sorry. So, in academia, there are these techniques going on now. In applied research, that is pushing for formally verifying the properties and the code that you are producing.
23:20
And for claim sense specific, we have formally defined all the security and privacy properties using cryptographic games. So we know, for example, that we provide non-equivocation under what terms, and that we can provide un-leakability across blocks again because of this and this and this cryptographic game that we can combine together.
23:42
And we also have a formally verified implementation of our cryptographic components in F*. So you can go and find the Merkle prefix tree and the VRF function in our GitHub repositories.
24:00
When it comes to resilience, we need to know how our systems can scale, and therefore we've used simulations with real-world data from the Enron dataset. This is a leaked email directory from a company called Erron. So it's usually used in the academia for when we need to simulate real-world communication patterns.
24:29
And we've used this for calculating the efficiency of the cross-housing protocol in propagating the latest state of other people's key material.
24:44
When it comes to interoperability and plans for gradual deployment, as we've mentioned, claim sense is very flexible on how you're going to deploy it. We've chosen to be... and we know, for example, we haven't done much yet, but we know that when it comes to actually starting to implement this to users,
25:07
we need to be compatible with all existing email encryption applications. So, for example, we want to be compatible with the Knoopdz agent. Again, something that is very important, I don't think we've done great work here, but usability of email encryption.
25:25
How do you perform key management in a way that users can understand, not do mistakes? What happens when you need to revoke a key, or there's a key compromise? How do you communicate this with a user, and how we can act upon that?
25:51
There is a great debate that is going on on that, and unfortunately we cannot say that we've solved this at all. We focused on coming up with the structures and the properties
26:04
and simulating how claim chains can scale and work effectively. Hopefully though, we've been able to do all of the above because we are a multidisciplinary team in NextLeap. We've got sociologists, we've got philosophers, cryptographers,
26:25
and it's great to have European projects that are focused on privacy and secure communications, and they can actually use the knowledge of all parties for that.
26:42
I think this is also pushing for open innovation. All of our material reports and source code is open to the public, and everybody can go and take the claim chain structure and use it for other types of applications. So this is how we can extend claim chains.
27:04
So we have a bit of time for questions. Thank you very much for your time. Okay, we have four microphones here in the hall.
27:20
Please line up next to them. Thank you again very much Mariusz. We do have a question from the internet. Signal Angel, please. Yes, as far as I understand, to use this system, you both have to do the signing dance just as with GPG, but also to ask your friends to give your read access to parts of their social graph.
27:42
Isn't that even harder to use and scale than GPG? Your understanding is correct. We still need to do this crazy dance thing and ceremonies and key signing parties if you want to be sure about the other person,
28:03
that you have the right claim chain for the other person. But we believe that through this mechanism of introductions, it might actually...
28:20
Let's see how it works. So this is part of the simulations. As you can see on the left, we simulate the complete decentralized scenario where we just attach introductions in emails, and we see that it kind of works without having to...
28:47
If you trust the person who is introducing you to the other participants in the conversation, then we say that we can have a good status of emails going out encrypted with the right keys.
29:09
Microphone number 1, please. I'm interested in the expressiveness of your capability-based access model. Do you support things like groups? Do you support revocation of credentials?
29:22
Do you support delegating right access? Things like that. You can do all that. For example, we say that you can use segpal semantics, and then you can do whatever you like,
29:40
like threshold, revocations, you can build this on top of our stack, but we haven't done that, no. Microphone number 2, please. Use SHA-256 for both lookup and encryption key generation. How difficult would it be to change it provided it's broken one day?
30:00
Given that we have a claimed chain protocol version somewhere at the top of the block structure, that's how you would probably change it, but no, it won't be easy. Thank you. Microphone number 3, please. Hi, thank you, great talk.
30:21
I want to ask about the crypto bit and key derivation process. Why are you using SHA hash function to derive keys, not some key derivation function like HKDF or PBKDF?
30:47
I think it's for simplicity reasons, but I don't have an answer on that. Probably what you're suggesting is better, and would you like to discuss about it later on?
31:00
Of course. Thank you very much. We have time for one more quick question from the internet before we have to close. How is privacy of the social graph, the crosshashing, ensured again? I'm not sure I fully understand that. The privacy of the social graph, how do we protect that?
31:25
The privacy of the social graph, the crosshashing, how is this ensured? So if you take a look at when we add the claim, the actual content of the claim that we put in our micro prefix trees is encrypted.
31:47
And it does not leak any information about the label or the content of that claim. And because of the capability mechanism of allowing only a specific number of readers
32:06
to read a specific crosshash, I think that's how we achieve the privacy of the social graph. Thank you to everyone. Sadly we ran out of time, but Mariusz will be here for a little while longer
32:22
so you can catch up with him over a chunk or a beer and well, thank you again Mariusz.