siriuslee69/Tyr-Crypto

GitHub: siriuslee69/Tyr-Crypto

面向 Nim 语言的实验性加密工具包,整合多后端并支持后量子与经典算法的混合密钥交换和签名模式。

Stars: 0 | Forks: 0

# Tyr-Crypto 此工作区中同级仓库的实验性 Nim 加密工具包。 ## 警告 本仓库**不保证已达到生产就绪状态**。 - 它包含自定义加密结构和纯 Nim 实现,在获得更深入的审查和外部验证之前,应将其视为实验性的。 - 本仓库明确是 **vibecoded** 的实验性加密代码。请预期存在粗糙的边缘、API 变更以及仍需深入审查的地方。 - 提供**不附带任何种类的担保或保证**。 - 如果您需要加固的生产级加密,请优先选择经过充分审查的上游库和经过审计的协议设计。 ## 本仓库负责的内容 - 可选加密后端周围的可复用 Nim 封装器 - 工作区使用的纯 Nim 辅助原语 - 基于 password/PIN 的密钥派生和封装辅助工具 - 分块文件加密和哈希辅助工具 - 后端元数据和算法注册辅助工具 - 可选本地依赖项的构建辅助工具 ## 本仓库不负责的内容 - 应用程序的协议定义 - 证书生命周期或信任策略 - 网络传输/会话编排 - 用户/账户存储 - 本仓库本地封装器之外的密钥管理基础设施 ## 主要状态类型 - `EncryptionState` - 位于 `src/tyr_crypto/wrapper/crypto.nim` 的封装器级对称加密状态 - `CipherText` - 封装器密文及认证材料 - `Key` - 位于 `src/tyr_crypto/wrapper/pin_key.nim` 的 password/PIN 派生封装状态 - `DerivedEncryptionKeys` - 派生的对称状态及 KDF 元数据 - `ChunkyOptions` 和 `ChunkyManifest` - 分块文件处理配置和输出清单 - `SignatureKeypair` - 用于经典、PQ 和混合签名模式的封装器级签名密钥对 ## 主要编排器 - `encrypt` / `decrypt` - 对称消息加密的高级封装器入口点 - `deriveSymmetricKeysFromBytesWithSalt` / `deriveSymmetricKeysFromString` - password 到封装器状态的派生 - `deriveMasterKey`, `wrapMasterKeyWithPin`, `unwrapMasterKeyWithPin` - password/PIN 密钥生命周期 - `encryptFileChunks`, `decryptFileChunks`, `hashFileChunks` - 大文件分块处理 - `createHybridKexOffer`, `respondHybridKexOffer`, `finalizeHybridKex` - 混合 PQ/经典 KEX 辅助工具 - `createKyberX25519KexOffer`, `createMcElieceX25519KexOffer` - 具有枚举选择 PQ 变体的双重混合 KEX 辅助工具 - `signatureKeypair`, `signMessage`, `verifyMessage` - Ed25519、PQ 签名和混合签名的统一签名 API ## 循环入口点 - `updateBlake3` / `finalBlake3` - 流式哈希更新 - `runEncryptTasks` / `runDecryptTasks` - 分块工作线程循环 - `encryptChunkTask`, `decryptChunkTask`, `hashChunkTask` - 每分块文件处理循环 ## 布局 - `src/tyr_crypto/common.nim` - 共享错误类型和辅助模板 - `src/tyr_crypto/random.nim` - 操作系统随机性及可选的额外熵混合 - `src/tyr_crypto/registry.nim` - 支持的算法和提供者的元数据 - `src/tyr_crypto/wrapper/` - 高级加密、PIN/KDF、签名和混合 KEX API - `src/tyr_crypto/custom_crypto/` - 纯 Nim 和面向 SIMD 的加密辅助工具 - `src/tyr_crypto/chunkyCrypto/` - 分块文件加密和哈希 - `src/tyr_crypto/bindings/` - 可选的本地绑定 - `tools/` - 本地依赖项构建辅助工具 - `tests/` - 向量、回归和封装器测试 - `iron/` - 仓库协调元数据 ## 快速开始 ### 基础构建和测试 ``` nimble test nim check src/tyr_crypto/registry.nim ``` ### 启用可选后端 ``` nimble build -d:hasLibsodium -d:hasLibOqs -d:hasOpenSSL3 -d:hasNimcrypto -d:hasBlake3 ``` 如果后端在编译时被排除或运行时缺失,封装器将引发 `LibraryUnavailableError` 而不是静默失败。 ### 本地构建器任务 ``` nimble build_libsodium nimble build_liboqs nimble build_openssl ``` 这些任务需要相关的子模块和可工作的本地构建工具链。在 Windows 上,这通常意味着 MSYS2 风格的环境以及标准的 C/C++ 构建工具。 ### 完整的本地后端测试运行 ``` nimble build_libsodium nimble build_liboqs nimble build_openssl nimble test_all ``` `nimble test_all` 是本地后端套件的路径,预期在启用 `libsodium`、`liboqs` 和 OpenSSL 的情况下运行。 如果您使用的是子模块本地构建而不是系统安装的库,可能需要使用环境变量(如 `LIBSODIUM_SOURCE`、`LIBSODIUM_LIB_DIRS`、`LIBOQS_SOURCE`、`LIBOQS_LIB_DIRS`、`OPENSSL_SOURCE` 和 `OPENSSL_LIB_DIRS`)将加载器指向它们。 ## 示例 ### 1. 对称封装器 API ``` import tyr_crypto/wrapper/crypto let state = EncryptionState( algoType: chacha20, keys: @[Key(key: newSeqWith(32, 0x11'u8), keyType: isSym)], nonce: newSeqWith(24, 0x22'u8) ) let msg = @[byte 1, 2, 3, 4] let cipher = encrypt(msg, state) let plain = decrypt(cipher, state) doAssert plain == msg ``` ### 2. 密码派生状态 ``` import tyr_crypto/wrapper/pin_key import tyr_crypto/wrapper/crypto when defined(hasLibsodium): let derived = deriveSymmetricKeysFromString(xchacha20Gimli, "correct horse", @[], 0'u16) let cipher = encrypt(@[byte 7, 8, 9], derived.state) doAssert decrypt(cipher, derived.state) == @[byte 7, 8, 9] ``` ### 3. 分块文件加密 ``` import tyr_crypto/chunkyCrypto import tyr_crypto/wrapper/pin_key import tyr_crypto/wrapper/crypto when defined(hasLibsodium): let derived = deriveSymmetricKeysFromString(xchacha20AesGimli, "file-passphrase", @[], 64'u16) var opt = initChunkyOptions() opt.chunkBytes = 64 * 1024 opt.bufferBytes = 4096 let manifest = encryptFileChunks("input.bin", "chunks", derived.state, opt) decryptFileChunks(manifest, "chunks", "output.bin", derived.state, opt) ``` ### 4. 枚举驱动的混合 KEX ``` import tyr_crypto when defined(hasLibsodium) and defined(hasLibOqs): let duo = createMcElieceX25519KexOffer(mvClassicMcEliece6960119) let (duoResp, duoSharedB) = respondMcElieceX25519KexOffer(duo.offer) let duoSharedA = finalizeMcElieceX25519Kex(duo, duoResp) doAssert duoSharedA == duoSharedB let triple = createHybridKexOffer(kvKyber1024, mvClassicMcEliece8192128) let (tripleResp, tripleSharedB) = respondHybridKexOffer(triple.offer) let tripleSharedA = finalizeHybridKex(triple, tripleResp) doAssert tripleSharedA == tripleSharedB ``` ### 5. 具有调用者提供熵的混合 KEX ``` import tyr_crypto when defined(hasLibsodium) and defined(hasLibOqs): let userEntropy = "mouse-jitter|keypress-latency|request=42" let state = createKyberX25519KexOfferWithEntropy( kvKyber768, userEntropy ) let (resp, sharedB) = respondKyberX25519KexOfferWithEntropy( state.offer, "server-timing|request=42" ) let sharedA = finalizeKyberX25519Kex(state, resp) doAssert sharedA == sharedB ``` 这些辅助工具通过作用域内的混合 RNG 路径为 liboqs KEM 操作提供输入,该路径混合了: - 普通的支持 OS 的安全随机源 - 调用者提供的字节,例如用户交互或本地事件计时 - 用作额外多样化的本地进程/计时上下文 ### 6. 混合签名 ``` import tyr_crypto when defined(hasLibsodium) and defined(hasLibOqs): let kp = signatureKeypair(saEd25519Falcon512Hybrid) let msg = @[byte 1, 2, 3, 4] let sig = signMessage(saEd25519Falcon512Hybrid, msg, kp.secretKey) doAssert verifyMessage(saEd25519Falcon512Hybrid, msg, sig, kp.publicKey) ``` ## 自定义封装器组合 - `chacha20` - 封装器流模式,目前实现为 `xchacha20Xor(...)` 加上带密钥的 BLAKE3 标签 - `xchacha20Gimli` - `XChaCha20 -> Gimli stream -> Gimli tag` - `aesGimli` - `AES-CTR -> Gimli stream -> Gimli tag` - `xchacha20AesGimli` - `XChaCha20 -> AES-CTR -> Gimli stream -> Gimli tag` - `xchacha20AesGimliPoly1305` - `XChaCha20 -> AES-CTR -> Gimli stream -> (Gimli tag || Poly1305 tag)` - `aes256` - 通过 Nimcrypto 后端的 AES-256-GCM 这些封装器名称是特定于仓库的结构,不是标准化的 AEAD 名称。请将密文和标签布局视为特定于实现且对版本敏感的。 ## 混合封装器表面 - `createKyberX25519KexOffer*` / `respondKyberX25519KexOffer*` - `Kyber + X25519` - `createMcElieceX25519KexOffer*` / `respondMcElieceX25519KexOffer*` - `Classic McEliece + X25519` - `createHybridKexOffer*` / `respondHybridKexOffer*` - `Kyber + Classic McEliece + X25519` - `*WithEntropy` KEX 辅助工具 - 通过作用域 liboqs RNG 回调混合 OS 随机性、调用者提供的熵字节和本地计时/进程上下文 - `saEd25519Falcon512Hybrid` / `saEd25519Falcon1024Hybrid` - 生成并验证 Ed25519 和 Falcon 两部分 ## 当前加密表面 - 对称封装器模式 - `chacha20` - `xchacha20Gimli` - `aesGimli` - `xchacha20AesGimli` - `xchacha20AesGimliPoly1305` - `aes256` - 混合 KEX 模式 - `Kyber + X25519`,使用 `kvKyber768` 或 `kvKyber1024` - `Classic McEliece + X25519`,使用 `mvClassicMcEliece6688128`、`mvClassicMcEliece6960119` 或 `mvClassicMcEliece8192128` - `Kyber + Classic McEliece + X25519`,使用枚举选择的 Kyber 和 McEliece 变体 - 混合签名模式 - `saEd25519Falcon512Hybrid` - `saEd25519Falcon1024Hybrid` - 混合签名需要经典和 PQ 两部分都通过验证 ## 本地和磁盘边界 - 本地运行时边界 - `libsodium`、`liboqs` 和 OpenSSL 是可选的动态/本地依赖项 - 磁盘边界 - `blake3HashFile` - `encryptFileChunks` - `decryptFileChunks` - `hashFileChunks` - 仓库本地构建边界 - `tools/build_libsodium.nim` - `tools/build_liboqs.nim` - `tools/build_openssl.nim` ## 安全说明 - 封装器 `chacha20` 模式现在使用带密钥的 BLAKE3 标签,而不是直接哈希 `key || nonce || ciphertext`。 - AES-256-GCM 封装器现在使用认证解密,而不是解密后比较。 - PIN 封装现在默认对新密钥使用基于 Argon2id 的派生。 - 早于存储 PIN KDF 参数的旧封装密钥仍保留旧版解封回退路径。 - 混合 liboqs KEM 调用不再仅依赖 liboqs 默认 RNG 路径;封装器现在安装作用域混合熵回调,并公开用于调用者提供材料的 `*WithEntropy` 辅助工具。 - liboqs RNG 钩子是进程全局的,因此那些混合熵 KEM 部分在密钥生成/封装运行时使用锁进行序列化。 - `otp.nim` 公开自定义确定性 OTP 风格辅助工具。它**不是** RFC HOTP/TOTP 互操作性层,不应假设与验证器应用程序兼容。 - `custom_crypto/` 中的几个模块首先是实现实验,其次是兼容性表面。 ## 许可 - 本仓库中的原始 Tyr-Crypto 代码根据 `Unlicense` 发布。 - 完整文本请参见 `LICENSE`,依赖摘要请参见 `THIRD_PARTY_LICENSES.md`。 - 检出的子模块保留其上游许可,**不会**被 Tyr-Crypto 重新许可。 - 当前观察到的顶层子模块许可: - `libsodium`: ISC - `liboqs`: MIT,源码树内有针对每个文件夹的第三方例外 - `OpenSSL`: Apache-2.0 - 检出的 `submodules/openssl/` 树还包含具有额外许可的嵌套辅助和测试仓库,包括 GPL/LGPL 组件,如 `tlsfuzzer` 和 `tlslite-ng`。 - 本摘要仅用于仓库维护和署名。这不构成法律建议。 ## 常用命令 ``` nimble test nimble test_all nimble test_all_threads_on nimble test_all_threads_off nimble test_gimli nimble test_blake3_simd nimble perf_sigma ``` ## 问题排查手册 - `LibraryUnavailableError` - 您在编译时未使用匹配的 `-d:has*` 标志,或者运行时本地库不可用。 - `nimble test` 通过但本地后端仍未验证 - 默认套件也测试回退路径。当您需要特定后端验证时,请使用相关标志和已安装的库进行编译。 - 分块哈希目前是串行的,即使加密/解密使用工作线程 - 目前这是有意为之。之前的 ORC/ARC 线程哈希路径在 seq 负载上遇到了所有权损坏,因此正确性优先于并行性。 - 构建器任务在 Windows 上失败 - 检查子模块是否存在,以及是否安装了上游项目预期的本地工具链。 - OTP 输出与外部 TOTP 应用不匹配 - 预期行为。`otp` 模块是自定义的,不是直接可替换的 RFC 4226/6238 实现。 ## 开发说明 在更改行为之前,请阅读 [CONTRIBUTING.md](./CONTRIBUTING.md)。安全报告指南位于 [SECURITY.md](./SECURITY.md)。依赖项的许可说明位于 [THIRD_PARTY_LICENSES.md](./THIRD_PARTY_LICENSES.md)。 ## 约定摘要 - 保持函数简短并组合辅助工具,而不是深度嵌套。 - 在 proc 的顶部附近声明 `var`/`let` 块。 - 保留 `src/tyr_crypto/` 下基于级别的模块布局。 - 优先选择显式运行时错误,而不是静默回退行为。 - 每当加密行为、文件格式或后端接线发生变化时,添加或更新测试。 - 当公共行为或仓库结构发生变化时更新文档。
标签:CVE, DNS 反向解析, KDF, Nim 语言, PBKDF, StruQ, 分块加密, 加密包装器, 加密工具包, 后量子密码, 哈希算法, 安全测试工具, 实验性代码, 密码学, 密钥派生, 对称加密, 开发库, 手动系统调用, 数字签名, 文件加密, 本地密钥管理, 混合签名, 纯 Nim 实现, 自动化审计, 防御绕过, 零依赖