QUANTUM GEM

SYSTEM DOCUMENTATION

Project Documentation: Quantum-Resilient Secure Communication System

1. Introduction & Goal

This documentation serves as a comprehensive guide for the Quantum-Resilient Secure Communication System. The primary goal of this system is to secure digital communications against the dual threat of:

  • Classical Attacks: Exploitation of current RSA/ECC vulnerabilities.
  • Quantum Attacks: Future compromise of classical cryptography by large-scale Quantum Computers (QC).

This system achieves resilience by implementing an Adaptive Hybrid Key Exchange Protocol (RSA + Kyber), ensuring security during the critical transition phase to Post-Quantum Cryptography (PQC).

2. Architecture & Stack

The application is built on the Python/Django framework, following the Model-View-Template (MVT) architectural pattern.

Component Technology Role in Quantum Resilience
PQC Key Exchange Kyber-768 (via oqs-python) Provides Quantum Confidentiality. Lattice-based security resists Shor's algorithm.
Classical Assurance RSA-2048 Provides Classical Integrity. Secures initial exchange and verifies server identity.
Session Storage Redis (Vercel KV) Persistent Storage for user sessions across serverless instances.
Symmetric Encryption AES-256 GCM Secures message traffic with the Session Key (KSession).
Framework Django / Python Hosts API endpoints and User Interface.

3. Adaptive Hybrid Protocol

The core security feature is the Hybrid Key Exchange, which combines the outputs of two distinct algorithms using a Key Derivation Function (KDF).

3.1. KEX Flow Steps

  1. Key preparation: Server loads RSA-2048 & Kyber-768 keys. Client generates ephemeral RSA keys.
  2. Hybrid Exchange: Client sends RSA Public Key + Kyber Ciphertext to Server.
  3. Identity Verification: Server Signs the Kyber Public Key with its RSA Private Key. Client verifies this signature to prevent Man-in-the-Middle (MITM) attacks.
  4. Secret Derivation:
    • SRSA: Classical Secret via RSA.
    • SKyber: Quantum Secret via Kyber decapsulation.
  5. Session Key Gen: 256-bit Session Key derived via HKDF-SHA256:
    KSession = HKDF(SKyber || SRSA)

3.2. Adaptive Threat Response

The system features an Adaptive Resilience Mode:

  • Standard Mode (Hybrid): Defaults to RSA + Kyber for layered security.
  • Threat Response Mode (Kyber-Only): If a classical compromise is detected (or simulated via the UI "Simulate Attack" checkbox), the system ignores the RSA component and derives keys solely from SKyber.

4. User Interface Guide

The interface is modular and intuitive.

4.1. Key Exchange

  • FETCH_KEYS: Retrieve server public keys.
  • INITIATE_HANDSHAKE: Perform the hybrid exchange to establish KSession.
  • SIMULATE ATTACK: Checkbox to forcibly switch the system to Kyber-Only mode for testing.

4.2. Secure Messaging

  • ENCRYPT: AES-256 GCM encryption. Output: Ciphertext, Nonce, Tag.
  • DECRYPT: Verifies integrity (Tag) and recovers plaintext.

5. Performance Benchmarks

The system includes a built-in benchmarking suite to measure cryptographic overhead.

  • Execution Time: Measures the milliseconds taken for Key Exchange, Encryption, and Decryption.
  • Resource Usage: Tracks CPU and Memory consumption during cryptographic operations.

Results are visualized in real-time charts on the Dashboard.

6. System Logs

A real-time Audit Log panel records critical security events:

  • AUTH: Login/Logout events.
  • KEY_EXCHANGE: Successful handshakes and mode switches (Hybrid/Kyber).
  • THREAT: Detection or simulation of attacks.
  • CRYPTO: Encryption/Decryption operations.

7. Restrictions

  • PEM Format: Keys must be valid PEM strings.
  • UTF-8: Plaintext must be convertible to UTF-8.
  • Integrity: Ciphertext, Nonce, and Tag must match exactly for decryption to succeed.