Today, we welcome the 46th government onboarded to Have I Been Pwned’s free gov service: the Philippines.
The Philippines’ National CERT, working with the Department of Information and Communications Technology, now has access to monitor official government domains against the data in HIBP. This gives their Cyber Threat Intel and Monitoring Section the ability to identify exposure across government email addresses and respond quickly when those accounts appear in new data breach.
This is precisely what the HIBP government service was built for: helping national cyber teams better understand credential exposure across their government domain space, monitor for compromised accounts on demand via API, and receive notifications when government domains are impacted by newly loaded breach data.
The Philippines joins a growing list of national CERTs and government cybersecurity teams using HIBP to help strengthen national cyber defense, protect government departments and resources, and reduce the risk posed by compromised credentials before attackers can take advantage.
Today, we welcome the 45th government onboarded to Have I Been Pwned’s free gov service: Bhutan. The Bhutan Computer Incident Response Team, BtCIRT, now has access to monitor Bhutanese government domains against the data in HIBP. As Bhutan’s national CIRT, BtCIRT is responsible for consuming threat intelligence and sharing relevant insights with its constituents, helping identify and respond to cyber risks affecting government services and the people who depend on them.
This is exactly the sort of organisation the HIBP government service was built to support: national cybersecurity teams using breach data to identify leaked credentials and compromised databases associated with their government domains.
BtCIRT now joins the growing list of national CIRTs and government cybersecurity teams using HIBP to better understand their exposure, respond quickly when new breaches appear, and reduce the risk posed by compromised credentials before attackers can take advantage.
Today, we welcome the 44th government onboarded to Have I Been Pwned’s free gov service: The Bahamas. The National Computer Incident Response Team of The Bahamas, CIRT-BS, now has access to monitor government domains against the data in HIBP. As the national CIRT, CIRT-BS is responsible for coordinating and supporting cybersecurity-related matters across the country, and this access will help them prevent, identify, and mitigate incidents involving compromised credentials and data exposure affecting government entities and critical stakeholders.
This is precisely the sort of use case the HIBP government service was designed for: giving national cybersecurity teams the ability to identify exposure across their own digital ecosystem, respond quickly when government accounts appear in breaches, and reduce the risk posed by reused or compromised credentials before attackers can take advantage.
CIRT-BS joins a growing list of national cybersecurity teams using HIBP to help protect government departments, public resources, critical stakeholders, and the people who keep them running.
Today, we welcome the 42nd government onboarded to Have I Been Pwned’s free gov service: Costa Rica.
The CSIRT of the Government of Costa Rica now has access to monitor government domains against the data in HIBP. This enables their national cybersecurity incident response team to identify exposure of government email addresses in data breach, support prevention and analysis activities, and respond more quickly when new incidents appear.
Costa Rica’s CSIRT plays a national role in cybersecurity incident response, helping coordinate, analyse, and respond to threats affecting the government and the broader digital ecosystem. We’re very happy to support that mission by providing visibility into breached government accounts and helping them proactively reduce risk across public sector services.
We’re standing at the threshold of a new era in cybersecurity threats. While most consumers are still getting familiar with ChatGPT and basic AI chatbots, cybercriminals are already moving to the next frontier: Agentic AI. Unlike the AI tools you may have tried that simply respond to your questions, these new systems can think, plan, and act independently, making them the perfect digital accomplices for sophisticated scammers. The next evolution of cybercrime is here, and it’s learning to think for itself.
The threat is already here and growing rapidly. According to McAfee’s latest State of the Scamiverse report, the average American sees more than 14 scams every day, including an average of 3 deepfake videos. Even more concerning, detected deepfakes surged tenfold globally in the past year, with North America alone experiencing a 1,740% increase.
At McAfee, we’re seeing early warning signs of this shift, and we believe every consumer needs to understand what’s coming. The good news? By learning about these emerging threats now, you can protect yourself before they become widespread.
A new case disclosed by Anthropic, first reported by Axios, marks a turning point: a Chinese state-sponsored group used the company’s Claude Code agent to automate the majority of an espionage campaign across nearly thirty organizations. Attackers allegedly bypassed guardrails through jailbreaking techniques, fed the model fragmented tasks, and convinced it that it was conducting defensive security tests. Once operational, the agent performed reconnaissance, wrote exploit code, harvested credentials, identified high-value databases, created backdoors, and generated documentation of the intrusion. In all, they completed 80–90% of the work without any human involvement.
This is the first publicly documented case of an AI agent running a large-scale intrusion with minimal human direction. It validates our core warning: agentic AI dramatically lowers the barrier to sophisticated attacks and turns what was once weeks of human labor into minutes of autonomous execution. While this case targeted major companies and government entities, the same capabilities can, and likely will, be adapted for consumer-focused scams, identity theft, and social engineering campaigns.
Before we dive into the threats, let’s break down what we’re actually talking about when we discuss AI and its evolution:
Traditional AI: The Helper
The AI most people know today works like a very sophisticated search engine or writing assistant. You ask it a question, it gives you an answer. You request help with a task, it provides suggestions. Think of ChatGPT, Google’s Gemini, or the AI features on your smartphone. They’re reactive tools that respond to your input but don’t take independent action.
Generative AI: The Creator
Generative AI, which powers many current scams, can create content like emails, images, or even fake videos (deepfakes). This technology has already made scams more convincing by cloning real human voices and eliminating telltale signs like poor grammar and obvious language errors.
The impact is already visible in the data. McAfee Labs found that for just $5 and 10 minutes of setup time, scammers can create powerful, realistic-looking deepfake video and audio scams using readily available tools. What once required experts weeks to produce can now be achieved for less than the cost of a latte—and in less time than it takes to drink it.
Agentic AI: The Independent Actor
Agentic AI represents a fundamental leap forward. These systems can think, make decisions, learn from mistakes, and work together to solve tough problems, just like a team of human experts. Unlike previous AI that waits for your commands, agentic AI can set its own goals, make plans to achieve them, and adapt when circumstances change
Key Characteristics of Agentic AI:
Gartner predicts that by 2028, a third of our interactions with AI will shift from simply typing commands to fully engaging with autonomous agents that can act on their own goals and intentions. Unfortunately, cybercriminals won’t be far behind in exploiting these capabilities.
Think of agentic AI as giving scammers their own team of tireless, intelligent apprentices that never sleep, never make mistakes, and get better at their job every day. Here’s how this digital apprenticeship makes scams exponentially more dangerous.
Traditional scammers spend hours manually researching targets, scrolling through social media profiles, and piecing together personal information. Agentic AI recon agents operate persistently and autonomously, self-prompting questions like “What data do I need to identify a weak point in this organization?” and then collecting it from social media, breach data, exposed APIs and cloud misconfigurations.
Unlike traditional phishing that uses static messages, agentic AI can dynamically update or alter their approach based on a recipient’s response, location, holidays, events, or the target’s interests, marking a significant shift from static attacks to highly adaptive and real-time social engineering threats.
An agentic AI scammer targeting you might start with a LinkedIn message about a job opportunity. If you don’t respond, it switches to an email about a package delivery. If that fails, it tries a text message about suspicious account activity. Each attempt uses lessons learned from your previous reactions, becoming more convincing with every interaction.
AI-generated phishing emails achieve a 54% click-through rate compared to just 12% for their human-crafted counterparts. With agentic AI, scammers can create messages that don’t just look professional, they sound exactly like the people and organizations you trust.
The technology is already sophisticated enough to fool even cautious consumers. As McAfee’s latest research shows, social media users shared over 500,000 deepfakes in 2023 alone. The tools have become so accessible that scammers can now create convincing real-time avatars for video calls, allowing them to impersonate anyone from your boss to your bank representative during live conversations.
Perhaps most concerning is agentic AI’s ability to learn and improve. As the AI interacts with more victims over time, it gathers data on what types of messages or approaches work best for certain demographics, adapting itself and refining future campaigns to make each subsequent attack more powerful, convincing, and effective. This means that every failed scam attempt makes the AI smarter for its next victim. Understanding how agentic AI will transform specific types of scams helps us prepare for what’s coming. Here are the most concerning developments:
Multi-Stage Campaign Orchestration
Agentic AI can potentially orchestrate complex multi-stage social engineering attacks, leveraging data from one interaction to drive the next one. Instead of simple one-and-done phishing emails, expect sophisticated campaigns that unfold over weeks or months.
Automated Spear Phishing at Scale
Traditional spear phishing required manual research and customization for each target. In the new world order, malicious AI agents will autonomously harvest data from social media profiles, craft phishing messages, and tailor them to individual targets without human intervention. This means cybercriminals can now launch thousands of highly personalized attacks simultaneously, each one crafted specifically for its intended victim.
Real-Time Adaptive Attacks
When a target hesitates or questions an initial approach, agents adjust their tactics immediately based on the response. This continuous refinement makes each interaction more convincing than the last, wearing down even skeptical targets through persistence and learning. Traditional red flags like “This seems suspicious” or “Let me verify this” no longer end the attack, they just trigger the AI to try a different approach.
Cross-Platform Coordination
These autonomous systems now independently launch coordinated phishing campaigns across multiple channels simultaneously, operating with an efficiency human attackers cannot match. An agentic AI scammer might contact you via email, text message, phone call, and social media—all as part of a coordinated campaign designed to overwhelm your defenses.
The rise of agentic AI scams requires a fundamental shift in how we think about cybersecurity. Traditional advice like “watch for poor grammar” no longer applies. Here’s what you need to know to protect yourself:
Since agentic AI eliminates traditional warning signs, focus on these behavioral red flags:
High-Priority Warning Signs:
Emotional urgency: Messages designed to make you panic, feel guilty, or act without thinking
Requests for unusual actions: Being asked to do something outside normal procedures
Isolation tactics: Instructions not to tell anyone else or to handle something “confidentially”
Multiple contact attempts: Being contacted through several channels about the same issue
Perfect personalization: Messages that seem to know too much about your specific situation
At McAfee, we understand that fighting AI-powered attacks requires AI-powered defenses. Our security solutions are designed to detect and stop sophisticated scams before they reach you. McAfee’s Scam Detector provides lightning-fast alerts, automatically spotting scams and blocking risky links even if you click them, with all-in-one protection that keeps you safer across text, email, and video. Our AI analyzes incoming messages using advanced pattern recognition that can identify AI-generated content, even when it’s grammatically perfect and highly personalized.
Scam Detector keeps you safer across text, email, and video, providing comprehensive coverage against multi-channel agentic AI campaigns. Beyond analyzing message content, our system evaluates sender behavior patterns, communication timing, and request characteristics that may indicate AI-generated scams. Just as agentic AI attacks learn and evolve, our detection systems continuously improve their ability to identify new threat patterns.
Protecting yourself from agentic AI scams requires combining smart technology with informed human judgment. Security experts believe it’s highly likely that bad actors have already begun weaponizing agentic AI, and the sooner organizations and individuals can build up defenses, train awareness, and invest in stronger security controls, the better they will be equipped to outpace AI-powered adversaries.
We’re entering an era of AI versus AI, where the speed and sophistication of both attacks and defenses will continue to escalate. According to IBM’s 2025 Threat Intelligence Index, threat actors are pursuing bigger, broader campaigns than in the past, partly due to adopting generative AI tools that help them carry out more attacks in less time.
While the threat landscape is evolving rapidly, the combination of human intelligence and AI-powered security tools gives us powerful advantages. Humans excel at recognizing context, understanding emotional manipulation, and making nuanced judgments that AI still struggles with. When combined with AI’s ability to process vast amounts of data and detect subtle patterns, this creates a formidable defense.
The rise of agentic AI represents both a significant threat and an opportunity. While cybercriminals will certainly exploit these technologies to create more sophisticated scams, we’re not defenseless. By understanding how these systems work, recognizing the new threat landscape, and combining human wisdom with AI-powered protection tools like McAfee‘s Scam Detector, we can stay ahead of the threats.
The key insight is that while AI can mimic human communication and behavior with unprecedented accuracy, it still relies on exploiting fundamental human psychology—our desire to help, our fear of consequences, and our tendency to trust. By developing better awareness of these psychological vulnerabilities and implementing verification protocols that don’t depend on technological red flags, we can maintain our security even as the threats become more sophisticated.
Remember: in the age of agentic AI, the most important security tool you have is still your human judgment. Trust your instincts, verify before you act, and never let urgency override prudence, no matter how convincing the request might seem.
The post How Agentic AI Will Be Weaponized for Social Engineering Attacks appeared first on McAfee Blog.
What. A. Week. It wasn't just the preceding weeks of technical pain as we tried to work out how to get this data loaded, it was all the subsequent queries we had to deal with too. Some of them are totally understandable, whilst others just resulted in endless facepalms 🤦♂️ But we got there in the end with the worst of it just being a 24-hour period where we ended up on a SpamCop block list, for reasons I still don't understand. We are still on the very tail end of sending individual notifications, so there may be more to update in the next vid, but at least that one will be from home with sunshine, good coffee and a slower pace 😊
I hate hyperbolic news headlines about data breaches, but for the "2 Billion Email Addresses" headline to be hyperbolic, it'd need to be exaggerated or overstated - and it isn't. It's rounded up from the more precise number of 1,957,476,021 unique email addresses, but other than that, it's exactly what it sounds like. Oh - and 1.3 billion unique passwords, 625 million of which we'd never seen before either. It's the most extensive corpus of data we've ever processed, by a significant margin.
Edit: Just to be crystal clear about the origin of the data and the role of Synthient (who you’ll read about in the next paragraph): this data came from numerous locations where cybercriminals had published it. Synthient (run by Ben during his final year of college) indexed that data and provided it to Have I Been Pwned solely for the purpose of notifying victims. He’s the good guy shining a light on the bad guys, so keep that in mind as you read on. (Some of the feedback Ben has received is exactly what I foreshadowed in the final paragraph of this post.)
A couple of weeks ago, I wrote about the 183M unique email addresses that Synthient had indexed in their threat intelligence platform and then shared with us. I explained that this was only part of the corpus of data they'd indexed, and that it didn't include the credential stuffing records. Stealer log data is obtained by malware running on infected machines. In contrast, credential stuffing lists usually originate from other data breaches where email addresses and passwords are exposed. They're then bundled up, sold, redistributed, and ultimately used to log in to victims' accounts. Not just the accounts they were initially breached from, either, because people reuse the same password over and over again, the data from one breach is frequently usable on completely unrelated sites. A breach of a forum to comment on cats often exposes data that can then be used to log in to the victim's shopping, social media and even email accounts. In that regard, credential stuffing data becomes "the keys to the castle".
Let me run through how we verified the data, what you can do about it and for the tech folks, some of the hoops we had to jump through to make processing this volume of data possible.
The first person whose data I verified was easy - me 😔 An old email address I've had since the 90s has been in credential stuffing lists before, so it wasn't too much of a surprise. Furthermore, I found a password associated with my address, which I'd definitely used many eons ago, and it was about as terrible as you'd expect from that era. However, none of the other passwords associated with my address were familiar. They certainly looked like passwords that other people might have feasibly used, but I'm pretty sure they weren't mine. One was even just an IP address from Perth on the other side of the country, which is both infeasible as a password I would have used, yet eerily close to home. I mean, of all the places in the world an IP address could have appeared from, it had to be somewhere in my own country I've been many times before...
Moving on to HIBP subscribers, I reached out to a handful and asked for support verifying the data. I chose a mix of subscribers with many who'd never been involved in any data breach we'd ever seen before; my experience above suggested that there's recycled data in there, and we had previously verified that when investigating those other incidents. However, is the all-new stuff legitimate? The very first response I received was exactly what I was looking for:
#1 is an old password that I don't use anymore. #2 is a more recent password. Thanks for the heads up, I've gone and changed the password for every critical account that used either one.
Perfectly illustrating most people's behaviour with passwords, #2 referred to above was just #1 with two exclamation marks at the end!! (Incidentally, these were simple six and eight-character passwords, and neither of them was in Pwned Passwords either.) He had three passwords in total, which also means one of them, like with my data, was not familiar. However, the most important thing here is that this example perfectly illustrates why we put the effort into processing data like this: #2 was a real, live password that this guy was actively using, and it was sitting right next to his email address, being passed around among criminals. However, through this effort, that credential pair has now become useless, which is precisely what we're aiming for with this exercise, just a couple of billion times over.
The second respondent only had one password against their address:
Yes that was a password I used for many years for what I would call throw away or unimportant accounts between 20 and 10 years ago
That was also only eight characters, but this time, we'd seen it in Pwned Passwords many times before. And the observation about the password's age was consistent with my own records, so there's definitely some pretty old data in there.
The following response was not at all surprising:
I am familiar with that password... I used it almost 10 years ago... and cannot recall the last time I used it.
That was on a corporate account, too, and the owner of the address duly forwarded my email to the cybersecurity team for further investigation. The single password associated with this lady's email address had a massive nine characters, and also hadn't previously appeared in Pwned Passwords.
Next up was a respondent who replied inline to my questions, so I'll list them below with the corresponding answers:
Is this familiar? Yes
Have you ever used it in the past? Yes and is still on some accounts I do not use any longer.
And if so, how long ago? Unfortunately, it is still on some active accounts that I have just made a list of to change or close immediately.
This individual's eight-character password with uppercase, lowercase, numbers and a "special" character also wasn't in Pwned Passwords. Similarly, as with the earlier response, that password was still in active use, posing a real risk to the owner. It would pass most password complexity criteria and slip through any service using Pwned Passwords to block bad ones, so again, this highlights why it was so important for us to process the data.
The next person had three different passwords against rows with their email address, and they came back with a now common response:
Yes, these are familiar, last used 10 years ago
We'd actually seen all three of them in Pwned Passwords before, many times each. Another respondent with precisely the kind of gamer-like passwords you'd expect a kid to use (one of which we hadn't seen before), also confirmed (I think?) their use:
maybe when i was a kid lol
Responses that weren't an emphatic "yes, that's my data" were scarce. The two passwords against one person's name were both in Pwned Passwords (albeit only once each), yet it's entirely possible that neither of them had been used by this specific individual before. It's also possible they'd forgotten a password they'd used more than a decade ago, or it may have even been automatically assigned to them by the service that was subsequently breached. Put it down as a statistical anomaly, but I thought it was worth mentioning to highlight that being in this data set isn't a guarantee of a genuine password of yours being exposed. If your email address is found in this corpus then that's real, of course, so there must be some truth in the data, but it's a reminder that when data is aggregated from so many different sources over such a long period of time, there's going to be some inconsistencies.
As a brief recap, we load passwords into the service we call Pwned Passwords. When we do so, there is absolutely no association between the password and the email address it appeared next to. This is for both your protection and ours; can you imagine if HIBP was pwned? It's not beyond the realm of possibility, and the impact of exposing billions of credential pairs that can immediately unlock an untold number of accounts would be catastrophic. It's highly risky, and completely unnecessary when you can search for standalone passwords anyway without creating the risk of it being linked back to someone.
Think about it: if you have a password of "Fido123!" and you find it's been previously exposed (which it has), it doesn't matter if it was exposed against your email address or someone else's; it's still a bad password because it's named after your dog followed by a very predictable pattern. If you have a genuinely strong password and it's in Pwned Passwords, then you can walk away with some confidence that it really was yours. Either way, you shouldn't ever use that password again anywhere, and Pwned Passwords has done its job.
Checking the service is easy, anonymous and depending on your level of technical comfort, can be done in several different ways. Here's a copy and paste from the last Synthient blog post:
My vested interest in 1Password aside, Watchtower is the easiest, fastest way to understand your potential exposure in this incident. And in case you're wondering why I have so many vulnerable and reused passwords, it's a combination of the test accounts I've saved over the years and the 4-digit PINs some services force you to use. Would you believe that every single 4-digit number ever has been pwned?! (If you're interested, the ABC has a fantastic infographic using a heatmap based on HIBP data that shows some very predictable patterns for 4-digit PINs.)
It pains me to say it, but I have to, given the way the stealer logs made ridiculous, completely false headlines a couple of weeks ago:
This story has suddenly gained *way* more traction in recent hours, and something I thought was obvious needs clarifying: this *is not* a Gmail leak, it simply has the credentials of victims infected with malware, and Gmail is the dominant email provider: https://t.co/S75hF4T1es
— Troy Hunt (@troyhunt) October 27, 2025
There are 32 million different email domains in this latest corpus, of which gmail.com is one. It is, of course, the largest and has 394 million unique email addresses on it. In other words, 80% of the data in this corpus has absolutely nothing to do with Gmail, and the 20% of Gmail addresses have absolutely nothing to do with any sort of security vulnerability on Google's behalf. There - now let reporting sanity prevail!
I wanted to add this just to highlight how painful it has been to deal with this data. This corpus is nearly 3 times the size of the previous largest breach we'd loaded, and HIBP is many times larger than it was in 2019 when we loaded the Collection #1 data. Taking 2 billion records and adding the ones we hadn't already seen in the existing 15 billion corpus, whilst not adversely impacting the live system serving millions of visitors a day, was very non-trivial. Managing the nuances of SQL Server indexes such that we could optimise both inserts and queries is not my idea of fun, and it's been a pretty hard couple of weeks if I'm honest. It's also been a very expensive period as we turned the cloud up to 11 (we run on Azure SQL Hyperscale, which we maxed out at 80 cores for almost two weeks).
A simple example of the challenge is that after loading all the email addresses up into a staging table, we needed to create SHA1 hashes of each. Normally, that would involve something to the effect of "update table set column = sha1(email)" and you're done. That crashed completely, so we ended up doing "insert into new table select email, sha1(email)". But on other occasions the breach load required us to do updates on other columns (with no hash creation), which, on mulitple occasions, we had to kill after a day or more of execution with no end in sight. So, we ended up batching in loops (usually 1M records at a time), reporting on progress along the way so we had some idea of when it would actually finish. It was a painful process of trial, waiting ages, error then taking a completely different approach.
Notifying our subscribers is another problem. We have 5.9 million of them, and 2.9 million are in this data 🫨 Simply sending that many emails at once is hard. It's not so much hard in terms of firing them off, rather it's hard in terms of not ending up on a reputation naughty list or having mail throttled by the receiving server. That's happened many times in the past when loading large, albeit much smaller corpuses; Gmail, for example, suddenly sees a massive spike and slows down the delivery to inboxes. Not such a biggy for sending breach notices, but a major problem for people trying to sign into their dashboard who can no longer receive the email with the "magic" link.
What we've done to address that for this incident is to slow down the delivery of emails for the individual breach notification. Whilst I'd originally intended to send the emails at a constant rate over the period of a week, someone listening to me on my Friday live stream had a much better suggestion:
the strategy I've found to best work with large email delivery is to look at the average number of emails you've sent over the last 30 days each time you want to ramp up, and then increase that volume by around 50% per day until you've worked your way through the queue
Which makes a lot of sense, and stacked up as I did more research (thanks Joe!). So, here's what our planned delivery schedule now looks like:
That's broken down by hour, increasing in volume by 1.015 times per hour, such that the emails are spread out in a similar, gradually increasing cadence. On a daily basis, that works out at a 45% increase in each 24-hour period, within Joe's suggested 50% threshold. Plus, we obviously have all the other mechanisms such as a dedicated IP, properly configured DKIM, DMARC and SPF, only emailing double-opted-in subscribers and spam-friendly message body construction. So, it could be days before you receive a notification, or just run a haveibeenpwned.com search on demand if you're impatient.
We've sent all the domain notification emails instantly because, by definition, they're going to a very wide range of different mail servers; it's just the individual ones we're drop-feeding.
Lastly, if you've integrated Pwned Passwords into your service, you'll now see noticeably larger response sizes. The numbers I mentioned in the opening paragraph increase the size of each hash range by an average of about 50%, which will push responses from about 26kb to 40kb. That's when brotli compressed, so obviously, make sure you're making requests that make the most of the compression.
This data is now searchable in HIBP as the Synthient Credential Stuffing Threat Data. It's an entirely separate corpus from that previous Synthient data I mentioned earlier; they're discrete datasets with some crossover, but obviously, this one is significantly larger. And, of course, all the passwords are now searchable per the Pwned Passwords guidance above.
If I could close with one request: this was an extremely laborious, time-consuming and expensive exercise for us to complete. We've done our best to verify the integrity of the data and make it searchable in a practical way while remaining as privacy-centric as possible. Sending as many notifications as we have will inevitably lead to a barrage of responses from people wanting access to complete rows of data, grilling us on precisely where it was obtained from or, believe it or not, outright abusing us. Not doing those things would be awesome, and I suggest instead putting the energy into getting a password manager, making passwords strong and unique (or even better, using passkeys where available), and turning on multi-factor auth. That would be an awesome outcome for all 😊
Edit: I've closed off comments on this blog post. As you'll see below, there was a constant stream of questions that have already been answered in the post itself, plus some comments that were starting to verge on precisely what I predicted in the last para above. Reading, responding and engaging is time-consuming and at this point, all the answers are already here both above and below this edit in the comments.
This is the fifth in a multi-part series on cryptography and the Domain Name System (DNS).
In my last article, I described efforts underway to standardize new cryptographic algorithms that are designed to be less vulnerable to potential future advances in quantum computing. I also reviewed operational challenges to be considered when adding new algorithms to the DNS Security Extensions (DNSSEC).
In this post, I’ll look at hash-based signatures, a family of post-quantum algorithms that could be a good match for DNSSEC from the perspective of infrastructure stability.
I’ll also describe Verisign Labs research into a new concept called synthesized zone signing keys that could mitigate the impact of the large signature size for hash-based signatures, while still maintaining this family’s protections against quantum computing.
(Caveat: The concepts reviewed in this post are part of Verisign’s long-term research program and do not necessarily represent Verisign’s plans or positions on new products or services. Concepts developed in our research program may be subject to U.S. and/or international patents and/or patent applications.)
The DNS community’s root key signing key (KSK) rollover illustrates how complicated a change to DNSSEC infrastructure can be. Although successfully accomplished, this change was delayed by ICANN to ensure that enough resolvers had the public key required to validate signatures generated with the new root KSK private key.
Now imagine the complications if the DNS community also had to ensure that enough resolvers not only had a new key but also had a brand-new algorithm.
Imagine further what might happen if a weakness in this new algorithm were to be found after it was deployed. While there are procedures for emergency key rollovers, emergency algorithm rollovers would be more complicated, and perhaps controversial as well if a clear successor algorithm were not available.
I’m not suggesting that any of the post-quantum algorithms that might be standardized by NIST will be found to have a weakness. But confidence in cryptographic algorithms can be gained and lost over many years, sometimes decades.
From the perspective of infrastructure stability, therefore, it may make sense for DNSSEC to have a backup post-quantum algorithm built in from the start — one for which cryptographers already have significant confidence and experience. This algorithm might not be as efficient as other candidates, but there is less of a chance that it would ever need to be changed. This means that the more efficient candidates could be deployed in DNSSEC with the confidence that they have a stable fallback. It’s also important to keep in mind that the prospect of quantum computing is not the only reason system developers need to be considering new algorithms from time to time. As public-key cryptography pioneer Martin Hellman wisely cautioned, new classical (non-quantum) attacks could also emerge, whether or not a quantum computer is realized.
The 1970s were a foundational time for public-key cryptography, producing not only the RSA algorithm and the Diffie-Hellman algorithm (which also provided the basic model for elliptic curve cryptography), but also hash-based signatures, invented in 1979 by another public-key cryptography founder, Ralph Merkle.
Hash-based signatures are interesting because their security depends only on the security of an underlying hash function.
It turns out that hash functions, as a concept, hold up very well against quantum computing advances — much better than currently established public-key algorithms do.
This means that Merkle’s hash-based signatures, now more than 40 years old, can rightly be considered the oldest post-quantum digital signature algorithm.
If it turns out that an individual hash function doesn’t hold up — whether against a quantum computer or a classical computer — then the hash function itself can be replaced, as cryptographers have been doing for years. That will likely be easier than changing to an entirely different post-quantum algorithm, especially one that involves very different concepts.
The conceptual stability of hash-based signatures is a reason that interoperable specifications are already being developed for variants of Merkle’s original algorithm. Two approaches are described in RFC 8391, “XMSS: eXtended Merkle Signature Scheme” and RFC 8554, “Leighton-Micali Hash-Based Signatures.” Another approach, SPHINCS+, is an alternate in NIST’s post-quantum project.
Hash-based signatures can potentially be applied to any part of the DNSSEC trust chain. For example, in Figure 1, the DNS record sets can be signed with a zone signing key (ZSK) that employs a hash-based signature algorithm.
The main challenge with hash-based signatures is that the signature size is large, on the order of tens or even hundreds of thousands of bits. This is perhaps why they haven’t seen significant adoption in security protocols over the past four decades.
Verisign Labs has been exploring how to mitigate the size impact of hash-based signatures on DNSSEC, while still basing security on hash functions only in the interest of stable post-quantum protections.
One of the ideas we’ve come up with uses another of Merkle’s foundational contributions: Merkle trees.
Merkle trees authenticate multiple records by hashing them together in a tree structure. The records are the “leaves” of the tree. Pairs of leaves are hashed together to form a branch, then pairs of branches are hashed together to form a larger branch, and so on. The hash of the largest branches is the tree’s “root.” (This is a data-structure root, unrelated to the DNS root.)
Each individual leaf of a Merkle tree can be authenticated by retracing the “path” from the leaf to the root. The path consists of the hashes of each of the adjacent branches encountered along the way.
Authentication paths can be much shorter than typical hash-based signatures. For instance, with a tree depth of 20 and a 256-bit hash value, the authentication path for a leaf would only be 5,120 bits long, yet a single tree could authenticate more than a million leaves.
Returning to the example above, suppose that instead of signing each DNS record set with a hash-based signature, each record set were considered a leaf of a Merkle tree. Suppose further that the root of this tree were to be published as the ZSK public key (see Figure 2). The authentication path to the leaf could then serve as the record set’s signature.
The validation logic at a resolver would be the same as in ordinary DNSSEC:
The only difference on the resolver’s side would be that signature validation would involve retracing the authentication path to the ZSK public key, rather than a conventional signature validation operation.
The ZSK public key produced by the Merkle tree approach would be a “synthesized” public key, in that it is obtained from the records being signed. This is noteworthy from a cryptographer’s perspective, because the public key wouldn’t have a corresponding private key, yet the DNS records would still, in effect, be “signed by the ZSK!”
In this type of DNSSEC implementation, the Merkle tree approach only applies to the ZSK level. Hash-based signatures would still be applied at the KSK level, although their overhead would now be “amortized” across all records in the zone.
In addition, each new ZSK would need to be signed “on demand,” rather than in advance, as in current operational practice.
This leads to tradeoffs, such as how many changes to accumulate before constructing and publishing a new tree. Fewer changes and the tree will be available sooner. More changes and the tree will be larger, so the per-record overhead of the signatures at the KSK level will be lower.
My last few posts have discussed cryptographic techniques that could potentially be applied to the DNS in the long term — or that might not even be applied at all. In my next post, I’ll return to more conventional subjects, and explain how Verisign sees cryptography fitting into the DNS today, as well as some important non-cryptographic techniques that are part of our vision for a secure, stable and resilient DNS.
Read the complete six blog series:
The post Securing the DNS in a Post-Quantum World: Hash-Based Signatures and Synthesized Zone Signing Keys appeared first on Verisign Blog.
Login