Coder Legion - Recent posts tagged postquantumcryptography

Oracle Plans Post-Quantum TLS for Java 8 and 11 in Late 2027, and Wants Testers Now

Tue, 27 Oct 2026 23:35:19 +0000

Security teams are starting to ask a question platform teams don't like: what's our plan for post-quantum encryption? For shops still running Java 8 or 11, the answer has mostly been a shrug.

At Oracle AI World in Las Vegas this week, I got a firmer one. I sat down with Georges Saab, senior vice president of Oracle's Java Platform Group; Donald Smith, vice president of product management for Java Platform; and Bernard Traversat, vice president of software development for the Java Platform Group. I asked about the schedule for hybrid post-quantum key exchange in TLS 1.3.

The feature is generally available in JDK 27. It arrived in JDK 25 with the October critical patch update. I laid out what comes next as I understood it: Java 21 and 17 in the first half of 2027, Java 11 and 8 in the second half. The team confirmed that was right.

Those are half-year windows, not release dates. And there is a condition attached.

Customers have been asking Oracle for post-quantum support as fast as possible. Now that it ships, the team wants them to use it. Many reply that they'd rather have it backported first. Oracle's answer is to test what already exists.

Smith said the key to stability is "just getting people using what we have, even though it's only in the latest."

There is a chicken-and-egg problem. The specification was only finalized in February, so many of the endpoints a Java client talks to don't support the hybrid exchange yet. Smith called the backport itself the hard part. For the next two to three months, the team is focused on stability so the backport starts from solid ground.

Feedback comes from two places. One is customers. The other is a group in OpenJDK that works with major third-party library projects, including Apache and Eclipse, and with the OpenSSL community.

Performance is the other worry. Java 8 shipped years before TLS 1.3 was final, and the team had to backport it. That taught them the backport has to be stable and fast on old hardware. A team tracks performance benchmarks on every release, including the new algorithms, he said. He gave no numbers.

If you run Java 8 or 11, waiting for the backport and then starting your testing is the slow path. Point a JDK 25 or 27 client at your post-quantum-capable endpoints, such as a gateway or proxy, and report what breaks. Oracle says it needs that feedback.

Backports aren't the only way out. Saab said he now regularly meets teams where most workloads are on Java 21.

He described the upgrade ladder this way. Going from 8 to 11 is the hardest step. Each step after that gets easier. "21 to 25 super easy," he said. The platform has been changed so that code survives upgrades better than it used to.

When teams do get stuck, the cause is usually outside the JDK. One is third-party libraries that nobody maintains. The other is the oldest problem: "when people used APIs that were not part of the public API," Saab said.

For finding those problems, Traversat pointed to Oracle's Java Management Service. It analyzes the APIs an application uses and reports deprecated APIs, changed behavior, and JVM argument changes between versions, such as 11 to 17 or 25. After that, he said, you still run the testing you use to certify the application.

I also asked how a team should verify code that an AI agent has refactored. Smith was direct: "I don't have a swift answer for that one." Saab said migration tooling is being built by other people. His team has helped groups inside Oracle migrate, to learn what the JDK could do better. Would the JDK team build migration tools itself? "I'm not saying we will never do that," he said.

So if you plan to use agents on a legacy Java codebase, the tools will come from outside the JDK. Verification still falls to your test suite.

The other date on your calendar is the patch schedule. Oracle announced in the spring that it is moving to monthly security updates across the company, not just for Java. Smith said the Java team will phase this in. "Next year we'll probably do 10 security updates and then it'll be every month thereafter," he said.

AI is part of the reason. "It's clear that AI has increased the rate at which you find vulnerabilities," Smith said. He added that it has also improved the team's ability to fix them.

He worried at first that system administrators would push back. They haven't. "The feedback is like nobody is surprised by this," he said. Some organizations will still have to adapt. A team on a quarterly change window is the obvious example.

Two items have no dates: non-hybrid key exchange and Merkle certificates. Smith said the work follows the IETF specifications and he wasn't sure enterprises could plan around it. His advice was to follow OpenJDK development. The issue trackers are open, and code already exists.

That caution is deliberate. "Never get ahead of the spec," Smith said. He pointed to the original java.util.Date as the example. An early implementation gained traction, it wasn't the best design, and the proper replacement took 10 to 15 years to arrive. Traversat added that anything shipped in the platform has to be supported for years, so Oracle moves conservatively.

For Java teams, the planning date is the second half of 2027 for Java 8 and 11. The work that decides whether that date holds starts now, and Oracle is asking for your help.

Atsign's Kill Switch for AI Agents Isn't Software. It's an Identity You Can Revoke.

Tue, 04 Aug 2026 13:00:00 +0000

Atsign's Kill Switch for AI Agents Isn't Software. It's an Identity You Can Revoke.

Most conversations about AI agent security start with permissions: what an agent is allowed to touch, and how to stop it if it goes wrong. Atsign, an AI infrastructure and agentic identity platform, starts somewhere else entirely — with the idea that the network itself shouldn't have anything worth attacking in the first place.

"We have open ports where there is nothing of value, and where there are things of value, the ports are closed," said Gary Casey, Atsign's principal software engineer, describing the company's core protocol. "That's why we say it's zero trust connectivity with no open ports."

Every entity on Atsign's platform — a person, a device, an agent, a service — gets its own cryptographic identity, called an Atsign, resolved through a lookup system Casey compared to DNS: query an Atsign, get back an encrypted address to talk to directly, peer to peer, with no central server ever holding the data or the keys that protect it. "We don't want to be in a position ever where we are looking after somebody's secrets," Casey said. "That's not our purpose."

Why this doubles as a kill switch

That architecture has a direct payoff for anyone running AI agents in production right now: identity, not code, becomes the mechanism for shutting one down. Atsign's permission model — internally called APKAM, for application-level public key authentication mechanism — lets a single Atsign hold thousands, even millions, of separately scoped identities underneath it, each with access to only a narrow slice of a namespace. Compromise or misbehavior in one doesn't cascade to the rest. "If you have 1,000 agents and they're all doing different things, you don't want the compromise of one to lead to damage to anything else," Casey said. Revoking a single agent's access is immediate, and doesn't touch any other agent's ability to keep working.

CEO Aparna Rayasam framed the implication directly: "We think that this should be the de facto solution for kill switches for AI." Her pitch to the industry is blunt about who should be paying attention. "We think that almost every LLM provider should partner with us, so that we can make this easier for their customers."

The model also supports agents that are designed to disappear on their own. Casey described spinning up an agent with access to a specific namespace for five minutes, after which access expires automatically — no lingering credential, no forgotten process quietly running up an LLM bill long after its job is done.

Identity answers who. Policy answers whether it makes sense.

Scoped identity only solves part of the problem, and Casey was clear-eyed about where the rest of it lives: in a separate policy layer that evaluates whether a given request should actually be allowed, chained across however many hops an agent-to-agent interaction spans. His example: one agent asking another to approve a $50,000 payment on a person's behalf. Before that happens, something has to check whether the request is legitimate, whether the human it claims to represent actually authorized it, and whether a cryptographic chain of identity can prove the request really originated where it says it did — even ten steps removed from the original ask. "It shouldn't be hard-coded into agents," Casey said. "It should live in a policy world."

Deliberately, none of this runs through a central hub. Policy decisions can be delegated at whatever granularity an organization wants — one policy service for a small team, another for a larger division — but Atsign's architecture doesn't assume, or require, one authority sitting in the middle. Casey drew a sharp distinction for what that buys an organization under attack: "You can disrupt, but you can't compromise." Someone can still sever a connection. What they can't do is decrypt what was flowing through it.

What it actually takes to adopt

For engineering teams sizing up the lift, Casey's answer was straightforward: "It's entirely — run it on top of what you've got. It doesn't require anything else. It's literally you just run the software." No network-level changes, no separate infrastructure to stand up first. The SDK — most mature in Dart, with enterprise-grade Java and Python engines explicitly optimized to meet developers building autonomous AI applications — handles key management, encryption and decryption, offline sync, and event notifications.

Key management itself has no central authority by design. "They all do it themselves," Casey said of key generation and rotation — cut and rotated at the edge, published to each identity's own server, with no centralized key store required and, in Casey's view, none recommended at scale. Compromise response follows the same logic: revoking an agent's access also triggers key rotation across anything that shared its namespace, giving Atsign what Casey called post-compromise security — the damage is contained going forward, even though nothing can undo what a compromised key already read.

Getting ahead of the quantum deadline without betting on any one algorithm

Atsign is currently transitioning its post-quantum cryptographic support from targeted enterprise preview to production-grade deployment targets. The engineering choice Casey described as the hardest part wasn't a specific algorithm — it was building a pluggable provider model into the SDK that keeps the protocol itself agnostic to whichever encryption scheme is running on top. "Our protocol, our atServers and all that stuff, is completely agnostic to any of this stuff," Casey said. "They're just shipping bytes around the place. The crypto agility and all of the encryption and decryption is a client-side concern." Atsign isn't implementing cryptographic algorithms itself — it's relying on established, well-scrutinized libraries and adopting NIST- and IETF-blessed standards as they're finalized, aiming to plug new ones in and retire old ones quickly rather than committing hard to any single implementation.

That flexibility matters for reasons beyond the quantum timeline alone. Casey pointed to recent research using AI models to probe for weaknesses in AES, the current gold standard for symmetric encryption, as a reminder that classical cryptography itself isn't static ground. "My level of terror changes from day to day," he said. "This crypto agility is incredibly important" — not just for the eventual post-quantum transition, but for whatever comes next after that.

The next phase beyond the current rollout is post-quantum group communication, using PQMLS to bring forward secrecy to multi-party conversations at scale — an extension of the peer-to-peer model the platform runs on today. The IETF has ratified MLS itself; the post-quantum version is still working its way through standardization.

Casey echoed a view that's increasingly common across this year's Black Hat pre-show conversations, agreeing with the prediction others have made that most large enterprises will have a dedicated cryptography lead within the next few years — not necessarily a research mathematician, but someone whose job is specifically understanding the cryptographic landscape well enough to make these calls. "I would never call myself a cryptographer," he said. "But I would say at this point I kind of understand the landscape."

PQC Migration: What an Enterprise Consultant and a Network Vendor Are Actually Seeing

Tue, 28 Jul 2026 11:28:10 +0000

Ask ten security leaders about post-quantum cryptography and you'll get ten versions of the same nervous shrug. The word "quantum" alone scares off half the room. But talk to the people actually running PQC migrations at scale, and a much more concrete picture shows up — one with a real deadline, a real budget conversation, and a real technical playbook.

Two conversations ahead of Black Hat USA 2026 gave a good look at that picture from two different angles: Tom Patterson, emerging tech cybersecurity lead at Accenture, who has spent a decade helping the world's largest organizations plan their migrations, and Anusha Vaidyanathan and Dhiraj Sehgal at Versa Networks, who are building PQC directly into the network fabric those organizations run on.

The deadline is real, and it's closer than "someday"

Patterson has been doing this long enough to have a 2017 White House workshop transcript to compare notes against. "It's pretty much on track or faster than we had expected," he said, pointing to the chip advances that landed late last year — Google's Willow chip followed a week later by a rival claiming 5x the speed. Quantum computers stopped being theoretical the day you could rent time on one in the cloud for $100 a minute.

NIST's deprecation notice made it official: 2030 is the date to start deprecating RSA and ECC. Patterson said Accenture's clients have broadly accepted 2030, plus or minus two years, as their finish line — not 100% complete, but with their most critical systems, continuity of operations, and crown-jewel data locked down against harvest-now-decrypt-later attacks.

Versa's Vaidyanathan sees the same urgency, but from the traffic itself. "Harvest now, decrypt later is a today's problem. It's a past problem," she said. "It's not a future problem." The data adversaries want to decrypt once quantum computers mature is already sitting on the wire, encrypted with algorithms that won't hold. That's driving fast movement from regulated and critical-infrastructure customers — oil, electricity, financial services — well ahead of the rest of the market.

Where the two views converge: it's a coordination problem, not a shopping problem

Patterson's biggest finding after ten years of this work isn't technical. "The cost of a post-quantum algorithm is exactly the same as the cost of a classical algorithm," he said. "It's just a matter of there's a transition program you've got to fund." Done right, it can be net-neutral over a ten-year lifecycle, because you end up using encryption more efficiently across the whole estate.

The real barrier is coordination — inside the organization and across it. Accenture's eight-step methodology, which the firm has published at Davos for years, walks clients through strategy, discovery, and ecosystem coordination before they touch architecture. "It's not just you that's making this change," Patterson said. "Thousands of your suppliers are also changing the way they're going to communicate with you." Most of Accenture's clients are still in the first half of that eight-step process.

Versa's Dhiraj Sehgal described a similar coordination gap playing out inside client organizations right now, just at the team level: the infrastructure group handling PQC plumbing and the team exploring agentic AI security aren't talking to each other yet. "That converges" eventually, he said, "but it's too early" today.

What "PQC-ready" actually means at the network layer

This is where Versa's side of the conversation gets useful for anyone building or buying network security today. PQC-ready doesn't mean ripping out existing crypto — it means hybrid key exchange, combining classical elliptic-curve Diffie-Hellman with the NIST-approved ML-KEM algorithm. "We don't want to just take and go completely PQC-native with just ML-KEM," Vaidyanathan said. "We want to crawl, walk, run." Data encryption itself stays on AES-GCM, which is already considered quantum-safe — the vulnerability is in how keys get negotiated, not in the encryption of the data itself.

Versa's architecture protects that key exchange across the data plane, control plane, and management plane alike — branch-to-hub traffic, but also the Versa Controller, Concerto/Director, and the analytics and messaging layers that manage the network. That last part matters: "A lot of people don't think about the management plane," Vaidyanathan said. "They only think about protecting the data."

Versa's PQC crypto engine sits in the data plane (SD-WAN hub or SASE gateway), the control plane (Versa Controller), and the management plane (Concerto/Director, Analytics, Messaging Service) alike — using hybrid ECDH + ML-KEM key exchange with AES-GCM data encryption.

For enterprises not ready for a full rollout, there's a lighter first step: quantum-resistant IPsec, using pre-shared post-quantum key negotiation, layered onto existing branch-to-hub tunnels. Vaidyanathan described a regulated, latency-sensitive customer — a trading environment — starting exactly there. "There's no migration involved," she said. "It's just one knob, and then the key negotiation happens automatically. There's no forklift involved."

The interoperability problem is real, but not everywhere

Patterson raised a pointed challenge for anyone evaluating vendors right now: put a reporter's skeptical eye on "PQC-ready" marketing claims. Accenture built a quantum test lab specifically to check whether products that claim readiness actually work together. "We just take all the products that say that they're PQC-ready and we plug them together," he said. "An HSM from here and a PKI from here, and they don't work. They don't communicate together. They each work individually."

Versa's answer is more nuanced than the blanket complaint suggests. Versa-to-Versa interoperability is solid by design. Client-to-server interoperability — a browser talking to Gmail or Salesforce — already works as long as both ends support the same hybrid standard. Where it genuinely doesn't exist yet is site-to-site interoperability between different vendors' PQC implementations — Versa talking to a Cisco PQC deployment, for instance. But per Vaidyanathan, that's less a broken promise than an unasked question so far: "People are not asking for that kind of interoperability yet."

The most common mistake, from both sides

Patterson's version: organizations underestimate how much of their environment actually depends on legacy encryption, and nobody owns the problem. "They didn't realize how big the encryption issue was," he said. Most clients don't have anyone in charge of encryption today; by 2030, Accenture expects most will have a VP-level owner and a dedicated cryptographic center of excellence.

Versa's version is more granular: teams focus on key management and forget data encryption, or they underestimate the hardware acceleration PQC algorithms need at scale — one reason Versa works directly with Intel and AMD on their acceleration roadmaps rather than assuming commodity hardware will keep up.

What to check in your own environment this week

Both sources converged on a practical starting list for network engineers and architects:

Map every data-in-transit deployment — who's talking to whom, and how it's architected
Confirm whether your management plane is protected, not just your data plane
Build a cryptographic bill of materials (a C-BOM) rather than trying to brute-force an inventory with spreadsheets
Check what algorithms your vendors actually support in transit, not just what their marketing claims
Watch for NIST's CNSA 2.0 suite and upcoming digital signature and code-signing standards — the data-in-transit algorithms are only the first wave

Where this is headed

Patterson expects the second half of this year to bring real movement on PKI standards specifically — "not a lot of go-buy-my-whiz-bang," as he put it, but genuine technical progress that should mostly land by 2027. And after years of quantum being a niche Black Hat topic — "maybe 100 people in the room" five or six years ago — both sources expect the subject to draw a crowd this year.

Agentic AI is the wild card on both sides of this conversation, but for different reasons. For Accenture, generative AI has compressed the timeline enterprises are working against — Patterson pointed to those decades-old, deeply buried certificates with 50-year lifespans that used to be safely forgotten. "Now, with generative AI, you can just expect that an adversary is going to be able to find some way in and get it." For Versa, agentic AI and PQC are still two separate workstreams inside most client organizations — related, but not yet convinced they need each other. Expect that to change.

2026 will force every CISO to confront decades of deferred maintenance, or risk catastrophic failur

Wed, 06 Aug 2025 00:06:23 +0000

The Quantum Wake-Up Call: Why CISOs Need to Fix Their Tech Debt Before 2026

The cybersecurity world is racing toward two simultaneous inflection points that will fundamentally reshape how organizations approach digital security. While everyone's attention remains fixated on AI implementation, a quantum cryptography crisis is quietly building momentum that could make the Y2K transition look like a minor inconvenience.

Chuck Herrin, Field CTO at F5, has spent the past year traveling 300,000 miles globally, witnessing firsthand how enterprises are struggling to balance immediate AI security demands with the looming post-quantum cryptography (PQC) transition. His observations, during Black Hat 2025, paint a sobering picture of organizational unpreparedness.

The Fundamentals Crisis

"Most companies can't tell you how many exposed API endpoints they have, plus or minus 5,000," Herrin explains. This visibility gap becomes exponentially more dangerous when IDC research shows that companies investing in generative AI expand their attack surface by roughly 5x. Yet organizations continue to skip the basics in favor of flashier AI initiatives.

The problem isn't just about AI applications; it's about treating them as entirely new entities, rather than what they actually are: distributed applications that require the same fundamental security controls we've always needed. API visibility, continuous discovery, authentication, authorization, and rate limiting remain as critical as ever, but they're getting lost in the AI hype cycle.

"A world of AI is a world of APIs," Herrin emphasizes. "You absolutely cannot secure your AI systems without securing the interfaces that serve them."

The Multi-Lens Approach to AI Security

Traditional security approaches are failing because they're over-indexed on single data sources, typically traffic logs. Herrin advocates for a multi-lens approach that combines traffic analysis with source code discovery, network segmentation visibility, and DNS monitoring. This comprehensive view becomes essential when dealing with AI applications that may process multiple modalities—text, images, audio—each representing a potential attack vector.

Before deploying AI applications externally, organizations need to answer fundamental questions: How many modalities does your model need to process? Can you use a narrower model to reduce attack surface? Do you understand what versions of interfaces you're exposing?

"If you can use a narrow model that doesn't expose multiple modalities, you have fewer avenues to monitor, manage, harden, test, and validate," Herrin notes.

The Quantum Time Bomb

While AI security demands immediate attention, the quantum threat operates on a different timeline that's equally urgent. F5's research reveals that 91.4% of the top one million websites don't support PQC, with adoption remaining devastatingly low across critical sectors: banking (2.9%), healthcare (8.5%), and government (7.1%).

The "harvest now, decrypt later" attacks are already happening. Nation-state actors are collecting encrypted data today, banking on future quantum computers to decrypt it. This means any data requiring long-term confidentiality—intellectual property, healthcare records, financial information—is already at risk.

"If you've got data that you need to keep safe and confidential for 50, 60, 70 years, you need to be on this now," Herrin warns. "The day that a cryptographically relevant quantum computer hits the scene, you must consider data that was previously encrypted as compromised."

The Banking Paradox

Despite heavy regulation, financial institutions are moving slowly on PQC implementation. The largest banks are actively working on it, they have tens of millions of interfaces to upgrade, but it's a multi-year project. Smaller institutions aren't even considering it yet.

"AI is sucking all the air out of the room," Herrin explains. "Nobody is coming to them saying 'save me a million dollars next year' with PQC. There's no big business use case driving adoption."

This creates a dangerous prioritization problem. Organizations are pouring resources into AI initiatives while ignoring the cryptographic foundation that protects all their data.

The Tech Debt Reckoning

The convergence of AI expansion and quantum threats will force a massive tech debt reckoning. Legacy IoT devices, SCADA systems, HSMs that can't support PQC key lengths, all will require urgent attention.

"Tech debt is going to come due with interest," Herrin predicts. "You're going to have to upgrade your old IoT devices, your legacy systems. It's going to drive a whole raft of unplanned projects."

Practical Steps Forward

For CISOs navigating these challenges, Herrin recommends starting with continuous discovery, improvement, testing, and validation; automating these fundamental processes before pursuing advanced capabilities.

"You can have complete cybersecurity mastery on the 10% of interfaces you're aware of, and you're going to get burned because of the 90% you don't know about," he explains. "You fundamentally can't skip the fundamentals."

The organizations that will thrive are those using AI to strengthen their security posture rather than just racing toward advanced use cases. F5 customers are already using AI to understand legacy configurations, explain complex rule sets, and gain visibility into inherited technical debt.

The message is clear: 2026 will separate organizations that invested in foundational security from those that chased shiny objects. The time for eating vegetables before dessert is now, before both quantum computers and AI-powered attacks make the choice for you.