dcrypt-hybrid 2.0.0

Hybrid cryptography schemes for the dcrypt library
Documentation
dcrypt-hybrid-2.0.0 has been yanked.

Hybrid Cryptography

Crates.io Docs.rs License Repository

Overview

dcrypt-hybrid composes classical and post-quantum algorithms. Hybrid designs can reduce dependence on a single primitive during a migration, but their security also depends on the combiner, framing, domain separation, protocol context, key validation, and both component implementations.

Do not interpret this composition as an unconditional guarantee that the result is secure whenever either component survives. Applications still need an independent review of the complete protocol and its assumptions.

This crate is part of the broader dcrypt library ecosystem.

Implemented Schemes

The crate provides hybrid implementations for two primary cryptographic functions: Key Encapsulation Mechanisms (KEMs) and Digital Signatures.

Hybrid Key Encapsulation Mechanisms (KEMs)

A KEM establishes a shared secret between two parties. These hybrid KEMs combine two component secrets through a KDF. The resulting security claim is conditional on the combiner and surrounding protocol as well as the component assumptions; it is not established by concatenating algorithms alone.

Available KEMs

  • EcdhP256Kyber768: Combines classical ECDH on the P-256 curve with post-quantum Kyber-768 (NIST Level 3).
  • EcdhP384Kyber1024: A higher-security variant combining ECDH on P-384 with Kyber-1024 (NIST Level 5).

How it works:

  1. A key pair is generated by creating both a classical and a post-quantum key pair. The public keys are concatenated.
  2. To encapsulate, the sender performs two separate encapsulation operations, one for each algorithm.
  3. The resulting two shared secrets are combined into a single, final shared secret using HKDF-SHA256.
  4. The recipient performs two decapsulations and combines the results in the same way to derive the identical final secret.

Example Usage (EcdhP256Kyber768):

use dcrypt::api::Kem;
use dcrypt::hybrid::kem::EcdhP256Kyber768;
use rand::rngs::OsRng;

// 1. Generate a hybrid key pair for the recipient.
let (pk, sk) = EcdhP256Kyber768::keypair(&mut OsRng)?;

// 2. The sender encapsulates a secret for the recipient's public key.
let (ciphertext, shared_secret_sender) = EcdhP256Kyber768::encapsulate(&mut OsRng, &pk)?;

// 3. The recipient decapsulates the ciphertext with their secret key.
let shared_secret_recipient = EcdhP256Kyber768::decapsulate(&sk, &ciphertext)?;

// 4. Both parties now have the same shared secret.
assert_eq!(
    *shared_secret_sender.to_bytes_zeroizing(),
    *shared_secret_recipient.to_bytes_zeroizing()
);
println!("Successfully established a hybrid shared secret!");
# Ok::<(), Box<dyn std::error::Error>>(())

Hybrid Digital Signatures

A hybrid signature requires that both the classical and post-quantum signatures are valid to be accepted.

EcdsaMlDsa65Hybrid

This scheme combines:

  • Classical: ECDSA with the P-384 curve.
  • Post-Quantum: final FIPS 204 ML-DSA-65.

Public keys, secret keys, and signatures use domain-separated version-2 framing. The decoder rejects version-1 EcdsaDilithiumHybrid objects because their component called Dilithium used a nonstandard, incompatible encoding. Version-1 objects are not migrated or relabeled as ML-DSA.

RsaFalconHybrid

RsaFalconHybrid is a placeholder, not an available secure scheme. Its RSA-PSS component is an RSA-PSS-STUB whose key generation, signing, and verification return NotImplemented. Do not use it for security or present it as a completed RSA-PSS/Falcon construction.

How it works:

  1. A hybrid key pair consists of both a classical and a post-quantum key pair.
  2. To sign a message, two separate signatures are generated and concatenated.
  3. To verify, a recipient must successfully verify both component signatures. If either fails, the entire signature is invalid.

Example Usage (EcdsaMlDsa65Hybrid):

use dcrypt::api::Signature;
use dcrypt::hybrid::sign::EcdsaMlDsa65Hybrid;
use rand::rngs::OsRng;

// 1. Generate a hybrid key pair.
let (pk, sk) = EcdsaMlDsa65Hybrid::keypair(&mut OsRng)?;

let message = b"This message needs a hybrid signature.";

// 2. Sign the message with the hybrid secret key.
let signature = EcdsaMlDsa65Hybrid::sign(message, &sk)?;

// 3. Verify the hybrid signature with the public key.
let verification_result = EcdsaMlDsa65Hybrid::verify(message, &signature, &pk);

assert!(verification_result.is_ok());
println!("Successfully created and verified a hybrid signature!");
# Ok::<(), Box<dyn std::error::Error>>(())

Release status

v2.0.0 is the first remediated dcrypt release. v1.2.3 is confirmed affected, and the exact affected ranges for earlier releases remain under investigation. The remediated line has not received an independent post-remediation audit or FIPS validation; review SECURITY.md and pin the exact version selected for deployment.

Features

Only the default std build is currently supported. Although the manifest still declares alloc and no_std feature flags, the transitive dependency graph does not provide a validated, supported no_std configuration. Do not rely on those flags for embedded deployment until a release explicitly restores and tests that support.

  • std (default): Enables functionality that requires the standard library.
  • alloc / no_std: Present for compatibility, but unsupported and not a release guarantee.
  • serde: Enables serialization and deserialization for some public types via the Serde framework.

License

This crate is licensed under the Apache-2.0 License.