Fact-checked by Grok 2 weeks ago

Cryptographic key types

Cryptographic key types encompass the diverse categories of keys employed in cryptographic systems to protect data confidentiality, , , and . These are primarily divided into symmetric keys—which are identical secrets shared between parties—and asymmetric key pairs, consisting of a private key known only to the owner and a corresponding public key available to others. Keys can also be classified by usage (e.g., long-term or ephemeral) and function (e.g., session or master keys). These keys enable core mechanisms such as , message authentication, digital signatures, and key establishment, with their design ensuring secure operations in protocols like TLS and . Symmetric keys, also known as secret keys, are used in algorithms where the same key performs both and decryption or tasks, offering efficiency for bulk data protection but requiring secure distribution to prevent compromise. Notable subtypes include data-encryption keys for , keys for and source verification, key-wrapping keys for secure key transport, key-agreement keys for derivation, and master or key-derivation keys for generating subordinate keys. These keys demand high protection due to their shared nature and are subject to cryptoperiods—limited usage durations—to mitigate risks from prolonged exposure. Asymmetric keys, rooted in , support operations where the public key handles accessible functions like or , while the private key performs sensitive ones like decryption or signing, enabling without prior . Key subtypes include private signature keys for creating digital signatures, public signature- keys for validation, private and public key-transport keys for , private and public static or ephemeral key-agreement keys for computation (with ephemeral providing ), and private and public or keys for and access . Private asymmetric keys require stringent , whereas public keys prioritize to prevent tampering. Overall, the selection of key types depends on the —such as for symmetric encryption or /ECDSA for asymmetric signing—and must align with standards like those from NIST to ensure interoperability and security against evolving threats, including risks addressed in post-quantum variants such as ML-KEM and ML-DSA standardized in 2024.

Basic Classifications

Symmetric Keys

A symmetric key is a single cryptographic key used with a for both and decryption operations, where the key remains secret and is shared only among authorized parties. In these algorithms, the same key performs complementary functions, such as transforming into and reversing the process, ensuring that only entities possessing the key can access the data. This must be distributed securely in advance, often through methods, to prevent interception by adversaries. Symmetric keys power various encryption primitives, including block ciphers that process data in fixed-size blocks and stream ciphers that generate a keystream for bitwise operations. Prominent examples include the (AES), a that operates on 128-bit blocks using keys of 128, 192, or 256 bits—such as AES-128 for standard security needs—and the older (DES), a 64-bit with a 56-bit effective key length that was withdrawn by NIST in 2005 and is no longer approved for use. , standardized by NIST in 2001, has become the de facto global standard for symmetric due to its robustness. For stream ciphers, generates a pseudorandom keystream but is now deprecated owing to vulnerabilities, such as statistical biases enabling recovery in protocols like TLS. The primary advantages of symmetric keys lie in their computational efficiency and high speed, making them ideal for encrypting large volumes of in resource-constrained environments. These algorithms require fewer resources than asymmetric counterparts, enabling fast bulk for applications like data storage and network traffic protection. However, a key disadvantage is the challenge of secure , as the must be exchanged without exposure, often necessitating additional protocols or physical delivery. Compromise of a single key can jeopardize all associated communications, amplifying risks in multi-party scenarios. Historically, symmetric cryptography traces its roots to early 20th-century innovations like the , patented by in 1917, which uses a truly random key as long as the message for perfect secrecy when applied correctly. This concept influenced later developments, evolving into standardized block ciphers during the 1970s when the National Bureau of Standards (now NIST) selected an design for , issued as a federal standard in 1977 to protect unclassified sensitive data. 's adoption marked the first public cryptographic standard, though its short key length prompted calls for stronger successors like . In contrast to asymmetric keys, symmetric approaches rely on prior secure sharing, highlighting their suitability for high-performance encryption rather than initial .

Asymmetric Keys

Asymmetric keys, also known as , consist of a mathematically related pair comprising a public key, which can be freely distributed, and a private key, which must remain secret to its owner. This dual-key system enables and without the need for prior exchange of secret information between parties. The core mechanism of asymmetric keys relies on computationally hard mathematical problems to ensure security. The public key is used for of messages or verification of digital signatures, while the private key performs decryption or generates signatures. Common foundations include the problem for the algorithm, introduced by Rivest, Shamir, and Adleman in 1977, and the elliptic curve discrete logarithm problem for , proposed independently by Koblitz in 1985 and in 1985. Asymmetric cryptography originated with the 1976 paper by Diffie and Hellman, which outlined the concept of public-key distribution to address over insecure channels. Key advantages of asymmetric keys include solving the problem inherent in symmetric systems, allowing parties to communicate securely without pre-shared secrets. They also enable digital signatures, providing proof of origin, integrity, and , as the private key's use in signing ensures only the owner could have produced a valid signature verifiable by the public key. Specific examples include , with recommended key sizes of 2048 to 4096 bits for current security levels, and , with 256 to 521 bits offering equivalent strength but smaller sizes. However, asymmetric keys have disadvantages, including slower performance and higher computational overhead compared to symmetric methods, due to the of the underlying mathematical operations. In practice, asymmetric keys often initiate secure sessions in schemes, where they exchange symmetric keys for efficient .

Usage-Based Classifications

Long-Term Keys

Long-term keys, also referred to as static or persistent keys, are cryptographic keys designed for prolonged use over extended periods, often spanning multiple sessions, transactions, or even years, rather than being discarded after a single operation. These keys are generated once and reused to maintain consistent , , or capabilities in cryptographic systems. According to NIST guidelines, they include both symmetric keys, such as those for data or key wrapping, and asymmetric keys, like private or static key-agreement s, which are integral to key establishment schemes involving repeated invocations. As of 2025, long-term asymmetric keys are increasingly migrated to post-quantum variants, such as those using ML-DSA for , to resist quantum attacks. In practice, long-term keys underpin critical functions in secure protocols and infrastructures. Within public key infrastructure (PKI), they serve as the private components of digital certificates, facilitating authentication and secure communications; for example, a certificate authority's (CA) root private key signs subordinate certificates to establish trust chains across an ecosystem. In the Transport Layer Security (TLS) protocol, the server's private key functions as a long-term key to authenticate the server during handshakes and support key exchanges, while avoiding direct use in ephemeral session derivation to preserve forward secrecy. Similarly, in the Secure Shell (SSH) protocol, host and user private keys act as persistent identifiers for authenticating servers and users across multiple connections, enabling secure remote access without regenerating credentials each time. The security of long-term keys necessitates stringent protection due to their extended lifespan, which amplifies vulnerability to attacks like or unauthorized disclosure. NIST recommends robust storage mechanisms, such as hardware security modules, and regular auditing to prevent compromise, emphasizing that their strength is limited by the weakest link in the chain, including and . Key rotation is advised every 1-2 years for symmetric data-encryption keys or static key-agreement keys, and 1-3 years for private keys, with immediate re-keying upon detection of compromise or expiration of the cryptoperiod to transition to stronger parameters as threats evolve, including post-quantum algorithms. A primary of long-term keys lies in their potential for broad impact if breached, as a single compromise can retroactively expose encrypted data or enable ongoing impersonation across all dependent operations, unlike the limited scope of ephemeral keys used temporarily for single sessions. To counter this, protocols incorporate mechanisms; in PKI, certificate lists (CRLs) enable to invalidate and list compromised by , ensuring relying parties can verify status before trusting the associated long-term key, with CRLs issued periodically and signed for integrity. Effective management, including secure distribution and contingency planning, is essential to minimize recovery costs and maintain system integrity.

Ephemeral Keys

Ephemeral keys are cryptographic keys generated for each execution of a key-establishment , meeting requirements such as uniqueness to each transaction or session. They are temporary by design, created and discarded after a single use to minimize exposure risks. These keys are typically derived on-the-fly using cryptographically secure pseudorandom number generators compliant with standards like , ensuring sufficient entropy for security. Their lifetimes are inherently brief, confined to the duration of one session or operation, often spanning seconds to hours based on protocol specifics. In practice, ephemeral keys play a central role in secure key exchange protocols to establish session-specific secrets. For example, in the Transport Layer Security (TLS) protocol, ephemeral Diffie-Hellman (DHE) and elliptic curve Diffie-Hellman ephemeral (ECDHE) cipher suites employ fresh key pairs generated by each party during the handshake. These are exchanged to compute a premaster secret, from which the session keys are derived, as seen in HTTPS connections where they secure initial negotiations. As of 2025, hybrid post-quantum ephemeral key exchanges, combining classical ECDHE with ML-KEM, are supported in TLS to provide quantum resistance. Likewise, the Signal protocol's PQXDH (Post-Quantum X3DH) key agreement uses an ephemeral key pair for each initial message, combining it with the recipient's prekeys to derive a shared secret via hybrid classical and post-quantum computations, with the Sparse Post-Quantum Ratchet (SPQR) advancing secrecy per message. The key security advantage of ephemeral keys lies in enabling perfect (PFS), where session keys remain protected even if long-term private keys are later compromised, since each session relies on distinct, discarded ephemerals. This approach confines potential damage to individual sessions, preventing widespread decryption of historical communications. In the Signal protocol's Double mechanism, enhanced by SPQR as of 2025, new ephemeral key pairs are generated per message, advancing the ratchet to provide ongoing forward secrecy and recovery from key compromises. Ephemeral keys are frequently paired with long-term keys, which provide persistent while ephemerals handle transient .

Functional Key Types

Session Keys

Session keys are short-term symmetric cryptographic keys employed to encrypt and decrypt data exchanged during a single communication session, ensuring for the duration of that interaction. Unlike long-term keys, they are designed for temporary use to limit exposure risks if compromised, typically employing algorithms such as for efficient bulk encryption. These keys are commonly established through key agreement protocols that leverage asymmetric cryptography, for example, by deriving the shared secret via the Diffie-Hellman key exchange using ephemeral public keys, or alternatively from pre-shared symmetric secrets in scenarios requiring . This derivation process ensures that the session key is unique to the participants and the specific session, often incorporating additional to enhance security. In practical applications, session keys secure the bulk data transfer phase in protocols like TLS and following the initial authentication and . For instance, in TLS 1.3, the handshake generates traffic keys from the to protect application data, while in , they encrypt packets within s established by IKEv2. Their lifetime is confined to the session's duration—such as a single TLS connection or an , typically lasting minutes to hours—after which they are discarded and new keys are generated for subsequent sessions to mitigate replay and long-term compromise risks. Representative examples include AES-256 session keys used in IPsec-based VPN tunnels to encrypt network traffic, providing robust protection for remote access. Historically, served as the basis for session keys in the deprecated (WEP) protocol for wireless networks, but its weaknesses, including vulnerability to key stream reuse attacks, led to its deprecation in IEEE 802.11i in favor of stronger alternatives like WPA2.

Master and Root Keys

Master keys, also known as root keys in certain contexts, serve as top-level cryptographic secrets within a system, employed to derive subordinate keys through key-derivation methods or to wrap other keys for enhanced . These keys form the foundation of key hierarchies, enabling the systematic generation and protection of lower-level keys without exposing the master directly to operational use. In essence, a master key acts as a pseudorandom source from which multiple derived keys can be produced, ensuring that the compromise of a subordinate key does not necessarily reveal the master. Master and root keys find application in structured key hierarchies, prominently in Modules (HSMs) where they oversee the encryption and management of transaction or data keys, and in protocols like for securing authentication databases. In , the master key encrypts the long-term keys of service principals stored in the database, facilitating secure ticket issuance without direct exposure. Root keys, particularly in (PKI), anchor the chain of trust by serving as the private keys of root Certification Authorities (), which sign certificates for intermediate CAs to propagate trust throughout the system. Due to their pivotal role, and keys demand the highest levels of , as their compromise could to undermine the entire cryptographic ecosystem, including all derived or protected keys. They are typically stored and managed within secure like HSMs, which provide tamper-resistant environments for , storage, and operations to mitigate risks from physical or logical attacks. Illustrative examples include the master key, denoted as K/M for the principal K/M@, which encrypts ticket-granting tickets and protects the principal database against unauthorized access. In PKI, root CA private keys sign the certificates of subordinate s, establishing verifiable trust paths for end-entity certificates used in secure communications. In hierarchical structures, master keys derive session or operational keys using standardized functions such as (HMAC-based Extract-and-Expand Key Derivation Function), which extracts entropy from the master key and expands it into multiple pseudorandom outputs for specific uses. Root keys, meanwhile, underpin the chain of trust in PKI by enabling the validation of certification paths from end-user certificates back to the trusted root. This derivation process, often leveraging key derivation keys as intermediaries, ensures scalability and compartmentalization in complex systems.

Key Derivation Keys

Key derivation keys, also known as derivation secrets, serve as the primary inputs to key derivation functions (KDFs), which deterministically generate one or more child keys from a single source secret, such as a or , along with additional parameters like salts or nonces. These functions transform potentially low-entropy inputs into cryptographically secure keys suitable for , , or other purposes, ensuring that the output keys are indistinguishable from random without knowledge of the input. The mechanism of key derivation relies on specialized algorithms designed to "stretch" short or weak secrets into robust keys by incorporating computational overhead, salts, and multiple iterations to resist brute-force and dictionary attacks. Common algorithms include , which applies a pseudorandom (PRF) like HMAC-SHA-256 iteratively with a to derive keys from passwords, as specified for storage applications. employs an extract-then-expand approach using HMAC-based PRFs to first extract uniform randomness from the input secret and , then expand it into multiple keys with contextual labels. Similarly, functions as a memory-hard KDF, enforcing high and CPU costs during derivation to hinder parallelized attacks on low-entropy inputs like passphrases. These methods ensure that even identical inputs produce unique outputs when salts vary, while the iteration counts or requirements slow down adversaries. In practice, key derivation keys are employed in password-based systems to generate encryption keys from user , enhancing security in scenarios where high-entropy keys cannot be directly entered, and in network protocols for session establishment. For instance, in , a serves as the derivation secret, processed via PBKDF2-HMAC-SHA1 with the network's SSID as salt to produce the (PSK) for subsequent authentication. Master keys may occasionally act as inputs to such derivations for hierarchical in protocols. From a security perspective, salting in KDFs is crucial for preventing rainbow table attacks, where precomputed hash chains could otherwise accelerate password cracking, as the unique salt per derivation invalidates reusable tables. Iterations and memory-hardness further elevate the computational cost, making exhaustive searches impractical on commodity hardware. The resulting child keys can support symmetric encryption (e.g., keys) or serve as components in asymmetric schemes, such as deriving shared secrets for Diffie-Hellman exchanges. Prominent examples illustrate widespread adoption: is integral to TLS 1.3, where handshake secrets derive traffic encryption keys, application traffic keys, and other materials to ensure and secure key separation. For modern password storage, provides a memory-hard alternative, recommended for deriving keys or hashes resistant to GPU-accelerated attacks, with variants like Argon2id balancing side-channel resistance and data-dependency for key derivation tasks.

Security and Management Considerations

Key Sizes and Strengths

Key size in refers to the length of a measured in bits, which fundamentally determines the algorithm's resistance to brute-force attacks by exponentially increasing the computational effort required to exhaustively search the space. For symmetric algorithms, such as the (AES), a 128-bit provides 128 bits of strength, making AES-128 suitable for many applications, while AES-256 offers 256 bits of for enhanced protection. In contrast, asymmetric algorithms require significantly larger keys to achieve equivalent levels due to their reliance on harder mathematical problems; for instance, a 2048-bit yields only 112 bits of , whereas a 3072-bit achieves 128 bits, and (ECC) is more efficient, with a 256-bit providing 128 bits of . NIST guidelines, updated in the 2020s through Special Publication 800-57 Revision 5, recommend AES-256 for long-term data protection exceeding 20 years and favor 256-bit keys over larger equivalents for their computational efficiency in resource-constrained environments. , with an effective 112-bit security strength despite its 168-bit nominal , has been deprecated, with NIST prohibiting the generation of new keys after December 31, 2023, and aligning current standards under to exclude it from approved modules except for legacy decryption. Larger key sizes enhance security by raising the attack complexity but introduce trade-offs, including increased computational overhead, slower encryption/decryption speeds, and higher storage requirements, which can impact performance in high-throughput systems. Emerging quantum threats, particularly , render current asymmetric keys vulnerable by enabling efficient factorization and discrete logarithm solving, necessitating with larger or alternative key structures; for symmetric keys, halves effective security, prompting recommendations to double sizes, such as using AES-256 to maintain 128-bit post-quantum security. In August 2024, NIST published the first three (FIPS) for : FIPS 203 (ML-KEM for key encapsulation), FIPS 204 (ML-DSA for digital signatures), and FIPS 205 (SLH-DSA for digital signatures). Additional algorithms, such as HQC, were selected for in March 2025.
Security Strength (bits)Symmetric Key SizeRSA Key SizeECC Key Size
1121122048224
1281283072256
1921927680384
25625615360521
These mappings, per NIST SP 800-57, illustrate the disproportionate sizing needs between symmetric and asymmetric keys to achieve comparable protection levels.

Key Generation and Storage

Cryptographic keys must be generated using cryptographically secure (CSPRNGs) to ensure sufficient unpredictability and to attacks. Approved CSPRNGs, such as those specified in NIST Special Publication 800-90A, employ deterministic random bit generators (DRBGs) based on functions, , or block ciphers like to produce high-quality random bits from an initial seed. Weak pseudorandom sources, such as the standard C library's rand() function, must be avoided as they lack adequate and can lead to predictable keys vulnerable to brute-force or prediction attacks. Key generation processes can be either fully random, drawing directly from high-entropy sources like noise generators, or deterministic, deriving keys from a high-entropy seed using mechanisms like key derivation functions (KDFs) or DRBGs. For security, the entropy input must match or exceed the desired security strength of the key; for instance, an AES-256 key requires at least 256 bits of to prevent exhaustive search within feasible computational bounds. NIST recommends obtaining random bits solely from approved random bit generators (RBGs) outlined in SP 800-90A, SP 800-90B, and SP 800-90C to meet these requirements. Secure storage of cryptographic keys is essential to prevent unauthorized access and compromise. Hardware-based solutions, such as Trusted Platform Modules (TPMs) and Hardware Security Modules (HSMs), provide tamper-resistant environments for key storage and operations, often validated under standards. TPMs integrate directly into computing platforms to protect keys bound to specific hardware states, while HSMs offer dedicated, isolated processing for enterprise-scale key management. In software environments, encrypted vaults like Apple's store keys using AES-256-GCM with separate table and per-row keys, ensuring data remains protected even if the storage medium is accessed. Key wrapping enhances storage security by encrypting a key with a stronger or more protected wrapping key, allowing safe transmission or archival without exposing the plaintext key. Best practices include zeroization—securely overwriting keys with random data or zeros immediately after use to prevent recovery from memory or storage—and implementing strict access controls to limit key exposure to authorized processes only. Compliance with standards like ensures interoperable key management interfaces that support secure generation, storage, and destruction across diverse cryptographic tokens and devices. A in and is side-channel attacks, such as timing attacks, where variations in execution time reveal about . Mitigation involves using constant-time implementations that perform operations in fixed time regardless of input values, thereby eliminating measurable timing differences that could leak secrets.

References

  1. [1]
  2. [2]
  3. [3]
  4. [4]
  5. [5]
    [PDF] Vernam, Mauborgne, and Friedman: The One-Time Pad and the ...
    May 7, 2014 · The one-time pad as we know it today is generally credited to Gilbert Vernam and Joseph O. Mauborgne [22].<|separator|>
  6. [6]
    Cryptography | CSRC - NIST Computer Security Resource Center
    In the early 1970s, the National Bureau of Standards (NBS) initiated the development of a symmetric key cryptographic algorithm standard that could be used by ...
  7. [7]
    [PDF] New Directions in Cryptography - Stanford University
    DIFFIE. AND. HELLMAN: NEW. DIRECTIONS. IN CRYPTOGRAPHY. 653 of possible keys. Though the problem is far too difficult to be laid to rest by such simple methods ...
  8. [8]
    [PDF] A Method for Obtaining Digital Signatures and Public-Key ...
    We demonstrate in this paper how to build these capabilities into an electronic mail system. At the heart of our proposal is a new encryption method. This ...
  9. [9]
    Static key - Glossary | CSRC
    Definitions: A key that is intended for use for a relatively long period of time and is typically intended for use in many instances of a cryptographic key- ...
  10. [10]
    RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
    Below is a merged summary of RFC 8446 regarding mentions of long-term keys or static keys in TLS, especially in the PKI or certificate context. To retain all information in a dense and organized manner, I’ll use a combination of narrative text and a table in CSV format for key details. The response consolidates all segments while avoiding redundancy and ensuring completeness.
  11. [11]
    RFC 4253 - The Secure Shell (SSH) Transport Layer Protocol
    This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure ...Missing: long- | Show results with:long-
  12. [12]
    RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
    Below is a merged summary of the Certificate Revocation Lists (CRLs) and their use for long-term keys in PKI based on RFC 5280. The information is consolidated into a dense, structured format, including tables where appropriate to retain all details efficiently. The response avoids unnecessary repetition while ensuring all key points, sections, and URLs from the individual summaries are included.
  13. [13]
    Ephemeral Key - Glossary | CSRC
    ### Summary of Ephemeral Key Definition and Usage
  14. [14]
    [PDF] NIST.SP.800-52r2.pdf
    Aug 2, 2019 · Prefer ephemeral keys over static keys (i.e., prefer DHE over DH, and prefer ECDHE over ECDH). Ephemeral keys provide perfect forward secrecy.
  15. [15]
  16. [16]
  17. [17]
    Specifications >> The X3DH Key Agreement Protocol - Signal
    Nov 4, 2016 · Compromise of a party's private keys has a disastrous effect on security, though the use of ephemeral keys and prekeys provides some mitigation.Keys · Publishing keys · Sending the initial message · Protocol replay
  18. [18]
  19. [19]
  20. [20]
    RFC 4107 - Guidelines for Cryptographic Key Management
    Oct 14, 2015 · Automated key management derives one or more short-term session keys. The key derivation function may make use of long-term keys to ...<|control11|><|separator|>
  21. [21]
    [PDF] Recommendation for Pair-Wise Key-Establishment Schemes Using ...
    Apr 3, 2018 · Table 20: One-pass Diffie-Hellman key-agreement scheme summary ... Hitchcock, On Session Key Construction in. Provably-Secure Key ...
  22. [22]
  23. [23]
    [PDF] Guide to IPsec VPNs - NIST Technical Series Publications
    Jun 1, 2020 · IPsec endpoints create session keys that are changed frequently, typically once an hour. Afterwards, the endpoints wipe the old session keys.
  24. [24]
    RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2)
    This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication.
  25. [25]
    Master key - Glossary | CSRC
    A key used with a key-derivation method to derive additional keys. Sometimes called a master key. Sources: NIST SP 800-57 Part 1 Rev. 5 under Key-derivation key
  26. [26]
    [PDF] A Framework for Designing Cryptographic Key Management Systems
    HMAC can be used with a NIST-approved cryptographic hash function, in combination with a shared secret key. ... cryptographic methods that are approved for “key ...
  27. [27]
    None
    Below is a merged and comprehensive summary of cryptographic key types from NIST SP 800-57 Part 1 Rev. 5, consolidating all information from the provided segments. To maximize detail and clarity, I’ve organized the content into sections with tables in CSV format where appropriate (e.g., for key types, purposes, and classifications). This response retains all unique details while avoiding redundancy and adheres to the constraint of no thinking tokens by focusing solely on the extracted and summarized data.
  28. [28]
    RFC 4120 - The Kerberos Network Authentication Service (V5)
    This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and ...
  29. [29]
    RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and ...
    1. Authority Key Identifier The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign ...
  30. [30]
    Hardware Security Module (HSM) - Glossary | CSRC
    A physical computing device that safeguards and manages cryptographic keys and provides cryptographic processing. An HSM is or contains a cryptographic ...Missing: hierarchy | Show results with:hierarchy
  31. [31]
    RFC 5869 - HMAC-based Extract-and-Expand Key Derivation ...
    This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in ...
  32. [32]
    Key-derivation function - Glossary | CSRC
    A function used to derive secret keying material from a shared secret (or a key) and other information.
  33. [33]
    [PDF] Recommendation for Key-Derivation Methods in Key-Establishment ...
    Aug 2, 2020 · This Recommendation specifies techniques for the derivation of keying material from a shared secret established during a key-establishment ...
  34. [34]
    [PDF] NIST SP 800-132, Recommendation for Password-Based Key ...
    Cryptographic key (key) A binary string that is used as a parameter by a cryptographic algorithm.
  35. [35]
    RFC 7914 - The scrypt Password-Based Key Derivation Function
    ... key derivation function scrypt. The function derives one or more secret ... The object identifier id-scrypt identifies the scrypt key derivation function.
  36. [36]
    [PDF] Recommendation for Key Derivation Using Pseudorandom Functions
    Aug 1, 2022 · Key-Derivation Function (KDF) ... An improperly defined key-derivation function can make the derived keying material vulnerable to attacks.
  37. [37]
    RFC 8009
    Oct 5, 2016 · ... derive the base-key from a passphrase and salt. The string-to-key ... Salting prevents "rainbow table" attacks, while large iteration counts slow ...
  38. [38]
    RFC 9106 - Argon2 Memory-Hard Function for Password Hashing ...
    Dec 8, 2023 · ... key derivation. Argon2id works as Argon2i for the first half of the first pass over the memory and as Argon2d for the rest, thus providing ...
  39. [39]
    NIST to Withdraw Special Publication 800-67 Revision 2 | CSRC
    NIST will withdraw Special Publication (SP) 800-67 Revision 2, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, on January 1, 2024.
  40. [40]
    Post-Quantum Cryptography | CSRC
    Based on such understanding, current applications can continue to use AES with key sizes 128, 192, or 256 bits. NIST will issue guidance regarding any ...
  41. [41]
    [PDF] Recommendation for Cryptographic Key Generation
    Symmetric-key algorithm A cryptographic algorithm that uses the same secret key for its operation and, if applicable, for reversing the effects of the ...
  42. [42]
    SP 800-90A Rev. 1, Recommendation for Random Number ...
    Jun 24, 2015 · This Recommendation specifies mechanisms for the generation of random bits using deterministic methods. The methods provided are based on either ...Missing: pseudorandom CSPRNG
  43. [43]
    RFC 4086 - Randomness Requirements for Security
    This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities.
  44. [44]
    [PDF] Hardware Enabled Security - NIST Technical Series Publications
    Apr 20, 2022 · cryptographic processing inside the HSM3 where the private key is stored. ... private key is then pushed to the attestation and secure key storage ...
  45. [45]
    [PDF] Trusted Platform Module ST33TPHF20SPI & ST33TPHF20I2C
    The security module is used primarily for cryptographic key generation, key storage and key management as well as generation and secure storage for digital ...
  46. [46]
    Keychain data protection - Apple Support
    Dec 19, 2024 · Keychain items are encrypted using two different AES-256-GCM keys: a table key (metadata) and a per-row key (secret key).
  47. [47]
    [PDF] Recommendation for Block Cipher Modes of Operation
    This document describes key wrapping methods, including AES Key Wrap (KW) and AES Key Wrap With Padding (KWP) modes, and TKW for TDEA.Missing: practices | Show results with:practices
  48. [48]
    PKCS#11 Cryptographic Token Interface Base Specification OASIS ...
    This document defines data types, functions and other basic components of the PKCS #11 Cryptoki interface.
  49. [49]
    Guidelines for Mitigating Timing Side Channels Against ... - Intel
    Jun 29, 2022 · Learn how cryptographic implementations use constant time principles to help protect secret data from traditional side channel attacks.