Project
Quantum Cloud Guard
A software-only, three-layer architecture for small and medium-sized enterprises: client-side hybrid post-quantum encryption, self-hosted key custody with ML-DSA-87-signed keys, and an application-layer abuse gateway.
Problem
Ciphertext harvested from cloud storage today can be decrypted later by a sufficiently capable quantum computer. Small and medium-sized enterprises are least able to respond: they neither run the infrastructure their data sits on nor employ a cryptographer, and a managed key service relocates trust rather than removing it.
Architecture
- Client-side hybrid encryption. Files never leave the client in plaintext: each is sealed under AES-256-GCM and its key wrapped to an ML-KEM-1024 public key from the enterprise’s own key service.
- Self-hosted key custody. The enterprise alone administers the key service, which signs every served key with ML-DSA-87; a client that has pinned the service’s signing key detects substitution.
- Sentinel Gate. An in-process, application-layer abuse-prevention gateway.
Separating key custody from data custody is the point of the design: a provider holding both can read the data.
Results
On a 24 MHz STM32F407 microcontroller, ML-KEM-1024 key generation took 40.8 ms and decapsulation 44.0 ms. On the server every post-quantum operation stayed below a millisecond, signing adding 0.24 ms per request. The service ran on a 4.49 EUR/month virtual server.
Under sustained flooding, Sentinel Gate rejected 98.8% of attack traffic while a legitimate client's median latency moved from 621 to 625 ms.
These are the author's reported measurements (see the paper).
Limitations
The flooding test came from a single source, so it shows filtering effectiveness, not resilience to distributed denial of service.
Substitution of served keys is detected only by clients that have pinned the key service's signing key.