Podcast
Root Causes 496: E2EE Gmail
Hosted by
Tim Callan
Chief Compliance Officer
Jason Soroko
Fellow
Original broadcast date
May 19, 2025
Gmail is now end-to-end encrypted for all recipients, regardless of the receiving client. We explain how Gmail accomplishes this trick.
Podcast Transcript
Lightly edited for flow and brevity.
Tim CallanSo Jason Google recently made an announcement about end to end encryption in Gmail.
Jason SorokoSo we all know about S/MIME. Enterprise grade email encryption, signing, et cetera. And a lot of people are looking at what Google's saying and saying, geez, this is interesting. What was the breakthrough? Tim, and I'm asking this rhetorically, what was the breakthrough Google made in this is that their trust of what they're doing is you can send an email to whoever you want. It'll be signed, encrypted, and anybody who's using Gmail, not just amongst other Gmail users, but other email systems. This is fascinating, and so there's obviously a fundamental difference in between how S/MIME works and how Gmail is doing what they're doing, because the holy grail of consumer grade email encryption is to be able to allow people to encrypt and sign something to somebody who isn't necessarily trusted in a centralized system. Because you they want to be have an outlook user,Tim CallanThat's the whole thing.Jason SorokoSo any idea how they're accomplishing that?Tim CallanI was going to ask you that if it works with certain other systems, then this could be a walled garden between I'm making this up Google, Microsoft and Apple. If it works generically, just anywhere, then it's on public roots.Jason SorokoSo let me tell you how it is, and it's this podcast is not so much about the Google end to end email that I think that their publishing of that information is terrific. Go check it out. It's fascinating stuff, but I want to tell you about the guts behind it and the implications to where you generate the key defines the capabilities of your use case. I love the term you used, walled garden. So we're talking about, all right, Tim, if you and I want to do business together in a walled garden, right, we're going to use a centralized certificate authority. And define, we define and maintain. And there's going to be a key pair generator for you, a key pair generator for me and if I want to do business with you, if I want to send you something, I'm going to go get the public key, and I'm going to encrypt with the public key, and I'm going to sign with my private key to you, and away we go. But the trust was bestowed to us by a centralized certifying authority.Tim CallanThat we just agreed to. If we just said, Look, we're gonna do this. We all feel good with it. Everyone's good. Let's move forward.Jason SorokoI trust the CA. You trust the CA. I don't have to trust you. I trust our trust is now implicit, all right. What happens? So what's that perfect for? Just before go any further, that's perfect for when you want to carefully bestow trust to a finite number of a population.Tim CallanAnd you know who it is, there's a great deal of control, and even if it's not static, it is slow enough in its evolution that it's easy to onboard.Jason SorokoBusiness to business partners. I know the partners I want to bestow trust to, so I'll put you on my...Tim CallanWe got a whole big process. There's a sales process, and there's negotiations, and contracts are signed and there's not a lot of ambiguity.Jason SorokoBusiness partners, contractors fall under that category, B to B, B to E is the other one. A company knows who its employees are, so you want to carefully bestow trust to your finite number of employees. And it's all coming off of a private or...Tim CallanInside a very limited consortium where we know who our members are.Jason SorokoYou got it exactly. Exactly correct. So B to B and B to E are ideal use case categories for centralized certificate authorities. Because carefully bestowing trust to a finite population. What happens, Tim, when you are B to C and there's a unlimited population.Tim CallanAnd traditionally, that's where you need public certs, because what a public certificate scenario really is, is the walled garden is the earth. It's the same thing as a walled garden, only the scope of the walled garden is everybody.Jason SorokoSo what happens if you're Google and you've just told the world don't use publicly trusted certificates for the purposes of client authentication and signing and encryption. You've just told the world don't use publicly trusted certificates.Tim CallanWell, you've told the world don't misuse publicly trusted certs. That, I think, is the difference. They they want certs to be used, to be understood and used correctly according to the expectations for how they're going to be used. Their real complaint is about this kind of haphazard thought list general use. Just spread it around everywhere they want things to be precise and controlled and thought through.Jason SorokoWell here's what I can tell you, they didn't choose that route. They chose a private route. Private individually to each client. The key pair generation. In the case of Google's end to end encryption platform for Gmail, the keys are generated at the client side. In other words, every single client kind of has a little mini micro CA in it. So it's completely decentralized trust. We're not talking blockchain, but what I'm saying is it's the opposite of a centralized CA. In other words, the key pair generation is happening in your Gmail client. And what Google is saying is, we will use a secure element to put the private key and the public will be shared through us. And so Google becomes kind of the the public key directory of this massive system.Tim CallanSo I like literally when I create my email in Gmail and I send it to you, you are getting a public key for me that is generated at creation time in the client, correct? So then, if I log into the same gmail account from more than one machine, I'm giving you more than one public key. So it's not yoked to an account, it's yoked to a piece of hardware.Jason SorokoYes, in fact, it's to an app, which is hardware, hardware + app fair enough, because you can have multiple apps, etc, etc.Tim CallanAnd they'd be different. So I send you Gmail from more than one app on the same machine. I'm giving you a different public key for each.Jason SorokoNow, I'm presuming, I don't know this for sure, but I'm presuming it's similar. Remember, we had an episode about public key directories and the magic of just how they're changing the world, for how to do all of this, B to C, and how am I doing PKI magic without having this CA in between? Well, it's because somebody's actually doing the hard work of having a public key directory. So in other words, when you're sending me the email, you're not necessarily sending me the public key. Doesn't have to work that way. It could work at a public key directory level, where, if you and I are doing some chatting together, you at least have an address where to look and get my public key. There's there's all sorts of schemes, and I'm not saying which one Google has chosen, but there's many ways to do it, is the point. But where you generate the key defines what you could do with the use case. And if you have a client side key generation that really extends your use cases to anything where you don't necessarily have a walled garden, you can trust anybody who basically downloads Gmail and starts using it, and that's how they're doing it. They're they're doing it with a a reverseprivate trust system. They're not using public trusted certificates. They're not using a private CA, in the traditional sense of trust bestowing to a finite population. They're saying, y'all can generate your own keys and join the party. And in fact, Tim, that's how Fido works. B to C. All good B to C systems have the key generated client side. Fido, does it, and now Google's doing it. Tailscale, does it. That's how they're all doing it. And so it's just this is a continuation of that public key directory story with client side key generation being the magic that's being sprinkled on all B to C scenarios. And I like it. I really do like it. And I have one final point to make, and I'll turn it back to you Tim, which is for those of you who are CIOs, CISOs, and you look at this Google technology, and you're like, Whoa, do I need S/MIME anymore? Because S/MIME is a controlled environment, you can revoke smime certs. Yeah, you can have escrow of smime certs that are lost. You can all those like that, highly controlled, finite population environment requires something like S/MIME, Google's keys that are generated anywhere. Do you as a CIO want just anybody? No, you don't.Tim CallanThey're doing different things right, like a and and a Gmail, end to end encrypted system is it's right there in the woods. It's really about encryption. What it is about is to make sure that no intruder in the middle can read your email. Doesn't do anything else, doesn't doesn't authenticate you in any meaningful way that's done through the Gmail system, in your Gmail address.Jason SorokoCorrect, that's how all the attestations work.Tim CallanS/MIME is accomplishing different things.Jason SorokoYes, it is. And that is my point. That's where I wanted to land on this podcast, which is for those of you who look at S/MIME and go, oh, don't need that anymore. Nothing went away. It's just a it covers the B to B and B to E scenarios, but there was something lacking in B to C email. Gmail just showed us how to do it.Stay informed with expert insights
Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!
