Jacob Hoffman-Andrews: Yeah, you’re definitely right, it’s a lot of work. I’ll go through a bunch of the stuff, and I should clarify a lot of this is not done by me. There’s a whole team that spent a lot of work doing this.

To be a certificate authority doesn’t mean much. You could become a certificate authority today. You can create a CA certificate on your own machine and issue your own certs, but nobody would trust them. If you loaded that on a web page, people would get a warning when they reached it. So you need your root CA certificate to be in trust stores. That’s in operating systems, or browsers, or things like Java; on Linux there’s usually a package called CA Certificates that ships down a bunch of these trust anchors.

[\00:24:10.08\] The problem is even if you were to convince all of those (we call them) root programs - the programs that manage who gets to be a CA and who doesn’t - even if you convince them all simultaneously to let you in today, there’s all the older software that doesn’t yet trust your root CA certificate. The usual way around this is what’s called cross-signing. You get somebody who’s already a CA to sign your root CA certificate or an intermediate, and essentially vouch for you and say “This organization knows how to safely issue certificates and based on our existing presence in these root stores, certificates from them should be trusted.” That’s step one - finding somebody to cross-sign for you.

Let’s Encrypt was very lucky to find IdenTrust, who was willing to cross-sign for us. Even if you are running an operating system that was built years before Let’s Encrypt existed, your browser will still load Let’s Encrypt certificates successfully because of that cross-signature. Now, in order to get that cross signature, you have to meet a certain number of requirements and pass a certain number of audits.

First, obviously, you have to generate your keys and your certs; you wanna generate those keys in an HSM (Hardware Security Module). The whole point of a hardware security module is to store crypto keys in a way such that even if somebody hacked you to bits, they still wouldn’t be able to make off with the keys; they might be able to trick your HSM into signing something incorrectly, but they wouldn’t be able to go make a copy of your private key.

So once you’ve generated those certs safely and written down all the steps you took – or rather, first you write down the steps you’re gonna take, then you follow them all on what’s called a “key ceremony”. You do it all on video, and you have auditors check that you did it all [unintelligible 00:26:20.26]

Evan Weaver: Not everybody. Obviously, a lot of Fauna’s features were inspired by things that we wanted to have at Twitter, and we’re forced to develop and forgo on our own. Fauna is really design for the modern web 2.0+ application world. With SaaS, in particular - I would say the majority of our customers are building some kind of SaaS app, with a business purpose. Or consumer-oriented applications. And then I think that the third category, which somewhat overlaps with the first, or blockchain-adjacent applications, things that use crypto for public transactional purposes, but also store additional data for application purposes.

The thing that these all have in common is that – you know, there’s a wide variety of customers and people interacting with datasets that interact with it in a soft, real-time way; they interact with it from the web, from mobile applications… You know, it’s all the apps you use today.

What we don’t do is analytics. We’re not a olap database, we’re not a data warehouse. We’re not a cache for some other database. The transactional consistency does have a cost in throughput and latency, so if all you want is a cache, you should go get memcache or something like that. We’re not an information retrieval system; we don’t replace Elasticsearch. We’re not a queue. You can go get Kafka or something else like that for those purposes. It’s really sort of the dream of MySQL, like - we wanna be to the serverless era, and JAMstack, and kind of the API infrastructure era the same way MySQL was to the web 1.0 era, where this is a general-purpose operational data platform. It’s very easy to use, it’s very easy to adopt… No startup costs, develop on your laptop. It does a very good job; I mean, we can argue about whether MySQL did a good job, but it was a better job than others at the time, because it existed. It does a very good job at that core, short request transactional user data, mission-critical data, constrained indexed use cases… And then it does a decent job at everything else you need to build a fully-featured application, so that you can get started without having to have a whole bunch of tools all mixed up in your tool chain.

We fundamentally don’t really believe in the classic polyglot persistence attitude where you pick the best tool for every single kind of query pattern you might have in your app. Databases are heavy pieces of infrastructure. It’s hard to move data around. You don’t wanna have too many of them. So the more general-purpose that it can be, the less you have to use. We do have an advantage in the cloud though, that we can connect and integrate more easily with adjacent systems in a way that takes the integration burden off the user. So that’s one of the things we’re working on going forward, making it seamless to link up to the analytics database you wanna use, the queue you wanna use, and that kind of thing.

Rob Barnes: I think there’s a there’s a couple of things there. Obviously, the first thing we talked about is the whole encrypted secrets in Git. I think we’ve kind of covered that. The second thing is your cryptographic system. Essentially, this is one of the things… Implementing cryptography in your applications - it’s hard. It’s really, really hard; very, very, very hard. It’s error prone, there are loads of steps along the way where you can easily make mistakes… And I’m willing to bet that the average developer out there doesn’t want to touch cryptography, right? They’re not interested in that; they’re in fact scared of it. But from a business perspective, there are reasons to have to implement cryptography in your applications, there are laws that we have to comply with, which some of the easiest ways to comply with that is to encrypt PII, for example.

So you have this thing where, okay, there’s data, you need to protect that data in transit, and in rest. So we are probably talking about encryption. You have the process of encrypting that. That can come from within your application. And then you have the key part of cryptography - so how do you store and manage the keys? Again, another difficult problem to solve.

The ideal solution for a developer is to offset all the complexity and the responsibility of that to something else… Which is one of the things I love about Vault, right? That’s one of the things that you can delegate that responsibility, too. As an application developer, all I need to do is tell it the name of a key in Vault - a payment key, or something like that - and I’m presented with a simple API. I make API calls, so I can encrypt data, I can decrypt data according to my permissions. So f this application is only supposed to encrypt data, then that’s all that’s all it will be able to do.

Now, in terms of rotating a key, that’s the other nice thing - you can build in automation where let’s just say your organization says “Every 30 days cryptographic keys needs to be rotated.” That’s fine. You can rotate it in Vault. And the data that is encrypted with the old version of the key - you can easily rewrap it, you can even specify the version of the key, so you’re not going to have any specific downtime in terms of that. You can just point it to the older version until you rewrap the data, you can build automation for that to rewrap it as well, and then it will always have kind of the new ciphertext, which is encrypted according to the new version of the key.

From a developer’s perspective - they don’t even care about all of that stuff. They don’t need to. From an ops perspective, I’d say it’s minimal effort to kind of build in automation first, because a lot of the hard work is already done within Vault. You just kind of need to point it to where your data is stored and just do the rewrapping operation.

But that’s the key thing… So when we’re talking about how this leak happened. Cool. It was encrypted and stored in source control management. I understand that. But then the second part of problem was it probably wasn’t a robust enough cryptographic implementation, which is quite common if you don’t offset it to a proven system that takes care of that for you.

[38:09] So I don’t want to sound like I’m a salesperson for Vault, because that’s exactly what I’m not. I’m an advocate for developers. So if you’re a developer and you are listening to this, I understand your frustrations, I understand the pain that you’re going through, and I’m telling you, you don’t need to go through that pain; just offset it to a system. That’s what you have to tell your technical decision makers, is choose a system that gives you encryption as a service.

Salvatore Sanfilippo: Actually, thank you for using it, because if you think at Redis, even if it compiles certain ideas in new ways, they are all old ideas. So I believe that software is mainly a platform for people to communicate concepts. And without a community – Redis was so resilient; it lasted so much time because the community created a mental framework about fixing problems with such tools that are inside Redis. So basically, the community is Redis, in some way.

And the way it started was because – my first days as a programmer were all about security. I worked in security for a couple of years. Then what happened in security is what is happening right now to software. It started to be cool, it started to be business, a lot of business. And security was no longer research, it was a product. And I grown immediately tired of this industry, so I started to write embedded systems.

[00:07:52.07] And then I started to get a bigger project, because I was in a very bad situation in my life. I had struggles with my relationships, I had a son that was like three years ago, and I was - I could say depressed, but it’s impossible for me to get depressed physiologically, because the kind of attitude I have in general. But I was low in my life, and I needed a project to focus my energies.

So the first weeks I just watched Star Trek Voyager nonstop, and South Park… And then I started to work to an interpreter for the Tcl programming language, for embedded systems. And much of this code was the foundation to make Redis one year later.

So basically, with this interpreter, which was not just a toy interpreter, it was compatible with all the Tcl programming language set, extended it in many ways… It added continuations and other stuff, and was in some way, in some things even faster, and so forth. Finally, it clicked something in my mind about how to design bigger systems. But then I forgot about this, and since I had no money, I remember that in this period in my life, I often looked under in my car to see if maybe one, two euros was around. And then I asked even for money to the girlfriend I had at the time. So I said, “Okay, that’s not possible. I need to do something.” And so a friend of mine [unintelligible 00:09:47.11] went and said “Do you want to collaborate? Let’s do something together.” And this was the start of Web 2.0 in the United States. But in Italy, there was still – what was Alta Vista, basically, in the U.S. So these portals, static portals, no user generated content. So we said, “Probably if we just copy what they are doing, we will have an edge.”

And we created two services. One was exactly like Delicious, and another one was an improved Digg, much more like Reddit now, basically. So there was complex moderation, there was a Tcl program that did the advanced filtering in order to avoid friends voting themselves. And this became popular in Italy, and so Telecom Italia, which is the biggest ISP here in Italy, a telephone company, called us. They didn’t know in any way us. They called and said, “Why you don’t join the Telecom Italia network with your services?” [unintelligible 00:11:01.01]

I remember when we went in Milan I was dressed so badly that they didn’t want to let me at the hotel in. They’re like “Are you sure that you have a reservation in this hotel?” I said, “Call this number.” They said “Okay, you can enter.” Because we were underground people. In Palermo we had Linux systems with cables in order to pay, and we had illegal greens to connect to the telephone to internet… We did this kind of thing, so this was our mood. They were business people, so there was a cultural gap, in some way.

And so we entered the network, and from one day to the other, we had to sustain the traffic of a lot of users, all the Italy connected. And our systems were not ready. So the first thing that I did was in PHP - the system was written in PHP - to write a memoization function that basically whatever you could call inside this function, the return value was stored, serialized into some kind of BTree that I created on the disk.

[00:12:22.15] And this way we had some kind of cache in order to avoid stressing MySQL too much. And this worked the first weeks, but then we created a new service that was a real-time log analyzer, and the use case was not static caching. You know, till this point I didn’t know even that Memcached existed. So I could not use it, just because of the lack of knowledge of existence.

But even if I had Memcached, that was not enough for me, because I needed a cache with data structure where I could add items and remove all the items. So I took Tcl and wrote a prototype, and they tested it, and it worked so well. And they said, “Okay, that’s good, but it’s not a scripting language thing. I want an actual daemon in the ground, with a low memory footprint.” And especially, I realized that I wanted a fork in order to persist on disk with the other child.

And since I in the past had background in security and low-level programming for cryptography, I studied the very in-depth the Stevens books, all the system call of Unix, the implementation of small Unix systems like Minix, provided a few patches to the TCP/IP stack of Linux… So I was a very low-level already, and I realized that with fork - this is an interesting story, because fork, after 15 years, still is the best way to do the Redis thing from the point of view of persistence; this magical thing of copy and write of the kernel pages. So this fundamental idea back then survived to these days.

And so I started to write this Redis thing, and it took me two weeks to have the basic core in order to apply it in our system. And since I had a long story of releasing open source software, [unintelligible 00:14:34.05] device drivers for the Canon cameras, web log analyzers, many projects that were in Debian and in other Linux distributions, I said “You know what? If I release Redis, this will not impact in any way our business”, because the other application was closed source. So I released it on Hacker News, because Hacker News was very new when I released Redis in Hacker News… There were like 10 upvotes, a few people commented, but basically nobody cared at all. But Ezra Mobius…

Roland Shoemaker: But this has been a problem for a long time, especially for people who use Docker… Because if you build a very lightweight Docker image, often you will not end up with a root store. And when you try and write a Go program, and you drop it into your Docker image, your lightweight Docker image, and then you try and connect to a web server that uses TLS, all of a sudden you’re getting all these failures, and it’s kind of confusing why. So in 1.21 I think we added a new API that allowed you to register a default set of root certificates to trust. So if you don’t get anything from the system, you will get this special extra bundle of certificates that you will fall back on. And this has, I think, solved a problem for a lot of people, but maybe introduced new problems for us, in that we now have to also provide a bundle of certificates… Which we have done as a separate module in the golang.org X crypto module. It’s a special sub-module, which provides the Mozilla bundle of certificates.

Feross Aboukhadijeh: Yeah. I mean, take what we’re doing with Wormhole - we were looking for this; we had Dependabot installed, and Dependabot will go ahead and send us a pull request if we have a vulnerability in our project, and we would update that and get that out as quickly as we could… And that’s a great thing to do. But the thing we were specifically worried about was the kind of attack that would target Wormhole specifically, or one of these supply chain attacks that would just start doing random things on our server, like mining cryptocurrency, or talking to random servers.

You know, there was that eslint-scope bug - that was another attack that happened, where the malware actually stole your npmrc file, and it could publish packages as you… The list goes on. The things that can go wrong… It’s like, you have this small probability of a really bad thing happening, because when you run npm install, you’re basically just trusting that the code is gonna do what it says. And running this on your laptop, with all your personal files, your photos, all your documents, your social security number - all that stuff is on there. And then you’re running it on your product server with all your user data; now, in the case of Wormhole we didn’t store any user data, but our app needed to be secure, to not serve compromised JavaScript code down to our visitors. So that was our concern, that was what we were worried about. And once Wormhole got popular and we started getting over 100,000 people using it every month, and we started looking at the really basic statistics that we gather about the users, we saw a third of our visitors come from China, and they’re using it to send files there securely…

So then I started to get pretty worried. I was like – you know, we’re not the biggest fish in the pond, but there is a chance that we could be the target of state-sponsored attackers who wanna know what’s going on in those files… So it seemed like a thing that we should at least have a plan for how we’re gonna deal with our dependencies, and how we’re gonna vet these things… And when we looked around for tools for this, basically I didn’t find anything. One option is I guess you could check in your dependencies into your repo… But then you’re still not gonna be vetting them. I think basically what everybody does is they just kind of hope for the best, and they don’t look at their code.

Feross Aboukhadijeh: Yeah, that is the part I wish I could give you a better answer for right now… Okay, here’s the thing - I’ve open sourced everything I’ve ever worked on in my entire life, basically. It’s all on my GitHub. And with this project, we wanted to make sure that it could be sustainable from the beginning… Because you know, when you’re hosting tons of files - we’re paying bills to Backblaze for this stuff, we’re paying for servers… And if we grow it to be ten times bigger, that’s gonna start to be a really meaningful amount of money that we’re paying to host the service. So we need to find some way to charge for something in order for this to be sustainable. So we’re working on a pro plan right now that you’ll be able to pay for, that’ll give you extra features, like larger files, customizable expiration times, so you could change it to be like seven days, or a month, instead of just 24 hours… Stuff like that. And eventually, we’ll have maybe the Drive features as well, and then you’ll be able to store all your files, forever.

[01:04:02.20] I’m just not sure yet if open sourcing it would somehow be a problem for the business. I don’t want someone to just make a clone of it and then say – I don’t know, it somehow causes the whole thing to not make sense, and then we have to stop working on it… So it’s just at this stage where – you know, you can’t un-open source something, so just erring on the side of… I open source the cryptography code so that the security community could take a look at it and make sure that there’s no flaws… And we have a bug bounty program for that. So if you find any problems, you can make up to $1,000 finding bugs in that. And same thing with the Wormhole website itself - if you identify vulnerabilities in the Wormhole website, you can also make $1,000.

So that’s the place we’re at now. I honestly think we might end up just open sourcing it, it’s just that I just wanted to be a little bit thoughtful about it and not just do it that way from day one… I hope that makes sense. I just really wanna make sure that it’s a thing that we can keep doing going forward and not have this be like some kind of strategic mistake from –

Alexander Neumann: This deduplication thing was built into Restic right from the beginning, because at first I thought “Oh, I’d like to have a backup program”, and then I started thinking about it and discussing with my colleagues what should a backup program do, and one of the things that you have in a backup program - you have duplicate data. Either you have the same file at different times - sometimes files haven’t been modified, so you have exactly the same data and that’s really easy to handle, but sometimes you have virtual machine images of like 100 gigabytes and you just have changed one or two bytes within the whole image, and it would be really a shame to store this 100 gigabytes twice, because most of the data is exactly the same.

So I started looking into algorithms that try to detect changes or similarities in data, and one of the ideas that have been built into this is this really old tool called rsync. There’s a PhD thesis by somebody called Andrew, I think… I’ve forgotten the name.

rsync does really interesting things. For example, when you try to copy a file to a remote server, then on the local site they have some process that opens the files, starts reading and sending to the remote site. If this is cancelled for some reason - for example, you cancel the program locally or your internet connection breaks down… Afterwards you restart this process and rsync will detect that there is some part of the file already on the remote side, it will open it and it will find where it left off on the previous run.

This is the easy part, but what happens when the file on the remote side was modified and you would like to make it pristine again and copy the original file over to the remote side again? You can just delete the remote file and start transferring again, but that’s not very efficient. rsync cuts the file into different blobs and detects which blobs need to be transferred. For example, if you just changed one byte because of a hardware error on the HDD or something like that, then you just need to detect which of the blobs changed. For example, the first blob, the first 1,000 bytes or so - rsync will detect that and will transfer this small amount of data and reconstruct the file on the remote side.

The algorithm that it uses is called a rolling hash sum. It starts by reading the file and taking all the subsets of 32 bytes from the file, and for each of these 32 bytes it computes a hash. When this hash has some property, for example the lower bits are set to zero, then it says “Oh, I’ve found a block boundary!”, and afterwards is uses a real hash function, a cryptography hash function - I think it uses MD5, or something like that - to detect if the content of the blob has been changed.

So you could have also kept the file into 1 kilobyte pieces, but then the problem is you cannot detect when one byte has been inserted at the beginning, because all your blob boundaries are wrong. And when you have these dynamically-sized blobs, then you can detect “Oh, there has been a byte inserted; the first blob is different, but all the other blob markers at the end of the file are completely the same again.” This is really efficient to dynamically slice the file into blobs, and this is what Restic does.

The problem with the algorithm that `rsync’ does is that it is targeted at really small blobs, for example 100 bytes or 5,000 bytes, and in a backup program we don’t deal so much with inter-file duplication, but with intra-file duplication. We have some files that are not exactly the same, but mostly the same. So it’s a good idea to have larger blobs, because when you have a snapshot that I’m doing of my directory now, and two days from now most of the files will be exactly the same and some will be modified, but most of the data will probably be exactly the same, so it makes sense to reduce the number of blobs that you need to handle and have larger blobs.

Restic at the moment is configured to try to have one megabyte of data as one blob, and this was just not possible with the algorithm that rsync uses. So I looked at an algorithm called Rabin fingerprinting. It’s a really old idea by a mathematician called Rabin from the ’80s, and I read the original paper and it was a typeset with a typewriter, and I think the formulas were manually inserted and painted in there, something like that. I tried to understand the math behind it and then implemented it in Go.

Alexander Neumann: Everything in a Restic repository, besides the really tiny bits of data, is completely encrypted. As I said in the beginning, when you initialize a repository, you have to supply a password, and this password is not optional. You have to supply some kind of password, and it uses strong cryptography and stores everything encrypted. So all these data chunks that I talked about earlier, and all the metadata - it’s all encrypted. There is almost nothing that’s not encrypted in a Restic repository. So the security is very important to me personally there.

Yaron Schneider: We have huge plans. We’ve recently added workflows, which is really nice… So a workflow as code type of programming model where you can tell your code “Hey, sleep for 100 years and then kick off this process”, and that’ll be reliable and secure. And we’re adding cryptography APIs, blob streaming APIs, document store APIs, SQL APIs… There’s a whole world of APIs getting added to Dapr. We have eight today, and we’re going strong on 12, I want to say, in the next year.

André Staltz: Yeah… Also, the active backing up is annoying. It’s just a thing that you do in case things go bad… But just the day-to-day use of Scuttlebutt is backup, so you don’t have to ever think like “Oh yeah, I have to back up my Scuttlebutt”, it’s just keep on using it and have some friends that use it as well.

This has actually happened… A couple of have – let’s say their computer has died, or something… They just need to have their private key stored somewhere, and we’re investigating ways how we can store that nicely. One of them is just by having a big seed, sort of like twelve words that you write down or memorize, and that’s enough to recover your account or your private and public key.

There’s different ways of backing that up. Another one would be also through your friends, which is essentially splitting your crypto identity into (let’s say) five parts, and then giving one part to each close friend. Then once you wanna recover your private and public key, then you just ask three of those five, some kind of quorum of your friends, and then they get together and they can restore your account. So you could literally have no passwords; it would be enough to just have your friends.

Perry Mitchell: Exactly. And there’s also various other values which are stored with the vault, such as a HMAC, which is authentication… It’s basically to ensure that the vault hasn’t been tampered with, which is another common crypto technique. So after your password is hashed, we also derive this HMAC, which is just another type of key, and we compare the two, and basically make sure that the vault hasn’t been tampered with - there’s no modification to the data before that payload is decrypted. There’s a number of techniques we use there just to make sure that the vault is clear, not corrupted, not modified… And then, of course, we attempt to decrypt it. If the password is wrong, the decryption will fail, of course, but not after taking a substantial amount of time to derive the key… So obviously, you have to wait x hundred milliseconds for the key to be derived, which should hopefully prevent a huge, large number of attacks per second.

Autumn Nash: So mine is YubiKeys cryptographic flaw let attackers clone devices by extracting private keys. So some security researchers were testing the YubiKeys and looking for vulnerabilities, and apparently the YubiKeys series 5 has a vulnerability that lets you clone the device and extract the keys stored, which is like, how many huge enterprises do use YubiKeys? That is a wild. And it’s a side channel exploitation, which is just… Wow. This is such an interesting way to – you’re using a YubiKey to be more secure, and then there’s such a huge vulnerability in the YubiKey, which just shows that we keep getting better, and then there’s new ways to do crazy security things.

Ben Burkert: Yeah, the CLI tool itself is open source. It’s on our GitHub org page anchor.dev/cli. We use a dry version of mkcert, an awesome dev tool built by Filippo, who is on the Go security team. It’s kind of the standard de facto way to interact with trust stores, and we use that – we hope to contribute to it in the future, and… Yeah, it’s awesome software.

The SaaS version of Anchor, the certificate issuing parts of Anchor - that’s close to our SaaS product. But we do publish a lot of usable Acme clients that you can use in your code. For example, we helped write Puma. Puma is a Ruby web server for your Rails app. We wrote an Acme client so that Puma can use Acme to provision a certificate on boot. And a couple other languages… JavaScript… Go actually already has great Acme support. There’s the built-in, kind of blessed x/crypto package. It has an Acme package and an Autocert package. Autocert’s a great little package. There’s also the Caddy team, and Matt has written another great Acme client - I forget the name of that one, but that one’s even better. It’s got better features, and stuff. So Go has great Acme support out of the box, but we’ve been trying to bring Go’s level of quality Acme to other languages, and those are open source and on our GitHub repo as well.

Paul Vixie: Well, fortunately, quantum computing is always 10 years out. If that changes, and we end up needing to have post quantum crypto, so that it remains impossible to factor large numbers and it remains impossible to store and decrypt information, then we’re gonna have a problem. Because we’ll be trying to move toward a type of crypto that simply won’t fit UDP. And we will get fragmentation as a backstop; it’s just going to happen to TCP, with everything. So that means there’s a tipping point. If we get close enough to real quantum computing, to where we need post quantum crypto, we’re just going to be using TCP for all DNS, except for the part that doesn’t get the memo, and therefore does not switch, and therefore doesn’t work, or doesn’t adopt post quantum crypto at all. And I don’t mean to sound like this will be an emergency for the world. y2k was not an emergency for the world. It was just kind of a big deal, and in the newspapers. But there’s always going to be something like this. It’s only in the case of the internet that we do it to ourselves.

Jeronimo Irazabal: [24:01] Yes. Before giving the explanation how I ended up here… But actually using immudb for an application developer is exactly the same as using a traditional database. You can download the immudb binary or local container, and you will use any other key-value store, or SQL database as well.

So before I joined Codenotary, I was working as a software engineer for IBM, and the last projects were related to digital rights management, and that was related to applied cryptography there for generating the crypto materials… And also, I was a contributor for Hyperledger Fabric. By then also I worked also in an experimental project where we added SQL to Hyperledger Fabric. We added SQL support into the changelogs, actually in the smart contracts. But by then, I was convinced that the complexity of the project was quite big. There were many companies or organizations willing to use blockchain just to be sure or to prove themselves or to their clients that the data was not changed. But then they had to run a very complex system, so I always thought about the possibility to have just a traditional database with the verification possibilities. So to have the same verification capabilities like a blockchain provided, but thinking of singular organizations being the owners of the data, but yet to fulfill with auditory requirements or to prove to their clients that the data has not been changed.

So by then I just started to think about this type of systems, and I got to know about the company and the initial release of immudb. By then, immudb was implemented relying on another key-value store that was written in Go. So that’s where I just started to work,

And related to immutability, I think tampering detection is one of the types of verifications we can do, but there are many other things that are to be included, like what is the latest record that was modified, being able to verify when you are dealing with higher-level data models, like SQL… If you have a database and you have a document like a data model, and you have queries, and you have to verify them. So there is a lot of things to investigate, to explore, and of course, to implement.

Jerod Santo: For the sake of conversation, let me play the bear for a minute with you, Alan, because as you said, internally it was not unanimous, so no doubt you had interesting conversations with your colleagues and leadership at Wire around this. One of the major points brought up by people who were skeptical of open sourcing - I think it’s a legitimate skepticism with regard to rip-offs. Rip-offs happen, and the more successful you are, the more they can happen.

In fact, just recently I was reading about a cryptocoin wallet called Coinomi, which I think is an Android-only thing now, and I was just reading about their history a little bit (these things interest me) and they were open source, I think it was GPL-ed even, and their Android application was all open source, on GitHub, and they were doing it all in the open… Which makes a lot of sense for a crypto wallet as well, because talk about you wanted to know what the coin is doing… Similar to an encryption type of a secure chat, you wanna know what’s going on under the hood, so it made sense for them to be open source. Well, what happened was other people who were being very capitalistic, decided they were going to just take that code, rename it, rebrand it, and put it on the Android Store.

This is not an isolated incident, we see this happening over and over. The Coinomi folks stopped open sourcing, they decided it wasn’t worth it for them anymore; I believe that repo is still on GitHub, but it hasn’t been updated in a few years, and they’ve marked it as inactive, so they’ve continued to develop the codebase closed, because they had these problems.

Was this a potential reason not to open source discussed at Wire? Because surely, if everything you do is in the open, somebody could just take all of your code and all that you’re doing and rebrand it and compete with you.

Alex Sexton: Yeah, so PCI determines all of the algorithms for how you must store credit card numbers and things like that. I have a pretty good guess on what it is, but I’m not even credentialed enough to touch or look at any of that code as an early employee at Stripe. That’s another one of the security precautions that PCI mandates. It is mandated by a body, but as far as all of this auth goes, I feel like maybe my security brain is coming out a little bit… The way that your password gets hacked is not hashing algorithm collisions currently.

This one’s bad - I don’t think too many people are using SHA1. Even if you use HMAC or SHA1 it’s fine. There’s even ways to make SHA1 fine, but use bcrypt to do passwords… Actually, my number one recommendation is don’t implement any security stuff yourself. Use libraries that are well known and well tested. The number one rule at Stripe is don’t implement your own crypto; don’t invent your own crypto, because you have not thought it through correctly. That’s my advice.

Tess Rinearson: Yeah, totally. Or an onion that’s too small, or a carrot that has two legs, or all these things that make something inappropriate for a grocery store, but they’re still totally edible and delicious. I kind of got into this when I was living - this is also a cliché - in Berkeley, and my roommate in Berkeley has a food startup, and he’d bring home these big boxes of these “ugly” vegetables. So I was like, “Okay, great. I’m gonna sign up for this”, but they only deliver between midnight and six in the morning, and I live in a part of San Francisco where if someone leaves a box of vegetables on the steps outside the apartment building, it will be gone in like 15 minutes.

So the solution that the company suggests is that you give - this is turning into a very long backstory - a key to your building to them. And I was like “Yeah, I work at crypto… I don’t feel good giving a key that I can’t rotate to some company.” So I was like “Oh, I know… I will write a code into my callbox app”, so that if someone comes up, dials a number and then puts in the code within ten seconds, the Twilio app plays back a dial tone that I found online that matches the right, you’re supposed to press nine, so it plays the tone for nine back to the buzzer, and the buzzer unlocks the door. So I can get deliveries in the middle of the night without getting woken up.

This will be a problem when the person delivering the vegetables does not enter the code in time and then I get a phone call anyway. But until that happens, that’s my grand plan. So that’s what I’ve been doodling around with lately.

Anna Pobletts: Yeah. So behind the scenes, we’re using public key cryptography; protocols that have been around, algorithms that have been around for decades, even very well-established protocols, just being used in a new way. So what happens is when you go to sign into a website, or sign up for a website for the first time, your device or wherever you’re storing your passkeys - I’m sure we’ll talk about this later, but you can also store passkeys in 1Password… Wherever you’re storing those passkeys, you will create a public/private key pair, and you’ll store that private key in your provider on your device, and it’s never going to leave. So it’s never sent to the website. Instead, you’ll send this public key to the website, and that public key can then be used to verify any future logins.

So on a future login, you say “I’m Anna. I want to log into this website.” The website will send you a challenge, and you will sign that challenge with a private key. You’ll send that back to the website, and the website can verify it with the public key, and say “You’re all good, you’re authenticated.”

Now, when I say “you”, like, the user actually isn’t doing anything here. This is all happening behind the scenes, between your browser and the website and your provider, your device, or your 1Password account, something that. So it’s all really transparent to the user. All you’re doing is essentially proving to the device that you own that device by doing your touch ID, your face ID. And then that’s granting your private key access to sign that challenge. And so it looks super-transparent. It looks you’re just doing Touch ID, but behind the scenes there’s all this cool cryptography going on.

Raul Jordan: Definitely. I think Preston and I consider ourselves pretty pragmatic engineers, so when we first started on this journey, we were just excited by this concept of having this global computation platform that anyone can use. It was like “Wow, it’s so cool, the things that this can enable for the world.” And of course, blockchain cryptocurrency has had quite a negative reputation on a lot of fronts, especially because there have been a lot of nefarious use cases for the technology. And you can say that about any sort of new technology.

Why we got excited about Ethereum is because Bitcoin was, of course, the first blockchain, the original blockchain, and it serves its use case as basically a store of value; basically, the predominant narrative is that Bitcoin is like this digital gold. But on Bitcoin, interestingly enough, you can’t really run code, or run these decentralized applications that are Turing-complete. You can’t write a custom piece of software that basically can do whatever you want. Ethereum is the first blockchain actually that allows for these decentralized applications, for basically decentralized computation of software; and to us, that was really cool.

Ethereum has the most network effect, has the most developers, the most people building on it; it’s not controlled by a single company or a single person. People say it has a soul… It’s basically community-owned, and that to us is really awesome. That’s kind of like why we got into it.