Stop Using Encrypted Email with William Woodruff Artwork

Security Cryptography Whatever

Some cryptography & security people talk about security, cryptography, and whatever else is happening.

Security Cryptography Whatever

Stop Using Encrypted Email with William Woodruff

August 22, 2025 • Security Cryptography Whatever • Season 4 • Episode 12

There was a bug in an OpenPGP library which finally gave us an excuse to tear encrypted email via PGP to shreds. Our special guest William Woodruff joined us to help explain the vuln and indulge our gnashing of teeth on why email was never meant to be encrypted and how other modern tools do the job much, much better.

Watch on YouTube: https://www.youtube.com/watch?v=IoL3LfIozJo

Transcript: https://securitycryptographywhatever.com/2025/08/22/stop-using-encrypted-email-with-william-woodruff

Links:

- William Woodruff: https://yossarian.net/
- https://www.latacora.com/blog/2020/02/19/stop-using-encrypted/
- https://www.rfc-editor.org/rfc/rfc4880
- https://codeanlabs.com/blog/research/cve-2025-47934-spoofing-openpgp-js-signatures/
- https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_GnuPG.html
- https://www.rfc-editor.org/rfc/rfc9580.html
- https://www.tumblr.com/accidentallyquadratic
- https://www.w3.org/TR/xmldsig-core/
- https://support.yubico.com/hc/en-us/articles/360013790259-Using-Your-YubiKey-with-OpenPGP
- https://www.rfc-editor.org/rfc/rfc9580.html#name-signature-packet-type-id-2
- https://www.rfc-editor.org/rfc/rfc9580.html#name-key-derivation-function
- https://en.wikipedia.org/wiki/S/MIME
- https://delta.chat
- https://signal.org/blog/the-ecosystem-is-moving/
- https://phakeobj.netlify.app/posts/gigacage/
- https://x.com/dakami

"Security Cryptography Whatever" is hosted by Deirdre Connolly (@durumcrustulum), Thomas Ptacek (@tqbf), and David Adrian (@davidcadrian)

0:00

almost all PGP encrypted emails are larp. they're encrypted because, you know, people feel cool, encrypting it, they're like play acting. It's like a, you know, Nerf swords version of, of whatever it is they're doing. Hello and welcome to Security Cryptography and Whatever I'm your host Tom with. am Deirdre. Oh, we're running with wrong time. I'm always second. I'm always second. I know, but oh well. and with us today is William Woodruff. Uh, I spent, I'm a little wrecked. I spent the day moving boxes and bookshelves and furniture from my mom's office to clear out some space for her, which is a thing I would rather do than ever read a PGP email message. Um, which is what we are here to talk about with William Woodruff today, the secure email ecosystem. Um, and I kind of think we should kick this off with the reason we're talking about that this week, which is, uh, I think there was a bug. There was a bug this week in open pgp. Yeah. Oh it was, it was an open PGP js. Does anyone know how it worked? No, It was malformed packet. It was like, it was some kind, it was a packet of confusion of some sort. I, I, I was not being serious. Do, do you three really not know how this bug works? I really do not know how this bug works and I'm excited for you to explain it to me. You had one job. This is the thing we talked about that you were gonna talk about. Oh my God. I read the other things. told me to read the packet format and I looked at it and I was like, oh, cool. The new packet formats from 1998. I think we should talk, I think we should talk for a little while, for a very short while about how PGP messages are formatted. Can I ask if any of the three of you know how a PGP message is formatted? It is. Binary data that's been ASE armored and for some reason has a CRC check sum at the end. O if only that were the case. Oh. Go on. This is the point where somebody comes in and explains why it's not the case. All right, so there's a blog post from, what is it, the name of the, it's a good Find Code and Labs. They deserve credit for this, right? So they have a vulnerability that allows you to, um, spoof arbitrary open PGP messages as valid. Um, and that message opens up with the claim that PGP has a relatively simple packet format and then points to the RFC where they explain the grammar of the PGP packet format. RFC 48 80. this is RFC 95 80. Oh, Um. So an open pg p message is a packet or sequence of packets that adheres to blah, blah, blah. The following grammar, which is open PGP message, consists of encrypted message or sign message, or a compressed message, or a literal message where a compressed message is a compressed data packet. And a literal message is a literal data packet. It goes on and on like this, in like a pseudo BNF thing. And any of these things can wrap any of these other things. So it's like an arbitrarily nested, you know, set of packets, like, you know, type length value packets. Um, And, And, the packets have types. So this is like every network protocol has like a typed packet format. So why, why are we, uh. like thi this, like this packet format has apparently been a nightmare for PGP implementers for like a really long time. Um, there was like in the, up until like, I guess the late two thousands, somebody's gonna call me on this, but it's some, some, some, somewhere around that timeframe, there was a network of PGP key servers that everyone used. Um, there was like a global internet key server network where you could register your keys. This is by itself a bad idea and we'll get into why that is later. But it existed. Um, it stopped idea because the way the, the keys are used, like we have, we have bulletin boards for certain kinds of keys. That is not the worst thing in the world. Yeah, you're definitely right. And we'll get into like PGP as like a. PGP is like a strata for like signing things for like signing packages and things like that versus for secure messaging. Right. Um, but like, so the thing that takes my understanding is the thing that takes the key server down is a series of DOS attacks on the key server stuff based on packet parsing problems. Like there are ways to make the parsing of those packets go quadratic, um, so that you can send like, you know, fork bombs of PGP packets. William is nodding, so I think William knows something so I can stop talking. Yeah, well, I, the, the main thing that I remember was I think the, the big PGP key server explosion was in, I wanna say 2018 or 2019. And that was because That's far too late. Yeah, shock shockingly, I, I would say, um, and it was, yeah, they, they, it was, it was trivial to make, uh, both GPG and other PGP backends. Not that there's so many, but the other ones as well go quadratic on key paring. Um, Which keys in, like, keys in PGP messages are themselves packets. Yes. Yeah. I guess I guess I'm using key interchangeably with what PGP also calls a certificate, but, Mm. which is a set of packets. Right. So like it's, I was gonna say, it's easy to explain and complicated in practice, but it's not even easy to explain, right? Because there's a grammar in ten three of that RFC, but then there's like, like 12 different exceptions to the grammar. And like all sorts of weird shit happens, and there's just no reason for any of this stuff to exist in the format. But it does, uh, it's like a 1990s format that we still live with today or some people do, right? And there was an open P pgp JS of vulnerability in the handling of that format, and that vulnerability was, um, you take a valid signed PGP message, um, from anywhere, and you tack onto the end of it, an additional compressed data packet. And that is the vulnerability. The, so the signature on that message for what proceeded the message is valid. It, um, the, whatever the, whatever the hell you tacked into the compressed data packet at the end is not valid. It's just a random thing you slap to the end of the message and open P-G-P-J-S returns the data from the unsigned thing that you slapped onto the end of the packet. That's the whole bug. The whole bug, which is like, I, it's interesting, right?'cause this is also like an XML dci SAML vulnerability type situation. It's kind of the same idea, or it's a similar vibe as, uh, what's, what's what's called XML signature wrapping. Where like in that format, there's this idea that like, you have a single XML document and like a subset of the tree of that document is the signature and kind of the way that HTML has like IDs for like different, like different elements in the document, right? The signature in that little, that subset of the document has an ID that points back to the part of the document that's signed. Just saying this out loud, you can hear how fucking crazy this is, right? But that's how XML dsig works, right? But like you sort of give X ML-DSA, pa, you don't give it a pass. That's literally the worst format. But like literally the worst format that there is. Right? But like, open PGP isn't XML. Like it's not, it doesn't, it's not supposed to have that kind of flexi, it, it doesn't even, it doesn't benefit from that kind of flexibility. It's not like an extensible grammar or whatever. It's not like, it's not XML, but they manage to re recreate the vulnerability anyways. Um, like a funny thing when you see like people in that ecosystem responding to this bug is just like, well, this is an implementation failure, right? Like, and it is an implementation failure, right? Only open P-G-P-J-S has this bug, right? But like, there's the obvious objection to that, right? Which is it shouldn't be possible to have this kind of whatever. So that's. Have, like have you ever read open pg p code? Like my, my theory here, I, I did this once, um, when I was trying to figure out like, uh, you can talk to like UB keys through some PGP protocol. It's separate from PIV and sometimes like yeah. those that lets you do operations that, that aren't exposed in piv like curve 2, 5, 5 19. And so I was trying to understand like how open PGP did this at one point. And I, you know, I went to grad school, meaning I've dealt with some like bullshit code that wasn't written by me more than perhaps in other situations. Um, and PGP was scary. Like I could not figure it out like for the life of me, like what the code even did. Like, not even like where it taught, just it was very like 1990 C code. And I have a feeling that the packet structure is like downstream of some imperative C code that someone wrote Okay, because I was gonna say, like got back solved into some sort of packets format. Um, using whatever like style of writing c code was acceptable, popular whatever in 1990. I was gonna say like, and r the format seems like it's like miserable and, and would lead to a miserable parser with all these exceptions and like, circular and like, it's like the fact that you have nested, nested, nested like types. Like it's a key, but it's also a packet. But it might also be a certificate. Like I would think it would be the other way around, but I could totally see it being like, no, no, no. We have code that resulted in a format, not a format that resulted in this gnarly, uh, parser code. I dunno. that's, that's my understanding of the history of PGP, is that the, the, the tail wagged the dog in terms of the standard. The standard came, well, well, after the set of initial needs were, were established, Ah, so it just sort of grew outta that. I, not that I I don't think that's necessarily a bad thing, right? Like I think more standards should stuff, but like, you, you wanna start with something good. Yeah. Yes. in, in And usually, the nineties. Yeah. I, I think the history, the process itself is, is justifiable. It's more the, the timing is unfortunate. sorry. If I recall correctly, like the early versions of like the dot doc file for, for Microsoft Office was just like, um, you just mem copied, like, like, or, or me mapped the struct that they used to represent a document in the program to disc and then like un and mapped it. And this had obvious problems, um, for years and vol eventually someone solved it by introducing XML and Doc X. But like same, same story I think type of thing where like the format, it's perfectly fine to do things without standards, but like if you're operating under the constraints of the nineties, it's likely that your format is like. Uh, a little insane. It is not necessarily what it would look like if you, you know, built something without a standard that used a format. Um, today. Yeah. Yeah, I am not sure we've ever like done a proper PGP takedown before, and there's like a lot wrong with PGP. Um, like this, like the signature format is crazy. The way they handle authentication is crazy. Like there's all this crazy stuff in it. Like I don't if there's anything like top line important to talk about there. I think like generally if you're kind of paying attention to us, I think pretty much everyone here mostly is written off PGP. Every time this comes up on a message board, I'm always like, please find me one cryptographer, just one anywhere, any, any cryptography engineer that works anywhere that will stick up for pgp and I'm not sure that exists. Right? So like, going through the litany of all the things that PGP does not get right, um, is like, I don't know how super productive that is, but I think there's a more important thing which is like PGP has two use cases, right? It is a package signing system for packages that people don't check signatures on. Um, and it is a secure messaging system for messages that no one will ever care to read. Or, or it's, it's a way to encrypt data, but usually that data is a message, not, uh, not like a file for format, although it is also used to encrypt like files. Yeah, that's, I mean, that's a fair point, right? So it's actually, it's three things, right? It's, it's, it's the two things I said, and then it's also like encrypting files and for like a very long time. A thing that really pissed me off was that none of the, like, like Mac Os for instance, doesn't have like a tool to just password protect and encrypt a file that you have to download something to do that, which means that people, you know, download, like. Whatever the zip program is, and then that's a, its own complete nightmare, right? And like for that problem, like you should use age or aga or whatever, how you, however you pronounce Felipe's thing in, in preference to pgp. But like the, the big problems with PGP aren't going to screw you if you're just encrypting a file, right? Like, I mean, I guess it has a really bad password, K, d, F, so don't password, like, use like a a use a random password or something like that, right? But, but that aside, right? KDF now. I can't remember what it was. I just remember that it's bad. Um, but like, so, so there's those three things, right? But like, I think the, like the, the important thing to talk about is PGP email. Right. It's, it's, and it's, it's more broadly any attempt to get email to be secure and like this is a thing that has been setting, this is like the fifth thing in this conversation we're having, where I've pointed out that something sets me off. Right. But this one really sets me off, right? Which is like, there's so for obvious reasons, we are in a time period where we're reading lots of security guides for activists, it's a big problem. Lots of activists, you know, doing important work and don't wanna be surveilled, right? So you've got all these security guides and there's like, there's two really big tells for me when I'm reading these things that like, whoever wrote this was not super plugged in to, you know, serious kind of digital security stuff, right? Number one is when they uncritically recommend that people use Firefox. Um, I'm fine if you have a, well, a well-reasoned Firefox argument, but if it just says use Firefox, it's open source. You don't want to, you know, be up in Google or whatever, right? Um, like that's a, a red flag for me.'cause that's not, that's not that simple that, but the other thing is, any attempt to get people to use PGP for email, and you see this all the time, like this is like a, a really big recommendation that people try to give people. Like, they're trying to get people to do encrypted email and encrypted email is bad, can't be made to work. Um, I don't why is encrypted email bad and can't be made to work? Yeah. You, you, you, you, you can just disagree with me. Ba no, no, I'm, I really, I like, tell me, uh, I, I agree with you almost entirely. Please tell me, because I literally was to like, scratch my brain and explain this to a normie the other day. And, uh, and they were like, well, what, well, why is that bad? And, um, and then so on. Well, I mean, I think, I think David, so I was talking to Deirdre. I saw Deirdre's face and then a blog post that I wrote like five years ago was in my face.'cause she pushed the button. I think, I think David should, should kick this off. Otherwise it's just gonna be me talking this whole time. Yeah. Well, I, I think we should, uh, go through this blog post, by which I mean, I will read out loud and pretend I am that streamer who shall not be named, um, this blog post called Stop Encrypted email. Stop using encrypted email. I already screwed up reading it. Now you're reading, you're reading it about as well as the YouTuber would read it. um, uh, which Thomas wrote, um, in 2020 that I thought this was older than this That doesn't seem right. I, I 20 before the It, it has a, it has a timeless, it has a timeless quality about it. it does, um, but it begins saying that email is unsafe and cannot be safe. The tools we have today to encrypt email are badly flawed. Even if those flaws were fixed, email would remain unsafe. Its problems cannot be plausibly, be mitigated, avoid using encrypted email, which I think was just Thomas's point I think I write in a way that is difficult for people to read on streaming things. Eh, well, we're doing it. we're we're doing it. Um, and as Thomas noted, technologists hate this argument because few of them specialize in cryptography or privacy, but all of them are interested in it and everyone wants to use encrypted email tools. I don't know if by everyone you really mean everyone, but I think you mean people who write guides for journalists online. I think it's also nerd currency. I mean, I definitely, when I was. A, a, a, a teenager. I was like, man, this is the coolest thing ever. I want to encrypt emails to my friends, which, you know, didn't go well, but it was like nerd credit at the time. I think, I think technologists see like, I can make this work in the Golden case and you may be able to do that, but a lot of security and privacy is like, is not the golden case. It's the average case or often the worst case. And a lot of that comes down to kind of usability and like defaults of the whole system, which is not a technologist sort of thing. It's like a usability and design sort of thing. And that's not necessarily where our, uh, that has evolved over time with the tools that we have available today. And that was not part of how encrypted email came about really. Yeah, so we have like the LARP case that Thomas mentions here of just, of what, you know, William was describing of Oh, let's send encrypted emails to each other because it's cool. Um, and I set up the software. Um, but then we have the case that Thomas refers to going on in which security does matter because messages can be material to civil cases subject to discovery, subpoenaed by law enforcement action. All that fun stuff, journalists, confidential sources. Um, and in this case you have like actual harms coming, um, where if the message leaks, I think it's fundamentally true that almost all PGP encrypted emails are LARP. Right. They are, they're encrypted because, you know, people feel cool, encrypting it, they're like play acting. It's like a, you know, Nerf swords version of, of whatever it is they're doing. Right. Um, the, the, the subtext here is like, um, when you talk about how shitty encrypted email is, people are always like, well, what else are you gonna use? Like, what's, what's, what's your suggestion? Right. And if you like, say signal, they'll like, you know, scoff or whatever. Right. But like, signal was created by the US government, Thomas. I, I don't, I don't think that's true, but continuing right? Like, um, so, so like you, it always kind of boils down to like, you know. Like the choices are sending plain text email or sending encrypted email. And so you sound crazy when you tell people not to send encrypted email 'cause it might go wrong. The thing I think people need to get their heads around is that those are not the only two choices, right? The, the more important choice, like the important third choice is don't send the email to begin with. Right? Like, if you're coordinating a protest like thing or a direct action or something like that, like there are very good reasons not to trust any secure messaging system with those messages, right? Like that's opsec. Um, and like almost all of the discussions about secure email don't have that premise. They all have the premise that the message has to get sent, right? And that can't be true. I do think there are some systems deployed out there that are like in our little email system where we control all the ends. We require PGP, we require, you know, there's other, there's other things that are kind of like PGP and that, like you have a, a message encryption key that's encrypted under some other key, but it's all still like bolted onto email and you can still send a plain text email and it's really hard to enforce that in practice. What stuff is all mostly smm, which is like, Yeah. BU's different. separate, discuss technology, but like, kind of same concept, but like there are ways to deploy SMM mildly effectively within the context of a single enterprise and get Exactly. something maybe out of it, um, out of I, I, I think most of these arguments will. Apply to s mine as well. Yeah, I would agree with that. I mean, SIM is the, the, the basic flaw is, is present in both cases. the the only difference is that SIM has the, the benefit of actually having a community, like a standards body that's, I guess, somewhat serious. Um, and you can configure like most, I think web like organization like enterprise web mail now to be like, you use SMM and you have to use SMM for emails within my organization. And like, here's the key server now. Like, does that actually do anything if like the keys are all escrowed somewhere else? I don't know. But if you're really concerned about the emails existing in plain text on the mail provider server, you can understand why people might like this. So you are thankfully giving up on the, uh, premise of just reading this straight through, Yes. I appreciate. Right. So like what I'm gonna do is just introduce the first argument and then let you discuss and tell me if I'm wrong. All right. So my first argument, no matter whether you're using sime or PGP or the secure email system of the future, you have this problem, which is that. Ultimately, if you're using a system that defaults to plain text, wants to send plain text, eventually you're gonna send plain text, which is to say like everybody who's ever used PG p or SM and anger, and at a security consultancy I ran the mid two thousands, we used SM for everything, right? Like inevitably somebody will respond to your message with an unencrypted reply, which will include your message that you sent originally encrypted. Everybody who has ever used secure email has seen this happen. This is a thing if you are, if you're a journalist or if you're like, you know, you know, organizing or anything like that, that can't happen. You're talking about like life and death there, right? Um, and so the first reason that secure email is completely broken, right? Is that that can happen. Tell me if I'm wrong, or tell me or I think I think of your, this whole blog post from 2020, this is the strongest argument, and this was also the argument that some people had about the old school variant of, I think it was Signal when it was Text secure. Text secure, which was like. It was encrypted chat over SMS. Um, it was using the best, you know, uh, ratcheting, uh, cryptography on top of the SMS messaging protocol. That was the, in the clear, visible to your mobile provider, uh, messaging protocol, uh, to start. And that it was definitely like, be careful. You can send a end-to-end encrypted chat message on Tech secure. Or you may, you know, if you are sending it to the wrong person, you may be sending it in the clear. And this is, this is also kind of what I happens in my iMessage to this day, which is like you use one client to send a chat message, but you may or may not know that going to the non iPhone receiver phone number, it will be in the clear. Uh, and if it goes to the iPhone receiver or iMessage receiver, it will be end-to-end encrypted. Um. It's an unfortunate failure mode for like signals way like years and years and years has been all signal clients are end-to-end encrypted. There is no accidental sending of a signal chat message or WhatsApp chat message after they migrated their entire client base to end-to-end encryption. Um, they originally were SMS, they, they were in a nice space because they were SMS and then they migrated the whole thing to end-to-end encryption. Where signal in the very early days was kind of this, you know, possibly both, uh, case, um, but. That is impossible with signal. Now everything is end to encrypted by default. That is impossible. In WhatsApp, everything is end to encrypted by default, even though it has a little bit less metadata privacy than signal. That is not the case. In encrypted email, you might have es IM you might have this PGP, you might have everything nicely done correctly. The protocol is still a default plain text protocol. You are layering this extra crap on top of a default plain text protocol and it's up to you to never fuck up. Like there. What is it? The, you have to be perfect all the time. The adversary only has to get it right once, something like that. Or you have to fuck up once and the adversary just has to catch you. Um, that's, that's the case for trying to make end, uh, end-to-end crypto email work. Um, and it's, we've learned those lessons of why this is bad in other places for secure communication, and it just doesn't seem like we're ever able to make it work. Email, signal, WhatsApp, all these other, um, iMessage aside, they aren't on top of the default plain text protocol anymore. They completely moved away from it. Um, email is still plain text by default. So I think this is the strongest part of your, your, your arguments here. Yeah, I think. Kind of a funny thing that that keeps happening is every once in a while, someone who defends pg p will, will bite the bullet on this and they'll say, well, what we'll do is we'll control the client and we'll force the client not to send plain text responses. And that gets to the argument that I've seen Thomas me before, which is that, well, if you're gonna do this entire thing where you build the whole ecosystem around PGP such that you can't use pg p wrong, why not simply do the easier thing and not use PGP given that you're gonna break compatibility anyways? Um, yeah, I don't know. Like I, I know like that's like the Delta chat thing. Like I, I haven't really looked too closely at what they do, but their whole thing is they claim to do. They, they, they're the ones who have finally done it. They finally cracked the code on encrypted secure email. But, um, they do that by, by totally breaking the, the compatibility assumptions in, in email. But I mean, the one thing and that like you do that, the one thing that you are retaining from email is the possibility of being compatible with somebody who won't encrypt their messages. That's all you've saved. also like the sending of messages solution, like I think people are, they want to use the thing that already works, which is like the modality of sending emails, but they want to do it securely and so they, it, it, like, it's so, I can see it being so easy to just be like, well, we just don't send emails. It looks like email, smells like email, but it's not email. But then people were like, well, why can't I email this person who uses this client who, that it's suppo. Like it's not secure. It's not set up to take my ex unencrypted email. And then you kind of, you're back at square one. Yeah. Man, I would love it if I couldn't accept email from people so. uh, There is that subtext. uh, I think there's a lot of like, um. I think about this a lot with like, with like, uh, protocols in general. There's a lot of like nerd pattern matching. People love the username at domain scheme for things, and I think email in that sense is very comforting. And so the idea that you can do encryption on top of that is, is, is especially comforting. S speaking of, speaking of the thing that users love about this, which is the username at thing, right? My second argument, which I think might be stronger than the first argument, so I'm waiting for, uh, you guys to tell me I'm wrong about this, right? The second argument is, um, for a serious adversary, you know, if it's a, a, you know, a state level adversary or whatever, the metadata surrounding the message is often, maybe, even usually just as valuable as the message itself. Right. What they wanna do is roll up the network of who's talking to who. They're probably starting from a point where they've got like some particular person or contact that they know they're targeting, and they're just trying to work out what the network is like, who they should, like, expand surveillance to and all that. Right? So metadata super, super important. And email doesn't just like leak the metadata email, like proudly publishes the metadata. It's a store and forward system where every time you send a message, the, you know, no matter what you're doing to encrypt the content. The funniest thing about this whole thing, by the way, is that PGP email doesn't encrypt the subject editor, which is like the subject, the subject head isn't even metadata, it's just message. Right. It's just part of the, it's the summary of the message. Right. But, but that aside, like the, the, the two in the, from of that message and that graph that you build of who's talking to who, like this is. The entire reason why Signal asks for your phone number is so they can draft off of your local contact list and not maintain a server side contact list. Because if they had that server side contact list, somebody would eventually, you know, target them for it legally or otherwise and get it and then have the entire graph of everybody who's talking on the service. By the way, if you use like a secure messaging system where like you go from device to device and you just automatic automatically have the complete contact list everywhere, you should ask yourself how that's working, right? Because if the way that works is that they have a server side contact list, they're keeping the whole graph of who's talking to everybody, like server side, just there, right? Um, yeah, yeah, they, the iMessage and, uh, apple like migration tooling, and now the signal migration tooling from device to device has like. Uh, become a very advanced, to avoid this scenario in particular, they literally take everything on your device. You do like a, you do a little bit of a diffy Hillman handshake to make sure that you like, do a daisy chain of, of auth and you're, uh, you know, authorized to move things from a old device to a new device. Um, and they go from device to device. There's nothing going up in the cloud really, other than like, I am registering a, a new device like at timestamp. Like that's kind of it. Um, that's going from device to device, if. You're not doing that kind of like, you know, kind of little dance protocol between devices and things just show up on your new device. It's because they're, it's up in the cloud and maybe there's some sort of password and maybe some of it's encrypted or whatever. But, you know, going from device to device and not going up through somebody else's computer, um, is, you know, less risky and less, uh, exposed. Um, the other part about the, the contact list being like public and available and subpoena able, or hackable or whatever, um, signal's done a lot of work to like, keep as much metadata about who's talking to who, who's in what groups, what the groups are about the, the profile pictures and, you know, aliases and nicknames of people in groups and between people completely encrypted and private and not accessible, visible to signal the service. But that has involved a lot of advanced cryptography that no one else does. WhatsApp doesn't do it. A lot of these advanced, uh, you know, end-to-end encrypted messengers that aren't. Super popular yet they're not quite there yet either. Signal has done a lot of work and that was definitely not available when they were kind of up and coming. And that's like why the, the bootstrapping of your local contact list of, you know, phone numbers in your phone, um, which is just on your phone and does not get uploaded and, and none of that, um, uh, that occurred. And it's sort of like the historical legacy, um, that's, that's kind of inherited into Signal. Doing that, doing that syncing privately is a ton of work and Signal may be the only encrypted messaging service that could do it, and they're still not doing it because it's very difficult. Like I, it is gonna sound, I think a lot here, like we're just boosting a signal and like the, I'm like the, the really just use anything but email and I don't have this much of a gripe. Right. It's just email is the problem. Right. Use use matrix. That's fine. There's, I, I have like, I have things to say about Matrix, but I think Matrix is generally a well-intentioned and heading in the right direction project. Right? Like there's lots of different things you can use. Um, just email. You should, I guess, matter most. think also specifically the, the email argument or the rather the metadata argument with email is that email is uniquely profligate with how much metadata it encourages everybody to use. Like, Like, all the email clients have emoji reactions now, and those are in metadata. And those are also part of the message semantically. Uh, but those are now in metadata. And so now people I think probably don't realize the five people who both use PGP and Emoji reacts in Gmail, uh, are sending, you know, clear text emojis. I hate that and Do we, do we do We know This is, this is, you're breaking news here. This is, so how does this work? Is it like my matters that, that could attach to Yeah. They, they add, I, I can't remember what the Gmail one is, but the, the m phone is like XMS react or something like that. And then it's, uh, I, I, I would've to, I would've to look up the exact details, but it's like, You can just off the top of your head, this, you don't actually have to have it. Right. But is like a, is it like a single line base? 64 header, like an actual header? It's not like the. I'm, I'm, I'm pretty sure it's an actual header. I can, like, I can imagine like a mime section, right? Like it's the, you do the whole, like the, the messages, like this set of mime packets or whatever. I believe you, when you say it's a header, I just think that's It's, it, it it may also vary by email provider. Is, is the, is the thing that is concerning me is that I think what I'm saying is correct possibly for, for Outlook. It might not be correct for Gmail. Gmail may do the mime thing, but let me, I, I am trying to actually find this documented somewhere. I, hate this so much because emojis are content. They are, they are. They're the body of communication. I mean, you can have an entirely like important, very sensitive conversation just in emoji reacts, because I've done it, I've done it. on the argument that metadata is important as content, um, it, it really depends. Like some, it's important to protect it. It's also difficult to protect it. The, the e emoji reacts not being counted as content is just wrong, but like the metadata about who's talking to who at what time and like how long the conversation is and things like that. The sub, the subject line that is content that should just be encrypted and the fact that it's not as, as ridiculous. Um, but the other stuff, um, it's hard to protect it because a lot of it is like. Control flow, like how do we route information? Um, even, even WhatsApp has, uh, doesn't encrypt this stuff. They, they know who is talking to who at what times and things like that. Uh, signal has done a lot of work to not be able to detect a lot of this, uh, but it got better at it over time. And the stuff that's subpoena able from Signal is literally like the time that someone registered an account, like the very first time and the last time they contacted the signal service. Like that's, they've very proudly put up their, you know, responses to, you know, subpoenas and court orders about like, give me information about X, Y, z, uh, users. Right. but even if you get it, it, I think there's like. This, this has been kind of the evolution of what you can get from devices. If you just be like, just try to give me access to devices. If you can get access to devices, there's a lot of content, including previously secure, securely communicated, end-to-end, encrypted content on devices or on clouds, especially like iClouds that are not fully, uh, encrypted, backup or other cloud backups, um, that you might be able to get access to. And that's really rich. And if you can get, get access to that, uh, that's really good stuff. If you can't get access to that, the metadata is useful. And especially if you're trying to spider out from a target. If you're trying to find more people in like a communications network and you're trying to find links, I do think it's important. Uh, I don't. Quite agree that it is as important as content in the year of our Lord 2025, because there's just so much content available out there from random places, whether it's the cloud or, you know, just give me access to your device, uh, via some sort of like corridor or if you want to be, uh, really, you know, targeted as a specific person, you can try and like target their devices specifically and send them, you know, an attack, um, depending on the security of their device and get everything quote, like effectively everything. So, Right. I, I think that those are all totally valid points, right? Like, um, I think the thing I'm trying to call out about. The un salvageability of email is just, if you think about how email works, right? Like, um, when you, there's so many places where you can do a dragnet and just collect all of the metadata going through like a message flow for a bunch of people, right? Like every every MX hop, whatever, like they're just, the processing of these emails leaves a log trail of who is talking to who, and not just on the central, the one central place that you could potentially protect or whatever, but just like everywhere that the message goes, just like leaving this trail. Um, it's also like, to me the, the, like, another important thing here is just that, um, governments are already really good at accessing this metadata. They understand SMTP metadata, right? Like there's, for a long time there was a, there was a thing that got passed around about like for each of the different messaging services, which what could the FBI access. Like, which things could they actually use? And it's like with Signal it was like, you know, that you use Signal and then nothing else. Right. Um, but like the amount of stuff they can mine out of SMT p metadata, I think is a lot more than they can, like they're ready to, to get from anything else. Yeah, And, and like every client, just like re-broadcast all the metadata from their perspective at every step. And that's like how the protocol works, right? You include all the parent responses, you say exactly who you're responding to and why, and like the chain of how you got there. And then the provider signs every message to make it clear that the metadata is like real, because everything via, uh, what's that dm? Um, uh, and yeah, because everything that we had to build for spam is all about like authenticating the med, allowing servers to authenticate the metadata to each other. Can we do like a one minute thing about how you should never take any kind of security advice from anybody who says that De Kim messages should be authentic and like that it's a bad idea to burn de Kim signatures. This is very definitely a thing right? There are definitely, like, this is how like the, the Hunter Biden messages got authenticated, like they were published with valid deam signatures. And it's like you respond to that and say like, well, we should burn the Deam keys so that you can't really authenticate we fought the deep state. would never be able to fight the deep state without Deam keys. and it's like PE people will say things like, well no, we need to keep these d Kim keys secrets so we can authenticate messages.'cause that's how we'll do journalism by like authenticating people's leaked messages. And it's like, you are the adversary. Like you're, you are being the adversary right now. I, I mean, leaking them on the scale of like, you know, uh, rotating them every one month to six months or whatever. And then like publishing the old ones, I think. Yeah, I don't think we should stop authenticating messages. A time of send, right? Like, I, for one, enjoy that I'm, my inbox is only like 50% spam and not 95% spam. yeah. And like 50% spam is like stuff that I signed up for once upon a time and not like boner pills are us or whatever. Um, of new sponsor, you do wanna sponsor us and you, you are not boner pills are us. Uh, we're trying to hold an event in Las Vegas during blackout Defcon. Um, contact us@securitycryptographywhatever.com. Uh, are we.com. Dot org? I me. Just, just contact me, figure it out. Da David's the one that handles this. Um, the, the, just talking me a PGP email, I will not respond. I received, I sent, after I defended my PhD, I sent a number of people thank you emails, and then one person responded to mine with A PGP email, and to this day, I still not have read it. yep. Um, this, this is the way that it stays secure is when you do send the encrypted email, no one will ever be able to decrypt it. And so it stays, that part stays secure. Um, this is re all this metadata discussion is reminding me that. One of the pros of email of, you know, SMTP is that it is federated. Um, that is why it's what part of the reason it's leaving this metadata trail, like all over the internet. Um, this is like a thing that some people like about the protocol, that I would call it a pro, that it's federated. I would simply state that it is federated. I have a bigger thing here, which is just, okay, so it's federated and people might or might not like federation. This is like a, a long time thing with, uh, um, signal, like Moxie wrote a whole thing about how, why they weren't federated, which really set people off, right? And like, I feel like he was. Utterly vindicated on that after what happened with Matrix and their attempt to convert from, uh, encrypt, uh, non-encrypted to encrypted. Um, but there's a deeper issue here, right? Um, people complain about federation. Maybe that's a colorable argument. People complain about things being open source. Maybe that's a colorable argument. People complain about running too much stuff through Google. Maybe that's a colorable argument, but none of those arguments are about security. Right. If, if, if the premise is we're creating a transport for messages that are life or death sensitive, then none of that can matter. It can't matter whether or not, if so, if you are, if you are talking to, like, if you are talking to an activist community, especially if you're talking to an activist community in some other country, but increasingly in ours as well, right? If you're talking to people who are like organizing to protect immigrants from ICE, for instance, or something like that, right? And you tell them to use pg p email because the alternatives are not open source or federated enough for you, that's malpractice. It's literally malpractice. Not in a funny way, not in a dunking way, like you are committing professional malpractice, right? You're like, you're putting people at risk to serve your weird goal of being a federated or open source or non Google transport, and that's fucking crazy. Like, I don't understand why people look like, why people's jaws don't drop when they see people saying this stuff out loud. Yeah. I, I think this is now getting into like the crank side of the world, but like I think, I think people sometimes just don't believe that things are actually end, end encrypted and because they don't believe that they then believe contrapositive things, like it should be federated like, well, if they're not gonna end, end encrypted, then I might as well do the federated thing, and this is obviously wrong to me, but I think this is why we get into these weird online arguments as a community over and over again about this stuff Yeah, Yeah, the set, the set of people that think signal. Has a backdoor there because it's centralized or because Moxie wrote a blog post they didn't like, or because they think the CEO is like too, whatever. Yeah, my next argument, uh, this one is I think, more small ball than the first two. I think the third, the, the last one, there's four of them total. The last one gets us back to kind of, you know, grand theory stuff. This one's really specific, right? Which is everybody who uses email has an archive of their email messages, um, which is a thing that secure messengers deliberately go out of their way to not have, right? So I can go and search through pretty much every email that anybody's ever sent me. Um, going back like a staggeringly far, you know, back time in history and, and my Gmail account, right? Um, so all of those things will eventually somehow leak. Like every day that you hold that archive, you're incurring some kind of risk that it's gonna leak. Um, it's just inevitable that at some point it has to, right? So there's no plausible mechanism for doing any kind of disappearing messages in email. Um. And I think like, that's not like the most super interesting, fun technical topic to talk about.'cause it's really simple. Right? But I think it might be pretty important, um, in terms of actually impacting people's safety. Um, just the fact that you can't court, you can't like set a maximum amount of time for a conversation to lift. Yeah. I, I, I think that's actually like the most important feature for like, quote unquote, like secure messengers for like non activists as well. Like, like even iMessage, like you can, if you go into settings, you can set your iMessage to delete after like 30 days, but it's like per device setting. Oh, that's can end up with like iMessages that. are on one device from like, I just saw some that were over like a year old on this, on, on this laptop, even though I have it set to delete after 30 days on my phone. Um, and, and that's not because like it's a life of your death scenario or because I'm an activist, but just because I'm like, I. don't want these messages. Like, like I just don't want old shit to like come up and bite me regardless of what it is.'cause it's old and like, oh, remember when, you know, David cheered for the wrong football team? Right. Like, even shit like that, like, it's just like, no, you don't want, um, you don't want that to come, uh, to just like somehow get screenshotted or whatever. Right. I like the idea that at some point in your past, you cheered for Ohio, I cheered for Michigan State for like a small period of time when I was in high school and my brother was a student there before I had the good sense to become an engineer at Michigan. yeah. Like I'm in Gmail right now and like Gmail's not. I don't know. A, a fold, it's a web client. It has other, you know, desktop clients, but like, there's no option for me to just like automatically delete things at, at, at any age. Like, I can throw stuff in the trash that requires me to take an action and it will auto delete stuff in the trash. But like, yeah, I've got thousands and thousands and thousands of emails from many years in my, in all like, and then I've got multiple email accounts. And like a co a comeback you can imagine is somebody saying, okay, well they'll just add the feature or you'll use an email client that has that feature, but that's actually not the feature, right? The feature is the protocol accommodation where you can communicate to your counterparty that they should also delete these messages, which is something that's like, you could write a signal client that didn't honor that message, but no one's gonna use it. Right? Um, it's, it's the fact that the protocol kind of, it, it's an accepted feature of the protocol, which it will never be an not true. Pete Hegseth will use that signal client, but other than that, no one will use it. Pc small group. Um, yeah, let, this is sort of like one plus in the, in the kind of the moxie know federate argument that he made. And we, we we're linking to the, that post in, in the show notes where the off chance you're listening to this and you don't know who Moxie is, he is the creator of Signal Yeah. He, he's the, the primary, the primary creator of Tech Secure and, oh gosh, I forget the name of the, the calling app that he, that then got merged into open Whisper Systems. Open whisper. e the original, the original think was the app. Text Secure was the texting app, And the company was called Whisper. Open. Whisper. yeah, it was Whisper system. And then there they were involved with Twitter long ago, and then they. Twitter somehow. And then like, he made the new open Wi Whisper systems and everything got turned into the signal app and the signal service and everything is, is like a Cano, uh, licensed and open. But you know, it's a, it's a, a copy left license. So Don't look at it. to Yeah, well you can look at it, your gaze. yeah. Um, so you could run it if you wanted to. Everything's there, but you can't, uh, anyway, but, um, because everything is controlled, um, and not federated, they control all the clients. They imple implement them themselves, are able to my update and move the protocol forward. Um, uh, because they control all the clients and they're able to move faster and they were able to. Um, make, uh, automatic deletion and deleting messages for all the parties, all the clients in a chat, for example, a thing. And that is so much harder to do when it's like, uh, an open protocol such as something like SMTP, like you can do it, but like, do you have the guarantees and practice that that is going to be implemented, uh, honestly and correctly when it's an open protocol? Like, okay, yeah, you may have like a must in this, like delete this message packet header or something like that. Delete after, you know, t plus 30 days according to your local clock or delete for in 24 hours and like. As I think we all know that like you can put all the musts and must snots in your protocol spec as you, as you want. And like people may do their damnedest and sometimes issues happen and sometimes you fail. And sometimes there are bugs and sometimes there are bugs in client software when you control all the clients. But generally it is less likely that you will have implementation skew, uh, and bugs between interop, independent interoperable implementations of something like a, a delete me flag on a message when you control all the clients and there's only like three of them in the case of signal. There's the iOS, there's the desktop, and there's the Android clients. Um, that seems like less of a thing that you can do on, on a protocol like SMTP, Yeah, although I'm very curious how ML Slike protocols will do this, but I, the it, it just may be maybe more of the same, of like. Try real hard. to like interoperate, aside from the one obvious example. Um, Well, they really want can implement disappearing messages by implementing disappearing messages. And they happen to use FLS with other WebEx Europe is really incentivizing people to actually make it happen. Yeah, I, I think I, I mean, a key part about this is, this is not even a cryptography thing. Like you can't cryptographically prove deletion. This is purely a applica, a protocol and application design matter. Right, which makes it interesting that how intractable this is for email, right? It's not like, it's not even like there's a theory issue for it. It's just like you'll never get something deployed where you can reliably tell somebody else to delete an email. So, Yeah. uh, last argument. Last argument, last argument. You guys ready? I think we're ready. The last argument, long-term secrets. So. Eventually any secret you hold will also leak. This is the forward secrecy thing, which is like forward secrecy. If you're talking to people like I'm, I'm imagining I do a lot of local politics and every once in a while I'll get asked about secure messaging stuff from people who are not computer people. And I'm trying to imagine explaining forward secrecy to somebody who is not like, 'cause it's not like it's the, the, it's the worst term, right? Because it's like, it's not about secrecy going forward, it's about secrecy going backwards, but it's called forward secrecy, right? So it's just the idea that every solution that we have for secure email is based on static long-term secrets. Um, there's no such thing as an ephemeral. You know, email secret exchange, which means that, you know, everything's kind of tack down, like whatever. If you're, you know, having ongoing conversations with people, any, at any point if that secret leaks, the entire backlog of everything that you've ever sent is also gonna leak, which is a complete own goal, right? You don't have to have that problem in a serious messaging protocol. You could just do, you could fix that with ephemeral key exchanges. So I think that's also a really big point. Yeah. And this, this is fundamentally like both how s mime and PGP based, uh, encryption schemes work is you have a encryption public private key pair. You push the public key onto one of these key servers, these bulletin boards, and then someone will usually encrypt a message encryption key to your asymmetric public key. It's a symmetric encryption key for something like a s. Um, and they encrypt it to you under your public, uh, a, um, like RSA or EC, um, public key encryption scheme. Um, and then you decrypt the key with your private key that goes with the public key, and then you decrypt the message with that secret. But this is still protected by one key pair that you use over and over and over and over and over again. And so while you have a different key per se message or whatever it is, it's still all fundamentally protected by the same key. This is not how it works in Signal or WhatsApp or MLS or possibly matter most. I'm not, I forget that protocol. This is just not what modern encryption messaging protocols are like they. Do a new key establishment for every message, and they mix in information from when you set up the session that kind of, that binds to identities to a little bit. You attest that you are who you say you are and that this is linked to previous messages, but every message is computed differently so that if any of those previous things leaked, uh, the, like, if any pieces of these things leak, like you are safe, like the previous things are safe, the future things are kind of defunct. And like, depending on how the protocols, uh, implemented, it can self heal. If you have an honest protocol and you kick out the, you know, the leak at the adversary or whatever, it can heal and then you can get back to that same security level of independent messages. Um, having different key material that is just not how it works with BDP email or my. I'm gonna read you something and you're gonna tell me when you know who the author of this thing is, don't tell who the author is. I don't want to, Okay, but you'll, you'll tell me. All right. Here. Here we go. Forward. Secrecy is somewhat overrated in end-to-end encrypted messaging. Most people do not want a truly off the record experience, but instead keep their messages around. Definitely, as long as those old messages exist and are accessible to the user, they'll be just as accessible to any attacker who gets access to the secret key material. The signal protocol somewhat excessively provides forward secrecy for each and every message sent. This is sort of pointless while the messages still exist on the screen. Uh, I. I, I knew after the first sentence, and I, you still don't want me to say who it is Now you can, you can in the abstract. okay. Uh, this, this is, this is one of my, my favorite people on the internet, uh, is who it is. Uh, someone who I've, I've talked with many times, or rather I don't even talk with, is maybe not the right way to say it. Exchanged missives with, I, he, he does a valuable service. Right? So it's, this is a commenter on Hacker News who is like the designated defender of pgp. Right. And like, um, it's actually pretty valuable like having like something like this be written 'cause it forces you to kind of refine, like he has a whole spiel about why authenticated encryption is not always good. Which is like, it's real. I can't, I can't even remember what the argument is, right. It's, it's hard to get your head around. Like it's something about, it was something about like, um, recovering, corrupted messages. Like what most users want is messages where if there's like a bit flip failure or something like that, they can like, recover it or something. And authenticated encryption makes that break down or something. Um, but it's like having to articulate why. Of course you need, you know, authenticated encryption everywhere is actually kind of valuable. Um, it's just the amount of like back rationalizing you have to do to keep pgp like kind of in the story. Yeah. And he has, he has a couple of posts that are not like in or not, they're not entirely nonsense. Like he has one about like 20, 48 bit RSA, like. It is fine. Is, is I think, the point of his argument and it's like, you know, is it good? I, I would say it's not good. It's something that I would, I would, I mean, I would, I would do a default. Bad. Bad. No. For any RSA, but like, is it the worst thing in the world? No. Uh, Like, there's, there's strong arguments within like the, you know, uh, proper cryptographic community about how much, how big these parameter sets really need to be. Like a lot of them are arguments about symmetric primitives, like some of the new stuff that's based on ketch. Uh, if you want to, uh, look up Too Much Crypto, by JP Aumasson, he makes some nice arguments about. The bounds that we need in practice against known adversaries and the best known attacks, uh, so that we can arguably get just as much security with smaller parameter sets, blah, blah, blah. I don't know if that applies to RSA 2048, but there are good faith, uh, well-founded debate about other cryptographic primitives and sizes and things like that. Um, arguing that like you, like just don't have good forward security or post-compromised security, um, just because you don't, you don't really need it. Um, that that's fundamentally just like giving so much Lee power to a possible attacker of just like, again, they only have to be right once and you have to be right over and over and over again. And having these forward, forward secrecy and post-compromised security protocols make it so that. The adversary basically has to, it gets reset almost every time you send a message practically. Um, it just makes it a lot, lot, lot, lot harder for someone to just, you know, take all the public information you're sending in these cipher texts and like get a good crack at like Well if, if you assume every, uh, via I Thomas's, I think principle too was that every PGP message ends up getting sent in plain text anyway. Um, you don't need forward secrecy then. There's look. it will simply leak. So there's like, there's a kernel of like a, you know, a useful conversation in that, in that argument that he has. Right. Which is like, you know, people don't, people are gonna keep their messages around anyways. So what does forward secrecy matter? And it's like there's some truth to like, you know, I have an archive of emails going back to like, whenever Gmail started apparently. Right. Like, and I just, I don't care. Like I'm, I'd rather have them around than like opsec them out. Right? Like, when I'm, I, I just don't use email for stuff that, that would matter for. Right. So like, the thing to, the thing to note here is like, it's fine to say that email is fine for some kinds of conversations. Like, it's fine to say that, like, I'm not saying don't ever use email. Use email, that's fine. I use email for all sorts of things. Right? Just don't use encrypted email. Don't like try to send secure emails to people. Right. We get in trouble when we try to make this one system that we all like serve life and death use cases. And if you can't, like if you can't articulate a threat model, like if you don't, if you, first of all, if you don't know how to articulate a threat model, but like if you can't like just roll, rattle off what the different threat models are for people protecting immigrants from ICE versus people chatting with people they met on Hacker News or whatever. Right. Like then you shouldn't be giving people advice. Right. And this brings me back to just like digital security guides for activists and things like this where there's clearly no threat model in this stuff, right? Like it's just, it's not based on an understanding of who their adversaries are. And what's really frustrating about that is the real advice is not that complicated. It's not like, this is just not that, like we don't have the sophistication that we need to give people good advice. It's just you need people to just be able to say like, just use signal. Right. Forget about all the politics of it. Forget about like whatever you think about Moxie Marlinspike or federation. Just, just use Signal, right? Um, probably don't use Firefox. You know, just things like that. Um, which again is just like this whole thing right now for me is just my red flags for digital security guides. One of them being anybody talking about PGP. Yep. And like number one for me, a lot of people when you're making recommendations of like how to stay, how to, how to achieve digital security, uh, trying to achieve a goal, you're trying to organize, you're trying to keep, keep your team secure, you're trying to serve some community. Um, it needs to be easy to use and easy to get right. It can't be, make sure you use super special client. Oh, you know, it might not be available on this phone. Oh, like you have to make sure you tick this box. You have to add this extension. You have to do X, y, Z to make sure that you use it right. That's bound to fail. One, it's bound to fail because it's hard to get right and so you might actually get a security failure. Two, it's a lot of work for people to do. If the other of the alternatives are download signal, we will add you to the chat. That's so much easier to one do period and get right, because you don't have to do a bunch of extra steps to get it right and achieve better security. yeah, I feel like a lot of people are just trying to, uh, they have their values and they're trying to say, oh, you should do X, Y, Z because this is, this, uh, aligns with my values as opposed to people trying to achieve something in the real world. And if it's too complicated and it takes too much work to achieve good security, they're not gonna do it. Or if they try to do it, they will fit, they will fail and they'll open themselves up to a vulnerability and like, and then what's the point of the technology in the first place? and one, one thing I kind of wanted to point out is like, oh, if you're, if you've got an archive of all your messages forever and theoretically your messages will just leak because they're around forever and you know, so what's the point of, of forward security and, and like what one. It's a belt and suspenders things. It's the Swiss Swiss cheese approach of security and systems. It's not any one thing. It's if you don't have forward security, you are more vulnerable to one of these things going wrong. An adversary, you know, pointing one of these keys or a key server or whatever it is. Um, well the key one of these keys. Um, and then everything falls apart. But if you don't have a giant me, you know, message archive, like, you know, the, the blast radius is, uh, less bad. And like if you don't have all this metadata, then like the blast radius is, is less bad. It's all of these things to together are pretty fucking bad. If any one of these things was less bad, then it would be less bad. If all anyone, if any of these things were less bad together, we probably wouldn't be talking about this, uh, at all. But they are all pretty bad together. So the forward security, you know. Just don't try to do encrypted email, use signal. Use WhatsApp. Like some people don't like WhatsApp for reasons. Using WhatsApp is way better than trying to use encrypted email, in my opinion. Yeah, It's also like the only way to talk to people in Europe. Yeah, I, I was blown away by that. Every time I, I go somewhere that is, especially like Southern Europe or Northern Africa, it's like people will just message me randomly on WhatsApp and I will have no idea who they are, but better than anything else possible. It's awesome. yeah. Use signal, use WhatsApp if you need to encrypt files, use Tor. yeah, if you need to use Tor, install the Tor browser, then you're done. It's a good, it's based on Firefox. It's a pretty good browser, Huh? Did, didn't we just tell people not to use Firefox? wait. Hold on. Hold on. William, are you gonna respond to this or am I Oh, Actually, I think can't, I can't tell if dear, just trying to make my brain pop. Sorry, but the Tor just not ironically. the Tor browser, is like it's, everything's set up. Everything's good to go. And I think the other options are less less tailored, but sorry. Yes, I said that I, I'm guessing for reasons that you're probably familiar with Dan Guido's argument about why the tor browser bundle is the literal least safest browser to use in the world. I, I, I've definitely heard him make the argument before. I, I can't remember off the top of my head. So, so it's, it's, it's a combination of things where it's like, so first of all, you're using torque. Right, which, like from a traffic analytic perspective, you can see that somebody's using Tor, right? You are using Firefox, which is the least secure of the mainstream browsers, and you're using a fork of Firefox, like a tracking fork of Firefox, and you're collapsing all of the Firefox vulnerabilities down to a very small set of tor browser bundle targets. Um, so like the exploits that you need for that, like you, you, you, like a serious adversary needs like a battery of exploits for like all the different versions, whatever they're using, but they don't need that for tor browser bundle people. Hmm. Yeah, I've definitely heard it make that argument before and I, I mean, I find it convincing, especially for, I mean, I, I, I think it was, it was especially true maybe 10, 12 years ago when the state of Firefox container or isolation was, was really, really bad. It's been a long time since, since I've looked at browser security and so. I would say Firefox has come a long way, especially in terms of sandboxing and a lot of memory safety integration into, into the whole stack. I think arguably Safari is less good than Firefox at this point. For some of those reasons. Um, but yes, if you're, if you're using, if you're using to browser, you are a little bit sticking out in terms of, you know, fingerprinting and all that sort of stuff. Um, in terms of, I don't think we're, we're really selling people. You should use Tor, we're mostly doing the meme of use signal, use Tor, and if you, if you wanna use Tor, like downloading the to browser and just using it is like the easiest, straightforward way to do that. But yeah, just nevermind Is this is, it's, it's not a super strongly held opinion of mine. It's just a, it's like, it's, it's an argument I've had beaten in for me, in, into me by, uh, Dan Guido and the Grugq Uh, but if, if you use safari, you get to use the best named mitigation ever, which is the giga cage. the the if the giga cage gig? Oh, giga Cage. yeah. I want to gig a cage. this is my favorite mitigation ever added to a browser, uh, which is, uh, people kept using Ray Buffer for exploits instead of safari. And so what they did was they put every, um, uh, they put the, the backing store for all of, for a ray buffer into a, uh, uh, and mapped four gigabyte key region and made all, uh, offsets 32 bed. So you just can't escape that region. This is, this is a Dan Kaminsky idea from like the mid two thousands. This was like his big memory, like his big memory safety thing was 64 bits. yeah. this is also how the V eight sandbox works as well as, it's a little part of it. So like the, the V eight sandbox is a little more than that, but to make the, the memory regions work, they have a variety of slightly larger than four gigabyte regions that are only addressed in 32 bits that you, you can't get off of, um, cool. in theory, but like then, then there's a bit more to it There's always, yeah. We're only gonna find out over the next 20 years that Dan Kaminsky was literally right about everything, just in like subtle ways. someone has one of those Wall Street Journal dot profile pictures. The stipple painting. Yeah. the stipple painting you, they just, that just makes you correct about everything. I was, I was wrong to doubt the Stipple painting. Rip, rip Dan Kaminsky. Yes. Alright, so I'm gonna go, I'm gonna go install some random mass PGP extension in my browser, and I'm just gonna start sending the, the wrap up for this, uh, recording with an an encrypted email. Um, I hope you make sure you use Tor browser. huh? Yes. e armor of the episode notes. Yeah, Yeah. Yeah. I want, I want it Cast5, the official Canadian block Cipher. right. Uh, and apologies to the person who sent me that PGP email on the off chance you're listening because it's kind of identifiable. Maybe it was a really mean email. Could have been. Who knows. all right. Yep. Uh, if you can stop using encrypted email and stop, stop telling people to use encrypted email. It's just not, not good in our opinion. Good note, Deirdre, Yeah, cryptography, whatever is a something of who? With, of wait. It's, it's a side project of you, you, me, and David. Yeah. exactly. And our editor is Netty Smith and we sell merch at merch dot securitycryptographywhatever dot com. And we thank you for listening and we thank William for coming on this episode with us. William, thank you very much. Yeah. Thank you. for having me. Bye.