🛡️ CryptoHives Open Source Initiative 🐝
An open, community-driven collection of cryptography and performance libraries for the .NET ecosystem.
.NET is a solid platform for building secure, high-performance applications across almost any target, 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.
CryptoHives exist to close both gaps, one package at a time.
The CryptoHives Open Source Initiative is maintained by The Keepers of the CryptoHives and is currently addressing three areas:
- 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, meant to keep GC pressure out of transformation pipelines and crypto workloads
- Cryptography — OS-independent implementations for a wide range of cryptographic algorithms, usable as drop-in replacement for
System.Security.Cryptography
📚 Documentation
🐝 Available CryptoHives
📦 Nuget Packages
| Package | Description | NuGet | Documentation |
|---|
Memory | Pooled buffers and streams | | Docs |
Threading | Pooled async synchronization | | Docs |
Threading.Analyzers | Analyzer for pooled async synchronization | | Docs |
Security.Cryptography | Cryptographic algorithms | | Docs |
All packages are published under the CryptoHives.Foundation prefix and namespace — see CryptoHives on NuGet for the full list.
🩺 Health
🏗️ Architecture Overview
┌─────────────────────────────────────────────────────────────────────────────────┐
│ CryptoHives .NET Foundation │
│ CryptoHives Open Source Initiative │
└─────────────────────────────────────────────────────────────────────────────────┘
│
┌───────────────────────────┼────────────────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────────┐ ┌───────────────────────┐ ┌────────────────────────────┐
│ Memory │ │ Threading │ │ Security.Cryptography │
├────────────────────┤ ├───────────────────────┤ ├────────────────────────────┤
│ ArrayPool- │ │ AsyncLock │ │ Hash │
│ MemoryStream │ │ AsyncKeyedLock<TKey> │ │ SHA-2 · SHA-3 │
│ ArrayPool- │ │ AsyncSemaphore │ │ SHAKE · cSHAKE │
│ BufferWriter<T> │ │ AsyncAutoResetEvent │ │ TurboSHAKE · KT128/256 │
│ ReadOnlySequence- │ │ AsyncManualResetEvent │ │ ParallelHash (SP 800-185) │
│ MemoryStream │ │ AsyncReaderWriterLock │ │ KMAC128 · KMAC256 │
│ ISegmentOwner<T> │ │ AsyncBarrier │ │ Keccak · BLAKE2 · BLAKE3 │
│ PooledSegment │ │ AsyncCountdownEvent │ │ Ascon · Regional · Legacy │
│ AllocatedSegment │ │ AsyncConditionVariable│ │ │
│ EmptySegment │ │ AsyncExchange<T> │ │ MAC │
│ │ │ │ │ HMAC · KMAC │
│ SequenceLease<T> │ │ IValueTaskSource<T> │ │ AES-CMAC · AES-GMAC │
│ ISequenceOwner<T> │ │ backed by │ │ Poly1305 · BLAKE2/3 │
│ PoolFactory │ │ ObjectPool<T> │ │ │
│ ObjectOwner<T> │ │ │ │ Cipher │
│ │ ├───────────────────────┤ │ AES-GCM/CCM (AEAD) │
│ │ │ Threading.Analyzers │ │ ChaCha20-Poly1305 │
│ │ │ ValueTask Roslyn │ │ XChaCha20-Poly1305 │
│ │ │ analyzers │ │ Ascon-AEAD128 │
└────────────────────┘ └───────────────────────┘ │ AES-128/192/256 │
│ ChaCha20 (stream) │
│ SM4 · ARIA · Camellia │
│ Kuznyechik · Kalyna │
│ SEED │
│ │
│ Key Derivation │
│ HKDF · KBKDF │
│ ConcatKDF · PBKDF2 │
│ │
│ Post-Quantum │
│ ML-KEM (FIPS 203) │
│ ML-DSA (FIPS 204) │
│ SLH-DSA (FIPS 205) │
│ PKCS#8 · SPKI · PEM │
└────────────────────────────┘
Keccak class hierarchy (Security.Cryptography):
HashAlgorithm
└── KeccakCore (Keccak-p[1600] sponge, AVX2/SSSE3/scalar dispatch)
├── KeccakHashCore (fixed-length)
│ ├── SHA3_{224,256,384,512}
│ └── Keccak{256,384,512} (Ethereum-compatible, domain sep 0x01)
├── KeccakXofCore : IExtendableOutput (variable-length)
│ ├── Shake{128,256} (domain sep 0x1F, rate 168/136 bytes)
│ ├── TurboShake{128,256} (12-round Keccak, domain sep 0x7F/0x7E)
│ └── KT{128,256} (KangarooTwelve tree-hashing XOF)
└── CShake{128,256} : IExtendableOutput (bytepad prefix, domain sep 0x04)
ParallelHash (static, NIST SP 800-185)
per-block inner hash ─── Shake{128,256}
finalization ─── CShake{128,256} (N="ParallelHash", S=user)
IncrementalParallelHash (streaming wrapper, buffers input until Squeeze)
🧠 Buffer Pools (Memory)
Pooled buffer management for transformation pipelines and high-frequency I/O:
ArrayPoolMemoryStream — drop-in MemoryStream replacement backed by ArrayPool<byte>, with ReadOnlySequence handoff supportReadOnlySequenceMemoryStream — reads a ReadOnlySequence<byte> as a MemoryStream without copyingArrayPoolBufferWriter<T> — IBufferWriter<T> over pooled arrays, e.g. for Utf8JsonWriter; the writer itself is poolable, and ArrayPoolBufferWriterProvider<T> keeps many settings profiles on one shared poolSequenceLease<T> — a readonly struct carrying a ReadOnlySequence<T> plus the producer that owns it, so a payload can leave the scope that built it with no copy and no allocationPoolFactory — builds an object pool from a factory and a reset delegate, including for types this package does not referenceISegmentOwner<T> — ownership contract for ArraySegment<T> with three built-in strategies:
PooledSegment<T> — rents from ArrayPool<T>.Shared, returns on disposeAllocatedSegment<T> — wraps a GC-managed T[], no pool lifecycleEmptySegment<T> — zero-allocation null-object sentinel
ISequenceOwner<T> — the same contract for ReadOnlySequence<T>, with SegmentSequence<T> and EmptySequence<T>
Every type that owns pooled memory takes a clearArray flag, so buffers holding key material are zeroed on their way back to the pool.
🧵 Concurrency Tools (Threading)
Async-compatible synchronization primitives built on ObjectPool and ValueTask<T>, designed to keep Task / TaskCompletionSource<T> allocations off the hot path.
AsyncLock — mutual exclusionAsyncKeyedLock<TKey> — per-key mutual exclusionAsyncSemaphore — counting semaphoreAsyncAutoResetEvent / AsyncManualResetEventAsyncReaderWriterLockAsyncBarrier / AsyncCountdownEventAsyncConditionVariable — pairs with AsyncLock for "wait until condition" semanticsAsyncExchange<T> — two-party value rendezvous
All primitives support CancellationToken and ConfigureAwait(false) without extra allocations, timeout support via TimeProvider (an ITimer is only allocated once there's actual contention).
New in 0.7: synchronous non-blocking attempts — TryLock / TryWait / TryReaderLock / TryUpgradeableReaderLock / TryWriterLock / Releaser.TryUpgradeToWriterLock — that return false on a miss instead of throwing.
A Roslyn analyzer that catches common ValueTask usage mistakes ships as a standalone package.
⏱️ Async primitive benchmarks — contested and uncontested scenarios, pooled ValueTask vs. the BCL and the async libraries people actually use: Nito.AsyncEx, ProtoPromise, Microsoft.VisualStudio.Threading, NeoSmart.AsyncLock, DotNext.Threading, and the keyed-lock libraries.
🔐 Managed Code Cryptography (Security.Cryptography)
Fully managed hash, MAC, cipher, KDF and post-quantum KEM and signature implementations, written from NIST/RFC/ISO specifications and checked against official test vectors.
No OS crypto dependency, so results are deterministic on every platform. Where the hardware supports it, AES-NI, PCLMULQDQ/VPCLMULQDQ, SSE2, SSSE3, AVX2 and AVX-512 on x86/x64,
and ARM AES, ARM SHA-1/SHA-2, PMULL and NEON on Arm64, kick in automatically — in some cases outperforming the OS-provided implementation.
Algorithms:
| Family | Algorithms |
|---|
| SHA-2 | SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256 |
| SHA-3 | SHA3-224, SHA3-256, SHA3-384, SHA3-512 |
| Keccak | Keccak-256, Keccak-384, Keccak-512 (Ethereum compatible) |
| SHAKE / cSHAKE | SHAKE128, SHAKE256, cSHAKE128, cSHAKE256 |
| ParallelHash (SP 800-185) | ParallelHash128, ParallelHash256 |
| TurboSHAKE / KT | TurboSHAKE128, TurboSHAKE256, KT128, KT256 |
| BLAKE | BLAKE2b, BLAKE2s, BLAKE3 (all SIMD-accelerated) |
| Ascon | Ascon-Hash256, Ascon-XOF128 (NIST SP 800-232 lightweight) |
| MAC | HMAC-SHA-256/384/512, HMAC-SHA3-256, AES-CMAC, AES-GMAC, Poly1305, KMAC128, KMAC256, BLAKE2 keyed, BLAKE3 keyed |
| Cipher (AEAD) | AES-GCM (128/192/256), AES-CCM (128/192/256), ChaCha20-Poly1305, XChaCha20-Poly1305, Ascon-AEAD128 |
| Cipher (Block) | AES-128, AES-192, AES-256 (ECB/CBC/CTR), ChaCha20 |
| Cipher (Regional) | SM4, ARIA (128/192/256), Camellia (128/192/256), Kuznyechik, Kalyna (128/256/512), SEED |
| KDF / key wrap | HKDF, KBKDF, Concat KDF, PBKDF2, BLAKE3 DeriveKey, AES Key Wrap (RFC 3394/5649) |
| KEM (post-quantum) | ML-KEM-512, ML-KEM-768, ML-KEM-1024 (FIPS 203) |
| Signatures (post-quantum) | ML-DSA-44, ML-DSA-65, ML-DSA-87 (FIPS 204), SLH-DSA all 12 parameter sets (FIPS 205), plus the HashML-DSA / HashSLH-DSA pre-hash variants |
| Regional | SM3, Streebog, Kupyna, LSH, Whirlpool, RIPEMD-160 |
| Legacy | SHA-1, MD5 (kept for backward compatibility only) |
All XOF algorithms implement IExtendableOutput for streaming variable-length output via Absorb / Squeeze / Reset.
MLKem, MLDsa and SlhDsa deliberately mirror the names and signatures of .NET 10's in-box types, so moving from them is a using swap — and unlike them, IsSupported is always true on every target down to net462, because nothing here depends on Windows CNG or OpenSSL.
All three import and export PKCS#8, SubjectPublicKeyInfo and PEM, including PBES2-encrypted private keys, byte for byte compatible with .NET 10. No member takes a password or returns a plaintext private key as a string; secrets stay in spans the caller can wipe with CryptographicOperations.ZeroMemory — see Erasable Memory.
⏱️ Benchmarks
Measured with BenchmarkDotNet across a range of payload sizes, comparing our managed implementations against reference libraries and the OS-provided versions. Results are published through an interactive trends dashboard — pick platform, algorithm family, and method, and every implementation plots as its own line.
🧬 Development Policy
Development may use AI-assisted tooling; no guarantee of clean-room provenance is claimed.
🧱 Orthogonal by design
- Everything is built with free and open-source tooling — the .NET SDK, Visual Studio Community, VS Code, GitHub, Azure DevOps.
- Packages are meant to stand on their own; we try hard to avoid deep cross-dependencies between them.
- Dependencies on anything outside CryptoHives are kept minimal and limited to widely adopted, well-maintained libraries (e.g.
Microsoft.Extensions.*).
- OS and hardware dependencies are avoided where possible, so behavior stays deterministic across platforms and runtimes — this matters especially for the crypto implementations.
- None of this is meant to replace or compete with the existing .NET class library. It's meant to complement it.
⚡ Built for performance
- Every package targets high throughput with no steady-state allocations, for both transformation pipelines and crypto workloads.
- Where it helps, algorithms use managed SIMD intrinsics with a scalar fallback for platforms that don't support them.
- Performance and memory usage are benchmarked against reference implementations, not just asserted.
🛡️ Secure development policy
- Implementations are written directly from public specifications (NIST, RFC, ISO) rather than ported from other codebases.
- Every algorithm is checked against official test vectors from its specification.
- Reviews include validation against independent reference implementations.
- Public APIs and anything touching the network are treated as hostile-input surfaces by default.
- Defaults favor a minimal attack surface: explicit configuration, strict input validation, bounded resource use.
- Dependencies are kept minimal and vetted; reproducible, signed releases are on the roadmap.
- Fuzzing is planned; static analysis and defensive error handling are already in place to limit misuse and information leaks.
🤖 AI Usage in This Project
AI coding assistants (such as Claude and GitHub Copilot) are used in this project as productivity tools — for drafting boilerplate, tests, and documentation, and for reviewing code.
Every AI-assisted contribution is reviewed, understood, and validated by a human maintainer before being merged; no code is accepted that the maintainers cannot fully explain and stand behind.
Given the security-sensitive nature of this library, all cryptographic logic is verified against the relevant specifications and test vectors regardless of how it was authored.
Contributors are welcome to use AI tools under the same principle: you are responsible for the correctness, licensing, and quality of what you submit, and purely machine-generated PRs without human understanding will be rejected.
📥 Installation
Via the NuGet CLI:
dotnet add package CryptoHives.Foundation.Threading
Or from the Visual Studio Package Manager:
Install-Package CryptoHives.Foundation.Threading
💡 Usage Examples
Cryptography
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);
Threading
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
}
}
}
🚨 Security Policy
Security comes first here. If you find a vulnerability, please don't open a public issue — report it privately through GitHub's private vulnerability reporting. The CryptoHives Security Page has the details.
🔏 NuGet Package Code Signing
Packages aren't code-signed yet. The Keepers plan to add signing once there's enough demand (and funding) to justify it.
📝 No-Nonsense License Matters
This project is permissively licensed because we believe in open collaboration. That said, we're aware permissively licensed code sometimes gets copied, repackaged, and resold without credit — if you use this code, we'd appreciate it if you didn't do that:
- Give visible credit to the CryptoHives Open Source Initiative / The Keepers of the CryptoHives and link back to the source.
- Send improvements back upstream and report issues rather than silently forking.
None of that is legally required under either license — it's just what makes open source worth doing.
⚖️ License
Every component is licensed under either of
at your option. Apache-2.0 adds an explicit patent grant, which some organizations require for a cryptography library; MIT is the shortest. Releases up to and including 0.7.37 were published under MIT only and stay that way.
Unless you explicitly state otherwise, any contribution you submit is licensed the same way, without additional terms or conditions.
Source files carry the following SPDX header by default:
// SPDX-FileCopyrightText: <year> The Keepers of the CryptoHives
// SPDX-License-Identifier: MIT OR Apache-2.0
A few inherited components — e.g. the test-only reference implementations under tests/Threading/Async/RefImpl/ — keep their original MIT headers for provenance.
🔀 Choosing a license
If you redistribute a CryptoHives package, include the text of the license you chose. We recommend recording that choice in your third-party notices, for example:
CryptoHives.Foundation.<PackageName>
Copyright (c) 2026 The Keepers of the CryptoHives
Dual licensed under MIT OR Apache-2.0; distributed here under the MIT License.
https://github.com/CryptoHives/Foundation
Package metadata declares the SPDX expression MIT OR Apache-2.0. If your tooling or SBOM needs a single concluded license, record your choice (MIT or Apache-2.0) there.
🐝 About The Keepers of the CryptoHives
The CryptoHives Open Source Initiative is maintained by The Keepers of the CryptoHives, a loose collective of developers working on open, verifiable, high-performance cryptography for .NET.
🤝 Contributing
Issues, questions and pull requests are all welcome — small ones just as much as big ones. Issues labelled good first issue or help wanted are a good place to start. Have a look at the Contributing Guide and our short Code of Conduct.
© 2026 The Keepers of the CryptoHives
