Sumitchongder/Quantum-Resistant-Module-Lattice-Cryptography

# 🛡️ PQ-BANK：抗量子钱包与密钥管理系统（基于格密码学） [](https://github.com/Sumitchongder/Quantum-Resistant-Module-Lattice-Cryptography) [](https://www.rust-lang.org/) [](https://csrc.nist.gov/projects/post-quantum-cryptography) [](LICENSE) ## 基于 Rust 的模块格密码学现代演示 ## ✨ 执行摘要 **PQ-BANK** 是一个真实的 Rust 应用程序，演示如何使用基于格的 PQC（Kyber + Dilithium）、AEAD 信封（XChaCha20-Poly1305）和安全的密钥处理模式来保护银行记录、交易负载和加密钱包免受未来量子威胁，并提供精美的用户界面和审计功能。 ## 目录 1. 动机与价值 2. 架构与组件 3. 密码学深度解析（直观 + 技术） - PQC：是什么及为什么 - 基于格的密码学（直观） - Kyber（KEM）和 Dilithium（签名）——我们如何使用它们 - 混合信封模式（HKDF + XChaCha20-Poly1305） - 密码/钱包保护（Argon2id） 4. 威胁模型与安全考虑 5. 项目结构与需包含在仓库中的文件 6. 快速开始：构建与运行（复制粘贴命令） 7. 如何测试与示例输入 8. 开发者 notes：扩展到生产环境 9. 常见问题解答 / 故障排除 10. 许可与贡献 ## 动机与价值 量子计算机对常见的非对称密码学（RSA、ECC）构成威胁。处理金融或身份数据的组织必须具备**密码学灵活性**，并现在开始集成 PQC。本项目展示了实际工程实践，展示 PQC 原语如何集成到安全应用堆中、如何将它们与对称原语结合，以及如何通过密码学增强用户体验和审计能力。 ## 架构与组件

关键流程： - 钱包创建：生成 **Kyber** + **Dilithium** 密钥对，使用密码派生密钥（Argon2id + HKDF）加密，并存储为加密的钱包 JSON。 - 交易/文件上传：客户端获取服务器 Kyber 公钥，封装产生密文 + 共享密钥 → 通过 HKDF 派生会话密钥 → 使用 XChaCha20-Poly1305 加密负载 → 使用 Dilithium 签名负载 → 发送信封到服务器。 - 服务器：解封装获取会话密钥，验证签名，重新加密信封以供存储，附加签名审计块。 ## 密码学深度解析 — 直观 + 技术 本节解释这些原语、选择它们的原因以及它们是如何应用的。 ### 1) 后量子密码学（PQC）— 是什么及为什么（直观） - 传统公钥算法（RSA、ECDSA）依赖于数论困难问题（整数分解、离散对数）。使用** Shor 算法**的量子计算机可以高效地破解这些算法。 - **PQC** 算法旨在抵御量子攻击。NIST 在公开竞赛后标准化了多种 PQC 算法（Kyber、Dilithium 等）。 - PQC 并非灵丹妙药 — 需要谨慎组合和迁移规划。本项目展示了一种安全、实用的组合模式。

### 2) 基于格的密码学 - 格是高维空间中的规则点阵。格问题（如带错误学习 — LWE）在维数大且存在噪声的情况下，用经典和量子算法都难以求解。 - **Module-LWE / Module-LWR**（模块格）是使用多项式结构的高效变体 — 它们在密钥大小方面提供强大的安全性，是 Kyber 和 Dilithium 的基础。 **比喻：** 想象在巨大的多维噪声 mattress 上寻找最小的凹陷 — 这在计算上很昂贵，而且量子计算机不像对整数分解那样有算术捷径。

### 3) Kyber（KEM）— 如何使用 - **KEM** = 密钥封装机制。Kyber 是 NIST 标准化的基于模块格的 KEM。 - 流程（客户端/服务器）： 1. 服务器发布 Kyber 公钥 PK_S。 2. 客户端调用 `encapsulate(PK_S)` → 获取（CT, shared_secret）。 3. 客户端发送 CT 到服务器。 4. 服务器执行 `decapsulate(CT, SK_S)` → 恢复相同的 shared_secret。 - 我们使用 **HKDF-SHA256** 从 shared_secret 派生对称会话密钥。 **为什么选择 KEM？** 它为每个会话提供前向安全性，避免了不抗量子的经典 Diffie–Hellman 结构。 ### 4) Dilithium（签名）— 如何使用 - **Dilithium** 是 NIST 标准化的基于格的数字签名方案。 - 我们使用**分离签名**： - 客户端对负载（交易 JSON 或文件摘要）进行签名。 - 服务器使用负载中提供的客户端公钥验证签名。 - 服务器使用自己的 Dilithium 密钥对审计块进行签名，以证明日志的真实性。 **为什么选择 Dilithium？** 它提供强大的后量子消息完整性和不可否认性。 ### 5) 混合信封：HKDF + XChaCha20-Poly1305 我们遵循**信封模式**： 1. `shared_secret`（Kyber）→ 通过 `HKDF(SHA256)` 得到 `session_key`。 2. `session_key`（32 字节）与 `XChaCha20-Poly1305` AEAD 一起使用： - Nonce：24 字节（随机 XNonce）。 - 密文 = AEAD.encrypt(nonce, plaintext, associated_data) - 在加密信封中存储 `nonce||ct` + 元数据。 为什么采用这种方法？ - KEM 在不传输密钥的情况下提供带认证的共享密钥。 - HKDF 是一种强大的 KDF，避免了直接使用 shared_secret 位。 - XChaCha20-Poly1305 快速、安全（AEAD），比 TLS 原语更简单易用。XChaCha 的 24 字节 nonce 降低了 nonce 重用风险。 ### 6) 密码与钱包保护（Argon2id + salt） - 钱包加密使用强密码 KDF：**Argon2id**（内存硬），每个钱包使用 salt 和推荐参数。 - 派生密钥然后通过 HKDF 处理，以完成用于加密钱包 blob（Kyber + Dilithium 私钥数据）的对称密钥。 - **为什么选择 Argon2id：** 抵抗 GPU/ASIC 暴力破解，平衡时间/内存成本。 ## 威胁模型与安全考虑 **假设** - 本地演示：服务器在 `127.0.0.1` 上运行。默认不暴露网络。 - 用户仅为本地钱包解锁提供密码。 **考虑的对手能力** - 磁盘泄露（攻击者可以读取加密的钱包/信封）。 - 网络窃听本地 TCP（客户端/服务器消息是 AEAD 加密的 — 攻击者看到密文和 Kyber CT 但无法派生 shared_secret）。 - 恶意文件替换（通过 Dilithium 签名和审计链来防御）。 **此设计防御的内容** - 机密性：文件内容和私钥在静态和传输中加密。 - 完整性/真实性：Dilithium 签名用于交易和签名审计日志。 - 会话的前向安全性：Kyber 每会话 KEM。 **局限性 / 我们不声称的内容** - 此演示未经生产环境加固：密钥备份、HSM/TPM 集成、网络 TLS（mTLS/QUIC）、强化认证和正式审计*对于生产环境是必需的*。请参阅[生产路线图](/pqbank.git cd pqbank # 2. ensure Cargo.toml uses stable versions (no -rc) # (the repo already contains a tested Cargo.toml) # 3. clean then build cargo clean cargo build --release # 4. run (GUI) # Linux / macOS ./target/release/pqbank # Windows (PowerShell) .\target\release\pqbank.exe ``` 启动时： - GUI 打开 - 后台服务器线程启动并在 `127.0.0.1:40000` 上监听 - 存储目录 `./storage/` 会自动创建 ## 如何测试与示例输入 ### 1. 创建钱包（钱包管理器） - 钱包名称：`demo_wallet` - 密码：`Test@4!` *（公开仓库使用虚拟数据）* ### 2. 解锁钱包 - 使用相同密码解密；GUI 显示 Dilithium 公钥（b64）和 Kyber 公钥（b64）。 ### 3. 发送交易 - 金额：`2500` - 收款人：`ACC5566778899` - 点击**发送交易** — 序列： - GETPK → 封装 → 签名 → 发送 - 服务器解封装 → 验证签名 → 存储信封 → 写入签名审计块 ### 4. 上传示例文件 - 创建 `receipt.csv`： ``` time,desc,amount 2025-12-10 14:32,NEFT,4500 ``` - 点击**选择并发送文件** → 选择 `receipt.csv`。 ### 5. 验证日志 - 打开**审计日志** → 点击**验证链**。应报告链完整性正常并列出操作。 ## 示例数据格式 **交易 JSON** ``` { "amount": 2500, "currency": "INR", "sender": "sumit_demo", "receiver": "ACC5566778899", "timestamp": "2025-12-10T14:32:12+05:30" } ``` **加密信封（存储在服务器上）— 概念性** ``` { "id": "file-uuid", "nonce": "", "ciphertext": "", "signature": "", "signer_pubkey": "", "meta": { "filename": "receipt.csv", "uploaded_at": "..." } } ``` ## 开发者 notes — 如何扩展到生产环境（审查者路线图） 招聘人员阅读此内容会希望您了解差距。建议的路线图： 1. **将本地服务器线程替换为 axum/quinn 服务器**（双向认证 + QUIC）。 2. **HSM / TPM**：将服务器私钥移入硬件密钥库（TPM 密封密钥或云 KMS）。 3. **认证层**：用户的 OAuth2 / OpenID Connect；为 Web 客户端集成 CSRF/XSRF 保护。 4. **持久数据库**：元数据的 Postgres；Blob 的对象存储（S3）。使用信封加密；仅存储密文。 5. **TLS / mTLS + 加固网络**：应用 DDoS 防护、速率限制、TLS 证书轮换。 6. **CI/CD + SCA**：运行 cargo audit、clippy、fmt、单元测试、模糊测试。 7. **第三方密码学审计 + 形式化验证**在任何真实资金之前。 8. **密钥轮换与备份**策略 + 紧急恢复的安全托管。 ## 常见问题解答与故障排除 **问：在 Windows 上看到与 `winapi` 或 `eframe` 相关的构建错误** **答：** 确保 `Cargo.toml` 固定 `eframe = "0.24.1"` 并包含启用 `"winapi"` 功能的 `winapi` 覆盖（仓库提供了经过测试的 `Cargo.toml`）。先运行 `cargo clean` 然后 `cargo build`。 **问：为什么在本地存储服务器密钥？** **答：** 这是演示。生产环境中使用 HSM 或 KMS。 **问：这是否已准备好用于生产？** **答：** 否，它演示了设计和实现模式。生产环境需要审计、HSM、加固认证和部署。 ## 贡献 / 行为准则 欢迎贡献！如果您贡献： - 为您更改的任何密码学/网络代码添加测试 - 保持私钥不在提交中 - 遵循 Rustfmt 和 Clippy 建议 ## 许可证 **MIT 许可证** — 参见 `LICENSE` 全文。

标签：AEAD, Argon2id, CVE, Dilithium, eframe, egui, HKDF, Kyber, Lattice-Based Cryptography, NIST PQC标准, PQC, Quantum-Resistant, Rust, XChaCha20-Poly1305, 可视化界面, 后量子密码学, 安全存储, 审计链, 密码学演示, 密钥交换, 密钥封装机制, 操作系统检测, 数字签名, 格密码学, 混合加密, 网络流量审计, 蓝队防御, 通知系统, 量子抗性, 钱包管理, 防篡改