Kit Rodgers, Ben Jun, and Paul Kocher (Cryptography Research, Inc.) [Entire Talk]

(music playing) [EMILY MA] Hi, everyone. My name is Emily Ma, and I'm an adjunct lecturer for the Stanford Technology Ventures Program, which is part of the Management Science and Engineering Department at Stanford University. Last week, we had Brendan Foody join us. As a 23-year-old, he has two roommates. And then collectively, they built a $10 billion dollar company in 20 months. That was pretty amazing. So he talked about how coming together was really important: building community, having deep friendships. It's really important to building a company. So let's see what that looks like 30 years out. It is my honor and pleasure truly to bring alumni back. Three amazing alumni: Kit, Paul, and Ben, are going to tell you the story of what they did in the late 90s, early 2000s, building the Mercor of that era and what happened since then. So I'm going to quickly read their bios, and then I'm going to literally hand it over to the three of them to self-moderate, which is a bit of an experiment, but I believe it's going to be quite enjoyable because they have spent their lives together building amazing things. All right, without further ado, Paul Kocher is a distinguished entrepreneur and researcher who has profoundly shaped the landscape of modern cryptography and data security, most notably as a co-author of the SSL 3. 0, TLS 1. 0 protocols. After founding Cryptography Research Inc., he led the discovery of differential power analysis, DPA, and the development of security architectures now utilized in over one hundred billion chips worldwide. You probably hold some of their inventions in your hand right now. Paul has won numerous awards for his contributions to the field of cryptography, including the Marconi Prize, Levchin Prize, and named a Fellow of the International Association of Cryptological Research, is a member of the National Academy of Engineering, and has served on the National Academies Forum on Cyber Resilience. Paul holds a BS in biology, [SPEAKER 2] interesting, [EMILY MA] from Stanford and lived in... Okay, I need you to raise your hands if you lived in these dorms. Alondra? A non-SLE year. Lantana? Okay. Xanadu? French House. Okay. That's Paul in the middle. All right. Ben. Ben Jun bailed on his PhD to join Paul as the CTO of CRI, where they built and deployed some of the world's most impactful security technologies. He subsequently ran HVF Labs, Hard, Valuable, and Fun, the San Francisco fintech startup studio which launched companies including Divvy Homes, Affirm, and Yelp. Ben most recently founded the live streaming platform sidelineHD, which was acquired into Major League Baseball's portfolio of companies. Ben holds a BS and MS in electrical engineering from Stanford and lived in, get ready, Gavilan, Lantana, Arroyo, EAST House, and he was a Mayfield Fellow, first-class Mayfield Fellows. All right, finally, Kit to the far left. Kit Rodgers is the Senior Vice President of Technology Partnerships and Corporate Development at Rambus. He has held various senior management roles over 15 years there and currently leads the M& A licensing and corporate marketing groups. A key architect in transforming Rambus into the $10 billion semiconductor company it is today. Kit previously was CRI's first business person, Joining Paul and Ben as a co-founder of the company where he led the business activities at CRI until it was acquired by Rambus in 2011 for three hundred and forty-two million dollars. Kit holds a BS in Product Design and an MS in Industrial Engineering from Stanford. Lived in, okay, get ready: Branner, Cedro, Toyon, Rains, and was a member of LSJUMB, the rowing and football teams, and was also part of the first Mayfield Fellows class. So now I'm totally gonna get out of the way and let them chat. Thank you so much for being here. (applause) [KIT RODGERS] Thanks for having me. (applause) [BEN] Thank you, Emily. Uh, yeah, we're gonna try to self-moderate, which is, uh, we were talking about it earlier, might be a little bit like self-medicate during the process of, uh, of this forum. So, um, really quick, Paul, why don't you talk about the starting of the company? [PAUL KOCHER] Okay. [BEN] How you came up with it. [PAUL KOCHER] Well, I grew up in rural Oregon, outside of Corvallis. My dad was a physics professor there, and he kept bringing home pieces of interesting computer equipment, and I would play with them and learned how they worked. And it was kind of rainy in Oregon, and I'm kind of an introvert, so I spent a lot of time around computers before I showed up at Stanford and got to here. I was a freshman. Didn't really have a plan tied to computers at all.

In fact, I really didn't ever have a plan around computers, but was going to be a veterinarian. I'd worked in a vet clinic in high school, loved animals, seemed like a really great plan in life. And got curious about things, including, came across just sort of by coincidence, the cipher used in the PKZIP program, and this idea of this math problem where somebody designed it to be fiendishly hard instead of a math problem where you could just kind of walk to the solution and it was set out for you. Um, I found it really interesting and kind of started learning about cryptography. There was Usenet then, where you could read about things online, Terman Engineering Library, where you could read these things called books. And started getting more interested. My sophomore year, I think I reached out to Martin Hellman, who came here. He's in the front row. Thank you, Marty. And he actually filtered me through one of his grad students, figuring, I think the way he set it up, I was probably interested in like cryptograms and stuff. And apparently, I passed that screen, and he invited me to participate in this Stanford crypto seminar that met every couple weeks or month, I forget, where it was people in the Valley who were interested in cryptography. And to me, this wasn't a job. This was like a fun thing to be doing. Super interesting, interesting problems. And started participating in that group, um, kind of through coincidence, ended up with this a guy at Microsoft, who I don't think I ever met in person, who would send me, um, CD-ROMs full of Microsoft software they were gonna do for try before you buy kinds of things. He was in the marketing department. And I would just break them for him, and he paid me a whole bunch of money to do this. And that kind of was paying my tuition, much better, uh, pay than hashing. Um, and so I kept sort of doing this stuff, and then the-- [BEN] Your idea of fun is different than my idea of fun. [PAUL KOCHER] Oh, well, just for the record, your idea of fun is playing football. So you'll get to that in a second. Um, the, so-- I'm gonna fast-forward a couple years. The year that I graduated from Stanford, Marty stopped doing cryptography to focus on probably more important things, like protecting the world from nuclear war. But he sent my name amongst some others to people who were interested in doing, or were looking for help with cryptography projects. So rather than go to vet school directly, I put that on hold, and these super interesting projects started coming in. Some of them were things that didn't make any money, like the, uh, the, um, well, so that some of the academic things involved thing, like the project for Netscape to do the SSL 3 protocol was one of the early ones, um, that paid a little bit. There was a project Ben will talk about a little bit called Deep Crack that again wasn't a project that paid anything but super interesting, and then a bunch of things that were also um, bringing in revenue. I did some things that were kind of researchy. There was a paper on timing attacks that was kind of the first, most interesting of the sort of side channel papers that I worked on, which I chanced across partly because of applying biologist-style thinking to cryptography. Um, so I had basically great pay coming in from these consulting projects. No business plan. Initially just me. I hired a couple of people, but then... Actually, Ben hired me. So let me hit pause and let Ben take over for just a second here. [BEN 2] Yeah. So I was finishing up my undergrad here, And I graduated one quarter early, so I created a six-month internship at a company in Palo Alto. It was called IDEO. It was Professor David Kelley's company. He's the founder of the d. school. And so I got staffed on this really, really cool project. And I was, like, living in East House, biking to work every day. But I was working on this first-generation audio playback device for a company called Audible. And if its name sounds familiar, it's because it's the same Audible that you buy books from today. But this was how it was first built. And we had a chance to work on the design and the inner guts of it, the user interface, but one of the things we needed was we had to build the content delivery and protection system. So we were talking about selling books online. We were worried somebody would pirate it, so we were worried about security. We were also giving this device to people at a discount, and we were worried. We wanted it to stay locked to the Audible system. And so I didn't know how to do this, but I, you know, read some books, tried to figure out how to do some of the cryptographic elements of this. Realized pretty quickly that I needed to find someone who could actually, like, show me the way. Um, and so I started looking everywhere. Marty, I don't know if you remember this, but I contacted you, and I was like, "Would you come work on this project? " And you said, "No, I'm too busy, but there's this young guy named Paul Kocher that you should talk to. " And I was like, "I don't wanna talk to some young guy. I wanna, I wanna talk to someone who's, like, established in the field. " So I emailed a bunch of other professors, guys who wrote books, and they were all like, "Oh, we're too busy, but you should talk to Paul Kocher. " And so finally I was kind of desperate. And so I called Paul, and over a conversation where you were actually making pasta at the time when I was calling you— I convinced you to take the project on.

And so together we worked on building what was this system. So if you've bought a book online, you've downloaded the audio component from Amazon, you're using some like, later version of what Paul and I cooked up together in the '90s based on this. And this turned out to be a really cool thing for me 'cause it gave me a chance to know what it was like to work together with Paul, and it also turned out to be a class of problem that we ended up solving at our company. Right? And so I came back to Stanford, was pretty sure I was gonna get a PhD because it just felt like the right thing to do. And then after a while I thought, I'm not really sure I want to do this anymore. I'm not so sure. So I went and I called Paul and asked that we could go hang out. So Paul, I went to visit you in your office in San Francisco, And so it had been about a year since I talked to Paul. And while I was... in that year, I'd done some research on Paul. The work he did on timing attacks, understanding how systems break. He was just really good at understanding how to void the warranty on people who designed cryptographic systems in a way that showed these things to be catastrophically failing. So he was finding all of these things that were provably supposed to be secure and just walking in circles around them. And so every time I talked to him, my mind kind of blew up. So I went there, and this was like no other time. I show up, Paul has me sign an NDA, shows me a table full of payment devices. So these are basically smart cards with, I don't think we should see the logos here. All the same logos that you expect for the cards in your wallet. So there's a card, a table full of these things, and he showed me that simply by looking at the amount of power consumed by these cards, we could look at an oscilloscope trace, we could see that the power was correlated to what the card was doing. And by extension, he could extract the key. So we had this table full of devices where Paul and his friend were saying, "Hey, Ben, we've been able to extract the keys. We could clone all these cards. We've loaded a million dollars onto that one. And now we're trying to figure out how to monetize this. We think that we should work with the credit card companies and solve this. Do you wanna come and work on this problem? " And this was just like, there was no way I could say no. I was so hooked. And it was a good chance for me just to— I just immediately stopped, figured out how to finish my term here. I figured I could spend like two years working with Paul, solving the problems for the industry, and then go back and finish my PhD. [PAUL KOCHER] And the internet would be fixed, and you can go back to— [BEN 2] Yeah, we'd fix the internet, and it would all be good. Yeah. And that didn't happen. And so that's how I joined Paul. And then we pulled Kit into the story. So everyone here has had someone in their class where you're like, "Gosh, I'd like to work with you in the future. " At least that was the case for me. And when I was taking the Mayfield Fellows class, there was this one guy in all the case studies where it was really not a good idea to be on the opposite side of the table with him in like a negotiation session or anything like that. And that was Kit. And he was just so, so good at what he did there. And we had this class where we'd meet in the summers and get together once a week to talk about what happened in our startups and talk about our experiences. That's what the Mayfield— one of the elements of the Mayfield program. And Kit's company, in his first two or three weeks of being an intern, like crashed and died and then resurrected itself. as with an alternate business plan where he like wrote the other half of it as the intern. And this company actually went and had an interesting story, and Kit went and worked in these like rocket ship internet companies as a chief of staff for a bunch of just amazing entrepreneurs, where you ended up doing all the stuff that couldn't really... The company was scaling so fast they didn't know how to negotiate a contract or open an office in New York. You'd be sent to do that. So Kit was someone that I just always kept like in my back pocket and was like, "Oh, I hope to work with him some- someday. " And then we'll get to this part. When Paul and I were kind of hitting our heads against the wall trying to figure out why the credit card industry wasn't taking our technology that we thought it was supposed to, wasn't paying us the way we thought we should get paid- We gave you- And we exhausted every other way of getting it- We gave you a call. [KIT RODGERS] Yeah, so that's how I ended up joining the company. They gave me a call and said, "We need to hire a business person," whatever that means. So I went and interviewed with them. I'm not sure it was much of an interview. Paul started the interview by saying, "I'm not sure how to interview you. " I was like, "Great. " But I decided to join the company, you know, based on sort of a model of trust that Ben and I had developed in our very tight Mayfield Fellows Program. I had actually seen Paul a few times in industry in weird capacities at various forums and events, so we kind of knew of each other, and then I decided to just go for it. And I had a couple of really exciting venture-backed startup experiences under my belt already at that point. And these guys, you know, Ben was the guy that was a double E student that nobody wanted to be in the class the same quarter he was taking the class because he would break the curve. Back then we used to grade on a curve. So that was a tough thing. Ben was, like, the guy who just practiced a ton and worked really hard and was really strong. And Paul was kind of a different type person. He's a creative person that would come in and just

look at the problem differently. And I thought with these two guys, there was a lot of engineering talent there, and if I could help on the business side, then I thought I would do it. So that's how we got it started, and from there, let's talk about the business maybe a little bit. [PAUL KOCHER] Actually, I mean, something that we've touched on a bit, you probably have already noticed. [KIT RODGERS] We're [PAUL KOCHER] really different from each other. Yes. Like, really different. And in a way that complements. You know, if anything came along, exactly one of us would have some ability to solve it generally, and almost never two, which meant that we were really, from kind of a perspective, able to tackle things like, you know, execution on really hard engineering problems and making sure that we got things that delivered successfully, or architectural vision, or having office space and business deals and, you know, not going bankrupt and a bunch of those things. I mean, so really different styles that worked really well for us. [KIT RODGERS] I think that's true. And I think one of the things then we started to do in the evolution of the company was move beyond sort of the pure consulting projects and start to, you know, with these guys, and I should say there is a much broader team that Paul and Ben attracted to the organization. When you... At our peak, I guess we were about 30 people in the end, but 20 cryptographers is a lot of cryptographers under one roof, believe it or not, compared to many other organizations. So we were black belts in security from a technical perspective, and what we would do is try to help solve different industry problems that we weren't necessarily familiar with. The payments industry, pay TV, Blu-ray disc, all these different... printer cartridges and the counterfeiting problem that they have. So we would sort of apply our consulting depth in learning about their problems and solving some very specific security issues for them, and then we would develop solutions to those problems and then license them out or build it to them or that type of thing. So that's kind of how our business evolved, and we did it across multiple industries multiple times. [PAUL KOCHER] And one of the cool things about consulting that when you're charging a pretty good hourly rate is you have... You don't have to build that many of your hours, so you get paid to learn cool stuff when you're being paid, and then you have freedom to be curious with the rest of the time. And we really kind of consciously didn't try to bill large numbers of hours. We weren't doing the kind of consulting firm style structure, but were using that as a way to get knowledge and connections and understand how we might be able to innovate and then get those innovations rolled out. [KIT RODGERS] You, you guys want to talk about a couple of the technologies or fun stories? I mean, there's some great ones. So as we were setting up for this, we were reminiscing about lots and lots of David versus Goliath stories that we had together. So it was really fun. [BEN] I'm trying to think there. The one I can think about is when we started working on pay television. And so, you know, I'd mentioned that Paul and I had worked on this Audible system, and that we'd worked in computers and security in a variety of different places. We had a company approach us and say, "Hey, we've got a lot of problems with piracy on our system. We have— I don't wanna give any details here— we have a large system where we beam our signal to a lot of people and people are hacking it, and we don't know why or how. Every time we've done this, we've had some serious problems. We'd like to figure out if we can learn what's going on and do a better job of securing it. And so that's how we would take a project like that on, where I think the company would sort of reassemble itself. There'd be a bunch of folks, usually led by Paul, that would go and try to analyze the device, try to understand what vulnerabilities existed. Um, you kind of understand implicitly what a satellite receiver looks like, how it works, how it has to decrypt programming if you're paying for it, how it's not supposed to if you're not paying for it. And our job was to go a couple levels deeper on that. How are the attackers working on this? Can we find certain things that are wrong with this? At the same time, I would lead a bunch of people to try to understand what the right way to build a satellite TV system probably is. Um, what are all the components that have to work together? What is... What's actually run on the broadcast end? When we talk about security, we're trying to talk about how things aren't supposed to break or be attacked in the world. And yet we have to manufacture these things. We have to test them, we have to upgrade fix them, we have to field replace them. All of these things have to exist. And so understanding the entire life cycle of the system is something else that we learn on the way. [KIT RODGERS] Well, there's a business model there, too, so this is a large satellite broadcaster at the time, and you can imagine they're beaming this signal down to North America, and there's a bunch of folks in Canada that would love to also access that service. But because there's not enough French-Canadian content on it, they actually can't subscribe to this large service. So what you end up with is six million people in Canada that are willing to pay 50 bucks a month or 100 bucks a month for access to this service. So you're getting, what is that? Six— Huge amounts of money that are going to put pressure on this system to break it. And so what we did is we developed a solution that was very clever that made it So if you attack the system, you couldn't break it broadly.

You could only break it once for in a single case, and then it would break your business model as a pirate. So it was pretty clever. And we ended up saving billions of dollars for that company. [BEN] But most of the kinds of projects we took on were companies that were... We had enough of a reputation where we would get called if they had a... And that was a billion-dollar piracy problem, actually. Yeah. And so we're talking very big numbers with attackers who are willing to spend millions of dollars to circumvent the system and make their own profitable business. And the thing that we specialized in was understanding how to shore up the, understanding how these systems failed, and ultimately trying to fix them. And Paul, I think— [PAUL KOCHER] Well, we also were willing to take risks. So we would often go to a customer and say, "Hey, if this works, you're gonna pay us a lot. If it doesn't work, well, we put a lot of work into it. " And those bets on ourselves paid off. [BEN] Risk-sharing. [PAUL KOCHER] They probably caused Ben some ulcers and things. So, from a broad trade-off perspective, customer's happy, we got the deal done, and poor Ben over here had to execute perfectly, over and over again. So from a success perspective, it required creative business deals, required an architecture that was going to work better, and required execution. So, without any of those three... And that's probably why there's three of us here. It's not... It's totally a team project delivering on something like that. [BEN] I mean, security was such an interesting business at the time too, 'cause there were all these digital businesses that were starting to hit real scale, where we were relying on enforcement to occur inside someone's house, in a car, in your printer, in your postage meter. All of these things had to be secured, and they were built in ways that really weren't built the right way. They were built by standard engineers working on standard engineering principles. And it was Paul's ability to see what was, you know, it was clear to see what was wrong. We'd find a problem. But Paul, there was something that you did that I don't think very few people can do, which is you ended up being able to re-architect some of these systems around managing risk so that we could build some sort of defensive system for these people. [PAUL KOCHER] This comes back to team, though. If I were here telling you all of the bad ideas that I had over the years that people on the team said, "Hey, that's not a good idea, let's keep working. " First of all, I wouldn't be here, and you'd think I was an absolute idiot. But when you have a bunch of really smart people around who trust each other, who execute well, and you filter out kind of the good ideas from the bad ones, it kind of looks like, "Oh yeah, this was a team of charming people who kind of walked from one thing that worked to the next. " Um, so there's a ton of survivorship bias that you're going to hear in just a second when Ben tells you about some of the other projects he worked on. Because the things that we, for example, other people on the team talked me out of, or I talked them out of, or whatever, we're not going to talk about. But why don't you talk about some of the other projects really quickly? [BEN] So another business we knew nothing about, but was on printers. So a printer is a device that emits paper with ink on it, and you buy ink. Printers are sold at a loss. Almost every single printer is sold under a subsidy model. The manufacturer lost money putting that printer in your hands and is hoping that you're going to buy some number of cartridges over the life of that printer so that they can make their money back. This is deemed so important that cartridges have ink in them, but it's really not the ink that's special. They have s-security chips in them that actually force you to buy a certain kind of cartridge. You've noticed this, I'm sure. And one of the things that we recognized was that the p- the technology people were using for this was woefully inadequate. They were trying to protect these very, very large business models with kind of security technology they'd co-opted from employee ID badges, things that didn't really make any sense. And the engineering side of us would look at this and go, "This makes sense. " They bought what they thought was the right part, but it didn't fit with this. And again, like, you're all looking at me going like, "Printers, really? " Yes, it's a huge business. I think at the time it was like a $40 billion business. [SPEAKER 3] Yeah. [BEN] And so we were to the place where we realized, you know, there's a different way. We can use the same technology we're using in credit cards, payment systems, and we can use some of those models to protect how these cartridges are actually communicating with the printer itself. Can we treat the cartridges as a payment system, not just as a repository with an odometer on it? And it was really Paul that helped us see that this was possible. And it requires looking at this problem that we can articulate in a very straightforward way, but thinking about securing it in a very different way. And then you would go, and you wanna talk about that first sale where we got that deal? [KIT RODGERS] I mean, look, we just, you know, we would establish ourselves through these technical consulting projects and then come back and say, "Look, we think we can solve your problems. Here's how we would do it, and we're willing to bet our financial benefit on actually solving your problems. " And that's a pretty compelling way to sell things, I think. We had some really fun other projects, but I want to move us ahead just for timing. I mean, we ended up developing a technology that became part of the Blu-ray Disc format, and in order to do that

We needed to work with the movie studios. That was a whole different industry than either of any of us had been involved in before. So we started to go down to LA all the time and rub shoulders with Hollywood executives, which is a totally different crew of cats than the payments industry, for example. [BEN] We had a box at Staples Center. [KIT RODGERS] Yeah, Center because that's where we could actually get work done and have some meetings with the executives down there. We flew to Japan every three or four weeks. Paul and I were jo- we used to share rooms because we didn't have, We were never externally funded. [PAUL KOCHER] It was years before we'd spent more rooms in hotels with our spouses than with each other. [KIT RODGERS] I mean it. Yeah. Sadly, that's true. [PAUL KOCHER] Of course. [KIT RODGERS] But actually, I think that is an important point that I'd like to make right now that is different than probably many of the folks you'll see each week come speak to you. We never raised any money from venture financing or anybody else. We never raised any money at all. So, um, the business was purely built on the consulting model initially until we had developed some solutions that we then licensed out to the industry and that type of thing. So it's a pretty different way to run a business. You don't have a group of advisors that are trying to help direct you or help you at all. And I know Ben craved mentorship and this other stuff. It was really just us and our team that we had to build the company over time. And you wanna talk about kind of our office arrangement and stuff like that. I mean, [BEN] I think one of the things that I think this actually started from even your view of looking at security. A lot of security problems occur because people work at different layers of a complicated system, and they don't read all the fine print, so they don't realize that something you do on this layer kind of jeopardizes the system from the bottom up. And so communications are really, is like the root of all security problems, really. And I think we treated that same way with how we worked, so we were in each other's faces all the time. So Kit and I would, even in the case where we were a fairly big company, we would share an office, the same physical room with a table in it, and it was just always chaotic in that room. I mean, we'd have a small little table, and so whenever his team would have a meeting, they would meet there, and I'd be, like, in the room trying to work. And then I'd be... And then we'd flip it the same way. But that enabled me to understand some of the challenges that he had in selling what we were doing, and him to understand the challenges we had in building. There's a classic tension between engineering and sales, or business rather. Sort of the engineers believe that the business guys aren't looking out for them and are overselling stuff they can't build. The business people are like, "These engineers, come on, they're just like, they're taking too long. They don't understand what we need to close the business. " And so this, this way we actually had very few direct meetings with each other where we would talk schedule. I could just feel it based on his conversations, he could mine. I remember there was a time when I listened to a customer kind of eviscerate you on, like, our schedule. And then I leaned back and I was like, "Kid, I have no idea how we're gonna do this. We're, like, totally maxed out. But I will figure out how to add that feature in. We have no choice. " Yeah. And similarly, when he would come and hear a crisis that we were having on our team, he would come over and be like, "I don't know how we're gonna do this, but I'm gonna try to buy you guys three more weeks of schedule. " And so just being that close, Um, I think allowed us to, I think, work well together. It was- [PAUL KOCHER] This kind of communication has pros and cons, though, I want to point out. Like, it's super stressful if, for example, Ben's trying to think through all the engineering implications of a strategy conversation, especially when it's not super well-grounded yet. Or if there's a customer conversation about what the customer wants for a deliverable, and things are being negotiated, and people are kind of working on positions. Those have implications that ripple through what all kinds of other people are trying to do. So we consciously did it in terms of sharing like this, but it's also really hard to make it work, and it requires a great deal of kind of trust and collaboration that a lot of teams don't have. Um, and I was super fortunate to be able to work with Kit and Ben, and we had some other amazing Stanford folks as well as part of the team who kind of could handle that and navigate that, but it wasn't easy, and especially when you kind of throw in the fog where you have no idea kind of how the future's gonna play out. It was challenging a lot of times, too. [KIT RODGERS] I mean, it's worth pointing out, so we did the things you hear about. We slept in the office, we worked 95-plus hours a week. We were doing all of those things. We took hits on our salaries for many years to sort of keep things floating and going, and obviously it paid off in the end and it was great, but it required a level of trust, that it was going to pay off that I think is uncommon, Um, and kind of looking at it, back at it now, it's hard to imagine having done that, so. [PAUL KOCHER] And speaking of like none of the three of us are kind of mercenary. Um, there was never a second where I doubted about whether Kit or Ben or really kind of anybody who was part of the team that lasted, core, um, was looking at... E- Everybody's working together as a team, and that's kind of the most fun thing that you can have in a small organization. You can't have that on a team of 200 or 1,000, um

just because, you know, budgets get too complicated, internal politics arises, you know, stuff like that. But, um, super fun when you've got a group that's working well together. [BEN] That's kind of the holy grail. If you can have a team that has a shared goal, where you have a view of the future that you all agree on, um, and at the same time you have to tactically figure out how to work together. And there were some tough, there were tough meetings there. I think I told you that they are weird. Paul doesn't, I told him this today. There was a, there was a bookstore next to our office with a children's book section in the basement, and there were times after I met with him that I'd have to go in there and, like, detox, because it was just too hard. It was really hard. And at the end of the day, you know, I'd come back to my desk, and we'd go on. But what does it mean to have that degree of trust? It's huge. [PAUL KOCHER] And also a piece of respect. Like, you know, Kit's skills are absolutely essential for the business to succeed. Mine were, Ben's were. But it's really easy as a technical person to say, "Oh, you know, those fuzzies, those business people, those sales people, those marketing people, um, are... " [KIT RODGERS] More engineering degrees than you have. [PAUL KOCHER] No. [BEN] Okay. Kit, I'm looking at the time. I think we should talk about the sale of the company. [KIT RODGERS] So yeah, So you know, along the way in our development, particularly as the business became more profitable and we started to get notoriety in our weird little cultish niche of cryptography in the world, we were starting to be—our technology was starting to be deployed now in billions of chips a year. Our business was really flourishing, and along the way, we kept getting the question about, you know, would we be interested in selling the company? What would we want to do when we grow up? That kind of stuff. You know, there was a new technology we developed where it was going to be a part of securing the manufacturing flow for semiconductor companies. And some of these gigantic semiconductor companies were saying, "Guys, we're really uncomfortable with 30 of you in San Francisco being in the middle of our multinational huge business in our manufacturing flow. " "Like, you need to be part of a bigger company. You need to—you know, we just can't, you know, rely on that. " And so, um, you know, basically what happened is a company approached us and said, "Hey, here's what we would talk about buying you for in terms of a dollar value. " And for years we had said, "No, no, no," but this time, the number was very big, and it started to get a little anxious about it because even though we were making a great living by that point in time, you start thinking about everybody else in the company and the significant impact that it can have on their lives. And so we kind of did a couple of unusual things. I mean, we actually asked all of the employees in the company to vote on whether we should sell the company or not. We said, "Yes, no, or whatever the management team decides. " And everybody in the company, all 30 of us, said yes or, you know, go with what the management team is saying there. And if you looked at kind of the net present value of the business and how well we thought we could do over time, these numbers were still exceeding that. I think you mentioned, Emily, $342 million plus the 50 we had in the bank. I mean, it was a nice exit for a company at that phase. But really we wanted to scale the business, and in order to do that we needed to find a bigger partner. We ended up finding Rambus, who's been great to us. I'm still there, and several of our teammates are still there working. [BEN] Stanford company too. [KIT RODGERS] Yeah, they're a Stanford company too. Mark Horowitz and Mike Farmwald. Yeah, so they're professors at Stanford. Although they were long gone by then. So, yeah, I mean, it really was about establishing that scale and having partners that we could continue to work with all of our semiconductor companies. We actually took a deal. This is an interesting point. We took a deal that was not the highest offer that was made to us, not even close to because Rambus was willing to structure the deal in some interesting ways where we could take care of some of the employees that didn't have as much stock ownership. We felt like we had enough between the three of us, so we wanted to give some of those funds in a non-pro-rata way to some of the other employees. And also there was this retention thing. Why don't you talk about the retention piece, which is really fun? [PAUL KOCHER] Yes, for each. So when we did the acquisition, we set up a large pool of money, sort of life-changing for each employee, with the arrangement that if they left the company, whether they were fired or quit, the money would go to charity, and if they stayed, they would get it. And this created no incentive to lay off the people who had large amounts of money coming to them, but also created no incentive for people to not keep showing up and doing a great job. And all in all, that worked great. I mean, Rambus went through, sort of unrelated to our business, some challenges right after the acquisition. There was no sense that my team, the team that was acquired was in jeopardy from that. There was somebody who actually decided he wanted to pursue a PhD at Stanford, and some money went to charity, which was great. And that relationship or that structure where if there

is disagreement about how funds should be allocated, that it goes to a neutral, beneficial third party, I think should be used way more in deals of all kinds. [KIT RODGERS] And I've actually used it a few times since then, so it, professionally. It's really good. Emily, I want to be sensitive to time and Q& A. [EMILY MA] Well, you could go forever. This is amazing. Yeah, okay, as we set up for Q& A, I'm gonna ask you a question. I'm gonna queue up something for the students, which they will know what to do. But I'm gonna ask you a question to wrap up this section, which is, if you could go back in time and share something with the 20-year-old version of yourself, what would you tell Kit? Paul? What would you tell the 20-year-old version of Ben? Because that's the average age of the classroom here. [KIT RODGERS] I mean, that's the time to take a risk. I mean, I'm glad I took the risk at that time. It's hard to imagine doing it now, for example. Um, but I, I think the thing to look for is to find partners or a group or an initiative that means something more than just solving the next fad or the hot buzzword of the day. And I had recognized with these two gentlemen that they were the best in their field of the people that I knew in my network at the time. And they had found some really interesting technical problems to solve, and that was kind of enough for me. [PAUL KOCHER] Oh, hmm. I think that for me, I want to highlight the importance of the journey. There's always that feeling like you're trying to get to some destination or you have a goal in mind. But the goal is certainly not money. It's a useful tool for doing certain things, but tools aren't goals. It's not the acquisition. It's not a venture funding round. You know, I viewed cryptography as a fun hobby, and it turned into a really great career. But if I had— d— you know, it wasn't that I was out seeking a business model, it was just more that I was doing fun things and that worked. And there's a lot to be said for that. And going to a thing you don't like and working hard on it to make it happen is possible, and I've got a lot of friends, I won't say lawyers only, but certainly a number of them are lawyers, who've kind of followed all the rules and worked hard to make partner and kind of scrambled and then kind of woke up at 50 or 60 and didn't really love what they were doing. And it doesn't mean everybody in law has that experience, but, um, just because everybody's going into AI or everybody's going into one thing or another, that might actually be a reason to go somewhere else if that's not your thing. But also, you know, pivoting around. Biology, I'm a failed vet, and it worked out great. So I did have a plan and I was working on it, but it wasn't where I ended up. [BEN] I think what I would have told myself is, I was worrying about what if, like, the right thing to do was, and including what my parents would think, and in all the mix, [BEN FORD] and I think the thing I would say is, you have a chance to make the world that you want it to be. And you don't need to start a company necessarily, and you don't even need to succeed as a company to do that. There's many follow-on effects that come from choosing to make the world the place that you want it to be, what you, amplifying what you think is right, working on just. And if you are thinking that way, the rest just kind of works out. [PAUL KOCHER] I'm gonna amplify on what Ben said there a little bit. There's been a bunch of Stanford startups where, words like lethality and surveillance are part of the business model, and to me that stuff's super creepy. And social- putting your time into things like that, Yeah, I would encourage you to not do, even if you see a business model there, or friend doing that, your job was to talk them out of it. And, [BEN FORD] yeah, technology is, sort of, it's a tool that can be used for... It's technically agnostic, but in almost every application of it, it's very clear which way you're using it. It's very clear what you're doing. Sorry, go ahead. [PAUL KOCHER] Yeah. And don't talk... And you can rationalize anything, but try not to do that. And we were lucky in some ways in that s— security is kind of clear. Usually the defense is the place you wanna be focusing in almost all situations, and we generally were— didn't have to make that many of those decisions, but there were a number of industries we consciously avoided, um, just, you know, didn't, didn't seem right to be working there, and there were plenty of green pastures to work on. So I encourage you all to know who you are and make sure that what you're doing is true to that. [MARTHA] I'll ask a question. [PAUL KOCHER] Oh, please. [BEN FORD] Great. Mark, [MARTHA] I was there, seated. How did you... I know the answer to this, but I think it's an interesting one. How did you interview people, and did you ever not hire somebody? [KIT RODGERS] Well, you're referring to a rule that we established at some point, which is... So the question was, how did we hire people?

How do we interview people? We had kind of a no-jerk rule, and I'll use the G-rated version of the word here. So we wanted to hire people and work with people that we wanted to be around, and that was true at every level in the company. So, you know, including my assistant, who's still with me. It's been 26 years we've been working together. And if people when they came in for an interview didn't treat her great, you know, they were a no-hire for us, from the beginning. So, you know, we kind of established a level of camaraderie and decency that we expected everybody to adhere to. So [PAUL KOCHER] we also hired younger, less experienced but ambitious, really smart, capable people over people maybe who had actually done the thing that we were trying to do. Job offers included generally below-market salaries, and then we had a bonus structure, which was the annual bonuses will be kind of whatever money's around, and Kit, Ben, and I will decide what those would be. There was no formula. But after a couple years of that, there was a lot of trust that was established where people saw that was working fine. So trust became a really, really important part of kind of what made the organization function. And it worked really well, surprisingly. I mean, it wasn't one where there was like a formula for people who were selling things based on how much their quota. There was no, um— [KIT RODGERS] No, I would say we've probably put the well-being of the rank and file ahead of ourselves on many occasions also, So that was a part of it, too. [STUDENT] But when you guys were talking about how you'd kind of feel like arguing in a room, you know, often late into the night. When I think about my, like, limited employment history, my favorite teams have been the ones where you felt like you could kind of argue together kind of passionately, but then leave and not hate each other and, like, be willing to come back. Do you guys feel like there was a way that you could know that, like, the three of you would be able to do that until you got into the heat of the moment? I mean, you had mentioned finding the best in the field, but it's like I've seen partnerships even like in early stages of a startup like dissolve because of- [KIT RODGERS] Yeah, we've seen it too. So many differences. [STUDENT] Like when did you guys know, "Oh, we can be around each other more than our spouses and it's gonna be okay? "" Like is there a way to know that before you're in it? [KIT RODGERS] We didn't have spouses at the beginning, but, uh- [BEN FORD] I mean, I think for me, one of the things that was helpful for me to think about when I would talk to Paul and Kit, and I'm gonna use Paul a little more directly because, um- Some of this is like brainstorming, and I would say for my colleagues, around a third of what they're saying is dumb. Like, it doesn't make any sense, or like they're missing the full picture. It's not gonna apply. It's crazy. Dumb's not the right-- It's crazy. So crazy it's not gonna work. A third of what they're doing is genius. Like, really, really genius, and it's a very different way of thinking. It requires that I sort of put my feet in their shoes. It requires saying no to some of the engineering intuition that I've been taught here. Um, it requires thinking differently, right? And then another third of it, I don't know. And so I view that, like, I view these conversations when they're healthy as, like, trying to figure out what bucket these thoughts are in. And then, of course, we're all voting together, so there's, like, this collective thing. Um, and sometimes I find that more helpful than saying, like, "We're going to have tension," 'cause that, I don't know, that is draining for me, I think, more than my colleagues. But, um, that's how I think about it. [PAUL KOCHER] There's also pieces of kind of respect and shared work. So, you know, I would have... I kept the most interior, at least the worst office space for myself. I was there working late at night, making things happen. So there wasn't a sense of here's the management and here's the people who are doing work. So that meant, I think, a bit when there was a technical conversation, it kind of did stay on the difficult merits and different opinions and different conflicting ideas, but it wasn't one where there's the person's intentions or commitment to making the project successful. [BEN FORD] But some people need to go home and think before they can tell you you're right or wrong. And you just have to make space for that, too. So it's not like we had this great kumbaya moment all the time. We'd have to, like— [KIT RODGERS] But the burying of ego was an important thing. [BEN FORD] Yeah. [KIT RODGERS] And you were great about that, right? That's a big thing. [STUDENT] It sounds like a balance of the empathy— [KIT RODGERS] Yeah, [STUDENT] and humility. Like empathy for other people's style of thinking, and then humility. [KIT RODGERS] Yeah, it's uncommon. As we've been in the world since then, we still reflect with one another that it feels uncommon. [PAUL KOCHER] Pain tolerance is part of it too. [KIT RODGERS] Yes, for me in particular. [EMILY MA] Okay. We have a small flood of questions coming. All right. We'll go. And let's check that the microphone is on. And since we only have three minutes left, maybe we could keep the answers a little short. Okay. We could, like, you know, Rochambeau who answers it. All right. And keep it short. So we're gonna try and get through all four people. Okay. Please go ahead. [STUDENT] Cool. I don't know if the sound- Yeah, it is on.

I... A little bit of a quirky question, but I've done a few things in security and related to, like, cybersecurity and stuff like that. And one of the common things overall in the field is, like, you know, the more you learn about it, the more skeptical and concerned that you get about cybersecurity and all that stuff. So I wanted to ask, what is, for all three of you, what is a piece of technology that you may or may not use in every day, but it's a fairly common piece of technology that you are skeptical about? How about you, D-? [KIT RODGERS] Yeah, you go, just one. [PAUL KOCHER] Software. [STUDENT] What's the- Do you have a specific one? [PAUL KOCHER] Just broadly skeptical. I mean- Okay, human error is the colossal problem. AI error is gonna be the next part of that. And our business was around largely trying to figure out ways to manage the risks of excess complexity. We'll chat more offline if you want our thoughts— [STUDENT] Okay. [PAUL KOCHER] Yeah, I'd be happy to continue that conversation. [STUDENT] Thank you. [PAUL KOCHER] Yeah. [STUDENT] Mic check. [KIT RODGERS] Yep. [STUDENT] Oh, hello. I recently read about the concept of harvest now and decrypt later, and I was wondering, organizations are very slow to adopt solutions to long-term problems. So in this type of world, how do you focus attention to solving these things, especially like when there's, um, a reluctance to do post-quantum cryptography? [KIT RODGERS] I think that's still a challenge. And I'm still in the industry here, and it's a challenge sometimes to get people to invest in something that's going to be a problem much into the future. I mean, honestly, for security, most of the time people are willing to pay for it when they're suffering from piracy or fraud or some other significant business, or compliance is, like, the other reason people invest in it. So I would say that I do not have a silver bullet for that. That is still a problem. Yeah. [STUDENT] Hi. Thank you for coming. [KIT RODGERS] Yeah. [STUDENT] Um, I had two quick questions, and you mentioned the human error and AI error. And the first one is, with the AI-generated code becoming more of the norm for startups, do you see cryptographic security getting stronger or weaker in the future? Like, does it become easier to do and so, um, easier to attack and- [PAUL KOCHER] I view cryptography as kind of like these almost bulletproof bricks, but we don't have good mortar. So when you start piling more and more AI-generated code and stuff around the edges, that becomes the soft part. I don't think cryptography is going to figure out how to factor large numbers. I don't think it's going to break the sort of AES cipher. But it certainly will find ways to do traffic analysis. to tie together correlations of who's communicating with who, or look at packet timings and packet sizes and figure out things that otherwise might have been too much work for somebody to identify or find bugs in software. So the things that have been kind of a struggle through our careers are going to be getting worse in the short term. Longer term, I think it's less clear. [STUDENT] Okay, thank you. My second question is more with working with a group of three. I'm sure it's nice because you can kind of vote it out. It's always odd. And what strategies did you use, however, when you came to disagreements to overcome them? [KIT RODGERS] I mean, Paul established early on. So Paul founded the company first originally. They call us founders, but it's really Paul. But he did say, "Look, if the two of you decide on a different outcome than I want, and the vote is two to one," he would defer to us. So, and we never really had a fisticuffs on something that was immutable and unsolvable and that kind of thing. But he did say that early and held true to his word on that. So, [PAUL KOCHER] for each issue, one of us is gonna be the best at it. So it was generally a sense of deferring to or somebody else on the team. So, um— I think respecting the people of different perspectives was a big key to making that work. (laughter) [EMILY MA] All right. I hate to be the person who slows this conversation down. It was amazing. (laughter) [EMILY MA] Um, so, thank you so much. Huge round of applause for Kit, Paul, and Ben! Yes! Woo! (applause and cheering) [EMILY MA] We will see you next week. We have Harry Tannenbaum, who was early at Google Nest, join us to talk about Mill and food waste and climate. Thank you. (applause and upbeat music playing)