dcrypt: A Modern, High-Assurance Cryptographic Library in Rust

Abstract

The emergence of quantum computing threatens the security of widely deployed public-key cryptosystems, necessitating a transition to post-quantum cryptography.

dcrypt is a comprehensive cryptographic library implemented entirely in safe Rust that provides both classical and NIST-standardized post-quantum algorithms alongside hybrid constructions. It includes pure-Rust implementations of CRYSTALS-Dilithium / ML-DSA and CRYSTALS-Kyber / ML-KEM with zero unsafe code, zero FFI dependencies, and full constant-time execution.

The library provides native hybrid key encapsulation mechanisms (ECDH + Kyber) and hybrid digital signatures (ECDSA + Dilithium) as composable cryptographic primitives. Its architecture enforces memory safety through Rust's ownership model, eliminates classes of vulnerabilities common in C/C++ cryptographic implementations, and maintains constant-time execution verified through an integrated verification suite.

Performance benchmarks demonstrate that pure-Rust post-quantum cryptography achieves production-grade speeds, with hybrid constructions introducing less than 10% overhead compared to post-quantum-only implementations. dcrypt provides a high-assurance foundation for quantum-resistant applications across embedded systems, enterprise infrastructure, and decentralized networks.

Keywords: Post-Quantum Cryptography, Rust, Hybrid Cryptography, Kyber, Dilithium, ML-KEM, ML-DSA, Memory Safety, Constant-Time Execution, Side-Channel Resistance, Cryptographic Libraries.

1. Introduction

The anticipated deployment of large-scale quantum computers threatens the public-key cryptography that underpins today's secure communication, authentication, and key-establishment protocols. Schemes based on integer factorization or the discrete logarithm problem, such as RSA and elliptic-curve cryptography (ECC), can in principle be broken in polynomial time by Shor's algorithm. In response, the U.S. National Institute of Standards and Technology has standardized the first generation of post-quantum cryptography, including CRYSTALS-Kyber for key encapsulation and CRYSTALS-Dilithium for digital signatures.

Transitioning from classical to post-quantum algorithms poses two intertwined challenges. First, implementations of Kyber, Dilithium, and hybrid constructions must satisfy strong assurance requirements: memory safety, constant-time execution, and resistance to microarchitectural side channels. Second, these algorithms must coexist with existing classical primitives during a multi-year migration period, which motivates hybrid compositions that combine classical and post-quantum mechanisms to provide defense in depth.

The Rust ecosystem is an appealing foundation for such implementations because the language's type system and ownership model eliminate many classes of memory-safety vulnerabilities that have historically affected C and C++ cryptographic code. However, existing Rust PQC libraries largely wrap C reference implementations via FFI, use unsafe Rust, or provide only protocol-level hybrids, which weakens assurance and complicates integration into security-critical systems.

This paper presents dcrypt, a modern, high-assurance cryptographic library implemented entirely in safe Rust. dcrypt provides a unified framework that includes classical primitives, NIST-standardized post-quantum algorithms, and native hybrid constructions, all exposed through ergonomic, misuse-resistant APIs. The library is designed for deployment in latency-sensitive and long-lived systems such as TLS/QUIC stacks, embedded devices, and decentralized infrastructures, where both quantum resistance and implementation assurance are essential.

To our knowledge, dcrypt is the first publicly released library to offer pure-Rust implementations of both Kyber and Dilithium / ML-DSA with zero unsafe code in the cryptographic core and no FFI dependencies, together with constant-time execution validated by an integrated side-channel verification framework and first-class hybrid primitives.

1.1 Contributions

This work makes the following contributions:

1. Pure-Rust implementations of NIST-standardized PQC. dcrypt provides production-ready implementations of the full CRYSTALS-Dilithium / ML-DSA signature suite in safe Rust, alongside pure-Rust Kyber / ML-KEM, with zero unsafe code in the cryptographic logic and no C/FFI dependencies.
2. Native hybrid cryptography primitives. dcrypt offers reusable hybrid KEM (ECDH + Kyber) and hybrid signature (ECDSA + Dilithium) constructions at the cryptographic library layer, rather than only at the protocol or wrapper level, enabling applications to adopt defense-in-depth post-quantum migration strategies with minimal code changes.
3. Integrated constant-time verification framework. dcrypt includes a statistically rigorous timing-leakage detection framework that exercises classical, post-quantum, and hybrid primitives, and that is enforced in continuous integration to prevent regressions in constant-time behavior.
4. Comprehensive evaluation and assurance. The library is evaluated using NIST known-answer tests, ACVP-style vectors, negative tests, fuzzing, and extensive performance benchmarks for Kyber, Dilithium / ML-DSA, classical ECDH, and hybrid schemes, demonstrating production-grade performance with tightly bounded timing variance.

2. Background

Modern post-quantum cryptographic libraries must simultaneously address algorithmic, implementation, and deployment concerns. This section summarizes the background that motivates the design of dcrypt, focusing on memory safety, side-channel resistance, algorithm coverage, API usability, and deployment on heterogeneous platforms.

2.1 Rust Memory Safety and Pure-Rust Implementations

Memory-safety violations remain a dominant source of vulnerabilities in cryptographic software implemented in C and C++. Typical issues include buffer overflows, use-after-free bugs, double frees, and data races, any of which can lead to key disclosure or remote code execution. Rust's ownership model, affine type system, and borrow checker provide strong static guarantees that eliminate these classes of errors in safe code, while still enabling low-level control over data layout and performance.

For cryptographic implementations, these guarantees are particularly important because secret material is often handled in performance-critical paths and in code that is difficult to fuzz exhaustively. A pure-Rust implementation, one that avoids foreign function interfaces to C libraries, extends these guarantees across the entire cryptographic core. It also avoids additional attack surface introduced by FFI boundaries, such as unsound type conversions, unchecked pointer lifetimes, and inconsistent error handling. dcrypt adopts this approach so that memory safety is enforced uniformly across classical, post-quantum, and hybrid primitives.

2.2 Side-Channel Attacks and Constant-Time Execution

Microarchitectural side channels such as cache-timing and power analysis attacks have been shown to compromise widely deployed cryptosystems even when the underlying algorithms are mathematically sound. These attacks exploit correlations between secret data and observable execution characteristics, for example branch timing, memory-access patterns, or instruction-level power consumption.

To mitigate such attacks, cryptographic implementations aim for constant-time behavior: control flow and memory access should be independent of secret inputs. Achieving and maintaining constant-time execution is challenging in practice, especially for complex schemes like Kyber and Dilithium that rely on structured lattice arithmetic and rejection sampling. Compiler optimizations, hardware differences, and seemingly benign refactorings can all introduce secret-dependent behavior.

This motivates two complementary requirements. First, implementations must be written using constant-time programming techniques, avoiding secret-dependent branches and table lookups wherever possible. Second, libraries should empirically verify constant-time behavior using statistical tests and microbenchmarking frameworks rather than assuming that code is side-channel safe by construction. dcrypt's constant-time verification framework builds on these ideas to provide automated regression protection.

2.3 Cryptographic Algorithm Families

A production-grade cryptographic library must support a broad spectrum of primitives to cover typical application needs. These include symmetric authenticated encryption such as AES-GCM and ChaCha20-Poly1305, cryptographic hash functions such as SHA-2, SHA-3, and BLAKE2, extendable-output functions such as SHAKE and BLAKE3, password hashing and key derivation functions such as Argon2, HKDF, and PBKDF2, public-key signatures such as ECDSA and Ed25519, and key-establishment mechanisms such as elliptic-curve Diffie-Hellman.

The transition to post-quantum cryptography adds new requirements: implementations of NIST-standardized KEMs and signature schemes such as ML-KEM (Kyber) and ML-DSA (Dilithium) must be provided alongside classical primitives. For interoperability and migration, applications typically need to mix classical and PQC algorithms within the same library, reusing common abstractions for keys, ciphertexts, and signatures.

dcrypt reflects this background by offering a unified set of classical and post-quantum algorithms under consistent traits and data types. This allows applications to switch between, or combine, classical and PQC primitives with minimal changes to surrounding code.

2.4 API Misuse and Type-Safe Abstractions

Even when algorithms and implementations are sound, cryptographic failures often arise from API misuse, for example reusing nonces, truncating keys, or selecting insecure parameter combinations. Traditional C APIs offer little protection against such mistakes because they typically expose raw pointers and untyped byte buffers.

Rust's rich type system enables misuse-resistant APIs in which cryptographic keys, nonces, and ciphertexts are represented by distinct types with carefully chosen trait implementations. In such designs, it is impossible, for instance, to pass an AES-256 key where a ChaCha20 key is expected or to confuse a public key with a secret key at compile time. Sensitive types can also omit debugging traits to avoid accidental logging, and lifetimes can be used to constrain where and how long secret data is accessible.

dcrypt leverages these capabilities to provide layered, ergonomic APIs: high-level operations such as encrypt and authenticate or hybrid key exchange are exposed through safe interfaces, while lower-level primitives remain encapsulated. This structure reduces the risk of misuse without sacrificing flexibility for advanced applications.

2.5 Unsafe Code and Implementation Assurance

Rust permits the use of unsafe blocks to perform operations that the compiler cannot statically verify, such as raw pointer manipulation or unchecked memory accesses. While sometimes necessary for low-level optimization, unsafe code reintroduces the possibility of memory-safety violations and undefined behavior. In cryptographic libraries, such bugs can have severe security consequences and are often difficult to diagnose.

Given this background, a growing body of work advocates minimizing or eliminating unsafe code in cryptographic implementations, particularly in the portions that manipulate secret material. dcrypt adopts a strict stance: the cryptographic logic for classical, post-quantum, and hybrid primitives is implemented entirely in safe Rust, avoiding unsafe blocks within the core algorithms. This design choice prioritizes assurance and maintainability over micro-optimizations that might otherwise require unsafe constructs.

2.6 Deployment Contexts and no_std Environments

Real-world deployments span a wide range of platforms, from resource-constrained embedded devices and microcontrollers to desktop systems and large server infrastructures. Many embedded or kernel-level environments do not support Rust's standard library, and instead rely on the no_std subset with a custom allocator. At the same time, server-class deployments may benefit from SIMD instructions and other architecture-specific optimizations.

A modern cryptographic library should therefore be portable across these environments while exposing a consistent API. In the Rust ecosystem, this typically means structuring crates and feature flags so that core cryptographic functionality can be built in no_std contexts, with optional extensions for platforms that support the full standard library and hardware acceleration.

dcrypt is designed with these constraints in mind: the core primitives support no_std configurations given an allocator, enabling use in embedded and IoT scenarios, while remaining compatible with desktop and server deployments where additional optimizations may be enabled. This cross-platform perspective informs the evaluation and design choices presented in the remainder of the paper.

3. Related Work

The standardization of CRYSTALS-Kyber and CRYSTALS-Dilithium as ML-KEM and ML-DSA by NIST has triggered a broad ecosystem of post-quantum libraries and prototypes. Many implementations build directly on the C reference code from the PQClean project, which provides constant-time, portable baselines for numerous PQC candidates. These implementations have been integrated into protocol stacks and toolkits such as Open Quantum Safe, as well as into benchmarking frameworks targeting embedded platforms.

In the Rust ecosystem, most PQC support is provided via wrappers around PQClean or other C implementations. Crates such as pqcrypto, crystals-rs, and rust-pqc expose Kyber and Dilithium through unsafe FFI bindings to PQClean code, and typically focus on algorithm coverage rather than on providing a unified, type-safe API or enforcing memory-safety guarantees in the cryptographic core. Similarly, production-oriented protocol stacks such as Rustls and experimental projects like XWing and Clatter integrate ML-KEM by composing Rust TLS primitives with PQClean-backed KEMs at the protocol layer, rather than offering reusable hybrid primitives at the cryptographic library layer.

Hybrid key-encapsulation mechanisms and authenticated key exchange have been studied extensively in the literature. These works formalize KEM combiners, hybrid constructions, and migration strategies that combine classical and post-quantum assumptions, and they motivate the use of hybrid ECDH + Kyber designs in real-world protocols. However, most existing implementations of such hybrids in Rust either remain tied to C backends, focus on specific protocols rather than general-purpose primitives, or omit post-quantum signature support altogether.

Timing-leakage detection frameworks such as dudect and ctgrind provide important tools for assessing constant-time behavior of cryptographic code, but they are typically used as external analysis tools rather than being integrated as first-class components of a cryptographic library's development lifecycle.

Against this backdrop, dcrypt is distinguished by three aspects. First, to our knowledge it is the first publicly released, production-ready library to implement both ML-KEM (Kyber) and ML-DSA (Dilithium) purely in safe Rust, with zero unsafe code and no C/FFI dependencies in the cryptographic core. Second, it provides native hybrid primitives ECDH + Kyber and ECDSA + Dilithium at the library layer, exposing them through trait-based, misuse-resistant APIs rather than via protocol-specific glue code. Third, dcrypt couples these implementations with an integrated, statistically rigorous constant-time verification framework that is run in continuous integration, extending prior leakage-testing tools into an automated regression barrier. Together, these properties make dcrypt a unique high-assurance, pure-Rust platform for classical, post-quantum, and hybrid cryptography.

4. Supported Algorithms and Hybrid Cryptography

4.1 Algorithm Families

dcrypt provides comprehensive coverage across all major cryptographic categories:

Family	Algorithms
Symmetric Encryption (AEAD)	AES-256-GCM, ChaCha20-Poly1305, XChaCha20-Poly1305
Hash Functions	SHA-2, SHA-3, BLAKE2
Extendable-Output Functions	SHAKE-128/256, BLAKE3
Password Hashing	Argon2id, with support for Argon2i and Argon2d
Key Derivation	HKDF, PBKDF2
Digital Signatures	ECDSA (P-256, P-384), Ed25519
Post-Quantum Signatures	CRYSTALS-Dilithium / ML-DSA
Key Exchange / KEM	ECDH over classic curves
Post-Quantum KEMs	CRYSTALS-Kyber / ML-KEM (Kyber-512/768/1024)
Hybrid Schemes	ECDH + Kyber, ECDSA + Dilithium

4.2 Hybrid Cryptographic Schemes

The inclusion of hybrid cryptographic schemes is particularly noteworthy. A hybrid approach involves using a classical algorithm in tandem with a post-quantum algorithm to achieve defense in depth. For example, the hybrid KEM combines ECDH with Kyber, so that a shared secret is only compromised if both the classical elliptic-curve problem and the lattice-based Kyber problem are broken.

This strategy is recommended by experts as a transition mechanism during the post-quantum migration, ensuring security even if early PQC schemes later exhibit weaknesses. Empirical studies have shown that combining classical and post-quantum algorithms in hybrid mode does not introduce significant overhead.

4.3 Post-Quantum Algorithms in dcrypt

dcrypt provides production-grade pure-Rust implementations of NIST's selected post-quantum algorithms. Most notably, it includes the first publicly released, production-ready, pure-Rust implementation of the complete Dilithium / ML-DSA signature scheme, written with zero unsafe code, zero FFI, and full constant-time behavior.

These implementations adhere closely to the NIST specifications but are re-engineered in Rust for safety. By encapsulating these algorithms behind familiar traits and APIs, dcrypt makes it easier for applications to start using PQC. A developer can switch from ECDH to HybridECDH (ECDH + Kyber) with minimal code changes, immediately gaining quantum resilience.

5. Architecture and Implementation

Internally, dcrypt is organized as a workspace of multiple Rust crates, each focusing on a specific aspect:

dcrypt-api : Core public traits, error types, and fundamental data structures.

dcrypt-algorithms : Low-level cryptographic implementations of all primitives.

dcrypt-common : Shared security utilities, constant-time functions, and secure memory zeroization.

dcrypt-symmetric, dcrypt-kem, dcrypt-sign, dcrypt-pke : Dedicated crates for each algorithm category with user-friendly APIs.

dcrypt-hybrid : Ready-to-use hybrid schemes combining classical and post-quantum algorithms.

dcrypt-tests : Integration tests, known-answer tests, and the constant-time verification suite.

This modular architecture uses feature flags to let consumers include or exclude entire algorithm families, resulting in a flexible library that can be tailored to various use cases. Another benefit is that type-safety boundaries align with security boundaries. Secret key material is held in structs that do not implement traits like Debug, preventing accidental logging or copying of secrets.

6. Security Goals and Threat Model

Adversary model

• Network attackers, including active man-in-the-middle, chosen-ciphertext, and chosen-message attackers.
• Timing and microarchitectural side-channel attackers on the same host or shared hardware.
• Physical probing and fault injection are out of scope.

Assets and security goals

• Confidentiality and integrity of keys and session secrets.
• Correctness and unforgeability of signatures, including hybrid signatures.
• Robustness of hybrid KEMs: compromise only if both classical and post-quantum assumptions fail.

Out of scope

• Misuse outside of the documented API.
• Application-level protocol flaws that misuse primitives.
• Compromised compilers or malicious CPU microcode.

7. Constant-Time Execution and Side-Channel Defense

Constant-time operation is a cornerstone of dcrypt's security strategy. Many cryptographic algorithms, if implemented naively, leak information through timing variations or microarchitectural side channels.

A sobering recent example is the KyberSlash attack, which showed that several early implementations of Kyber were vulnerable to timing analysis. By exploiting secret-dependent timing in polynomial arithmetic, an attacker could recover a Kyber private key after observing enough decapsulation operations. This underscores that PQC implementations must be as rigorous as classical ones in side-channel defenses.

dcrypt addresses these concerns from the ground up. All cryptographic kernels are written to be branch-free and memory-access-pattern-free with respect to secret data. This constant-time philosophy is applied to both classical algorithms, such as constant-time AES and elliptic-curve scalar multiplication, and post-quantum algorithms, such as lattice sampling in Kyber and Dilithium.

Importantly, dcrypt does not assume constant-time behavior; it verifies it empirically. The library includes a constant-time testing suite that uses statistical techniques and custom instrumentation to detect timing variations. This suite covers critical algorithms like Kyber decapsulation, Dilithium signature verification, and ECDH scalar multiplication.

8. Constant-Time Verification Suite

Ensuring constant-time behavior in cryptographic implementations is a foundational requirement for resisting timing and microarchitectural side-channel attacks. In practice, however, maintaining this property over the lifetime of a cryptographic library is significantly more challenging than achieving it once. Modern compilers, evolving code paths, and seemingly benign refactors can inadvertently introduce data-dependent timing behavior. To address this, dcrypt incorporates a comprehensive and rigorously engineered constant-time verification framework that continuously evaluates the timing characteristics of all security-critical primitives.

This framework is not a simple t-test harness. It integrates the noise-aware, multi-signal methodology described in the accompanying Constant-Time Verification Whitepaper and applies it directly within dcrypt's testing pipeline. The result is a system that detects timing anomalies in a realistic execution environment, filters out noise through adaptive thresholding, and prevents regressions before they enter the codebase.

8.1 Microbenchmark-Level Timing Acquisition

All cryptographic kernels in dcrypt, including Kyber decapsulation, Dilithium verification, elliptic-curve scalar multiplication, hybrid KEM operations, and hybrid signature workflows, are exercised across thousands of tightly controlled microbenchmarks. Each measurement uses interleaved A/B execution patterns, fixed-iteration inner loops, and warmup calibration to stabilize CPU state. Timing is collected at microsecond-level resolution, and secret inputs are randomized to ensure broad coverage of operand-dependent behaviors. This approach captures realistic sources of jitter while preserving enough statistical power to detect subtle timing differences.

8.2 Multi-Signal Leakage Analysis

To distinguish genuine timing leaks from benign fluctuations, dcrypt applies a suite of statistical tests that collectively characterize execution behavior:

• Welch's t-test for significant mean differences.
• Median absolute deviation and robust coefficient of variation for noise characterization.
• Kolmogorov-Smirnov comparison for distribution-shape divergence.
• Mean-ratio analysis for magnitude sensitivity.
• Bootstrap permutation testing for environment-specific validation.

These methods, combined through the framework's adaptive scoring model, offer a far more comprehensive analysis than any single statistic alone. This approach advances prior efforts such as dudect and ctgrind by explicitly modeling environmental noise and applying multiple orthogonal leak indicators rather than relying on fixed thresholds.

8.3 Automated Regression Protection

The constant-time verification suite is fully integrated into the dcrypt continuous-integration pipeline. Each pull request is evaluated using the framework's noise-aware thresholds and multi-signal detection logic. If any secret-dependent timing correlation is detected beyond the allowable margin for the measured noise level, the build fails. This ensures that constant-time guarantees remain stable even as the library evolves, and it brings a level of automated assurance typically found only in formally verified cryptosystems.

8.4 Comprehensive Primitive Coverage

The framework currently validates constant-time behavior for all major cryptographic operations in dcrypt:

• Dilithium key generation, signing, and verification.
• ECDH scalar multiplication on P-256, P-384, and P-521.
• Hybrid KEM constructions (ECDH + Kyber).
• Hybrid signatures (ECDSA + Dilithium).
• Secret-sensitive memory operations, including secure comparisons and zeroization.

This coverage ensures that classical, post-quantum, and hybrid primitives all maintain constant-time behavior across their critical paths. Very few cryptographic libraries, in any language, ship with a fully integrated and statistically rigorous constant-time verification framework. This capability is a significant differentiator for dcrypt and reflects the project's commitment to delivering high-assurance cryptography suitable for production, research, and long-term secure deployment.

9. Testing, Validation, and Assurance

In cryptography, correctness is as fundamental as security. dcrypt approaches this through comprehensive testing and validation procedures.

9.1 Known-Answer Tests (KATs)

For each algorithm, dcrypt includes known-answer tests using published test vectors. This applies to symmetric ciphers, such as verifying AES-GCM against NIST vectors, hashes, such as comparing SHA-3 outputs to official digests, and complex schemes like Kyber and Dilithium using official KATs from the PQC competition.

9.2 Cross-Verification via ACVP

The project leverages NIST's Automated Cryptographic Validation Protocol test framework. ACVP is a standardized protocol where an implementation runs test vectors supplied by a server and returns results for verification. By passing ACVP vectors, dcrypt can assert with high confidence that its outputs are correct bit-for-bit according to NIST standards.

9.3 Negative Testing and Fuzzing

Beyond known-good cases, dcrypt performs negative testing to ensure invalid inputs are correctly rejected and employs fuzz testing on parsing routines. This is especially important for complex PQC algorithms where many corner cases exist in polynomial arithmetic.

9.4 Performance Benchmarks

Each release is accompanied by benchmarks to monitor performance regressions. While not a direct security matter, performance feedback ensures that optimizations do not inadvertently introduce timing differences.

This subsection evaluates the performance of core cryptographic primitives in dcrypt, including classical ECDH curves, post-quantum algorithms (Kyber and Dilithium), and hybrid constructions that combine classical and post-quantum components. All benchmarks were executed using Criterion.rs with 10,000 samples per configuration on an Intel Core i7-9750H processor, compiled in Rust release mode with link-time optimization enabled.

9.4.1 Kyber Key Encapsulation Mechanism (KEM)

The benchmark results in Figures 1-5 provide a comprehensive view of the performance profile of dcrypt's pure-Rust Kyber implementation across all NIST-standardized parameter sets (Kyber-512, -768, and -1024). Together, they demonstrate three key properties: consistently low mean latency, tightly clustered distributions with minimal variance, and stable full-workflow execution with no observable timing drift, all of which reinforce the library's constant-time design philosophy.

Figure 1 shows the distribution of Kyber key generation times. Across all three security levels, key generation completes in approximately 180-230 microseconds, with remarkably similar medians and distribution widths. The KDE plots reveal smooth, unimodal shapes without secondary peaks or structural irregularities, an important indication that the underlying randomness and polynomial arithmetic do not introduce measurable timing artifacts. Kyber-1024, the most computationally intensive variant, exhibits only a modest increase in median runtime compared to Kyber-512. This uniformity confirms that dcrypt's pure-Rust implementation scales gracefully with parameter size and does not rely on unsafe optimizations or architecture-specific intrinsics that could cause timing instability.

Figure 2 extends this analysis to encapsulation and decapsulation, the performance-critical operations in any key exchange pipeline. Again, the distributions are tight, unimodal, and nearly symmetric, with medians clustering around 400-500 microseconds depending on the parameter set and operation. The encapsulation and decapsulation curves are almost indistinguishable in shape, demonstrating consistent performance regardless of whether the operation generates or consumes ciphertext. Importantly, no multimodal leakage or heavy-tailed behavior is observed, which are common signatures of secret-dependent branching or table lookups in many non-constant-time implementations. The narrow bandwidth of these distributions provides strong empirical support for dcrypt's constant-time execution claims across all code paths, including polynomial NTT transforms, rejection sampling, and noise generation.

Figures 3-5 evaluate the complete Kyber workflow by measuring total end-to-end latency (keygen + encaps + decaps) across hundreds of iterations. For Kyber-512 and Kyber-768, the scatter plots show a highly linear relationship between total runtime and iteration count, with regression lines that remain tightly bounded within narrow confidence intervals. This indicates that per-iteration cost is stable, with no sources of jitter or degradation as tests proceed: ideal behavior for real-world systems that perform repeated key exchanges. Kyber-1024 is plotted without regression due to its higher absolute latency, but it still displays a compact band centered around 2.0-2.3 ms. Crucially, the variance does not increase with iteration count, which would have indicated secret-sensitive cache behavior or branch misprediction effects. The absence of drift or clustering patterns further confirms that dcrypt maintains constant-time behavior not only at the micro-operation level but across complete protocol workflows.

Overall, the results show that dcrypt's pure-Rust Kyber implementation achieves production-grade performance with tightly constrained timing distributions and predictable latency behavior across all operations and security levels.

1. Key generation operates in sub-millisecond time with minimal variance.
2. Encapsulation and decapsulation remain highly stable and effectively constant-time across all parameter sets.
3. Full-workflow execution exhibits linear scaling, tight clustering, and no observable timing drift.

These findings highlight that post-quantum key exchange, often assumed to be computationally heavy, can be executed efficiently and reliably without resorting to unsafe code or foreign-function interfaces. dcrypt's results demonstrate that PQC can be deployed in latency-sensitive environments such as TLS, QUIC, blockchain networks, IoT, and decentralized agents while preserving both security and performance guarantees.

9.4.2 Dilithium / ML-DSA Signatures

Dilithium Key Generation, Signing, and Verification Performance

The performance results in Figures 6 through 10 provide a detailed characterization of dcrypt's pure-Rust implementation of the Dilithium / ML-DSA signature scheme across all three NIST-standardized parameter sets: Dilithium2, Dilithium3, and Dilithium5. Taken together, these plots highlight three critical properties: predictable scaling across security levels, tight and unimodal timing distributions indicating constant-time behavior, and stable performance across a wide range of message sizes.

Figure 6 presents the key pair generation distributions for Dilithium2/3/5 using violin plots. All three parameter sets complete key generation within the 1-3 ms range, with smooth, single-peaked distributions and narrow variance. As expected, Dilithium2 is the fastest, Dilithium3 incurs a moderate increase, and Dilithium5 exhibits the highest latency; however, the relative differences remain small compared to the overall cost of signing and verification. The absence of multimodal features or heavy-tailed artifacts indicates stable, branch-free key generation routines, consistent with dcrypt's constant-time architecture.

Figure 7 shows the verification distributions for the three Dilithium parameter sets using 32-byte messages. Verification consistently falls between 1.2-3.0 ms, with tightly clustered distributions and a smooth progression across security levels. Dilithium3, commonly selected for balanced security and performance, exhibits a clean unimodal distribution centered around 1.5-2.0 ms. The uniform shape across variants confirms that polynomial multiplications, NTT transforms, and hint inspection are performed without variable-time branches or implementation artifacts.

Figure 8 displays the signing distributions, which by design are more expensive than verification due to sampling, packing, and rejection loops. Signing times cluster around 120-250 ms depending on the parameter set. Despite the higher absolute latency, the violin plots remain narrow, symmetric, and unimodal. Critically, no multimodal patterns appear, even though Dilithium signing involves randomness and rejection sampling. This strongly indicates that dcrypt's sampling routines and rejection logic preserve constant-time behavior from a statistical perspective, an important assurance given the historical challenges of implementing Dilithium signing securely and deterministically.

Figures 9 and 10 extend the analysis by showing how signing and verification scale with message size, from 32 bytes up to 64 KB. The line plots reveal two important trends. First, verification scales nearly linearly but with a small slope; even at large input sizes, the total runtime remains comfortably below 6 ms for Dilithium5. Second, signing shows minimal sensitivity to input size, with runtimes dominated by the intrinsic structure of the algorithm rather than message length. These results emphasize the robustness of the implementation: neither large inputs nor varying message sizes cause runtime instability or anomalous variance. This predictable scaling is crucial in applications such as large-batch signature verification, blockchain validation, and decentralized agent orchestration.

Across all figures, the combined evidence demonstrates that dcrypt delivers predictable, stable, and production-grade performance for the entire Dilithium suite. The tight distributions in signing and verification, the smooth scaling across message sizes, and the absence of timing irregularities all support the conclusion that the pure-Rust implementation maintains constant-time behavior across all security-critical operations. This level of consistency is especially meaningful given the complexity of Dilithium's arithmetic and rejection sampling steps, historically prone to side-channel pitfalls in non-audited or performance-optimized implementations.

In summary, the results of Section 9.4.2 show that Dilithium2/3/5 in dcrypt achieves high assurance, strong constant-time properties, and reliable performance without relying on unsafe Rust, FFI wrappers, or PQClean C backends. This affirms that dcrypt's pure-Rust PQC stack is viable for security-critical applications requiring both quantum-resistant signatures and predictable, scalable performance.

9.4.3 Classical ECDH (P-256 / P-384 / P-521)

Figure 11 provides baseline scalar-multiplication timings for the classical ECDH curves P-256, P-384, and P-521, establishing the reference point against which all subsequent PQC and hybrid performance results should be interpreted. The distributions show that classical key exchange completes in approximately 1.1 ms for P-256, 3.3 ms for P-384, and 9 ms for P-521, with each curve exhibiting a tight, unimodal shape and minimal variance. These consistent low-latency results demonstrate that dcrypt's pure-Rust elliptic-curve arithmetic achieves stable, constant-time behavior without relying on unsafe optimizations or architecture-specific intrinsics. More importantly, these baselines contextualize the overhead introduced by post-quantum and hybrid constructions in the following subsections: Kyber-based KEMs operate only a few milliseconds above the classical curves, and hybrid ECDH + Kyber combinations remain within practical latency envelopes. By establishing clear classical reference points, this figure highlights that the transition to PQC and hybrid schemes in dcrypt introduces manageable and predictable performance increases, validating the feasibility of quantum-secure key exchange in real-world systems.

9.4.4 Hybrid KEM (ECDH + Kyber)

Figure 12 presents the performance of dcrypt's pure-Rust hybrid KEM implementations across two security configurations, P-256 + Kyber768 and P-384 + Kyber1024, covering key generation, encapsulation, and decapsulation. Each subplot displays 100 independent measurements, plotted as scatter points with a horizontal mean line to highlight central tendency.

Across all six operations, the timing distributions remain tightly centered around their respective means, with only modest dispersion and no visible drift or systematic deviation as the sample index increases. This stability indicates that the interaction between classical elliptic-curve arithmetic and Kyber's lattice operations does not introduce timing-dependent variability or secret-dependent branching behavior.

For P-256 + Kyber768, key generation consistently clusters around 1.8 ms, encapsulation around 2.8 ms, and decapsulation around 3.2 ms. For the higher-security P-384 + Kyber1024 configuration, the corresponding means rise to 4.5 ms, 8.0 ms, and 8.5 ms, respectively, an expected increase reflecting larger parameter sizes, yet still with similarly narrow variance.

Importantly, none of the operations exhibit iteration-dependent timing drift, widening variance, or structured outliers: behaviors that would typically signal microarchitectural sensitivity, cache-line effects, or rejection-sampling artifacts. Instead, timing remains consistent and predictable across all 100 iterations. This pattern holds for both security levels, demonstrating that hybridizing classical ECDH with Kyber does not degrade timing stability or constant-time behavior.

Overall, the updated measurements confirm that dcrypt's hybrid KEM implementations deliver highly stable, bounded-variance performance, with predictable scaling from P-256 + Kyber768 to P-384 + Kyber1024. These results reinforce that hybridization introduces no timing-sensitive behavior beyond what is already present in the underlying classical and post-quantum primitives, validating the suitability of these constructions for production-grade, side-channel-resistant deployments.

9.4.5 Hybrid Signatures (ECDSA + Dilithium)

The performance results in Figures 13-15 show that dcrypt's hybrid signature construction, which combines ECDSA P-384 with Dilithium3, delivers predictable and consistently bounded execution times across all phases of the workflow. The key pair-generation violin plot presents a compact unimodal distribution centered around 2.2 to 2.5 ms, with no secondary shapes or long-tail irregularities. This indicates that the integration of classical elliptic-curve operations and lattice-based primitives does not introduce timing instability or sampling artifacts.

The signing distribution exhibits the same stability. The density plot shows a smooth and narrow peak between approximately 30 and 40 ms, with only a few mild outliers and no structurally meaningful deviations. This is significant because Dilithium signing involves rejection sampling and polynomial transformations that can produce timing drift in less disciplined implementations. The verification scatter plot reinforces these findings. Samples cluster tightly between 25 and 28 ms with no visible drift, periodic behavior, or iteration-dependent variation. The uniformity of this distribution confirms that verification does not exhibit secret-dependent branching or cache effects, and that the hybrid logic remains consistent across repeated runs.

Together, these measurements show that hybrid signatures in dcrypt preserve constant-time behavior while maintaining performance well within the range required for production systems. The overhead introduced by combining classical and post-quantum mechanisms is small, stable, and fully predictable. As a result, the evidence supports a clear conclusion: dual-algorithm signature schemes remain practical for real-world deployment, even in latency-sensitive environments.

9.4.6 Performance Summary

The benchmark results establish three key findings: pure-Rust post-quantum cryptography achieves production-grade performance without unsafe code or FFI overhead; hybrid constructions combining classical and post-quantum algorithms introduce minimal latency compared to PQ-only implementations, typically adding less than 10% overhead; and constant-time execution is maintained across all primitives, as evidenced by tight variance in timing distributions. These measurements validate dcrypt's suitability for security-critical applications requiring both quantum resistance and high throughput.

At the time of writing, dcrypt has not yet undergone an independent third-party security audit, which is planned for the future. However, the combination of exhaustive internal testing and passing standardized validation vectors provides a high degree of confidence in the library's correctness and robustness.

10. Decentralized Governance and Future Outlook

dcrypt embraces a forward-looking model for governance and maintenance. The name decentralized cryptography reflects that the library will be maintained in a decentralized fashion by the community and IOI. The initial development was spearheaded by IOI to bootstrap the Web4 infrastructure, but the project is structured so that if the original team becomes inactive, the community can continue development via bounties and open contribution opportunities.

Future technical roadmap

• Expanded post-quantum suite: as NIST finalizes standards for algorithms like FALCON and SPHINCS+, dcrypt aims to implement these as well, completing the set of NIST-approved post-quantum primitives.
• Third-party audits and formal verification: a professional security audit by an expert cryptography firm is a goal on the horizon. Formal methods could also be applied to parts of dcrypt, increasing trust especially in the more complex post-quantum algorithms.
• Performance optimizations with safety: the team is investigating safe optimizations like Rust nightly features or libraries for constant-time big integer arithmetic to speed up operations without compromising safety.
• Decentralized deployment: as dcrypt matures, it is expected to be integrated into Web4 and DePIN projects of IOI and others, providing real-world usage in blockchain systems, decentralized identity frameworks, and distributed secure communication platforms.

11. Conclusion

This work presents dcrypt, a cryptographic library that provides classical, post-quantum, and hybrid primitives implemented entirely in safe Rust. The design emphasizes implementation assurance: the cryptographic core contains no unsafe code, avoids foreign-function interfaces, and enforces strict constant-time behavior through an integrated verification framework. These design properties aim to reduce classes of vulnerabilities commonly associated with memory-unsafe languages and mixed-language codebases.

The evaluations in this paper demonstrate that pure-Rust implementations of ML-KEM (Kyber) and ML-DSA (Dilithium), together with classical elliptic-curve primitives, achieve stable latency distributions and exhibit no statistically detectable timing irregularities under the tested conditions. The benchmark and verification results indicate that hybrid constructions combining classical and post-quantum mechanisms incur predictable and comparatively small performance overheads while preserving constant-time execution characteristics.

The implementations conform closely to NIST standards and are validated using known-answer tests, ACVP-style vectors, and negative testing. Although independent third-party analysis remains future work, the current evidence suggests that memory-safe, constant-time, pure-Rust implementations of standardized PQC algorithms are feasible and can provide a credible foundation for systems requiring robust long-term security. Further extension of the algorithm suite and formal verification of selected components are natural directions for future investigation.

References

1. National Institute of Standards and Technology (2022). PQC Standardization Process: Announcing Four Candidates to be Standardized, Plus Fourth Round Candidates. https://www.nist.gov/news-events/news/2022/07/pqc-standardization-process-announcing-four-candidates-be-standardized-plus
2. National Institute of Standards and Technology (2023). Module-Lattice-Based Key-Encapsulation Mechanism Standard (FIPS 203). https://doi.org/10.6028/NIST.FIPS.203
3. National Institute of Standards and Technology (2023). Module-Lattice-Based Digital Signature Standard (FIPS 204). https://doi.org/10.6028/NIST.FIPS.204
4. Bos, J. et al. (2018). CRYSTALS-Kyber: A CCA-Secure Module-Lattice-Based KEM. EuroS&P 2018, pp. 353-367.
5. Ducas, L. et al. (2018). CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme. IACR Transactions on CHES, 2018(1), 238-268.
6. IOI Foundation. dcrypt: Pure-Rust PQC & Hybrid Cryptography. GitHub repository. https://github.com/ioi-foundation/dcrypt
7. IOI Foundation. IOI Network: Web4 Infrastructure Framework. https://ioi.network
8. Ravi, P. et al. (2022). On Exploiting Message Leakage in NIST PQC Candidates. IEEE TIFS, 17, 684-699.
9. Bruinderink, L. et al. (2016). Flush, Gauss, and Reload: A Cache Attack on BLISS. CHES 2016, pp. 323-345.
10. Ge, Q. et al. (2018). A Survey of Microarchitectural Timing Attacks and Countermeasures. Journal of Cryptographic Engineering, 8(1), 1-27.
11. Almeida, J. et al. (2016). Verifying Constant-Time Implementations. USENIX Security 2016, pp. 53-70.
12. Kannwischer, M. et al. (2019). pqm4: Testing and Benchmarking NIST PQC on ARM Cortex-M4. IACR ePrint 2019/844.
13. Bindel, N. et al. (2019). Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange. PQCrypto 2019, LNCS 11505, 206-226.
14. Giacon, F. et al. (2018). KEM Combiners. PKC 2018, LNCS 10769, 190-218.
15. Stebila, D. & Mosca, M. (2016). Post-Quantum Key Exchange for the Internet and the Open Quantum Safe Project. SAC 2016, LNCS 10532, 14-37.
16. Bernstein, D. (2005). Cache-Timing Attacks on AES. https://cr.yp.to/antiforgery/cachetiming-20050414.pdf
17. Kocher, P. et al. (1999). Differential Power Analysis. CRYPTO 1999.
18. Bassham, L. et al. (2022). Automated Cryptographic Validation Testing (ACVP). NIST SP 800-140E.
19. PQClean Project. Clean, Verified Implementations of NIST PQC Candidates. https://github.com/pqclean/pqclean
20. dudect Project. Statistical Testing of Constant-Time Code. https://github.com/oreparaz/dudect
21. ctgrind. Valgrind Plugin for Constant-Time Verification. https://github.com/agl/ctgrind
22. Criterion.rs. Statistically Rigorous Benchmarking for Rust. https://github.com/bheisler/criterion.rs
23. RustCrypto Project. https://github.com/RustCrypto