| ||||||
Description: Why is metadata such a problem? What massive new audience just got end-to-end encryption by default? What's the latest on Iran's Cyber Av3ngers? What were the most exploited vulnerabilities of 2023? How are things looking two years after the discovery of the Log4j flaw? Whatever happened with Sony's attempt to force Quad9 to block a music pirate's domain? What exactly is the Dark Web, anyway? And where is it? And after closing the loop with some of our listeners, we're going to examine last week's surprising news of a significant breakthrough in quantum computing.
High quality (64 kbps) mp3 audio file URL: http://media.GRC.com/sn/SN-952.mp3 |
SHOW TEASE: It's time for Security Now!. Steve Gibson is here. Coming up, Ron Wyden's fight to protect our metadata. Why is metadata a risk? We'll find out. We'll also talk about Sony. They lost that big case. Yeah. And then Steve explains why he thinks quantum computing just had a breakthrough moment. It's all coming up next on Security Now!.
| Leo Laporte: This is Security Now! with Steve Gibson, Episode 952, recorded Tuesday, December 12th, 2023: Quantum Computing Breakthrough. It's going to be good because it's Steve Gibson. That's what I hear everywhere because Steve is the hero of the hour, the host of the show you're now listening to, Security Now!, where we cover security and privacy and how computers work, how technology works. This one's going to be a big one, I think. Hi, Steve. |
| Steve Gibson: Hey, Leo. Great to be with you. Let's see. Oh, yeah. This is airing before anyone will have seen what we did on Thursday. |
| Leo: Oh, yeah, our holiday show. We should mention... |
| Steve: Yeah, yeah, the old prostate show. |
| Leo: The good thing is because we're all old we had to make it a short show so everybody could get to the bathroom. It's our Christmas Eve TWiT, which Steve is a part of. |
| Steve: It was a lot of fun. |
| Leo: With Doc Searls and Jeff Jarvis and Rod Pile. And it was, it was great. So if you're around Christmas Eve, make sure you get TWiT. It'll be up on the feed December 24th. |
| Steve: So here we are, and I'm more conscious than ever that we're moving past 999 because we've just crossed the 950. We're into 952 now. |
| Leo: Yeah, yeah. And it would be shaking my boots right now. I'd be... |
| Steve: It would be a little sad if we were like... |
| Leo: Yeah, thank you. |
| Steve: ...heading to the end. But we're not. |
| Leo: Thank you. |
| Steve: Well, the end of the podcast at least. We may be nearing the end of traditional asymmetric crypto. And don't anyone get upset. We still have plenty of time. But today's podcast is titled "Quantum Computing Breakthrough" because there has been one. And it appears to be significant. I appreciate, and our listeners will hear this when I'm quoting the scientists who are involved, everybody around it is, you know, they're adding the caveat of, you know, if this indeed works the way it appears to. You know, that's what scientists say. I mean, that's science, instead of, you know, the marketing hype people. But I really believe everybody's going to understand what happened because it's under, well, it's understandable. And in fact it's also this week's Picture of the Week, not yet something that people are going to have on their desktops. But the first computers weren't, either; right? I mean, they were - they had, you know, power generation stations all dedicated to them in order to light them up. |
| Leo: Well, given that these have to operate at absolute zero, I don't think there's going to be a desktop quantum computer. |
| Steve: Not soon. |
| Leo: No. |
| Steve: So we're going to get there. But first we're going to answer the question, why is metadata such a problem? What massive new audience just got end-to-end encryption by default? What's the latest on Iran's Cyber Av3ngers? What are the most exploited vulnerabilities of 2023, which we can now examine because we're nearing the end of 2023. How are things looking two years after the discovery of the Log4j flaw? Whatever happened with Sony's attempt to force Quad9 to block a pirate domain that was offering some of Sony's music? Whatever happened with that lawsuit? We talked about it a couple years ago. |
| Leo: That's right. I forgot about that. |
| Steve: Yup. What exactly is the Dark Web, and where is it? And after closing the loop with some of our listeners, we're going to examine last week's surprising news of a significant breakthrough in quantum computing. |
| Leo: Wow. That's almost scary, to be honest with you. |
| Steve: It definitely has advanced the timeline significantly. |
| Leo: Holy cow. |
| Steve: So I'll be - we'll talk about that and everything that it means here by the end of the podcast. |
| Leo: Yeah, I want to know more. |
| Steve: A great podcast for our listeners. |
| Leo: I really want to know more because honestly I've been skeptical, to be honest, about what quantum computing, whether it would even happen. It's like fusion energy; you know? |
| Steve: Well, when they're bragging that they were able to factor the number 37 or something, then it's like, uh, okay. |
| Leo: Yeah. Nevertheless, I trust you. And if you say there are big things ahead, I'm thinking, uh-oh. |
| Steve: Everyone will get it by the end of this podcast. |
| Leo: Good, good. Good, good, good. All right. Let me get - I should stall a little bit because I don't have the ad in front of me. But I shall get it soon. |
| Steve: I heard that Wix is now an advertiser. |
| Leo: Yeah. Do you use Wix? |
| Steve: No, but Lorrie does. |
| Leo: Oh, yeah. |
| Steve: She's a Wix maven. |
| Leo: It's good stuff, yeah. |
| Steve: Leo, I use a text editor. Excuse me. |
| Leo: Of course, HTML. Nothing wrong with HTML. No sirree. Steve, I have queued up the Picture of the Week. Do you want to introduce it? |
| Steve: Yeah. This is an actual picture from the lab at Harvard University that we'll be discussing at the end of the podcast. One of Michael McCollum's sci-fi novels is titled "The Sails of" - Sails as S-A-I-L-S, as in light sails - "The Sails of Tau Ceti." And light sails is an actual thing. You can use a large, very gossamer-thin fabric which is aimed at a star in order to get propulsion. Which is to say that photons, light coming from the star, actually do create pressure which can be used, in the case of Michael's book, to power a starship, to propel a starship through the universe. Well, through the galaxy because, you know, between galaxies you've got a problem with insufficient starlight. But in this picture, that is being done. Somewhere buried in this insane-looking machine, and this is one of those where, like, you know, you don't let the janitor come in to clean. This is, you know, painstakingly assembled. And you could sort of see that it's like a high-end LEGO set; right? You know, these things are screwed down. They all have slots which allow them to be adjusted before the screw is tightened on the base in order to hold whatever that is in place. But in here, and you'll hear me talking about it later, are laser tweezers which use lasers to manually move molecules of... |
| Leo: What? |
| Steve: ...super-cooled rubidium atoms around. |
| Leo: What? |
| Steve: Yeah. |
| Leo: What? |
| Steve: So we're talking serious, I mean, you know, this was science fiction 20 years ago. Now here it is, and it actually works. |
| Leo: This would make a great jigsaw puzzle. |
| Steve: Oh, it really would, yeah. |
| Leo: Wow. |
| Steve: Yeah. |
| Leo: Find the tweezers, everybody, find the tweezers. |
| Steve: By the end of the show, I'm not saying that this will make any more sense than it does now, but at least we'll have an overview of what this contraption has accomplished. Last Wednesday, December 6th, one of our favorite privacy rights crusading senators, Oregon's Senator Ron Wyden... |
| Leo: Ron Wyden. Love this guy. He's been so good. |
| Steve: Yup. Well, we need somebody like this to be doing this, so I'm sure glad he is. He addressed a letter to "The Honorable Merrick B. Garland, Attorney General, U.S. Department of Justice." Here's what Wyden and his team wrote. They said: "Dear Attorney General Garland: I write to urge the Department of Justice (DOJ) to permit Apple and Google to inform their customers and the general public about demands for smartphone app notification records. In the spring of 2022, my office received a tip that government agencies in foreign countries were demanding smartphone 'push' notification records..." |
| Leo: Oh, boy. |
| Steve: "...from Google and Apple. My staff have been investigating this tip for the past year, which included contacting Apple and Google. In response to that query, the companies told my staff that information about this practice is restricted from public release by the government." So your democracy's tax dollars hard at work tying the hands and gagging companies to prevent them from disclosing what they're being forced to do in what, like the name of national security? Anyway, Ron's letter continues with Ron explaining: "Push notifications are the instant alerts delivered to smartphone users by apps, such as notification about a new text message or a news update. They aren't sent directly from the app provider to users' smartphones. Instead, they pass through a kind of digital post office run by the phone's operating system provider. For iPhones, this service is provided by Apple's Push Notification Service; for Android phones, it's Google's Firebase Cloud Messaging. These services ensure timely and efficient delivery of notifications, but this also means that Apple and Google serve as intermediaries in the transmission process. "As with all of the other information these companies store for or about their users, because Apple and Google deliver push notification data, they can be secretly compelled by governments to hand over this information. Importantly, app developers don't have any options. If they want their apps to reliably deliver push notifications on these platforms, they must use the service provided by Apple or Google, respectively. Consequently, Apple and Google are in a unique position to facilitate government surveillance of how users are using particular apps. "The data that these two companies receive includes metadata, detailing which app received a notification and when, as well as the phone and associated Apple or Google account to which that notification was intended to be delivered. In certain instances, they also might also receive unencrypted content, which could range from backend directives for the app to the actual text displayed to a user in an app notification. "Apple and Google should be permitted to be transparent about the legal demands they receive, particularly from foreign governments, just as the companies regularly notify users about other types of government demands for data. These companies should be permitted to generally reveal whether they have been compelled to facilitate this surveillance practice, to publish aggregate statistics about the number of demands they receive, and unless temporarily gagged by a court, to notify specific customers about demands for their data. I would ask that the DOJ repeal or modify any policies that impede this transparency. "Thank you for your attention to this pressing matter. If you have any questions or require clarification, please contact Chris Soghoian in my office." |
| Leo: Right on, Ron Wyden. And by the way, I didn't know Chris Soghoian was working for Ron Wyden. Just yet another reason to respect Ron. Chris Soghoian's one of the best security guys out there. |
| Steve: Yup, he absolutely is. |
| Leo: Yeah. Wow. |
| Steve: So Reuters picked up on this and did some additional reporting. They wrote: "In a statement, Apple said that Wyden's letter gave them the opening they needed to share more details with the public about how governments monitored push notifications. Apple wrote: 'In this case, the federal government prohibited us from sharing any information. Now that this method has become public, we are updating our transparency reporting to detail these kinds of requests.' And for their part, Google said that it 'shared Wyden's commitment to keeping users informed about these requests.' The Department of Justice declined to comment on the push notification surveillance or whether it had prevented Google or Apple from talking about it. "Wyden's letter cited a 'tip' as the source of the information about the surveillance. His staff did not elaborate on the tip, but a source familiar with the matter confirmed that both foreign and U.S. government agencies have been asking Apple and Google for metadata related to push notifications to, for example, help tie anonymous users of messaging apps to specific Apple or Google accounts." In other words, deanonymizing them. "The source declined to identify the foreign governments involved in making the requests, but described them as democracies allied to the United States. The source said they did not know how long such information had been gathered in that way. Most users give push notifications little thought, but they have occasionally attracted attention from technologists because of the difficulty of deploying them without sending data to Google or Apple. Earlier this year, French developer David Libeau said users and developers were often unaware of how their apps emitted data to the U.S. tech giants via push notifications, calling them 'a privacy nightmare.'" So we've talked before about the power and value of metadata. While it may be that Apple and Google's messaging encryption technology deliberately prevents them from being able to comply with lawful government subpoenas for the content - we know quite well that Apple doesn't want to - the fact that messages are flowing, and between whom they are flowing, is not something that is nearly as easy for Apple to have no way of knowing. Right? They've designed their technology so that they cannot respond to the subpoenas. They don't want to. But this is not something for them to - like for them not to know. These subpoenas doubtless require Apple and Google to provide all information they have of any kind, including specifically metadata, for the individuals targeted by the subpoenas and relating to the apps and other users those targets are interacting with. So metadata itself is a pervasive problem. We've talked about how even though today's ISPs who are unable to see into today's web connections, the fact of those connections is not hidden without the use of a VPN to tunnel everything past an ISP's prying eyes. We also talked recently about the move to encrypt the initial TLS handshake packets since they were also carrying useful metadata. And even the Tor network, whose entire existence is about obscuring endpoint connection metadata, has a difficult time doing so. We've seen that a correlation attack mounted by examining packets entering and exiting the Tor network, assuming that there's some way to obtain that sort of near-global visibility, can be surprisingly effective. So it's significant that Wyden and his team are only, at least in this instance, asking about Apple and Google. It's significant because this is very likely the tip of the iceberg. It would be safe to say that any and all social media enterprises operating inside the U.S., such as Meta with WhatsApp, and of course Facebook and Facebook Messenger, are subjected and being subjected to the same sort of metadata requests accompanied by the same sort of gag orders. Although law enforcement and other government agencies may be thwarted in their examination of messaging content, the social graph networks through which their targets move remains a significant source of valuable and, in fact, vital information. And it's not at all clear how Apple, Google, WhatsApp and the rest can eliminate that loophole. I mean, even Tor has technically a difficult problem doing so because these service providers are maintaining explicit accounts with the users of those devices. In all of this worry over encryption, backdoors, and privacy, this ubiquitous presence of notification, connection, and messaging metadata is almost always overlooked. So again, as you said, Leo, bravo to Wyden for pointing at this and probably eventually hopefully prying this open as a much bigger problem than it's been given. [Crosstalk] we've got everything in... |
| Leo: Very few people know how useful metadata is. And obviously law enforcement does. And I'm glad that he recognizes that. And I think credit to Chris Soghoian because he's got a good cybersecurity advisor. |
| Steve: Yes. And you could also argue that third-party cookies are nothing but metadata. |
| Leo: Yeah. |
| Steve: That's, you know, it isn't - all it is, is literally a token which follows you around, and it's by - it is your movement around the Internet metadata which is then all aggregated and pulled together to mean something. |
| Leo: Right, yeah. And people are wondering, yes, Chris Soghoian is a relative of Sal. It's Sal's nephew. Sal Soghoian of course a long-term contributor on the network, the creator of - a big guy at Apple, scripted Apple for a long time, the creator of Automator, and a regular on our shows in the early days. So, yeah, comes from a good family, too. |
| Steve: Yup. |
| Leo: Yeah, good on you, Ron. Good on you. |
| Steve: Yeah, yeah. Thank goodness we have him, you know, jumping up and down about this stuff. And while we're on the topic of end-to-end encrypted conversations, also last Wednesday Facebook announced that their gradual rollout of encryption for Facebook Messenger, which we talked about when it first appeared as an encrypted conversations option in Messenger, is now switching to always on by default. This took a long time since it meant that all endpoints would need to have been upgraded. That has happened. So now Facebook is flipping the switch. Since I was curious about what underlying technology they were using, I did a bit of digging and learned that they had the wisdom to not roll their own encryption system. Facebook Messenger is based on the Signal protocol. Even to the extent of borrowing from Signal's open source libraries over at GitHub. Facebook needed to tweak Signal here and there since their platform models are different. But it's nice to know that Messenger's billion-plus users will be using a stable and well-proven encryption technology by default moving forward. Last week we noted that widespread attacks were being seen targeting PLC systems made by the Israeli company Unitronics. These were of particular concern since the systems in question were controlling water management systems in the U.S. and throughout the world. The shocking piece of this was that the systems being "attacked" - and you really need to put that word "attacked" in air quotes here, since given that these systems had never bothered to change their manufacturer's original, default established password of "1111," connecting remotely to any of the between 500 and 800 systems now known to be vulnerable, really, you know, it amounts to more of a visit than an attack. "Yeah, we're just visiting your..." |
| Leo: Just dropping in. |
| Steve: We're just visiting your system from Iran. You know? What's up? So in any event, these Iranians are reportedly continuing to busily scan the Internet for the appearance of any of these PLC systems, and we now have the six Iranian IP addresses they're using. I've added them to the show notes for anyone who might be interested in watching their honeypots or their public WAN interfaces for probes from any of these six IPs. You know, 88.135.36.82, and there are five others. I won't recite them all here. They're at the very bottom of page 3 of the show notes for anyone who's interested. Thank you, Leo, for putting it on the video there. So yeah. If any of those IPs visit you, they're coming from Iran. And they're just coming over to say hi and to see whether you might be, you know, have your sprinkler system connected to the Internet through an Israeli Unitronics PLC. |
| Leo: They're probably not geolocated in Iran, either; right? They're probably, you know, come - they look like they're coming from Indiana or somewhere, I would imagine. |
| Steve: I did note that there's a five-dot, which is interesting. |
| Leo: Yeah, that's interesting. |
| Steve: Because remember that Hamachi used the five-dot network extensively because not a single IP had ever been allocated from five-dot anything. And of course we gave - we had to give up on that a while ago as we began to run shy of IP4 address space. |
| Leo: I'll add these to my Ubiquiti blocklist. I block nations, you know, I block China. I block Russia. But like I said, I bet it doesn't all - they're not all Iranian. I'll block Iran. |
| Steve: Probably not. Probably specifically in order to get around these sorts of blocks. |
| Leo: Sure, yup, yup. |
| Steve: So Cisco's Talos group have just published their annual cybersecurity Year in Review. And the thing that caught my eye there was their breakdown of the most targeted vulnerabilities. Before we look at the top 10, here's what the Talos group said about their findings. They said: "In 2023, cyber threat actors exploited older software vulnerabilities in common applications. In many cases, the vulnerabilities were more" - wow, it's hard to even read this. "The vulnerabilities were more than 10 years old, consistent with CISA's finding that adversaries have targeted old security flaws more than newly disclosed recent ones in recent years. In fact, four of the top five most-targeted vulnerabilities we observed were also cited by CISA as being frequently exploited in prior years, further highlighting this point. This underscores the need for entities to regularly install software updates, as many of these systems were likely unpatched given the age of the targeted vulnerabilities." Meaning they're so old they obviously never received a patch since then. Which, right, okay. So they said: "The top targeted vulnerabilities were found in common applications like Microsoft Office. This finding is also substantiated by CISA, which noted that actors in 2022 prioritize CVEs that are more prevalent in their targets' networks." In other words, you know, they're going to attack the ones that are there; right? "Adversaries likely prioritize targeting widespread vulnerabilities because the exploits developed for such CVEs can have long-term use and high impact." That's a good point. If you're targeting, if you're able to target an exploit, a very old vulnerability, that says the system has never been updated since then, which further says it probably won't ever be again. So if you can get in using that, you can probably get to stay a long time. They said: "Lastly, most of the vulnerabilities on our list would cause substantial impact if exploited" - right, they're all like in the high nines in the CVSS score, and a lot of them are remote code execution. So ouch. They said: "With six of these top 10 receiving a maximum vulnerability risk score of 100 from Cisco Kenna and seven receiving the highest 'critical' score from the Common Vulnerability Scoring System (CVSS). Most of the CVEs are also listed in CISA's Known Exploited Vulnerabilities catalog" - their KEV, K-E-V - "which is meant to inform users on the security flaws for which they should prioritize remediation. The high frequency of targeting attempts against these CVEs, paired with their severity, underscores the risk to unpatched systems." So I have in the show notes the chart from Cisco's Talos Group. What's astonishing is that this year, okay, 2023 we're talking about, the number one most often exploited vulnerability, with a high CVSS of 9.3, is CVE-2017-0199. That's right, 2017. This is a vulnerability that... |
| Leo: So it's six years old. |
| Steve: Yes. Six years ago this thing was found. And we talked about it on the podcast extensively. This affects Microsoft Office and WordPad. It's a remote code execution vulnerability that leverages RTF files and a flaw in Microsoft's equation editor which is exploited through Microsoft Word. |
| Leo: Oh my god. Oh my god. |
| Steve: I know. For six years. Leo, it's remote code execution. It's a CVSS of 9.3, the maximum vulnerability score of 100. And it is the, today, the number one most exploited vulnerability. |
| Leo: Yeah, but I have to point out it's not the oldest on this list. |
| Steve: No, no, no. |
| Leo: By a long shot, in fact. |
| Steve: No. It's not. |
| Leo: Holy cow. |
| Steve: You know, and what's absent from these discussions - and from my ability to imagine - are any details about the machines which are, today, still not only running Microsoft's Office software from 2017, unpatched even once since then, but also have no other AV defense of any kind in place, even Microsoft's free solution. And this is not just one lonely abandoned system somewhere forgotten in a closet. The exploit enters through an email attachment. So the systems being compromised not only have no defenses of any kind and haven't received a single update in six years, but they are in active use. Somebody is receiving email on them and clicking a link to get themselves exposed to this. And it's the number one most often thing that happens. |
| Leo: Oh, my god. |
| Steve: Where are these systems? Whose are they? Okay. And want to take a guess at the number two problem among the top 10? Believe it or not, it also has the same high CVSS of 9.3, and its CVE was also issued back in 2017. |
| Leo: Oh, my god. |
| Steve: CVE-2017-11882. And that beauty is brought to us by Microsoft's Exchange Server. Now, obviously the same thing applies as above, although an unattended machine running Exchange Server might well be in some dusty old forgotten back closet somewhere. And lately I've been pushing the idea that automatic updates would solve many of the problems we're seeing in our industry today. But Microsoft pioneered the idea of automatic updates. They're enabled by default and have been for a very long time. Yet somehow a huge number of machines, enough to put their exploit at number one in the first place in the ranking, are still not being patched. They've remained unpatched. So it would really be interesting to look at case studies of the specific machines and the environments that surround them that allow six-year-old Microsoft flaws to remain present today. Who has these things? Where are they? We don't know. But Leo, we are going to know who's helping to support this podcast and the TWiT Network. |
| Leo: Very important. We would not want to forget such important people. You didn't mention that there is a CVE from 2010 from Apple Safari. |
| Steve: Yes, Safari, yeah. |
| Leo: But oh, don't worry, it's only a 9.3. Nothing to worry about. |
| Steve: Yow. |
| Leo: There's a CVE from 2012 for Microsoft Office, GZIP 2012. I mean, some of these are pretty dang old. It's kind of incredible. |
| Steve: It does demonstrate what a problem we have with software that isn't getting updated. |
| Leo: Legacy, yeah. |
| Steve: And that will - we'll be talking about the Log4j library next. But first a word from our sponsor. |
| Leo: I can't imagine anybody's still using a 2010 version of Safari. I don't even know if that would work. But if you are, stop; okay? Just stop. Stop the insanity. |
| Steve: So while we're on the topic of long-lasting vulnerabilities, it's not only the deep past that seems to be behaving irresponsibly. Two years ago, 2022, we kicked it off here with the news that a potentially devastating flaw in the Log4j library might rock the Internet. Fortunately, that never happened because the flaw was not readily exploited except in the one instance where it was found in a zero-day attack. So it was never the lowest hanging fruit. And as we've seen, the bad guys use the easiest route in, which Log4j turned out not to be. But that didn't mean that the flawed library didn't still need to be fixed and replaced because as long as this known-to-be-vulnerable library is present, a resourceful hacker might find a way to exploit it in its particular use case. Last Sunday, on the second anniversary of the discovery of this flaw, BleepingComputer reported on the findings of the application security company Veracode, who took a look at the status of Log4j today. Here's what BleepingComputer reported. They said: "Roughly 38% of applications using the Apache Log4j library are using a version vulnerable to security issues, including Log4Shell, a critical vulnerability identified as CVE-2021" - because it was at the very end of 2021, and we began talking about it at the beginning of 2022 - "44228, that carries the maximum severity rating, despite patches being available for more than two years." Okay? So 38% of applications that have a version of Log4j bound into them include a critical vulnerability. They said: "Log4Shell is an unauthenticated remote code execution (RCE) flaw that allows taking complete control over systems using Log4j 2.0-beta9 through 2.15.0. The flaw was discovered as an actively exploited zero-day on December 10th, 2021; and its widespread impact, ease of exploitation, and massive security implications acted as an open invitation to threat actors. "The circumstance prompted an extensive campaign to notify affected project maintainers and system administrators; but despite numerous warnings, a significant number of organizations continued to use vulnerable versions long after patches became available. Two years after the vulnerability was disclosed and fixes were released, there are plenty of targets still vulnerable to Log4Shell. A report from application security company Veracode, based on data collected between August 15th and November 15th, highlights that old problems can persist for extended periods. "Veracode gathered data for 90 days from 3,866 organizations that use 38,278 applications relying on Log4j with versions between 1.1 and 3.0.0-alpha1. Of those apps" - so those 38,278 apps - "2.8% use Log4j variants 2.0-beta9 through 2.15.0," that was the original Log4j disaster, "which are directly vulnerable to Log4Shell. Another 3.8% use Log4j 2.17.0, which, although not vulnerable to Log4Shell, is susceptible to the same CVE, a remote code execution flaw that was fixed in version 2.17.1. Finally, 32%" - get this - "are using Log4j earlier, Log4j version 1.2.x, which reached its end-of-life support in August of 2015, and all of those versions are vulnerable to multiple severe vulnerabilities published until 2022" - CVE-2022-23307, 305, and 302. "In total, Veracode found that about 38% of the apps within its visibility use an insecure Log4j version. This is close to what software supply chain management experts at Sonatype report on their Log4j dashboard, where they show 25% of the library's downloads in the past week include known vulnerable versions. The continual use of outdated library versions indicates an ongoing problem, which Veracode attributes to developers wanting to avoid unnecessary complications. Veracode found that 79% of developers chose to never update third-party libraries after their initial inclusion in their code base to avoid breaking functionality." In other words, this is deliberate in 80%, 79% of developers. "And this is true even if 65% of open-source library updates contain minor changes and fixes unlikely to cause functional problems. "Moreover, the study showed that it takes half of all projects over 65 days to address high-severity flaws. It takes 13.7 times longer than usual to fix half of what's in their backlog when understaffed, and over seven months to handle 50% of it when lacking sufficient information. Overall, Veracode's data shows that Log4Shell was not the wake-up call many in the security industry hoped it might be. Instead, Log4j alone continues to be a source of risk in one out of three cases, and may be one of the multiple ways attackers can leverage to compromise a given target. The recommendation for companies is to scan their environment, find the versions of open-source libraries in use, and then develop an emergency upgrade plan for all of them." Okay, now, there are many places where our industry is limping along and hoping for the best, such as with the use of very useful open source libraries. One of the problems is that developers could truly spend all of their time just keeping their code current with upstream library version changes. You know, I love, and I've mentioned this before, the Notepad++ application for Windows. It's really terrific. But its developer refuses to leave it the "F" alone. It's fine. It works. Just stop messing with it. It is constantly wanting to update itself. And since it does everything I want, I finally disabled its checking for updates because it was just so annoying. Every time I launched it, oh, look, a new version. Stop everything. Hold the presses. You know, upgrade. But now, with updates disabled just for the sake of sanity, now I have a real problem because I wouldn't know if a serious vulnerability turned up in it because it was just too noisy, because the developer abused the automatic update system. So I can imagine just how much chaos there would be if a project was using a large assortment of open source libraries which were themselves dependent upon other open source libraries, and so on up the dependency tree. It likely would be truly a full-time job just keeping everything current. And I totally sympathize with the idea that you update some library, and it breaks a bunch of things because the functionality changed. It wasn't just fixing a bug. It was, oh, look, we realize the whatever it is, you know, you don't want new, you just want secure. So it's not difficult to imagine a developer thinking, look, everything's working right now. I don't want to rock the boat and risk breaking things that are working just for the sake of having the latest and greatest version of everything. Maybe they're more secure, or maybe a bug was introduced when the change was made. Right? I mean, it's not like when we're adding new features we're not also bringing new bugs along. Otherwise, you know, Windows would have been perfect a long time ago. But it sure isn't. Okay. Two years ago we reported on the despicable tactic Sony was undertaking of blaming the DNS resolving service Quad9, just singled them out because, you know, they're non-profit, so they ought to be easy to squash and step on and set a precedent. So they sued Quad9 for the fact that they were providing random people on the Internet who have their browsers pointing at Quad9 the IP address of a pirate domain whose server was making some of Sony's copyrighted recordings available. Sony said that the domain owners didn't respond and couldn't be located. And I don't know about the hosting provider. So they decided to sue Quad9 because, you know, they could find them, and they would respond to email. |
| Leo: Notice they didn't sue Google. |
| Steve: Exactly. Exactly. And at the time, Leo, you and I were both livid at the idea that Sony might prevail in this since this might set a precedent where anyone with a grievance could sue someone who was providing some of the Internet's infrastructure, regardless of how incidental to the underlying complaint. So here we are two years later with the news that the German court where Sony brought this case has ruled in favor of the defendant Quad9. |
| Leo: Hallelujah. |
| Steve: Thank goodness. Denying any appeal and instructing Sony to pay all of the defendant's defense costs, which certainly is the way it should go. Here's what Quad9 had to say about all of this. They wrote: "Today marks a bright moment in the efforts to keep the Internet a neutral and trusted resource for everyone. Quad9 has received word from the courts in Dresden, Germany in the appeal of our case versus Sony Entertainment (Germany). The court has ruled in favor of Quad9, clearly and unequivocally. Needless to say, we are elated at the news. "Sony Entertainment (Germany) started a legal proceeding against Quad9 more than two years ago to force Quad9 to stop resolving certain domain names which they claimed were involved in copyright infringement behavior. We believe this lawsuit was an attempt to set a precedent, such that commercial rights holders could demand that sites on the Internet be made unreachable by forcing recursive resolvers to block content. We contended that recursive resolvers have no commercial or even remotely indirect relationship to any of the infringing parties, and that Sony's demand for blocking was ineffective, inappropriately specified, and not related to Quad9. "What made this case more problematic, in our view, was that the servers in question in this case were not located in Germany, and the links they pointed to were on servers also not in Germany. The domain name (canna.to) was not registered in Germany and was under the top-level domain operated by the nation of Tonga. Sony Entertainment further asserted that we block the domains globally, not just in Germany, as GeoIP does not block for users based in Germany with certainty. For that matter, Quad9 has no office or standing in Germany (we are a Swiss entity), but due to the Lugano Convention treaty it was possible for Sony to serve an injunction in Switzerland and drag Quad9 into legal proceedings there. "The appeal with the Higher Regional Court in Dresden follows a decision by the Regional Court in Leipzig, in which Sony prevailed, and Quad9 was convicted as a wrongdoer. Before that, Sony successfully obtained a preliminary injunction against Quad9 with the Regional Court in Hamburg. The objection against the preliminary injunction by Quad9 was unsuccessful, and the appeal with the Higher Regional Court in Hamburg was withdrawn by Quad9 since a decision in the main proceeding was expected to be made earlier than the conclusion of the appeal in the preliminary proceedings." And you have to read that paragraph five times to understand what they said. But basically they appealed their initial loss, and they won on appeal. They said: "The court has also ruled that the case cannot be taken to a higher court, and their decision is the final word in this particular case. Sony may appeal the appeal closure via a complaint against the denial of leave of appeal and then would have to appeal the case itself with the German Federal Court. So while there is still a possibility that this case could continue, Sony would have to win twice to turn the decision around again." They said: "We would like to clarify that even though Quad9 benefits from the liability privileges as a mere conduit, it is possible that a DNS resolver operator can be required to block as a matter of last resort if the claiming party has taken appropriate means to go after the wrongdoer and the hosting company unsuccessfully." Which is interesting because those - two years ago we said that, like, it's so wrong that Sony didn't do those things. Turns out that the way the language is written, and here Quad9 is saying, if a complainant did first go after the wrongdoer, and the hosting company, and do everything, you know, all their due diligence, which Sony didn't, then it might be ruled that a DNS resolver operator could be required to block the domain. Quad9 said: "Such measures could be legal action by applying for a preliminary injunction against a hosting company within the EU." Meaning that would be regarded as sufficient. "These uncertainties still linger, and we expect that this ongoing question of what circumstances require what actions, by what parties, will continue to be argued in court and in policy circles over the next few years." Now, I'll just pause here to say on a broader level this cannot be allowed to happen. Recognize what this would mean. This would mean that anybody, any big bully with money could sue DNS resolvers to force them to block domains that they're not happy with for any reason. It also means countries could do it. |
| Leo: And worse than that, it's worst than that because it wouldn't just be DNS resolvers. It'd be any infrastructure, any [crosstalk] infrastructure. Because it's all using that infrastructure. I mean, that's ridiculous. |
| Steve: I know. |
| Leo: They're not aligned, I mean, that's like suing the phone company because somebody phoned in a bomb threat. It doesn't make sense, and it's just untenable. It can't - you can't continue that way. |
| Steve: Yes. Please don't bring this up to that judge in Texas. |
| Leo: Oh, lord. Oh, lord. |
| Steve: Because that would be the end of life on the Internet. |
| Leo: And I always get nervous when stuff goes to courts because you don't know what you're going to get. You know? |
| Steve: Right. Right. So Quad9 says: "We remain committed to the concept that resolving a domain name is not an action that should be prohibited for commercial goals. The DNS does not contain content. It is a system designed for delivery only of pointers, not for data transport. The courts in Cologne also recently ruled in favor of Cloudflare in a similar case involving DNS recursive resolution, although that case also includes a separate consideration of issues relating to CDN and proxying services. And we are pleased to have consistent and clear statements from both courts in this matter of DNS recursive resolution. "Today was a significant win in Germany, but there is some disappointment, as well. We received a notice from a consortium of Italian rights holders - Sony Music Italy, Universal Music Italy, Warner Music Italy, and Federation of Italian Music Industry - who have demanded that Quad9 block domains in Italy, and there is potentially another court process ahead of us." Wow. Okay. So on the one hand this is good news, but it's also clear that this is not over yet. Sony is at it again, attempting to use their muscle to force Quad9, a non-profit DNS resolving company, to bend to their will. Here's the status of this second new lawsuit. Quad9 wrote: "While our case in Germany has been found in favor of Quad9, we've been served with another demand from commercial interests in an EU nation to block domain names, again based on alleged copyright violations. Italian legal representatives have presented us with a list of domains and a demand for blocking those domains. Now we must again determine the path to take forward fighting this legal battle, in another nation in which we are neither headquartered nor have any offices or corporate presence. "Unsurprisingly, the group of media companies that are represented by the plaintiff" - and it's an Italian legal firm, LGV Avvocati, Milan, Italy on behalf of the Federation against Music and Multimedia Piracy - "are Sony Music Entertainment Italy, Universal Music Italy, Warner Music Italy, as well as the Federation of the Italian Music Industry. "The short answer from us is that we're going to fight this demand for censorship, but it may take us time to be certain of a full victory and completion of our case in Germany before we are able to take on another court process. Quad9 can only have a few legal fronts open at once. We are nearly entirely dedicated to operational challenges of running a free, non-profit recursive resolver platform that protects end users against malware and phishing. We are not a for-profit company with lawyers on retainer. "We've complied with the request, and these names are now blocked on Quad9 systems. Since the courts have provided again no guidance on how we determine if a request is made by someone under Italian jurisdiction, we have applied this block globally. The German courts entirely disregarded our use of GeoIP lookups on queries, and asserted that since tests via a VPN were able to resolve the domain, we were in breach of court orders. We wish to avoid that same distraction again for the time being. "We've created an attributed blocking list with these domains on it, and they are searchable on the front page of our website in the search bar, and the results will contain information about the status and origin of the blocking requirements. When Quad9 decides to take action on this issue, we will post updates on this blog and modify our blocklists accordingly." Well, you know, Leo, saying again, this is so wrong. |
| Leo: Yeah. |
| Steve: I am so glad that the court in Dresden made Sony responsible for all the costs of Quad9's defense, and I hope Quad9 may be able to use their success in Germany to help with this next case. What Sony, Universal, and Warner are doing cannot be allowed to happen. And, I mean, what we really need is some higher level intervention somewhere. I mean, somehow. This just can't, as you said, Leo, this is just one handy part of the infrastructure. But, you know, the separation has to be made. |
| Leo: It makes, I mean, it just makes you not want to do good things. It's like, you know, they're doing this great service. |
| Steve: I know, it's sad. |
| Leo: And thank goodness that they have the fortitude. I would just say, well, screw you, bye. But good for them that they stuck it out. I mean, it's got to cost them a ton to do this. |
| Steve: Yeah. Well, and the good news is they're getting their expenses reimbursed. |
| Leo: Sony, yeah. |
| Steve: And so I hope so. So the problem is, Sony is so huge. |
| Leo: They don't - it doesn't hurt them. |
| Steve: And they do have, I mean, they have attorneys on retainer who they're paying a salary to, so it doesn't cost them anything. |
| Leo: It's not a fair fight. |
| Steve: No. I hate bullies. That just - I have a problem with that. So a group known as Searchlight Cyber posted an analysis about the state of the DDoS for Hire business which exists on the so-called Dark Web. That made me realize that while I've referred to the Dark Web often in the past, we've really never stopped to talk about it. For anyone who's unsure, the Dark Web is actually a thing, or rather a place. It's not just an expression. And you cannot get there from here. It's not just a matter of using some secret URL to bring up a Dark Web site. There are three terms used within the cyber security community to refer to three classes of the web. There's the Clear Web, the Deep Web, and the Dark Web. The web that we all use every day is more formally known as the Clear Web. It's what Google indexes and where anyone can easily wander with links that are shared with us either by a public search engine or by other web pages. This is the traditional web that Tim Berners-Lee first conceived of when he was at CERN. And interestingly, this Clear Web only contains roughly 4% of the entire web content. It's like the tip of an iceberg. So where's the rest? Most of the rest resides in the so-called Deep Web. This is the web content that is not indexed publicly because it requires authenticated access through a portal of some kind. So this includes things like our credit reports, IRS tax records and medical histories, fee-based content, membership websites and confidential corporate web pages. Those are all considered to exist on the Deep Web. And estimates place this Deep Web content at roughly 96% of the total browser-accessible web. And finally, a small subset of this Deep Web is known as the Dark Web. The dark web's servers are deliberately hidden and are accessible only through the Tor browser on the Tor network. It's necessary to use Tor because those servers and the services they offer wish to remain hidden and quite difficult, if not nearly impossible to locate. And it's worth noting that despite its ominous-sounding name, not all of the dark web is used for illicit purposes, though this is another place where the emergence of cryptocurrency has transformed the place from a backwater hacker curiosity into a significant collection of criminal enterprises. My advice would be to stay as far away from the Dark Web as possible. So I won't be offering any guide or tips to accessing this dark underbelly of the Internet. But if you're really curious and want to go poking around down there, you'll find that the Clear Web contains many step-by-step how-to guides into setting up a secure sandboxed OS, obtaining the Tor browser, putting on your hazmat suit, holding your breath, and taking the plunge. Good luck. And as for what the Searchlight Cyber guys found out about DDoS for Hire services being offered on the Dark Web, there was nothing really noteworthy. It's pretty much what we would expect. Portals exist where people can create an account and transfer some of their cryptocurrency to it to create a positive balance. Then they select the type of DDoS attack they wish to launch, either at OSI stack Level 4, which is down at the transport layer, so using either UDP or TCP flooding packets, or up at Level 7, which is the application layer, so an HTTP connection and query flood. Then the target IP or URL is provided, and the size and duration of the attack is specified, and the site takes care of conducting the attack from there. One thing that did surprise me was that one of these services, named the "Nightmare Stresser," claimed to have 566,109 registered users. That number cannot be verified, of course. But it does perhaps support the view from up here out in the Clear Web, you know, up in the light, we see more or less constant DDoS attacks, so much so that they're just prevalent. Talk to any Tier 1 Internet provider, and it's like, oh, yeah, you know, that's just happening all the time. So 566,109 registered users of this one service where if you want someone to be attacked, it's not hard to do. And actually it doesn't even cost that much, which is another reason we're seeing so many of them. Okay. Let's close the loop with a few listeners. Mike Ward, via DM, said: "Hi, Steve. I just discovered a major privacy and security flaw in the messaging app Telegram. Telegram," he wrote, "automatically informs users you've joined if that user has your phone number, and has previously uploaded it to Telegram as part of their contact list sharing, even if you deny Telegram access to your contacts." He said: "I discovered this firsthand just now. After downloading and signing up for Telegram, and specifically denying it access to my contacts, a friend sitting across the table from me received a notification on his phone that said I had joined Telegram." Mike wrote: "This is a major privacy and security flaw, as a stalker or domestic abuser could upload a victim's number and be automatically notified if that person ever joins Telegram. For that matter, so could any law enforcement or government agency. It may also explain why spam and scams are so prevalent on the services, as mal-actors are able to upload your phone number acquired from somewhere else, then inundate you with messages the moment you join." So that was an interesting observation, Mike. And I agree that this appears to be a significant privacy failing of Telegram. The system ought to require mutual sharing of intersecting contact information in order to provide any notifications, not just one-way, unilateral contact use. They likely use the less private approach as a means of promoting the further use and adoption of Telegram. But that's not what anyone wants from a secure messaging solution. |
| Leo: Yeah, it's actually very annoying because I get so many messages from Telegram saying your friend has just joined Telegram. Like, and I never give - by the way, let's emphasize this. Never give your contacts to any third party. You're basically turning over information about your friends to a third party without their consent. Never do that. |
| Steve: Right. |
| Leo: Not for the very mild convenience of getting notified when your friends join Telegram. But you know that's not why they want that information. |
| Steve: Right. |
| Leo: Yeah. |
| Steve: Yeah, I'm still using an old and long-since-retired landline as the phone number that I give out most places. |
| Leo: Right, that's a good idea. |
| Steve: I just won't let them have even my phone number because, you know, I look at other people whose phones are just exploding, you know, with nonsense, and I'm glad I don't have that. Justin Ekis, he said: "Have you ever seen something like this? Looks like my cell carrier is forcing me to trust an additional root CA. This is unacceptable. I'll be switching at the earliest opportunity. Thought my fellow listeners would like to know." And he included a link to a Twitter media snapshot which was of his Xfinity cellular provider asking him to accept a root certificate and give it full trust on his phone. |
| Leo: Oh, sure. |
| Steve: I know. |
| Leo: Why the hell wouldn't I want to do that? |
| Steve: Obviously we agree with Justin completely. |
| Leo: Wow. |
| Steve: There's only one possible reason for this, which is that Xfinity wishes to insert a transparent proxy into his Internet connections. |
| Leo: Right. So why? So they could put [crosstalk] in there; right? |
| Steve: Well, and it will decrypt everything he does with his phone. |
| Leo: Yeah. |
| Steve: All of his use of the Internet browsing will be decrypted by certificates which Xfinity is able to build on the fly, which will be trusted because he accepted their root cert. I mean, it is full-on spying. And so yes, that should certainly raise warning flags for anybody who understands what's going on. Unfortunately... |
| Leo: I should mention, Steve, that this link that you put in here is actually a link to direct messages. So I can't see it, and no one could see it because it's a message to you. |
| Steve: Ah, okay. |
| Leo: So don't get all excited, folks. |
| Steve: Thank you, Leo. |
| Leo: I would love to see that screenshot. That's why I clicked it. But geez, Louise. |
| Steve: Ah, right, right. |
| Leo: Yeah, yeah. |
| Steve: So, yes. Anyway, do not accept any requests for, like, from your cell provider saying, hey, you know, in order to continue our relationship with you, you're going to have to add this root certificate to your phone. |
| Leo: Holy cow. |
| Steve: No. No. |
| Leo: Is that a condition of using Xfinity cellular? If it is... |
| Steve: Apparently it's [crosstalk]. |
| Leo: Don't, yeah. |
| Steve: Right, right. |
| Leo: Ugh. |
| Steve: Justin was very right to bring this up. Thank you. Elliot Alderson said: "Instead of pulling all but six CAs," meaning six CA roots, "couldn't someone make an extension that just shows green for one of the main six, yellow for another CA, red for HTTP, and a duck for a QWAC cert? Maybe need blue, orange, and pink or something for color blindness." So that's an interesting thought. But my concern would be that this places the burden on the user to observe some visual flag. If our goal in removing the ridiculous number of barely, if ever, needed certificate authority root certs is to improve our security in the event that one of the fringe CAs mints a malicious cert, then I still think that the cost of running with only the top six is likely very minimal and represents the best solution. Michael Smithers says: "Hi, Steve. I'm a longtime listener and SpinRite customer. Thank you for all your work. Can you recommend a hardware VPN solution for home that's not complicated to set up? I need to access my home server from around the world, mainly for version control access, and I presently have some ports Internet-facing with port forwarding. Yes, I know this is not good. I can see from the logs that bots are continuously attempting to guess login credentials and are causing user lockouts for some more common usernames. Many thanks for your help. Here's to 1000 and beyond. Michael." Okay. VPNs are definitely useful when you want to protect your use of the Internet, for example, from your prying ISP, who's like trying to scavenge all the metadata they can from you. But setting up your own VPN server to provide incoming access is probably no longer the optimal solution. For all of those needs you really want to look at an overlay network. Think Tailscale or ZeroTier. Overlay networks is the newer, better, more secure and much more powerful and flexible way to solve this sort of problem. We've talked about these before, and I've received a bunch of feedback from our listeners who have said that they have been astonished by how easily the system was installed, set up, and running. And another advantage is that they run through NAT routers without needing any static port forwarding, so no bots are going to be probing for a connection. Tailscale has a companion page where they compare themselves with ZeroTier, and I've looked at that page in the past. It appears to be quite evenhanded. Since nothing else has claimed GRC's shortcut of the week so far, grc.sc/952 will take you directly to that page. It's at tailscale.com/compare/zerotier, Z-E-R-O-T-I-E-R. I'm very glad that Michael asked this question since today's new overlay network solutions really do represent a useful advance and a much better way to solve the need for roaming access to a remote network. Once upon a time it was Hamachi and their five-dot networks. You know, we talked, we covered this a long time ago. Now these things have gone mainstream. They're open source. They're free. They have been audited. They are bulletproof. And they really work. Tailscale or ZeroTier. And Tailscale, by the way, runs on top of WireGuard, which is the rewrite of a state-of-the-art secure tunneling technology. It just really works, and it is very fast. So that's what I would look at for any of that sort of problem. And finally, Chris Hatch says: "Steve, very thankful you're continuing SN past 999. Longtime listener. Just heard you mention API Monitor. When I put the URL in Firefox, Malwarebytes blocked going there with the warning 'Website blocked due to Trojan.'" He said: "I checked with Virus Total, and it had two AV's that thought it was malicious. What do you do to check if a site is safe to visit? Looking forward to upgrading SpinRite when 6.1 is released. Thanks for the great show. Chris." Okay. Unfortunately, that amazing API Monitor tool that I talked about before and impressed me so much when I had to do some reverse engineering of some Microsoft undocumented stuff, it's about 10 years old. And it has not been touched in all that time. It is also not digitally signed since, 10 years ago, few things were. And I recognize that many people feel that any software that has apparently been abandoned is automatically worthless. That's not my feeling at all. I strongly prefer software that has become stable because all of its bugs have been found and eliminated, making that software complete and finished. I'm fully aware that's not the way our industry has evolved where many programs are full of bugs or where commercial interests require that software remains forever in flux with people continually paying in the hope that it will finally someday be finished. For what it's worth, only triggering two out of all of VirusTotal's AV scanners, generally about 70, means that there's nothing whatsoever wrong with that code. If the screen had lit up with 20 or more out of 70, then, yeah, I would never have let it get near my machine. Just now, like two hours ago, I dropped my copy of API-Monitor-Setup.exe, which I downloaded and then tested against VirusTotal. I dropped it on VirusTotal. I just now received a 0 out of 71 score. So VirusTotal agrees that the code being served by that site, old and unsigned as it is, is clean and safe to use. And Leo, this brings us to our third sponsor, and then I think what is going to be a really illuminating and interesting discussion of a recent quantum computing breakthrough. |
| Leo: I am, you know, fascinated by this whole thing. And as I said, skeptical. So I'm looking forward to hearing this. Okay. Now we've got to find out what's all this about quantum computing, Steve. |
| Steve: So the podcast actually has an extended title. It's "Quantum Computing Breakthrough: A Breakthrough for the Turbo Encabulator," and "All Your Qubits Are Belong to Us." |
| Leo: Yeah, we couldn't fit that in the lower third, Steve. |
| Steve: No. |
| Leo: Do people know what the Turbo Encabulator is? |
| Steve: I think maybe now would be a good time to introduce them, Leo. |
| Leo: I'll play a little short - this is just a short audio-only clip. |
| Steve: Just a piece of the beginning. |
| Leo: Just so you understand what we're talking about here. |
| Steve: It will prepare them for what is to come. CLIP: For a number of years now, work has been proceeding in order to bring perfection to the crudely conceived idea of a transmission that would not only supply inverse reactive current for use in unilateral phase detractors, but would also be capable of automatically synchronizing cardinal grammeters. Such an instrument is the Turbo Encabulator. |
| Leo: There you have it, ladies and gentlemen. You've wanted it. You've needed it. |
| Steve: Yes, and that lingo will sound familiar in a minute. |
| Leo: By the way, that's doublespeak nonsense. But what you're going to tell us is real. |
| Steve: Eh, we've got some of the doublespeak in there. It's not nonsense. |
| Leo: Okay. |
| Steve: So DARPA-funded quantum computing research conducted at Harvard made headlines last Thursday with what those in the know are pretty certain represents a significant step forward in the quest for a practical quantum computer. One of the big problems, which is currently and has been limiting the practical application of quantum computers, is the need for extensive error correction. One way to think of this is that quantum bits, the so-called qubits, spelled Q-U-B-I-T-S, qubits, are powerful but imprecise. |
| Leo: Yes. |
| Steve: So when you need precision for things like, you know, cryptographic computations, where quantum's fuzziness is a bug, not a feature, it's necessary to use a whole bunch of fuzzy qubits in an error-correcting system. |
| Leo: Is it using - let me just ask, prefabulated aluminite, surrounded by a malleable logarithmic casing? |
| Steve: It's a foundation of prefabulated aluminite. Yeah, yeah. Yeah. |
| Leo: Okay. Just checking. |
| Steve: The individual fuzzy qubits are referred to as "physical" qubits. But what we want and need for many of the types of calculations that quantum computers promise are what's known as "logical" qubits. And as I said, traditionally, the number of physical to logical qubits has been around 1000:1. Which is to say it takes 1000 fuzzy physical quantum bits in an error-correcting mode to reliably obtain a single solid logical bit. And it's only the logical bits that are able to do most of the useful work. Okay, now, in a minute I'll share a useful explanation of what was recently accomplished and just published. And that will come from a non-physicist who speaks English as his first language, rather than quantum. |
| Leo: Good. |
| Steve: Reading the actual paper, published in Nature last Wednesday, written by those who do speak quantum fluently, I was reminded of our favorite turbo encabulator which made good use of those flambulating differential reverse trunions. |
| Leo: Oh, yes. |
| Steve: To give everyone - you ought to have those, and they have to be differential. |
| Leo: Oh, yeah. |
| Steve: To give everyone a flavor of just how far out this science has wandered, this is what they wrote for the abstract of their paper, which was titled "Logical quantum processor based on reconfigurable atom arrays." They wrote: "Suppressing errors is the central challenge for useful quantum computing, requiring quantum error correction for large-scale processing. However, the overhead in the realization of error-corrected 'logical' qubits, where information is encoded across many physical qubits for redundancy, poses significant challenges to large-scale logical quantum computing." |
| Leo: Makes sense so far. Yeah, yeah. |
| Steve: "Here we report the realization of a programmable quantum processor based on encoded logical qubits operating with up to 280 physical qubits. Utilizing logic level control and a zoned architecture in reconfigurable neutral atom arrays, our system combines high two-qubit gate fidelities, arbitrary connectivity, as well as fully programmable single-qubit rotations and mid-circuit readout." |
| Leo: Of course. |
| Steve: But you have to have that, mid-circuit readout. "Operating this logical processor with various types of encodings, we demonstrate improvement of a two-qubit logic gate by scaling surface code distance from d = 3 to d = 7." |
| Leo: Oh. |
| Steve: Yeah, that was - uh-huh, huh. |
| Leo: Yeah. |
| Steve: "Preparation of color code qubits with breakeven fidelities, fault-tolerant creation of logical gigahertz states, and feed-forward entanglement teleportation, as well as operation of 40 color-code qubits. Finally, using three-dimensional [8x3x2] code blocks, we realize computationally complex sampling circuits with up to 48 logical qubits entangled with hypercube connectivity with 228 logical two-qubit gates and 48 logical CCZ gates." |
| Leo: Ah. |
| Steve: Yeah. "We find that this logical encoding substantially improves algorithmic performance with error detection, outperforming physical qubit fidelities at both cross-entropy benchmarking and quantum simulations of fast scrambling. These results herald the advent of early error-corrected quantum computation and chart a path toward large-scale logical processors." |
| Leo: Well, of course, |
| Steve: Well, naturally. |
| Leo: Oh, thank god. |
| Steve: What you're looking for is high-fidelity feedforward entanglement teleportation. |
| Leo: Uh-huh. |
| Steve: Wow. And that was not nonsense. That was actually the abstract from the paper published in Nature last week. |
| Leo: I bet there's only 100 people in the whole world who could understand that. Do you understand that? |
| Steve: No. |
| Leo: No. |
| Steve: No. |
| Leo: Okay. I'm relieved. |
| Steve: But we're going to get to the gist of what it means. Everyone agrees that if this turns out to work as it appears to, it would represent a bonafide breakthrough in quantum computing by dramatically reducing that previous 1000:1 physical-to-logical qubit ratio thanks to a breakthrough in quantum error correction technology. And when I saw this, it immediately became this week's podcast topic. Okay. So now I want to share English. I want to share something that was written by a non-physicist where there will be no mention at any point of feedforward entanglement teleportation. |
| Leo: Oh, well, okay. |
| Steve: It begins with this powerful claim: "Widespread quantum computing may now come years sooner than widely expected." |
| Leo: Wow. |
| Steve: Yes. "Thanks to a Pentagon-funded project, as in DARPA which, as we know, also brought the world the Internet, with implications for everything from rapid vaccine development and weather forecasting to cyberwarfare and codebreaking. If the Harvard-led experiment can be replicated and scaled up, it would still take years to make quantum computers widely available to run new forms of artificial intelligence for medical research, scientific experimentation, and military command-and-control." Thus DARPA's interest. "But early adopters would almost certainly include intelligence agencies eager to crack encryption protocols widely used by governments and businesses alike. That makes it all the more urgent to implement the new quantum-resistant encryption algorithms the National Institute of Standards & Technology (NIST) aims to finalize next year in 2024. "On Wednesday afternoon" - that's last Wednesday - "the Defense Advanced Research Projects Agency and a paper in Nature announced results from a team of almost two dozen scientists, most of them from Harvard, funded by a DARPA program known as ONISQ (Optimization with Noisy Intermediate-State Quantum devices). By manipulating individual atoms with precise, low-powered laser beams, known in the trade as 'laser tweezers,' the team was able to create 'quantum circuits' that correct for errors much more efficiently than alternative techniques, potentially overcoming the biggest barrier to practical quantum computers. "DARPA's program manager for ONISQ said 'Quantum error correction is fundamentally challenging.' Mikhail Lukin, one of the Harvard scientists" - actually it's Lukin's lab where this was done - "said: 'You cannot copy quantum information, and you also cannot measure the quantum state without destroying it.' Different corporate, government and academic teams have tried various approaches to error correction, but they all waste an exorbitant amount of the quantum computer's power. But the Harvard team has found a radically more efficient way to guard against errors. DARPA's program manager said: 'This is truly revolutionary. Having been demonstrated and even validated in this paper, we are off to the races.' "Back-of-the-envelope calculation suggests that the Harvard team's experimental quantum computer is potentially four times as powerful as the most advanced quantum chip available for purchase, IBM's Condor. Unveiled on December 4th, Condor boasts 1,121 qubits, which is almost a threefold increase over last year's record-breaking IBM Osprey. So what's a qubit? The term turns out to have multiple meanings. While a normal 'classical' computer uses bits that can represent either zero or one, a qubit exploits the fuzzy nature of quantum phenomena to let it represent all the infinite possible values in between. That's a nifty trick that could shortcut previously impossible calculations. But because quantum phenomena are so strange, it's also much harder to figure out whether a qubit is working properly or glitching. "So all quantum computers to date have had to devote most of their qubits to double-checking each other. That means the number of usable 'logical qubits' that can actually do reliable calculations is orders of magnitude smaller than the number of a machine's physical qubits. Using error-correcting methods, it takes more than a thousand physical fuzzy qubits acting together to form one logical qubit. IBM is now exploring a new, more efficient error-correcting technique it says should allow a mere hundred physical qubits to form one logical qubit. So depending on whether the technique is used, a high-end chip with a thousand physical qubits, like Condor, could generate as little as one usable logical qubit or as many as 10. "The Harvard team, however, used a radical new approach to error correction that turns a mere 280 physical qubits into 48 logical qubits. That's about 20 times better than what IBM is hoping it may be able to achieve in its next-generation chip and 200 times more efficient than the 1000:1 ratio that current techniques are trying to reach. "One of the Harvard physicists said: 'Up till now, all the state-of-the-art people have realized was one logical qubit or maybe two at most. We have done 48. For the first time, we've actually built a processor which operates on these logical qubits. We demonstrated the key basic elements of this processor, namely the ability to encode, decode, and perform logical gate operations. For the first time ever, we executed algorithms with logical qubits." "Skip Sanzeri, a co-founder of QuSecure, which builds software to defend against quantum-powered hacking, said logical qubits are the Holy Grail for quantum computing. He explained that physical qubits are very ethereal. They can be disturbed easily, which is what leads to errors. Sanzeri said: 'With the Harvard team's approach you don't need thousands, hundreds of thousands, or millions of physical qubits to error-correct. If it works, it's a huge speed-up.'" Okay. So I want to flesh this out one bit more with some additional background coverage and quotes from other researchers quoting about this breakthrough: "The system is the first demonstration of large-scale algorithm execution on an error-corrected quantum computer, heralding the advent of early fault-tolerant, or reliably uninterrupted, quantum computation. "Professor Lukin, who runs the lab at Harvard, described the achievement as a possible inflection point akin to the early days in the field of artificial intelligence. The ideas of quantum error correction and fault tolerance, long theorized, are starting to bear fruit. He said: 'I think this is one of the moments in which it is clear that something very special is coming. Although there are still challenges ahead, we expect that this advance will greatly accelerate the progress toward large-scale, useful quantum computers. "The National Science Foundation's Denise Caldwell, who is the acting assistant director of the Mathematical and Physical Sciences Directorate which supported the research through the NSF's Physics Frontiers Centers and Quantum Leap Challenge Institutes programs, agrees." She said: "This breakthrough is a tour de force of quantum engineering and design. The team has not only accelerated the development of quantum information processing by using neutral atoms, but opened a new door to explorations of large-scale logical qubit devices, which could enable transformative benefits for science and society as a whole. "In quantum computing, a quantum bit or qubit is one unit of information, just like a binary bit in classical computing. For more than two decades, physicists and engineers have shown the world that quantum computing is, in principle, possible by manipulating quantum particles be they atoms, ions, or photons to create physical qubits. But successfully exploiting the weirdness of quantum mechanics for computation is more complicated than simply amassing a large number of qubits, which are inherently unstable and prone to collapse out of their quantum states. "The real coins of the realm are the so-called logical qubits formed from bundles of redundant, error-corrected physical qubits. These can store information for use in a quantum algorithm. Creating logical qubits as controllable units, like classical bits, has been a fundamental obstacle for the field; and it's generally accepted that until quantum computers can run reliably on logical qubits, the technology cannot really take off." In other words, that's what just happened, folks. "To date, the best computing systems have demonstrated one or two logical qubits, and one quantum gate operation, akin to just one unit of code, between them. "The Harvard team's breakthrough builds on several years of work on a quantum computing architecture known as the neutral atom array. This was also pioneered in Lukin's lab. It is now being commercialized by QuEra, which recently entered into a licensing agreement with Harvard's Office of Technology Development for a patent portfolio based on innovations developed by Lukin's group. "The key component of the current system is a block of ultra-cold, suspended rubidium atoms, in which the atoms, the system's physical qubits, can move about and be connected to pairs, or 'entangled,' mid-computation. Entangled pairs of atoms form gates, which are units of computing power. Previously, the team had demonstrated low error rates in their entangling operations, proving the reliability of their neutral atom array system. With their logical quantum processor, the researchers now demonstrate parallel, multiplexed control of an entire patch of logical qubits, using lasers. This result is more efficient and scalable than having to control individual physical qubits. "The paper's first named author Dolev Bluvstein, a Griffin School of Arts and Sciences Ph.D. student in Lukin's lab, said: 'We're trying to mark a transition in the field, toward starting to test algorithms with error-corrected qubits instead of physical ones, and thus enabling a path toward larger devices." So everyone agrees that this is almost certainly a benchmark on the road to moving quantum computing from a promising curiosity in the lab to a place where it can be commercialized for use in solving previously intractable problems in the real world. Cryptography is not in trouble yet. But that trouble just jumped significantly closer. Remember that it's not symmetric crypto that's endangered by quantum computing. So algorithms such as the AES's Rijndael cipher and hashing-based solution they've always been and will likely continue to be quantum safe. But asymmetric crypto such as RSA, based on the previously intractable problem of factoring a huge number composed of two half-as-huge prime numbers, and elliptic curve crypto are both on the chopping block. So it was prescient that the academic crypto community began worrying about this years ago and has now generated a series of quantum-safe replacement algorithms that are rapidly being moved toward adoption. The challenge is that almost everything that's currently being done in the world today is still using traditional quantum unsafe asymmetric cryptography. I say almost everything because remember that three months ago, in September, Signal announced their adoption of quantum-safe crypto running in parallel with traditional time-proven, but now potentially unsafe, crypto. The other entity that has proven itself to be prescient is the U.S. National Security Agency, our NSA. As we know, having watched them build that massive data center facility out in Utah, they've taken advantage of the astonishing reduction in the cost of electromagnetic storage - or "spinners" as we call them over in GRC's newsgroups and forums - to suck up and store mass quantities of Internet and other communications that they cannot decrypt today, but which they will likely be among the first to be decrypting once they receive their standing order for serial number 1 of a sufficiently powerful quantum computer. I'll bet that facility already has a room set aside just waiting for something to be installed there. What this means for the industry is that we're not going to be able to enjoy the traditional luxury of upgrading our communications encryption when we eventually get around to it. It will be necessary for the finally approved standards to be moved into preliminary implementations with more speed than normal. The good news is that this is not our first retirement of creaky older crypto in favor of shiny new crypto, so we've gained experience with doing this and can expect it to go smoothly. Once sufficient testing has been done, these next generation algorithms will need to be deployed. And again, not eventually, but as soon as possible. The wisdom Signal demonstrated of running any new and inherently less well-proven algorithm alongside and in parallel with a traditional well-proven asymmetric crypto system, may be the best in the near term. Requiring that the results from both systems are needed for encrypting and decrypting an ephemeral symmetric key provides protection against the possibility of an unexpected weakness being found in the newer post-quantum system, which would break everything. Then later, once the new system has been shown to be entirely safe, the secondary parallel backup system could be dropped to obtain a boost in performance. The surprise this week is yet another reason for taking this podcast past 999. We definitely want to be here to chronicle the adventure and the arrival of post-quantum cryptography. |
| Leo: Well, and I know your focus is crypto, of course. But you mentioned it, you know, in glancing. We are at a kind of already at an inflection for AI. |
| Steve: Yeah. |
| Leo: And it's throwing this kind of massively advanced computing against the software we've developed. I mean, right now it's a software thing running on existing hardware. We're getting better at the hardware. |
| Steve: Well, running on the fastest available, monstrously crazy GPU arrays. Now you just drop one rubidium atom on it, and it says, "Well, hello. How are you feeling?" |
| Leo: Well, and I also think that there's a kind of a nice nexus between what is not exactly determined, these are not deterministic computers, these quantum computers. And AI shouldn't be deterministic either. We're not deterministic. And so there's a certain - the fuzziness of it kind of lends itself, I think. |
| Steve: There's a synergy; right. |
| Leo: Yeah. So honestly, we may think, oh, yeah, crypto, fine. But we had no idea Hal 9000 was just around the corner, or Skynet, or worse. And of course if it is security and privacy you're concerned about, remember that big data facility that the NSA built in the Midwest, storing every electronic communication for the last two decades, much of which they couldn't decrypt. Well, now, thanks to stuff like this, maybe they will be able to decrypt it unless it used perfect forward secrecy. And with modern analysis techniques, AI-style analysis techniques, extract the juice out of it in new and terrifying ways. |
| Steve: Yeah. |
| Leo: So we are at - we could well be, this could be a watershed. I think you're right. We want to go past 999 because I think right now we are in technology watershed that is the equivalent of the invention of the personal computer or the Internet. Maybe even more significant. I don't know, is that overstating it? |
| Steve: I don't think that's overstating it, my friend. No. |
| Leo: We live in interesting times, Steve. And it gives us something to talk about, which is good. And it gives you something to think about, which is really good. Listeners, that's, you know, I mean, that's why we think what we do here at TWiT is so important because staying on top of these developments and understanding them, it is why we've always been here, going back, you know, 15 years, 18 years. But now more than ever I think that it's important that we as citizens kind of stay on top of this. We can't let Ron Wyden do all the work. And be able to act rationally around it. Thank you, Mr. Gibson. You'll find Steve's work at GRC.com, the Gibson Research Corporation. That's where SpinRite lives, his bread and butter, the world's best mass storage maintenance and recovery utility available. Right now it's 6.0. You did say you were going to have an announcement today. Okay. I'm not going to hold you to it. |
| Steve: I did. I slipped. Everything last week fought against me. I did a big posting in my newsgroup to explain what happened. |
| Leo: Don't worry. |
| Steve: Definitely next week I'll have an announcement. |
| Leo: We don't hold it against you, Steve. We love you, and we know you're working as hard as you can. |
| Steve: I'd rather get the bugs out now than later. |
| Leo: Do it right. Absolutely. That's one of the reasons we totally respect you. Take care. |
| Steve: Bye. |
|
 | Gibson Research Corporation is owned and operated by Steve Gibson. The contents of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP, NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy. |  |
| Last Edit: Dec 18, 2023 at 11:09 (544.09 days ago) | Viewed 6 times per day |