00:04:50 · Thai Duong
[00:04:50] S4: Yeah, it took me four years to convince Bruce. So, you know, when you go to a website or you go to Amazon, even Facebook, Instagram, your computer will share information with the server, right? Yeah. And that would be, the information would travel through many, many other servers, like your ISP, your Wi-Fi routers. So you want to encrypt that information to make sure that only the server can see your data, nobody else. And there's a mechanism for that. It's called the SSL protocol, or the later version is called like TLS, like transport layer protocol. security protocol. So, um, I love those protocols and, um, back in the day, together with, uh, friends, we found a bunch of ways to break the protocols, you know, to decrypt the data. And, um, it's pretty cool. It's actually changed the internet, how the internet works, because we basically, um, showed that in the past that like two protocols, like SSL Versus 3.0, that was invented by Netscape. You remember Netscape? Yeah, yeah. 30 years ago. And then people still use it because it's still working somewhat. But we show that, oh, it's not working very correctly. If you use SSL 3.0, then people can decrypt your data. So we hope the internet really, really removes SSL 3.0. And that's one thing. The other thing that I really enjoy doing was, you know, people think that in the past you have compression, you have some data and you want to compress the data and you have encryption. And both of them actually randomize your data in some way, right? If you look at a zip file, you open a zip file, look at the raw binaries, buy data in the zip file, look random to you. Because... all the redundant information has been removed and encoded in a way to reduce the size of the file. And so one of the basic question in computer security was, would you compress data and then you encrypt or you encrypt then compress? And I took some crypto class at Stanford University and I remember my professor, he asked this question in one of the homework assignments. And the obvious answer back then was you don't want to compress and then you don't want to encrypt and compress because encryption randomize your data. It means that compression would be less effective. So the right answer is you compress and then you encrypt. And that was the correct answer on my homework assignment. I think I took that class in 2011.
00:07:36 · Thai Duong
And then three years later, we found that it's wrong. If you do that, then people can actually decrypt your data. And the way it works is pretty cool. I can explain to you. So compression actually reveals, if you look at a compressed file, you know how well it is compressed, right? Because it's softer. If it's smaller, the compression is very good because there's a lot of redundant information. That's why compression works well. It means that if you look at a compression alone, the size of the compression, a compressed file, you can tell whether the file has a lot of redundant information. And encryption hides the length. So it doesn't hide the size of the encrypted data. When you encrypt a message, you can still see that this message is maybe this long or this message may be this long, right? Because encryption doesn't try to hide that. There's some people try to do that. So it means that if you compress and then you encrypt, it means that I can see where your message has some redundant information, has a lot of redundant information. And that alone is a leakage already, right? That you don't want to review. And I gave you an example. Let's say that you take a message, like a random message that I gave you, and then you put your password together with that message. Let's just say that there's a reason for you to do that. You put your password together with the message I gave you and you compress together. And then you encrypt it. with a key that I don't know. And you reveal the ciphertext, the result encrypted message to me. So supposedly I don't have the key. I shouldn't be able to read the message, right? But because I give you a message and you get my message put together with your password, you compress together. If the compression works very well, then I know whether my message has some redundancy with your password.
00:09:46 · Tracy Alloway, Thai Duong, S1
[00:09:46] S3: You can reverse engineer between the two relationships. [00:09:49] S4: Yeah, exactly. And you do that repeatedly. Eventually, we can recover your password. And that's exactly what we found on the web encryption protocols. In the past, that's exactly what they did. They take my data, they concatenate your password, they compress together, and then they send over the wire. And then as an attacker, I can see the length And that's enough for me to decrypt. And the solution was really interesting, because they decided to turn off compression. There's no solution. And then eventually, I was at Google back then. I was born in Saigon, Vietnam. I grew up there. Then I got a job in Mountain View for a consultancy, like what we do. So I moved to Mountain View in 2011. And then I joined Google. later that year. And I did cryptography at Google, basically help people do cryptography correctly, like try to avoid the mistakes that we found. I was there for 12 years. I work on like very last number of products. Google has a lot of products, right? Gmail, Chrome browser that we are using right now. And there's a lot of people out there that want to hack Google and our products. [00:11:17] S1: Yeah. [00:11:17] S4: So my job was to hack these products before we released them to the public. And I was there for 12 years and then I left to create Calif. And yeah.
00:11:17 · Thai Duong, Joe Weisenthal, Bruce Dang, S1
[00:11:17] S4: So my job was to hack these products before we released them to the public. And I was there for 12 years and then I left to create Calif. And yeah. [00:11:30] S0: That's fantastic. I'm already fascinated by this conversation. I want to get into obviously what Calif does specifically. I want to get into some of the latest vulnerabilities. But before we do that, you know, both of you have had long careers that by and large predate what we now call AI. Are the risks associated with AI a sort of continuation on some path that cybersecurity have well understood, or are we in a truly novel area for how we should we be thinking about cybersecurity risk? [00:12:07] S2: I think it's a combination of the two. We've always known that there are security vulnerabilities in systems. And so we have security engineers who are hackers. [00:12:17] S1: Who try to find and exploit these vulnerabilities.
00:12:17 · S1, Bruce Dang
[00:12:17] S1: Who try to find and exploit these vulnerabilities. [00:12:20] S2: So the system has always been vulnerable to some degree, to a varying degree. What AI has done is it's kind of accelerated the speed in which you identify and exploit these vulnerabilities to a level where it's almost like superhuman. You know, like 20 years ago, Microsoft would release, let's say, maybe 20 updates every month. Now you're looking at like, you know, 1,400 updates per month. And that number is going to continue to grow. Just to give you an idea of the scale of things. And now, for example, to have certain systems, it may take you, let's say, three months with lots of people. Now, that may take you a few days with just one person and a very capable AI model. [00:13:08] S1: That's the reality that we're in today. [00:13:09] S2: It even changed the way how Attackers have certain types of systems, like in the banking sector, that our customers are in. You can tell some stories about that time. But that's kind of what I think. I think it's the systems have always been vulnerable to some degree. [00:13:26] S1: And now it's the AI just... accelerates that and makes it much more visible. [00:13:32] S2: And it's also made it easier for people to identify these vulnerabilities as well. [00:13:37] S1: And so, and then, you know, obviously there are pros and cons to that. But yeah, you can go into that later.
00:13:37 · S1, Tracy Alloway
[00:13:37] S1: And so, and then, you know, obviously there are pros and cons to that. But yeah, you can go into that later. [00:13:58] S3: Why don't we talk about discovering the PHP vulnerability then? Because I think this was a joint project between Calif, Wiz, and I think it was OpenAI. How did you find this? What was the process? And then what was the decision? I know you guys have gotten a little bit of pushback about publicizing it before it was fixed. So what was the process of actually putting out the statement saying we found this thing?