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

summary

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.

In short

The study benchmarked ML-KEM, a post-quantum key encapsulation mechanism, for client-side encryption in S3-compatible storage under high concurrency. Findings show ML-KEM incurs minimal CPU overhead unless the client processor is near full load. The primary lasting cost is storage: every object requires 1,056 more bytes due to larger ciphertexts compared to classical methods.

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 used across episodes

Reinforcement Learning (RL) — explained in 25 episodes
Sample Complexity — explained in 20 episodes
Retrieval-Augmented Generation (RAG) — explained in 19 episodes
Federated Learning — explained in 17 episodes
Flow Matching — explained in 17 episodes
Quantum Fisher Information (QFI) — explained in 16 episodes

This episode discusses

The paper

Benchmarking Post-Quantum Key Encapsulation in S3-Compatible Object Storage under Client Concurrency · Read on arXiv

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

Chaitanya Bharathi Institute of Technology

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.

More episodes

← Home