PaperlayerView exact revision on arXiv

Source-linked AI summary

A Hybrid Post-Quantum Encryption Architecture with Self-Hosted Key Management for SME Cloud Data Protection

Muhammad Shaheer Bin Junaid

arXiv:2608.26777v1cs.CR

TL;DR

SMEs face harvest-now-decrypt-later exposure but lack the infrastructure, expertise, and budgets needed for bespoke migration, while managed key services preserve provider trust rather than enterprise custody. QCG addresses this architectural gap with a software-only, three-layer design combining client-side hybrid encryption, self-hosted signed key custody, and an application-layer gateway. The evaluation reports feasibility on constrained hardware and effective single-source flood filtering, while identifying availability, memory-hygiene, and broader-scale evaluation boundaries.

  • Problem

    SMEs are exposed to harvest-now-decrypt-later attacks but generally lack the infrastructure, cryptographic expertise, and migration budgets available to larger organisations.

  • Method

    QCG integrates client-side AES-256-GCM and ML-KEM-1024 encryption, self-hosted key custody with ML-DSA-87 signatures, and an abuse-prevention gateway.

  • Results

    The evaluation supports hardware independence, low end-to-end overhead, and filtering of almost all sustained single-source flood traffic without latency cost to legitimate users.

  • Takeaways & Limitations

    QCG’s contribution is a deployable SME architecture that keeps encryption and key custody under enterprise control while using standardised primitives.

Abstract

from arXiv · show

Harvesting ciphertext from cloud storage needs no quantum computer; decrypting it later does. That gap is the harvest-now-decrypt-later exposure: anything protected by RSA or ECDH today that must stay secret for decades is already compromised. Small and medium-sized enterprises are least able to respond: they neither run the infrastructure on which their data sits on nor employ a cryptographer. Bespoke migration suits firms with security budgets; a managed key service relocates trust rather than removing it. The obstacle is architectural, not cryptographic. We present Quantum Cloud Guard (QCG), a software-only three-layer architecture. No prior SME-oriented system combines its three elements: client-side hybrid post-quantum encryption, self-hosted key custody with client-verifiable ML-DSA-87 signatures on served keys, and an integrated application-layer abuse-prevention gateway. Files never leave the client: each is sealed under AES-256-GCM, its key wrapped to an ML-KEM-1024 public key from the enterprise's key service. The enterprise alone administers it; it signs every key with ML-DSA-87, so a client that pinned it detects substitution. Separating key custody from data custody is the point: a provider holding both can read the data. On a 24 MHz STM32F407, ML-KEM-1024 key generation takes 40.8 ms and decapsulation 44.0 ms; on the server every post-quantum operation stays sub-millisecond, signing adding 0.24 ms per request. The service runs on a 4.49 EUR/month virtual server. Under sustained flooding, the in-process gateway Sentinel Gate rejected 98.8% of attack traffic while a legitimate client's median latency moved from 621 to 625 ms. Being single-source, this shows filtering effectiveness, not DDoS resilience.

A. Shor’s Algorithm and Public-Key Cryptography

Shor’s algorithm breaks the public-key assumptions behind RSA, elliptic-curve, and Diffie-Hellman systems, while quantum search weakens symmetric keys rather than destroying them. This motivates migration toward post-quantum replacements and hybrid designs for cloud-dependent SMEs.

  • Shor’s algorithm solves integer factorisation and discrete logarithms in polynomial time, breaking RSA, elliptic-curve cryptography, and Diffie-Hellman together.
  • Quantum impact differs by primitive: public-key mechanisms break, while symmetric encryption generally requires longer keys or retains reduced strength.
  • Harvest-now-decrypt-later lets adversaries collect ciphertext today and decrypt it after quantum hardware becomes available.
  • SMEs face the exposure without the migration budgets, personnel, or vendor control available to larger organisations.
  • Existing hybrid and cloud encryption proposals address parts of the problem but target enterprise systems, retain vulnerable key exchange, or require specialised hardware.

D. Positioning of QCG

QCG is positioned as an SME-focused architecture that combines established cryptographic components with self-hosted custody and operational protection. Its design-science methodology builds and evaluates the artefact incrementally, incorporating revisions forced by implementation failures.

  • D. Positioning of QCG: QCG occupies the gap between hybrid endpoint protocols, cloud schemes with vulnerable exchanges or hardware requirements, and migration studies without an artefact.
  • D. Positioning of QCG: No prior SME-oriented system is identified as combining client-side hybrid encryption, self-hosted key custody, and an integrated abuse-prevention gateway.
  • D. Positioning of QCG: The paper claims the conjunction of these properties, rather than a new cryptographic primitive, as its contribution.
  • Methodology: Design Science Research treats construction decisions and implementation-driven revisions as part of the research result.
  • Methodology: Construction proceeded bottom-up from cryptographic core through storage, service, network, and feature layers.
  • Empirical Evaluation Strategy: The evaluation separates constrained-device primitive measurements from complete-system deployment measurements using production software and repeated timing procedures.

B. Lattice-Based Cryptography and Module-LWE

QCG uses lattice-based Module-LWE primitives for post-quantum key establishment and signatures, paired with AES-256-GCM for data encryption. The KEM-DEM construction limits ML-KEM to protecting fresh symmetric keys, combining post-quantum and classical strengths.

  • Lattice cryptography supplies most of NIST’s initially selected post-quantum algorithms and avoids a known efficient quantum analogue of Shor’s attack.
  • Module-LWE adapts Learning With Errors to polynomial-ring elements, reducing key sizes by an order of magnitude while retaining a worst-case to average-case reduction.
  • ML-KEM-1024 establishes a shared secret and ciphertext, while ML-DSA provides post-quantum signatures for authenticity.
  • AES-256 retains an effective 128-bit strength against Grover’s algorithm and is matched to ML-KEM-1024’s category-5 strength.
  • QCG’s KEM-DEM construction encrypts each object with a fresh AES-256-GCM key and encapsulates only that key under ML-KEM-1024.
  • The hybrid design provides defence in depth because breaking either the lattice or symmetric component alone does not expose the plaintext.

B. Key Generation and Parameter Selection

QCG generates a long-term ML-KEM-1024 recipient keypair and uses fresh encapsulated secrets with AES-256-GCM for each protected object. Decryption reverses this process and authenticates the ciphertext before releasing plaintext.

  • Key generation: The recipient’s ML-KEM-1024 keypair is generated once at service initialization, while each encryption uses a fresh symmetric secret.The public key is distributed to senders; the secret key remains with the recipient.
  • Encryption: Each encryption encapsulates a fresh 256-bit shared secret, draws a fresh 96-bit nonce, and encrypts the plaintext with AES-256-GCM.The nonce must not repeat under one key, and the output includes a 128-bit authentication tag.
  • Encryption: The protected object is the tuple (c_kem, N, c_dem, T), after which the client wipes the shared secret from memory.The tuple is uploaded to cloud storage, while the shared secret is not retained.
  • Decryption: Decryption decapsulates c_kem with the recipient’s secret key, decrypts c_dem under K and N, and verifies T in the same operation.A tag mismatch causes the complete operation to fail before plaintext is released.
  • Decryption: GCM binds authentication to the exact ciphertext, so tampering is rejected and recorded rather than producing altered plaintext.The shared secret is erased when decryption ends, whether the operation succeeds or fails.

E. Key Lifecycle Management

QCG treats key custody, authenticity, storage, access, and availability as lifecycle concerns under SME control. Its self-hosted service protects the secret key while exposing a narrowly controlled interface through Sentinel Gate.

  • Key lifecycle: QCG generates and rotates long-term and session key material according to a six-stage lifecycle, including generation, storage, rotation, revocation, and destruction.Fresh symmetric secrets rotate automatically, while long-term key rotation follows the SME’s chosen frequency.
  • Key lifecycle: Revocation refuses further decapsulation with a key judged compromised, while destruction makes associated data unrecoverable after retired keys protect nothing.The SME must balance destruction against data-retention obligations.
  • Custody: Layer 2 keeps the key infrastructure entirely under SME control on a self-managed VPS, while public-cloud storage holds only encrypted bytes.The trust boundary is defined by who holds credentials and administers the key service.
  • Service design: The QS-KMS stores key material, authenticates users, decapsulates on demand, and signs every served public key with ML-DSA-87.Sentinel Gate runs as in-process middleware, and Redis stores gateway and session state.
  • Key protection: The secret key is sealed under an Argon2id-derived vault key with AES-256-GCM, so the VPS stores C_vault rather than sk_R.The master passphrase is not stored on the server, and the encrypted vault can be backed up without exposing sk_R.
  • Trust boundary: The design assumes the SME’s VPS is trusted because sk_R resides in memory during open sessions, although stricter deployments can use physical hardware.ML-KEM-1024’s IND-CCA2 security addresses chosen-ciphertext queries but does not protect a compromised host’s memory.

C. Sentinel Gate as the Access Protection Layer

Sentinel Gate protects the self-hosted QS-KMS before expensive key-service operations execute. It combines application-layer screening, weighted quotas, adaptive penalties, logging, and session-token checks.

  • Gateway role: Every QS-KMS request passes Sentinel Gate because self-hosted key operations are costly and lack hyperscaler-level abuse absorption.Argon2id and ML-KEM decapsulation can impose real resource costs even when requests fail.
  • Request screening: Sentinel Gate checks Redis reputation first, then identity, quota, and volumetric weight before forwarding a request to QS-KMS.The ordering rejects known-bad sources before Argon2id consumes resources.
  • Request screening: Route-weighted quotas make expensive endpoints exhaust an attacker’s allowance faster than cheaper endpoints.Endpoint weights reflect the cost of serving each request, with the assignments listed in Table IV.
  • Abuse controls: Dynamic blacklisting, progressive tarpitting, weighted rate limiting, and forensic logging provide the gateway’s main abuse controls.Trusted devices are exempted from banning and tarpitting while remaining logged, and Redis failure causes closed-mode denial.
  • State management: Redis supports millisecond-scale checks with expiry and shared state across processes, unlike a disk-backed database or plain in-process structure.Session and gateway state therefore remains available across service processes.
  • Session management: Session tokens remain in client memory and are checked against Redis on every later request.A one-hour expiry, synchronous close revocation, and heartbeat expiry jointly bound token lifetime.

E. End-to-End Workflow

QCG combines client-side encryption, self-hosted key custody, and gateway-protected access into an SME-deployable workflow. The proof of concept uses inexpensive, open-source infrastructure, while deployment remains bounded by availability, recovery, and endpoint-trust assumptions.

  • Method and implementation: Design Science Research guides QCG from an SME problem to an evaluated artefact, with implementation decisions revised when the original design could not be built.The implementation section focuses on feasibility and supplies the evaluation setup.
  • Setup: Initial setup installs QS-KMS, Sentinel Gate, and Redis on a VPS, derives a vault key with Argon2id, and registers office machines as trusted devices.The owner retains the master passphrase in memory and receives a usable public key with a sealed secret key.
  • Daily workflow: During normal work, the client encapsulates a fresh key, encrypts drawings with AES-256-GCM, wipes that key, and uploads the protected object to cloud storage.The cloud receives the encrypted result rather than plaintext drawings.
  • Remote access: A remote client authenticates through the gateway before the QS-KMS temporarily accesses the secret key to support decryption.The gateway checks blacklist and rate limits before forwarding the request.
  • Deployment: A two-processor, two-gigabyte VPS costs approximately 4–6 euros monthly, or nothing on some tiers, for the complete key infrastructure.The deployment uses Python, liboqs, pyca/cryptography, FastAPI, Argon2id, Redis, and public repositories for replication.
  • Limitations: The basic installation has a single QS-KMS failure point, password-loss irrecoverability, and an assumption that endpoints are trustworthy.A second instance can improve availability at additional cost and complexity, while forgetting the passphrase permanently prevents recovery.
  • Security scope: Timing-channel resistance relies on constant-time liboqs, whereas power and electromagnetic side-channel evaluation lies outside the work’s scope.Those side channels depend on the physical deployment environment rather than the architecture.

B. Layer 1 Implementation

Layer 1 performs file encryption locally and authenticates the retrieved recipient key before ML-KEM encapsulation. The QS-KMS protects key material with encrypted-at-rest storage, role-gated access, session controls, and ML-DSA signatures.

  • Client-side encryption: Client-side encryption makes no network call, keeping routine file protection local and independent of the key infrastructure.The module provides local encrypt and decrypt operations.
  • Key authenticity: The client verifies the QS-KMS ML-DSA-87 signature on the recipient public key and aborts encryption if verification fails.The locally stored QS-KMS verification key is used to detect public-key substitution.
  • Hybrid encryption: ML-KEM-1024 encapsulation produces the wrapped-key ciphertext and a uniformly random 256-bit shared secret used for subsequent encryption.The shared secret is generated by encapsulation rather than selected beforehand.
  • Hybrid encryption: AES-256-GCM encrypts the plaintext with a fresh 96-bit nonce, producing ciphertext and a 128-bit authentication tag for upload.The protected object contains the KEM ciphertext, nonce, symmetric ciphertext, and tag.
  • Prototype limitation: A Python prototype cannot guarantee immediate destruction of every copy of the shared secret, despite minimizing its lifetime and avoiding disk writes.The paper identifies C or Rust as preferable for strict memory-hygiene requirements.
  • Decryption: Decryption sends the KEM ciphertext to the QS-KMS, recovers the shared secret, and releases plaintext only after AES-256-GCM tag verification.Altered storage or transit data therefore fails authentication and yields no plaintext.
  • Key service: The QS-KMS uses least-privilege, role-gated routes, while Argon2id-derived vault keys protect the ML-KEM secret key at rest.The service also uses ML-DSA-87 to sign registered public keys and manages sessions with expiring, revocable tokens.

D. Sentinel Gate Integration

Sentinel Gate protects the self-hosted QS-KMS through in-process Layer 7 inspection, while shared Redis storage keeps gateway and session state operationally separate. The implementation is version-pinned and publicly inspectable for reproducibility.

  • Gateway integration: Every request passes Sentinel Gate inspection before QS-KMS logic, with trusted-device handling, synchronous revocation, and separate forensic-log storage.The gateway runs as in-process middleware behind the TLS-terminating reverse proxy.
  • Gateway integration: Gateway route weights prioritize expensive authentication, moderate decapsulation, lightweight health operations, and maximum penalties for unrecognized routes.The deployed values match the paper’s Table IV configuration.
  • State management: Gateway state and QS-KMS session tokens share Redis while remaining isolated through separate namespaces.This reduces the storage burden on the small VPS without merging the two concerns.
  • Reproducibility: The proof-of-concept, client, QS-KMS, gateway, benchmark scripts, raw results, and deployment procedure are publicly available.The repository separates QCG-KMS, Sentinel-Gate-QCG, QCG-CLI-Kit, and benchmark materials.
  • Reproducibility: Pinned dependency versions allow the reported benchmarks to be reproduced under the same software conditions.Version pinning prevents later library changes from silently redefining the measurements.

A. Experimental Methodology

The evaluation combines an embedded ML-KEM-1024 benchmark with localhost and remote end-to-end measurements on a live VPS deployment. It separates cryptographic, symmetric-encryption, and network contributions across file sizes.

  • Experimental design: The study measures primitive cost on constrained STM32F407 hardware and full-workflow cost on a live VPS deployment.The live configuration uses a two-vCPU Hetzner CX22 server behind Caddy and the liboqs backend.
  • Embedded benchmark: The STM32F407 benchmark runs at 24 MHz with deterministic cycle counts and measures each operation over twenty runs.Timing uses the on-chip DWT cycle counter, with serial output excluded from the timed region.
  • Embedded benchmark: The embedded benchmark reports stable measurements, supporting the conclusion that ML-KEM-1024 is feasible on hardware weaker than ordinary workstations.Standard deviations are near a tenth of a millisecond, and the paper uses this as its performance floor.
  • Embedded benchmark: The embedded measurements use an enclosed STM32F407 rig with OLED timing output and status indicators.The wiring figure identifies the OLED, LEDs, and reset control connections.
  • End-to-end measurements: The workflow comparison uses co-located and remote clients to isolate computation from wide-area network cost.Both configurations discard warm-up runs and report medians using liboqs.
  • End-to-end measurements: Only the wrapped key crosses the network, so key-encapsulation and network costs remain fixed while local symmetric encryption grows with file size.The remote configuration includes transport cost, whereas localhost uses loopback through the reverse proxy.
  • End-to-end measurements: Post-quantum operations stay below one millisecond across file sizes, while bulk symmetric encryption scales with data and wide-area network cost remains constant.For small files the network dominates; at larger sizes local symmetric encryption becomes the leading cost.

D. Comparison with a Classical Baseline

The comparison finds that QCG’s post-quantum key establishment is computationally comparable to X25519 at the relevant per-message granularity, while larger artefact sizes are the principal transition cost. Additional measurements cover AES throughput, client hardware, ML-DSA, and single-source abuse filtering.

  • Classical baseline: ML-KEM-1024 encapsulation is comparable to X25519 per message, with the difference within measurement variation under the study’s deployment granularity.The comparison accounts for X25519 ephemeral-key generation and ML-KEM’s amortized recipient-key generation.
  • Classical baseline: ML-KEM-1024 public keys and ciphertexts are about 1.5 kilobytes versus 32 bytes for X25519, roughly a factor of fifty larger.The paper identifies size rather than computation as the real transition cost.
  • Symmetric throughput: AES-256-GCM throughput settles at approximately 500 MB/s at scale, with lower small-file throughput caused by fixed per-call overhead.The measurement isolates the symmetric bulk-encryption term that grows with file size.
  • Client hardware: The 2018 i5 encrypts at roughly 442 MB/s and still processes 100 MB in under a quarter of a second, while the 2020 Ryzen reaches roughly 1090 MB/s.Single-threaded AES-NI performance matters more than total core count in this comparison.
  • Authentication cost: ML-DSA-87 operations complete well under one millisecond, so signatures add no meaningful per-object workflow cost.The reported public key, secret key, and signature sizes are 2,592, 4,896, and 4,627 bytes.
  • Abuse resistance: The gateway evaluation measures per-identity rate limiting, credential-stuffing and brute-force resistance, and sustained single-source flood containment.Attack traffic and legitimate probes originate from distinct public addresses and networks.
  • Abuse resistance: 98.8% of attack traffic was removed before reaching the key service, while legitimate median latency changed from 621 to 625 milliseconds.The result held on every run with the gateway enabled.
  • Abuse-resistance limitation: The evaluation does not demonstrate distributed denial-of-service resilience because one attacking machine could not generate enough load to exhaust the server.Distributed abuse from many addresses remains outside the tested scope and is identified as future work.

G. Economic Feasibility

QCG’s self-hosted model is presented as economically feasible for SMEs through predictable flat pricing, while preserving enterprise key custody and avoiding penalties for key hygiene.

  • Managed KMS pricing is metered by keys, key versions, rotations, and cryptographic operations, whereas QCG uses a flat self-hosted cost.Illustrative AWS and Google totals vary with exact usage and deployment assumptions.
  • Self-hosting preserves custody separation that managed services cannot provide when the same provider stores both encrypted data and keys.This trust-model distinction remains part of the economic argument rather than being reduced to price alone.
  • QCG’s economic case is cost predictability, because frequent key rotation and other hygiene do not create additional hosting charges.The paper does not claim self-hosting is cheaper in every instance.

A. The Backend Portability and Performance Trade-off

QCG supports both a dependency-free pure-Python backend and a faster native liboqs backend, allowing portability and performance to be selected behind one interface.

  • The Backend Portability and Performance Trade-off: QCG defaults to pure-Python ML-KEM for portability while allowing native liboqs when performance matters.The pure-Python option avoids system dependencies; liboqs requires compilation or a platform-specific binary.
  • The Backend Portability and Performance Trade-off: Section IX benchmarks use liboqs because per-file key operations are dwarfed by network cost and barely change end-to-end numbers.The implementation therefore exposes backend choice without forcing operators to choose permanently between portability and speed.
  • The Backend Portability and Performance Trade-off: Redis stores session and gateway state outside process memory, allowing rate-limit counters and tokens to survive application restarts.The trade-off is one additional component that must be deployed and secured.
  • The Backend Portability and Performance Trade-off: QCG’s production scope excludes high availability, formal compliance certification, and network-scale distributed denial-of-service protection.These gaps are identified as hardening requirements before deployment with production data.

B. Confidentiality of the Core Construction

QCG’s confidentiality argument composes AES-256-GCM with ML-KEM-1024, while signatures protect recipient-key authenticity and IND-CCA2 security addresses the decapsulation oracle.

  • Confidentiality of the Core Construction: No computationally bounded classical or quantum adversary recovers plaintext from the stored ciphertext tuple without the recipient secret key, under the stated assumptions.The claim reduces confidentiality to ML-KEM-1024 and AES-256-GCM security.
  • Confidentiality of the Core Construction: Each object receives a fresh AES-256-GCM data key, and ML-KEM-1024 encapsulates that key under the recipient public key.This is the paper’s Layer 1 KEM-DEM construction.
  • Confidentiality of the Core Construction: Approximately 128 effective post-quantum bits remain for AES-256 after Grover’s square-root reduction.The paper treats AES-256’s 256-bit key as a margin against quantum search.
  • Confidentiality of the Core Construction: IND-CCA2 security is used to argue that decapsulation-oracle access does not reveal the secret key or information about other encapsulations.The oracle analysis concerns chosen-ciphertext submissions to the key service.
  • Confidentiality of the Core Construction: ML-DSA-87 signatures authenticate the recipient public key, preventing substitution by an adversary unable to forge the signature.The same design also requires hybrid post-quantum protection for TLS carrying authentication and token traffic.

A. Self-Hosted Custody Against Managed Post-Quantum Key Services

QCG argues for self-hosted custody because managed post-quantum services reunite keys and encrypted data under one provider, while QCG separates them at predictable cost.

  • Self-Hosted Custody Against Managed Post-Quantum Key Services: Managed key services place keys under the administrative control of the same provider hosting encrypted data, whereas QCG keeps key custody with the SME.The paper identifies custody separation, not a new cryptographic primitive, as the sharpest contribution.
  • The Longer-Term Economic Argument: Each object uses a fresh data key, so rotation applies only to the recipient keypair rather than to every object key.The envelope design therefore gives QCG a light rotation burden.
  • The Longer-Term Economic Argument: A flat self-hosted cost avoids charges for frequent rotation, while managed pricing scales with keys, versions, and operations.The longer-term comparison emphasizes predictability rather than universal cheapness.
  • The Longer-Term Economic Argument: The integrated gateway still needs evaluation against genuinely distributed abuse, and the single key-service instance needs replication for high availability.These are identified directions for future hardening.
  • The Longer-Term Economic Argument: QCG’s scope excludes production certification, network-layer distributed denial-of-service protection, threshold key management, and formal implementation verification.The paper frames these as boundaries requiring further work before production trust.
Loading 2608.26777v1…