CryptoHives .NET Foundation

Welcome to the CryptoHives .NET Foundation documentation.

Overview

CryptoHives .NET Foundation is a set of libraries for .NET applications, covering high-performance memory management, async threading primitives, and cryptographic algorithms.

.NET is a solid platform for building secure, high-performance applications, but two gaps keep showing up: high-performance patterns rarely get packaged as simple, drop-in libraries, and cryptography still leans heavily on whatever the underlying OS happens to provide — with all the inconsistency in features and performance that brings. These libraries exist to close both gaps, one package at a time. None of this replaces the .NET class library; it complements it.

Ecosystem

The initiative currently includes four packages:

  • Threading — async synchronization primitives built for low/no allocation and high throughput, using ValueTask-based waiters backed by pooled resources
  • Memory — buffer management on top of ArrayPool<T> and the modern .NET memory APIs, for transformation pipelines and crypto workloads that work in terms of ReadOnlySpan or IBufferWriter
  • Cryptography — OS-independent reimplementations of System.Security.Cryptography algorithms, usable as drop-in replacements
  • Threading.Analyzers — the optional CHT0xx Roslyn rules that catch ValueTask misuse at compile time

Available Packages

Memory Package

Buffer management utilities that lean on ArrayPool<T> and modern .NET memory APIs to keep GC pressure out of transformation pipelines and cryptographic workloads.

Key features:

  • ArrayPoolMemoryStream and ArrayPoolBufferWriter<T>, both backed by ArrayPool<byte>.Shared
  • SequenceLease<T> carries a ReadOnlySequence<T> together with the producer that owns it, so a payload can leave the scope that built it with no copy and no allocation
  • The buffer writer is itself poolable, and ArrayPoolBufferWriterProvider<T> keeps many settings profiles on a single shared pool
  • ISegmentOwner<T> and ISequenceOwner<T> — ownership contracts for ArraySegment<T> and ReadOnlySequence<T>, with pooled, GC-managed and empty strategies behind each
  • ReadOnlySequenceMemoryStream for streaming from an existing ReadOnlySequence<byte>
  • ObjectPool-backed resource management helpers, and PoolFactory for pooling types this package does not reference
  • Opt-in clearArray on every type that owns pooled memory, for callers holding key material

Explore the Memory package →

Threading Package

Async synchronization primitives built for low allocation and high throughput.

Key features:

  • All waiters are ValueTask-based synchronization primitives, designed around low memory allocation
  • An optional Roslyn analyzer package that catches common ValueTask misuse at compile time
  • Full CancellationToken support across every wait/lock primitive
  • IValueTaskSource<T>-based implementations backed by ObjectPool<T>, so waiter objects get recycled instead of allocated
  • Optional timeout on every acquisition, with a timer allocated only once a call actually has to wait
  • AsyncLock for async mutual exclusion, with scoped locking via the IDisposable pattern
  • AsyncKeyedLock<TKey> for per-key exclusion, where unrelated keys never block each other
  • AsyncAutoResetEvent and AsyncManualResetEvent, complementing the existing Task-based equivalents
  • AsyncBarrier as an async-aware replacement for the .NET barrier
  • Pooled AsyncReaderWriterLock, AsyncSemaphore, and AsyncCountdownEvent, all with async wait support
  • AsyncConditionVariable for "wait until condition" semantics paired with an AsyncLock
  • AsyncExchange<T> for a two-party value rendezvous
  • Fast-path optimizations for the uncontended case
  • No-allocation design for hot-path code and cancellation tokens (see Benchmarks)

Explore the Threading package →

Security.Cryptography Package

Specification-based implementations of hash algorithms, MACs, ciphers, key derivation functions and post-quantum key encapsulation, all fully managed and OS-independent.

Key features:

  • SHA-1, SHA-2, SHA-3 families, all validated against full test vectors
  • SHAKE and cSHAKE extendable-output functions (XOF) for variable-length output
  • TurboSHAKE and KangarooTwelve (KT128/KT256), the high-performance XOFs
  • KMAC (Keccak Message Authentication Code) for authenticated hashing
  • ParallelHash (SP 800-185), with an incremental variant for streaming input
  • Ascon lightweight hashing and AEAD (NIST SP 800-232) for constrained environments
  • BLAKE2b, BLAKE2s, and BLAKE3, with keyed modes
  • Keccak-256/384/512 for Ethereum compatibility
  • Regional standards: SM3 (China), Streebog/GOST (Russia), Kupyna/DSTU (Ukraine), LSH/KS (Korea), Whirlpool (ISO)
  • Legacy algorithms MD5, SHA-1, RIPEMD-160, kept for compatibility only
  • AES-CBC, AES-GCM, AES-CCM, ChaCha20, ChaCha20-Poly1305, XChaCha20-Poly1305, and Ascon-AEAD128 ciphers
  • Regional block ciphers: SM4, ARIA, Camellia, Kuznyechik, Kalyna, SEED
  • Key derivation: HKDF, KBKDF, Concat KDF, PBKDF2, BLAKE3 DeriveKey
  • MACs: HMAC, AES-CMAC, AES-GMAC, Poly1305, KMAC, BLAKE2/3 keyed
  • AES Key Wrap with Padding (RFC 3394/5649)
  • ML-KEM-512/768/1024 (FIPS 203) post-quantum key encapsulation, mirroring the .NET 10 MLKem API shape — and always supported, since nothing here depends on Windows CNG or OpenSSL
  • Cross-platform consistency with no dependency on OS crypto APIs

Explore the Security.Cryptography package →

Usage Examples

using CryptoHives.Foundation.Security.Cryptography.Hash;

// Allocation-free hash
using var blake3 = Blake3.Create();
Span<byte> hash = stackalloc byte[32];
blake3.TryComputeHash(data, hash, out _);

// XOF streaming (variable-length output)
using var shake = Shake256.Create(64);
shake.Absorb(data1);
shake.Absorb(data2);
Span<byte> output = stackalloc byte[128];
shake.Squeeze(output);

using CryptoHives.Foundation.Threading.Async.Pooled;

// Allocation-free async lock, even with a cancellation token
private readonly AsyncLock _lock = new();

public async Task DoWorkAsync(CancellationToken ct)
{
    using (await _lock.LockAsync(ct).ConfigureAwait(false))
    {
        // critical section
    }
}

// Non-blocking attempt — no exception, no ValueTask on a miss
public void DoWorkIfIdle()
{
    if (_lock.TryLock(out var releaser))
    {
        using (releaser)
        {
            // critical section
        }
    }
}

How It's Built

  • Specification-first cryptography. Implementations are written directly from public specifications (NIST, RFC, ISO) rather than ported from other codebases, and every algorithm is checked against the official test vectors from its specification, then cross-validated against independent reference implementations.
  • No steady-state allocations. Every package targets high throughput with no per-operation heap allocations, for both transformation pipelines and cryptographic workloads.
  • SIMD with a scalar fallback. Where it helps, algorithms use managed hardware intrinsics (AES-NI, PCLMULQDQ, SSE/SSSE3, AVX2, NEON) and fall back to portable scalar code everywhere else, so behaviour stays identical across platforms and runtimes.
  • Orthogonal by design. Packages stand on their own — none depends on another, and dependencies outside CryptoHives are kept minimal and limited to widely adopted libraries.
  • Measured, not asserted. Performance and memory use are benchmarked against the reference implementations people actually use, and every recorded run is published.

Benchmarks

Both the Threading and the Cryptography package are measured with BenchmarkDotNet against the reference implementations people actually use — the OS-provided algorithms, BouncyCastle, Nito.AsyncEx, Microsoft.VisualStudio.Threading and others — and every recorded run is published.

The results are browsable rather than pasted into a table: each page embeds an interactive dashboard that loads the run history as a small SQLite database in your browser, with no server involved. It offers three views — one run reproduced as a table, with a second run comparable against it; a trend over time per commit; and a scaling curve over data size or contention level. Every point names the commit, the .NET runtime and the reference library version it was measured against, so a step in a line can be attributed rather than guessed at.

  • Threading benchmarks — contended and uncontended acquisition across the async primitives, per-waiter allocation included
  • Cryptography benchmarks — hash, cipher and MAC throughput across data sizes, including the separate SIMD paths, plus per-instance memory footprint tables

Runs are archived per commit and per machine, so results measured on any contributor's hardware can appear side by side rather than only those from a fixed set of CI hosts.

Platform Support

  • .NET 10.0
  • .NET 8.0
  • .NET Framework 4.6.2
  • .NET Standard 2.1
  • .NET Standard 2.0

Resources

License

This project is licensed under the MIT License. See the LICENSE file for details.

Impressum (Legal Notice)

© 2026 The Keepers of the CryptoHives

Edit this page