 Hey, folks, thanks for coming out. So this is Cryptpad. And so first off, how many of you know what Cryptpad is? How many of you have used it? How many of you haven't? All right, OK. So basically, what Cryptpad is, it's a zero-knowledge, real-time collaborative editor. That means the server doesn't know what you're typing when you type something. So basically, what we're doing is we're hacking on top of what you might call a quirk in HTTP, that anything after the hash mark in the URL is never sent to the server. It's there for a reason. It's not the reason that we used, but we found that we can put a key there, and then we can do all the encryption in JavaScript. And that will keep the server ignorant of the content. As long as the server is willingly ignorant, it can be ignorant of the content. So we also have a drive, like a Google Drive type drive. I can show you mine. This is my drive. It has lots of stuff and lots of folders. And the way that we get the drive is also a pad. And the way we get the key for the drive is we sCrypt your username and password. And then you take that, you store it in local storage. And again, never just sent to the server. You look up the drive, you decrypt it, and the drive just manages all your pads. So the server doesn't even know your username. That's the level of security that we have here and the level of just dumbness that we've put in the server. So we are 2 and 1 half developers. I'm only half. We're about 3,000 lines of server side code in Node.js. And just under 40,000 lines of client side code. We have 24 libraries, seven libraries, and AGPL. You can read the slide. And this presentation is on Cryptpad, as you can see. We have about 100 installations. Thank you installers. Thank you webmasters for not enabling stealth mode. So you do tell us that you are using an installation unless you enable stealth mode. So thank you because as developers, it helps us to know information about this. And then on cryptpad.fr, that's our flagship server, we don't have a lot of information about you. But what we do have is nginx logs. And so from nginx logs, we know that we get about 3,000 unique visitors a week. And about 16,000 pads are loaded a week. And CPU usage, it's really boring. And in case you'd notice, yes, the prod server is called cryptpad alpha dev. Don't judge me. So that's the drive. That's what you see as a user. And that's like one pad. This is another pad. This presentation is another type of pad. What the server sees is basically this. This is actually on the prod server. We have a bunch of directories. And then in the directories, we have a bunch of files. And the files are just hashes. They're basically indistinguishable append only logs. And we can make guesses about them by the pattern of sizes of encrypted messages in them. But other than that, they're indistinguishable. And this is what you see inside of a log. So it's basically the sender, message, recipient, and the content which is encrypted. And that's all the server sees in any file. It doesn't know if it's a drive. It doesn't know if it's a pad, or a presentation, or anything. So this is my like, I want to say, if you're doing interesting things with open source, consider research. Because this was funded by Investissement to Avenir and BPE France, part of the Open Pass NG project, which we participate in with a couple of businesses, Lina Grande Nexity, and a couple of universities, Laurier and Leaks. And with this project, we were able to make Cryptpad from just a very small proof of concept. We brought it up to where it is today. And it wasn't even supposed to be in the project. It was convenient for demoing and testing the things that we were developing for the XWiki Cloud, which was in the project. So what is in this Cryptpad thing? So we have plain JavaScript. As far as how we develop software, we're really old. We develop old man JavaScript. And we use some ES6 APIs, but we have to all agree to use them. And it has to bring real value that we can't get otherwise. New prototype constructor, this. JavaScript, the bad parts. We don't allow that. Like, we don't want that. We use vanilla.js. We use some jQuery. We use a lot of required.js. We prefer unopinionated. We prefer libraries. We prefer old things. And actually, we have no build process. So when you install Cryptpad, when we update Cryptpad on the nginx server, we do a git pull, and we edit a file with a cache breaker with a version. That's it. That's the release. So the server side, that's Node.js. About 3,000 lines of Node.js. So if anybody wants Cryptpad in Python, just write it. Come on. 3,000 lines. So we allow some const, some let, some arrow functions. We're not doing classes, no generators. None of the hairy stuff in ES, whatever. We're using Express, WebSocket, NPM. We basically just threw together the server. But the server stuff, we could just change it to anything else. So we also use JS hit and flow type, which are quite nice. But again, no build. So we don't allow strange syntax leaking into our JavaScript. We use only the comment syntax of flow type. And we use selenium testing. But again, we're kind of old manning about this, where we say, yeah, well, selenium test, but we're only going to use selenium to load the page and then to pull the logs out of the page. So here's our CI server. And you can see those are browser logs that got sniffed out of the browser by selenium. And it's basically the browser is running the test because we set a cookie that says, we want to test, load the page, and the page self-tests. And then it says it passed, and then selenium sniffs that back up and passes the test. So this ends up being very useful for preventing the bane of selenium flaky tests that kind of pass and fail sometimes. So one of our innovations is the cross-domain iframe. So basically, all the UI in cryptpad is in an iframe that's on a different domain. It's not on cryptpad.fr. Because cryptpad.fr has local storage, and local storage has keys. And keys can read out your drive. And so in that event, any cross-site scripting is deadly. It's like total run. So everything that you see inside of here is on sandbox.cryptpad.info. So cross-site scripting attacks are limited. And we have RPCs everywhere because of this, which is sort of bad and sort of good. It helps us architect the software by forcing that on us. The server, it's basically a chat protocol. That's all there is. And it's a protocol called Netflix. And it was developed by the coast team at Inria, our partners. So because it doesn't have any history of its own, it's meant to be a peer-to-peer protocol. We have this magic user called the HistoryKeeper. And HistoryKeeper joins all the channels as soon as someone else does and just kind of stores that history. And you can send him a private message. And it'll send you all that history of that channel. So you can think of like a Super Chan serve. That's basically what we're doing there. Yeah, stores that on files in the file system. So we're not using MySQL or anything like that. We're just using flat file. And surprisingly enough, it's scaled so far. It's been OK. Basically what the server does, it reads a file into a web socket. So a lot of work there is there. If you build an index, you can also read out history ranges. But the elephant in the room here, a lot of people bother us about this, is that you kind of have to trust the JavaScript. You have to trust that it's not going, that we're not just feeding you JavaScript. It's going to eat your keys and send them to the server. So we don't have a solution for that right now. But I have a few ideas. And the first idea is that we use Substack Hyperboot. And basically what Hyperboot does is forever caches HTML with a signing key. It's trust on first use. If you hard reload, it's going to flush the cache. And you're back at square one. But once you've loaded that page once, you can see updates come in. And it's like, OK, there's an update to this web app. Would you like to use it? And idea number two is a Hyperboot validator. If we could get Hyperboot to start being used in zero-knowledge web applications, then we could build a browser extension that will validate that Hyperboot. And then attackers don't necessarily know if that browser extension is present or not. And so if they attack the Hyperboot thinking, like, OK, I'm going to change some of this to insert a backdoor, well, if the browser extension is present, it can catch them and even report them. And so we could track attacks. That would be pretty cool. And idea number three, which I'm not sure I'm going to have time for, but I'll go with it. This one's really, really geeky. We could validate this in Namecoin. And Namecoin is really kind of interesting because it has two really silly properties, really useful properties, sorry. One is that it's almost free to transform a Namecoin because everybody's just forgotten about it. It's like not an interesting cryptocurrency. And number two is that it's merged mind with Bitcoin. So the amount of proof of work that validates every Namecoin block, it's like astronomical. And this allows for offline validation. So I need to explain how blockchains work. So you have all these transactions, and they're hashed together in a hash tree, and they're put into a block. They're hashed into a block header. The block header is small. The transaction is fairly small. All the transactions are big. And the hash tree, each branch of the hash tree is fairly small. And then the way Namecoin works is that, with merged mining, is that they put the header hash of the Namecoin block into a special transaction in the Bitcoin block. And then so basically you can trace a route all the way up from Namecoin, a Namecoin transaction. You can trace that path by checking hashes all the way up to the Bitcoin block hash. And you might think, OK, Bitcoin blocks are 1 megabyte. This is going to be a lot of data. You have to send this to somebody in order for them to validate. Well, no, because you don't have to send the whole Bitcoin block. All you have to do is send that path. And I did the math on this. The path, it's actually about a kilobyte of data. It's one kilobyte of data. And you can validate basically any signature just by doing a Namecoin transaction. And if you send more Bitcoin headers, so you can send that path, and then you can send a bunch like 10 more Bitcoin headers. And they're 80 bytes each. They're basically free. And that makes the power, the strength of that proof like 10 times more powerful. It takes 10 times more electricity to fake that. And if we had a browser extension that just stored the header chain, which is 4 megabytes per year, then the proofs become basically rock solid. You can't break that. So again, Namecoin is interesting because it's merge mined with Bitcoin because it's old and because they kind of got in early. And nobody cares about it, so it's cheap to experiment with. A lot of other cryptocurrency people will tell you, oh yeah, we have a cryptocurrency that also puts things in Bitcoin. But the Namecoin is unique because it's actually merged mined into Bitcoin. And if somebody says, oh, I put something in a Bitcoin transaction, they could also put something else in another Bitcoin transaction. And then they could tell you about this one. And they could tell somebody else about the other one. And those are two valid Bitcoin transactions. Whereas with Namecoin, it always goes in the coin-based transaction, and there's only one of those. So don't believe the hype about signing things and putting that into a Bitcoin transaction. If it's not merged mined, it's basically not going to work. But it's kind of cool because Namecoin is, nobody's doing an ICO on that. It's basically dead. And yet, it actually works for this. So Cryptpad features, future ideas. Yeah, this Namecoin thing, I don't think we're probably going to do it for Cryptpad. It's cool. It's nerdy. But I don't think we need anything that strong. And somebody should write a paper on this. This would be really kind of neat. Especially since one thing is cool about it and it's also a thing that will make it less likely to get actually implemented is that nobody can make an ICO and try to make a million dollars selling you shitcoins. So I like that space. Anyway, Cryptpad futures. So we have four different apps right now, four or five different apps. They're all basically hard-coded because we've done everything in a rush. We would like it to be like an app store where you can just write your own app with an API and an SDK. And because the app is running inside of a sandbox iframe, it should be pretty safe and that the app's not going to eat your keys. Better permissions. So all the permissions in Cryptpad are cryptographically enforced. And so we have really, really simple permissions. You just share the link and that person gets irrevocable access to the pad because, well, that's how keys work. We want to do better permissions. We want to do really cool permissions. But we also want to keep to the cryptographic standard that the server is not really trusted for anything. So that's an interesting research problem. Solve group key management. The Matrix guys are doing that. I'm interested in it. I'm not sure I really want to do it. I know it's going to be a pain. Encrypted chat is broken for multi-user. And that's for a really good reason. It would be interesting to solve, but we need a research grant. Encrypted at rest email. That's kind of an interesting idea. There's a lot of idea of encrypting email end to end. But just when the email server receives it, just encrypt it when it receives it. And then you have to decrypt it in the web app. That is something that if your threat model is that somebody will hack into the web server and dump all the mail, that could be useful. And my personal favorite is I want to use this sort of as a pock to start the ball rolling on this idea that we can write web apps where the server doesn't really know anything. And how much time do I have? Five? OK. I can open this up to Q&A. I can also do a little demo. I've already done a little demo. And I have stickers, but not very many. So yeah. So I've made little blocks of 15 stickers each. You just start them passing along. Yeah, something like that. Sorry, there aren't enough stickers for everybody. I have also some old stickers that are what we used to have way back in the old days. And you can ask me afterwards if you would like one of those. Any questions about anything at all except the nose? Just tell me. I'll repeat it back. Yes, sir? Handle the sources for cryptography. OK. You may not have access to the phantom from JavaScript. It's the first question. And second part, how do you handle memory loading? You need to look memory where keys or user password is stored because if this memory is not locked, it may be accidentally sold out and went to disk and unencrypted from JavaScript. So the questions were, number one, how do we access randomness? And the answer to that is for accessing randomness, there's this HTML5 stuff where they just added a whole bunch of crap to the browsers. And one of the things they added was a secure random generator. And the second question was, how do we prevent our memory from getting swapped out? And then you have keys in swap space on your computer. And it's a legitimate problem. But we're just trying to be better than Google Docs, where they just sniff up all your data. And if a key that you're using in your browser gets put into swap memory on your desktop, if your threat model is that it's a mean corporation and they read all your data, well, we've solved that problem. And if your threat model is that you are self-hosting a server and a hacker gets into it and dumps all the data, we've also solved that problem. Because then the hacker has to go around to all the laptops and grab all the keys out of the swap space. OK, thank you. Yes, sir? It's encrypted using, so this is the opportunity to talk about the key algorithm. Salsa 20, Poly 1305 for all the symmetrical. So it's a stream cipher. And we have per message nonces, if I recall correctly. Basically, you can do a lot of, it just depends on how big the nonces. So I think we're doing 24 byte nonces because we can't be bothered to change the tweetNACL box function. Yeah, we use tweetNACL.js. And the asymmetrical encryption, which we use for a few strange things, of course, is also, it's curved25519 and ed259. Is there a cryptpad browser for accessing cryptpad? Oh, what's the best browser? Unfortunately, yeah, Chrome is really fast. Chrome JavaScript execution is just really, really, really fast. And it's so hard to compete with that. I love Firefox. I mean, I appreciate what they're doing. They're keeping the web open. But it's fast. Firefox Quantum. Actually, a really interesting story about Quantum. They hit out of regression. I just opened the bug. Basically, in Quantum, the cross-domain iframe that has an animated loading screen. I can show you the loading screen. It's that spinner. That loading screen, that animation, it's just hidden. And it never actually goes away. And in Quantum, they continue to render that, even though it's hidden, because it's in a cross-domain iframe. And right after they applied the Spectre meltdown patches, they moved that into another process, I think. And then that animation started to consume like mega CPU. Next question? Yeah, go ahead. Let me see if I understand you properly. Can we protect against rogue extensions? Oh, yeah, yeah, yeah. So you install an extension that puts pictures of cats on your browser. And in fact, it also leaks your keys. No, we've got no answer for that, because extensions just have more permission than we do. Yeah, yeah, keys go in local storage on krippad.fr. So I'll show you what it looks like here in Spectre Element. So up to the top, so this is krippad.fr. And then inside of krippad.fr, there's an iframe. And I don't know if you can see that easily, but the iframe is on sandbox.krippad.info. So almost all of the code that's running is running over here inside of an iframe. And that was a hack which we used to sandbox all this stuff. And we were able to use it because they invented that for being able to make ads that jump around on your screen, but they're contained inside of an iframe. So they built that, and it works really well, because they needed to for ads. And then we stole it. Yeah, how do we message between the iframe and the outside? Another HTML5 thing, they added this thing called post message. And you can just send messages back and forth. It's all asynchronous, so we have protocols and protocols and protocols for all the different things that communicate with each other. We've gotten really good at writing RPCs. OK, who wants to be the last question? Yes, sir. It's multi-user real-time editing. That was the question. I wanted to repeat it back because you know. All right, thank you very much, everybody. If you didn't get a sticker and you want one, I still have some of the old legacy stickers. Just talk to me after, and I can hook you up.