Post-quantum encryption slightly slows cloud storage with many users
Benchmarking Post-Quantum Key Encapsulation in S3-Compatible Object Storage under Client Concurrency
Cryptography and SecurityDistributed, Parallel, and Cluster Computing
Summary
Data stored today could be broken in the future if large quantum computers appear, so new types of encryption called post-quantum algorithms are needed to keep data safe. This study tested how one such algorithm, ML-KEM, affects the performance of cloud storage systems that save many encrypted files for many users at once. The researchers found that ML-KEM slows the system only a little, mainly when the client device is very busy, and some slowdown depends on software details. However, it always uses more space because it stores bigger encrypted keys.
What this means in practice
- •For cloud storage engineers: Optimize client-side encryption with ML-KEM algorithms considering processor load and client concurrency effects.
- •For security software developers: Design encryption libraries that minimize performance loss in object storage clients using post-quantum key encapsulation.
Authors
Revanth Reddy Lingala, K. Gangadhara Rao, Padigela Srujan, Saarthak Manocha, Vainavi Venkat
Abstract
Data encrypted today with classical public-key algorithms could be decrypted once large quantum computers exist. Cloud object stores keep data for years, so the client-side encryption that protects it must move to post-quantum algorithms such as ML-KEM, which adds a key-encapsulation step and a larger ciphertext to every stored object. So far, the cost of ML-KEM has been measured for the algorithm on its own and for securing network connections, but not for encrypting each object in a storage system that serves many clients at once. It has therefore been unclear whether ML-KEM slows such a system, under which conditions, and why. We address this problem by measuring per-object ML-KEM against classical key exchange on an S3-compatible object store, with two client implementations, two processor types and up to 500 concurrent workers, using pre-registered experiments and statistical equivalence tests. ML-KEM reduced throughput only when the client's processor was at or near full load, with one unexplained exception, and then by 4.0 to 4.9% in our main client. Controlled experiments on one processor type traced most of that loss to the way the software library was called, and a second, native client showed that the size of the loss depends on the implementation. The lasting cost is storage: 1,056 more bytes per object than with classical key exchange. The results cover two clients, one single-node store and one cloud provider.