AIOSchema .NET: Zero Dependencies by Design ◈︎


Document ID	AS-ART-DOTNET-001
Date	June 10, 2026
Category	Technical
License	CC-BY 4.0

Abstract

The AIOSchema .NET implementation ships as a single C# library with a dependency graph of exactly zero. No external NuGet packages. No third-party cryptographic libraries.

Instead, SHA-256, SHA-384, Ed25519 signing, JCS canonical JSON, and UUID v7 generation are all implemented directly against System.Security.Cryptography and the standard .NET 8 Base Class Library (BCL). This wasn’t a packaging shortcut - it was a deliberate architectural choice. When your entire job is establishing data provenance and trust, your code shouldn’t force users to blindly trust a web of external dependencies. Here is why we built it this way, and exactly what it took to get there.

1. The Real Cost of `dotnet add package`

Every NuGet package you pull into a project is a trust decision. Usually, that is a fair trade-off for speed. But when you are building a cryptographic provenance library - where the entire goal is to prove an asset is authentic and unaltered - dependencies introduce a structural contradiction.

It is incredibly tempting to pull in excellent, well-maintained libraries like Bouncy Castle or NSec to handle complex curve cryptography. They are fantastic projects. But “credible” is not the same as “zero attack surface.” Every external line of code introduces:

A supply-chain dependency on an external package registry.
Risk exposure to dependency confusion or typosquatting attacks.
A transitive dependency graph you did not write and cannot fully audit.
An update cadence that may diverge from your own release cycle.

If a library promises to guarantee integrity to its users, it should not rely on an external chain of custody it cannot verify with that same level of rigour. By cutting the cord to external packages entirely, the .NET AIOSchema implementation ensures the trust boundary ends exactly where your application code begins.

2. Zero Dependencies in Practice

The .csproj targets .NET 8+ and references absolutely nothing outside the standard BCL. The core footprint relies strictly on:

System.Security.Cryptography - hashing (SHA-256/384) and HMAC.
System.Text.Json - structural parsing and output.
System.Text.Encoding - deterministic UTF-8 manipulation.

Everything else is written from scratch.

UUID v7 - required for time-ordered, globally unique asset_id generation - is implemented in Uuid7.cs using DateTimeOffset.UtcNow and RandomNumberGenerator. Twelve lines of code. No package required. (.NET 9 added Guid.CreateVersion7() natively, but targeting .NET 8 without a dependency meant writing our own.)

JCS canonical JSON (RFC 8785) - the deterministic serialisation required for core_fingerprint computation - lives in Algorithms.cs as a recursive, key-sorted serialiser. Regardless of how a JSON object is laid out in memory, it always serialises to the exact same byte sequence. This is the same algorithm used by all six AIOSchema reference implementations, and it is cross-verified against 18 deterministic vectors shared across Python, TypeScript, Node.js, Go, Rust, and .NET.

3. The Hard Part: Pure Ed25519 in C#

The honest challenge of a zero-dependency constraint is handling Ed25519 curve arithmetic without wrapping native binaries like libsodium via P/Invoke or pulling in Bouncy Castle.

To prevent timing side-channel attacks, the twisted Edwards curve arithmetic - defined over the prime field p = 2²⁵⁵ - 19 - must run in strict constant time. The implementation in Ed25519.cs achieves this using 64-bit limb arithmetic and a Montgomery ladder algorithm for scalar multiplication.

Following RFC 8032, the signing path generates nonces deterministically from the private key and message, producing a 64-byte signature. The verification path reconstructs the expected group element and compares it to the supplied signature point in constant time.

Writing custom curve arithmetic is demanding work. But Ed25519 is exceptionally well-documented, and the RFC 8032 test vectors are definitive. The result is an entire cryptographic engine auditable in a single afternoon from a single file. No wrappers. No abstraction layers. No external surface.

4. Cross-Verification: Mathematical Trust

Claiming a dependency-free crypto library is one thing. Proving it interoperates correctly with the rest of the world is another.

The .NET implementation passes all 18 cross-verification vectors (CV-01 through CV-18) and all 68 unit tests covering TV-01 through TV-24 - the complete mandatory conformance suite for AIOSchema v0.5.6. A manifest signed by the Python implementation verifies correctly under .NET, and vice versa, with no coordination beyond the shared specification.

For engineers operating in regulated environments - healthcare data pipelines, fintech, media authentication - this replaces vendor trust with mathematical trust. Auditors do not need to map a sprawling tree of transitive packages. The entire compliance boundary lives inside a single repository, reviewable end to end.

5. Get Started

Install from NuGet or clone directly from the monorepo. The footprint is identical either way: pure, auditable C#.

dotnet add package AIOSchema

Then generate and verify your first manifest:

using AIOSchema;

// 1. Generate a signed Level 2 manifest
var manifest = Generator.GenerateManifest("document.pdf", new ManifestOptions {
    PrivateKey = yourEd25519PrivateKeyBytes
});

// 2. Verify asset integrity
var result = Verifier.Verify("document.pdf", manifest);

Console.WriteLine($"Compliance Level: {result.ComplianceLevel}");
Console.WriteLine($"Verification Success: {result.Success}");

Full API reference, project structure, and the complete test suite are documented at /implementations/dotnet/. The source is in the aioschema/aioschema monorepo under implementations/dotnet/.

For the compliance implications of zero-dependency cryptographic implementations in regulated environments, see our EU AI Act Art. 50 position paper.