Hybrid & Migration

The transition from classical to post-quantum cryptography is a multi-year process that requires careful planning. The Dyber SDK provides comprehensive hybrid operation modes that combine classical and post-quantum algorithms for defense-in-depth, progressive migration strategies with rollback safety, and crypto-agility patterns that future-proof applications against algorithm changes.

Overview #

Hybrid cryptography combines classical algorithms (RSA, ECDSA, ECDH, X25519) with post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) in a way that maintains security even if either algorithm family is broken. This "belt and suspenders" approach is recommended by NIST, CISA, and the NSA's CNSA 2.0 guidance for the transition period where confidence in PQC algorithms is still being established.

The SDK supports hybrid operation at every level: TLS key exchange (via the OpenSSL provider), digital signatures (composite certificates), key encapsulation (dual-KEM), and application-level cryptographic operations (Universal API hybrid mode).

Hybrid Operation Modes #

Parallel Hybrid #

Parallel hybrid mode performs both classical and post-quantum operations simultaneously and combines the results using a key derivation function (HKDF). Both shared secrets must be available to derive the final key, so an attacker must break both algorithms to compromise the exchange.

// Enable parallel hybrid mode
qc_hybrid_config_t config = {
    .mode = QC_HYBRID_PARALLEL,
    .classical_alg = QC_ALG_X25519,
    .pqc_alg = QC_ALG_KYBER_768,
    .combiner = QC_COMBINER_HKDF_SHA256
};
qc_set_hybrid_config(&config);

// Key exchange now automatically performs both algorithms
qc_key_handle_t hybrid_key;
qc_key_generate(&hybrid_key, QC_OP_KEY_EXCHANGE, QC_SECURITY_LEVEL_HIGH, 0);
// hybrid_key contains both X25519 and ML-KEM-768 key material

Sequential Hybrid #

Sequential hybrid mode wraps the classical operation with a post-quantum layer. For signatures, this produces a composite signature containing both a classical and PQC signature. For key exchange, the classical shared secret is encrypted under the PQC KEM before transmission.

Migration Strategies #

The SDK supports three primary migration strategies, each designed for different organizational risk tolerances and deployment constraints.

Big Bang: All systems switch to PQC simultaneously on a coordinated date. Simplest conceptually but highest risk. Suitable for isolated environments without external interoperability requirements.

Gradual Rollout: PQC is deployed incrementally — starting with internal systems, then expanding to external-facing services. The SDK's hybrid mode enables mixed classical/PQC environments during the transition. This is the recommended approach for most organizations.

Canary Deployment: A small percentage of traffic uses PQC algorithms while the majority continues with classical. The percentage is increased as confidence grows. Automatic rollback triggers on performance degradation or errors.

Canary Deployments #

// Configure canary deployment
qc_canary_config_t canary = {
    .pqc_percentage = 5,              // 5% of operations use PQC
    .monitor_latency = true,
    .max_latency_increase_pct = 200,  // Auto-rollback if latency triples
    .monitor_errors = true,
    .max_error_rate_pct = 1,          // Auto-rollback if errors exceed 1%
    .ramp_schedule = QC_RAMP_WEEKLY_DOUBLE  // Double percentage each week
};
qc_set_canary_config(&canary);

The canary system collects telemetry on operation latency, error rates, and interoperability success. If any monitored metric exceeds its threshold, the system automatically reverts to classical-only operation and generates an alert.

Crypto-Agility Patterns #

Crypto-agility is the ability to switch algorithms without code changes. The Universal API is inherently crypto-agile — applications that use policy-driven algorithm selection can adapt to new algorithms, parameter set changes, or security advisories through configuration updates alone.

Key crypto-agility patterns supported by the SDK include algorithm negotiation protocols for distributed systems, versioned key envelopes that embed algorithm metadata alongside encrypted data, policy hot-reloading for long-running services, and backward-compatible deserialization that can process data encrypted with any previously supported algorithm.

Rollback Safety #

Every migration step is designed with rollback safety. Hybrid keys can be decomposed back to their classical components. Canary percentages can be set to zero instantly. And the policy engine maintains a shadow configuration that can be activated in milliseconds if the primary policy encounters issues.

// Emergency rollback to classical-only
qc_emergency_rollback(QC_ROLLBACK_CLASSICAL_ONLY);

// Verify rollback state
qc_migration_state_t state;
qc_get_migration_state(&state);
printf("Mode: %s, PQC active: %s\n",
       state.mode_name, state.pqc_enabled ? "yes" : "no");

Backward Compatibility #

The SDK maintains full backward compatibility with classical cryptographic operations. Applications using the Universal API or OpenSSL provider can interoperate with peers that do not support PQC. The TLS integration gracefully falls back to classical key exchange when the remote peer does not advertise PQC support. Key serialization formats include algorithm version metadata so that older clients can process hybrid keys by extracting just the classical component.

Migration Monitoring #

The SDK provides a migration dashboard API that tracks the percentage of operations using PQC, hybrid operation success rates, performance comparisons between classical and PQC paths, and per-application migration status. Metrics are exported in Prometheus format for integration with existing monitoring infrastructure.