Encryption bound to an authorized future.
A security-first, no_std-first protocol for encrypted data governed by identity, policy, state, branches, guardians, and scoped capabilities.

Release Plan | SDK Architecture | Threat Model | Security

nornvefr

nornvefr is a security-first Rust workspace for a new encrypted-object and authorization model called worldline encryption.

Ordinary encryption generally answers:

Does this person possess the correct private key?

Nornvefr is designed to answer a more complete question:

Does this exact identity or device have an authorized capability for this object, branch, exact state/key/policy/guardian/membership epochs or versions, purpose, operation, time, company policy, and current state—and were the required guardians satisfied?

The project does not invent a replacement for established block ciphers, KEMs, signatures, hashes, or KDFs. Its intended contribution is the protocol, canonical object format, causal state model, guardian workflow, scoped capability system, and company trust model built around independently reviewed cryptographic primitives.

Warning

Nornvefr is currently a research-stage foundation. It does not yet encrypt files and must not be used to protect secrets. No cryptographic, interoperability, revocation, or production-readiness claim applies yet.

Current Status

Status: v0.1.0 foundation released; v0.2.0 release-evidence hardening is the next implementation milestone.

The repository currently establishes the crate boundaries and engineering rules needed before cryptographic implementation begins. The first serious production-ready CLI and SDK are planned for v1.0.0 through deliberately small, security-reviewed releases.

Implemented now:

• Rust workspace pinned to stable 1.97.0, edition 2024, resolver 3.
• EUPL-1.2 project licensing.
• Focused no_std protocol crates with zero third-party production dependencies.
• Project-owned Rust uses #![forbid(unsafe_code)].
• Opaque object, branch, identity, and company identifier scaffolds that reject the all-zero sentinel.
• Protocol-version and bounded object-size foundations.
• Fail-closed object preamble validation for magic, reserved flags, and length bounds.
• Compile-time KEM and signature-verifier provider traits without a concrete cryptographic implementation.
• Deny-by-default policy vocabulary.
• Branch-state vocabulary where revoked or superseded branches cannot advance.
• Minimal CLI scaffold with --version, --help, self-test, and doctor.
• Linux, Windows, macOS, BSD, Android, iOS, WebAssembly, and embedded build boundaries in local or CI checks.
• Cargo deny, RustSec audit, immutable GitHub Action pins, Dependabot, and CodeQL default-setup policy.
• Security, threat-model, modularity, platform, toolchain, unsafe-code, supply-chain, implementation, SDK, and release planning documents.
• A pentest-before-tag workflow that does not fabricate a PASS report.
• A hard limit of 500 lines for non-generated Rust source files.

Not implemented yet:

• No identity key generation or private-key storage.
• No ML-KEM, ML-DSA, SLH-DSA, AEAD, hash, KDF, or password-KDF provider.
• No canonical encrypted-object encoder or decoder.
• No file sealing or opening.
• No recipient envelopes or sender signatures.
• No structured encrypted components.
• No policy language or policy evaluator.
• No signed events, state transitions, or branch persistence.
• No guardian threshold sharing or capability assembly.
• No authority, witness, audit, or guardian service.
• No company profiles, memberships, devices, roles, or classifications.
• No local key agent or operating-system key-store integration.
• No published nornvefr-sdk crate yet.
• No GUI.
• No production support claim for any operating system.

The detailed sequence from this foundation to v1.0.0 is defined in the release plan.

Trust Dashboard

Area	Current status
License	EUPL-1.2
Pinned Rust	1.97.0
Edition / resolver	Rust 2024 / Cargo resolver 3
Default library target	no_std
Production third-party dependencies	none
Unsafe policy	project-owned Rust forbids unsafe code
Network, signer, and key-store defaults	none
Concrete cryptography	not implemented
File encryption	not implemented
Release evidence	local gates, cargo-deny, cargo-audit, release notes, pentest handoff
CodeQL	GitHub default setup; no advanced workflow
SDK	planned side by side with CLI from v0.12.1
1.0 target	production-ready CLI and crates.io nornvefr-sdk

What Nornvefr Is Intended to Provide

Static recipient mode

The ordinary offline case:

nornvefr seal report.pdf --recipient alice.nvi --output report.pdf.nve
nornvefr open report.pdf.nve --output report.pdf

An authenticated bounded bundle of the authorized component secrets is wrapped to a recipient identity. It does not expose a derivable global ancestor key. This mode can work offline, but it cannot honestly promise revocation after the recipient has received the object or cached its keys.

Governed mode

Selected component or subtree secrets are protected behind scoped gate keys and a guardian threshold. Governed mode never releases a global object/master secret from which unauthorized components can be derived. A recipient requests a capability for an exact object, branch, typed state/key/policy/guardian/ membership epochs or versions, purpose, path, operation, device, and time window. One normative ObjectAuthorizationDigest identifies the exact authenticated object state. Guardians keep persistent shares inside their own trust boundaries and jointly produce transcript-bound partial outputs for one identical common approval; outputs from different requests cannot be accumulated by a custom assembler. Finalization yields only the scoped component-key bundle encrypted to the request key, not the persistent gate secret.

The v1 design permits one non-interactive guardian response per canonical session descriptor, with no online guardian-to-guardian or generic multi-round MPC interface. That one-round limit applies to threshold participants; a separately profile-bound guardian-to-authority CAS or commit-lease call may exist on the authorization control plane. Every guardian validates the full participant set and all security/resource parameters against authenticated policy. Outputs bind the exact gate-ciphertext input, and a response is durably committed before exposure so retries are byte-identical after a crash. Before non-cancellable provider entry, an atomic compute permit reserves bounded worker, memory, work, RNG/signature-use, sink-receipt and external-witness operations/evidence, storage, validity, deadline, and fairness capacity. Primitive suites, threshold-release profiles, and composite protocol profiles have separate immutable IDs; the threshold profile also fixes its commit-control and query-accounting topology, and absence never silently becomes a provider. Activation, deterministic CAS-receipt, and deterministic sink-persistence-receipt cryptographic primitives/modes plus role-separated witness artifact signatures belong to the primitive suite; the threshold profile binds only their admitted construction, roles, key scope, acceptance level, and topology use. If v0.25.2 cannot admit a reviewed complete PQ threshold-plus-activation construction meeting this profile, production v1.0.0 is blocked; it does not silently become a static-only release.

Activation has an explicit non-circular transcript position. A pre-output activation policy/key epoch enters the threshold-operation input; after inactive preparation, an activation statement binds that input, the prepared- output digest, commitment, and verifier parameters before the signed core.

Immediately before commitment, each guardian requires exact continuity between one authenticated typed authorization snapshot, the approved CommonApprovalDigest, and the final CAS or canonical signed lease. A changed policy, state, participant policy, or checkpoint fails the old session even when it would still evaluate to allow. The signed response core is durably stored before authority lease issuance, but contains only a cryptographically inactive prepared output. Even stolen core plaintext and its storage key cannot contribute to threshold assembly until exact response-bound activation exists. Signature-derived activation first exists with the evidence signature; separate-key activation is itself potential release before final lease packaging. The final response is a deterministic signature- free container of that core and exactly one externally verifiable evidence variant: an authenticated local CAS receipt or an authority lease. Irrecoverable post-commit corruption becomes terminal CommittedUnavailable: allowance remains consumed and the response is never recomputed or re-signed. Authority reservations and commits are two-phase and idempotent across network retries. Authority lease signing additionally atomically freezes the debit, authorization context, exact post-consumption root, anchor-coverage intent, and an unsigned lease skeleton. Verified coverage creates an anchor-covered skeleton, followed by one fresh atomic authorization/ time/cutoff/capacity revalidation. Signature-derived activation reaches conservative potential release/ OutputCommitted at LeaseSigningStarted; separate-key activation reaches it earlier at ActivationMaterializationStarted. Their handles bind only the anchor-covered skeleton. The post-anchor revalidation freshly verifies witness/ result reservations and proves expiry.checked_sub(release_now_upper) >= profile_worst_case_postcommit_recovery_margin. The bound includes trusted source time, monotonic elapsed time, and commit uncertainty through the atomic release point; the margin is derived from the profile recovery dependency DAG. The co-located CAS path uses topology-equivalent covered intent/body, revalidation, and atomic-start semantics. For both authority and co-located CAS, one atomic start transaction consumes the fresh revalidation, compares its snapshot/generation/fence with current state, consumes the reservation, records the start marker, and invalidates competitors before private-key entry. CAS uses its own uncovered intent and anchor-covered receipt body; debit freeze is not OutputCommitted. Separate-key CAS activation accepts only that covered body together with the consumed fresh revalidation and matching atomic-start result/fence; a legacy committed receipt record cannot authorize materialization. Separate mode adds only recovered activation before the signature; signature-derived mode adds only the signature and derives activation from it. CommitLeaseIssued means the self-verified byte-identical lease is durably available. Recovery retrieves the same attempt's cached result or enters CommittedUnavailable without invoking the key again. Co-located CAS uses one deterministic receipt signature over an atomically persisted receipt body, allowing byte- identical postcommit materialization after a crash. Persisted valid signatures are reused; new materializations are self-verified, strictly bounded, durably counted even when faulted, and never switch to a replacement key. A later receipt ordinal requires an explicitly retry-eligible prior terminal state and an open attempt family; compensation cancellation closes every issued, reserved, and future ordinal and atomically defeats allocation. The signer-side linearizable rollback-resistant family ledger is the sole ordinal/handle/ redemption/cancellation authority; controller records are caches, replicas need consensus or single-writer fencing, and an HSM without the ledger uses a fail- closed gateway inside the signer trust boundary. Generic retry is allowed only after the signer CASes AttemptStarted to FailedDefiniteNoKeyEntry; that outcome is mutually exclusive with KeyEntryAuthorized, which alone creates a single-use provider capability. Any uncertainty after authorization is terminal. External HSM ACLs admit only the current fenced authenticated gateway and registered operation; backends permitting gateway bypass are not retry- capable. Definite-no-entry evidence permits only a bounded next ordinal in the same open family; it never proves no release, cancels the family, restores debit/quota, or refunds that attempt's consumed capacity. A generated canonical signer-state registry owns exact internal states; public Started means only AttemptStarted | KeyEntryAuthorized and is never proof input. Signer-internal verification keeps invalid/faulted material inside the boundary and terminally quarantines the family/key epoch; post-key-entry retry requires a separately reviewed suite-specific fault profile whose ID/digest, or explicit no-recovery sentinel, is frozen across the suite, receipt body, family, handles, admission, capacity, and authorization before debit/start. A CAS receipt proves signer accountability, not independent atomic store execution. Signers accept only sealed committed-state handles during ordinary operation, while extracted-key compromise is treated separately and can bypass interface restrictions. In the ordinary profile, the receipt key alone can forge externally valid receipt evidence over a chosen body, but cannot forge the guardian-signed prepared core; stronger witness guarantees require a separate witness key/profile. If activation is separate from receipt/lease signatures, it has exactly one durable pending/started/materialized-or-terminal invocation. All signer/materializer handles bind one attempt, body, key, role/audience, authenticated controller and result sink, state generation, fence, and expiry and are redeemed once with durable replay accounting. Result retrieval requires independent sink authorization over a protected correlated channel; a stolen handle cannot receive the artifact. The pinned sink self-verifies and durably stores the result and returns a publicly verifiable signed ResultPersistedV1. The pinned controller always retrieves/self-verifies the bytes and builds the next typed object. Sink transport, result-encryption, persistence-receipt, storage-AEAD, and rollback-witness keys are separate roles. Remote and co-located sinks sign canonical ResultPersistedDigestV1 with the dedicated receipt key; MAC-only receipts are not admitted. Data durability is followed by sealed deterministic receipt- signing and same-attempt recovery; the compute permit reserves the bounded receipt count. The receipt signer returns directly to the authenticated sink over a correlated protected signer channel, never through SignerResultSink. Co-transactional witnesses may share the store transaction, while external witnesses use explicit anchoring/reconciliation and never claim cross-system atomicity. External anchoring requires canonical signed anchor/ status/conflict and the profile-selected promise/inclusion/checkpoint evidence; the public log leaf is a hiding commitment rather than private identifiers, and TLS status is insufficient. The sink freezes a receipt intent before anchoring; the anchor binds that intent and the final receipt binds the exact verified witness evidence. The witness durably grants capacity, atomically redeems it for the matching anchor, owns namespace-scoped sequence allocation, and recovers grants, anchors, checkpoints, and migration artifacts across crashes under distinct key roles and monotonic statuses. Verified evidence is tagged as co-transactional or external. Identified mode declares metadata visible to the witness; blinded mode sends only an opaque commitment and unlinkable quota capability, without fallback. Capacity is revalidated at release, and every postcommit operation consumes its recovery-DAG runtime budget. Ordinary-v1 live result bytes and their per-record key exist only until retrieval expiry, when access is denied and the key is erased across replicas/backups. Historical receipts, digests, mappings, anchors, and tombstones remain verifiable without reconstructing bytes. Sink service compromise, sink-key compromise, rollback/deletion, and signer-sink collusion have separate consequences; invalid or cross-attempt substitution still fails cryptographic verification and transcript correlation. Commitment is the irreversible release point even if delivery is uncertain: later revocation can stop new responses but cannot recall committed partial outputs. Under strict one-time/debit/quota/revocation profiles, however, a prepared output cannot become usable until accepted AnchorCoveredLedgerRootV1 evidence covers its exact post-consumption root. Coverage produces a typed anchor-covered lease skeleton, followed by a fresh atomic authorization/time/ cutoff/capacity check before signer or materializer entry; uncovered skeletons cannot authorize those operations. Batching may prepare but not release: sealed batches have immutable membership/roots, later writes form bounded successor batches, and each anchor kind supplies profile-tagged authenticated evidence. An anchor/local crash or post-anchor denial preserves consumption and never permits reissue. Compensation additionally requires authenticated terminal CancelledBeforeEntry evidence for every release-capable local/remote attempt. Cancellation and AttemptStarted are mutually exclusive atomic transitions from Unused; still-redeemable Unused, local absence, AttemptStarted, KeyEntryAuthorized, FailedDefiniteNoKeyEntry, Completed, Failed, Indeterminate, missing, or unavailable evidence forbids compensation. Compensation first enters CompensationPendingCoverage with one frozen successor root. External coverage reconciles separately into CompensationCovered, which grants no availability. A later local CAS freshly revalidates all mandatory registry/company/service floors and enters either RestorationPermitIssued or irreversible RestorationDeniedTerminal. Temporary freshness-authority uncertainty stays covered and retryable; authenticated mandatory-floor denial never becomes restorable after later relaxation. Issued permits end durably as redeemed, expired, or invalidated. Profiles releasing inside a nonzero anchor window state that they do not make the strict rollback-safe claim. Random session IDs have one complete-descriptor meaning within a sharing-epoch namespace, query limits cannot be multiplied by new IDs or overlapping participant sets, and authenticated finite quotas plus an exact searchable rollback-safe compaction index prevent durable namespace exhaustion without losing replay/collision, compute-use, signature-use, prepared-core, or pending-receipt history. Public evidence uses opaque accounting handles instead of raw ordinals or internal sequences. Every cryptographic ceiling preserves available + reserved + consumed + disabled = admitted ceiling; reserve, consume, safe reclaim, cutoff, retirement, and crash recovery are durable and idempotent, and uncertain work is never refunded. A covered conditional compensation credit remains a typed part of consumed, never available. Its body binds the predecessor but not its containing successor root; the successor commits the body digest, and an anchor-covered wrapper binds both. Successful final validation issues one server-side non-bearer AvailabilityRestoredPermitV1 from that wrapper. Redemption freshly checks the new authorization, current registry/floors, owner/company/namespace/class/ service/destination, validity, units, and fence, then atomically consumes permit and credit with byte-identical recovery. Client bytes, opaque references, raw roots, or coverage evidence cannot spend it; tightening invalidates an unredeemed ordinary-v1 permit. Unauthenticated, malformed, wrong-owner, out-of- scope, and stolen-reference redemption requests are rejected before victim lookup or mutation and consume only bounded abuse capacity. Admitted attempt IDs are server-owned and immutably bind the canonical authorized request; temporary failure preserves the same issued attempt. Ordinary authenticated policy denial invalidates by default, while retaining an issued permit requires a pre-bound reviewed profile with exact attempt, result-retention, and deadline limits. A retained denial keeps the main permit continuously RestorationPermitIssued while its bounded attempt moves from Pending to PolicyDeniedRetained and advances the attempt generation. Temporary failure leaves that same attempt pending; a terminal permit CAS closes every pending attempt as CompletedByPermitTerminal. Permit and attempt registries are generated together so no hidden issued cycle or terminal reopen can appear. One linearizable PermitAuthorityRecordV1 owns admission, budgets, generation, retained denial, and terminalization. Effective child state and byte-identical terminal results derive from that authenticated parent immediately; cross-shard child rows are only lazy idempotent projections and can never authorize work. Redeemed names the registered pending winner, its request/destination, and the exact reservation/spend transfer result. Parent, credit, destination, and result commit in one frozen accounting partition. Only the winner derives RedemptionSucceededV1; other pending children derive ClosedBySiblingRedemptionV1 without any usable success reference. Query/work allowance consumes at provider entry, release debit at authority/CAS debit freeze, and signer/materializer capacity at the atomic start marker; none is moved to a generic output-commit boundary. Each budget class also has a closed reclaim policy fixed by the effective protocol/company profile. Valid terminal cancellation/no-release evidence never grants refund by itself; NeverReclaim, profile authorization, state/fence, compensation authority, and successor coverage are enforced as applicable, and caller-selected or unknown policies fail closed. Every accounting record authenticates its original reclaim-policy/profile/ company-floor binding. Recovery intersects that immutable binding with the current supported-protocol registry and every mandatory company/service floor, which may restrict but never retroactively increase refundability. A rollback- resistant minimum-seen generation, authenticated continuity/freshness, and an observed-generation reclaim CAS prevent a valid old floor or restored backup from weakening recovery; stale offline evidence and missing historical verification material deny reclaim. Expired responses are no longer retrievable from guardians, are never recomputed, and leave durable tombstones and query-accounting state; recovered responses must pass guardian, tagged commit-evidence, historical-key, profile, and context verification in addition to storage authentication.

The threshold provider stays pure no_std cryptography. Session coordination, durable storage, profile-sealed commit control, authority transport, and authorized time/freshness evidence remain separate internal boundaries with explicit secret ownership. Cancellation is checked before provider entry; once secret-bearing cryptography begins under a live compute permit, it runs non-cancellably to completion within the admitted bounds. Before the call, the guardian durably records ProviderExecutionStarted, invocation identity, consumed cryptographic budgets, and rollback state. Any uncertain post-marker result becomes terminal and cannot rerun; expiry during execution consumes work but prevents later activation. Provider return persists an unsigned core before a separately marked guardian-signing call; the signature is self-verified, and signing or activation uncertainty is terminal without retry. All required key epochs are pinned before provider entry, orderly retirement waits for an exact pending- state census, and compromise cutoff is immediate. Admission queues and retained prepared cores remain strictly bounded. Nested guardian transcripts and durable state transitions follow a machine-checked typed acyclic dependency graph whose declared edges exactly match canonical constructors and sealed transition APIs; the operation-input digest precedes the complete session-descriptor digest.

Profiles that claim guardian independence must satisfy committed constraints across typed, overlapping axes such as operator, cloud, region, backup administrator, and root/control key, including declared correlation closure. Authentic domain labels alone are not enough.

Encrypted object
      |
Capability request
      |
Policy + state checks
      |
Guardian approvals
      |
Scoped capability
      |
Authorized components

No guardian approval, event, threshold partial output, or issued capability may transfer to another object, branch, typed epoch/version, request, purpose, company, or device—even when the recipient ignores the official SDK and writes a custom assembler. After an exportable component key reaches an untrusted recipient, cryptographic path separation still prevents sibling or ancestor derivation, but operation, purpose, device, time, use-count, recipient non- transferability, and onward-sharing limits cannot remain attached to that copied key. Continued enforcement requires a named non-exporting agent, HSM, or trusted-hardware boundary.

Managed state mode

An authority and append-only state log provide fresh branch state, revocation before key release, atomic one-time capability consumption, signed checkpoints, and witness-assisted split-view detection.

This mode cannot make someone forget plaintext that was already released.

Structured object mode

A Nornvefr object can contain independently encrypted components such as:

/document
/pricing
/audit
/executive-notes
/recovery

v1 objects do not use compression. Implicit, auto-detected, or flagged compressed representations are rejected; bounded authenticated per-component compression has its own post-1.0 version.

A capability for /document must not receive the key for /recovery.

Nornvefr cannot safely infer semantic sections inside an arbitrary existing file. The creator or another trusted process must define the component boundaries.

Company Mode

--company is intended to select a signed cryptographic trust domain, not add a decorative company name.

nornvefr seal contract.pdf \
    --company valkyoth \
    --recipient northcorp/alice \
    --classification restricted

A company profile can enforce:

• trusted roots and organizational authorities;
• approved suites and minimum security floors;
• signed policy versions and classifications;
• guardian sets and thresholds;
• current memberships and device registration;
• state-checkpoint freshness;
• capability lifetime and purpose requirements;
• mandatory audit and metadata privacy;
• prohibition of static encryption for sensitive classifications.

CLI arguments, local aliases, or a future GUI must not weaken these rules. Aliases such as valkyoth are conveniences; the cryptographic company ID and signed company profile are the authority.

Security floors are compared per axis, not as one universal strength number; privacy, retention, audit, diversity, witness, and availability requirements may be incomparable, in which case Nornvefr denies. Every remote service verifies only its role-minimized authenticated enforcement projection instead of trusting an SDK/CLI-supplied effective plan. A blinded witness verifies an issuer-attested opaque projection rather than hidden company/session metadata. Device-local claims require signed agent or admitted attestation evidence, and user intent can only restrict a request.

SDK and Future GUI

nornvefr-sdk is planned as a public crates.io package developed side by side with the CLI.

nornvefr CLI -----+
Future GUI -------+--> nornvefr-sdk --> protocol and host crates
Other Rust tools -+

The CLI will parse user input, call typed SDK workflows, and render results. It must not maintain a separate implementation of policy or protocol behavior.

The row-generic SDK/CLI surface remains a candidate while production workflow rows are implemented one at a time. Unimplemented admitted rows return a typed unavailable result; future/forbidden rows are not exposed. The public API, JSON, process-client, and crates.io surface becomes interface-complete only after every v1 production row is implementation-conformant, security-frozen after platform/formal/fuzz/audit/pentest closure, and stable at v1.0.0.

The SDK will support:

• direct in-process Rust workflows for tools and a future GUI;
• injected storage, time, randomness, network, and key-operation boundaries;
• typed requests, results, progress, cancellation, and safe errors;
• an optional installed-binary client using versioned JSON and stable exit classes.

The binary client will not invoke a shell or place secrets in arguments or environment variables. It will use an explicit executable, protected pipes or the key agent, bounded output, timeouts, cancellation, schema checks, and version/capability negotiation.

See SDK Architecture.

Workspace Shape

Current crates:

Crate	Responsibility	no_std
nornvefr-core	identifiers, bounds, versions, and shared errors	yes
nornvefr-format	format magic, PrimitiveSuiteId, and preamble validation	yes
nornvefr-crypto	fail-closed cryptographic provider traits	yes
nornvefr-policy	bounded authorization-decision vocabulary	yes
nornvefr-state	branch status and transition vocabulary	yes
nornvefr	public facade library and host CLI scaffold	library only

Planned focused crates include encoding, object, identity, company, capability, guardian, log, audit, storage, platform, networking, services, testkit, nornvefr-sanitization, and nornvefr-sdk boundaries. Secret-memory handling will use the project-owned sanitization crate only through that focused boundary; zeroize is not admitted.

The main crate remains an orchestrator. Core crates do not depend on CLI, filesystem, network, service, database, operating-system, or GUI crates.

Install

Nornvefr is not published to crates.io and has no usable encryption release yet. For foundation development, build from this repository:

git clone https://github.com/valkyoth/nornvefr.git
cd nornvefr
rustup show
cargo build --workspace
cargo test --workspace

Do not install the current CLI expecting file-encryption functionality.

At v1.0.0, the CLI is distributed through signed release artifacts and operating-system repositories, while nornvefr-sdk is published to crates.io. The CLI itself is not published to crates.io. Internal crates remain private unless a separate reviewed release explicitly admits them.

CLI Scaffold

The currently available commands are intentionally limited:

cargo run -p nornvefr -- --version
cargo run -p nornvefr -- --help
cargo run -p nornvefr -- self-test
cargo run -p nornvefr -- doctor

Expected doctor status at this milestone:

status: research scaffold
cryptography: unavailable
safe for secrets: no

Platform Policy

The no_std protocol libraries are designed not to lock Nornvefr to a desktop operating system.

Architecture and build targets include:

• Linux;
• Windows;
• BSD;
• macOS;
• Android;
• iOS;
• WebAssembly;
• embedded/no-OS environments;
• a future Aesynx adapter after its stable integration interfaces exist.

Build checks are not equivalent to full runtime support. Native filesystem, permissions, ACL, IPC, key-store, installer, service, backup, recovery, and integration evidence is assigned explicit pre-1.0 milestones.

See Platform Support.

Security Model and Non-Claims

Nornvefr is designed to enforce authorization before protected key material is released. It cannot:

• revoke or erase plaintext already seen or copied;
• delete old ciphertext held by an attacker;
• restore confidentiality after an object content secret was stolen;
• enforce purpose, operation, device, time, use-count, non-transferability, or onward-sharing limits after an exportable component key is copied outside a trusted non-exporting boundary;
• withstand threshold shares being compromised cumulatively during one guardian sharing epoch, including through backups, snapshots, retired disks, crash dumps, or copied guardian databases;
• make encrypted export of persistent Shamir shares request-bound; v1 forbids that construction because shares could be accumulated across approvals;
• hide plaintext or component secrets from an object creator/dealer that retained them;
• prove real-world guardian independence from authentic domain labels when attestation issuers collude or common control is undisclosed;
• repair already-issued signatures or copied ciphertext after a catastrophic algorithm-family break; suite sunset and migration limit future exposure;
• preserve identity/company continuity after operational-signature failure without a precommitted independent-family recovery root; otherwise recovery must create a new trust domain;
• prevent screenshots, photography, memory, or authorized endpoint malware;
• prove employment, location, legal status, device health, or time without a policy-authorized evidence issuer;
• guarantee secure deletion on every platform or filesystem;
• claim arbitrary functional encryption, general witness encryption, private policy proofs, or distributed rekey before their separately versioned research releases;
• promise to resist every future classical or quantum cryptanalytic result.

The primary v1 public-key profile also records the correlated-family residual risk of using ML-KEM and ML-DSA, which both rely on module-lattice assumptions.

Terms such as “unbreakable”, “quantum-proof”, and equivalent absolute claims are prohibited.

See Scope and Non-Claims and the Threat Model.

Release Discipline

Every version has a deliberately narrow implementation scope and a clean stop before tagging:

vX.Y.Z implementation stop reached.
Run pentest for this exact commit.

Active pentest findings live temporarily in root PENTEST.md. Findings must be fixed, regression-tested, documented, and retested before a permanent versioned PASS report is committed. Normal CI does not require a still-pending report, but the final tag-readiness gate does.

No normal repository script creates or pushes a tag.

Checks

Use the pinned Rust toolchain from rust-toolchain.toml.

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

The main local gate runs formatting, workspace checks, Clippy with warnings denied, tests, documentation, release-policy tests, crates.io plan validation, modularity enforcement, security-policy checks, and documentation-presence checks. The release planner never publishes the nornvefr CLI.

Documentation

• Architecture
• Implementation Plan
• Release Plan
• SDK Architecture
• Scope and Non-Claims
• Threat Model
• Security Controls
• Platform Support
• Toolchain Policy
• Modularity Policy
• Unsafe Policy
• Supply-Chain Security
• GitHub Security Settings
• Security Policy
• Nornvefr 0.1.0 Release Notes

Security Reports

Do not open a public issue containing exploitable details. Follow SECURITY.md and use the repository's private reporting channel when available.

License

Nornvefr is licensed under the European Union Public Licence, version 1.2 (EUPL-1.2). See LICENSE.