Benchmarking Post-Quantum Key Encapsulation in S3-Compatible Object Storage under Client Concurrency

arXiv:2610.21457 · cs.CR, cs.DC · Submitted 2026-10-15 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: Today's paper: "Benchmarking Post-Quantum Key Encapsulation in S3-Compatible Object Storage under Client Concurrency".

Elias: The gist The per-object ML-KEM-768 costs 0.045–0.047 ms on x86 and 0.058–0.063 ms on ARM in this stack: less than X25519 on PUT, comparable on GET,

Nadia: First, who's behind it and why it matters.

Title and authors: Elias: So, let's talk about what the authors suggest we can actually do with these findings in terms of practical application or future work for this study.

Nadia: They pointed toward improving the performance of client-side encryption stacks by focusing on the specific performance deficits they found within the Python client implementation <ref:2610.21457#pg2>.

Priya: What kind of improvements are they suggesting there? Is it just about writing better code for those bindings?

Elias: They suggested that developers should look at how their code handles the foreign calls during key establishment and try to minimize them <ref:2610.21457#pg2>.

Nadia: They found that a compiled client showed no performance deficit because it only uses one call per operation, which is a significant win there <ref:2610.21457#pg2>.

Priya: That means if you're building an application, optimizing the client side to reduce those external function calls could really lessen the slowdowns when things get tight <ref:2610.21457#pg2>.

Elias: And for storage cost optimization, they suggested that you should dynamically select the most efficient KEM mode based on what you expect the object size to be <ref:2610.21457#pg3>.

Nadia: So if you know your objects are small, maybe Xtwenty-five thousand five hundred nineteen is better because of the smaller manifest size compared to ML-KEM <ref:2610.21457#pg3>.

Priya: That’s a way to manage that storage overhead dynamically; choosing a lighter KEM when you don't need the extra security margin for very large objects <ref:2610.21457#pg3>.

Elias: And for migration planning, they suggested using the CPU accounting data to predict throughput changes under saturation, which we discussed earlier in this paper <ref:2610.21457#pg3>.

Nadia: So if your system is running near capacity, you can use that data to get a quantitative prediction of how much slower things will run <ref:2610.21457#pg3>.

Priya: It seems like they are trying to give operators tools to manage the trade-off between security and performance based on real-time utilization <ref:2610.21457#pg3>.

The paper's summary: Nadia: So, wrapping up the discussion on "Benchmarking Post-Quantum Key Encapsulation in S3-Compatible Object Storage under Client Concurrency," the main message is that ML-KEM isn't a guaranteed performance hit under normal conditions.

Elias: It only hurts when the client CPU is fully saturated, and it adds storage cost regardless of which post-quantum method you choose for key establishment <ref:2610.21457#pg2>.

Nadia: And they provided some specific advice on how to tune client libraries or use the CPU accounting data to predict performance under load <ref:2610.21457#pg3>.

Priya: For me, the most important thing is that we have a clear procedure now: check your client CPU usage against these metrics before making any big switch to post-quantum crypto in production environments <ref:2610.21457#pg3>.

Elias: We need to remember that these results are specific because they only test one single-node store and one cloud provider setup, so you can't just take those numbers and apply them everywhere without new measurements <ref:2610.21457#pg3>.

Nadia: That’s right, the paper is a benchmarking study on "Benchmarking Post-Quantum Key Encapsulation in S3-Compatible Object Storage under Client Concurrency," and it gives us concrete data on performance under specific test conditions <ref:2610.21457#pg1>.

Priya: Overall, it shows that for now, storage overhead is the most consistent cost across these different modes <ref:2610.21457#pg3>.

Elias: And the performance impact depends entirely on client saturation levels and which implementation you are running <ref:2610.21457#pg2>.

The paper's improvements: Nadia: So we’ve looked at the "Benchmarking Post-Quantum Key Encapsulation in S3-Compatible Object Storage under Client Concurrency" paper, and what we see is that ML-KEM isn't inherently slower unless your client CPU is completely maxed out.

Elias: Exactly. The core finding is that for most of the time, classical key exchange methods are fine even when you’re running a lot of concurrent workers <ref:2610.21457#pg2>.

Conclusion: Nadia: So, we’ve looked at the "Benchmarking Post-Quantum Key Encapsulation in S3-Compatible Object Storage under Client Concurrency" paper, and what we see is that ML-KEM isn't inherently slower unless your client CPU is completely maxed out.

Priya: But we have to keep an eye on that storage cost they found, because every implementation pays more in bytes per object than Xtwo thousand five hundred nineteen <ref:2610.21457#pg3>.

Nadia: And we need to keep an eye on those specific implementation details when moving from these single-node tests to wider deployments <ref:2610.21457#pg3>.

Elias: Exactly. Next up, we’re taking a quick look at the VOW paper about verifiable and oblivious watermark detection for large language models.

Priya: That's it for today on this one, folks <ref:VOW.

Revanth Reddy Lingala, K. Gangadhara Rao, Padigela Srujan, Saarthak Manocha, Vainavi Venkat

Chaitanya Bharathi Institute of Technology

cs.CR, cs.DC

Submitted: 2026-10-15

Updated: 2026-10-15

Comments: 21 pages, 4 figures, 23 tables. Code and per-run data: https://github.com/revanthreddy0906/pqc-object-store

Code: https://github.com/revanthreddy0906/pqc-object-store

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 86/100

The gist: The gist The per-object ML-KEM-768 costs 0.045–0.047 ms on x86 and 0.058–0.063 ms on ARM in this stack: less than X25519 on PUT, comparable on GET, and far less than RSA-4096 decryption.

Key concepts

ML-KEM: This is a post-quantum key encapsulation mechanism used for secure communication. It involves a key exchange step and produces a larger ciphertext than classical algorithms, which increases storage requirements for encrypted data.
Client Concurrency: The research tested how the system performs when many clients access the storage simultaneously. This helps determine if adding post-quantum encryption slows down the entire system under heavy load.
Storage Overhead: This refers to the extra space needed to store encrypted data. The paper found that ML-KEM results in 1,056 more bytes per object compared to using classical key exchange methods.
Session Amortization: This concept explores how long a single security session can protect multiple objects before needing renewal. The study found that amortization only helps reduce CPU cost if the client's processor is the bottleneck.

Terminology

Benchmarking — 1× in this paper · explained in 4 episodes

Summary

The gist The per-object ML-KEM-768 costs 0.045–0.047 ms on x86 and 0.058–0.063 ms on ARM in this stack: less than X25519 on PUT, comparable on GET, and far less than RSA-4096 decryption.

How it works

The paper addresses the cost of post-quantum key encapsulation mechanisms (KEMs) like ML-KEM when used for client-side encryption in S3-compatible object storage under concurrent client workloads. It measures per-object ML-KEM against classical key exchange on an S3 interface, involving two client implementations, two processor types, and up to 500 concurrent workers. The study investigates whether ML-KEM slows the system under concurrency and why.

The cost analysis reveals that ML-KEM reduced throughput only when the client’s processor was at or near full load, with one unexplained exception in the native reader. The lasting cost identified is storage: 1,056 more bytes per object than with classical key exchange.

Key Establishment Modes and Costs

The study compares several key establishment modes for object encryption, including B0 (none), B1 (pre-shared key), R1 (RSA-OAEP-4096), B2 (X25519 ECDLP), P1 (ML-KEM-768 MLWE 1,088 bytes ciphertext and 32-byte shared secret), P2 (X25519+ML-KEM-768 concatenation hybrid), and P3 (X-Wing as specified in [17]). The sizes of the manifests carried by these modes vary, ranging from 622 to 2,085 bytes, which impacts parsing and hashing overhead.

Performance Findings Under Concurrency

The performance results show that throughput ceilings are reached across all modes. For small PUTs, the ceiling is attributed by profiling the server directly to contention in MinIO’s and the file system’s metadata path rather than disk limits. The client CPU accounting identity is used to localize throughput differences, showing that if a deficit occurs, it is due to client CPU saturation.

Client-Specific Deficits and Artifacts

The paper identifies specific causes for performance variations in the Python client. The deficit in the saturated cell is produced by the library binding which makes four foreign calls per decapsulation, accounting for 17% of the loss. Furthermore, the larger manifest accounts for 17 % of it in this deficit. The cost that every implementation pays is storage, specifically a larger ciphertext with every object.

Session Amortization and Trade-offs

The study explores bounded session amortization, where a session root protects at most Bmax objects and lives at most Tmax seconds. In the one-worker scenario, N1 saves 30–66 µs of CPU per request and raises throughput only for small GETs at 32–128 workers. The paper concludes that amortization is enabled only when profiling shows the client CPU to be the bottleneck, and a bound of Bmax = 10 already removes most of the CPU cost.

Storage Overhead

The lasting cost is storage, as an ML-KEM manifest is 2,034 bytes, 1,412 more than X25519 in encoding. This difference is dominant for kilobyte-sized objects and larger than the payload itself at 1 KiB. The study concludes that the cost that every implementation pays is storage.

Conclusion for Migration Planning

For migration planning, the CPU accounting of Section IV-C provides a procedure: measure client CPU per request for the current and the candidate mode on the real workload and client. If clients are well below CPU saturation, our data gives no reason to expect a change in throughput, with the reservation of anomaly A2. If they are saturated, expect throughput to change by about the inverse ratio of the two CPU figures. A measurement on one client stack does not transfer to another. The size of the cost depends on the client implementation.

The results describe two clients, one single-node store and one cloud provider, and the native reader covers the GET path only. They should not be extended to distributed object stores, other S3 implementations, other libraries or wide-area deployments without new measurements. The paper's claims are limited accordingly.

The results describe two clients, one single-node store and one cloud provider, and the native reader covers the GET path only<ref:2610.

Improvements for AI systems

Overall throughput prediction based on client load: If clients are well below CPU saturation, our data gives no reason to expect a change in throughput, with the reservation of anomaly A2. This allows AI systems deployed in resource-constrained environments to predict performance stability based on real-time client utilization, avoiding unnecessary reconfigurations or scaling when the system is not bottlenecked by the CPU.
Binding artifact identification for client software: The deficit in the saturated cell needs an explanation, because on GET ML-KEM’s decapsulation is cheaper than X25519’s exchange (Table VIII). AI systems can automatically diagnose performance degradation in client-side encryption stacks by comparing observed throughput ratios against known cryptographic primitives and binding artifacts, pinpointing whether the loss is due to the larger manifest or a binding that makes four foreign calls per decapsulation.
Storage cost optimization based on object size: The paper shows that the storage cost of ML-KEM is 1,056 bytes more than an X25519 public key, or 1,412 more in a JSON/base64 manifest, which is relevant for kilobyte-sized ones. AI systems can dynamically select the most efficient KEM mode (ML-KEM vs. X25519) based on the expected object size to minimize storage overhead, ensuring that data at rest remains cost-effective across varied object types.
Client implementation performance tuning: For developers, the paper suggests a compiled client shows none of the binding deficit because it uses one call per operation. AI systems can analyze client code or generated bindings and suggest refactoring strategies to minimize foreign calls during key establishment, effectively mitigating the performance penalties observed in Python libraries.
Saturation-aware migration planning: If they are saturated, expect throughput to change by about the inverse ratio of the two CPU figures: 4.0–4.9 % in our Python client. This provides a quantitative procedure for migration planning where AI systems can monitor client CPU per request and automatically predict throughput changes under saturation, guiding operators on when performance degradation will occur and by how much.