Security Now 964 Transcript

Please be advised this transcript is AI-generated and may not be word for word. Time codes refer to the approximate times in the ad-supported version of the show.

0:00:01 - Leo Laporte
It's time for security now. Steve Gibson is here with lots of security news, including a look at Apple's new PQ3 encryption. Seems Apple might have oversold its capabilities. This is Security Now with Steve Gibson, episode 964, recorded Tuesday, march 5th 2024. Pq3.

Security Now is brought to you by our friends at ITProTV, now known as ACI Learning. You already know the name ITProTV I'm sure you do from our network. After many years of advertising, well, now they're a part of ACI Learning. Itpro has expanded its capabilities. They're providing more support for IT learners as individuals, but, even more importantly, for IT teams. Aci Learning now covers all your teams, audit, cybersecurity and information technology training needs. They provide you with a personal account manager to make sure you're not wasting anyone's time. Your account manager will work with you to ensure your team only focuses on the skills that matter to your organization.

Leave unnecessary training behind ACI Learning. They've kept all the fun and personality of ITProTV while amplifying their robust solutions for all your training needs. Let your team be entertained while they learn, with short form content and over 7,200 hours to choose from. Visit goacillearningcom. If you fill out ACI's form, you'll receive a free trial and as much as 65% off an ITPro Enterprise solution plan, fill out the form and find out how much you can save at goacillearningcom Pretty much anything that's meant to happe.

0:02:20 - Steve Gibson
Great to be back for your pre vacation podcast.

0:02:26 - Leo Laporte
Yes, I'll be gone fresh. I should tell everybody I've been gone for two weeks. Michael be going in.

0:02:31 - Steve Gibson
Yeah, catch you before you leave. So this is. I was wondering with you before we began recording whether this was the shortest title We've ever had for a security now podcast. I mean maybe, but I guess you know it could there there. There could be one called IQ or something in the past.

0:02:50 - Leo Laporte
I don't know the shortest Pond to Queen 3 is the name of this show.

0:02:55 - Steve Gibson
That's right. Yes, or post quantum level 3?

oh that, well, exactly that's something that that apple just made up out of whole cloth, because of course they said we, we want to be special and we're gonna denigrate all of the other things that have come before us that are down at level. They even have level zero, where I think they miscategorized telegram saying that it didn't have end to end encryption. It's like what are you talking about? Anyway, I'm, uh, I'm a little annoyed with apple after. Oh, I have to learning about this, um. But speaking of the podcast, before I forget, um, I brought Whole site search backup at GRC. We've had a number of our listeners who have written saying hey, uh, I want to. You know, you say you have transcripts and I know you do, but I can't find what I want. And you know, of course, yes, you could use google and put site colon g r c and then whatever it is anyway. But you know what I, and In the upper right of our, of all of the pages of g r c, has been a search box for a long time, but google changed something that broke it and I, you know, I figured, well, I gotta get spin right done. So, anyway, spin right is done, so search is back. So I'm just saying that we, they know you're the whole site search and you can, you, you can narrow this the the search to just security. Now podcast Uh, transcript search, if you like. So that's there. Um, we got a fun podcast.

Last week. We covered a large amount of security news. This week Not so much, uh. There are security stories which I'll be catching us up with next week. But after sharing a wonderful piece of writing about the fate of voyager, one news of an attractive new humble bumble, uh, or humble bundle, uh, a tip of the week from a listener, a little bit of spin right news and a number of interesting discussions resulting from feedback from our listeners, our promised coverage of apple's new pq3 post quantum safe I messaging protocol consumed the entire balance of this week's podcast budget, bulging today's show notes to a corpulent 21 pages, whoa. So we got lots to talk about and I think everyone's gonna have a good time. And, of course, we've got a great picture of the week.

0:05:31 - Leo Laporte
That wouldn't have been a good title, though corpulent you might have considered.

0:05:35 - Steve Gibson
A corpulent podcast, that's right.

0:05:37 - Leo Laporte
You might have considered that, okay, we're gonna get underway in just a moment with first a word From our sponsor, the wonderful folks we love them so much at molissa. Uh, they're the data quality experts and they have been since 1985 and they care about your dollar. That's why they offer free trials, sample codes, flexible pricing and an roi guarantee Plus, of course and you need this unlimited technical support to customers all around the world. Actually, you probably won't need it. We've been able to use molissa easily without problems, but it's nice to know it's there when you want it.

Molissa's international address validation. If you're in two different languages, automatic Transliteration from one system to another, like a Chinese to Cyrillic. You can download the free molissa lookups at if you want to try it. They're free on ios and android, no sign up even required. You can see how wonderful molissa is by validating an address or a personal identity in the us or canada. You can check global phone numbers to find a caller, the carrier, uh. Geographic information that's really handy when you get those weird calls from who knows where. You can also check global ip address information and more. That's all free on ios and android. Just search for molissa lookups.

Molissa has achieved the highest level of security status so you can give them your information with no fear. They've actually got fed ramp authorization, which is very hard to get. Well, and now, of course, this is intended for government agencies, but everybody uses molissa benefits from the from the fed ramp approval. Uh, molissa solutions and services are also gdpr and ccpa the california privacy act compliant. That meets sock 2 and hippohy trust standards for information security management. There are so many things molissa can do. I want you to visit them and start, if you want, with 1000 records cleaned for free. You can try the api that way, if you want, or their secure fdp upload, or their sass, or their on prem app, or their web-based app molissa, or their ios or android app. See, they got it covered.

Molissacom slash twit. M el I s s a molissa Dot com slash twit. We thank him so much for their support of steve, the work he does, which is so important. I think we'll all agree On security. Now I have the picture of the week teed up. I have not let yet looked at it. One you will appreciate. Oh nuts, my screen has changed again. Why don't you describe it while I uh, while I push the buttons here?

0:08:17 - Steve Gibson
Okay, well, so we have, uh, one of the wonderfully classic, Uh, fake o'reilly, oh, I love these, yeah, programming coding books. Uh, you know, and, and this, this one One, is titled coding, yeah, so true, coding with gpt. And Then the subtitle is introducing the uncanny valley into your code base, because you know, as we would say on this podcast, what, what could, could, possibly Go wrong. And then you know, a riley is is wonderful, because they've always got some Animal of some sort. I don't know how the animals are chosen, if there's any rhyme or reason or if they just rolled the dice.

Anyway, this one, of course, in keeping with uh, gpt, has a completely Bizarre, fictitious, made-up animal. It's got the head of a Dog with cute little floppy ears looking off to the left, but then for its body it's got the like the back end of a goose or a bird of some turkey who knows what it is of some kite whose feet are on backwards, and then At the very end, it's got like a tail of some other sort of bird looking. I mean, it's just, as you know, a Weird, bizarre animal, and I don't remember where it was, leo, but it was on one of your podcast, I think it might have been on a mac break weekly a couple weeks ago where we saw some Weird animation of a of a lot of like, like, like a bunch of that were.

Yeah, it was just. It like hurt you to watch it because they they just kind of kept Turning around and merging hallucinating.

Yeah, oh, wow, I remember anyway. So this is a hallucinated animal and I would recommend that everyone keep, you know, chat GP away from their code. Actually, um, we'll probably get to it next week one of the things that I didn't have room for this week. Uh, ben guirion, a person Whose work we've covered before. Uh, he, he was at the university of the negave. Um, they've produced a chat gpt worm, which they call morris 2.

Okay, so we've had some fun keeping eye on voyager and on the occasion that we may have finally lost control of this intrepid explorer. I found a wonderful piece of writing about this that I know our listeners will enjoy and appreciate. It's a blog post by someone named dug mur, titled death, lonely death, and. And uh, dug writes billions of miles away, at the edge of the solar system, voyager one has gone mad and has begun to die. Let's start with the billions of miles.

Voyager one was launched in early september 1977. Jimmy Carter was a hopeful new president. Yugoslavia and the ussr were going concerns, as were american motors, pan am, fw, woolworth, photo mat, boots, borders, bookshops and pier one. Americans were watching happy days, mash and charlie's angels on television. Their british cousins were watching george and mildred the goodies and tom baker as the fourth doctor. If you turned on the radio, hotel california by the eagles was alternating with dancing queen by abba and, if we want to be completely honest, carwash by rose roiss. Most cars still ran on leaded gasoline, most phones were still rotary dial and the internet was a wonky idea. That was still a few weeks from a working prototype. The thorn birds was on top of everyone's bestseller list, blah, blah, blah. He goes on to sort of set the the the place for us, reminding us also that it was the summer of star wars and voyager one was blasting off for a tour of the solar system.

There's no way to pack the whole story of voyager one into a single blog post. Here's the tldr. Voyager was the second spacecraft to fly past jupiter and the first to take up, to take close-up photos of jupiter's moons. It flew on past saturn and examined saturn's moon titan, the only moon with an atmosphere, and then it flew onwards, on and on for another 40 years. It officially left the solar system and it and entered interstellar space in 2012. It just kept going further and further into the infinite emptiness.

And he says you know about the golden record. Come on, everyone knows about the golden record. It's kind of a one. It's kind of a hokey and cheesy idea. It's also kind of amazing and great.

He says voyager has grown old. It was never designed for this. Its original mission was supposed to last a bit over three years. Voyagers turned out to be much tougher than anyone ever imagined. But time gets us all.

Its power source is a generator full of radioactive isotopes and those are gradually decaying into inert lead. Year by year the energy declines, the power levels relentlessly fall. Year by year. Nasa has been switching off voyager's instruments to conserve that dwindling flicker. They turned off its internal heater a few years ago and they thought that might be the end. But those 1970s engineers built to last and the circuitry and the valves kept working even as the temperature dropped down down, colder than dry ice, colder than liquid nitrogen, falling towards absolute zero.

Voyager stored its internal data on a digital tape recorder yes, a tape recorder, storing information on magnetic tape. It wasn't designed to function at 100 degrees below zero, it wasn't designed to work for decades, winding, rewinding, endlessly rewriting data, but it did. Voyager kept going and kept going until it was over 15 billion kilometers away, at the speed of light. The moon is one and a half seconds away. The sun is about eight light minutes away. Voyager is 22 hours away. Send a radio signal to it at lunch on Monday and you'll get a response back Wednesday morning. He says I could go on at great length about voyager, the discoveries it's made, the deep space network, that that has maintained, that has maintained contact with it over the decades, the ever shrinking crew Of aging technicians keeping it alive on a shoestring budget. How amazing has all has it all been?

In 1990, just before voyager's camera shut down forever, the probe turned around and looked backwards. It zoomed in and took a picture of earth. By that time it was so far away that earth was just a single pale blue pixel. Seeing the blue pixel, carl Sagan wrote that's here, that's home, that's us On it. Everyone you love, everyone you know, everyone you ever heard of. Every human being who ever was, lived out their lives, the Aggregate of our joy and suffering. Thousands of confident religions, ideologies and economic doctrines. Every hunter and forager, every hero and coward, every creator and destroyer of civilization, every king and peasant, every young couple in love, every mother and father, hopeful child, inventor and explorer, every teacher of morals, every corrupt politician, every superstar, every supreme leader, every saint and sinner in the history of our species lived there on a mode of dust suspended in a sunbeam. He says voyager kept going for another year. He said he was a great leader. He said he was a great leader. He was a great leader. He says voyager kept going for another 34 years After that photo. And it's still going. It has left the grip of the sun's gravity, so it's going to fall outward forever.

Here's a bit of trivia. Voyager one currently holds the record for most distant active spacecraft. It's not even close. The only other contender is voyager's little sister, voyager two, which had a different mission profile and so lags billions of kilometers behind its older sibling. Here's another bit of trivia. If you're reading this in 2024, it's very unlikely that you will live to see that record broken. There are only two other spacecraft outside the solar system voyager two and new horizons. Both of them are going to die before they get as far as voyager one. And nobody not nasa, not the chinese, not the eu Is currently planning to launch another spacecraft to those distances.

In theory we could. In practice we have other priorities. We thought we knew how voyager would end. The power would gradually, inevitably run down. The instruments would shut off one by one. The signal would get fainter. Eventually, either the last instrument would fail for lack of power or the signal would be lost. We did not expect that it would go mad.

In december of 2023, voyager started sending back gibberish instead of data. A software glitch, though, perhaps caused by an underlying hardware problem, a cosmic ray strike, or a side effect of the low temperatures, or just aging equipment Randomly causing some bits to flip. The problem was the gibberish was coming from the flight direction software, something like an operating system, and no copy of that operating system remained in existence on earth. This is a problem nasa long since solved. These days, every space probe that launches leaves a perfect duplicate back on earth. Remember in the martian how they had another copy of pathfinder sitting under a tarp in a warehouse? That's accurate. It's been standard practice for 30 years, but back in 1977 no one had thought of that yet.

Voyager mission control used to be a couple of big rooms full of busy people, computers, giant screens. Now it's a single room in a small building in the san gabriel valley, in between a dog trading school and the mcdonalds. The mission control team is a handful of people, none of them young, several well past retirement age, and they're trying to fix the problem, but right now it does not look good. You cannot just download a new os from 15 billion kilometers away. They would have to figure out the problem, figure out if a workaround was possible and then apply it All with a round trip time of 45 hours for every communication, with a probe that is flying away from us at a million miles a day. They're trying, but nobody likes the odds. So at some point not tomorrow, not next week, but at some point in the next few months, they'll probably have to admit defeat and then they'll declare voyager one officially over dead and done the end of a long song.

0:20:33 - Leo Laporte
If you want to know more about this is a wonderful documentary came out last year. I'm playing the trailer from it, called it's quieter in the twilight, and it focuses on those people Working in that little office in san gabriel valley who have gotten gray with voyager. There it is, there's a little office, it's a great story. In fact, during the filming of the documentary that's when they had decided they had to turn off the heater. So it's quite a dramatic moment when they're just making that decision and what the cost of that will be and so forth. These are the people, the handful of people still running the voyager mission, and they've gotten a lot farther than anybody thought they would, which is why they're getting kind of long in the two it looks like grams.

It's great. This is a fabulous documentary. I Couldn't recommend it more highly. It's called it's quieter in the twilight and, uh, they're not just talking about voyager, I think. They're talking about the uh, the scientists, the engineers, the mission specialists that made this Happen and are still running this distant, distant. It's kind of cool. It really is something to be said, leo for.

0:21:41 - Steve Gibson
Our ability to create something with this kind of endurance in that kind of environment. I mean, it is hostile out there, you know, yeah, uh well, and it feels like it's just luck but, on the other hand, nasa keeps doing it.

0:21:55 - Leo Laporte
Remember, yeah, the same thing with, with rover, exactly.

0:21:59 - Steve Gibson
So what spirit, spirit and I want to say accountability, and I want to say accountability yeah the.

0:22:08 - Leo Laporte
They finally had to end the. You know, the uh drone, the little hovercraft, single uh single rotor hovercraft they had that was flying around. What a story, but they only expected to do a few, a handful of flights with that and they, they got dozens. It's just, it's very impressive. I agree, it really is, and it's a great story.

0:22:27 - Steve Gibson
And hey, salute to voyager Uh yeah, I have a feeling that you know. I will briefly let everyone know when, when they finally pulled a plug, but otherwise, uh, you know, we even we've enjoyed.

0:22:40 - Leo Laporte
Yeah, yeah, so good yeah good.

0:22:43 - Steve Gibson
So I got a very cool tip of the week from patrick johnson who wrote high steve, long time listener, and when downloading 6.1 I discovered that I've been a spin right owner for 10 years. As of tuesday, I was surprised to hear an sn 963 that firefox had let you keep the dedicated search box for so long. I forgot when it was turned off by default for new installs. That was my reaction too, yeah, but I did keep turning it back on for quite a while Until I discovered that the control k Shortcut for search Still worked. Yeah, huh, you know, remember how we liked control l because it immediately selected the url, which was very handy for like doing, then doing a control c to copy it and and paste it somewhere else. He said treating the text entered in the omni bar as a strict search query, even for terms that look like a url, no quotes needed. He says as a dot net developer, libraries and frameworks with the something or other dot net naming convention Turn up quite a bit in my searches. He says chromium seems to have copied this so that now brave, edge and chrome All behave like firefox with control k forcing a search. And he said thanks for everything you do, patrick. So, patrick, thank you. Uh, this was news to me so I tried it and it works perfectly. I previously shared my discovery, which I just mentioned, about Control-L, and I've now added Control-K to my you know bag of keyboard shortcuts because it leaves no confusion. You hit Control-K and immediately the box. In my case, I've just left my Firefox with the default Google search and so it immediately comes up and, like, puts Google in front, confirming what engine it will send this to when I hit Enter. So very cool tip, thank you.

I have no big spin-write news, which, at this stage, is what we hope for. Everything continues to go well. I'm pushing forward on several fronts. I'm spending time in GRC's forums watching as new people encounter spin-write 6.1 for the first time, so I'm learning about their experiences, which will be informing spin-write's forthcoming FAQ. One thing I've seen is that Linux users need spin-write in a format that's directly usable to them. Requiring non-Windows users to briefly somehow use Windows like someone else's Windows system to have spin-write create a bootable USB drive for them is something I've always planned to work around, so not to require that. So I've been working on the tech to add direct bootable image downloading to GRC servers, so non-Windows users will be able to obtain a bootable drive image which they can copy directly to a USB drive just using DD in Linux, although I guess Ubuntu has a nice little drive imaging tool built in which will allow them to boot their licensed copies of spin-write.

I also had the beginnings of GRC's forthcoming email list system running that I know that a lot of our listeners are waiting for. Someone just said that he received a note from ex you know, twitter ex that he would no long he'd be losing his DMing privileges if he didn't get more active or something it's like what. And Elon just insists on creating trouble for people. So I know that a lot of our listeners are only using Twitter so that they can send me notes from time to time, so I'll be fixing that. So I'm in the process of bringing up our email list system and I plan to just maintain two lists one specifically for weekly podcast announcements to our security now listeners and another for GRC related news, you know, new software updates, features and so forth. So people will be able to join either or both as they choose, and I'm also working on SpenRice documentation, which is coming along nicely, having learned from Microsoft last week that certificate reputation matters, even though they're deliberately mute about how exactly that reputation is earned. I presume it's a function of the exposure of a new certificate in the signing of non-malign software. So right after last week's podcast, I used this relatively new certificate that I've got to cosine GRC's top six most downloaded windows freeware In order of decreasing average daily download rates. The top six are Validrive, the DNS benchmark Inspector, securable In Control and Bootable. What surprised me was that, for the first time ever, validrive has taken the top slot to become GRC's most downloaded freeware, with nearly 2,200 downloads per day. Anyway, taken together, those top six are being downloaded in aggregate 5,323 times per day. So now they're all carrying this new certificate whose reputation I want to earn, and I expect it'll become golden before long.

I should also mention something really weird that was just pointed out to me and that is an update of Microsoft's Trusted Root Certificate Program. If I read this correctly, they're saying that the specialness of EV is being deprecated. In August they specifically say in August of 2024, all certificates, ev or not, will be treated identically. So what? Anyway, I wrote to a good friend of mine at DigiCert who back in the day were podcast listeners. I don't know if he still is saying am I reading this right? Is EV sort of in the same way that EV has been deprecated for SSL, right? Like none of our browsers show us anything special about EV certs anymore, I'm wondering what's going on with EV code signing. Maybe the same thing. Anyway, I expect I'll have an answer from him and I'll let everybody know next week. I'm certainly curious because I spent a month figuring out how to get dynamic on the fly server side hardware security module code signing for Spenright and now it looks like before it really gets used that much. Maybe it's gonna just be a non-starter anyway, don't know.

0:30:10 - Leo Laporte
We have EV certs for Twit, which we pay a lot of money for.

0:30:15 - Steve Gibson
Now, those are TLS certs, though, right.

0:30:18 - Leo Laporte
Yeah.

0:30:19 - Steve Gibson
Yeah, and so I'm talking about code signing, ev. Oh, for code signing, of course, yeah, yeah, yeah, microsoft says, eh, we're not gonna bother paying attention to that anymore.

0:30:29 - Leo Laporte
Oh so TLS EV certs continue.

0:30:34 - Steve Gibson
Yes, they continue, although, yeah, they continue, although they're like you know, only if a user goes to look is it clear anymore that a site is an EV cert. It's, you know. I've stopped using them because there's no point, there's no benefit to they don't show green anymore or anything like that.

Nope they don't show anything different. It's all disappeared from the Chrome. So let's take our second break, Leo, and then we're gonna do some feedback from our listeners before we get to a really interesting topic of what Apple has done with post-quantum crypto for their iMessage.

0:31:14 - Leo Laporte
And you skipped your humble bundle item. I don't know if you meant to oh.

0:31:18 - Steve Gibson
I did not mean to.

0:31:19 - Leo Laporte
Well, save that for later, folks. Oh, okay, okay, and we'll do the add and we'll do that. Good, good, thank you. You got one more item Our show today brought to you by something really, really important Bitwarden. You know, everybody who listens to this show probably uses a password manager. You know we kind of harangue everybody to do that. Both Steve and I, you know, think that maybe-.

0:31:46 - Steve Gibson
Well, it's for their own good. Yes, For their own good. I mean, it's like how can you survive now without one?

0:31:52 - Leo Laporte
Yeah, well, there are. There are lots of people who don't. Given that you are listening to the show, you probably already have one, but I know that there are people in your friends and family who don't. And we talked on Sunday on Ask the Tech Guys with somebody who was training on how do I get my family members to use a password manager. Well, I wanna recommend Bitwarden.

Even if you're using another password manager, you should take a look at Bitwarden. It's the only open source password manager you can use at home, at at work, on every device. It does everything right. It is a cost effective solution that can drastically increase your chances of staying safe online. And let me say something really that will help you sell it. It's free for personal use. Free forever. Free, basically. Unlimited passwords, unlimited devices, ios, android, mac, windows, linux. Even the free version even supports things like Yubikis and Passkeys. They do not hobble their free version and it's free forever cause they're open source.

Okay, so if you're going to friends and family and they say, well, I don't wanna pay for a password manager, at least tell them about the free one. And they're always adding new features. They just added account switching to the Bitwarden browser extensions, which means you can log into as many as five different accounts on a single browser and switch between them seamlessly. Works, desktop, mobile apps and now browser too. Why would you want that? Work and personal right. Your personal account is yours, free, forever, but you may also have a business. In fact, this is a great thing to do. There's teams and enterprise accounts for enterprise. They may they should be using Bitwarden, and now it's very easy for you to switch between the two of them without closing one and opening the other. If you use Kubernetes, you'll love this. If you want to self host yes, that's another great feature. Bitwarden you can self host it, so you don't have to trust a single third party to store your passwords and your secrets. You can do it yourself. And if your business uses Kubernetes, bitwarden has just developed a Helm chart to enable deployment to Kubernetes clusters, which means if you're already using Kubernetes, you can keep your software stack simplified without needing to add a new service, which I like.

Generating and managing complex passwords is easy. It's secure, with a trusted credential management solution like Bitwarden. Wired says it's the best for most people fast companies, 2023 brands that matter in security, and it's the one I use. The one Steve uses is the one I recommend. It's no wonder why Bitwarden is the open source password manager now trusted by millions. It's rapidly becoming the most popular password manager in the world, for very good reason. Get started with Bitwarden's free trial of a teams or enterprise plan, or get started for free, forever across all devices as an individual user. Bitwardencom slash twit. Tell your family and friends, it's free. Bitwardencom slash twit.

0:35:00 - Steve Gibson
Thank you, bitwarden Well then, leo, I would argue that it's becoming rapidly becoming the most popular password manager in the world, because we all left last pass, which was the most popular right.

0:35:12 - Leo Laporte
That's right and Bitwarden's doing, because they're open source. One of our listeners, quixen, submitted an S-Crypt implementation for it through a pull request.

0:35:22 - Steve Gibson
Argon2.

0:35:22 - Leo Laporte
Argon2? Oh, that's right. Actually, he did both. He did S-Crypt and Argon2. And then, after some talk, and they decided on Argon2. So that's now possible instead of PBKDF2, which is a much better memory hard way of hashing your passwords. I mean, they just they are always doing something new and it's really great. Thank you, bitwarden. Passkey implementation, by the way, is really great, really nice. All right, on, we go with the show.

0:35:48 - Steve Gibson
I am so glad you brought me back to the humble book bundle Because you know Corey Doctro quite well, oh, good friend yeah.

Yes, and this is, as far as I know, corey's first incredibly affordable humble book bundle. I mean, I'll just read the description of it from the page I've got it in the show notes it's humblebundlecom slash book slash Corey Doctro, and so it's easy to search and find. The description reads Doctoro's visions of the future. Lose yourself in the visionary fiction of Corey Doctro, the celebrated author and digital rights activist known for his masterful explorations of the intersection of tech and society. Little Brother is a stark exploration of surveillance and authoritarianism in the backdrop of a major terrorist attack on San Francisco. Radicalized features four distinct sci-fi novellas, each telling a gripping story inspired by today's technologies and societal trends. In Red Team Blues, you'll follow along with a well-connected money laundering expert on the most dangerous and exciting gig he's ever taken on.

0:37:07 - Leo Laporte
He's actually a forensic accountant. This is hero in his new series and I love it. It's so good, he's so good. I love Corey.

0:37:16 - Steve Gibson
Oh, very cool. Yeah, that says get all these and more 18 books in total and help support the Electronic Frontier Foundation with your purchase. So 18 books. As always, it's a pay what you feel it's worth as little as $18, $1 each or more, in order to support Corey and the EFF. So, anyway, I want to make sure everybody knew about this Doctoro humble book bundle. Ok.

0:37:47 - Leo Laporte
That's such a good thing, thank you.

0:37:49 - Steve Gibson
Yeah, Very cool. So Tom Desmond said hey, Steve, I'm just finishing listing to episode 963. So that was last week and I think I'm missing something. On the cookie email link login loop, the quote he has in quotes absolutely secure unquote process seems to assume that no bad person has compromised the email. Think about this Someone gains access to the email from wherever. They see an old email loop link, they go to the site and guess the username Maybe it's the same email address and they get the link in the compromised email and they are in. Am I missing something? And sadly, Tom, you're not. I hate it when I miss something that's so obvious.

Tom is, of course, completely correct. The solution which I described last week of embedding the email link requesters, IP address and browser cookie into the link would absolutely and strongly prevent anyone who did not request the email-based login link from using it. If they were to just passively observe it in flight or at rest, that's nice but, as Tom points out, that doesn't solve the problem that we're still just as dependent upon email security as ever. Nothing prevents an attacker, as Tom says, who has the ability to monitor the user's email account from themselves going to the site requesting a login link from their IP location with their browser, then clicking the link that arrives in the compromised user's email, Whoops, and yes, they're logged in. So this means that while there's no reason not to at least embed, for example, the requesters' browser cookie in the link, we don't really gain anything from doing that and we remain dependent upon the security of email for all of our logon security, whether or not it's passwordless, using email only, or passworded with the ubiquitous I forgot my password total security bypass. So thank you, Tom. And I should say Tom was just the first of a bunch of listeners who said Steve, I think you are solving the wrong problem, and they were right. So thank you everybody.

Our longtime listener and early advertiser with the podcast, Alex Nehouse. He wrote regarding email slash password links in SN 962. So that's two weeks ago. He said if you send a link with a hash slash IP address et cetera, you eliminate the ability to copy the link and open it in another browser. It would also encourage clicking on links in email, Something enterprises are trying hard to untrain users from doing. He said also, if you did get such a link that you opened in incognito mode and the server expected a persistent session cookie. Next time, after restarting the browser, you asked for the link in either normal mode or incognito, it would not exist.

Email links instead of passwords are a good idea, Alex thinks, and can be made secure as you describe, but it does not fit with the way many people interact with browsers, especially those who use multiple browsers. And, of course, Alex's point is a good one. Heavy use of email links for common logon would have the effect of untraining users against clicking on links in email. If the world were to switch over to that and I don't think there's any danger of that happening there would certainly be a lot more email link clicking going on. And it's also true that the tighter we make the anti-spoofing security, the greater the chance for rejecting a valid user, which, of course, would upset them because this is the way they log on. The presumption is that the user wishes to log on now, not later, so they would request a link that immediately go to their email to find and execute the link, which would take them back to where they just were. But Alex is right that there are various things that could go wrong. So, as we so often encounter, everything's a trade-off. The great benefit of email link logon is that the user needs to remember and possess nothing and they are able to log in from anywhere, as long as their email is secure and they have access to it. I think the best thing probably to come from the last few weeks of this discussion has been the recognition that passwords really only amount to log on accelerators, and that as long as every username and password logon opportunity is also accompanied by the dog ate my password bypass, nothing else we do to further increase logon security actually matters. Not hardware dongles, not fingerprints, not one-time passwords, nothing. It all just amounts to security theater. This in turn implies that the security of our email is far more important than is commonly appreciated, and so I think that's another good thing that really come from this discussion.

And before we finish this, another listener said this bit of fun. He wrote the Taco Bell app seems to have gone passwordless in favor of emailing you a link whenever you try to log in. It's not great user experience for me in that it's slow and prone to spam filtering. When you're trying to put in your order from the car on your way to the bell, it's enough to make you drive to Chipotle instead. So yes, you want to make sure if you're going to switch to pass. And I thought it was interesting that Taco Bell, the Taco Bell app, now just wants to have you immediately confirm who you are by replying to a link in email. They don't want to create user friction. They apparently think that they're reducing it by not requiring the user to use a password all the time, but, as this listener pointed out, they might lose some business.

Joel Clermont said there's a security-focused reason to enforce a max password length when hashing with B-crypt, he said. I recently discovered the recommendation and wrote up more details here. So Joel provided a link to his write-up, which is located at masteringlaravellio, which was interesting. It turns out that Laravel uses B-crypt as its PBKDF password hashing algorithm and, for reasons that defy understanding, the B-crypt algorithm itself has a hard and fixed internal password length limit of 72 bytes.

Ok now, normally we'd think that 72 bytes was way more than anyone might need, but unfortunately many characters in non-Latin alphabets are encoded as 3 and even 4 bytes, so it would be possible for a non-Latin password to max out B-crypt's fixed 72 byte limit with just 18 characters. And again, that's probably enough. But still, Joel makes a good point about there being possible exceptions to the boundless upper password length presumption. I'll just note that a simple solution to this problem for anyone who might be stuck using B-crypt would be to first run the user's truly unlimited length password through an SHA-256 hash or even an SHA-512. Why not? And do it just once. Sha-512 will take a password of any length, even a long one using non-Latin characters, and reduce it to exactly 64 bytes, which can then be sent into B-crypt to be strengthened against brute force guessing, which is why you use B-crypt at all in the first place. Anyway, the cute little hack here is just stick a hash in front of something that can't take long enough passwords and you completely solve that problem.

0:47:28 - Leo Laporte
Does Argon, too, have the same issue, or just B-crypt?

0:47:31 - Steve Gibson
No no, just it was an early design decision of B-crypt, b-crypt's kind of old actually, isn't it?

0:47:37 - Leo Laporte
And kind of funky, yes.

0:47:39 - Steve Gibson
And one would not even start using it. At this point, earl Rod said, regarding the discussion of Nevada's request for an injunction against meta encrypting messages from miners in Security, now 963,. As I listened, I was aware that the great missing piece is data. All of those quoted on both sides privacy advocates and law enforcement advocates have lots of opinions, but they present no data. Data like the number of times criminals were believed to go free because of encrypted messages, stopping prosecution, or the number of times such crimes were not prosecuted at all due to encryption. Or data like times that using unencrypted messages was known to lead to harms to miners. Is this really a case of balancing privacy ie being pummeled with advertising versus throttling the ability of law enforcement to find and prosecute serious crime, he said. I suspect it's not that simple, but without any data, who knows the actual trade-off? Okay, I think Earl makes such a good point here. We've been driven so far away from actual data collection that we appear to have forgotten that actual data could be collected and made available. We're just never asking for it right. We've become the anecdotal example, culture being slammed from one extreme to the other. And here's the problem. Expressing a strong opinion is easy. It excites, it's junk food for the mind, but actually collecting, tabulating and evaluating data is difficult, time-consuming and expensive work, and the biggest problem is, as Earl suggests, the result of all that actual work probably doesn't support the extreme views of either side, so it's not in either side's best interest to be presented with any of those pesky facts which would likely lead to some form of compromise policy. Better just to wave our arms around, attempting to terrify everyone and jam through regulations that support an ideology rather than reality.

It seems that too much of the world is working this way these days. We've seen countless examples of how the move to an online digital world has very likely provided law enforcement agencies with a treasure trove of readily accessible, indexable and searchable information the likes of which has never been known before. We've recently learned that these agencies are consumers of the information that commercial data brokers have been collecting about us for years. They're buying this data. Today. Everyone leaves footprints and breadcrumbs wherever they go online and whatever they do. If law enforcement knew what all of our various service providers know and what our ISPs probably know about where we wander on the Internet and we should assume that they do know any of that if they wanted to, then law enforcement knows pretty much everything about us, certainly more than was ever knowable about people before the Internet. As a law-abiding citizen of the United States, which for the most part leaves its citizens alone unless some intervention is required, I'm all for law enforcement working behind the scenes to keep a lid on criminal behavior. That's what I want them to be doing, given the unparalleled tools that are now available to aid in that work.

It is difficult to get too worked up over the encryption debate. Law enforcement authorities can even know who we're talking to if they wish, even if it's much more difficult to peer into the content of those conversations. Although I also do not have any data to back up my opinion, my intuition is that we're already sitting with a workable compromise for both sides. Could the privacy absolutists wish for more privacy? Absolutely. Are they going to get much more? Probably not. Do our law enforcement agencies wish they could also listen in on anyone's conversations? I'm sure they do. Are they going to be able to do that? Let's hope not, because that would clearly be a step too far in the Big Brother direction. Again, they must already have access to far more data about us than they even know what to do with. It seems to me that the right balance has already been struck. I think Earl's point is such a good one about hey, where's the data to back up any of this? Either way, thank you for that.

Elliott Anderson said hey, steve, the issue with passwordless login the way you described is if someone only has email on their phone. He said I don't have email on my computers because I don't need it Really. If the IP and everything is baked into the link, I'm SOL. That also makes it very difficult to log in on other browsers. That's true. Okay, having listened to everyone's thoughts about this, it's clear that the potential automation offered by an email link creates more problems than it solves. The solution for email-only based login is to return a visible, easy to transcribe one time six digit token. Like everyone who uses one time passwords has become used to Just email the token to the user and request that they enter the token into the browser they're currently using. If they receive the email on their phone, they have the advantage of seeing both the token and their browser page at the same time. This eliminates the untraining of you know about never clicking on a link. It's not really that much more work for the user to type in six digits, you know, and they still don't need to remember anything their password or anything else. So I think you know. Stepping back from the link idea, you know, more automated though it was, it's got a lot of downsides which our listeners, as stewed as they are, have all pointed out. So thank you everybody.

Secfan said Steve in SN 963 yesterday, a listener had mentioned the idea of having a standardized way of documenting a site's password requirements so they could be automated In writing. My own algorithmic password manager named pacify that's a cute name. He said that I messaged you about previously. I had the same thought and wanted pacify's algorithm to accommodate known requirements wherever possible. I discovered that Apple had put some thought into this and created password manager resources on GitHub and that's what it's called on. You know, githubcom slash, apple slash password hyphen manager hyphen resources. He said it includes a JSON format, just sort of as I was suggesting last week for documenting password rules, as well as a number of other helpful things for password managers to automate or semi-automate password management.

The idea is not completely new. Apple's Safari browser has supported a password rules HTML attribute that uses the same rule markup as the JSON to describe requirements for a while. Thanks again for all your work, looking forward to the official release of the new spin ride. Anyway, it's cool that Apple has already done the work of creating some of this structure, and my comment last week was about it being a heavy lift to get the industry adoption, and that appears to be the case. This is now four years old and it has remained somewhat obscure.

Of course, if any website wanted to modernize, they could simply place a relatively high lower limit on password length and accept passwords of any greater length containing any characters. Just hash the thing a bunch and just don't worry about how long it is or what the thing contains, and do it on the browser side and you're good to go. Then, on the server side, they could prevent endless brute forcing password guessing by putting up a roadblock if someone is misguessing that the password to a site. Some number of times. Rob said security. Now question.

After hearing your discussion of session cookies, I was reminded of my own security concern I've had for years, seems I'm always logged into my Google account based on session cookies, and so it seems if a hacker could grab those cookies from my computer, they'd now have access to all my emails and many other Google things. This, he says, even with Google's advanced protection program. He says I believe I've even migrated to a new MacBook and was automatically logged in fine, on the new MacBook. He says though my memory could be a bit off on that and I don't think so I think there's a lot of inter browser synchronizing going on these days, he says. Didn't seem there was any other verification that my hardware was the same, etc. Just doesn't feel very secure to me. Am I missing something? Okay, so first of all a bit of clarification here, because Rob used the term session cookies, which I'm also seeing a lot of casual use about.

When a cookie is set in a browser, the browser can be told how long to retain that cookie, in the form of either an expiration date, which will, at which point the cookie will then expire, or a maximum age. If either of those are provided, then the cookie is considered to be persistent and the browser will retain and return that cookies value until it is refreshed. That is, the setting of the cookie is refreshed, the cookie is deleted by the user or by the website which is able to do so, or that designated end of life is reached and the cookie self expires. Any cookies that have not expired will be retained from one browser session to the next, that is, they are persistent. But I mentioned that the specification of these expirations was optional. If a cookie is set without any explicit expiration, then it is considered to be a session cookie, as in good for this browser session, because it will be retained only for the current browser session. It is explicitly retained only in RAM and it is never written in any way to any permanent form of storage. Once the browser closes, the browser session ends and the cookie will be forgotten.

So to Rob's question and uneasiness, it is the case that our browser's persistent cookies are now being retained over the long term, and that's what keeps us logged into our various websites persistently from one boot up of our computer to the next. It's definitely the case that if bad guys could arrange to obtain those persistent login cookies, they could immediately impersonate us. In fact, this is exactly what that fire sheep Firefox add on did many years ago, and this was one of the primary motivators for the move to always present HTTPS. Fire sheep relied upon the mistake that most websites of the era were making after authenticating with a username and password whose communication was protected by HTTPS, most popular sites would drop back to plain, lower overhead, unsecure, clear text HTTP, figuring wrongly that the user's identity had been protected. They failed to take into account that the only way that user was remaining logged on from our HTTP from one HTTP page query to the next was that each browser query was accompanied by cookies, but that, without the encryption protection provided by HTTPS, those cookies were being sent in the clear so that anyone who could eavesdrop could obtain them and immediately impersonate the user, obtaining parallel access to their currently logged on web sessions. So yes, rob, our browser cookies do serve as persistent long term authentication tokens and anyone who might have some means for obtaining them could indeed impersonate their owner.

Sometimes, when logging into a site, you'll see a trust this browser and remain logged in question and check box. This is useful when you do not want to leave a persistent cookie behind in that browser. For example, when logging into a shared internet cafe machine, you'll also want to carefully and explicitly log out of that machine once you're finished in order to at least invalidate that cookie, even if it isn't completely removed from the machine. But that trust this browser and remain logged in question is offering to change the logged on authentication cookie from a temporary session cookie to a long term persistent cookie, and there is a difference. One sticks around, the other one should If the browser is behaving itself correctly, and I know we talked about this in the past. There was a point at which the various important browsers which at this point means Chromium based browsers and Firefox and Safari, were being very careful never to write that transient true session level cookie to permanent storage.

Hi, steve, listen to SN962 and want to provide a bit of additional information regarding your discussion on password requirements. I work for a company in the financial services sector, specifically insurance. I did want to note that many companies in this sector still rely on mainframes and that is likely the case for many of these maximum password link limits and character restrictions due to IBM's fanatical backwards compatibility. He said several years ago I interned for another company in this sector and was shocked at the requirements for passwords seven to eight characters only and the only symbols allowed were the at sign and the dollar sign characters. He says how much of this is whose fault is a bit opaque to me even still, but I can say that it isn't entirely the mainframes fault. I've seen that more modern and he has that in quotes. Implementations allow up to a 40 character password phrase but still restrict a few characters. All that being said, you see these kinds of restrictions often in sectors that continue to rely on the mainframe and other legacy platforms and products, and I should also mention that a number of our other listeners have since sent me notes saying that, steve, mainframes are not gone, they still exist. They're not around the way they used to be, but they're not gone. So I appreciate the feedback that we still haven't moved very far.

One of the most significant things we've seen and learned through the years of this podcast is the power and prevalence of inertia, which is everywhere acting to keep things from changing. One trick that I ought to mention that works quite well is to map a hashed value to some fixed alphabet. Say that a back-end system can only accept eight characters of upper and lower case alpha numbers and, as we saw in this case, an at sign and a dollar sign. So that's 26 lower case and 26 upper case. So now we're at 52. 10 digits brings us to 62. And two other characters brings a total alphabet size to 64. Now, okay, first of all, the fact that the alphabet size turned out to be 64, you know, representable by exactly six binary bits. You know, two to the sixth, power is 64, that should jump out at everyone. Okay, so let's take this case first.

We want a web front end to give its users unrestricted passwords. So it hashes whatever they provide. Doesn't matter, absolutely doesn't matter, preferably, you know, using some contemporary PBKDF function like Argonne 2. The output of that will be 256 evenly distributed bits. We know that. That's what hashes give us, so they are simply taken from either end. Let's take them from the right end, you know the least significant right end, if we regard this 256-bit value as a number. So we'll take them six bits at a time. Each of those six bits is mapped back into one of those 64 characters. So after eight groups of six bits have been taken, those eight characters are then passed back to the creaky old mainframe as the user's password. The result is that the user is able to use whatever crazy long and special character-filled password they may choose, and whatever they choose is first strengthened by a modern PBKF to harden it against brute force attack and then converted into high entropy eight character password which meets the needs of the back-end system. Okay, but what if the back-end systems password alphabet wasn't conveniently 64 characters, which allowed us to take? Just simply take six bits at a time, okay. So consider this One way to visualize taking six bits at a time is dividing the large hash value by 64, which is to say the size of the alphabet In a binary representation.

Division by 2 is a right shift of the bits. So dividing by 64 is shifting right. By six bits, we can think of the bits that are shifted off to the right as the remainder of the division. So to extract a single character from an alphabet of 64, we're actually dividing the large binary hash value. We're doing a long division by 64, and taking the remainder, which will always range from 0 to 63, thus having one of 64 possible values. So this means that we can extract characters of an alphabet of any size we wish from a large hash value by performing successive long division of the hash by the size of the alphabet we wish to extract, where the remainder from each division will be the value that's mapped back into the alphabet. Anyway, I've always found this to be very cool and been fond of this solution, since it provides high entropy, evenly distributed characters from an alphabet of any size extracted from large binary values, such as those that are conveniently produced from hashing.

Our second to the last bit of feedback. We have a bit of a longer format piece, but this is significant and important and there's some lessons here, and I've had several bits of conversation with him since which I'll share. He said hello, steve, I've been a long time listener and even longer time spin right user, and I enjoy your weekly updates and common sense perspective on all kinds of security topics. I want to share a rather long story with you and would like to hear your opinion about an interesting, in progress responsible vulnerability disclosure. Here goes that's actually not that long, he said.

In October 2023,. I came across a sign in page of a high profile company with 20 plus billion in US dollar revenue and more than 100 million monthly active users on their website Not a small business. For my work, I, sometimes just for fun, regularly visit websites with the developer tools tab open. This time, I noticed that the sign in page of this particular website returned a response header that mentioned engine X slash 1.12.2 as the web server. In itself, not a big problem, but it is better to hide this information from the public. However, if the page was really served by engine X 1.12.2, then the website would have a big problem, because this version of engine X is very old and has a number of critical and high severity vulnerabilities that are known to be actively exploited. So, being a good citizen, I wanted to tell them about the issues, just for the sake of improving their security and, of course, also for improving the security of their 100 million monthly active users. Finally, he was one of those. He said so.

I searched on the company's website for their policy for responsibly disclosing these vulnerabilities, but the best I could find was the email address for privacy related questions. I wrote an email telling them about the vulnerabilities, including some screenshots for evidence, and asked some questions about their statements in their privacy policy and terms and conditions on protecting my information and just keeping the website bug free. I was not looking for any financial compensation. I just wanted to make the world a better place. I soon received a response that a bug report had been filed and then it could take up to 120 days for bug reports to be tested and validated. I received no answers for my questions about privacy.

Next forward to February 2024, 118 days since their message that the bug report had been filed. I politely asked them about the status of the bug report, notified them that the vulnerability still existed and asked them if my personal data is still safe with them. A week later, I received an email from them saying that, after review and risk rating by their information security team, the bug report qualifies for a bounty payment of $350. If I agree to this payout agreement, I also agree to keep my silence about the issue. My questions about privacy and trust and new questions about their responsible disclosure policies remain unanswered. In the meantime, the issues still exist and a small tour around some of the other websites of the same company show similar problems.

The fact that these vulnerabilities are so easy to find, the fact that the reported web server is so old, the fact that it is so easy to remove a server banner and the fact that it is still not fixed after more than four months makes me believe that this could be a honeypot. Well, he's being extremely generous. I don't believe that. I think what we're dealing with is a typical irresponsible company. Anyway, he says if it is, then I think that it is a very, very risky attempt of having a honeypot. Now, why would you have a honeypot as your main logon server? I doubt that's the case, he said, because it is easy to find. It is on pages where people enter their username and password and if the media get hold of it then the brand damage of such a high profile company will be big. He said.

I've asked them directly if this is a honeypot, but I did not get a reaction yet. What do you think about this? What should I do? Accept the payout and keep my silence? Should I also report the 30 plus other vulnerabilities on their websites and sign in pages? Should I tell them that just by looking at the web server response headers, I know that they use a mix of Nginx 1.12.2, microsoft IIS 10.0, aspnet 4.0.30319, shopify, wordpress, et cetera? Or should I just leave it up to them to find it all out? I mean, what could possibly go wrong? Kind regards and again, I love your show. Keep going, robert Blackmere, wow.

1:16:24 - Leo Laporte
He's a good subordinate. So, robert, wow, yep.

1:16:28 - Steve Gibson
I said and I wrote. I said, Robert, I agree that this is a conundrum. I took a quick peek at the version of Nginx and what immediately jumped out at me as it would any researcher, nefarious or not was CVE 2021-23017. It's a well-known remotely exploitable off by one error which gives an attacker unauthenticated remote code execution capability and, what's more, a three-year-old working Python proof of concept exploit is also publicly available. Well, there you go.

1:17:12 - Leo Laporte
I mean it just doesn't get any worse Even a three-year-old could do it, geez.

1:17:18 - Steve Gibson
So, robert, I agree that you're right to be worried about them and worried in general. It appears that any miscreant wishing to target this enterprise has everything they need to do so. Unfortunately, although you've done the right thing every step of the way, their ongoing negligence in dealing with this, which you had no way of anticipating upfront, has now compromised you, since you've acknowledged to them that you're in possession of information that could damage them either reputationally or for use in an attack, and, as we all know, attorneys can allege that just by looking at their web server headers, you've obtained non-public network hacking information, and some judge, who knows no better, could be convinced. It's happened before. I think I would have nothing further to do with them. The problem with a company that has become this large is that the people who you really should be talking to are unknown and inaccessible to you by design. Between you and them are layer upon layer of chairwarming functionaries who have no idea what you're even talking about. At this point, my recommendation would be for you to turn everything over to CISA and let them take it from there. Perfect Completely discharges your responsibility in the matter while insulating you from any blowback, since no one not the company in question. Nor any judge could fault you for confidentially and privately informing the US government's cybersecurity and infrastructure security agency of this potential critical vulnerability, after having first given the company in question all of November, december, january and February to deal with upgrading their servers.

Cisa, the rare government agency that appears to actually have its act together, has a simple procedure for report filing Go to wwwcisagovcom.

I also created a GRC shortcut so that even if someone forgets the agency's name, going to grcsccom will always bounce you to that page at CISA.

The page has several categories of problems to report. If you scroll down, you'll find report software vulnerabilities or ICS vulnerabilities, which appears to fit best. If you go there, you get bounced over to certorg, which is the Cert Coordination Center at Carnegie Mellon University. So I'd fill out that form to let the US government powers that be know about this. One of the things you can do is attach a file to your submission, so I would send them your entire email thread with the company so they can see that you've acted responsibly at every step. You'll have done the right thing and when CISA and cert reach out to contact the company about their negligence over a four-year-old known critical vulnerability across all their web platforms, you can bet that they'll wind up speaking to someone who can affect the required changes, and at that point you'll have done everything you can, while insulating yourself as well as possible from any annoyance this company might feel over being made to help themselves.

1:21:25 - Leo Laporte
And you're pretty sure, and if you did this, the company might not be happy about it, but honestly, I think you'd be safe from prosecution.

1:21:39 - Steve Gibson
Yes, I think you're as safe as you possibly could be. I should mention that he did that. He sent back to me afterwards that he took everything, he submitted it to them and he got a response saying thank you for the submission and we'll take it from there. Excellent, that's probably the way to start in these things.

I would say I really I think so too. I mean, we've seen and have covered on the podcast, so our listeners have heard too many instances where the company goes after the responsible disclosure guy saying you know, you hacked us, you bad person. It's like no, no, no, no, no, no, no.

1:22:27 - Leo Laporte
Anyway, yeah, I would just time for that, you know, I mean, yep, it's terrible yeah.

1:22:33 - Steve Gibson
Yep, it's wrong. Okay, and finally, for next week, we had the first appearance of a zero click Gen AI application worm. As I mentioned at the top of the show, ben Nassie sent me a tweet. Hi, he's at high, steve. I'm Ben Nassie, a former researcher at the Ben Gurion University and Cornell Tech, and the author of video based cryptanalysis and lamp phone, which you previously covered in your podcasts. I just published a new research paper on a worm that targets Gen AI applications. We named it Morris 2. That's why he said I think the audience of security now will love to hear more about it and keep on with the great podcasts that you and Leo are doing beyond 999. By the way, the research was also published on Bruce Schneier's blog.

1:23:30 - Leo Laporte
That's pretty cool.

1:23:31 - Steve Gibson
So I suspect the next week's podcast will be titled Morris 2. So stay tuned for a look at the wormization of Gen AI, where I'm sure we'll be answering the question what could possibly go wrong? But now we're going to take a close look at what was probably been done right by digging into Apple's new post quantum encryption upgrade named PQ3. After a word from our sponsor, yes, indeed.

1:24:02 - Leo Laporte
Thank you, Steve. And our sponsor for this segment of the show is Collide. You've heard me talk about Collide, but have you heard that Collide was just acquired by one password? I think that's really cool. That's pretty big news. Both these companies lead the industry in creating security solutions that put users first.

For over a year, collide Device Trust has helped companies with Okta, ensure that only known and secure devices can access their data. You've heard us talk about that. You show your ID, but then are they looking at your laptop and making sure it's secure, and Collide's going to keep doing that, by the way, but now as part of one password. If you have Okta, if you use Okta and you've been meaning to check out Collide, do not fear, this is a great time to do it. Collide comes to the library of pre-built device posture checks. Plus, you can write your own custom checks for just about anything you can think of. So really, you can lock everything down. Plus, you can use Collide on devices without MDM, which means that's very good news because it works on your Linux fleet. Your contractors, you can say here, install this Every BYOD phone and laptop in your company. You're going to use Okta. Okay, you can verify your identity, but you've got to verify your security as well with Collide. And so good news, you've heard the news, but Collide's going to keep on doing what they do best, but now that they're part of one password, it's only going to get better. Check it out.

K-o-l-i-d-ecom slash security Now to learn more. Watch the demo today. Collide K-O-L-I-D-Ecom slash security Now. There's a nice demo on there and, man, I am really happy for the guys at Collide and GALs at Collide. Very good news for them and good news for all Collide users. Collidecom slash security now.

1:26:01 - Leo Laporte
P-Q-T-W-A.

1:26:05 - Steve Gibson
So we can guess. We know that P-Q stands for Post-Quantum, and of course we'd be right. So is this Apple's third attempt at a Post-Quantum protocol, after one and two somehow failed, or failed short? What? No, you know, p-q-3. What happened to P-Q-1 and P-Q-2? No Well, apple has apparently invented levels of security and put themselves at the top of the heap.

So P-Q-3 offers what they call level three security. So here's how SEAR S-E-A-R, apple's Security Engineering and Architecture Group, introduced this new protocol. In their recent blog posting, they write today we are announcing the most significant cryptographic security upgrade in iMessage history with the introduction of P-Q-3, a groundbreaking Post-Quantum cryptographic protocol that advances the state of the art of end-to-end secure messaging with compromise, resilient encryption and extensive defenses against even highly sophisticated quantum attacks. P-q-3 is the first messaging protocol to reach what we call level three security, providing protocol protections that surpass those in all other widely deployed messaging apps. To our knowledge, p-q-3 has the strongest security properties of any at scale messaging protocol in the world. Well, so they're proud of their work, and they've decided to say that not only will iMessage be using an explicitly quantum, safe, encrypting messaging technology, but that theirs is bigger than I mean better than anyone else's, since so far, this appears to be as much a marketing promotion as a technical disclosure. It's worth noting that they've outlined the four levels of messaging security, which places them alone at the top of the heap. Level is defined four levels of messaging, with levels zero and one being pre-quantum, offering no protection from quantum computing breakthroughs being able to break their encryption, and levels two and three being post-quantum. Level zero is defined as no end-to-end encryption by default, and they place QQ, skype, telegram and WeChat into this level zero category. Now, this causes me to be immediately skeptical of this as being marketing nonsense, since, although I've never had any respect for Telegram's ad hoc basement cryptography, which they defend not with any sound theory, but by offering a reward to anyone who can break it we all know that Telegram is encrypted and that everyone using it is using it because it's encrypted. Lumping it into level zero and saying that it's not encrypted by default is, at best, very disingenuous, and I think it should be beneath Apple.

Level one are those pre-encryption algorithms I'm sorry, pre-quantum, because zero and one are both pre-quantum, non-quantum, safe. Level one are those pre-quantum algorithms that Apple says are encrypted by default. The messaging apps they have placed in level one are Line, viber, whatsapp and the previous signal before they added post-quantum encryption, which we covered a few months ago, and the previous iMessage before it added PQ3, which actually it hasn't quite added yet, but it's going to. Now we move into the quantum safe realm for levels two and three. Since signal beat Apple to the quantum safe punch, it's sitting all by its lonesome at level two with the sole feature of offering post-quantum crypto with end-to-end encryption by default, presumably as signals relatively new PQX-DH protocol moves into WhatsApp and other messaging platforms based on signals open technologies. Those other messaging apps will also inherit level two status, lifting them from the lowly levels of zero and one. But Apple's new PQ3 iMessaging system adds an additional feature that signal lacks, which is how Apple granted themselves sole dominion over level three.

Apple's PQ3 adds ongoing post-quantum re-keying to its messaging, which they make a point of noting signal currently lacks. This blog posting was clearly written by the marketing people, so it's freighted with far more self-aggrandizing text than would ever be found in a technical cryptographic protocol disclosure, which this is not. But I need to share some of it to set the stage, since what Apple feels is important about PQ3 is its attribute of ongoing re-keying. So, to that end, apple reminds us quote when iMessage launched in 2011,. It was the first widely available messaging app to provide end-to-end encryption by default, and we've significantly upgraded its cryptography over the years, the most recently strengthened I'm sorry. We most recently strengthened the iMessage cryptographic protocol in 2019 by switching from RSA to Elliptic Curve Cryptography and by protecting encryption keys on device with the secure enclave, making them significantly harder to extract from a device, even for the most sophisticated adversaries. That protocol update went even further with an additional layer of defense, a periodic re-key mechanism to provide cryptographic self-healing even in the extremely unlikely case that a key ever became compromised Again, extremely unlikely case that a key ever became compromised, they acknowledge, but now they have re-keying so it's possible. Each of these advances were formally verified by symbolic evaluation, a best practice that provides strong assurances of the security of cryptographic protocols, and about all that I agree. Okay. So Apple has had on-the-fly, ongoing re-keying in iMessage for some time, and it's clear that they're going to be selling this as a differentiator for PQ3 to distance themselves from the competition. They're telling us a whole bunch more about how wonderful they are. They get down to explaining their level system and why they believe PQ3 is an important differentiator. Here's what they say, and I skipped all the other stuff they said.

To reason through how various messaging applications mitigate attacks, it's helpful to place them along a spectrum of security properties. There's no standard comparison to employ for this purpose, so we lay out our own simple, coarse-grained progression of messaging security levels. We start with classical cryptography and progress toward quantum security, which addresses current and future threats from quantum computers. Most existing messaging apps fall either into level zero no end to end encryption by default and no quantum security or level one with end to end encryption by default but no quantum security. A few months ago, signal added support for the PQXDH protocol becoming the first large-scale messaging app to introduce post-quantum security in the initial key establishment. This is a welcome and critical step that, by our scale, elevated Signal from low no, no, they didn't say lowly from level one to level two security. At level two.

The application of post-quantum cryptography is limited to the initial key establishment, providing quantum security only if the conversation key material is never compromised. But today's sophisticated adversaries already have incentives to compromise encryption keys because doing so gives them the ability to decrypt messages protected by those keys for as long as the keys don't change. To best protect end to end encrypted messaging, the post-quantum keys need to change on an ongoing basis to place an upper bound on how much of a conversation can be exposed by any single point in time key compromise, both now and with future quantum computers. Therefore, we believe messaging protocols should go even further and attain level three security, where post-quantum cryptography is used to secure both the initial key establishment and the ongoing message exchange, with the ability to rapidly and automatically restore the cryptographic security of a conversation even if a given key becomes compromised. Okay, it would be very interesting to hear signals rebuttal to this, since it's entirely possible that this is mostly irrelevant, largely irrelevant marketing speak.

It's not that it's not true and that continuous key rotation is not useful. We've talked about this in the past. Key rotation gives a cryptographic protocol a highly desirable property known as perfect forward secrecy. Essentially, the keys the parties are using to protect their conversation from prying eyes are ephemeral. A conversation flow is broken up and compartmentalized by the key that's in use at the moment, but the protocol never allows a single key to be used for long. The key is periodically changed. The reason I'd like to hear a rebuttal from signal is that their protocol. Signals protocol has always featured perfect forward secrecy. Remember axolotl?

1:38:15 - Leo Laporte
Yeah, yes. Which is the same purpose as rekeying.

1:38:21 - Steve Gibson
Yes, it is rekeying. Oh, here's what Wikipedia says. I'm quoting from Wikipedia End Encryptography. The double ratchet algorithm, previously referred to as the axolotl ratchet, is a key management algorithm that was developed by Trevor Perrin and Moxie Marlin Spike in 2013. Oh, uh-huh, it can be used as part of a cryptographic protocol to provide end to end encryption for instant messaging. After an initial key exchange, it manages the ongoing renewal and maintenance of short-lived session keys. It combines a cryptographic so-called ratchet based on the Diffie-Hellman key exchange and a ratchet based on a key derivation function, such as a hash function, and is therefore called a double ratchet. The algorithm provides forward secrecy for messages and implicit renegotiation of forward keys, properties for which the protocol is named Right In 2013,. In other words, it would be nice to hear from Signal, since Apple appears to be suggesting that they alone are offering the property of perfect forward secrecy for quantum safe messaging, when it certainly appears that Signal got there 11 years ago. This is not to say that having this feature in iMessage is not a good thing, but it appears that Apple may not actually be alone at PQ's level three, much as they would like to be. So when do we see it from Apple? They write. Support for PQ3 will start to roll out with the public release of iOS 17.4, ipados 17.4, macos 14.4, and WatchOS 10.4, and is already in the corresponding developer preview and beta releases. Imessage conversations between devices that support PQ3 are automatically ramping up to the post-quantum encryption protocol. As we gain operational experience with PQ3 at the massive global scale of iMessage, it will fully replace the existing protocol within all supported conversations this year.

Okay, so now I want to share Apple's description of the design of PQ3. It includes a bunch of interesting details and also something that Telegram has never had, which is multiple formal proofs of correctness. Since we're now able to do this, it's a crucial step for trusting any newly created cryptographic system. Here's what Apple wrote. They said more than simply replacing an existing cryptographic algorithm with a new one, we rebuilt the iMessage cryptographic protocol from the ground up to advance the state of the art in end-to-end encryption and to deliver on the following requirements. Five of them Introduced post-quantum cryptography from the start of a conversation so that all communication is protected from current and future adversaries. Two mitigate the impact of key compromises by limiting how many past and future messages can be decrypted with a single compromise key. Three use a hybrid design to combine new post-quantum algorithms with current elliptic curve algorithms, which Signal has already done. Ensuring that PQ3 can never be less safe than the existing classical protocol or amortize message size to avoid excessive additional overhead from the added security and as we'll see, there really is some. And five, use formal verification methods to provide strong security assurances for the new protocol.

Okay, they say PQ3 introduces a new post-quantum encryption key in the set of public keys each device generates locally and transmits to Apple servers as part of iMessage registration. So devices generate a post-quantum key on device, store it in the secure enclave and then send the public part of that to Apple. For this application we chose to use Kiber post-quantum public keys, an algorithm that received close scrutiny from the global cryptographic community and was selected by NIST as the module lattice-based key encapsulation mechanism standard, or ML-KEM. This establishes sender devices to obtain a receiver's public keys and generate post-quantum encryption keys for the very first message, even if the receiver is offline, because you know Apple has the matching public key, which is all they need to perform the handshake. They said we refer to this as initial key establishment. They said we then include within conversations a periodic post-quantum re-keying mechanism that has the ability to self-heal from key compromise, which only that's their fancy term for just moving forward and protect future messages. In PQ3, the new keys sent along with the conversation are used to create fresh message encryption keys that cannot be computed from past ones, thereby bringing the conversation back to a secure state, even if previous keys were extracted or compromised by an adversary.

Pq3 is the first large-scale cryptographic messaging protocol to introduce this novel post-quantum re-keying property, and I don't. Yes, exactly this is where we need to hear from Signal, because maybe not, maybe not for ever, since Signal added post-quantum to their system, they say PQ3 employs a hybrid design that combines elliptic curve crypto with post-quantum encryption, both during the initial key establishment and during re-keying. Thus, the new cryptography is purely additive, which is what Signal did, and defeating PQ3 security requires defeating both the existing classical ECC crypto and the new post-quantum primitives. It also means the protocol benefits from all the experience we accumulated from deploying the ECC protocol and its implementations, even though they also said they redesigned it from scratch. So maybe it actually doesn't apply, but it makes nice marketing speak.

Re-keying in PQ3 involves oh yeah, no, it's the next piece I want to get to. But they said re-keying in PQ3 involves transmitting fresh public key material in-band with the encrypted messages that devices are exchanging. The new public key based on elliptic curve, diffie-hellman ECDH, is transmitted in line with every response. The post-quantum key used by PQ3 has a significantly larger size, and does it ever 2K. We'll talk about that in a minute. Then the existing protocol. So, to meet our message size requirements, we designed the quantum secure re-keying to happen periodically rather than with every message To determine whether a new post-quantum key is transmitted. Pq3 uses a re-keying condition that aims to balance the average size of messages on the wire, preserve the user experience in limited connectivity scenarios and keep the global volume of messages within the capacity of our server infrastructure, which is all a fancy way of saying we send it a little bit at a time. Anyway, I'll just interrupt here, also to note that it seems likely that PQ3 is rotating its quantum keys more frequently than signal.

I don't recall the details of signals ratchet and it may have changed since we last looked at it, but it might also be that this is a distinction without a difference. In the case of signals ratchet, it was designed not only to provide useful forward secrecy but as a means for resynchronizing offline asynchronous endpoints. The reason I suggest that it may be a distinction without a difference is that these key compromises are purely what-ifs. No one knows of any scenario where that could actually happen. The only reason Apple is mentioning it is that they have a way of sidestepping this as a problem. So now it's a problem. If anyone did have a way of sidestepping it, then the problem would be eliminated. It's a bit like saying my password is way stronger than yours because it's 200 characters long. That's good, but does it really matter? Anyway, apple continues With PQ3, they say I message continues to rely on classical cryptographic algorithms to authenticate the sender and verify the contact key, verification account key because these mechanisms cannot be attacked retroactively with future quantum computers.

In other words, they didn't bother upgrading that to post-quantum because they're not quantum vulnerable. In the same way, the hashes are not To attempt to insert themselves in the middle of an iMessage conversation. An adversary would require a quantum computer capable of breaking one of the authentication keys before or at the time the communication takes place. In other words, these attacks cannot be performed in a Harvest Now, decrypt later scenario. They required the existence of a quantum computer capable of performing the attacks contemporaneously with the communication being attacked. We believe any such capability is still many years away, but as the threat of quantum computers evolves, we will continue to assess the need for post-quantum authentication to thwart such attacks. Our final requirement for iMessage PQ3 is formal verification, a mathematical proof of the intended security properties of the protocol.

Pq3 received extensive review from Apple's own multidisciplinary teams in security, engineering and architecture, as well as from some of the world's foremost experts in cryptography. This includes a team led by Professor David Basin, head of the Information Security Group at ETH Zurich and one of the inventors of TAMREN, a leading security protocol verification tool, that was also used to evaluate PQ3, as well as Professor Douglas Stabila from the University of Waterloo, who has performed extensive research on post-quantum security for internet protocols. Each took a different but complementary approach, using different mathematical models to demonstrate that, as long as the underlying cryptographic algorithms and they actually meant yeah, okay, right algorithms like the post-quantum NIST approved algorithms themselves, as long as the underlying algorithms remain secure, so does PQ3. In other words, the protocols built on top of those algorithms will also be secure, they said. Finally, a leading third-party security consultancy supplemented our internal implementation review with an independent assessment of the PQ3 source code, which found no security issues.

In the first mathematical security analysis of the iMessage PQ3 protocol, professor Douglas Stabila focused on so-called game-based proofs. This technique, also known as reduction, defines a series of games or logical statements to show that the protocol is at least as strong as the algorithms that underpin it. Stabila's analysis shows that PQ3 provides confidentiality even in the presence of some compromises against both classical and quantum adversaries. In both the initial key establishment and the ongoing re-keying phase of the protocol. The analysis decomposes the many layers of key derivations down to the message keys and proves that for an attacker they are indistinguishable from random noise Through an extensive demonstration that considers different attack paths for classical and quantum attackers.

In the proofs, stabila shows that the keys used for PQ3 are secure as long as either the elliptic curve-diffie-helman problem remains hard or the kyber post-quantum chem remains secure. An apple that inserts a quote from Professor Douglas Stabila, which reads the iMessage PQ3 protocol is a well-designed cryptographic protocol for secure messaging that uses state-of-the-art techniques for end-to-end encrypted communication. In my analysis, using the reductionist security methodology, I confirmed that the PQ3 protocol provides post-quantum confidentiality, which can give users confidence in the privacy of their communication, even in the face of potential improvements in quantum computing technology. Signed Professor Douglas Stabila.

1:53:43 - Leo Laporte
I've been much better in a German accent. I'm just saying you really want people to believe a scientist?

1:53:49 - Steve Gibson
do an German accent Professor David Basen, felix Linker and Dr Ralph Sass at ETH Zurich.

1:54:16 - Leo Laporte
Swiss is even better.

1:54:37 - Steve Gibson
It's a precise specification of its fine-grained security properties and machine-checked proofs using the state-of-the-art symbolic Tamarin Prover. The evaluation yielded a fine-grained analysis of the secrecy properties of PQ3, proving that quote in the absence of the sender or recipient being compromised, all keys and messages transmitted are secret, and that quote. Compromises can be tolerated in a well-defined sense where the effect of the compromise on the secrecy of data is limited in time and effect. Unquote which confirms, writes Apple, that PQ3 meets our goals. And they quote Professor Basen Leo take it away.

1:55:30 - Leo Laporte
We provide a mathematical model of PQ3 as well as prove its secrecy and authenticity properties using a verification tool for machine-checked security proofs. We prove the properties even when the protocol operates in the presence of very strong adversaries who can corrupt parties or possess quantum computers and therefore defeat classical cryptography. Pq3 goes beyond signal with regards to post-quantum defenses. In PQ3, a post-quantum secure algorithm is part of the reasoning and used repeatedly, over and over, rather than only once in the initialization as in signal. Our verification provides a very high degree of assurance that the protocol is designed function-securely even in the post-quantum world. Doesn't that sound more credible?

1:56:24 - Steve Gibson
Don't you believe that, professor? Now, what I found disturbing about the quote not Leo's rendition- is that we had the professor say PQ3 goes beyond signal with regards to post-quantum defenses.

1:56:44 - Leo Laporte
That's really interesting.

1:56:45 - Steve Gibson
The big at signal was entirely unnecessary and gratuitous, and I don't understand why Apple apparently feels so threatened by signal. Oh wait, yes I do. Signal is open, open design, open source and entirely cross-platform. Anyone's conversations can be protected by signal on any platform they choose, whereas iMessage, just like everything else Apple does, is all about platform lock-in. So is PQ3 any reason to choose iMessage over signal? No, when we're talking about cryptography, we've learned that there's nothing wrong with adding a belt to those suspenders. After all, that's why Apple copied signal in adding post-quantum crypto to existing and well-proven pre-quantum crypto belt and suspenders. And so if your work model allows you to be stuck within Apple's closed ecosystem, then you can be confident that iMessage will be secure against any current and future surprises. I have no doubt that Apple did all of this right, but you'll certainly be secure enough using signal and you'll have the benefit of also having far more freedom.

1:58:08 - Leo Laporte
And the ability to talk to the rest of the world?

1:58:11 - Steve Gibson
Exactly, yeah, in a secure fashion. Finally, the paper drops into lots of interesting detail that I won't drag everyone through since we already had the essence of what's going on, but I did want to share one piece of the techie bits, since I think it's interesting, regarding the overhead that Apple has introduced, you know, by their more or less continuous rekeying and actually we find out how continuous. So keep in mind that text messages are often no longer than old school SMS tweets or shorter, you know, sometimes just a few words, right. Apple explains Quote To limit the size overhead incurred by frequent rekeying while preserving a high level of security, the post-quantum chem is instantiated with kyber 768. Unlike the IDS registered public keys used for the initial key establishment, ratcheting public keys are are used only once to encapsulate a shared secret to the receiver, significantly limiting the impact of the compromise of a single key. However, while a 32 byte elliptic curved Diffie Hellman based ratchet overhead is acceptable on every message, the post-quantum cam ratchet increases the message size by more than two kilobytes.

1:59:39 - Leo Laporte
Oh yeah, 2000 characters in English and ASCII. Yeah.

1:59:44 - Steve Gibson
Yes In a in a in a. Okay, thanks, mom, I'll be there soon. Message. To avoid visible delays in message delivery when device connectivity is limited, this ratchet needs to be amortized over multiple messages and otherwise stretched out. Spread out, yeah.

Therefore implemented an adaptive post quantum rekeying criterion that takes into account the number of outgoing messages, the time elapsed since last rekeying, the current connectivity conditions at launch. This means the post quantum ratchet is performed approximately every 50, 50 messages, but the criterion is bounded such that rekeying is always guaranteed to occur at least once every seven days, so at least weekly. And, as we mentioned earlier, as the threat of quantum computers and infrastructure capacity evolves over time, future software updates can increase the rekeying frequency while preserving full backward compatibility. Okay, so now everyone knows as much about P Q three as is necessary.

Apple has followed signal by adding a believed to be strong post quantum crypto algorithm to their built in I messaging platform, which will be arriving with iOS's next major update. And if you're talking to somebody who also has been able to upgrade their device to 17.4, then your conversation will be post quantum encrypted. Apple has also taken the welcome step of having their largely new I messaging protocol formally proven by highly qualified academic algorithm researchers with wonderful accents. It's only a bit sad that Apple clearly feels so threatened by signal.

2:01:54 - Leo Laporte
Celebrity accents impersonated. Actually, the most important thing is this is Kiber. With all three, I think, of the NIST protocols are Kiber as well. Right that there was one that failed.

2:02:09 - Steve Gibson
Yeah, one one was like in in consideration and it Problems were found.

2:02:16 - Leo Laporte
Yeah, have these been approved yet, or is NIST still testing?

2:02:20 - Steve Gibson
We're still we're in the late phases of this. So I mean again, everyone is being really careful, because this is where you want to be careful, this is where you know care matters.

2:02:31 - Leo Laporte
So they're using Kiber 768 with perfect forward secrecy. Those are the two things that probably you know should matter to you. Whether they're better than signal is a pretty big and loaded question.

2:02:45 - Steve Gibson
Yeah, it's a market, and I think yeah, and I'll be surprised after this if we don't hear something from signal you know, you know in their own well crafted accent.

2:02:58 - Leo Laporte
Yeah, they don't. I mean honestly, they don't need to prove anything, no, but it would probably be appropriate for them to say hey, you know, just so you know, we're not PQ to. We provide exactly as good protection as Apple does. Uh huh, and you shouldn't, you know, consider us anything less, despite what Apple might say Right Now, all of this is presuming that at some point we'll get quantum computing, which is still a long shot. I mean, it's not. We're not close by any means.

2:03:30 - Steve Gibson
Yes, the only at this point, what everyone is doing is is considering the harvest now decrypt, later scenario they're wanting, they're wanting to move us into into crypto. I mean, like it's like why not? We've got the computing power, we've got the bandwidth, you know the. Obviously the keys are much longer in order to be as secure as we need them to be so. So there is some cost, but it's cost we can now afford. So let's move the entire world now, so so that you know the. You know the NSA server farm in in Utah can have its next. You know expansion and continue storing stuff, but probably unable to decrypt it once quantum computing does happen.

2:04:21 - Leo Laporte
You know it's. You might wonder well, when is so? We're talking, yeah, and in 20, 30 years they if they still have your messages and if you still care absent any kind of post quantum crypto, they might be able to crack it, but that's pretty much a long way off. It's not just around.

2:04:40 - Steve Gibson
Yeah, I mean we have to. We have to imagine that what they're storing are not people saying they'll be home soon for dinner.

2:04:47 - Leo Laporte
Right, you know they are storing that. They're storing everything. That's the thing.

2:04:51 - Steve Gibson
They're storing that too.

2:04:52 - Leo Laporte
Yeah.

2:04:54 - Steve Gibson
So you know the, the, you know China's conversations with their advanced, persistent threat groups, right, and you know and, and where the money is being wired in order to fund them and all that. I mean all of that, right, it is not yet post quantum encrypted, is you know?

2:05:14 - Leo Laporte
it's hard to imagine anything, though that would be decrypted in a few decades, that would have anything other than historical interest. Right, I agree, I mean you know it's anyway, it's. You know what you can do it. We got the means. Why not go ahead and do it?

2:05:30 - Steve Gibson
Yeah, it's like Microsoft publishing the source for MS-DOS. Finally, it's like okay, thanks, does anyone care? Yeah, thanks a lot, you might care.

2:05:39 - Leo Laporte
But other than that, yeah, no, and I appreciate you kind of addressing the marketing kind of fluff in here from the technological point of view, because I think it is, it's, it's, doesn't, it's not needed, it wasn't necessary, apple I was disappointed.

2:05:59 - Steve Gibson
It's like wait a minute, you know, you know they have a ratchet and we don't know. And signal hasn't told us how often they they deploy it. But it's, you know. Again, nobody doesn't think that signal is secure. Everybody knows that signal. I mean, it's the standard, it's the gold standard.

2:06:18 - Leo Laporte
I think that's why I was attacking them. Frankly, they're the standard, they're the gold standard and there's nothing in here that makes them any less of a gold standard for for good pros. Quantum crypto.

2:06:28 - Steve Gibson
No, because Apple went to all this work. I I it's funny, leo, I was also thinking about the, the goggles, whatever the hell they are you know where, and I guess I listened to you on Sunday. I got this. I came away with a clear sense that Apple had gone too far, that they really they, they far over engineered those things and I'm beginning to wonder, maybe if that's what Apple has become is like a way over engineering company, because you could argue that that there's some there, there's some cost to mistakenly or needlessly over engineer things and and the there are. The very fact that they're having to amortize that their own post quantum re keying over at least 50 messages in order not to bog it down too much, suggests that you know that this was purely a marketing point.

2:07:27 - Leo Laporte
Yeah, it may be more than just marketing. It may also be a message to governments, especially China and Russia Don't bother. Yeah, no, no, we're we're committed to end end encryption. So, yeah, knock it off. Yeah, I think there's a. There's some of that there as well, and for that I applaud them. I think they do.

2:07:46 - Steve Gibson
Yeah, we're not softening anything.

2:07:48 - Leo Laporte
We're going quite, quite the opposite. We're going the other direction.

2:07:50 - Steve Gibson
Yeah.

2:07:51 - Leo Laporte
Yeah, all right, hey, steve, thank you very much. I one more thing I would say is I think telegram is encrypted, but you have to choose it. I don't think all telegram messages are encrypted, at least that's how it? Used to be.

2:08:06 - Steve Gibson
Yes, and I agree with you. I don't think that Apple is lying about saying that it's not encrypted by default by default is the thing. But who doesn't turn that on Right?

2:08:15 - Leo Laporte
And so it's like you know it's. It's like you have to choose an encrypted message, yeah.

2:08:19 - Steve Gibson
Yeah, and in fact I would argue that even that having level zero is dumb, because you either have end to end encryption or you don't, or you don't. So you know why? Have zero and put some people in a in that, in that category, oh, you have to turn it on, right. Okay, so everyone does as first thing they do right.

2:08:38 - Leo Laporte
When they load it is they turn on the encryption.

2:08:40 - Steve Gibson
Yeah, yeah, no, I'm sure probably goes up. How do you? How? How would you like to be encrypted?

2:08:45 - Leo Laporte
Okay, good idea?

2:08:47 - Steve Gibson
I think I do. And then what's for? I think I got this dumb thing.

2:08:52 - Leo Laporte
Steve Gibson, g r ccom. That's the place to go, not only for the world's best mass storage, maintenance and recovery utilities. Spin right, which is now, can I say, officially 6.1?. Did you fix all that?

2:09:05 - Steve Gibson
Oh yeah, yeah, it's, it's, it's in it, it it in in the second release of 6.1. Yeah.

2:09:12 - Leo Laporte
So go on and get that. It's done and if you buy it today, you'll get 6.1. Uh, you, when you're there, you might also check out the show. Steve has, of course, the 64 kilobit audio, which is kind of the standard version, uh, but he but he has a unique version of the 16 kilobit audio If you want a considerably smaller file size. He also has transcripts. He pays for. Uh.

Apple just announced they're going to do automatic transcription of all podcasts, but I think what Elaine Ferris is doing is going to be always going to be a lot better human, human transcriptions, uh, and and searchable too. At a g r ccom. We have the show audio and our unique format, which is video. Audio and video available at twittv, slash, sn. That's our website. Uh, what else? You can watch it on YouTube. There is a YouTube channel, dedicated security now video. You can listen on your favorite podcast player or watch, or listen by subscribing. And, of course, if you want to do it live, you want to get the very, very, very, very, very, very freshest version of the show. We record every uh Tuesday, right after Mac break. Weekly, that's around 1 30 pm Pacific, 4 30 Eastern, and it will be 20 30 UTC starting next Tuesday, because we're going to go back to summertime on us.

2:10:32 - Steve Gibson
Hey, I prefer it.

2:10:33 - Leo Laporte
Yeah, I do too. I wish just pick one, please. Uh, you know we're going to Mexico. Where they stopped, they said you know we don't need this. They just stopped, they're not going to change the clocks anymore. Mexico can do this, Nice, why don't we? Uh, I will not be here. But you brings up this second point. For the next two weeks, I'm going to go down to Cabo. At least I'm going to get some sun and uh, and not think about PQ three or anything like that. And I'm not bringing the vision pros, I'm just going down there to actually enjoy a real son and real sand and real surf. Uh, Micah will do the show for the next two weeks and I will see you right here in three.

2:11:13 - Steve Gibson
There's what one final parting comment I've. At the end of Mac break weekly you were showing a wedding where they.

2:11:21 - Leo Laporte
the groom looked like this he was wearing his vision pros.

2:11:28 - Steve Gibson
And then his bride was begging him not to do that and I was just saying, honey, if you don't know the guy you're marrying by now yeah, that's a good point. That's a good point. I and now I will say, though he's going to have a long and painful relationship with his mother-in-law. I don't foresee smooth sailing. I'm at count, oh goodness.

2:11:55 - Leo Laporte
Have a wonderful couple of weeks. I'll see you at the end of March. Uh, right here for security, are you going to be all tan? Oh yeah, I'll be. I'll be tan, rested, ready to run.

2:12:06 - Steve Gibson
Okay, buddy.