valkyoth/nornvefr

绑定到授权未来的加密。
一种安全优先、no_std 优先的协议，用于处理受身份、策略、状态、分支、守护者和限定范围能力管理的加密数据。

# nornvefr `nornvefr` 是一个安全优先的 Rust 工作区，用于实现一种称为*世界线加密* (worldline encryption) 的新型加密对象与授权模型。 普通加密通常回答： Nornvefr 旨在回答一个更完整的问题： 本项目并未发明用于替代现有分组密码、KEM、签名、哈希或 KDF 的方案。其预期贡献在于协议、规范对象格式、因果状态模型、守护者工作流、限定范围能力系统，以及围绕经过独立审查的密码学基础组件构建的公司信任模型。 ## 当前状态 状态：`v0.1.0` 基础版本已发布；`v0.2.0` 发布证据强化是下一个实现里程碑。 该仓库目前确立了在开始密码学实现之前所需的 crate 边界和工程规则。首个真正可用于生产环境的 CLI 和 SDK 计划通过经过安全审查的、特意细分的小版本迭代，在 `v1.0.0` 实现。 目前已实现： - Rust 工作区锁定至稳定版 `1.97.0`，edition 2024，resolver 3。 - EUPL-1.2 项目许可。 - 专注于 `no_std` 的协议 crate，零第三方生产环境依赖。 - 项目自有的 Rust 代码使用 `#![forbid(unsafe_code)]`。 - 不透明的 object、branch、identity 和 company 标识符脚手架，拒绝全零哨兵值。 - 协议版本和有界对象大小基础。 - 故障关闭 (Fail-closed) 的对象前导码验证，涵盖 magic、保留标志位和长度边界。 - 编译时的 KEM 和签名验证器 provider trait，暂无具体的密码学实现。 - 默认拒绝 (Deny-by-default) 的策略词汇表。 - 分支状态词汇表，被撤销或被取代的分支无法推进。 - 最小化 CLI 脚手架，包含 `--version`、`--help`、`self-test` 和 `doctor`。 - 在本地或 CI 检查中支持 Linux、Windows、macOS、BSD、Android、iOS、WebAssembly 和嵌入式构建边界。 - Cargo deny、RustSec audit、不可变的 GitHub Action 锁定版本、Dependabot 以及 CodeQL 默认配置策略。 - 涵盖安全、威胁模型、模块化、平台、工具链、unsafe 代码、供应链、实现、SDK 和发布规划的文档。 - 打标签前的渗透测试工作流，绝不伪造 PASS 报告。 - 非生成的 Rust 源文件硬性限制为 500 行。 尚未实现： - 无 identity 密钥生成或私钥存储。 - 无 ML-KEM、ML-DSA、SLH-DSA、AEAD、哈希、KDF 或密码 KDF provider。 - 无规范加密对象编码器或解码器。 - 无文件封装或开启。 - 无接收者信封或发送者签名。 - 无结构化加密组件。 - 无策略语言或策略评估器。 - 无签名事件、状态转换或分支持久化。 - 无守护者阈值共享或能力组装。 - 无 authority、witness、audit 或 guardian 服务。 - 无 company 配置、成员资格、设备、角色或分类。 - 无本地 key agent 或操作系统密钥存储集成。 - 尚未发布 `nornvefr-sdk` crate。 - 无 GUI。 - 不对任何操作系统声明提供生产环境支持。 从此基础到 `v1.0.0` 的详细路线图定义于[发布计划](docs/RELEASE_PLAN.md)中。 ## 信任仪表板 | 领域 | 当前状态 | | --- | --- | | 许可证 | `EUPL-1.2` | | 锁定的 Rust 版本 | `1.97.0` | | Edition / resolver | Rust 2024 / Cargo resolver 3 | | 默认库目标 | `no_std` | | 生产环境第三方依赖 | 无 | | Unsafe 策略 | 项目自有 Rust 禁止 unsafe 代码 | | 网络、签名器和密钥存储默认值 | 无 | | 具体密码学实现 | 未实现 | | 文件加密 | 未实现 | | 发布证据 | 本地门控、cargo-deny、cargo-audit、发布说明、渗透测试交接 | | CodeQL | GitHub 默认配置；无高级工作流 | | SDK | 计划从 `v0.12.1` 起与 CLI 同步开发 | | 1.0 目标 | 生产可用的 CLI 和 crates.io `nornvefr-sdk` | ## Nornvefr 旨在提供什么 ### 静态接收者模式 普通的离线场景： ``` nornvefr seal report.pdf --recipient alice.nvi --output report.pdf.nve nornvefr open report.pdf.nve --output report.pdf ``` 将经过身份验证的、包含授权组件密钥的有界数据包封装给接收者 identity。它不会暴露可推导的全局祖先密钥。 此模式可离线工作，但在接收者收到对象或缓存其密钥后，无法诚实地承诺撤销。 ### 治理模式 选定的组件或子树密钥受限定范围的 gate key 和守护者阈值保护。治理模式绝不会发布全局 object/master 密钥，从而防止推导出未经授权的组件。接收者请求 capability 时，必须明确指定精确的 object、branch、类型化的 state/key/policy/guardian/ 成员资格 epoch 或版本、用途、路径、操作、设备以及时间窗口。一个规范的 `ObjectAuthorizationDigest` 用于标识经过精确身份验证的对象状态。Guardian 在各自的信任边界内保留持久化的共享份额，并为一次完全相同的共同批准联合生成绑定到 transcript 的部分输出；来自不同请求的输出无法被自定义 assembler 累积。最终化过程仅产生加密到请求密钥的限定范围组件密钥包，而非持久的 gate secret。 v1 设计允许每个规范会话描述符对应一次非交互式 guardian 响应，没有在线的 guardian 间通信或通用的多轮 MPC 接口。该单轮限制适用于阈值参与者；在授权控制平面上，可能存在单独绑定到配置文件的 guardian 对 authority 的 CAS 或 commit-lease 调用。每个 guardian 都会根据经过身份验证的策略验证完整的参与者集合以及所有安全/资源参数。输出会绑定精确的 gate-ciphertext 输入，并且响应在暴露之前会被持久化提交，以便在崩溃后重试时实现字节级一致。在进入不可取消的 provider 之前，一个原子计算许可会预留有限的工作器、内存、工作量、RNG/签名使用、存储、有效性和公平性容量。基础组件套件、阈值发布配置文件和复合协议配置文件具有各自不可变的 ID；阈值配置文件还固定了其 commit-control 和 query-accounting 拓扑，且缺失绝不会静默地成为 provider。激活和确定性收据的密码学基础组件/模式属于基础组件套件；阈值配置文件仅绑定其允许的构造、角色、密钥范围和拓扑使用。如果 `v0.25.2` 无法接入符合此配置文件且经过审查的完整 PQ 阈值加激活构造，则生产环境的 `v1.0.0` 将被阻塞；它不会静默地变成纯静态发布版本。 激活具有明确的非循环 transcript 位置。输出前的激活策略/密钥 epoch 进入阈值操作输入；在非激活准备完成后，激活声明会在签名核心之前绑定该输入、准备好的输出摘要、承诺和验证器参数。在提交之前，每个 guardian 要求在一个经过身份验证的类型化授权快照、已批准的 `CommonApprovalDigest` 以及最终的 CAS 或规范签名租约之间保持精确的连续性。如果策略、状态、参与者策略或检查点发生更改，即使旧策略仍会评估为允许，旧会话也会失败。签名的响应核心在 authority 租约发布之前被持久存储，但它仅包含密码学上未激活的准备输出。即使核心明文及其存储密钥被盗，在有效的提交证据中收到精确绑定响应的激活之前，它们也无法用于阈值组装。最终响应是一个确定性的无签名容器，包含该核心以及恰好一个外部可验证的证据变体：经过身份验证的本地 CAS 收据或 authority 租约。 不可恢复的提交后损坏将变为终止状态 `CommittedUnavailable`：配额保持已消耗，且响应永远不会被重新计算或重新签名。Authority 的预订和提交是两阶段的，并且在整个网络重试中保持幂等。并置的 CAS 对原子持久化的收据正文使用单一的确定性收据签名，允许在崩溃后实现字节级一致的提交后具体化。持久化的有效签名会被重用；新的具体化会进行自我验证、受到严格限制，即使发生故障也会被持久计数，且绝不切换到替换密钥。CAS 收据证明的是签名者的责任，而不是独立的原子存储执行。签名者在常规操作期间仅接受密封的已提交状态句柄，而提取密钥泄露被视为独立事件，可能会绕过接口限制。如果激活独立于收据/租约签名，它将拥有自己持久的 pending/started/indeterminate 状态。 即使交付不确定，提交也是不可逆的发布点：随后的撤销可以阻止新的响应，但无法撤回已提交的部分输出。随机会话 ID 在共享 epoch 命名空间内具有一个完整的描述符含义，查询限制不能通过新的 ID 或重叠的参与者集进行翻倍，经过身份验证的有限配额加上精确可搜索的回滚安全压缩索引可防止持久命名空间耗尽，同时不会丢失重放/冲突、计算使用、签名使用、准备的核心或待处理收据历史记录。公开证据使用不透明的记账句柄，而不是原始序号或内部序列。 过期的响应无法再从 guardian 检索，永远不会被重新计算，并留下持久的墓碑记录和查询记账状态；恢复的响应除了存储身份验证外，还必须通过 guardian、标记的提交证据、历史密钥、配置文件和上下文验证。 阈值 provider 保持纯粹的 `no_std` 密码学实现。会话协调、持久存储、配置文件密封的提交控制、authority 传输以及授权的时间/新鲜度证据仍是具有明确密钥所有权的独立内部边界。在进入 provider 之前会检查取消操作；一旦在活动的计算许可下开始执行带有密钥的密码学操作，它将在允许的边界内不可取消地运行至完成。在调用之前，guardian 会持久记录 `ProviderExecutionStarted`、调用身份、已消耗的密码学预算以及回滚状态。任何不确定的标记后结果都会变为终止状态，且无法重新运行；执行期间的过期会消耗工作量，但会阻止后续激活。Provider 返回会在单独标记的 guardian 签名调用之前持久化一个未签名的核心；签名会进行自我验证，并且签名或激活的不确定性会导致终止状态且不进行重试。所有必需的密钥 epoch 都在进入 provider 之前被锁定，有序的退役需等待精确的待定状态普查，而妥协截止是立即生效的。准入队列和保留的准备核心仍受到严格限制。嵌套的 guardian transcript 和持久状态转换遵循经过机器检查的类型化无环依赖图，其声明的边完全匹配规范构造函数和密封的转换 API；操作输入摘要先于完整的会话描述符摘要。 声明具备 guardian 独立性的配置文件必须满足跨类型化、重叠轴（如运营商、云、区域、备份管理员和 root/控制密钥）的提交约束，包括声明的相关闭包。仅凭真实的域标签是不够的。 ``` Encrypted object | Capability request | Policy + state checks | Guardian approvals | Scoped capability | Authorized components ``` 任何 guardian 批准、事件、阈值部分输出或已发布的 capability 都不得转移到另一个 object、branch、类型化的 epoch/版本、请求、用途、company 或设备——即使接收者忽略官方 SDK 并编写自定义 assembler。一旦可导出的组件密钥到达不受信任的接收者，密码学路径分离仍然可以防止同级或祖先推导，但操作、用途、设备、时间、使用次数、接收者不可转移性和进一步共享限制无法再附加到该复制的密钥上。持续执行需要指定的不可导出 agent、HSM 或可信硬件边界。 ### 托管状态模式 authority 和只追加状态日志提供最新的分支状态、密钥发布前的撤销、原子性的一次性 capability 消耗、签名检查点以及 witness 辅助的拆分视图检测。 此模式无法让某人忘记已经发布的明文。 ### 结构化对象模式 Nornvefr 对象可以包含独立加密的组件，例如： ``` /document /pricing /audit /executive-notes /recovery ``` v1 对象不使用压缩。隐式、自动检测带标志的压缩表示将被拒绝；有限且经过身份验证的按组件压缩有其独立的 1.0 后版本。 针对 `/document` 的 capability 绝不能接收 `/recovery` 的密钥。 Nornvefr 无法安全地推断任意现有文件内的语义部分。必须由创建者或其他可信进程定义组件边界。 ## Company 模式 `--company` 旨在选择一个已签名的密码学信任域，而不是添加一个装饰性的公司名称。 ``` nornvefr seal contract.pdf \ --company valkyoth \ --recipient northcorp/alice \ --classification restricted ``` Company 配置可以强制执行： - 受信任的根和组织 authority； - 批准的套件和最低安全底线； - 签名的策略版本和分类； - guardian 集合和阈值； - 当前的成员资格和设备注册； - 状态检查点的新鲜度； - capability 生命周期和用途要求； - 强制审计和元数据隐私； - 禁止对敏感分类使用静态加密。 CLI 参数、本地别名或未来的 GUI 绝不能削弱这些规则。诸如 `valkyoth` 之类的别名只是为了方便；密码学 company ID 和签名的 company 配置才是权威。 ## SDK 与未来 GUI `nornvefr-sdk` 计划作为公开的 crates.io 包发布，与 CLI 同步开发。 ``` nornvefr CLI -----+ Future GUI -------+--> nornvefr-sdk --> protocol and host crates Other Rust tools -+ ``` CLI 将解析用户输入，调用类型化的 SDK 工作流，并渲染结果。它不能维护单独的策略或协议行为实现。 SDK 将支持： - 用于工具和未来 GUI 的直接进程内 Rust 工作流； - 注入的存储、时间、随机性、网络和密钥操作边界； - 类型化的请求、结果、进度、取消和安全错误； - 使用带有版本的 JSON 和稳定退出类别的可选已安装二进制客户端。 二进制客户端不会调用 shell，也不会将密钥放置在参数或环境变量中。它将使用显式的可执行文件、受保护的管道或 key agent、有限的输出、超时、取消、schema 检查以及版本/能力协商。 参见 [SDK 架构](docs/SDK_ARCHITECTURE.md)。 ## 工作区结构 当前的 crate： | Crate | 职责 | `no_std` | | --- | --- | --- | | `nornvefr-core` | 标识符、边界、版本和共享错误 | 是 | | `nornvefr-format` | 格式 magic、`PrimitiveSuiteId` 和前导码验证 | 是 | | `nornvefr-crypto` | 故障关闭的密码学 provider trait | 是 | | `nornvefr-policy` | 有界授权决策词汇表 | 是 | | `nornvefr-state` | 分支状态和转换词汇表 | 是 | | `nornvefr` | 公共门面库和宿主 CLI 脚手架 | 仅库 | 计划中的专注型 crate 包括编码、object、identity、company、capability、guardian、日志、审计、存储、平台、网络、服务、测试套件、`nornvefr-sanitization` 以及 `nornvefr-sdk` 的边界。密钥内存处理将仅通过该专注边界使用项目自有的 `sanitization` crate；不引入 `zeroize`。 主 crate 保持为协调器。核心 crate 不依赖于 CLI、文件系统、网络、服务、数据库、操作系统或 GUI crate。 ## 安装 Nornvefr 尚未发布到 crates.io，且没有可用的加密发布版本。针对基础开发，请从此仓库构建： ``` git clone https://github.com/valkyoth/nornvefr.git cd nornvefr rustup show cargo build --workspace cargo test --workspace ``` 不要在期待文件加密功能的情况下安装当前的 CLI。 在 `v1.0.0` 版本中，CLI 将通过签名的发布构件和操作系统仓库进行分发，而 `nornvefr-sdk` 将发布到 crates.io。CLI 本身不会发布到 crates.io。除非经过单独审查的发布明确接纳，否则内部 crate 将保持私有。 ## CLI 脚手架 当前可用的命令是有意限制的： ``` cargo run -p nornvefr -- --version cargo run -p nornvefr -- --help cargo run -p nornvefr -- self-test cargo run -p nornvefr -- doctor ``` 在此里程碑阶段预期的 `doctor` 状态： ``` status: research scaffold cryptography: unavailable safe for secrets: no ``` ## 平台策略 `no_std` 协议库旨在避免将 Nornvefr 锁定在桌面操作系统上。 架构和构建目标包括： - Linux； - Windows； - BSD； - macOS； - Android； - iOS； - WebAssembly； - 嵌入式/无操作系统环境； - 在未来的 Aesynx adapter 具备稳定的集成接口后提供的适配器。 构建检查不等同于完全的运行时支持。原生文件系统、权限、ACL、IPC、密钥存储、安装程序、服务、备份、恢复和集成证据均被指派了明确的 1.0 前里程碑。 参见 [平台支持](docs/PLATFORM_SUPPORT.md)。 ## 安全模型与非声明 Nornvefr 旨在受保护的密钥材料发布之前强制执行授权。它无法做到： - 撤销或擦除已经查看或复制的明文； - 删除攻击者持有的旧密文； - 在对象内容密钥被盗后恢复机密性； - 在可导出的组件密钥被复制到受信任的不可导出边界之外后，强制执行用途、操作、设备、时间、使用次数、不可转移性或进一步共享的限制； - 承受在一个 guardian 共享 epoch 期间阈值份额被累积破坏的情况，包括通过备份、快照、退役磁盘、崩溃转储或复制的 guardian 数据库； - 使持久化 Shamir 份额的加密导出变为请求绑定；v1 禁止该构造，因为份额可能会在不同的批准中被累积； - 向保留明文或组件密钥的 object 创建者/分发者隐藏它们； - 当证明颁发者串通或共同控制未被披露时，证明真实的域标签意味着 guardian 独立性； - 在发生灾难性的算法族破坏后修复已发布的签名或复制的密文；套件停用和迁移仅能限制未来的暴露风险； - 如果没有预先提交的独立家族恢复 root，则无法在操作签名失败后保持 identity/company 的连续性；否则恢复操作必须创建一个新的信任域； - 防止截图、拍照、记忆或受感染授权端点的恶意软件； - 在没有策略授权的证据颁发者的情况下证明雇佣关系、位置、法律地位、设备健康状况或时间； - 保证在每个平台或文件系统上实现安全删除； - 在其独立进行版本控制的研究版本发布之前，声称支持任意的函数式加密、通用见证加密、隐私策略证明或分布式密钥重置； - 承诺抵御未来任何经典或量子密码分析结果。 主要的 v1 公钥配置文件还记录了使用 ML-KEM 和 ML-DSA 的相关家族残余风险，因为这两者都依赖于模格假设。 禁止使用“牢不可破”、“抗量子”及类似的绝对声明词汇。 参见[范围与非声明](docs/SCOPE.md)和[威胁模型](docs/THREAT_MODEL.md)。 ## 发布规范 每个版本都有刻意缩小的实现范围，并在打标签之前设有明确的停止点： ``` vX.Y.Z implementation stop reached. Run pentest for this exact commit. ``` 活动的渗透测试结果暂时存放在根目录的 `PENTEST.md` 中。结果必须经过修复、回归测试、文档记录和重新测试，才能提交永久性的带版本 PASS 报告。常规 CI 不需要待定的报告，但最终的标签就绪检查需要。 没有任何常规的仓库脚本会创建或推送标签。 ## 检查 请使用 `rust-toolchain.toml` 中锁定的 Rust 工具链。 ``` scripts/checks.sh scripts/check_no_std.sh python3 scripts/release_crates.py --check cargo deny check cargo audit scripts/check_latest_tools.sh scripts/release_0_1_gate.sh ``` 主要的本地门控运行格式化、工作区检查、Clippy（警告视为错误）、测试、文档、发布策略测试、crates.io 计划验证、模块化强制执行、安全策略检查和文档存在性检查。发布规划器从不发布 `nornvefr` CLI。 ## 文档 - [架构](docs/ARCHITECTURE.md) - [实现计划](docs/IMPLEMENTATION_PLAN.md) - [发布计划](docs/RELEASE_PLAN.md) - [SDK 架构](docs/SDK_ARCHITECTURE.md) - [范围与非声明](docs/SCOPE.md) - [威胁模型](docs/THREAT_MODEL.md) - [安全控制](docs/SECURITY_CONTROLS.md) - [平台支持](docs/PLATFORM_SUPPORT.md) - [工具链策略](docs/TOOLCHAIN_POLICY.md) - [模块化策略](docs/MODULARITY_POLICY.md) - [Unsafe 策略](docs/UNSAFE_POLICY.md) - [供应链安全](docs/SUPPLY_CHAIN_SECURITY.md) - [GitHub 安全设置](docs/GITHUB_SECURITY_SETTINGS.md) - [安全策略](SECURITY.md) - [Nornvefr 0.1.0 发布说明](release-notes/RELEASE_NOTES_0.1.0.md) ## 安全报告 请勿打开包含可利用细节的公开 issue。请遵循 [SECURITY.md](SECURITY.md)，并在可用时使用仓库的私密报告渠道。 ## 许可证 Nornvefr 根据欧洲联盟公共许可证 (European Union Public Licence) 1.2 版 (`EUPL-1.2`) 获得许可。参见 [LICENSE](LICENSE)。

标签：AI工具, Rust, 加密协议, 可视化界面, 后量子加密, 密码学, 手动系统调用, 网络流量审计