Security Cryptography Whatever
Security Cryptography Whatever
Holiday Call-in Spectacular!
Happy New Year! Feliz Navidad! Merry Yule! Happy Hannukah! Pour one out for the log4j incident responders!
We did a call-in episode on Twitter Spaces and recorded it, so that's why the audio sounds different. We talked about BLOCKCHAIN/Web3 (blech), testing, post-quantum crypto, client certificates, ssh client certificates, threshold cryptography, U2F/WebAuthn, car fob attacks, geese, and more!
Transcript:
https://securitycryptographywhatever.com/2021/12/21/holiday-call-in-spectacular/
Find us at:
https://twitter.com/scwpod
https://twitter.com/durumcrustulum
https://twitter.com/tqbf
https://twitter.com/davidcadrian
"Security Cryptography Whatever" is hosted by Deirdre Connolly (@durumcrustulum), Thomas Ptacek (@tqbf), and David Adrian (@davidcadrian)
Crypto 2, Electric Boogaloo. So, I guess we can introduce ourselves because we are recording this and the people in the recording will not have the benefit of looking at the screen to see who was talking. The, my name is David. I'm hosting the space. Um, that's my claim to fame. I have with me is Thomas.
Thomas:Hi, I'm Thomas.
David:He's sorted out his mic by which, I mean, he's given up on his mic. Speaking of people who've given up on their mic, we also have Deirdre.
Deirdre:I blame Twitter on Android.
David:See, this is a punishment. So we had Justin come in here and tell us about how Pixels are actually more secure than iPhones. And we all kind of just let him say it, and Deirdre got to feel good about herself. And yeah, now that we have to use our phones to do something, suddenly me and Thomas are here having a, almost working time. And who knows what's going on in Android-land.
Deirdre:Land? It's obvious that Android is second for any new features for the Twitter dev team. They go iOS first and then maybe it shows up on Android and it's half broken and anyway, whatever.
David:Alright. So this is an hour of time in which you are wasting listening to us. I think at this point we will take audience questions, comments, and concerns. It's okay. Even if it's not a question, more of a comment, there is some feature to request talking uh, to request to speak. And I think we can just rotate through people and if no one says anything, we'll keep talking about Java. And so that should be motivation enough to request
Deirdre:to speak. Because someone nerdsniped me into signatures. So
Thomas:before we talk about like, you know, threshold signing and stuff like that, somebody should ask the question because this all good. Let's look at inscrutable real quick. If we start talking about,
Deirdre:if your, cryptography implementation is making a weird noise, please tell us about it.
David:We will just promote Matthew to speak if no one says anything.
Deirdre:Yup. Yup.
Thomas:I think we should just do that.
David:All right. Well he better be looking at his phone cause I just invited him to speak
Thomas:we're bad at call-in shows
David:Clearly.
Deirdre:Hey, it's our first one. We're we're we're doing it.
David:That's because our call-in show is actually implemented on top of a virtual machine machine inside of a compression algorithm. And so it just doesn't run very fast. Where are you just like XOR'ing clips in your fucking GIF PDF JPEG decompression thing?
Matthew:Ah, I have to figure out I've never allowed Twitter to access my microphone before I'm sitting here desperately figuring out how iOS permission settings work, but I think I've finally got it.
Thomas:You've definitely got it. You're on with us right now. What's your question, caller? All right.
Matthew:So I want to know what everyone thinks about. At least certain people in the world's favorite subject, which is client certs. I feel like they've gotten a really bad rap lately. You know, they're kind of hard to use, but they also give a lot of like, kind of nice properties where you're not just like sending a token over the wire and they're like pretty widely supported and a lot of stacks. Should I use them? Should I not? I'm afraid. Oh,
Deirdre:Thomas,
David:we actually have a whole episode about this. That's stuck in editing. Hell oh God. You're right. That hasn't been released. It hasn't been released yet. We recorded it like, I dunno, two or three months ago with Colm McCarthaigh, who probably just thinks we hate us now because we still have episodes that have been recorded after that since then. But I'll let Thomas, um, throw the first stone.
Thomas:I have an, I have an answer for this already written. Hacker news and I'm trying to find it. And then I can just read my hacker news comment. Um,
David:that's some engaging content right there. Let's all just read hacker
Thomas:news comments. I'm going to freestyle it. So I'm going to be wrong about things, but I'm, I'm always running about
David:that. Are you implying that hacker news comments are right
Thomas:about things? Well, when I write them well, when I write them, there is right as my, I, I normally I don't get more wrong when I write narratives. So, um, we, um, we use client certs for things here. I have like a general take that I think clients are to make sense for defining kind of static network industry. Like I buy the idea that that's a, like, that's workable. So for instance, um, we use, uh, we use console like the distributed KV database for service discovery. Um, we use a lot of console at fly IO and, to talk to console here, you need a client cert like we have, uh, like a mesh of plant certificates that you use to get access to. And for me, that's kind of like network topology. It's kind of just like, basically deciding who's allowed to use that link between servers and console, but we don't do, like, we don't do any, like th there's no interesting authentication happening off of the, like, off of the encoded parameters in those client certs. So the client search don't make any assertion other than like the bearer of the certificate is authorized to talk to console. So it's like a static secret that's stored on the disk on the servers, essentially. It's a bearer token. So I'm fine with it for that. Like I would try to these days, I would try to use WireGuard for that instead of using TLS for it. Just because WireGuard is so much less complicated, but like
David:that's a little orthogonal, right. Cause WireGuard has, you know, the Diffie-Hellman keys in it, but you could be doing a client certificate protocol for key distribution
Thomas:with WireGuard. Like, but the way that, the way that client certificates get— before Kubernetes hell, the way that clients should have it gets got used was essentially defining virtual links. so like they were constrained to a single application or whatever, but that's kind of how I saw them. Like you can, you can pick away at like that, that the, the analogy I'm drawing here and it's not a great analogy, but like, for like really high level, who's a lot to talk to who type stuff, like what parts of the network, what servers are allowed to talk to which servers I'm fine with them. There's like a. We wrote a long post, a long time ago about all the different ways that you can authenticate connections between like components of like a microservices architecture, or like we would call it like the interest services or the interest services
David:authentication. We didn't have interservice authentication schemes, June 12th, 2018 latacora dot micro dot blog.
Thomas:If that blog is still available. Right. So, um, we made some noise about client certificates as being a sane way of expressing authentication between your own services in that post at the time, like, I was pretty bullish on clients for that stuff. and then Colm MacCarthaigh, like, um, wrote a long string of tweets, um, about why he didn't like client certs for that kind of environment. He has some good reasons why he doesn't like them. I guess the first thing to know about that is that. If you're, I mean, Matthew, I'm sure you're obviously familiar with this. Right. But if you're familiar with how, like Amazon sees request authentication, sees during authentication between services, they authenticate requests. Right. All of their individual requests request by request are signed. and they like that for a bunch of kind of clear reasons. Right? So like gaining control over the transport, between different services, doesn't give you like naturally the ability to, you know, spoof a request or something like that, because you still need to go to assign the requests. I'm not really trusting the transport the classes, because our intrinsic, yeah, kind of transport based, right? So if you have control over the transport, if you can get the transport to issue new requests and that's what you're relying on for authentication, then the client cert, aren't helping you anymore. This is like a really obvious example of this, which is SSRF. but in general, like SSRF, like attacks, which these are places where you're tricking a service that you're talking to and to making an HTTP request for you. those requests, if they're routed over that, you know, clients, certain authenticated channel client certs aren't helping you there, right. You're able to make arbitrary requests over it. So I find that argument pretty compelling, right? Like, individually signing requests is its own bucket of worms. and there's lots of things you can get wrong in there too, but there's just kind of like a fundamental, like. You know, kind of impedance mismatch between what you're trying to do there, uh, between, you know, kind of protecting and authenticating a channel versus protecting them authenticating individual messages. And he would say, and I would agree that it's, you know, protecting the individual messages. That's what you want to protect in the first place. So that's where you should try to, you can just kind of put your energy. there's other like more tactical problems though. The biggest one is that to do client certificates, to actually implement them, you're naturally going to use a preexisting TLS library. Like nobody writes their own, it would be insane to do that. Right. And pretty much every TLS library that exists was built for the web PKI certificate model, right. With all of the assumptions that are baked into doing web PKI certificates. and so. You have, like, there are weird corner cases where, like your libraries didn't expect to do you know, the kinds of authentication that client cert authentication does. and you can wind up with, you know, accidentally authorizing things that you weren't supposed to authorize. I'll let David, you know, pick me apart a little bit more. What, like a read of the comments where I wrote more about what actually happens here. but that's like the top two things where like the library support for it, like it's just, it's, you're in a weird corner casey place for TLS. Um, but also fundamentally what you're trying to do is, um, you know, it's not a perfect fit for what you're trying to build on.
David:Thomas might be the first person in the history of the internet to be like, I need to make sure this is more accurate. Let me go read the comments of this article, but I completely agree that like client certs are, are great for authenticating, transports and bad for authenticating requests and really bad if you're using your transport to authenticate your requests. Um, so the big question is, are you in a request response system or are you in a transport system? Um, I think clients' starts are great in SSH. I think that more people should probably be using that instead of, uh, just, you know, authorized_keys files, uh, and you can do some cool stuff in that space. If you want to write a lot of code, like issue short-lived clients, certificates, certificates bound back till, um, say, an SSO and you be keep logging in on your, on your iDP. You could like generate a key on your YubiKey and then web into something and SSO into your IDP. And then that could sign your key backed on your YubiKey for, you know, like an hour or two hour long cert.
Thomas:I found it
David:and then you can sign into that.
Thomas:I found it. So I was looking for, I was looking for Colms example, right. Cause it's a good example. Right. So I remember like a little while ago when we talked about it on this, uh, on this podcast, right. Where we were talking about different token formats and I was thinking about, and we still are going to implement macaroons for fly.io And it was going around like, what libraries should we use for macaroons? And there's like a go macaroon project and a Rust macaroon project, and the macaroon standard and everyone, uh, every clueful person that I talked to hates those things. Um, and I was surprised by how much vitriol they got. Cause it's like macroon— and one of the nice things about macaroons is it's a very simple, you know, it's a very simple instruction. It's hard to mess up. Right. And the big complaint they had was the macaroons kind of as expressed in macaroon libraries, and then the standards, aren't typed. It's all just like a weird string DSL. Um, so it's like you wind up with like, you know, this asking key equals value thing that you parse and that's how you figure out, like, does this macaroon authorize me to do this other thing Colm's example for client certificates is, he was doing like X 5 0 9 stuff for a client because, at some point, and I'm like the CEO's admin assistant, like there, his secretary had like, you know, root access to absolutely everything because her email address had the string' admin,'admin assistant. And the reason that happened was because, x.509 Is so fucking complicated that, you know, after you get the, the MTLS part of it working, if you're gonna try and authorize based on things that are actually in their certificate, what you're really going to do is pull the name out of the certificate and try to parse it somehow. Like it's the most natural thing to do there. So there was like some regex, there was how they were determining whether you had admin access. Cause it's not like— that's not to say X five or nine is not typed, but it's plausibly deniabley typed, in that you could express anything you wanted to, but no one would ever do it. Right? Like you would just embed things in the string and then parse the string. So this really good example is that like the ecosystem for X five or nine, X five, and I was so janky, you don't want to, you don't want to kind of implicate any more of X.509 than you have to. Um, but it ultimately your assertions that you're making about this request, you know, You're going to express them in a string somewhere and you have to parse the string. I mean, you're going to fuck up parsing the string, which asks what that was like. Maybe not that specific example, but you are probably going to write ad hoc parsers for things that you pull out of X.509 certificates and like that also would terrify me. I'm not, I'm not against them. I'm fine with them, but I would kind of go out of my way not to use them if I had the option to. Matthew, I dunno, does that a good answer to the question? Does that not make sense to you and your opinions about this stuff? What's your opinion.
Matthew:Yeah, I mean, I think there's so many foot guns. David mentioned something really interesting, which is you brought up, SSH client certificates which I think a lot of people, don't use SSH certificates, and one of the reasons that people give for not using them is that, oh, they're like they're a special thing, they're not X.509. Right. And like, that's, you know, a lot of the foot guns are fucked, but are caused by X five or nine specifically. Right. and, and kind of SSH, has these relatively nice, relatively simple, format, I suspect is hard to fuck up. And I wonder if maybe we should just like use SSH keys for more things.
Thomas:you know, there was a, there was a point a couple of years ago when I was still a Latacora, that I had to do a design for like a cryptographically authenticated enrollment thing for an application. I was putting it together and I had never done one from scratch before. And I started using SSH certificates as kind of my reference point for them. And by the end of it, it's like, we should just use ssh certificates. They're not X 5 0 9. It's a really simple format. It seems like it's a hard format to mess up. and th they're pretty expressive, right? Like I like ssh certificates a lot. Right. And like, I think the important thing to know if you're not like a cryptography nerd is that ssh certificates have nothing whatsoever to do with, you know, TLS certificates. So those are great. Like we'll never be able to use the MTLS, but they're, they're great. We just switched over to all, all certificates, SSH access, um, at fly and it's been wonderful. Awesome.
Deirdre:With ed25519 keys, I presume.
Thomas:Yes. Yes. But also MFA access tying into our, you know, our SSO system and all that. We have an ad hoc stuff. We had, like, we had key signing and stuff that we're using from like bastion hosts and stuff like that. And pretty much all that's out the window now. And it's all just good clients for that, because I'm not so sure about it, but like, I dunno. I mean, you, you seem to think they're unfairly maligned and I think they're reasonably maligned. So I dunno, Hope
Deirdre:that helps Caller!
David:So I was notified by Adam Langley that apparently the request to speak button didn't even exist. It may or may not exist. also, I think Adam's given up on us and left.
Deirdre:Ooh,
David:hold on. But if someone can find the request to link button, the request to speak button and hit it, uh, that would be a positive confirmation that it does. In fact, exist,
Thomas:tend to be Adam Langley. We'll allow for pretend, Adam Langley.
Deirdre:I have invited, I dunno about them can hear us, but I think you need to be on a mobile device. You cannot,
David:you
Deirdre:cannot speak on browser, which
David:John requested.
Deirdre:Good.
Thomas:I see. Get a quick view of speaker requests. Approved. Cool.
Deirdre:Yay. Hi, George. Is that
Thomas:George? Hi. Hi, George you're co-hosting with us now. That's that's great. You made me install Twitter just for this.
David:It could be worse. We could have made you install clubhouse.
Deirdre:Hello, caller. What's your question?
David:Who was that? That was addressed to you, George. Now that was me accidentally hitting, um, the, the wine glass. I was drinking last night with the beer glass. I'm drinking now.
George:Uh, great. Yeah, I actually do. Thomas something you were just saying is highly relevant to my interests. Did you say that fly actually uses like an SSH CA and like mint certificates for internal service auth?
David:Wait for service auth or for SSH auth?
Thomas:Yeah, no, for us SSH auth, we don't do inter service authentication with SSH. We don't have SSH channels between we use, um, most of our serious inter service auth at fly is done with IPV6 and BPF code. so w our, our general strategy is we, we try to create a platform where we can trust source IP addresses by locking them down and then controlling the entire network. So generally, if we're going to make them like it's within the next month or two, it's going to be a combination of that, that, like, you know, these kinds of special semantically encoded IPV6 addresses, and macaroons is kind of where we're going. but we use SSH to like, you know, do deployment infrastructure work all the time, and that stuff now is all, you know, certificate-based.
George:Okay. Cool. I just, I, uh, I don't think I've ever encountered anyone, like, really leaning into that. so I assume you will write it up or something at some point.
Thomas:You're talking about SSH certificates or you're talking about service certificates. I feel like we're kind of behind the curve on that. Like, I think all my impression was that all the cool kids were doing cert based SSH for things. Like if you have a fleet of lots and lots of machines, which we're getting to the point where we're starting to have, like, when I joined, it was kind of silly to describe us as having a fleet of machines. Now it's kind of getting, it's making more and more sense for us to like, you know, talk about that. And I don't know how you would do it. Otherwise.
Matthew:I turned the rollout, sSH certs to like an entire fleet of machines and a company worth of users. A couple of years ago, I had like, it was an intern project worth of work.
Thomas:Yeah. George, Hey
David:George.
Thomas:Yeah. I, you know that the best, the best possible answer to any question is like, oh yeah, everyone's already done that work before you.
David:Yeah, everyone's already done the work. You're actually bad at your job. Please leave now. No, I've actually never used SSH certs aside from whatever magic was being done at Google when I was there briefly, which I think involved, like SSH over HTTP or something really very Google
Deirdre:Y because something boring Corp
David:or I couldn't tell ya. And I don't know enough of the details. Um, I think looking for more callers
Deirdre:for your question caller! And if we don't get the question soon, I might have to flush my cache of ECDSA versus Schnorr signatures.
David:My mom says it's more. We'll have to talk more about log4j.
Thomas:If it's not urgent,
David:I think speaking of log4j I actually, I just love any situation in which people learn that you can't parse non-regular languages with regular expressions. That always just gives me uh lots of joy. I feel like that was, many people who like went and got CS degrees at some point had to take like theory of computation and probably didn't take that much away from the class, except for some languages are regular and some are not.
Deirdre:Yeah. I did not have to take theory of computation for my MIT computer science degree to graduate. And I knew some physicists who took theory of computation for fun, but I was not required to take that course. So I might've been surprised if I paid more attention to log4j
Thomas:David. I have a write-in question.
David:Oh, okay.
Thomas:This is from Jeremy. You guys ready? Yes. I'm ready. Long time listener. First time caller. First question. Why did nobody think about some protocol for keeping multiple U2F tokens in sync. So I can keep one in the safe and don't have, don't have a single point of failure in my email account. I know Yubico has a draft spec out now, but this would have been better in U2F proper. There's going to be a question where we all just basically agree with him, but yeah, that's the question.
Deirdre:Yeah.
David:Is it like, that's not clear to me, like the don't you just want to register a second token,
Deirdre:the current standard operating procedures. You have one that stays a move, like the fire safe, safe for, you know, super extra backup, one that is super convenient for your mobile device, and one of those super convenient for your non-mobile device. And you basically have the new standard thing.
Thomas:Yeah, wait. I was like, I wasn't, I was in method acting mode when I was reading that. And I, I took over his vantage point for a second. And in that moment I agreed with him. But now I'm wondering why he's asking. Cause I totally agree. Like why would you
David:want, I think the big issue is then you have to like for every service you're using with it, you have to go in and take it out of your safety deposit box or wear, or your please don't steal this box box that you keep in the closet. and, uh, you know, register your second coat token across 10 services, 15 services, whatever. Uh, like the other day I counted in my password manager and I had 23 different slack accounts. So you can understandably not want to set up like YubiKeys for all of those. Yeah. And then
Deirdre:like I have, I have several U2F slash web auth and devices. W I have micros in my laptops. I've got the secure element in my phone and the secure element in the And I have the touch ones on my fucking key chain. I have two of them, the old USB B version and the USB-C version. And I have ones in my like safety box. Guess which ones of those get updated the most frequently when I have a new service or I want to rotate keys?, basically the one in the, in the fire safe box gets updated for like the fall, fall, fall back services. So like almost every service worth its salt, that has a recovery story, says, like, if you can't log in with all your multi-factor methods, like we will try to fail over to a recovery email or a recovery phone number. Sometimes they make you register a phone number and at least for Google, they do this and the, whatever your fallback is, should be ultra super duper secured, and probably should not have any fallbacks to it. And those are the ones that you really need to have that fallback multifactor tokens in a fire safe box. But honestly, for all the ones that I use on a regular basis, I use, I have so many devices that let me like sign challenges and authenticate with my web service and bind to the domains. So like, I'll use those, the more
David:frequently they are just signing.
Deirdre:Uh, yeah, but I think to respect the caller's question, I think the fact that U2F slash webauthn lets you just do it with one and if you lose that one, you're fucked. Isn't great, the fact that like we tell everyone to have more than one because if they lose one and they only have one registered, they're fucked, is part of the problem. So I don't know.
David:I think another issue. So like you can, you know, implement U2F or WebAuthn, I guess, you know, with like anything you can do it with, like I'll go program, for example. Um, in fact I have one of those, um, that I've used in tests before, like for, to make sure that WebAuthn was implemented correctly. I have my like shitty. Wipe off and go program that just writes out a key to my home directory and so on. first of all, so the reason that like web authen is useful or anything is actually is twofold. It's that the browser is like acting at a privileged layer above everything else. And it's coordinating everything. That's ensuring that like, oh, I know that this key is associated with this site and enforcing that the signatures are done via like the protocol, which includes like signing over the name of the website that you are, in a challenge, that you're authenticating to so that when you try and U2F Wes into the phishing site on attacker.com, your signature includes the word attacker.com. It doesn't do you any good, right. So it's non-forwardable. But then the other thing that people miss is that like it's next to their computer. Like that's actually something that's important. There's a reason you can't use your, you can't use it just like a phone as a web authen token, most of the time or your laptop, the reason being like you have no idea if you are authenticating a web session on your laptop or on Deirdre's laptop or on some attackers laptop. Um, if you want to think about it in terms of like a cryptography style game, imagine your phone is a web authentic token and there are two people, two laptops signing into your account and you can't see the screen. And the way that you win the game is by having a better than 50% chance of guessing who's signing into the accounts, laptop A or laptop B you do
Deirdre:have the thing now, which I think the Google identity folks are tying to add the new web authn two or whatever. Where you can have your key rooted in the secure enclave on your phone, and it communicates with your browser on your desktop via Bluetooth to make sure
David:that it is easily via Bluetooth.
Deirdre:Um, it's like, it's like making sure that you are physically close to the user agent via Bluetooth, but it's actually like routing information through Google servers. It's very like, I get it. It's also kind of convoluted.
David:Yeah. And it's not ideal because like anyone that could Snoop that Bluetooth connection could also like fake it, but or you could be authenticating any laptop within range of your Bluetooth session basically. Um, and so all this to say that like, physical proximity is kind of like an implied part of U2F/WebAuthn. And so having like a sync mechanism back to another. Um, I might go against that some, and also a sync mechanism to another key. Um, if you were to ask, say, for example, former eff lawyer, Nate Cardozo, what that is, he'd be like, oh, that's a backdoor, but you're describing is a backdoor, and so, there's definitely, uh, questions involving, uh, that I think the, uh, I think, you know, at the end of the day, we're gonna end up at something like using phones for this. And then, uh, and then like having some sort of sync solution between your phone and that's pro and, you know, with TPMS and so on, that'll probably go, not in a way that's not too shabby. uh, or, or you can always, you know, transfer with like QR code or something. It's just, it's always tricky. Whenever you try to build a, what is effectively a backdoor.
Thomas:Yeah. There's like the, oh yeah.
George:Well, so if you look at the UX, that's developing around like, you know, blockchain, hardware, wallets, uh, they try to embed, you know, some kind of like display on the trusted hardware side so that you can, you can verify, you know, a transaction, even if you've received it in some kind of like, not directly plugged into your computer way. so if you can imagine the phone version of that, that isn't terrible, you know, where we're like your, your laptop can request something from your phone and like identify itself and what it's trying to do. And then you say, oh yes, that is the thing that I'm trying to log into on my computer right here right now. maybe that, you know, maybe that could work, right. You can imagine phones being powerful enough to do that in an actually usable way.
David:Yeah, the tricky part is how do you identify the web browser? Because in the web case, most of the time, anything that you can pick could be faked by the attacker location, um, IP address, user agents, like all of those things you could route around with a proxy or just with a web browser that lies. so it gets a little more complicated, but
George:installed a web browser. That was,
David:well, no, only the attacker only the attacker needs to install a web browser that lies, right? Because the attacker installs a web browser that lies and says, it's in your house. And then you get a request on your phone that says, do you want to authenticate this web browser that's in your house? And you're like, sure, it's in my house, but actually it's, you know, across the country or something,
Deirdre:Google's able to get around this by having the compatible webauthy browser, having the backend of the web service here, trying to authenticate with connected to your phone and it knows your identity, and it's able to be like, you have a registered device with accounts dot, google.com. Here is an alert on your phone. It's like, do you want to approve this login request? And, you know, do whatever kind of pseudo signing challenge, confirmation that they do. but you know,
David:it's preregistration, is the way that you get around this. If you can say that you've, pre-registered every browser that you've signed in from then you've like trivially— e or preregistered the browser to the phone, so like there there's some web extension that, Nick Steele wrote when he was at duo was part of like the web authen spec that, uh, that showed basically a QR code. And you had to scan it on your phone. And then once you had done that, you transmitted some sort of key material between. It's the browser and the phone. And then with the help of a relay server, you can have the phone authenticate things in that browser?
Thomas:I like that. Cool.
George:Yeah, that's cool.
David:The tricky part is like, if you're a company that's trying to like build some sort of auth solution that's user facing, um, you can't really be like install this Chrome extension unless you're in the cryptocurrency space. Um, but like if you have normal,
Deirdre:we have a question in our chat somewhere from Jacob. question is where would your first, second and third ideal real world post quantum crypto deployments, B as in what technologies modality?
Thomas:I can definitely get my opinions in here because I have so many of them and I know so much about.
David:My opinion is that quantum computers, similar to birds, don't exist or they're a government conspiracy.
Thomas:Yeah, I read it. I read a breakdown the other day of like the progression. Uh, it was a really good post. I think Steve Weis posts posted are Steve Weis retweeted it. And that's how I found it. He was dropped off here. And so I can't continue messing with him about it, but like, it was like a graph of the progress that we need for both error correction and for the number of qubits we have, because like the way you actually build the way we think you're going to end up building a real quantum computer is that you're going to like collect a bunch of physical cubits into a logical qubit that you tied together with error correction. Um, so like the actual, the raw number of qubits is much less important to them. Kind of the, uh, I don't know about the. Product of both how many physical cubits you have and how good your error correction is. Right. And there's like a graph of like where we start to get interesting problems that we can solve. And we're nowhere close to like the border of that graph, where we can do like basic chemistry things. We might be able to do better with quantum computing. Like it could be forever and ever, never before we get there. And my takeaway from that was I never have to worry about quantum computing
Deirdre:I think we are doing the right thing in that we are doing the research now to have quantum resistant cryptography for just in case. And for those, you know, users like long-term storage or, you know, whatever, like the government or the military or whatever, who like no, really they need to encrypt something or they need to be able to do key establishment. And it needs to work 25 plus years from now, like that's part of their requirements. we saw that elliptic curve crypto was quote unquote invented in like 1985 and it took at least 20, maybe 25 years for it to get deployed at a efficient and widespread scale. I think we're doing a lot better now, but, we've definitely got a lot of options, but they're not perfect yet. And there was actually a nice post from, um, a presentation from Steven Galbraith about how like new cryptography gets introduced every about 10 years. And then it gets, it's, when it's first introduced, the math is slow and people are like, well, this is not useful because it's too slow or inefficient. And then like, not that long after someone will make it much more faster with like algorithmic improvements and math. And then all of a sudden it's much more useful and you find much more applications for it because it's finally efficient enough and we've seen that happen over and over again. I do think it's going to happen with all of these quantum resistance proposals, especially the isogenies stuff, which is, keeps getting faster and stays secure. Unlike some other, uh, stuff. But, uh, I'll go back to the original question before I forget. where would your first, second and third ideal real-world deployments be? I mean, number one is getting TLS, quantum safe. We'll just do a hybrid with either, you know, SIKE, uh, supersingular isogeny key exchange, or there's some proposals to make. SIDH actually usable in a static setting again, um, by doing a little, uh, check of the parameters to make sure that they're safe. So we might get that back and actually get something that's Diffie-Hellman Hellman and not a key encapsulation mechanism. Or you can do your favorite lattice. we are we've the Chrome people have done deployments with those and they were, they had some performance or latency issues, but like, they will work. Like if. Someone is very worried soon that it's not that they're in an insecure place. Uh, we have nice options that we can slot in and we've tried them and things don't break terribly. and we can do that. So TLS on the, on the web, on the internet is probably number one for key exchange. We're not that worried about signatures, for, for kind of trust on connection for that. Uh, it's mostly like long-term key establishment for recording the entire traffic. That's probably my number one and then probably I'm biased because I'm in a kind of blockchain space, but like trying to find post quantum, like. Key stuff for all of your blockchain crap. Like everything in the fucking, I don't want to say web three. I disagree with the term, what three crypto three, all of the fucking crypto stuff
David:is Crypto 2 electric Boogaloo.
Deirdre:Exactly. Like all, all of that shit is not quantum resilient, except for like a handful of exceptions. So like if that's going to keep going and there's tons of fucking money being thrown at it, somebody come up with quantum resilient versions of all the things you're building. Um, get rid of those ECDSA signatures, get rid of all of your key establishment that relies on, um, quantum insecure, mathematical problems. Hopefully that helps caller or questioner.
Thomas:I think, I think that they were asking what your preferred crypto system.
Deirdre:I thought that, but then they asked what real world deployments. Uh, and so I, I re-read it as like, where do you put the post quantum crypto?
David:I guess I'll answer what Deirdre's favorite. Primitives are and the answer is isogenies.
Thomas:You're like I saw isogenies then lattices then McEliece right.
Deirdre:So the thing is you can't do fully homomorphic encryption with isogenies. Well, you could believe with the, as inefficient as all the RSA implementations of the thing, and you probably wouldn't get the fully, you would just get the homomorphic encryption. You can do crazy shit with lattices that you can't do with basically any other like mathematical primitive for cryptography. So I have to give props to the lattice stuff. you know, where. Where they can do things that isogenies can't. I am, I love the structure and the, the algebraic niceness of isogeny stuff. I just think it's neat. but there's some stuff that it's not really applicable to yet. And then McEliece is boring! I think.
David:What is McEliece based on, like, it's not a isogeny and it's not a
Thomas:linear error correcting codes. Oh,
Deirdre:it's it's old school. I think people like it because they understand it. And it's just been sitting there for like 40 years and it's, people have been like, you know, hip checking it occasionally and it's still standing. Uh, I think it's mostly just it's people understand it. Not that it's a, it's a super, super cryptoanalyzed to death. There are some constructions that are based on block ciphers and hashes almost exclusively. Like no, no codes, no, multi-variate polynomials. No isogenies. No. lattices. It's like really bare bones, kind of symmetric crypto stuff. And you're able to build things like, picnic and signature systems and proofs of knowledge and other stuff like that from like really like stuff that we really get. And we really have a good, uh, sense of why they are, post quantum secure. I do like those, and I hope that more of those continue to live around. I don't think picnics survived until the last round of, of the NIST post-quantum competition, but I do like those and I want to see more of those, especially like zero-knowledge proofs and stuff.
David:Matthew, I believe you had another question.
Matthew:Yeah, I do. So I'm buying a modern car, one with electronics in it. And you know, one thing that I'm worried about is that it seems like cars are being stolen by keypad cloning or relay attacks on them. Is this actually a hard problem? Or do car manufacturers just not care or do they just not have like good cryptographers working on it? How do we fix this? How do I have confidence that someone's not going to come up with a little black box they got from somewhere and drive off with my car?
David:So I have part of an answer for you. And the first one is just never parked your car anywhere. I believe you used to live in San Francisco. So that should be very familiar to you. thing too, I don't have a good answer for you, but, um, a sense a friend of mine, Ethan Stark is in fact, in the audience, I'm going to share an anecdote when it says that no, the car companies do not have good people working for them. Because for example, my friend, Ethan, very smart person, he works for Waymo. We had another friend in college who was not as smart whose name I will not say who was not that good. And now he works for Ford. And, you know, I think that's just kind of the way the world goes that, uh, you're expecting, th th certainly not necessarily, uh, true for everybody. But, I think the top tier cryptographic talent is not getting hired by Ford. also could I recommend buying insurance?
Thomas:George. What do you think about key fob cloning? You have the real answer here.
George:I mean, cloning seems like a difficult problem to solve, the relay thing also seems like a difficult problem to solve for different reasons. I think that's probably also partly why they haven't fixed it, uh, right. Because like for most cars you kind of need like any random dealership to be able to clone and to like make a new copy of the key. and, and I know that like for instance, uh, Tesla keys, Like may not have that property. Like it is under some circumstances, very irritating to get a new key made for your Tesla. Presumably because they have like actual security that has to go back to the mothership to be like, re-key it or something.
Deirdre:So almost every year at real-world crypto, yet another demonstration of either cloning or breaking or, you know, recording the entire key exchange between your fob and your Tesla. And then just like doing the breaking and replaying the correct, like manufactured fob that you like doing the registered— because they found the like box that you deploy to your, uh, your Tesla service, uh, installation. And then they like, oh, look, we shall just use this to record the handshake between a fob and a car, and then use that to re-key a new key fob and use that to break into the Tesla. There seems to be like another iteration of this sort of thing every year. And I don't think it comes down to the cryptography so much as the like kind of what George said is like, you need to be able to service the car and like that kind of builds in these fundamental vulnerabilities into like these protocols. yeah.
Thomas:I did like, uh, I did look at utility RF thing once, like, just speaking to like that, that the constraints that, that, that you're working with us, I guess, to start with, right? Like I'm a little confused by keyfob cloning to begin with because cars are easy to steal. Um, and like the, the most marketable cars to steal, like the lucrative cars to steal don't tend to be keyfobbed anyways. It's like, they tend to be just like, you know, kind of garden variety, like whatever, a Honda civic or whatever. Right. I don't know what the cars are, but like the cars that are tend to be the most lucrative always surprise me. And they're, they're not like super modern advanced cars.
David:XKCD reminds us the$5 wrench is going to do a lot better than any crypto attack on your car,
Thomas:which like living in Chicago, right. The way your car is gonna get stolen. Is it somebody who's going to, like, as you pull up to your parking spot, come up to you with a gun. Right? So, um, Chicago is great, but like carjacking is real. So, um, you know, I guess like, You know, you'd think that like the actual cryptography part of that problem is like our really solved problem in that we know how to do like, you know, network authentication over untrusted channels. But like I've been on projects where people did really dumb, bad crypto things because of the constraints, both of their, like their, their SOC and the crazy RF constraints that they have, but that they're use really, really small messages and stuff. And like, we wound up with like, you know, 16 bit CTR counters and things like that. Um, like that's a thing that happens. So you can kind of, you know, if you're, if you're not like spending all, but also like my other thought there is like, I, I don't know anything at all about the caliber of person that works at Ford. I'm sure your friend is awesome. You refer to him as your friend, so I'm sure you're being sarcastic about how bad he is. But like, there's a huge cottage industry of, um, security consultancies working for every major— it's like a, it's a huge sour— was wisely least a couple of years ago, like a huge source of revenue for the big software assurance firms, just doing design and review work for car companies. So like, even if they don't have like cryptographers on staff, right, like they have an army of cryptography consultants that want to come in and find every possible thing to tell them to do better. you know, those contracts are worth, you know, a hundred,$200,000 a pop, right. So like the consultants definitely want to do that work. So I'm like, I'd be surprised to hear that they don't know how to do it. Right. yeah. I mean, that's all I have on that
David:actually feels like a fine use case for client certs. I have another, I have another written question again from Jeremy and it's a question I like more than its previous question. Cause I have opinions about it. You guys ready? Yes. Okay. Hold on. I got to get into the mode, right? Um, so Jeremy asks, first of all, he says, thanks for doing it to my first question. And Jeremy, you are very welcome. why do you think that there has been no real effort to create a cross-platform zip alternative with real encryption? And what do you think it would take to get, to get created that, to get, create one? You gotta write the questions better. If I'm going to read them like this, I have to be able to read them with real support. It doesn't seem to be too hard to combine age and zip somehow" I could not agree more. Um, I have friends that works. We all have friends that work at big tech companies. And every once in a while, they'll reach out with they'll do like an annual product roadmap thing where they're trying to figure out like what cool crypto things should they do. And then for some reason they asked me, I'm not a cryptographer, but they still ask me what they should work on. Um, I assume they collect it with lots of other people's feedback and I fell on the bottom. Because every God damn year, my answer to that question is I should be able to right-click, on a file in, you know, my, you know, my finder or my, whatever, the windows calls it or whatever and encrypt the damn file, um, which you can't do. So there's no good reason why, like, I would assume the only reason why we don't have this is because Google and Microsoft and apple would have to agree on something, but like, that's really easy. Right.
Deirdre:We have, we have one of the, creators of age on this call and I've just, uh, asked if they wanted to speak, but I feel like we are getting really close to that. And it does not involve one of the big, you know, operating system developers to be part of it.
David:This is already possible. You simply modify the default.Defaults text file in the correct/etc directory so that you can get GPG when you right click on something in the modal list
Deirdre:we kinda talked about before, like you don't go to the standards body, define a standard and then have everyone go implement it. Someone goes and designs it and implements it and then it becomes a standard. I think we might want to see age kind of be part of that, like age: good. age Thought it through, now, apple, Microsoft, Google, et cetera, go and like make right click encrypt with age, decrypt with age, like part of your operating system or something like that.
Thomas:I mean, you could probably make a bigger dent just by having some major operating system vendor, it doesn't matter which one of them just have this as a first class feature of the platform and then publish what the format they used for it was, like, I love age? Is that how you pronounce it? Um, you know, I love all this work that's being done, but like, it's still a cool kid thing, right? Like if I saw, like, if I saw files in your home directory, I would assume you're a crypto nerd and nothing you have is worth being hacking. So, um,
Deirdre:it was very designed to replace the like encrypt file, like use case of GPG.
Thomas:It's a thing. I yell about a lot online. I should yell about it every year. Like on January 1st, just that like, um, like obviously it's easy to encrypt something well, if you download a program that does it, and then that, that problem is just like, you know, how do you find the really good ones? And the answer to that it's really simple. You just find age and run that. Right. but you know, for this actually to be workable, like I go back to when I was doing consulting work. Right. And what I have to be able to do, is it happy? We'll do this with clients without telling them to go install something. Um, the moment I tell them they have to install something I'm done. It's just not going to happen. You know, instead of, instead of encrypting something after downloading it, what they're gonna do is, um, reply to me with encrypted zip file and encrypted, encrypted, zips are the worst thing on the planet, right? There's nothing worse than encrypted zips. So no,
David:definitely.
Thomas:It's like w what's worse, uh, you know, claims to be encrypted with AES-256, but is instead of encrypted with Bassomatic or straightforwardly says it's not encrypted,
David:I sent a professor a thank you note. After I graduated with my PhD and they responded with a GPG encrypted message. And I still have no idea what they said
Thomas:at the state. You haven't read it. So that's a good question. Unfortunately, has a really simple answer, which is that we're never going to have a good encrypted format, um, because it wouldn't, it would require collaboration between, you know, writers who don't trust each other. I was going to say, Linux should fix this somehow, but I have to think like, well then the Bluetooth maintainers have to do something and that's even worse than getting Microsoft to doing something so
David:well, you can get Jason to get it in the kernel somehow.
Thomas:Yeah, that's true. We haven't thought about this. Jason has the weird secret power where he can get Linux people to do things. So the answer is it has to be built into the Linux kernel. We have requests and I'm letting somebody speak here. Hello? Yeah, I was, I was about to make that same.
David:We got George to let two people speak at the same time. God which chopsticks do we use
Jake:my, my question is not security, not cryptography, pretty clearly, whatever. So if, uh, if that's not good, then I'll let George speak, uh, what, you know, why is Web3 a bad name. I just wanted to, I just wanted to stir the pot.
Thomas:No, you you, you're saying that when w when Deirdre took a pot shot at web three, I was going to stop her and hold her to account for working in cryptocurrency and somehow dissing on web three. So I'm glad you asked that because you reminded me that I have to write about this. Yes.
Deirdre:So web three is obviously being like, remember Web 2.0? Well, now it's web three, except it's not it's crypto shit. It doesn't have anything to do with the world wide web. And now it's just like, oh, it's just a bunch of like defi and blockchains and smart contracts and stuff in a distributed way, but it's not, it's not web three it's crypto three but the hype cycle that Web 2.0
David:Let's not let George keep quietly Jeffersoning on mute in the corner. Cause he's also works on cryptocurrency.
George:No, I mean, I feel similarly, right? Like I, I, um, you know, when, when, when challenged, I say crypto means zero knowledge proofs. No, like I have not. like you say, web three to me and I have no coherent idea of what that means. The closest closest thing that I can think of is that if you have a bunch of people with, you know, like their ethereum wallets or whatever, plugged into their browsers all the time, you have accidentally solved SSO. Like, is that web three?
Deirdre:All I know is anytime I see anyone talking about web three, it has nothing to do with the worldwide web, a browser, HTTP. Any of that, it's about crypto currency, crypto stuff, crypto crypto, crypto,
George:this beautiful vision of a world where in all human interactions are literally transactional.
David:No that's called San Francisco, george. Yeah.
George:You know, no, no coincidence.
Deirdre:Yeah. And it's not
David:no, the DNS replacement. I don't know if that counts as web three or not. Probably.
George:Yeah. I couldn't possibly say because web three is a bad phrase.
Thomas:If you're going invent pictures with monkey. I was bored
David:monkeys. Only if you could get a loan for a DNS name, maybe.
George:I mean, you can probably do that.
Thomas:Okay. W what is like, what is the line that you two draw between, like this kind of self-evidently monstrous space of weird transactional Ponzi schemes, atop Ponzi schemes, atop Ponzi schemes that is kind of NFT or Dao stuff? Like let's buy a copy of the United States constitution? I'm like the scam there is that it costs more money to get your refund back then the refund is worth. So they just keep all the money. Like, what's the distinction you draw between that?
David:No, they still sent the money back. So they basically accomplished lighting$14 million on fire or$30 million on fire. It's like a kickstart starter where, what do you get your money back instead, someone slaps you and then lights it on fire.
Thomas:I guess I get sort of in the same way that post quantum cryptography is a kind of, it's a full employment program for novel public key cryptosystem researchers. Like I get the sense in which things like Zcash are a full employment program for people that want to do public key signature work. so I get like the technical attraction to it, but what's the distinction that you draw between that kind of work. You know, kind of cryptocurrencies, zero knowledge, proof, you know, anonymous transaction stuff, and kind of the tokenized pump and dump scheme stuff.
George:Well, one of them has users. That's not your one, right there. One has
David:pictures
Thomas:with like lots of people at the Bored Ape party. Like it seems like there's lots of people doing that.
Deirdre:Um,
Thomas:Jimmy Fallon has a Bored Ape.
Deirdre:Oh my God. I think like
George:if you're looking for an explanation of the board apes, I like, I don't have one for you. And neither do I,
David:I think a lot of the web three people, or at least the people I know that are into that are building stuff on top of, on layers, on layers on top of cryptography that has been given to us by Deirdre and George and others.
Deirdre:A lot of it is on like an Ethereum platform with both sort of one global distributed, decentralized computer,smart
David:contracts
Deirdre:and stuff,
David:As we all know, Al gore invented Ethereum.
Deirdre:Um,
Thomas:what is the distinction then that Ethereum is bad, or things that function like Ethereum are like, that's the problem?
Deirdre:I think part of the problem is. Fundamentally computing has been, someone writes a program and like you trust the P the person that writes the program on your computer or a computer. And now smart contracts are trying to be like, it is a global consensus computer, and everyone, it's like a fundamentally different computing trust model of like someone writing a program, AKA, a smart contract that runs on Ethereum thing. And now we have to figure out who the fuck we trust. And if the thing is secure in a different way than we've been doing it, but also like it's a lot of just kind of scammy shit because it's like complex and people don't understand it.
George:All right, but you're, you're even, that is like an extremely, I build this stuff professionally take, right? Like the people who are, um, you know, mostly using this stuff, I don't think are sitting there like wondering about how robust their replicated state machine is. Right. So there's like, there's, the distinction is maybe between like people who are kind of interested in like the mechanisms and people who like want. You know, to like get 20% yield on there. They don't really care what it is.
Deirdre:Yeah. And I will say that people were, not the original web two, but just before web two, we had the original.com bust. And there was a lot of like people raising mountains of money for weird fucking websites and web services that were just like either, you know, vaporware or just a lot of money that went in a hole and nothing came of it. And I think this whole crypto defi smart contracts, NFTs, all that sort of shit is so like there's tons of money being thrown at it. People don't understand it, there's still a bunch of like weird grift and vaporware shit happening, not dissimilar to sort of the, you know, dot com bubble. There's just a lot more cryptography involved in it, I don't know.
David:I think the people that really believe in it that are doing web three stuff and not just like running scams all the time or solely, you know, looking for like 20% plus returns, are, like, view it as a way in which like web 2 like, like, Facebook basically was about like, you create a bunch of content and then Facebook makes a bunch of money off of it. And the like community aspects around web three here, the idea that like you create a bunch of content and the users make a bunch of money off of it is like what it's supposed to do. It's just, I don't think that that will happen. And I think that any of the cases in which we've like tried to leverage the, the trust, the distributed consensus models that like have been created for cryptocurrency and web three, and then tried to extend them to the real world. I think I've been objectively worse in every situation than one than one you just used a normal real world construction. Um, and that will probably continue to be the case until somehow you be reached the point, if ever, in which you can keep, which it is more valuable to keep your cryptocurrency as cryptocurrency in terms of utility. Like I need to spend money and buy things and do it, do stuff with it. Like until you get to the point where like regular businesses, if they took a cryptocurrency, could leave it in cryptocurrency and still like do stuff with money, like that's just always going to be the case because as soon as there's the on-ramps or the off-ramps in the cryptocurrency world, you have a centralized structure and then that's a point of failure. And whatever you do to address that point is just pretty much always worse than if you adjust, for example, the Sotheby's case. Like there was no connection of the LLC that was actually bidding on the constitution to the DAO. Like they signed a letter of intent that said they were going to do it, and they had the private key, but they could have also just taken all the money because there, there was no binding to the thing and the real world to the thing in the crypto world. And so, um, you know, I can, I can appreciate the peoples that are like, you know, let's try and get more access to financial systems to people and let's get more money in the hands of users instead of Facebook. Um, I remain skeptical that that will actually happen. But yeah, I, that's kind of the web three, uh, view, I think is instead of money you make content, money goes to Facebook, it's, you make content, money goes to users, and then we're all magically rich and living in space.
Deirdre:Yeah,
George:I think the most, the most charitable interpretation of, you know, if you're going to put forth like the strongest version of the argument for why all of these things should exist is that they are they're experimentation i You know, in, in the field of like, uh, what if it were much, what if it were dramatically easier to, you know, like transmit money in, in a peer-to-peer way? Right? Like we have kind of the best way that we have for paying people on the internet right now is like Stripe, but there are still fundamentally a lot of things that you can't do with the, like the model that they provide. And they're, they're kind of coming at it from the other way. Right. Like trying to make it so that you can like programmatically do more and more things on like, kind of fundamentally the same rails. And then there's a bunch of like strange people trying to reinvent it from like a totally different set of principles and maybe it'll work. And maybe it won't, but I like, I think that's the, the kindest view and then like, because they are building financial infrastructure, but like don't have a fraud department that Stripe does. All of the fraud is also happening.
Thomas:I just, you know, just wrapping this up, I just say, like, I'd be one of the no-coiner people I'm, I'm a no coiner, I guess. I'd be, I'd be much louder about it. Um, I'd like retweet a lot more critiques of cryptocurrency in general and the web three stuff in particular. Except that I always feel like if I did it, I would make Deirdre and George unhappy. Um, I also think you're like, there's gotta be something to it given that you guys are both very smart and you work in the field. But I have a hard time getting my head around it. Right. Because my immediate reaction, which I've never gotten over is that like, if this is like tulip mania, right? Like it can't possibly be but you know, I'm saying, I must be wrong about that somehow, but it's still kind of my surface level belief about this stuff.
Deirdre:I would say when it was just a bunch of forks of Bitcoin, and it was just a whole bunch of different coins and they were only marginally different. They were just trying to be the new Bitcoin. I would basically agree with you, but like all it's, it's evolving extremely quickly and with a lot of extremely interesting cryptography trying to achieve way different ends, like there's the smart contract stuff, there's sort of provability stuff. There's like, there's a ton of weird stuff going on, that's extremely interesting for a whole bunch of reasons. And so now I, I can't even predict where it would go where once upon a time was just fucking Bitcoin and doge coin. And now like doge coin has a resurgence because like fucking Elon Musk, turned it into a meme and then it crashed the next day. Yeah, That part of this,
Thomas:I have no trouble understanding that. Right. Like why it appeals to you? Like, you know, as an engineering problem really obvious, right? Like, of course. Um, so like, I get, like, if you want to spend all your day working in polynomial cryptography or polynomial, public key cryptography, and isogenies, I guess there's no isogenies in what you do. But you know what I'm saying? Like really, really weird curve signature stuff and all that, you know, I get that, I get the appeal. They're like, if you want to do like hardcore cryptography engineering work, like it's a really good way to get paid to do it. Right. It's just the broader kind of like, what is it for, that I have trouble with.
Deirdre:Sure. No, I get that. All right. We have another, we have another question that I want to get to before we, uh, we run out of time. Okay. From Andrew, uh, can each host please come up with a distinct use for a Merkle tree, but isn't a blockchain or certificate transparency and I'm going to get One: SPHINCS signatures are hash based signatures that require keeping track of keys that you've used, statefully with Merkle trees. So that's one, and that's post quantum secure, but it's a pain in the ass to use because of the stateful Merkle trees. And two, in the messaging layer security protocol,
David:I was going to say
Deirdre:they do all of the key management with TreeKEM and it's just fucking Merkel— it's sort of like transparency trees, but for your keys and your groups and shit and rotating them and adding them and removing them and all that.
Thomas:W you know, I mean, I don't know how much time we have left. Right. But like, if this was just us recording, normally I would stop you and ask you to like, define your terms there. Just on the assumption that not everyone listening to this knows what the hell Andrew is talking. Sure. So
Deirdre:Merkle trees have been around for a very long time and after Ralph Merkel, but they've become extremely in the zeitgeist because of, because of blockchain, and because of Bitcoin. You have a whole bunch of Merkle trees in Bitcoin, like you need to hash up all of the transactions in a block and you do it with a Merkle tree, so that you end up with hashes of hashes of hashes until you just get one hash. And then you commit to that hash as part of your block. And you put that in your block header and all this stuff. And in Zcash, we have a buttload of Merkle trees for a whole bunch of different reasons, including uh note commitments and other stuff. so instead of just blockchain, you can use them for a hash-based signature, like SPHINCS, where you have to keep track of what things you've already used and what things haven't been used. And you can commit to the entire history of the statefulness of your keys by updating your Merkle tree. So it all passes up to a single hash, your root, and then you can like keep track of just your root, because that is a commitment to the entire state of your Merkle tree of hashes. And then similar for messaging layer security. And the way that they keep track of all of the keys of members of a group end to end encrypted messaging uh channel or session or whatever is they have a publicly available Merkle tree that everyone that can check, when you add a new person or remove a person or a rotate, all the keys and the group, everyone can hash up all of the trees at the point in time, uh, all the keys at the point in time that everyone's supposed to be agreed on, on the state of all the members of the group into a root hash. And then you can all compare and make sure that you're all looking at the same state of the, all the group keys. And if you disagree, you can take some action, like reset, everything, or kick, or something like that, or, you know, throwing, throw an error. Um, that's what those things are. Does that help? Messaging layer security is cool and they're solving hard problems in distributed s— end-to-end encrypted group...
David:and one day maybe something besides Wire we'll use it.
Deirdre:Well,
David:I guess that is kind of
Deirdre:important. Yeah. Yeah. There are implementations that use it, but it's, uh, it's pretty cool because they're, they're doing the hard work of solving all these weird edge cases and performance issues. And they're doing it, uh, and it will eventually be an IETF spec. Cool. Thank you for the question caller. We have another in the chat.
David:I think the real question is why is anyone listening to us instead of watching the tail greeter indoor there in Illinois and the coastal Carolina Santaclears, which is a type of chicken.
Thomas:Oh, that's a good answer on the slack too, which is like Blake3-style tree hashing.
Deirdre:Yeah. Sarah, do you want to ask your question?
Sarah:Yes, I am. Go ahead and ask my question. this is, uh, going back to the previous topic about financial structures. I'm kind of curious what you think are going to be the legacy after effects of things like cryptocurrency. We have things like file transfers for ACH. So I'm curious what you predict will be legacy in 20 to 50 years. Also, if any of you want to feel old, think about how email was basically invented 50 years ago.
Deirdre:Yeah. I mean, I think Bitcoin will not evolve fast enough and that will be super legacy in not that long, especially as a lot of like things— Ethereum is trying to move away from proof of work to proof of stake, like within the next year. And, uh, I hope that they succeed because if they succeed then a lot of other blockchains or, you know, whatever distributed consensus, blah de blahs will have, you know, a model to follow. Um, and it's better to stop burning up all of our shit by just fucking rolling dice and hashing it. And just praying to God that you get the right fucking leading 10 zeros. It's so fucking dumb. I hate it. that that will not move fast enough. And I think it will look real dumb and janky and old pretty soon. But other than that, I don't— fuck, I don't know.
Sarah:Oh, I mean, here's another way to think about this question is, what is everyone going to groan about in 20 to 50 years? Because we're like, fuck, why did we come up with this idea 20 to 50 years ago such that we have to deal around, uh, we have to deal with it now and have to maintain it and learn all of this arcane stuff. May or may not be inspired by thinking about GPG.
David:Um, spiffy,
Thomas:Kubernetes, spiffy, sidecar model proxy, like building like a weird layers of abstract network transports between services and all that. But the idea that you're going to build your services to this weird service mesh that does MTLS-based security between proxies and stuff, isn't like that's Quorma, right? Like it's clearly we already, we groaned for a little while about Quorma, then it went away. And so that'd be my answer.
Deirdre:Also, sorry, you're talking about general technology, not just, you know, crypto financial crap?
Sarah:I mean, I, it was themed on crypto and was inspired by thinking about financial and like financial structures and financial institutions. And so it's like, you know, we're adding cruft upon cruft. It could be security cruft. What is going to be security and cryptography or security and cryptocurrency. However you want to define crypto cruft in 20 to 50 years.
Deirdre:I think I do think that there will be some development in terms of either threshold keys, or like multi-party computation that will make a single person with a single hard—, like, hardware wallet, or, you know, device that is like the single point of failure for accessing millions of dollars, will look like jank as hell. But we're not there yet. And I have a feeling that the thing that will happen will sort of be like, of course, it's the way we should do it, why did we think otherwise? But we're not in that world yet, but like the fact that like hardware wallets are like, everyone's like super fucking into hardware wallets, or like storing a single point of failure, key on your, you know, your phone and like that's as good as we can do right now, given what we have. But I think in like a couple of years after we've kind of gone through a paradigm shift of like what we can do, we will look at, look back and be like, what do you mean? There is like a fob in a vault. And that is the only way to like access all of our shit. And you're like, are you kidding me? Like, yeah, that's the only way we were able to do this, like, in ye olde 2020, or whatever. At least I sincerely hope so, that we are moving away from that. And like, that's not even just cryptocurrency, but like kind of the U2F/Webauthn keys that we have now, I sincerely hope that we can kind of do something better with multi-party computation or threshold key agreement or key establishment or signatures or something like that. That will make those single points of failure, like a thing of the past.
Thomas:I think Jack has his hand raised
Deirdre:Ooh, str4d!
str4d:Yes. Hi. somehow I snuck in, I'm not quite sure how, but, yeah, and for that question, I would go designing a world computer around a two hundred and fifty six bit word architecture.
Deirdre:Yeah. That's going to get old quick.
str4d:Yeah, it already is. as I gather from, from certain, uh, issues I have seen opened on various, uh, bug trackers. It really lends itself to, um, efficient computations on non-world computer architectures. and then people attempting to take things that are almost 256 bits and treat them as the same thing, which starts to work. It's close enough that you think it works.
Thomas:You guys are dunking on Ethereum, right?
str4d:Well, yes.
Thomas:Okay.
str4d:Yeah. Yeah. Ethereum like for, for those who are unaware, computers like to deal with things in words. The most computers nowadays use 64-bit uh word architecture. So, you know, you, if you're doing your math or whatever, you you process like a 128 bit number as 2 64 bit limbs. Ethereum was designed around a 256 limb architecture, and I have in fact seen someone on the LLVM mailing list requesting adding uh U256 support to LLVM so that they could just compile regular programs into like Solidity smart contracts. You support the 7-bit architecture from 1983, why not ours?
Deirdre:Like, I would also try to do that if that was my target.
David:I think we'll all be regretting the Linux kernel in 50 years. cause uh, I think having a kernel's that a, no one has to maintain is probably a bad idea, or that no one is paid or financially incentivized to maintain. Yeah.
Thomas:But th this design has survived this long. I believe that we could still be dealing with this 50 years from now and kind of accepting it as normal.
Deirdre:Is this not true of all open source?
David:Yeah. And when has a open source logging library hurt anybody this week?
Deirdre:Show me on the doll where the log4j hurt you.
str4d:So I actually have a question if we have time for another question. so cars, sort of co re you know, rolling it back in, but cars have, ODB ports into which you can plug interesting devices and like get a bunch of diagnostics, uh, out of your car, and, in a completely related field, I saw that, Tokio puts out their 0.1 of tokio-console, where you go plugin interesting tool, into your running async program and figure out like what stuff can go on with that. my question is do, uh, to the hosts, do you have any specific favorite tools for plugging into your cryptography or securities implementations? and figuring interesting pieces out about their internals, that, uh, that the audience might not know about?
Thomas:I was going to say,`go test`. If I'm trying to, I had to do this with WireGuard, like a, like a couple of weeks ago. We do this weird, crazy, like, um, to SSH into an instance on fly.IO, we run user mode WireGuard, and a full user mode TCP/IP stack, which is awesome. And it works most of the time, but when it doesn't work, it's a nightmare. So I've been doing lots of WireGuard debugging, and we're trying to build tooling for people to like, diagnose weird WireGuard problems they're having. I wound up doing some work on trying to do like a reliable probe for like, are you able to speak WireGuard in the first place? And like, I was goofing around with the protocol there because I wanted to, I didn't want to have to run a full WireGuard session for it. Like I just wanted to be like minimal number of packets for it. My general take on trying to do any of this kind of work, um, when I want to actually tinker with a protocol, especially a cryptography protocol is like, I just find the go implementation. I know that's painful for you to hear, Jack, but I tried, I tried to find the go implementation of something, and then like vendor it into a project and hack it up and then write tests for it. which like grovel through like the global variables and put prints all over the place and stuff. Yeah. So w wireguard-go made that super, super easy for me. so that that's kind of my dry, same thing happens with TLS and whether there were weird custom protocols and stuff, I I'll tend to start with a full implementation in go, and then hack it up. That's not the answer you want. Right? You want like something like tokio-console, which tokio-console is also really awesome. And I'm really optimistic about it. we do a lot of tokio here and it is very difficult to debug, so I'm excited about it. And I don't have any cool tools like that for general cryptography stuff.
str4d:Yeah. Like the, I guess the things I was imagining that people might say are stuff like, well, the, the SAT solver kind of stuff that people plug their protocols into, or, you know, GDB equivalent, but for, for that, but yeah. Print, print statements are a tried and true.
Deirdre:I also have to give a shout out to, either prop tests, like as implemented in the, in the Rust crate, or, or another, just like give me random data within certain parameters, that I can shove into a thing like a deserializer or a parser or something like that, and just run it a whole bunch and see if something panics or breaks or throws an error or does something weird. you never know, like even my own code, like we found issues because of prop testing. and that's kind of, it's just nice to be able to just, just see what happens with, if you just shove some random data into a thing that you don't understand very well. I like it.
Thomas:We had, we had Jason on like a few weeks ago and like, you know, at the end of that whole interview thingy, we talk a little bit about Tamarin and like what that whole getting started for Tamra and was at the end of that conversation, I really wanted to have a problem where like tamarind would be helpful because knew it sounds super, super easy to, you know, to do so, like people that are better with formal methods than I am, have much better answers on this. David Deirdre, you guys have probably better answers than I do too, but Tamarin seemed super awesome.
David:I've gotten very far in life with go implementations and WireGuard. Like, I mean, sorry, not wire guard, um, uh, WireShark. Looking at the bytes on the network is often very useful. You know, at some point it's not going to, like once you get to the part, that's just a bunch of AES encryption, probably not going to do you a lot of good. Um, unless you happen to see plain text instead of a, you know, trick number one: look for plain text, but, uh, debugging handshakes, or any network protocol like that, like just looking at what's on the wire and especially if there's a wire— Wireshark decoder for it, or even if there's not,like, there's a period in time where I could read TLS transcripts of handshakes, just the hex, uh, I've lost that ability, but.
Thomas:Yeah, a thing I wanted that didn't seem to exist when I was doing the WireGuard stuff, um, was test vectors, um, for each step of the handshake. So test vectors are a good one too, right. Like, you know, just like at this point in the handshake or at this point in like the construction that's building the running hash or whatever for this set of inputs, the hash should be this. I ended up generating a bunch of them. I was going to put them into a gist or something like that. Right. Cause I figured at some point somebody would want WireGuard test vectors when they're trying to build their own WireGuard implementation. So generating test vectors would be great too. Another good answer. I think.
David:Yeah, those are good. I do that a lot. Um, I have some go code that's not yet released, but it reimplement some of the like SHA-3-ish and duplex constructions from the stuff on keccak.team, except in go. And so to test a bunch of that, like testing crevasse, testing cyclist, I took their C code, and just wrote a C program that like output different transcripts and then wrote the go harness to be able to read those transcripts and then run the same thing in my go code. And just diff the raw bytes.
Thomas:It's also, I'm porting kernel code to userland or porting weird operating systems to userland. Right. I think other things like, and this is a tip I got once from Nate Lawson, right, which was super, super useful to me on a couple of different projects where I was like weird embedded operating systems or exotic operating systems or things like that. Or like enclave computing and things like that. If you have a project where you're trying to find vulnerabilities in that kind of stuff, actually testing the real system is a nightmare because there's no tooling. But it's, it's surprisingly easy to take any of that code and just port it over to something that lives in userland then kind of—you're not even emulating it, right, you're just stubbing out the little system bindings and then running the logic, which is all you really care about to begin with. so yeah, I, I w I was surprised that I had never thought of doing that before Nate Lawson told me to do it. And that's also, it's like the equivalent of the WireGuard thing, but for whole system emulation, except that you don't need to emulate anything, you just need to take their C code and port it over.
David:And expanding on that, just reading the source, always a great trick. And then if you want to be like a real professional, like Jason, um, reading the disassembly, but I am awful at that. And when I had to teach people how to do buffer overflows and the like, I've farmed that out and had other people do it.
Deirdre:Well, I think my recorder's just crashed, so I think we should wrap it up.
David:My recorder is still going thereby I've I've won the race. all right. Well, I guess we can wrap it up on that note and thank everybody for coming out.
Thomas:We love you all very much.
Deirdre:Thank you for coming to our first annual, maybe we'll do it again, holiday call-in spectacular!
David:Wait a minute. Thomas, are you cooking anything exciting for the holidays?
Thomas:The boy is cooking for the holidays. He's doing a goose. He's had it in for geese all year, every, every single family meal. He's like, can we do a goose? Can I cook a goose? Can we kill a goose? And so he's acquiring a goose and somehow smoking a goose for us for, uh, for Christmas, we've raised him well.
Deirdre:That's that's next level The goose! The Christmas goose!
Thomas:We're having a Christmas goose.
David:Um, so as someone that lives in Chicago, though, are you going to cook that in your basement kitchen or your upstairs kitchen?
Thomas:Well, actually there'll be the upstairs kitchen and the, on the deck kitchen.
David:All right. On that note, uh, have a happy holiday, everybody. and, uh, there's still time to catch the end of the, uh, of the tail greeter cure bowl on ESPN two. So go do that.
Thomas:Thanks everyone. Thank you.
Deirdre:Happy new year.