Strings of data used in cryptographic algorithms to encrypt, decrypt, sign, or verify data, serving as the secret parameters that transform plaintext to ciphertext and vice versa. Keys may be symmetric (single shared secret) or asymmetric (public-private pairs); their security depends on key length, entropy of generation, and rigorous lifecycle management.

Semantic Classification

Content

Definition

A cryptographic key is a string of data used to encrypt data (to keep the data secret), decrypt data (to perform the reverse operation), sign data (to ensure authenticity), or verify a signature. The security of any cryptographic system fundamentally depends on the secrecy, randomness, and proper management of its keys.

Key Types

By Encryption Method

Symmetric Keys

  • Single key used for both encryption and decryption

  • Must be shared securely between all parties

  • Faster and more efficient for bulk data encryption

  • Common algorithms: AES, ChaCha20, 3DES

  • Typical sizes: 128, 192, or 256 bits

    Asymmetric Keys (Public-Key Pairs)

  • Mathematically related pair: public key and private key

  • Public key encrypts data or verifies signatures

  • Private key decrypts data or creates signatures

  • No need to share private key, reducing exposure risk

  • Common algorithms: RSA, ECC, Ed25519

  • Typical sizes: 2048-4096 bits (RSA), 256-384 bits (ECC)

    By Function

  • Encryption Keys: Transform plaintext to ciphertext

  • Decryption Keys: Reverse the encryption process

  • Signing Keys: Create digital signatures (typically private keys)

  • Verification Keys: Verify digital signatures (typically public keys)

  • Master Keys: Root keys from which other keys are derived

  • Session Keys: Temporary keys for single communication session

  • Key Encryption Keys (KEK): Keys used to encrypt other keys

    Security Properties

PropertySymmetric KeysAsymmetric Keys
Key Size for Equivalent Security128-bit2048-bit (RSA)
SpeedVery fastSlower
Key DistributionChallengingEasier (public key shareable)
Use CaseBulk encryptionKey exchange, signatures

Blockchain Applications

  • Private Keys: Control access to blockchain addresses and funds

  • Public Keys: Derive addresses and verify transaction signatures

  • HD Wallet Keys: Hierarchically derived from master seed

  • Multi-sig Keys: Multiple keys required for transaction authorization

    Key Generation Requirements

  • High-entropy random number source (CSPRNG)

  • Sufficient key length for target security level

  • Algorithm-specific generation procedures

  • Protection against side-channel leakage during generation

    Hybrid Encryption

    Modern systems often combine both key types:

    1. Asymmetric encryption exchanges a symmetric session key
    2. Symmetric encryption handles bulk data (faster)
    3. Example: TLS/SSL in HTTPS communications

    Relationships

Current Landscape (2026)

  • The centre of gravity has shifted decisively to post-quantum key material: on 13 August 2024 NIST finalised FIPS 203 (ML-KEM, from CRYSTALS-Kyber) for key establishment alongside FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures, making quantum-resistant keys a ratified standard rather than a research topic.
  • Hybrid post-quantum key exchange is now the largest live deployment of PQC: the X25519MLKEM768 group (IANA code point 0x11EC) is enabled by default in Chrome (from v124, May 2024), Firefox, Edge and Safari, and on Cloudflare, AWS and Google edges, with over 30% of TLS 1.3 handshakes to Cloudflare negotiating a PQC hybrid by mid-2025 and OpenSSL 3.5 (April 2025) shipping ML-KEM in the mainline tree.
  • Regulatory deadlines have hardened the migration: NIST IR 8547 and NSA’s CNSA 2.0 deprecate RSA/ECC after 2030 and disallow them by 2035, CNSA 2.0 mandates that all new key-management and PKI systems support ML-KEM-1024 and ML-DSA-87 natively by end-2026, and US Executive Order 14412 with OMB memo M-26-15 (June 2026) set a hard target of PQC key establishment by 31 December 2030.
  • Key-management infrastructure is being re-tooled around larger PQC keys: KMIP 2.2 adds ML-KEM/ML-DSA key object types, PKCS#11 is being extended for PQC, AWS KMS added ML-DSA signing in FIPS 140-3 HSMs in 2025, and FIPS 140-3 Level 3 HSMs such as Thales Luna (and the new Luna 8, launched August 2026) now carry ML-KEM, ML-DSA and LMS/HSS in firmware with crypto-agile upgrade paths.
  • NIST is updating its foundational key-management guidance: SP 800-57 Part 1 Revision 6 (initial public draft December 2025, comments closed February 2026) folds in the FIPS 203/204/205 algorithms plus Ascon (SP 800-232) and separates key-establishment from key-storage keys for the first time.
  • Authentication keys are following: IANA added ML-DSA-44/65/87 to the COSE codelist on 24 April 2025, laying the standards groundwork for quantum-safe FIDO2 passkeys, though production passkeys still sign with P-256/Ed25519 pending browser and authenticator support expected around 2027-2028.
  • Open challenges as of 2026 centre on the certificate layer and algorithm diversity: PQC certificates lag key exchange (draft-ietf-tls-mldsa is still in working-group last call and no major browser negotiates ML-DSA server certificates by default), FN-DSA/FIPS 206 (Falcon) and the code-based HQC KEM backup (selected March 2025) remain unfinished and expected to finalise in 2026-2027, and enterprises face the harvest-now-decrypt-later threat while completing cryptographic inventory and crypto-agility work.

References

Provenance