 You know, Len and I kind of started it. I mean, he was working in anonymity and privacy. He was also running CodeCon, which was a software conference in the Bay Area that ran back in the early 2000s. I had actually gone there to give a completely different talk about some bioinformatics stuff that I was doing in my internship. And then over lunch, I happened to tell him about the SQL injection defense. I mean, basically the idea was, you know, another grad student had been telling me about how, you know, people try to defend against SQL injection with regular expression-based whitelisting or blacklisting. And, you know, this guy mentions this and I'm like, that's silly because SQL is context-free. So why would you try to, you know, why would you try to match it with regular expressions anyway? The pigeonhole principle says that's always going to be able to be tricked. Wouldn't you just come up with some way to do context-free whitelisting? And, you know, the guy's like, what would that even look like? And I'm like, I can see it. I guess I'll just have to go write the code. So I did. And then when I told Len about it, he realized that there was potential here for far more than just SQL. So I ended up giving a talk about that particular project called Dejector at Black Hat in 2005. And then, you know, for the next trick, the following year at crypto, Daniel Bleckenbacher showed up to the Rump session with the so-called E equals 3 patting forgery attack. The idea there was that you could forge PKCS1 signatures by basically adding a bunch of garbage onto the end of the signature because, turns out, a lot of the tools that were supposed to be checking these signatures weren't actually checking that the signature was the right length. They were just checking the value of it. And as a result, you know, you could forge signatures this way. So Bart Pernell comes up to me, you know, the next day and, you know, asks, can you, you know, can you do the same thing for PKCS1 that you did for SQL? I'm like, well, what does PKCS1 look like? And he sketches it out for me on the back of a napkin. And I'm like, okay, that looks like it's context sensitive rather than context free, but I think I can do that and, you know, knocked it together that night in Bison. Yeah, I mean, it started out as mostly a defensive thing. And then in 2009, we realized that we could actually use it adversarily as well. That was when Len and Dan Kaminsky and I started forging SSL certificates, which they gave a talk about that at Blackhead and DEF CON that year. First and foremost, ambiguity is insecurity. I mean, if there's more than one way that an expression can be interpreted, this is asking for trouble. I mean, and you wouldn't, this can sometimes also be the case if there's, you know, if there's too many ways to express something. You know, if you think of domain-specific languages, you can think of X509 as a domain-specific language, right? And one of the ways that we forged SSL certs was actually through an integer overflow that CAs weren't really able to detect because the malicious part of the code was disguised as an arithmetic expression. So the object ID for a common name in an SSL certificate is 2.5.4.3. Well, so it turned out that in crypto API, the Microsoft implementation, the type for integer was, you know, was 64 bits because 64 bits should be big enough for anybody, right? What this means is that if you pass as no ID the arithmetic expression 2.5.4.2 to the 64th plus 3, the CA has no idea, you know, what that giant number means. So it's perfectly happy to sign the certificate signing request and send you back a certificate for 2.5.4. giant number. And then when Internet Explorer sees the certificate, the giant number overflows and it sees 2.5.4.3. Oh gosh, well, I mean, in terms of the most, I'd have to say C. Yeah, I mean, C and C++ are foot guns waiting to be used. I love Haskell. Lately I've actually been using a tremendous amount of Kotlin, mainly because we're building an Android app at work, but Kotlin is a very functional language that works well on that platform. You know, it's JVM-based and that certainly has its complications, but at least the JVM semantics are complete. You know, unlike, say, ECMAScript, for instance, where there's all kinds of undefined behavior running around. I'm a big fan of virtualization. You know, the more you can sandbox, the one thing to be concerned about there is how you're sandboxing. You know, because we've seen runtime rewriting type approaches that, well, turns out you can trick rewriters sometimes. I mean, at some point somebody was going to do a programable smart contracts language. I mean, I think the advent of Bitcoin made that inevitable. I mean, grid computing has been, you know, a thing people have been up to for, I guess, a couple decades now at this point. I mean, I took a grid computing class when I was in grad school and, I mean, shit, we're even starting to see cryptocurrencies. There's one built on top of Boink, which is actually kind of bright. It's like, let's solve problems that are actually useful for people. You know, so the whole notion of a programmable blockchain, I think, has a lot going for it. Contrary to popular opinion, you can fix stupid, but you can't fix willfully ignorant. And I really don't get the impression that the mainline Ethereum developers are really all that interested in securing their platform. I mean, I think it's an attention issue. I think they're so fixated on the profit potential of sending this thing to the moon that they're not paying attention to what's going to happen when the O-ring shatters.