Post-Quantum-Kryptographie MCP-Server

Nur für Forschung und Prototyping. Dieser Server verwendet liboqs, das ausdrücklich nicht für den produktiven Einsatz oder zum Schutz sensibler Daten empfohlen wird. Bei Verwendung des Modus store_as (empfohlen) werden geheime Schlüssel aus der Tool-Ausgabe entfernt und in einem sitzungsgebundenen Schlüsselbund gespeichert. Ohne store_as erscheinen geheime Schlüssel und gemeinsame Geheimnisse in der Tool-Ausgabe, was in den Modellkontext, Client-Protokolle oder Transkripte gelangen kann. Setzen Sie PQC_REQUIRE_KEY_HANDLES=1, um den Handle-only-Modus für alle Operationen mit geheimen Schlüsseln zu erzwingen. Geeignet für Experimente, Bildung und Interoperabilitätstests.

Ein Model Context Protocol (MCP) Server, der post-quantenkryptografische Operationen unter Verwendung von Open Quantum Safe's liboqs bereitstellt. Ermöglicht KI-Assistenten wie Claude die Durchführung quantenresistenter kryptografischer Operationen, einschließlich Schlüsselgenerierung, Verschlüsselung, Signierung und Verifizierung.

Warum Post-Quantum-Kryptografie?

Aktuelle kryptografische Systeme (RSA, ECC, ECDSA) werden durch Quantencomputer, die den Shor-Algorithmus ausführen, gebrochen werden. Das NIST hat neue quantenresistente Algorithmen standardisiert:

Dieser MCP-Server macht diese Algorithmen für KI-Agenten für Forschung, Entwicklung und Integration zugänglich.

Funktionen

• Key Encapsulation Mechanisms (KEMs) verfügbar via liboqs: ML-KEM, FrodoKEM, HQC, BIKE, Classic McEliece

• Signaturalgorithmen verfügbar via liboqs: ML-DSA, Falcon, SLH-DSA, MAYO, CROSS, UOV

• Vollständige MCP-Integration: Funktioniert mit Claude Desktop, Claude Code, Cursor und jedem MCP-Client

• Unterstützt NIST-standardisierte Algorithmen: Implementiert FIPS 203, 204 und 205 Algorithmen

• Sicherheitsanalyse: Vergleich klassischer vs. Quanten-Sicherheitsniveaus

Schnellstart

Voraussetzungen

• Python 3.10+

• liboqs Shared Library

• uv (empfohlen) oder pip

Installation

1. liboqs installieren

macOS (Homebrew mit Shared Library):

# Homebrew only provides static library, build from source for shared:
git clone --depth 1 --branch 0.15.0 https://github.com/open-quantum-safe/liboqs.git
cd liboqs && mkdir build && cd build
cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=$HOME/.local ..
make -j4 && make install

Ubuntu/Debian:

sudo apt-get install liboqs-dev

Alternative: Verwenden Sie das mitgelieferte Installationsskript, das die oben genannten Schritte automatisiert:

bash scripts/install-liboqs.sh

2. Klonen und Installieren

git clone https://github.com/scottdhughes/post-quantum-mcp.git
cd post-quantum-mcp

# Install all dependencies (creates .venv automatically)
uv sync --all-extras

3. Claude Code / Claude Desktop konfigurieren

Fügen Sie dies zu Ihrer MCP-Konfiguration hinzu:

Claude Code (~/.claude.json):

{
  "mcpServers": {
    "pqc": {
      "type": "stdio",
      "command": "/path/to/post-quantum-mcp/run.sh",
      "args": [],
      "env": {}
    }
  }
}

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "pqc": {
      "command": "/path/to/post-quantum-mcp/run.sh"
    }
  }
}

Der Server kann auch direkt über python -m pqc_mcp_server ausgeführt werden.

Verfügbare Tools

pqc_list_algorithms

Listet alle verfügbaren Post-Quantum-Algorithmen auf.

Input: { "type": "kem" | "sig" | "all" }
Output: List of available algorithms with NIST standard mappings

pqc_algorithm_info

Ruft detaillierte Informationen zu einem bestimmten Algorithmus ab.

Input: { "algorithm": "ML-KEM-768" }
Output: Key sizes, security level, performance characteristics

pqc_generate_keypair

Generiert ein quantenresistentes Schlüsselpaar.

Input: { "algorithm": "ML-DSA-65" }
Output: Base64-encoded public and secret keys

pqc_encapsulate

Führt Key Encapsulation durch (erstellt ein gemeinsames Geheimnis).

Input: { "algorithm": "ML-KEM-768", "public_key": "<base64>" }
Output: Ciphertext and shared secret

pqc_decapsulate

Stellt ein gemeinsames Geheimnis aus dem Ciphertext wieder her.

Input: { "algorithm": "ML-KEM-768", "secret_key": "<base64>", "ciphertext": "<base64>" }
Output: Shared secret

pqc_sign

Signiert eine Nachricht mit einer Post-Quantum-Signatur.

Input: { "algorithm": "ML-DSA-65", "secret_key": "<base64>", "message": "Hello, quantum world!" }
Output: Base64-encoded signature

pqc_verify

Verifiziert eine Post-Quantum-Signatur.

Input: { "algorithm": "ML-DSA-65", "public_key": "<base64>", "message": "...", "signature": "<base64>" }
Output: { "valid": true/false }

pqc_hash

Hasht eine Nachricht unter Verwendung quantensicherer Hash-Funktionen.

Input: { "message": "data", "algorithm": "SHA3-256" | "SHA3-512" | "SHAKE128" | "SHAKE256" }
Output: Digest in hex and base64

pqc_security_analysis

Analysiert die Sicherheitseigenschaften eines Algorithmus.

Input: { "algorithm": "ML-KEM-768" }
Output: NIST level, classical/quantum security equivalents, Grover/Shor resistance

Hybrider Schlüsselaustausch (X25519 + ML-KEM-768)

Suite: mlkem768-x25519-sha3-256 — nutzt den KEM-Kombinierer aus dem LAMPS Composite ML-KEM Entwurf (id-MLKEM768-X25519-SHA3-256). Das sha3-256 im Namen der Suite bezieht sich auf den KEM-Kombinierer-Hash; die HKDF-Schlüsselableitung verwendet SHA-256 (via cryptography HKDF). Die Sealed-Envelope-Schicht ist das eigene Protokoll dieses Projekts, das auf diesem Kombinierer aufbaut.

Dies ist eine anonyme Sealed-Box-Konstruktion, die hybride Vertraulichkeit mit Ciphertext-Integrität bietet. Sie ist nicht Forward-Secret gegenüber einer Kompromittierung des Empfängerschlüssels und nicht senderauthentifiziert.

pqc_hybrid_keygen

Generiert ein hybrides Schlüsselpaar-Bündel.

Empfohlen: mit store_as (geheime Schlüssel entfernt)

// Input
{"store_as": "alice"}

// Output — no secret keys
{
  "suite": "mlkem768-x25519-sha3-256",
  "handle": "alice",
  "classical": {"algorithm": "X25519", "public_key": "DeRN3xLbEglMdXKO7P98cAvc...", "fingerprint": "a1b2c3d4..."},
  "pqc": {"algorithm": "ML-KEM-768", "public_key": "gDsL8UgEVcMeJgUOQgSlAotx...", "fingerprint": "e5f6a7b8..."}
}

Ohne store_as (Rohschlüssel werden zurückgegeben — nicht empfohlen):

// Input
{}

// Output — secret keys exposed in tool output
{
  "suite": "mlkem768-x25519-sha3-256",
  "classical": {
    "algorithm": "X25519",
    "public_key": "DeRN3xLbEglMdXKO7P98cAvc...",
    "secret_key": "YEYD9j5c2hpTei0ferXWbAFb..."
  },
  "pqc": {
    "algorithm": "ML-KEM-768",
    "public_key": "gDsL8UgEVcMeJgUOQgSlAotx...",
    "secret_key": "MQB2U0EzNGmloLuiTYG3BTcr..."
  }
}

pqc_hybrid_encap / pqc_hybrid_decap

Baustein für Key Encapsulation. Gibt ein kombiniertes gemeinsames Geheimnis zurück, das über den SHA3-256-Kombinierer der Suite abgeleitet wurde.

pqc_hybrid_seal / pqc_hybrid_open

Verschlüsselt/entschlüsselt Klartext unter Verwendung von hybrider Kapselung + AES-256-GCM. Vollständige Header-AAD-Bindung. Deterministische Nonce (wird nicht im Umschlag übertragen).

// Seal input
{
  "plaintext": "Hello, quantum world!",
  "recipient_classical_public_key": "<base64 X25519 public key>",
  "recipient_pqc_public_key": "<base64 ML-KEM-768 public key>"
}

// Seal output
{
  "envelope": {
    "version": "pqc-mcp-v3",
    "mode": "anon-seal",
    "suite": "mlkem768-x25519-sha3-256",
    "x25519_ephemeral_public_key": "6+b1Y8AkgEycKL5wL2cIeSMv...",
    "pqc_ciphertext": "DF+PYy4zx+OmnW8wLD3EL+4M...",
    "ciphertext": "NnEap2fDq5+xTCwvHdKfy5Xj..."
  }
}

// Open input
{
  "envelope": { "...envelope from seal..." },
  "classical_secret_key": "<base64 X25519 secret key>",
  "pqc_secret_key": "<base64 ML-KEM-768 secret key>"
}

// Open output
{
  "suite": "mlkem768-x25519-sha3-256",
  "plaintext": "Hello, quantum world!",
  "plaintext_base64": "SGVsbG8sIHF1YW50dW0gd29ybGQh"
}

Beispiel für hybride Prompts

"Generiere ein hybrides Schlüsselpaar und versiegle eine Nachricht für mich"

"Führe einen hybriden Schlüsselaustausch durch und zeige mir das gemeinsame Geheimnis"

"Verschlüssele 'geheime Daten' mit hybrider PQC und entschlüssele sie dann"

Authentifizierte hybride Umschläge

Fügt der hybriden Vertraulichkeitsschicht eine Senderauthentifizierung unter Verwendung von ML-DSA-65 (FIPS 204) Signaturen hinzu. Der Absender signiert ein kanonisches binäres Transkript, das den gesamten Umschlag abdeckt. Der Empfänger verifiziert die Identität des Absenders vor der Entschlüsselung.

Dies ist eine senderauthentifizierte Sealed-Envelope-Konstruktion. Sie ist weiterhin nicht Forward-Secret gegenüber einer späteren Kompromittierung des langfristigen Empfängerschlüssels. Die Sealed-Envelope-Schicht ist das eigene Protokoll dieses Projekts.

pqc_hybrid_auth_seal

Verschlüsseln + Signieren. Erfordert ML-DSA-65-Signaturschlüssel des Absenders + hybride Schlüssel des Empfängers.

Empfohlen: mit Schlüssel-Handles

// Input
{
  "plaintext": "Authenticated message",
  "recipient_key_store_name": "bob",
  "sender_key_store_name": "alice-signing"
}

// Output
{
  "envelope": {
    "version": "pqc-mcp-v3",
    "mode": "auth-seal",
    "suite": "mlkem768-x25519-sha3-256",
    
    "sender_signature_algorithm": "ML-DSA-65",
    "sender_public_key": "0ji6POTItnZUX8rELwVwWSOV...",
    "sender_key_fingerprint": "0f617ece2f1d04c0...",
    "recipient_classical_key_fingerprint": "c1deade4a5300a9a...",
    "recipient_pqc_key_fingerprint": "bb0e084213d6ac74...",
    "x25519_ephemeral_public_key": "5LEikNANeJNhZSiq...",
    "pqc_ciphertext": "ybgWc3ruG3JwXmr4...",
    "ciphertext": "6OYdADdh0eH/LviD...",
    "signature": "BOniPALs1kfhWcRh..."
  }
}

Alternative: mit Rohschlüsseln (nicht empfohlen)

// Input
{
  "plaintext": "Authenticated message",
  "recipient_classical_public_key": "<base64 X25519 public key>",
  "recipient_pqc_public_key": "<base64 ML-KEM-768 public key>",
  "sender_secret_key": "<base64 ML-DSA-65 secret key>",
  "sender_public_key": "<base64 ML-DSA-65 public key>"
}

pqc_hybrid_auth_open

Absender verifizieren + entschlüsseln. Erfordert entweder expected_sender_public_key oder expected_sender_fingerprint. Die Signatur wird vor der Entschlüsselung verifiziert — Authentifizierungsfehler unterscheiden sich von Entschlüsselungsfehlern.

// Open with expected sender public key
{
  "envelope": { "...envelope from auth_seal..." },
  "classical_secret_key": "<base64 X25519 secret key>",
  "pqc_secret_key": "<base64 ML-KEM-768 secret key>",
  "expected_sender_public_key": "<base64 ML-DSA-65 public key>"
}

// Or open with expected sender fingerprint
{
  "envelope": { "...envelope from auth_seal..." },
  "classical_secret_key": "...",
  "pqc_secret_key": "...",
  "expected_sender_fingerprint": "0f617ece2f1d04c0481aa0fe..."
}

// Output
{
  "suite": "mlkem768-x25519-sha3-256",
  "plaintext": "Authenticated message",
  "plaintext_base64": "QXV0aGVudGljYXRlZCBtZXNzYWdl",
  "sender_key_fingerprint": "0f617ece2f1d04c0481aa0fe...",
  "sender_signature_algorithm": "ML-DSA-65",
  "authenticated": true
}

pqc_hybrid_auth_verify

Verifiziert die Absendersignatur auf einem authentifizierten Umschlag OHNE zu entschlüsseln. Keine geheimen Schlüssel erforderlich. Überprüft Absenderbindung, Fingerabdruck-Konsistenz, ML-DSA-65-Signatur und Zeitstempel-Aktualität.

// Input
{
  "envelope": { "...envelope from auth_seal..." },
  "expected_sender_fingerprint": "0f617ece2f1d04c0..."
}

// Output
{
  "verified": true,
  "sender_key_fingerprint": "0f617ece2f1d04c0...",
  "sender_signature_algorithm": "ML-DSA-65",
  "version": "pqc-mcp-v3",
  "mode": "auth-seal",
  "replay_seen": false,
  "timestamp": "1711929600"
}

pqc_envelope_inspect

Inspiziert Umschlag-Metadaten ohne Entschlüsselung. Keine geheimen Schlüssel erforderlich. Gibt Version, Suite, Fingerabdrücke und Feldgrößen zurück.

// Input
{"envelope": { "...any sealed or authenticated envelope..." }}

// Output
{
  "version": "pqc-mcp-v3",
  "mode": "auth-seal",
  "suite": "mlkem768-x25519-sha3-256",
  "authenticated": true,
  "sender_key_fingerprint": "0f617ece2f1d04c0...",
  
  
  "ciphertext_size": 1234,
  "plaintext_size_approx": 1218,
  "pqc_ciphertext_size": 1088,
  "signature_size": 3309
}

pqc_fingerprint

Berechnet den SHA3-256-Fingerabdruck eines öffentlichen Schlüssels. Gibt hexadezimal in Kleinbuchstaben zurück.

// Input
{"public_key": "<base64-encoded public key>"}

// Output
{"fingerprint": "a1b2c3d4e5f6...", "algorithm": "SHA3-256"}

pqc_benchmark

Benchmark eines PQC-Algorithmus: zeitgesteuerte Schlüsselgenerierung, Kapselung/Signierung, Dekapselung/Verifizierung sowie Schlüssel-/Ciphertext-/Signaturgrößen.

// Input
{"algorithm": "ML-KEM-768", "iterations": 10}

// Output — timing and size measurements

Ablauf der Schlüsselgenerierung

1. Sender: generate ML-DSA-65 signing keys via pqc_generate_keypair
2. Recipient: generate hybrid keys via pqc_hybrid_keygen
3. Exchange public keys out-of-band
4. Sender: pqc_hybrid_auth_seal with both key sets
5. Recipient: pqc_hybrid_auth_open with expected sender identity

Beispiel für authentifizierte Prompts

"Generiere ein ML-DSA-65 Signatur-Schlüsselpaar und ein hybrides Empfänger-Schlüsselpaar, dann sende eine authentifizierte verschlüsselte Nachricht"

"Öffne diesen authentifizierten Umschlag und verifiziere, dass er vom erwarteten Absender stammt"

"Versiegle eine Nachricht an Bob und signiere sie mit meinem ML-DSA-Schlüssel, dann lass Bob sie mit meinem Fingerabdruck öffnen"

Schlüssel-Handles (Geheimnis-Redaktion)

Opt-in-Modus, bei dem geheime Schlüssel prozesslokal gespeichert werden und niemals in der Tool-Ausgabe erscheinen. Handles sind prozessweit und gehen bei einem Serverneustart verloren.

Generieren mit Handles

// pqc_hybrid_keygen with store_as
{"store_as": "alice"}

// Output — no secret keys
{
  "suite": "mlkem768-x25519-sha3-256",
  "handle": "alice",
  "classical": {"algorithm": "X25519", "public_key": "...", "fingerprint": "..."},
  "pqc": {"algorithm": "ML-KEM-768", "public_key": "...", "fingerprint": "..."}
}

Verwendung von Handles in nachgelagerten Tools

// pqc_hybrid_seal with store name instead of raw keys
{
  "plaintext": "Hello via handle!",
  "recipient_key_store_name": "alice"
}

// pqc_hybrid_auth_seal with two store names
{
  "plaintext": "Authenticated via handles",
  "recipient_key_store_name": "alice",
  "sender_key_store_name": "bob-signing"
}

Generische PQC-Tools (pqc_sign, pqc_verify, pqc_encapsulate, pqc_decapsulate) akzeptieren ebenfalls key_store_name.

Die Angabe sowohl eines Store-Namens als auch von Rohschlüsseln für dieselbe Rolle ist ein Fehler.

Key Store Management

• pqc_key_store_save: Speichert eine Ausgabe der Schlüsselgenerierung unter einem Namen für bequeme Referenz. Sitzungsgebunden, keine Persistenz.

• pqc_key_store_load: Lädt einen gespeicherten Schlüssel unter einem Namen. Gibt nur öffentliches Material für Handle-Einträge zurück.

• pqc_key_store_list: Listet alle gespeicherten Schlüssel mit Metadaten auf (Namen, Typen, Fingerabdrücke). Kein geheimes Material wird angezeigt.

• pqc_key_store_delete: Löscht einen gespeicherten Schlüssel unter einem Namen.

Sicherheitsfunktionen

v3 Umschlag-Protokoll

v3-Umschläge sind modusgebunden: Jeder Umschlag trägt ein explizites mode-Feld (anon-seal oder auth-seal), das in HKDF-Info, AAD und das Authentifizierungs-Transkript eingebunden ist. Dies bietet eine echte Trennung der Modi — Ciphertext, der in einem Modus erstellt wurde, kann nicht im anderen entschlüsselt werden, was Downgrade-Angriffe durch Auth-Stripping auf der AEAD-Ebene blockiert. AAD verwendet in v3 längenpräfixiertes Framing (selbstbegrenzend). Authentifizierte Umschläge enthalten ein signiertes timestamp-Feld im kanonischen Transkript; bei der Verifizierung/Öffnung prüft der Server die Aktualität (Standard: 24 Stunden, konfigurierbar über max_age_seconds). Die Toleranz für Takt-Skew beträgt 5 Minuten.

Replay-Schutz

Der Server unterhält einen Signatur-Digest-Cache (SHA3-256 der Umschlag-Signatur-Bytes) mit TTL. pqc_hybrid_auth_verify führt eine schreibgeschützte Replay-Prüfung durch. pqc_hybrid_auth_open führt eine Prüfung vor der Entschlüsselung und eine Markierung nach Erfolg durch. Der Cache bleibt in ~/.pqc/state/replay-cache.json bestehen und überlebt Serverneustarts. Maximal 50.000 Einträge mit "Älteste zuerst"-Verdrängung.

Umschlaggrößen-Validierung

Alle Umschläge werden vor jeder kryptografischen Verarbeitung validiert: maximal 1 MB pro Base64-Feld (ciphertext, pqc_ciphertext, signature, sender_public_key, x25519_ephemeral_public_key), maximal 50 Felder insgesamt. Verhindert Speicherbomben und Ressourcenerschöpfung.

Server-Sicherheitsrichtlinie

Setzen Sie PQC_REQUIRE_KEY_HANDLES=1, um den Handle-only-Modus zu erzwingen: Der Server lehnt jeden Tool-Aufruf ab, der rohe geheime Schlüssel übergibt, und erzwingt die Verwendung von store_as/key_store_name für alle Operationen mit geheimen Schlüsseln (Schlüsselgenerierung, Signieren, Dekapsulieren und hybride Umschlagoperationen). Dies ist eine serverseitige Prüfung, die von einem fehlerhaften Agenten nicht umgangen werden kann.

v1/v2 Abwärtskompatibilität

v1-Umschläge (pqc-mcp-v1) werden beim Öffnen/Verifizieren aus Gründen der Abwärtskompatibilität akzeptiert, erzeugen jedoch eine deutliche Warnung. v1-Umschläge fehlen signierte Zeitstempel und überspringen daher Aktualitätsprüfungen und bieten keinen Replay-Schutz. v2-Umschläge (pqc-mcp-v2) werden akzeptiert, ihnen fehlt jedoch die Modusbindung; eine Deprecation-Warnung ist in der Antwort enthalten.

Relay-Transport

Das Projekt enthält ein Cloudflare Worker-Relay für maschinenübergreifendes A2A-Messaging.

Live: `https://quantum-seal-relay.novoamorx1.workers.dev