Pluggable Cryptography

NTL’s most important security design decision: cryptography is a module, not a foundation.

The Problem with Hardcoded Crypto

Every major protocol today has cryptographic assumptions baked into its core:

TLS uses RSA or ECDSA for key exchange
Bitcoin uses secp256k1 for signatures
Ethereum uses ECDSA with keccak256
HTTPS certificates depend on RSA/ECC

When quantum computing breaks these schemes (not if — when), every protocol that hardcoded them faces an existential rewrite.

NTL’s Approach

NTL defines a CryptoModule interface that all cryptographic operations go through:

trait CryptoModule: Send + Sync {
    /// Generate a new keypair
    fn generate_keypair(&self) -> Result<(PublicKey, PrivateKey)>;

    /// Sign a signal
    fn sign(&self, data: &[u8], private_key: &PrivateKey) -> Result<Signature>;

    /// Verify a signature
    fn verify(&self, data: &[u8], signature: &Signature, public_key: &PublicKey) -> Result<bool>;

    /// Encrypt data for a recipient
    fn encrypt(&self, data: &[u8], recipient_public_key: &PublicKey) -> Result<Vec<u8>>;

    /// Decrypt data
    fn decrypt(&self, data: &[u8], private_key: &PrivateKey) -> Result<Vec<u8>>;

    /// Key exchange for synapse establishment
    fn key_exchange(
        &self,
        local_private: &PrivateKey,
        remote_public: &PublicKey,
    ) -> Result<SharedSecret>;

    /// Hash function
    fn hash(&self, data: &[u8]) -> Result<Hash>;

    /// Module identifier
    fn module_id(&self) -> &str;
}

Default Implementation

NTL ships with a default PostQuantumModule that uses:

Operation	Algorithm	Standard
Signatures	CRYSTALS-Dilithium	NIST PQC
Key Exchange	CRYSTALS-Kyber	NIST PQC
Encryption	AES-256-GCM (symmetric)	NIST
Hashing	BLAKE3	—

These are the current NIST Post-Quantum Cryptography standards. When they’re superseded, a new module is published — the protocol doesn’t change.

pq-v1 is specified but not implemented. The only module the reference implementation provides today is classical-v1 — Ed25519 signatures, X25519 key agreement, BLAKE3 hashing. See spec/crypto-interface for the full status table.A node configured for a module this build cannot provide fails to start, naming the modules it does support. It does not silently fall back: an operator who asked for post-quantum signing and got Ed25519 has been told the opposite of the truth about their deployment’s confidentiality horizon.

Swapping Modules

crypto_module is a top-level field, not a [crypto] table:

crypto_module = "classical-v1"   # the only module implemented today
# crypto_module = "pq-v1"        # specified; not yet available
# crypto_module = "hybrid-v1"    # specified; not yet available

Nodes negotiate crypto modules during the synapse handshake. If two nodes support different modules they fall back to the highest common module, or refuse the synapse.

Hybrid Mode

Design, not shipped. hybrid-v1 is specified; no implementation provides it yet.

The intent is that during the transition period a hybrid mode signs and encrypts with both classical and post-quantum algorithms. This provides backward compatibility with systems that don’t yet support PQ crypto while maintaining quantum resistance.

// Hybrid signature: valid if EITHER scheme verifies
// (protects against implementation bugs in new PQ schemes)
HybridSignature {
    classical: Ed25519Signature,
    post_quantum: DilithiumSignature,
}

Introduction

Core Concepts

Guides

Adapters

Security

Governance

The Problem with Hardcoded Crypto

NTL’s Approach

Default Implementation

Swapping Modules

Hybrid Mode

​The Problem with Hardcoded Crypto

​NTL’s Approach

​Default Implementation

​Swapping Modules

​Hybrid Mode

The Problem with Hardcoded Crypto

NTL’s Approach

Default Implementation

Swapping Modules

Hybrid Mode