Gnoppix Post-Quantum Email Service

📝 Technical Documentation: Gnoppix Post-Quantum Encrypted Email Service (V 1.4)

1. Introduction and Core Architecture

The Gnoppix Encrypted Email Service is a high-availability, geographically distributed, and quantum-resistant email platform. Its primary function is to intercept all incoming email, encrypt the entire message payload using the recipient’s uploaded Post-Quantum GPG Public Key, and then store the cipher-text in an external, highly optimized object storage environment.

1.1 Key Architectural Principles

• Zero-Knowledge: Gnoppix infrastructure never holds the user’s private keys, nor does it have access to the unencrypted message content.
• Zero User Logging: While the infrastructure is monitored for abuse, no user-specific activity logs are retained.
• Geographical Distribution: Processing infrastructure (nodes) is spread across legally and privacy-secure jurisdictions (Japan, Norway, Iceland).
• Post-Quantum Cryptography: All data at rest is encrypted using user-provided post-quantum cryptographic algorithms (e.g., Dilithium, Falcon, or SPHINCS+ via PQC-enabled GnuPG).

2. System Components and Hardening

The service is built upon a layered stack orchestrated via Docker Swarm across physically distinct data centers, all running on hardened Debian 13 (Trixie) systems.

Component	Technology / Role	Function
Operating System	Hardened Debian 13 (Trixie)	All host systems utilize minimal installs with restricted user access.
Edge Layer	HAProxy, DNS Load Balancing	Global traffic routing and load distribution with strictly limited IP access.
MTA/Ingress	Postfix, Docker Swarm	Receives incoming SMTP traffic; sends all content directly to the Encryption module.
Encryption Proxy	Custom Go/Rust Microservice	The core worker. Performs key lookup, encryption, and submission to Object Storage.
User Management	REST API (Go/Python)	Stores user metadata, encryption flags, and the Post-Quantum GPG Public Key (all hosted on the storage FoundationDB).
Storage Layer	Independent Object Storage	Sponsored, external infrastructure guaranteeing low latency and high traffic throughput for storing encrypted email blobs.
Orchestration	Docker Swarm, Consul and Ansible	Manages container deployment, service discovery, and cross-DC networking.
Security	OpenSource AI	Local AI models report anomalies to our n8n workflows. Based on the severity, appropriate measures are activated.

2.1 Security and Monitoring

The infrastructure, including the infrastructure nodes, is monitored 24/7 for abuse detection and system integrity. This monitoring is strictly limited to system performance and traffic patterns.

• No User Logging: No logs detailing which user logged in, when they accessed email, or what data was transmitted are retained.
• No IP Storage: External IP addresses are not stored or associated with user accounts after connection validation.
• Trained with AI-based attack patterns, which simplifies detection and reporting, showing where the node was destroyed and rebuilt elsewhere in the cluster.

2.2 Cloud Mitigation and Data Safety

We acknowledge that nodes and the object storage reside on cloud infrastructure.

• Mitigation (Processing Nodes): Even if the underlying ISP performs a snapshot of the nodes, the data is safe because the PQC Private Key is never present on these systems.
• Object Storage Mitigation (Data at Rest): Our encrypted data is hosted on infrastructure provided by an independent object storage provider. We do not host content on our servers.
  • This provider guarantees the low latency and high traffic necessary for a scalable service.
  • Crucially, the data placed in the object storage is already the PQC cipher-text blob. The object storage provider receives, stores, and manages meaningless, unreadable, encrypted data. Since the user’s PQC Private Key is never stored on the Gnoppix infrastructure or the object storage, the data remains cryptographically secure against any object storage provider snapshot, internal access, physical seizure, or waterboarding. Your data is safe due to the missing private key.

3. Email Ingress and Encryption Workflow

The entire system is triggered upon a successful SMTP transfer to the MTA layer. With AIDE, we track the application’s integrity, and a local AI monitors abuse.

3.1 Enabling Full Encryption

1. Key Generation: The user must locally generate a GPG key pair using a PQC-enabled GnuPG version.
2. Public Key Upload: The user uploads the Post-Quantum GPG Public Key via the User Management Interface.
3. Public Key Storage: The Public Key is stored locally on the Gnoppix nodes within a high-speed key cache (for fast access to the public keys). The source of truth is the FoundationDB.
4. Encryption Flag: The user enables the “Full Post-Quantum Encryption” flag.

3.2 Incoming Email Flow (Processing Pipeline)

When an external sender transmits an email to [email protected]:

1. SMTP Reception: Received by an available MTA/Ingress container on a hardened Debian 13 node.
2. Key Retrieval: The Encryption module retrieves the user’s Post-Quantum GPG Public Key from the local, high-speed key cache.
3. PQC Encryption (Critical Step): The Encryption Proxy uses the retrieved Public Key to encrypt the entire raw email payload (headers, body, and attachments), resulting in a single PQC cipher-text blob.
4. Storage Submission (local):
   • The MTA generates a unique Message ID.
   • The cipher-text blob is submitted to the Independent Object Storage Provider using authenticated API calls.
5. Synchronization and Replication: The object storage provider’s system is responsible for high durability and replication across its internal architecture, ensuring low latency and fault tolerance.

3.3 MTA Integrity and Email Sharing Constraints

The MTA/Ingress layer, utilizing a heavily customized version of Postfix, is architecturally hardened to prevent several common security and privacy weaknesses:

1.) **No Copying or Forwarding: The MTA is explicitly designed NOT to copy, blind carbon copy (BCC), or forward any incoming email payload to a secondary, external, or internal email address (i.e., address aliasing is disabled for all incoming PQC-flagged mail). This is a critical security measure to prevent accidental data leakage outside the PQC encryption pipeline.

2.) **Direct Pipeline Submission: Upon successful SMTP reception, the message is immediately transferred directly and solely to the Encryption module (3.2, Step 2).

3.) **Given this constraint, traditional email sharing features are not supported. The two available methods for sharing email content while maintaining maximum security are:

4.) **Internal Mail: The sender can use a Gnoppix PQC-enabled email address to send directly to another Gnoppix user. This utilizes the same PQC pipeline for the recipient.

5.) **Self-Share/Account Share: The user can send an email to themselves and then securely share their account credentials with a trusted party, allowing that party to decrypt and view the mail blob on the user’s behalf. Note: Gnoppix highly recommends using strong, unique passwords for this method.

Tor Network Integration: Gnoppix is currently developing support for the Tor Network. This will allow users to access Gnoppix email services natively within the .onion address space, providing an additional layer of anonymity and privacy for the connection itself.

4.0 References

One of the best introductions about Post-Quantum Cryptography I found at: https://www.cnlab.ch/fileadmin/documents/Publikationen/2025/Post-Quantum_Cryptography_-__A_Comprehensive_Guide.pdf In case the link doesn’t work anymore: https://media.gnoppix.org/Post-Quantum_Cryptography_-__A_Comprehensive_Guide.pdf

---