Special guest Filippo Valsorda joins us to debate with Thomas on whether one should or should not "roll your own crypto", and how to produce better cryptography in general.
After we recorded this, David went even deeper on 'rolling your own crypto' in a blog post here: https://dadrian.io/blog/posts/roll-your-own-crypto/
Transcript:
https://securitycryptographywhatever.com/2021/07/31/the-great-roll-your-own-crypto-debate-with-filippo-valsorda/
Links:
https://peter.website/meow-hash-cryptanalysis
https://arxiv.org/pdf/2107.04940.pdf
https://ristretto.group
https://filippo.io/heartbleed
Find us at:
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)
Special guest Filippo Valsorda joins us to debate with Thomas on whether one should or should not "roll your own crypto", and how to produce better cryptography in general.
After we recorded this, David went even deeper on 'rolling your own crypto' in a blog post here: https://dadrian.io/blog/posts/roll-your-own-crypto/
Transcript:
https://securitycryptographywhatever.com/2021/07/31/the-great-roll-your-own-crypto-debate-with-filippo-valsorda/
Links:
https://peter.website/meow-hash-cryptanalysis
https://arxiv.org/pdf/2107.04940.pdf
https://ristretto.group
https://filippo.io/heartbleed
Find us at:
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)
ordinary people shouldn't open up the Necronomicon either you'll go insane. But that doesn't mean that we don't read books.
Deirdre:Hello, welcome to security, cryptography, whatever I'm Deirdre
David:I'm David.
Thomas:I'm Thomas. Hi everyone. We have a special guest this time. our guest this week is my protege, Filippo Valsorda, cryptographer on the Google Golang team. Hey,
Deirdre:Hi Filippo.
Filippo:Yeah, I'll uh, I'll take that introduction. Hi everyone.
Deirdre:Today after months of anticipation, we're going to have the great,"should you roll your own crypto?" debate. And if we're going to put up this, this artificial construction of a binary choice, I would classify Filippo as leaning towards the affirmative: you should roll your own crypto, therefore, by the rules of debate that I just Googled, Filippo gets to argue their position first.
Filippo:I can already see myself being just associated with the,'Filippo said, you should roll your own crypto. So this is safe.' This is
Deirdre:I'm sorry.
Filippo:And yeah, well, I got myself into this very clearly got myself into this. Okay. I don't remember where this started, but what I, what I think I diverge from the fair, uh, where I think I diverge from the usual consensus of,"don't roll your own crypto, that's always bad", is that I don't actually believe most application developers are there itching to ship their own crypto into production. The application developers I encounter are scared shitless. Can I say shit?
Deirdre:yes.
Filippo:Great are scared shitless of shipping touching any cryptographic code. So when they do end up rolling their own thing and just plugging their ears and rolling out whatever they can figure out, I feel like that's our fault. We did not make our crypto easy enough, fast enough, easy enough to find well-packaged and have documented enough that– there's a whole list— but it's our fault as— well, the people that put together the cryptography, I'm not going to identify myself as a cryptographer because I know that that's something Thomas will rely on. Uh, um, but it's our fault for not providing something good enough that they could just get on with their day and not roll their own crypto. And of course, Somebody who really wants to be really, really clever will be there anyway. But you know, don't be too clever is something that you can apply to. A lot of things. I've seen known cryptographic protocols that fall apart because people are trying to be too clever. And I don't think that one is particularly specific. So yeah, when I hear don't own your own crypto, I first hear, wow. Somebody wanted to roll their own crypto? In their right mind?! And then I think that, the end result is that when users come to us and like, yeah, well,"your cryptography kinda sucks", and we are like uh, you know, this is what was passed down from our forefathers, the PGP way is the way to go. And this is a well tested, well- tried toolkit and you should not roll your own crypto. So, you know, all your objections are invalid, you are not allowed an opinion. Since you can't roll your own crypto, you shall just use our terrible toolkit that has been around for the past 20 years". And yeah, that always, to me, feels like a feedback loop that we got ourselves into. And I'm sure Thomas actually, so all of the application developers that I can't believe exist, but, I feel like this is my opening statement.
Deirdre:Thank you Filippo. Thomas, your rebuttal.
Filippo:Okay.
Thomas:Okay. I guess to start with, I'm on team,"don't roll your own cryptography". And I think that there's a weak form of this argument, like the standard debate or trick here would be to twist this into something that nobody can disagree with. And so, like the weak form of the argument would be that when I say people shouldn't roll their own cryptography, what I'm really saying is they shouldn't, like, design their own algorithms, come up with a new, authenticated encryption scheme or something like that. That's an easy argument to make. I'd be surprised if anyone here disagreed with that, although it happens, right? There was a post on hacker news this week. A really excellent if we had shown notes, I'd say we should've put it in there, but there was a differential—
Deirdre:it in there.
Thomas:Awesome. There's a differential cryptanalysis of a new Mac function called Meow hash. And it's just wonderful. There's diagrams like graphical diagrams of the differential trail that they found through Meow hash and. It's a cryptographic instruction that they came up with. And, I don't want to dunk on the Meow hash people. They handle things really well, and they seem all around good people, but as like an actual cryptographic construction, they got spanked by an actual crypto analysis. So like it happens, but that's an easy argument. And I don't think I learned much by going into should people, design their own new block ciphers, right? There's a medium form of the argument and there's the strong form of the argument. And I'm gonna, I'm gonna try and keep myself honest and say that my argument is the strong form and it is that we should generally be very skeptical of new tools that rely heavily on cryptography that are not designed by let's quote unquote actual cryptographers. And we can go back and forth on what the definition of an actual cryptographer is. And I'm unprepared to have that discussion. I think it's germane to what we're talking about, but I'm saying that. If we're looking at new systems that rely on some significant way on cryptography, they should be heavily influenced by reviewed by, or ideally designed by serious or real cryptography engineers. And that we get into trouble when they're not, I think Filippo makes some, good points.,I agree that one of them, I don't agree with the argument that people are, generally terrified of implementing new cryptography or if they are terrified, it doesn't tend to show, right. There are important IT systems that have been fielded, not only with RSA, but with RSA, with, you know, the exponent of one, right? that actually shipped. Somebody built that system with their own RSA and shipped you on RSA. it happens, I don't think it's a good thing that people are so scared of cryptography that they end up using PGP. I think that's another weak form argument. you know, nobody, on this group of people thinks that more people should be using PGP. Right. To the extent that people are scared of deploying new cryptography or designing new cryptography, they are because we made them scared. And I think that it's good that we made them scared. I think people should be in the same sense that I should be scared to do brain surgery, right. Like I would not do a good job of it and bad things would happen if I did. I think that's good that there's kind of a healthy distrust of cryptography. Cryptography is pretty treacherous. I think that the track record of new systems that are built by non cryptographers, you know, whatever we want to say, that means, is not great. And I think that, the harms that come from that systems are always externalities to us. Like we're just people, typing into a laptop, designing cool new things on computers, but in the real world, people ultimately use these things. And, when, serious cryptographic mistakes get made, people can get hurt. A really common argument for, encouraging more people to do cryptography is that we need more cryptographic tools, that the tools that we have right now that those new tools replace, those are also inadequate. That you really can't do much worse than what people are doing now is a common argument that gets made and it's not true. Even if a new, somewhat broken cryptographic tool is, on paper, better than the non cryptographic tool that it replaces. There's less uncertain certainty about whether it's okay to use that tool, right? If you're looking at a non cryptographic tool, you can tell yourself not a good idea for me to, mail sensitive financial instruments over unencrypted email. I think that, you know, it's pretty easy to tell people that that's not safe, but it's trickier for people to make that risk calculation when they're, you know, using tools that are ostensibly encrypted, and you get do riskier
Deirdre:email is impossible.
Thomas:That's also true, but, uh, so
Deirdre:Sorry.
Thomas:yeah, so I mean, I would make the strong argument that, we should be openly skeptical of— we should encourage people to be scared of doing a new cryptography. And the last thing I want to say here is, all three of you are kind of professional cryptography. People in some sense are a lot of cryptography engineers or isogenists or whatever it is that you guys are doing, right. I'm not a cryptographer. I think I get pulled into these discussions because I'm a vulnerability researcher that spends a lot of time thinking about crypto attacks. I would say that my relationship to cryptography is. I think similar to the relationship of like somebody who works on memory corruption, vulnerability, yeah. And a compiler designer, right? Like I'm not a compiler designer. I'm just a person who like, looks at the little bits of how these things are put together to see if I can actually break into things. And I like, it's a thing I'll have the same more about later about how I think they're more people need to do that kind of work. I think that ultimately there's an argument here about gatekeeping, about should we be, preventing more people from coming into the field? I don't even know that it's a good idea to get more people into the field of cryptography. And you guys can ask me more about that too. But, um, beyond that though, I just think there are other ways to get engaged with cryptography than to build new crypto systems. I avoid doing it. I avoid doing design work for crypto, for cryptography. Cause I just don't think I'm qualified to do it. And I think more people should be open about the fact that it's okay not to be qualified, to do this kind of work. In fact, people shouldn't be qualified to do this kind of work. It's pretty specialized stuff.
Deirdre:Okay, thank you. I have so many questions and things to say now. number one. There are some real ass cryptographers in the world that have like proper PhDs. Some cryptographers who know their cryptography and re and creating cryptographic protocols or primitives or constructions write terrible code. I've seen with my own eyes. There are also people. Who don't really know how to create cryptographic protocols. They don't have the foundation in that, that write much better secure code, much more understandable code. and I, I want them to have babies. I want those two people to like merge and, you know, whatever, and they do exist. And I, you know, there are some, we know a lot of them and I would say where we've, we all have a little bit of a flavor of them, including you, Thomas, even if you protest. so there's that, so the whole, like, don't roll your own cryptography unless you are a real cryptographer. even those, if some, if a real cryptographer, hands me a pile of code, a pile of C or C plus, plus I'll just be like, eh, I, that, that is no guarantee that I want to use that code.
Thomas:I mean, cue up the Al green, right. Get those people together in a room and, you know, buy them some drinks. I want that to happen too. Right. I also think there's an even stronger form of the argument where I say people shouldn't roll their own software and you could probably get me on the other side of that too. I agree completely. I don't think it's, I think that the input of a serious cryptographer is a necessary, but not sufficient condition for building a secure system. But I don't think that we have a whole lot of doubt that it's possible to find somebody to build, a secure system, maybe not in CNC plus plus, but like you can get a Rust developer in a room or something like that, or Go to developer, to build systems like that. And I think we have, a reasonably high degree of confidence that they can put a system together that's, secure, given a specification from somebody else. So I totally agree with that. I just don't know that it, I don't know that rebuts my take.
Deirdre:Oh yeah. and I'll, I'll let other people talk in a second. the prevalence of good cryptographic crates. And the popularity of the blockchain and cryptocurrencies has led to behaviors such as,"Hmm. I'm just going to add this crate to my project and I'm just going to slap some, some signatures on my blockchain, uh, consensus protocol, because I saw other people use it", and then I have to fly in and be like, please don't use this one. Please just use this other one when using this signature for consensus, because there are edge cases that really matter when you're using the signature for consensus. And if you don't, it'll result in problems, and this is kind of directly relevant to your point about like, if you're designing cryptographic constructions or protocols, you probably need to know a little bit more about what you're doing. Than if you are taking a spec designed by someone to— it took all those sort of the security properties, the privacy properties, the integrity properties, whatever it is, into account, and then is handing it over to you. It'd be like, just implement the thing. and yeah, that, that causes me worry.
Filippo:The argument about, we should get people on a consensus that this stuff is hard and, there, it can be subtly broken I'm on board with it. But that's true of all security. Like, I'm dealing with HTTP 1.1 right now, and I wouldn't like anybody to implement HTTP 1.1, please. Uh, ed, like retroactively, as in, let's not invent it, but it's the same thing. It can be broken and you can't tell, and there will be real externalities. And I agree like that. when our software, breaks, it's mostly, the damage to others. So. It's true that we need to make sure that people know that cryptography is hard. And, it should be taken with care. And again, I'm happy that application developers, generally are reaching for the thing that requires at least the ones I see for the thing that requires them to do the least amount of cryptography so that they can be like,"I used that". you know, the equivalent of" I hired IBM"."I used libsodium". if it blows up, I ain't getting fired, and that's a good place to get to. But at the same time, I feel like the whole,"we need people who are actual, cryptographers or actual experts" breaks down. And Thomas, you already mentioned that on how do we decide who is actual cryptographer and having been through myself at this point, I guess that the path of going from not a person you would consider after a cryptographer, to being a person that you consider actual cryptographer
Thomas:Yes. You went to the Thomas Ptacek school of cryptography.
Filippo:Yes. Yes. I mean, I did, I did crypto pals and, for context, the earliest things I remember doing for cryptography are watching Cryptography I by, Dan Boneh, on Coursera back when it came out and doing CryptoPals and yes, they're so good, both of them. however, then there wasn't app, I dunno, secret Cryptography II course by Dan Boneh that, only did, the ones that take that one are actual cryptographers. it's not like the Cryptography II, course is something that actually happened and we're just keeping it hidden. And it's how you graduate.
David:mean, it did happen. It just happened at Stanford and Mike Hamburg took it. Right. It just never ended up on the internet.
Thomas:So I feel like with regards to the HTTP 1 thing, right? three points there. the first is that very few people implement their own HTTP 1 in the first place. It's not a thing that an ordinary developer— there's probably a bunch of reasons why even people that are really into low-level programming or really getting into the guts of things, don't tend to build their own HTTP libraries. the second thing I would say about that is that there are things that go wrong when people build their own HTTP 1 libraries, I would be skeptical of a new system that implemented its own HTTP 1.1, right? Like we saw for the past couple of years, like the drum beat has been at BlackHat or whatever has been Port Swigger. And that the HTTP desync attacks and things like that. And essentially every new, distinctive implementation has probably introduced a bunch of very serious vulnerabilities to the internet and it's possible that those vulnerabilities are a lot more damaging than most of what we find in cryptography. it's also, it's possibly just an example of another thing that we should be really careful. But the third thing I would say is that, even with that given. I would say, I would guess that you believe that the number of things that can go wrong with a new HTTP 1.1 implementation are smaller and more predictable than the number of things that'll go wrong if you attempt to implement your own encrypted transport or your own, encrypted messaging system, right? Like just more things can go wrong. It's much harder to predict where those systems go. I can follow up on like the, what makes a real cryptographer thing too. But like my immediate thing is did you really believe that like implementing HTTP 1.1 is as hazardous as implementing, you know, a new encrypted transport?
Filippo:Honestly, having dealt with, CVEs for the Go standard library in the past months, I've dealt with more on the HTTP side than on the cryptography side. And a lot of the HTTP ones took me a lot of staring at the wall and eventually being like,"oh!", which is similar to how I learned about cryptography attacks. So that checks out. But, yeah, I'm not sure I would ever be convinced that, the set of things that can go wrong with HTTP is small and well-known and the set of things that can go wrong with cryptography. isn't and in terms of number of implementations, I think I definitely deal with more implementations of HTTP than I did with implementations of ed25519, add to I finance team.
Thomas:I agree.
Filippo:them. Um, HTTP 1 there's 500 of them. They all have different quirks.
Thomas:I, I agree, like there definitely are more implementations of HTTP you know, thank Christ than there are of, you know, ed25519. Right. That's also like, I'm not surprised that you find more or, issues with the HTTP implementation in Go with on the cryptography implementations in Go, cause the cryptography implementations in Go are very, very good. Right? is it true in the wild though, right? Like, is it Go's that HTTP you know, buggier than a random person's implementation of an entire cryptosystem right. Also go has go has a pretty expansive standard library, but the crypto parts of it are pretty low level, right?
Deirdre:Um,
Thomas:So when I think about the things that are going to break in a crypto system, you know, if you implemented it in JavaScript, I'm very worried that your ed25519 is somehow broken. Right. but I'm much more worried about how the systems are put together than I am about how, whether or not the primitives are broken. And I'm also much more worried about the things that go wrong in the joinery of these systems, where you plugged the different components in or design a protocol around it. I'm much more worried about that than I am about whether the primitives that I pulled in from the Go standard library are somehow insecure.
Deirdre:This is exactly what I am worried about. and that wasn't going to ask a question about, like, where does your gut feeling come from? That there'll be more things that go wrong with like implementing a new TLS or a secure transport rather than implementing HTTP 1? And I was going to propose that it's the complexity, the complexity of the protocol, the complexity of the system that you're trying to build in a way. Maybe with another TLS, but not necessarily TLS, maybe it's Noise pipes or Strobe or something like that, where we've seen an alternative to TLS, which has a bunch of cruft, that kind of baggage that it's carrying along with it over the years. but your point about, I'm not that worried about like the primitives that kind of live in their own nicely, abstracted box. It's how you put them together. And to a protocol or some sort of cryptographic construction. There was a nice paper recently by some, some of the lads at MIT. And when they looked at a bunch of, SSL, open SSL and forks, including Boring, Libra, et cetera, about where the vulns are in the cryptographic code. And they didn't, I was, I was sad. They didn't look at rust or other places, and they kind of came to the same conclusion that like in the like very scary areas of the cryptography, like implementing hash functions or ciphers or whatever, that's not really where the CVEs are. It's like the edges and kind of the complexity of maintaining a protocol, at least the way I read it in C and C++, this is not in memory, safe language and yes, that, what do you think.
David:The name of the paper is"you really shouldn't roll your own crypto: an empirical study of vulnerabilities and cryptographic libraries". by three people out of MIT, Jenny blessing, Michael specter and Daniel Weitzner.
Deirdre:I will point out that they're all C and C++, so not all crypto
Filippo:I want to harp on that. I want, I can, I want to take the C path of C it's programming. That's hard, but resist that temptation because I want to try to use it, to take a step back and try to move the responsibility. one layer up for, from where we are putting it now, like we're here saying that putting together primitives into, protocols is hard. And I agree, while implementing primitives is reasonably easy, which, you know, sidechannels aside, I'm not designing, implementing right. side channels aside, might be true. Like if we hand the specification of SHA256 to someone and tell them go, I am not sure. I can think off the top of my head, how they could get it wrong except sidechannels.
Deirdre:It very depends on the quality of the specification though.
Filippo:Right. So that's the thing. We have this set of blessed professionals that sit in organizations such as like four letter organizations, that handed down, specifications that are extremely hard to implement or put together or use with each other. Or we have even individual, blessed, cryptographers who put together something that happens to work. If you use it for Diffie-Hellman or happens to work if you use it for signatures. But as soon as you try to use it for anything else, Kaboom, you didn't know what a cofactor was what are you doing around here, kid? Um,
Thomas:They were rolling. They were rolling their own crypto and it didn't work.
Filippo:well, yes, but we gave them a hand grenade. and the same design done with, Ristretto for example, with something that a higher level of abstraction, something that actually thought about the abstraction which in this case, and this is like, of course my is specifically a prime order, groups where of course all the work was done by, uh, Henry deValence. And, uh, all the other authors on the spec, but, the thing is we, as"the blessed ones", put together a bunch of dangerous things, and—
Thomas:are you looking to put me on the side here where like I'm sticking up for professional cryptographers? Cause I think it's all a clown fire, right? Like that's not my argument.
Filippo:right. I feel like that moves all the way down because when the thing that we put together is, that's terrible use, for example, PGP application developers shouldn't even be allowed near PGP itself and surely that's not rolling your own crypto though, right? Like just invoking GPG, shelling out to GPG? Surely that's not
Thomas:Ordinary people shouldn't open up the Necronomicon either you'll go insane. But that doesn't mean that we don't read books. Right? So like, it's not enough just to say, you know, a PGP is an example of what happens when we tell people not to roll their own cryptography. It's a distinctive, world, historically bad piece of infrastructure that got built by the way by man cryptographers. So.
Filippo:I mean, the previous ones I mentioned though, aren't right. TLS were cryptographers, curve25519 is, oh, it was a cryptographer. but the point I'm trying to make is that. we seem to draw the line of what you can roll on your own at the highest level shitty thing we made, like people should not shell out to a GPG. I think people application developers really shouldn't shell out
Deirdre:Should they shell out to age? So they
Filippo:Right. Like if they shell out to age and it breaks, I will feel responsible, big, and I will not tell them,"Oh, I mean, of course you need to parse the error, the standard error better, uh, before you were use the plain text". No. so I will be like,"okay, I didn't build this well". and so the line will have moved down a little. So now shelling out to, uh, age is fine, but, doing the next thing lower level is not. I feel like we just didn't go through the process of making things safe enough that you can work with them by only learning about them and not learning everything underneath the problem of we joke that every paper says,"start with a prime older group". and then the problem is that if you're not a cryptographer, you might not know that when you go off to the shelf and take a thing that looks like a prime order group actually has a cofactor. Welp! Now your cryptocurrency can be spent eight times. Oh no, but maybe you are implementing a spec and if you had Ristretto there, maybe you would have succeeded.
Thomas:I think you're kind of making my case for me here. Right. So I think Deirdre was saying earlier that, big part of the problem here is the complexity of these systems. things fall apart when you get to these protocols with the crazy corner cases, but like my intuition for where these problems come from in real systems, you know, it comes from spending 10 years, finding vulnerabilities in these kinds of systems as a consultant and. what I'll say is that I agree that these protocols are crufty and they have, weird corner cases and stuff, but the simpler protocols, the intuitive, simple protocols are worse, right? Like a lot of the complexity that we look at in these systems is necessary complexity it's there because Paul Kocher looked at a previous incarnation of the same system and saw, you know, a lack of, domain parameters somewhere, or, you know, we were, doing keyed, hashes wrong or things like that. And we take it for granted. the obvious ways are the correct ways to use a lot of crypto primitives, but it's only intuitive if you've spent a lot of time working on it. Right. so I agree that if you take a random piece off the shelf, like a, you know, a curve or something like that, and try to build a system out of it, you won't know what Ristretto is. You won't know how co-factors work. you're going to, like everyone says you use curve— even Silicon valley. The HBO show says, use curve25519. none of the developers that do that have any intuition for, what setting and what set of parameters that you would use for signatures versus for key agreement and things like that. And you do, and I agree with your take that cryptographers need to deliver better kind of hermetically sealed tools that do specific things.
Deirdre:Um,
Thomas:But the fact that you can't take an, you know, well-regarded existing, tools and primitives and compose them the way you can compose else is I think part of the core of my argument, is that the systems that you build when you do that will, break, even if you use good primitives, um, and that we should discourage people from doing it. More blessed people, should build better tools with, better languages. I think all four of us would agree that you also shouldn't roll your own C programs. I'm more worried about C programs than I am about bad cryptography. Maybe I'm equally worried about those, kinds of systems. But I still feel like I still feel like I'm clearly on the winning side of this argument, Like I still feel like if you roll your own cryptography, things will go terribly wrong. And I think that professionally, we have an obligation to make sure that people understand that that's the case. And I I'm interested in kind of where you disagree with that statement. Like what, where am I wrong about that?
Filippo:Okay. That's a good question because I do agree with, everything you say basically, but then I'm left, just deeply unsatisfied with the idea that, as an industry, and this drove the software industry at large to, uh, that as an industry, we just left behind a mess and then walled it off and put a sign saying only we know how to deal with this mess. so just, you know,
Thomas:should be the name of the podcast.
Filippo:um, my favorite tab— um, label, on the Go issue tracker is'#unfortunate' and I think I'm the, uh, the major, the most common users of it. And yes, the thing is that we had"don't your own crypto" for the past 20 years. Um, well, I've only been around that long, and it hasn't yielded the results of this stuff getting particularly better that I would like to see. And I do really believe in the, ability of diversity to lead to a better result. I I've been called at times opinionated on Twitter. now yes, I, so you could say that I do believe in diversity, both from a moral point of view, but also from a practical point of view, because it leads to better results and I'm not convinced that"don't roll your own crypto" gets us, the people in the room that can do a better job than what we did so far, which didn't work, like walling it off and saying, yeah,"beware of the leopards!", it doesn't work. Especially when people keep getting eaten by leopards, there are broken cryptographic schemes, protocol and implementations and deployments all the time.
Thomas:I get where you're coming from, but I think you're probably wrong about the value of implementation and design diversity and cryptography. I think there's a couple of things wrong with it. Right. The first thing is like, we don't have full employment for the good, talented cryptographers that we have right now. I think a lot about like how, I don't know, maybe back in like 2012 or something like that, Watson Ladd interned for me at Matasano it, there's no clear indication that there isn't a full employment for cryptographers than having somebody like Watson working for me. Right. that doesn't make any sense at all. I feel like if you're a strong cryptographer, it's not necessarily the case that there's a job waiting for you right now that like really takes advantage of that skill set. Or if there is it's somewhere on the blockchain, right? I don't know that we do a good job of, putting that stuff to use, also, and I think more importantly, I think that when you have lots of different designs and implementations that are coming from all corners of the world, what really happens is that the good systems are now competing with bad systems, and the market does not judge systems by how sound the cryptography, is it judges systems by whether or not you have to put a phone number in when you sign up; it judges systems by, you know, whether it runs in a browser, or how pretty the icons are or things like that. And we have like pretty well-known clear cases where systems like that have briefly won in the marketplace and very important conversations have happened online in those systems while they were known to be broken. I don't know that the market fixes this for us. And that's kind of what you're appealing to when you say we need more diversity here.
Filippo:Well, one argument I have is that, that happened. We had don't roll your own crypto and that still happened.
Thomas:Yeah. But it could always be worse.
Filippo:I feel like, uh, we are in the same place. And, the only difference is that you're saying it could always be worse and I'm saying it could be better. Huh?
Thomas:I agree. I think that might be like, kind of the core of the debate here. Cause I don't think it can be a lot better. you know, I think that we're on a slow, like you know, the arc of history is bending towards justice. I think that things are getting better, but you're saying that they could get better a lot faster than they're getting better now. And I'm saying, I don't know that that's true.
Filippo:Okay. I liked the, uh, jobs, observation a lot because we talk about from time to time about, who needs a cryptographer? let's say, I quit Google tomorrow; who needs to pay me, to do what I do. Right. Like who specifically. I don't have a solution to that, which is I suppose, boring. but, I feel like that makes it even harder to require somebody to be a professional cryptographer before they can contribute. Um,
Thomas:Yeah.
Filippo:a good example is, the Slack there are people in the slack that sometimes I would just invite into the Slack and they were clearly like self-described amateurs and they would go on to implement amazing stuff. and eventually maybe land a job as a professional cryptographer, but how were they going to get taken seriously, especially when you can't get a job as a cryptographer, especially as a junior cryptographer. Who will hire you to train you as a cryptographer?
Deirdre:Who wants to describe what the slack is?
Thomas:wants to describe what this lack is if you have to ask. yeah, I think it's, I think it's. I think that's a good point, you know, I think in you know, an easy thing to take me down on would be to say that the industry has an idea of what a real cryptographer is. And that's simple as somebody who has a doctorate, um, you know, from a reputable program that does cryptography. I don't believe that, um, I believe a really weak form of, you know, the argument about what a cryptographer is. And to me, it's somebody who specializes in, focuses on and spends most of their time, and has for some time, on doing cryptography. I think there's a threshold of time and effort passed, which if you've spent the time doing this, I'm fine. You're a cryptographer. It's, it's totally fine. I think, you know, Moxie Marlin spike has exceeded the threshold for me. Right? Like it didn't, didn't start out as a, serious cryptographer, I think, you know, Trevor parent clearly did, but, I think there's a point at which you get, you don't have a degree, you don't have a credential. I don't care about their credentials. Right. You know that there's a question of how do people get started if no one's going to work with them. I think that there's not enough attention paid to offensive cryptography. Um, I think that, not enough people spend time actually, breaking systems. I mean, I think that there's, not enough, there's not enough time, spin on breaking systems and learning how to break systems and training people to break systems. I'm totally, I generally feel at peace with people who build, design, new cryptography, who put the effort in to do something substantive with cryptography before their first implementation. I worry a lot though, when the diversity that we're getting and the, kind of the ecosystem of tools that we're working with, especially privacy tools, is mostly people that are working with the hazmat for the first time. so I don't really care where we set the line, right? Like I'm, I'm, comfortable with almost any definition of what a, serious cryptography engineer is. And I definitely, I'm sensitive to, the need to bring more people into the field. you know, we did a lot of work with that. Not intentionally, like it was, it was originally CryptoPals was a gatekeeping tool. Right. So, but like, I'm sensitive to that argument. I'm open to it. again, I don't know that we, really need that many more people practicing right now, given how many people we have. But, I might be making a fool of myself here when I say that. So I don't know. I feel like I'm, I'm pretty okay firm ground with that,
Deirdre:I'll make the argument that, 1: cryptocurrency has drawn many, many more people to cryptography, like full on academic cryptography and like applied cryptography in the past ten-ish years. and therefore there are probably more cryptography cryptographer applied cryptography cryptographic engineer jobs, at least in the cryptocurrency blockchain space. that could be a pro or a con in your opinion
Thomas:Let me run with that point for us. This is a tangent. No one has to respond to it, but I'm going to, I'm going to throw this jab in here anyways. That's true. Right? Like there are lots of people working in mathematically-serious cryptography now because of blockchain stuff. But I think that actually makes the problem worse. I think that, so for instance, and we'll talk about this more, some other time, right? But I think that when you get lots of people dipping their toes in serious mathematical cryptography for the first time you get some weird after effects, right? So, in the field of cryptographic tokens, what should be a simple thing, right? It should be a very simple problem. How do I authenticate a user to an application with a cryptographic token? Right. It's a very solved problem. But one of like the, not mainstream, but one of leading things right now,
Deirdre:now.
Filippo:sorry. Oh, it's worth mentioning that this is not token as in cryptocurrency token, but as in JWT or PASETO or
Thomas:As As in JWT, right. JWT also an example the last generation of problems. But the current generation of problems is things like biscuits, where, the suggested implementations of biscuits for the crypto components for it involve either pairing curves, aggregate signature schemes and things like that. Like if it hadn't been for cryptocurrency, there's no way there'd be a pairing curve in our authentication and tokens, but they're fun to play with. People want to
Deirdre:They are play with, yes.
Thomas:I want to find applications for these things. And like, people's bad implementations of dubious ideas. They'll out. They'll get out there and they'll be in the market and good cryptography will compete with it.
Deirdre:I will say that there's some of that, there's some of like people dipping their toes in and either getting nerd-sniped by an interesting pairing-based curve or a new kind of zero-knowledge proof or something like that. And they think they could find an application for it in there. I don't know if they're their blockchain or their cryptocurrency or whatever other whizzbang thing that they're doing. And I am losing my train of thought. Damn.
Thomas:Before you get your,
David:types of software though. Not was saying that the biscuit people did this, but the let's make an overly complicated CRUD app is like token example of, the problem with web development today. or introducing microservices before you needed to, all of these kinds of things of people picking technology because it's cool and flashy, and more fun to deal with the dreariness of just like making another CRUD app,
Filippo:Yeah.
Thomas:Yeah.
David:another binary blob like that, everywhere.
Thomas:but do you think that the spread of microservices is as dangerous or as kind of, uh, failure prone as like the demand for ordinary people simply using authentication tokens for systems to have an intuition for how pairing curves work? Like I think that one of those problems is more significant than the other. I wonder how much you disagree with me on any of this.
David:I mean, from a security standpoint, maybe I agree with you that like, like from a monetary standpoint. I certainly don't agree with you.
Deirdre:Hm.
Thomas:You'd have to say more for me to understand what you mean by the
David:I mean, like, I think people have wasted a lot more money, designing for scale when they didn't need it, then, then have perhaps wasted using, the wrong curve.
Deirdre:a
David:Right? Like it, that affects the cryptography. But like, I, just want to make the point. these phenomenons are true across industries. And similar to what we said about like, you know, implementing HTTP, one, one is hard, implementing anything, domain specific tends to get hard. and whenever you do anything about that, you should have like enough knowledge about whatever the level is. One layer deep know you're dipping your toes in something that is dangerous so that you can then in ask the right people. makes you a cryptographer? It's knowing that the people who are smarter than you to ask the middle of doing something right?
Deirdre:This, this ties back to the thought that I lost, which is that there's, there are many people who are, dipping their toes in, to either whizzbang cryptography, or applied cryptography of any type. we would love it. I think we, the Royal, we not just the four of us here, would love it. If people who are coming up with new cryptographic constructions or protocols, or using cryptography had someone that knows about security proofs on their Rolodex, someone that they could ask, be like,"I am trying to design a thing. Can you like analyze the properties of this protocol and/or the privacy properties?" If you care about privacy or, or whatever, That's something we've been able to do with Zcash. Like we know people and we can be like,"Hey, we want to, see what kind of security proof of the properties to guarantee are available". that means we know someone usually with a PhD in cryptography who like had to do several years of like rocking security proofs, constructing them, the assumptions that they're based on so that they could, with reasonable credulity assert specific protocol attributes of the thing that they've built.
Thomas:right. And I wonder, wonder.
Deirdre:one of those on speed dial.
Thomas:I wonder what Filippo thinks of, to bring that example a little bit closer to earth, right? cause cryptocurrency is like, it's an insane amount of mathematical cryptography that goes into what Zcash is doing. Right. look at Wireguard think, look at for a model of where I think this is working well a way of delivering new cryptography, that didn't involve the person doing it, having a PhD in cryptography. Although Jason has a degree in math apparently, um,
Deirdre:um, like
Thomas:Jason, probably not like a serious cryptographer, by training or whatever, but also Jason did a really great job of bringing expertise into that system. You know, it's informed heavily by Trevor Perrin's Noise work, but also he got the UK, the formal tool that he was using to do the formal method stuff for it. a lot of formal methods work got put into that. There are, actual Tamarind is the, is the, I think the big model, but other people have done more formal methods on Wirecard, right? I'm very happy with systems like that. I mean, part of it is aesthetic. I think we're also just very happy with the choices that he made there, but like the process that he used to get to those choices was also, I think, a model of how to do it well. It's just, it's not a process that's normally used. And that's the thing that worries me.
Filippo:So, I want to take that to go back to what you said that, you're okay with even a very fuzzy, bar who's a real cryptographer, right.
Thomas:Yes.
Filippo:So
Deirdre:what,
Filippo:a bunch of times is that, and what I've seen through my own experience, because for context, people listening, uh, we know that, but I don't have a degree as in just, I don't have any of them. the us government was very unamused about that tried to immigrate. and, at some point I did, you know, crypto 1 0 1 and then, crypto one, then I did cryptopals and then I was at Cloudflare, and then I implemented TLS and, welp. Now what happened somewhere along those lines is that I, with my very honestly high self-esteem I'll go ahead and say it, and this giant pile of privilege over here was still feeling like,"Am I allowed to do this Am I a real cryptographer? Can I actually submit this CL to, the Go standard library where Adam Langley will have to review it, after the last interaction I had with Adam was a crying Wolf about a vulnerability, that was absolutely my code and not in the Go standard library. Does Adam Langley actually still run their way from me every time he sees me? Or is that a coincidence?" I did all of that in my brain. And society basically gave me when I was born,a ticket for,"no, just go for it, people will, believe it." And so if it was hard for me, figuring out when I cleared this fuzzy bar and feeling like I was allowed to, and I remember having this, whole year off, me and George Tankersley just texting each other all the time,"There are no gatekeepers! can walk up to Matt Green at Real World Crypto and he will answer you!"
Deirdre:That was me with Dan Boneh crypto would be
Thomas:they're all. Yeah
Deirdre:and he's like,
Thomas:They're all very,
Deirdre:read it.
Thomas:they're all very nice, if anything, I have more privilege than you do because I'm an American citizen. Right. And I've spent like, more than a decade doing consulting work in this field. And you have your set of experiences and I have my set of experiences and you're, you're better at cryptography than I am. I wouldn't hesitate to say that you're qualified to do this work that you know, or to grant other people permission to do the work. Right. I don't feel like I'm qualified to do this kind of work. People offer me money to design systems that use interesting cryptography. And I go out of my way to turn it down. I think the world is a better place because I do that, right. Like I say, over and over again, I'm not a cryptographer. I try to refuse design and implementation work. I feel very comfortable doing vulnerability research, but I don't feel comfortable building new crypto systems.
Filippo:But the question is how many people do what you do when they're not qualified and how many people instead, do it when they would be qualified. there are people every day who roll crypto without being qualified, because they've never been told they failed at anything, uh, because, they always, failed up or something like that. And so they just go and do it anyway. They hear,"cryptography is hard, and I'm clever. and I will definitely succeed". And then there are people who hear, cryptography is hard and hear, well, I don't have a degree. What can I do about that? and I'm not convinced saying over and over that cryptography is hard, is swaying the first class of people, which we want to stop doing cryptography, any more than it's, aimed, at the same time I know that it's swaying the ones that be doing cryptography aren't
Deirdre:That is a very interesting angle on that because I have seen people designing protocols and slapping together, like curves and hashes and whatever, and they're trying to do something. I'm not really sure what they're trying to do. And I don't know if they know it either and I'm just like, oh, oh no. Oh no. Like, eh, They are doing it. Thomas is not doing it. And I think I would rather Thomas doing it because he's seen so many pitfalls. So I think you have you're onto something there Filippo
Filippo:in chat, we have, str4d saying I was most definitely the second group. str4d!
Thomas:Which is the remind me of the sec, the second group is people that should be doing cryptography, but aren't because I'm telling them not to.
Filippo:Because they feel like it's too hard and they're not allowed to. And for context, str4d has implemented the Rust implementation of age and is a lot of the reason age is robust is because there's str4d's implementation over there.
Deirdre:and,
Thomas:people, but he's
Deirdre:str4d is hand in hand in the guts of a cutting edge, zero knowledge recursive proof circuit, str4d is a cryptographer now.
Thomas:But like the thing you'll try to pin me down on is that people without degrees or without degrees in cryptography, you know, should be doing cryptography. And I agree with that. I just think that the norm should be that people should have to talk themselves into doing it. I think that people should have a strong feeling about whether they should or shouldn't do it. the thing I would push strongly against is the idea that people by default should feel like it's okay for them to, you know, build those kinds of systems. The people talking about doing this stuff like that, they're not doing it on a whim. they, in, before they started doing the stuff or they put the work in to build a network of people that they can rely on to help them do that. But they're not just doing it on a whim. Yeah. Yeah
Filippo:I'm saying something a little orthogonal to that, which is that I've been in the room of people that do end up implementing cryptography. And what they have in common is not that, they all put in a lot of work to convince themselves and build to this network, which you are right, is what we want people to implement cryptography to do. But they're the people that are probably had the easiest time, me included, convincing themselves that they had done that. And that ties to a how much privilege you have again, because when I went to a conference and I said, yeah, I would like to get on stage and talk about cryptography. Nobody questioned me. Nobody went like,"dude, you don't have a degree get out of here!" and I probably wouldn't have had that experience if I wasn't, uh, a man, white, and, uh, full of, you know, extrovert, uh, willingness to get on this podcast and for example.
David:part of that is like you submitted something to the CFP, you wrote an abstract, you gave slides, whatever it was. And like it turns out that, doing that is actually somewhat hard and most people are really bad at it. so simply doing that, that brings you into, they probably would not have let you talk without, maybe I'm going to eat my words here, cause I don't know what conference you're talking about, but you weren't going to get invited to keynote. You had to submit to the abstract, then eventually somewhere throughout your career, you get invited to, to come without applying. Right. and so going through that process is just kind of something that happens in all fields, or at least lots of, We'll say computer science-ish or engineering sub-disciplines, right. Like, here's
Thomas:can report.
David:in college who goes to college, learns they're supposed to get an internship, feels horrendously under-qualified at said internship. Maybe eventually after a few years kind of understands,"okay, you know, I don't really know how all this stuff works, but like, I know what to Google. I can figure most stuff out now", goes and gets a job. or goes to grad school. Then a few years later, it kind of figures out the things that they're actually good at. Not as good at the stuff they like and so on. I'm to some extent talking about my own experience with software engineering and cryptography, but I could just as well have been talking about almost anybody in computer science or in mechanical engineering or right, Part of it is just growing up and then figuring out where you stand within the plethora of skillsets and like one that does and does not matter.
Thomas:As a parent, I can report that it also applies to the fields of biochemistry and to geology. so it seems maybe universal at least in the sciences. Right. I agree that we're trying to optimize for competence. We're not trying to optimize for confidence. and that that's a real problem, right? and we do need better systems so that we're not simply saying that we have, a governance by the people that are most confident. Because that's how we got PGP. Um, so I'm with you there. I think it's a strong point, right? I just think that the opposite take doesn't work either.
Filippo:But my, uh, my own path is, I think actually kinda different from the, getting in front of a number of committees until you figure out what your skill set is. I think I'm here. Thanks to my confidence. and it's not that I don't believe in my competence because again, see above my confidence, but, what got me the position to be taken seriously doing cryptography was working at Cloudflare and I went to work at Cloudflare, because I made a website. with a flat, UI toolkits or stuff like that, that checked for the Heartbleed, vulnerability. And it did that in the most buggy way possible. It was not good. but I, you know, went ahead, built it and I was probably rolling some level of my own crypto. and then I just had the confidence to go to all the conferences, talk about that website and then went into all of the, interviews at the Cloudflare London office, and basically told that story, that very same story, three times in a row to three interviewers, not four, because the fourth was a Recurser. And that was just basically a chat about, so what did you work, uh, on that records, but, then I was at Cloudflare.
Thomas:Yeah,
Filippo:and then I was taken seriously.
Thomas:You put a lot of work in before you did the Heartbleed site, right? you were actively engaged in cryptography, substantively and actively engaged before you built the Heartbleed site, your entry into cryptography wasn't one day I built a website for Heartbleed right. it's true. That what we want to do is take that path and remove the Filippo levels of ego, that are required to move forward with it.
Deirdre:And that's compliment,
Thomas:No, I
Filippo:I'm saying.
Thomas:by the way, I don't see you as a particularly egotistical you're, you're much more level headed than I am. Right. I buy that, that's a problem that we need to solve. Right. But I wouldn't want the takeaway from that story to be, you know, once I built a website for cryptography and it was just a small thing for one single vulnerability. And from that point on, I should be implementing TLS. Cause you did a lot more than that.
Filippo:I'm not saying that's what may be qualified for it, but I'm saying that that's what made me appear qualified. The reason people took my cryptography seriously was that. If I had done all the same work, but then didn't just run with the website, which was not the most impressive thing I had done at that point. and just show everybody how shiny the website was. I don't think I would have gotten the job at Cloudflare and then I don't think I would have been taken as seriously. So I really like how you put it as we are trying to select for competence, not confidence. And I honestly am coming here without an alternative solution. So I'm willing to yield on that in that I agree that we need to something, and"don't roll your own crypto"s where we have now. My argument it selects way too much for confidence and not enough, for competence, but to be fair, I'm not suggesting alternative solutions. So maybe I do lose.
Deirdre:one alternative that I have heard. So I don't take credit for this is don't roll your own crypto alone, go with a friend. And maybe if you are super confident that you and your buddy who are also super confident, will not result in the most competent results of your construction, but having two is better than having one by themselves. at least you have more bites at the apple of figuring it out or, figuring something terrible has gone wrong. But generally the vibe is, you know, Bounce ideas off someone. See if you can ask for, review or help, or, if you happen to be able to reach out to someone and be like, I'm trying to construct something. And I am trying to do an analysis of the protocol. if you happen to know someone who has done that sort of thing in the past, or you can afford to contract out to people who could do those sorts of services, much better possibility of better results than just Yolo. I'm just going to go give it a shot, myself.
Thomas:I think if I was going to take all that and make my own closing argument for all this stuff, first of all, I would note that Meowhash was a team. so it was more than one person doing it. don't, want to sound like I'm talking. love so much that we're in a world where Meowhash happened. It was great. but like, I would say this, I would say that my closing argument here is that when we talk about the kinds of people that you three seem to want to be doing more cryptography, but the type of people that you, think that the field doesn't attract enough right now that it repels them and lets other people that are just confident and talk a good game. And by the way, like one of the reasons I don't do cryptography is I think that my, my talking game is way, way better than the actual doing game. Right. I'm very sympathetic, but I would say that those people, that you're thinking of that should be doing cryptography are I think, part of a subset that you're not really acknowledging, that in your head, your mental model of these people are people that are engaged with cryptography. Most of those people, I think are people that I would probably agree are qualified to do cryptography, but that when, I say,"don't roll your own cryptography", it comes from, a lifetime of mental scarring from Hacker News, where I know that the people that are advocating for,"you should roll your own cryptography, it's all just gatekeeping", are people that have not put any time, don't want to put any time in, If you found the Meowhash vulnerabilities in their stuff, they would spend seven weeks talking it down and saying that it wasn't a real thing. And which Meowhash, by the way, did not do that. but I think that's the kind of people that you're bringing in when you open the field up. And I would just say that my close here is just to think about when you say more people should be doing it, which people are you saying? Like which paths are they taking into the field, whatever path that you like there, I probably like it too. The thing that I'm very worried about is the no-path thing where we need to democratize cryptography to the point where anybody can sit down, just,"I have a problem, it needs cryptography, here's a shelf full of crypto potions, I'm just going to pour a couple of them into the cauldron and, you know, see what happens". And I think that that's not an abstract or speculative concern. I think it's the norm. I think it's what really happens in real systems. and it gets people into trouble.
Deirdre:which is why we need things like Ristretto.
David:The one thing that I would add is just that selecting for confidence and not competence is like a problem in all fields in all places. and so I don't think that crypto is unique to that. Having more ways to learn is I think definitely a positive thing. I don't really have a strong opinion on the messaging at the moment.
Thomas:guys, I feel like people got their money's worth out of the donations the me versus Filippo debate. I want to say one more thing before I go, which is just that I heard my voice recorded for the first time when I listened to the podcast that we recorded last time. And what I've learned from that is that my beloved Sean Connery impression is nothing. It's nothing. I can't impersonate, Sean Connery at all. It's all been a lie.
Deirdre:you have a closing?
Filippo:I think my closing was earlier one where I said that, uh, I, I agree that we need something to select for competence, and I don't have a good alternative, so I really am not showing up with that contender. however, I will point out something, Thomas, you spend way too much time on hacker news and you know uh, and there you end up seeing a lot of people who definitely on high, on the confidence level in where you, where you see, oh no, these people will get in. I feel like these people are in any way. These people are on News, commenting on cryptography and they are going to write cryptography anyway. And I'm worried about all of the ones that are not involved in cryptography, which I think you have a very good point, like being involved in is how you eventually qualified almost by osmosis, maybe by being on the Slack. but I'm worried about so many people that don't even end up in that set because they're like, oh no, I'm not smart enough to get involved in that.
Thomas:A future, a future episode of this podcast will be the ways in which hacker news is misunderstood and underrated. I'll just say it's the mirror to the field that we're holding up to the field that you actually work in rather than the field that you say that you work in
Deirdre:black mirror.
Thomas:again, misunderstood underappreciated.
Filippo:afraid. You're right. But I refuse to believe it.
Deirdre:yeah.
Thomas:I totally, I, a hundred percent understand Filippo. Thank you so much for this.
Filippo:Thank you. Thanks
Deirdre:much.