Skip to main content
Glama
scottdhughes

Post-Quantum Cryptography MCP Server

by scottdhughes

耐量子計算機暗号 (PQC) MCPサーバー

License: MIT Python 3.10+ liboqs MCP

研究およびプロトタイプ専用。 このサーバーは liboqs を使用していますが、これは本番環境での使用や機密データの保護には明示的に推奨されていません。store_as モード(推奨)を使用する場合、秘密鍵はツール出力から削除され、セッションスコープのキーリングに保持されます。store_as を使用しない場合、秘密鍵や共有秘密がツール出力に表示され、モデルのコンテキスト、クライアントログ、またはトランスクリプトに含まれる可能性があります。すべての秘密鍵操作に対してハンドルのみのモードを強制するには、PQC_REQUIRE_KEY_HANDLES=1 を設定してください。実験、教育、および相互運用性テストに適しています。

Open Quantum Safeのliboqs を使用して耐量子計算機暗号操作を提供する Model Context Protocol (MCP) サーバー です。ClaudeのようなAIアシスタントが、鍵生成、暗号化、署名、検証などの耐量子計算機暗号操作を実行できるようにします。

なぜ耐量子計算機暗号なのか?

現在の暗号システム(RSA、ECC、ECDSA)は、ショアのアルゴリズムを実行する量子コンピュータによって解読されます。NISTは新しい耐量子計算機アルゴリズムを標準化しました:

標準

アルゴリズム

タイプ

ステータス

FIPS 203

ML-KEM (旧 CRYSTALS-Kyber)

鍵カプセル化

2024年確定

FIPS 204

ML-DSA (旧 CRYSTALS-Dilithium)

デジタル署名

2024年確定

FIPS 205

SLH-DSA (旧 SPHINCS+)

ハッシュベース署名

2024年確定

このMCPサーバーは、これらのアルゴリズムをAIエージェントが研究、開発、統合のために利用できるようにします。

機能

  • liboqs経由で利用可能な鍵カプセル化メカニズム (KEM): ML-KEM, FrodoKEM, HQC, BIKE, Classic McEliece

  • liboqs経由で利用可能な署名アルゴリズム: ML-DSA, Falcon, SLH-DSA, MAYO, CROSS, UOV

  • 完全なMCP統合: Claude Desktop, Claude Code, Cursor、およびあらゆるMCPクライアントで動作

  • NIST標準化アルゴリズムのサポート: FIPS 203, 204, 205アルゴリズムを実装

  • セキュリティ分析: 古典的セキュリティレベルと量子セキュリティレベルの比較

クイックスタート

前提条件

  • Python 3.10+

  • liboqs 共有ライブラリ

  • uv (推奨) または pip

インストール

1. liboqsのインストール

macOS (共有ライブラリ付きHomebrew):

# 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

代替案: 上記を自動化するバンドルインストールスクリプトを使用する:

bash scripts/install-liboqs.sh

2. クローンとインストール

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の設定

MCP設定に追加します:

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"
    }
  }
}

サーバーは python -m pqc_mcp_server を介して直接実行することもできます。

利用可能なツール

pqc_list_algorithms

利用可能なすべての耐量子計算機アルゴリズムを一覧表示します。

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

pqc_algorithm_info

特定のアルゴリズムに関する詳細情報を取得します。

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

pqc_generate_keypair

耐量子計算機鍵ペアを生成します。

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

pqc_encapsulate

鍵カプセル化を実行します(共有秘密を作成)。

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

pqc_decapsulate

暗号文から共有秘密を復元します。

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

pqc_sign

耐量子計算機署名でメッセージに署名します。

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

pqc_verify

耐量子計算機署名を検証します。

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

pqc_hash

量子セーフなハッシュ関数を使用してメッセージをハッシュ化します。

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

pqc_security_analysis

アルゴリズムのセキュリティ特性を分析します。

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

ハイブリッド鍵交換 (X25519 + ML-KEM-768)

スイート: mlkem768-x25519-sha3-256 — LAMPSコンポジットML-KEMドラフト (id-MLKEM768-X25519-SHA3-256) のKEMコンバイナーを借用しています。スイート名の sha3-256 はKEMコンバイナーハッシュを指します。HKDF鍵導出にはSHA-256 (cryptography HKDF経由) を使用します。封印されたエンベロープ層は、そのコンバイナーの上に構築された本プロジェクト独自のプロトコルです。

これは、暗号文の整合性を備えたハイブリッド機密性を提供する 匿名封印ボックス 構造です。受信者の鍵が侵害された場合の前方秘匿性はなく、送信者の認証も行われません。

pqc_hybrid_keygen

ハイブリッド鍵ペアバンドルを生成します。

推奨: store_as を使用(秘密鍵は削除されます)

// 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..."}
}

store_as を使用しない(生の鍵が返されます — 推奨されません):

// 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

ビルディングブロック鍵カプセル化。スイートのSHA3-256コンバイナーを介して導出された結合共有秘密を返します。

pqc_hybrid_seal / pqc_hybrid_open

ハイブリッドカプセル化 + AES-256-GCMを使用してプレーンテキストを暗号化/復号化します。フルヘッダーAADバインディング。決定論的ナンス(エンベロープ内では送信されません)。

// 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"
}

ハイブリッドプロンプトの例

"ハイブリッド鍵ペアを生成してメッセージを封印して"

"ハイブリッド鍵交換を実行して共有秘密を見せて"

"ハイブリッドPQCを使用して'機密データ'を暗号化し、その後復号化して"

認証付きハイブリッドエンベロープ

ML-DSA-65 (FIPS 204) 署名を使用して、ハイブリッド機密性層に送信者認証を追加します。送信者はエンベロープ全体をカバーする正規バイナリトランスクリプトに署名します。受信者は復号化の前に送信者の身元を検証します。

これは 送信者認証付き封印エンベロープ 構造です。受信者の長期鍵が後で侵害された場合の前方秘匿性は依然としてありません。封印されたエンベロープ層は本プロジェクト独自のプロトコルです。

pqc_hybrid_auth_seal

暗号化 + 署名。送信者のML-DSA-65署名鍵 + 受信者のハイブリッド鍵が必要です。

推奨: 鍵ハンドルを使用

// 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..."
  }
}

代替案: 生の鍵を使用(推奨されません)

// 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

送信者の検証 + 復号化。expected_sender_public_key または expected_sender_fingerprint のいずれかが必要です。署名は復号化の前に検証されます — 認証失敗は復号化失敗とは区別されます。

// 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

復号化せずに認証付きエンベロープ上の送信者署名を検証します。秘密鍵は不要です。送信者のバインディング、フィンガープリントの一貫性、ML-DSA-65署名、およびタイムスタンプの鮮度をチェックします。

// 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

復号化せずにエンベロープのメタデータを検査します。秘密鍵は不要です。バージョン、スイート、フィンガープリント、フィールドサイズを返します。

// 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

公開鍵のSHA3-256フィンガープリントを計算します。小文字の16進数を返します。

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

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

pqc_benchmark

PQCアルゴリズムのベンチマーク: 鍵生成、カプセル化/署名、復号化/検証、および鍵/暗号文/署名サイズの時間を測定します。

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

// Output — timing and size measurements

鍵生成フロー

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

認証付きプロンプトの例

"ML-DSA-65署名鍵ペアとハイブリッド受信者鍵ペアを生成し、認証付き暗号化メッセージを送信して"

"この認証付きエンベロープを開封し、期待される送信者からのものであることを検証して"

"ボブ宛にメッセージを封印し、私のML-DSA鍵で署名して。その後、ボブに私のフィンガープリントを使って開封させて"

鍵ハンドル(秘密の削除)

秘密鍵がプロセスローカルに保存され、ツール出力に決して表示されないオプトインモード。ハンドルはプロセスグローバルであり、サーバーの再起動時に失われます。

ハンドルを使用した生成

// 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": "..."}
}

下流ツールでのハンドル使用

// 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"
}

汎用PQCツール (pqc_sign, pqc_verify, pqc_encapsulate, pqc_decapsulate) も key_store_name を受け入れます。

同じ役割に対してストア名と生の鍵の両方を提供することはエラーです。

鍵ストア管理

  • pqc_key_store_save: 便利な参照のために、鍵生成出力を名前で保存します。セッションスコープ、永続性なし。

  • pqc_key_store_load: 名前で保存された鍵を読み込みます。ハンドルエントリの場合は公開素材のみを返します。

  • pqc_key_store_list: メタデータ(名前、タイプ、フィンガープリント)を含むすべての保存済み鍵を一覧表示します。秘密素材は表示されません。

  • pqc_key_store_delete: 名前で保存された鍵を削除します。

セキュリティ機能

v3エンベローププロトコル

v3エンベロープはモードバインドされています: すべてのエンベロープは、HKDF情報、AAD、および認証トランスクリプトにバインドされた明示的な mode フィールド (anon-seal または auth-seal) を保持します。これにより、真のクロスモード分離が提供されます — 一方のモードで生成された暗号文は他方では復号化できず、AEAD層での認証剥離ダウングレード攻撃をブロックします。v3ではAADは長さプレフィックス付きフレーミング(自己区切り)を使用します。認証付きエンベロープには、正規トランスクリプト内に署名付き timestamp フィールドが含まれます。検証/開封時に、サーバーは鮮度をチェックします(デフォルト: 24時間、max_age_seconds で設定可能)。クロックスキューの許容範囲は5分です。

リプレイ保護

サーバーは、TTL付きの署名ダイジェストキャッシュ(エンベロープ署名バイトのSHA3-256)を保持します。pqc_hybrid_auth_verify は読み取り専用のリプレイチェックを実行します。pqc_hybrid_auth_open は復号化前のチェックと成功後のマークを実行します。キャッシュは ~/.pqc/state/replay-cache.json に永続化され、サーバーの再起動後も保持されます。最大50,000エントリ、古いものから順に削除されます。

エンベロープサイズの検証

すべてのエンベロープは、暗号処理の前に検証されます: base64フィールドごとに最大1MB (ciphertext, pqc_ciphertext, signature, sender_public_key, x25519_ephemeral_public_key)、合計最大50フィールド。メモリ爆弾やリソース枯渇を防ぎます。

サーバーセキュリティポリシー

PQC_REQUIRE_KEY_HANDLES=1 を設定してハンドルのみのモードを強制します: サーバーは生の秘密鍵を渡すツール呼び出しを拒否し、すべての秘密鍵操作(鍵生成、署名、復号化、およびハイブリッドエンベロープ操作)に対して store_as/key_store_name の使用を強制します。これは、不正なエージェントによってバイパスできないサーバー側のチェックです。

v1/v2の後方互換性

v1エンベロープ (pqc-mcp-v1) は、後方互換性のために開封/検証時に受け入れられますが、大きな警告が表示されます。v1エンベロープには署名付きタイムスタンプがないため、鮮度チェックがスキップされ、リプレイ保護も提供されません。v2エンベロープ (pqc-mcp-v2) は受け入れられますが、モードバインディングが欠如しています。応答に非推奨の警告が含まれます。

リレートランスポート

このプロジェクトには、マシン間A2Aメッセージング用のCloudflare Workerリレーが含まれています。

ライブ: https://quantum-seal-relay.novoamorx1.workers.dev

リレーは不透明なエンベロープメールボックスです — 暗号操作を実行したり秘密鍵にアクセスしたりすることなく、JSONブロブを保存および転送します。

エンドポイント

メソッド

目的

/mailboxes/:fp

POST

受信者のメールボックスにエンベロープを預ける

/mailboxes/:fp

GET

保留中のエンベロープを取得する

/mailboxes/:fp/:id

DELETE

受信を確認する

/mailboxes/:fp/allowlist

PUT

送信者許可リストを設定する

制限: 最大50KBのエンベロープ、メールボックスあたり1000メッセージ、24時間のTTL、レート制限(IPあたり60 POST/分、120 GET/分)。

セキュリティ: リレーはプレ

-
security - not tested
A
license - permissive license
-
quality - not tested

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/scottdhughes/post-quantum-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server