 Hey everybody, my name is Sam Walker. I'm an engineer at Aeroswap. This is a workshop about key space, which is a protocol for antenna encryption using Ethereum and IPFS. Before I get started, I wanted to give a bit of a prologue for putting this piece of technology in kind of a larger context of what I see of kind of emerging technologies. So the inspiration for key space first came to me about a year ago when I was listening to a podcast by Arthur Falls called The Third Web. He was interviewing a developer named Dominic Tarr who's the who develops a distributed social media network called Secure Skeletal, but if any of you are familiar with that. But the thing I really liked in the interview was he talked about this concept called Cypher Space. So Cypher Space is what he sees as kind of an emerging style of application development on the net or on the web that has a kind of a proper abstraction between the networking layer and the application layer and that proper abstraction is enabled for the first time really by use of different cryptographic parameters. I think that having your application logic divorced from your network, networking logic looks kind of like GraphQL in that, you know, you can kind of specify what your application needs, but you don't have to worry about how it gets to you. So I think some more concrete examples of like what Cypher Space is and how this kind of development methodology is going to play out in the future. It's going to be made clear in some later examples, but just to have that context as you kind of wash this presentation. So this is the agenda. We're going to start out on a high level and just answer what is Cypher Space. So why was it built and what are its core components? Then we're going to zoom in a little bit more with the in-depth technical description. So there's kind of three main stages in the user lifecycle within the protocol. We're going to work through each of those. After that is the fun part. We have interactive examples. There's kind of a demo that you all can load up on either desktop through your phones, and we can kind of do some peer-to-peer encrypted group messaging amongst each other. And then after that we'll have some time for questions or exploration to see, you know, what we can do with this kind of protocol. So first definitions. What is key space? I think the simplest way to sum it up is that key space is a trustless open PGP implementation built on top of Ethereum's existing cryptographic key tooling. So some obvious questions come up from this definition. First of all, for those unfamiliar with cryptographic protocols, what is open PGP? And secondly, why do we need open PGP on Ethereum? So PGP stands for Pretty Good Privacy. It's an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing, encrypting, and decrypting text, emails, files, directories, and whole disk partitions, and to increase the security of email communication. So that's just the definition of what it could be. So PGP, a little background, it was developed by a cryptographer named Phil Zimmerman in the 90s. It was first developed as enterprise software. And in 1991, around 97, Phil decided that this would only work if it was open source, so he started the open PGP initiative. Then around 2014 is when elliptic cryptography was added to the protocol spec, which is much wider weight than the older forms of encryption of the protocol used, like RSA. This kind of lighter footprint allowed it to be more realistically used in the browser. So openPGP.js was added about the same time, kind of opening the door for end-to-end encryption screen-to-screen encryption. So you know, there's no... about the same time, kind of opening the door for end-to-end encryption, screen-to-screen encryption. So, you know, there's no, you know, it's kind of the standard of encryption that we like to have today, which is usually like a telegram or signal or other things like that. So, why do we need to bring PGP on Ethereum? So, a little background, this came to be because of specific kind of business needs that Areswap had. So, in kind of the history of like DEX development, the first popular DEX is like Ether Delta. All the information was held on chain, like in the smart contract. So, with order posting, order matching, and order settlement, all happened on chain. Kind of second generation DEXes had some improvements upon this to save gas. So, protocols like Areswap, ZeroX, Idex, DEX is HydroProtocol, and DYEX is Nebulant Orders, all kind of use a similar approach for gas saving where an order is signed off chain, it's posted somewhere, matched off chain, and then settled on chain. So, on Areswap in particular, the way that the protocol works is that order hosting happens period of year. So, makers send orders directly to takers. Matching happens when the taker decides that they want to fill the order, and then the actual settlement happens and the order is filled on chain. But since all of this is being moved off chain into messaging, that messaging has to happen somewhere. There's a possible information asymmetry that arises because like for example, if Areswap is hosting a messaging platform, then we kind of have a global view into all the messaging that's happening that could potentially give us an unfair advantage of seeing the trade that's gonna happen before it happens, or a GC-style interaction where you can see people negotiating a trading context. So, to kind of eliminate this kind of unfair angle or this unfair view, we need encryption. So, if all messages between makers and takers are encrypted, then they're the only ones who are able to see it, and there is no kind of global view to exploit from the angle of being a more technical party or kind of having a global access to the system. So, we need both encryption for that reason, and then we need authentication to basically tie the messages that are created to a particular viewing address so that if somebody is being abusive in the messages that they send, for example, trying to de-auss the network, we can say, okay, these messages are cryptographically verifiable as having come from this address. We're gonna disable, you know, that address can't send messages anymore, and then we can kind of see if assets transfer between that address and another address, we can basically figure out who's using the network or have some standard where we can have economics incentives for behaving correctly. So, obviously, by authentication, I just mean a signature and verification of the messages. So, there's a lot of different cryptographic protocols that you can use for authentication and encryption of messaging, but PGP seems like the right choice for multiple reasons. One of the main ones is that it's the right age, and what I mean by that is that it's been around long enough that it's fairly safe, it is, you know, very robust, it's used all over the world, and it's been around long enough that it has a great tooliness associated with it, which kind of helps on the developer lift of infamining a protocol like this. But then it's also simultaneously new enough that it uses cryptographic algorithms like elliptic cryptography, which is way enough to use in the browser without negatively impacting the user experience. Okay, so that's kind of the high-level view of why we needed to implement this trustless version of PGP on Ethereum, so we're going to zoom in a little bit and talk about kind of the specific implementation and how it looks and feels for a user. So the first step in that is a key generation in recovery. So what this means is that we're trying to deterministically generate a PGP key pair from an Ethereum key pair such that we can verify that this Ethereum address generated this PGP key and that if the PGP key is lost, for whatever reason, we can regenerate it as long as you have control of the wallet. So kind of a practical example of this is if I have my ledger and I generate my keys on one computer and I use those keys to read my encrypted messages, I can then terminate that session, wipe out that information, plug my ledger into another computer, regenerate my PGP keys and use them to decrypt the same messages. So it's kind of a stateless in a way and it's deterministic and so that's just kind of one of the properties we wanted to have in the system. The next step after keys are generated is a key distribution and lookup. So if I want to send a encrypted message to you by knowing your Ethereum address, I have to have some way to look up that Ethereum address and find your PGP key and I need to be able to cryptographically verify that that is indeed your PGP key which I can then use that public key to your encrypted message and send it to you. So there needs to be some sort of directory basically. The initial implementation of this actually for us was a smart contract. So you basically stored your PGP key on IPFS, took the IPFS hash of that key and stored it in a smart contract and then when I wanted to find the key associated with your address, I would just look it up in a smart contract. Pretty soon though we discovered that there is like a whole swath of users who didn't want, who wanted to basically try an application without paying gas upfront. You know as soon as like you have to pay for a transaction they weren't as interested in using that application. So there's another alternative way of storing these keys where instead of storing a contract, you sign it so that you can verify it as yours and then the signature together with the key can just be stored in any database and since that signature always exists next to it you can just pull it and look it up. It doesn't have the same guaranteed availability of the smart contract. So currently that database is hosted by Areswap and if Areswap went away then that database wouldn't be hosted but for those users they would just have to regenerate their keys and they could begin using the system again. So there's kind of different options of like based on like the longevity, the dependability that you need and the level of trustlessness that you desire. You can either pay more for that or kind of have more of a low investment alternative. So the third step in this is passive authentication and privacy. So after everything's set up basically, keys are generated, they're distributed and they can be looked up then we can use them at the application level without really having to understand anything about the underlying cryptography. So just all messages between periods that have the simultaneous guarantee of if you receive a message, you know for sure that the Ethereum address that sent you that message is who they claim to be and when you send a message that nobody other than the Ethereum address that you intend to read it will read it. So that's kind of like high level. Oops, I got out of a worry. So zooming in on the key generation. So there's actually some, we're not the first people to kind of come up against some of these problems. And a lot of the, many of the cryptographic libraries that wallets like MetaMask for example depend on like provide methods of deriving secondary keys from primary keys, but unfortunately there isn't an RPC spec for kind of exposing these methods to like the end user and adapt. But so the way that we get around that is key generation happens by taking the passphrase which is just the plain text word or set of words and then signing it and then using that pack string that's generated as kind of the encryption key for that encryption private PGP key basically. So openpgp.js when you generate a new key bear you have the option to pass in the passphrase that's kind of the encryption password. So that signed message becomes the encryption password for your key bear basically. So that's kind of a low level of how those two are associated. And then once that key is created IPFS provides kind of chief reliable storage. So the way that works for us is that we store the IPFS, we store the key bear and IPFS in like basically a redundant set of nodes using the pin set. So, you know, they go from infura to pinata to our own IPFS node to Cloudflare and some others. So we kind of use that pin set to like replicate across all those nodes. So that kind of makes these key bears reliably available without having to store them like on a smart contract basically. So key distribution. So this is kind of like the directory or the index that I talked about before. I think I actually covered most of this already but one thing I wanted to touch on was this idea of multiplexing which is an idea that kind of comes from with B2B basically. So if there's basically like, it's kind of like function overriding but like on the network level. So if I want for example to request some information and I shouldn't have to care about how that information is stored or how it's fetched I should just be able to, you know, ask for it and have some guarantee about how it gets to me. So kind of the multiplexing in this case is that we have keys that can be stored on a smart contract or keys that can be stored in a database and when you look up you kind of do that look up of both the smart contract and the database in parallel. And on the application level, you know, you don't really care about where that key is stored. You can just use it. And this also allows for the addition of other types of data storage for distributing the keys. One of which we use in our demo which is coming up shortly. So, Authent privacy. So this is kind of the last step in the Azure lifecycle. So this is like after everything is generated and distributed we can just enjoy the benefits of everything that the OpenBGP library offers. So on keyspace, on a keyspace class there's four function types that are pretty much everything that they're gonna use. You have an encrypt which takes a message, a plain text message and the address that you're going to send that encrypted message to. Decrypt which takes an encrypted message in the from address so you can verify that it was sent by the address you plan to send it and yeah, then you can just get the decrypted message that's meant for you. And then we also in isolation provide sign and validate as well. So that's all for the high level review. Now is the fun part which is the demo. So this demo will work on both your laptops and phones as long as they're connected to the internet. So you can go to the top link there where the live app is on the airstop.github.io slash keyspace slash devcon. That's where that link is not shorter. But originally this would be kind of a lot cloning repos and interactive coding and kind of I saw like all the network limitations we see that have here. So I just kind of spun up this app quickly which I think should work on, I tested on tree throttle internet so it should work all right. But I think this kind of will give us a view into kind of like the inner workings of the protocol without having too much of a bandwidth limitation. So I'll let everybody pull it up, walk everybody through how it's working. So it's basically just a, it's a React front end application that uses IPFS Pub-Sub to kind of have group messaging. So one of the cool things about this is that it's a group chat app that doesn't have any central survey to it. So basically everybody's fair and in laptop kind of in the room is kind of going to be networked together and it's kind of form a peer-to-peer chat application. Oh yeah, and also sorry I should have mentioned. When you first load the application it has an option to connect to MetaMask which that'll also work in like a lot of trust. You can also just generate a wallet inside the app, generate a temporary wallet which will, you can still use that to communicate since it doesn't currently use any gas. So doing most people that are gonna pull it up, have it up, anybody still typing? Okay, all right, so I'm gonna get to these steps myself. I'll generate a temporary wallet. So I'm the only peer that I found so far. Hopefully over time I'm gonna find all of you. Is our other people at this screen after generating the wallet? Okay, hey, there everybody. Okay, so I hope the mobile display still works with all these addresses and I wasn't able to test with that many people. Okay, so I'm gonna be Sammy. Okay, so, whoa. Okay, so this is everybody sharing their PGP keys with each other. Okay, I definitely have not tested it with this much scale yet but it seems like it's working okay. Yeah, okay, so I can go into a little bit of, I can go into a little bit of what's going on here. So basically this front tab, I think it says peer on your fan on the desktop it says peer discovery protocol. So basically this is a, instead of using a database or a contract to distribute keys, we all connect to the same IPFS Pub-Sub topic. So there's basically one IPFS server that we reach out to and say, hey, I'm listening to this topic. Then when other people connect, they also reach out to that same server and say I'm listening to this topic and we kind of find each other all through that way and then peer directly with each other. Then after we're all peer, we broadcast our key and then we send a message which is what we call a request introduction which basically is like a, we send a message to the Pub-Sub topic that is asking other people for their keys and then everybody else responds to that person with their keys basically. So it's kind of like a many, many messaging system for kind of building this dynamic database of keys. And like, so as you can see the more people that are added, the more messaging, the more people are requesting that everyone's keys the more messages that are sent. So that's just kind of go crazy probably right now. So then down here on the no one peer screen, oh yeah, I definitely did not design this for this many people to use. I built this like yesterday. So you can basically choose the keys or the identities that you actually want to send encrypted messages to. And then when you, I'm gonna say hello, sorry to the people that I didn't use that, but just under the example. And so then basically everybody that I selected will get a copy of that message that they can decrypt but everybody gets everybody's message. So, but the thing is is that only the people if you buy encrypted that message specifically for will be able to decrypt it. I'm gonna refresh this page because all the people joined have broken my view. So to take it kind of back to the original, that's kind of what I built this application of an example of. So the actual data transport like layer of this application is completely public and anybody can read it. It just, it takes place on a public IDFS topic but there actually is a complex application logic of permission to group chat happening in this public forum. So this is kind of the idea of Cypress Base that we can kind of divorce application logic from transport network logic and even database storage logic. But we shouldn't have to care about where the data for this application lives. All we have to care about is availability that part still hasn't really been solved yet. But, and then just write our own application logic using these different cryptographic primitives to kind of enforce the rules of our application. So this application, it's sort of a bit of fear. It just exists on all of our phones and our laptops in this room. And we're basically sending each other plain text messages but then all these different cryptographic tools kind of allow us to have a structured application built in this really simple context. So, oh, and for those of you on desktop, it's gonna really fit in the mobility but you can actually look at the key space parameters that I kind of talked through in the first portion. So you have like, you're on the sign-seed. So this is like what you sign to generate your password. This is the password that basically encrypts your private key. Then this is the PGP public key and the encrypted PGP private key. So these are kind of the building blocks that we're using to build this application. Try to think if there's anything else about this one. Oh yeah, the nickname. I can't get to it because there's so many people now. But as those of you who have said it, the nickname exists as one other type of specialized message on the network so you can kind of announce your nickname when you announce your key here. Yeah, that's it for the, oh yeah, sorry. I have one other thing. So if you have this loaded and you actually wanna look at some of the code for the application, you can click the question mark in the top right and it'll open up to GitHub. Kind of talks a little bit about what it is. Links to the application, links to the slides and the slideshow, and then links to KeySpace, which is bundled as part of Airsoft.js. You can look at the code for the application even though I wrote it really fast, so it's not very good or it's messy. But I would instead suggest that you actually look at the KeySpace in the Airsoft.js library, which actually has some better examples of documentation and it's easier to use. So yeah, if you wanna include KeySpace in your application, this is where you would go to figure out how to do that. Yeah, I think that's it for my demo. I think, yeah, so my epilogue is about putting it in the context of Cypress Space and this kind of application, right now it's running in public on IGFS, but it could be running on any kind of transport. Any messaging system, you could have any crypto messaging system built inside of it and the stories can happen anywhere. So I think that the initial Airsoft trading network was built on RabbitMQ and it's easily affordable now to IPFS because of that separation of concerns that we were talking about. So I think that, at least what I believe is that, I think that if we follow kind of this paradigm, I think that applications that we built in the future that are intrinsically tied to a certain type of web transport layer, like for example, fetching data over HVP, fetching something from WebSocket, it's gonna start to feel like spaghetti code. It's gonna start to feel like expensive and full of tech debt because it's hard to port. It's hard to, you have all these assumptions in your code about how the data comes to you and how it's available in the kind of areas that will happen when you fetch it. And I think that with this kind of approach to building applications, you have a separation of concerns such that you can actually port your application to different types of transports without having a lot of tech debt that you have to resolve. So yeah, that's it for my presentation. I have time for some questions. Thank you. Why did you choose to encrypt the key using a password rather than using the 50-helmet elliptic with the elliptic curve that you already have from your hearing address? I think it's because it's not available to DAP users over JSON RPC message. It's not part of the standard JSON RPC message format for interaction with a private key, basically. So the only cryptographic function that we have available to us as people who build applications that work on top of wallets are basically like personal sign, send transaction. There's a lot of cryptographic primitives that would be useful. When I was first building this and I didn't need it for encryption, I wanted to actually, I was like, well, why can't I use the Ethereum private key to encrypt data or decrypt data? But theoretically it's possible. Those functions are in the underlying cryptographic libraries that a wallet like Ledger or MetaMask uses, but it's just like the spec for making those functions available is far away. It's gonna be a long time until anything like that is. So this is kind of like a way of working around that limitation. Do you have to sign the same message every time to get the password? Yeah, so basically kind of what I was talking about earlier, like there's a bunch of different types of users who wanna use an application like this. Some are more hardcore about like their privacy and some people want something that's more convenient that they don't have to think about very much. So if you want to, for those users who want something that's very convenient and they're not as like worried about privacy, basically you can just kind of sign a default phrase that we choose and kind of provide to you every time to sign. So then it's kind of like, you don't have to remember the passphrase and you can kind of deterministically regenerate it. If you want another layer of privacy, you can choose your own passphrase. It's a secret to you that nobody else knows, but then if you lose that passphrase, then you lose access to your messages. But that's available for users who want a better layer of privacy. Yeah. Can you think of any practical use cases to employ key space apart from the example you just showed? So it's one thing that, the initial implementation of PGP like functions, it uses this concept called the web of trust to function, which is basically like people can trust PGP keys if other keys that they already trust also trust that those PGP keys. So like when the protocol was first developed, all the academic nerds would have signing parties and get together and trade PGP keys in person so they could kind of have that base level of trust and build this kind of trusted network. And then off of that, they built a larger network and it was kind of like, that was how trust was built. Initially, which is kind of actually now a site is kind of, it's more of a critique of PGP that that's kind of like a limitation of the protocol. Key space is more limited in scope since it's only about instead of binding identities to a real person, you're binding identities to an Ethereum address basically, but you don't have to worry about that same kind of web of trust, which has some kind of scalability issues. But I think there are some interesting opportunities with like connecting the systems like key space, not key space, key base, where like identity and a cryptographic key are already bound by other means. So then it kind of like allows you to use PGP and more modularly, where you can kind of strap it onto other existing networks of trust basically, as long as they have cryptographic capabilities. All right, that's it. Thanks everybody.