Hubbry Logo
Key (cryptography)Key (cryptography)Main
Open search
Key (cryptography)
Community hub
Key (cryptography)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Key (cryptography)
Key (cryptography)
Key (cryptography)
View on Wikipedia
from Wikipedia

A key in cryptography is a piece of information, usually a string of numbers or letters that are stored in a file, which, when processed through a cryptographic algorithm, can encode or decode cryptographic data. Based on the used method, the key can be different sizes and varieties, but in all cases, the strength of the encryption relies on the security of the key being maintained. A key's security strength is dependent on its algorithm, the size of the key, the generation of the key, and the process of key exchange.

Scope

[edit]

The key is what is used to encrypt data from plaintext to ciphertext.[1] There are different methods for utilizing keys and encryption.

Symmetric cryptography

[edit]

Symmetric cryptography refers to the practice of the same key being used for both encryption and decryption.[2]

Asymmetric cryptography

[edit]

Asymmetric cryptography has separate keys for encrypting and decrypting.[3][4] These keys are known as the public and private keys, respectively.[5]

Purpose

[edit]

Since the key protects the confidentiality and integrity of the system, it is important to be kept secret from unauthorized parties. With public key cryptography, only the private key must be kept secret, but with symmetric cryptography, it is important to maintain the confidentiality of the key. Kerckhoff's principle states that the entire security of the cryptographic system relies on the secrecy of the key.[6]

Key sizes

[edit]
Main article: Key size

Key size is the number of bits in the key defined by the algorithm. This size defines the upper bound of the cryptographic algorithm's security.[7] The larger the key size, the longer it will take before the key is compromised by a brute force attack. Since perfect secrecy is not feasible for key algorithms, researches are now more focused on computational security.

In the past, keys were required to be a minimum of 40 bits in length, however, as technology advanced, these keys were being broken quicker and quicker. As a response, restrictions on symmetric keys were enhanced to be greater in size.

Currently, 2048 bit RSA[8] is commonly used, which is sufficient for current systems. However, current RSA key sizes would all be cracked quickly with a powerful quantum computer.[9]

"The keys used in public key cryptography have some mathematical structure. For example, public keys used in the RSA system are the product of two prime numbers. Thus public key systems require longer key lengths than symmetric systems for an equivalent level of security. 3072 bits is the suggested key length for systems based on factoring and integer discrete logarithms which aim to have security equivalent to a 128 bit symmetric cipher."[10]

Key generation

[edit]
Main article: Key generation

To prevent a key from being guessed, keys need to be generated randomly and contain sufficient entropy. The problem of how to safely generate random keys is difficult and has been addressed in many ways by various cryptographic systems. A key can directly be generated by using the output of a Random Bit Generator (RBG), a system that generates a sequence of unpredictable and unbiased bits.[11] A RBG can be used to directly produce either a symmetric key or the random output for an asymmetric key pair generation. Alternatively, a key can also be indirectly created during a key-agreement transaction, from another key or from a password.[12]

Some operating systems include tools for "collecting" entropy from the timing of unpredictable operations such as disk drive head movements. For the production of small amounts of keying material, ordinary dice provide a good source of high-quality randomness.

Establishment scheme

[edit]
Main article: Key exchange

The security of a key is dependent on how a key is exchanged between parties. Establishing a secured communication channel is necessary so that outsiders cannot obtain the key. A key establishment scheme (or key exchange) is used to transfer an encryption key among entities. Key agreement and key transport are the two types of a key exchange scheme that are used to be  remotely exchanged between entities . In a key agreement scheme, a secret key, which is used between the sender and the receiver to encrypt and decrypt information, is set up to be sent indirectly. All parties exchange information (the shared secret) that permits each party to derive the secret key material. In a key transport scheme, encrypted keying material that is chosen by the sender is transported to the receiver. Either symmetric key or asymmetric key techniques can be used in both schemes.[12]

The Diffie–Hellman key exchange and Rivest-Shamir-Adleman (RSA) are the most two widely used key exchange algorithms.[13] In 1976, Whitfield Diffie and Martin Hellman constructed the Diffie–Hellman algorithm, which was the first public key algorithm. The Diffie–Hellman key exchange protocol allows key exchange over an insecure channel by electronically generating a shared key between two parties. On the other hand, RSA is a form of the asymmetric key system which consists of three steps: key generation, encryption, and decryption.[13]

Key confirmation delivers an assurance between the key confirmation recipient and provider that the shared keying materials are correct and established. The National Institute of Standards and Technology recommends key confirmation to be integrated into a key establishment scheme to validate its implementations.[12]

Management

[edit]
Main article: Key management

Key management concerns the generation, establishment, storage, usage and replacement of cryptographic keys. A key management system (KMS) typically includes three steps of establishing, storing and using keys. The base of security for the generation, storage, distribution, use and destruction of keys depends on successful key management protocols.[14]

Key vs password

[edit]

A password is a memorized series of characters including letters, digits, and other special symbols that are used to verify identity. It is often produced by a human user or a password management software to protect personal and sensitive information or generate cryptographic keys. Passwords are often created to be memorized by users and may contain non-random information such as dictionary words.[12] On the other hand, a key can help strengthen password protection by implementing a cryptographic algorithm which is difficult to guess or replace the password altogether. A key is generated based on random or pseudo-random data and can often be unreadable to humans.[15]

A password is less safe than a cryptographic key due to its low entropy, randomness, and human-readable properties. However, the password may be the only secret data that is accessible to the cryptographic algorithm for information security in some applications such as securing information in storage devices. Thus, a deterministic algorithm called a key derivation function (KDF) uses a password to generate the secure cryptographic keying material to compensate for the password's weakness. Various methods such as adding a salt or key stretching may be used in the generation.[12]

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Key (cryptography)

View on Grokipedia
from Grokipedia
In cryptography, a key is a parameter used within a cryptographic to transform into or vice versa, thereby ensuring data , , or authenticity. These keys are essential components of cryptographic systems, enabling , data protection, and digital signatures by controlling the operations of , decryption, signature generation, and verification. Cryptographic keys are broadly classified into two main categories based on the underlying algorithms: symmetric and asymmetric. Symmetric keys, also known as secret keys, are shared between parties and used for both and decryption in algorithms like AES, providing efficiency for bulk data protection but requiring secure to prevent compromise. In contrast, asymmetric keys consist of a public-private key pair, where the public key can be freely distributed for or verification, while the private key remains secret for decryption or signing, as utilized in systems like RSA or ECC. Effective key management is critical to the security of cryptographic systems, encompassing the secure , distribution, storage, use, and destruction of keys to mitigate risks such as key compromise or unauthorized access. Standards like NIST SP 800-57 outline best practices, including defining cryptoperiods—the allowable usage duration for keys—to balance and operational needs, with symmetric keys often limited to shorter periods than asymmetric ones. Advances in have prompted ongoing research into post-quantum cryptographic keys resistant to emerging threats. In response, NIST has standardized several post-quantum algorithms, such as ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) in August 2024, with further selections like HQC in March 2025.

Fundamentals

Definition

A cryptographic key is a value used to control cryptographic operations, such as , decryption, generation, or verification. Typically, it consists of a fixed-length string of bits or bytes that serves as a for a cryptographic . In symmetric , the key KK is used in the function E(M,K)=CE(M, K) = C to transform MM into CC, and in the decryption function D(C,K)=MD(C, K) = M to recover the original . This notation illustrates the key's role in reversible data transformation within symmetric schemes, though keys are also employed in asymmetric for related purposes. Symmetric keys and private keys in asymmetric systems must remain secret to prevent unauthorized access to protected data, as their disclosure compromises the of the associated algorithms. They require sufficient length to resist brute-force attacks— for instance, providing at least 112 bits of strength for many applications—and must be generated with high to ensure unpredictability and randomness. Unlike non-cryptographic keys, such as API keys used primarily for access control and authentication without transforming data via algorithms, cryptographic keys are integral to mathematical operations that secure or verify information.

Historical Development

The concept of a cryptographic key originated in ancient times with simple substitution ciphers, such as the Caesar cipher employed by Julius Caesar in the 1st century BCE, where the key was a fixed numerical shift in the alphabet, typically by three positions, to encode military messages. This monoalphabetic approach relied on secrecy of the shift value as the key, marking an early instance of keys as secret parameters for encryption. By the 16th century, advancements led to polyalphabetic ciphers like the Vigenère cipher, introduced by Blaise de Vigenère, which used a repeating keyword to select different Caesar shifts for each letter, enhancing security through a longer effective key length compared to single-shift methods. During , mechanical rotor machines represented a significant evolution in key usage, exemplified by the German , which employed sets of rotating wheels (rotors) configurable daily with specific wiring, initial positions, and plugboard settings as the shared key among operators to scramble messages across millions of possible configurations. These settings functioned as the key, changed frequently to maintain secrecy, and enabled the of vast military communications until Allied cryptanalysts exploited patterns in to break the system. The advent of digital computing in the 1970s shifted cryptographic keys toward algorithmic standards, beginning with the adopted by the U.S. National Bureau of Standards in 1977, which utilized fixed 56-bit keys for symmetric encryption of 64-bit blocks, balancing computational feasibility with security for early government and commercial applications. Concurrently, emerged with the Diffie-Hellman key exchange protocol published in 1976, introducing asymmetric keys where public parameters facilitated secure key agreement without prior shared secrets, followed by the RSA algorithm in 1977, which employed large prime-based key pairs for both encryption and digital signatures. In the modern era, the Advanced Encryption Standard (AES), standardized by NIST in 2001, superseded DES with variable key sizes of 128, 192, or 256 bits for symmetric block encryption, addressing growing computational threats and becoming the de facto global standard for data protection. Key lengths evolved further amid export restrictions; early Secure Sockets Layer (SSL) implementations in the 1990s often limited to 40-bit keys for international use, proving vulnerable to brute-force attacks, prompting transitions to stronger sizes. By the 2010s, concerns over quantum computing threats intensified following Peter Shor's 1994 algorithm, which demonstrated potential to factor large numbers efficiently on quantum hardware, endangering asymmetric keys like RSA and driving research into quantum-resistant alternatives. As of 2024, NIST guidelines approve AES with key sizes of 128, 192, or 256 bits, stating that even 128-bit keys provide sufficient security against known quantum attacks for the foreseeable future. In August 2024, NIST released the first three finalized post-quantum cryptographic standards—FIPS 203 (ML-KEM for key encapsulation), FIPS 204 (ML-DSA for digital signatures), and FIPS 205 (SLH-DSA for digital signatures)—providing quantum-resistant alternatives to traditional asymmetric keys.

Types of Cryptographic Keys

Symmetric Keys

Symmetric keys are cryptographic keys utilized in symmetric cryptography, where a single secret key is shared between communicating parties and employed for both and decryption processes. This key must remain confidential and is not disclosed publicly to ensure security. Symmetric key algorithms apply the same key to perform an operation and its inverse, such as transforming to and vice versa. These keys excel in scenarios requiring high-speed processing, making them ideal for bulk data encryption where efficiency is paramount. However, their use necessitates robust mechanisms for secure key distribution, as the shared nature of the key introduces risks if intercepted. Common implementations include block ciphers like the Advanced Encryption Standard (AES), a Federal Information Processing Standard that processes data in 128-bit blocks using keys of 128, 192, or 256 bits, often in modes such as Cipher Block Chaining (CBC) for confidentiality or Galois/Counter Mode (GCM) for authenticated encryption. Stream ciphers, such as ChaCha20, produce a continuous keystream from the key to XOR with the plaintext, offering strong performance in software implementations. An example of a deprecated stream cipher is RC4, which was widely used but prohibited in protocols like TLS after 2015 due to identified weaknesses. From a security perspective, symmetric keys are susceptible to compromise; if the key is exposed during sharing or storage, an attacker can decrypt all associated data, undermining the entire protection scheme. They also lack inherent , as possession of the key allows any holder to create or verify messages without proving origin. To mitigate distribution vulnerabilities, symmetric keys are frequently integrated into hybrid cryptosystems, where asymmetric key pairs enable secure initial .

Asymmetric Key Pairs

Asymmetric key pairs, also known as , form the core of , consisting of two mathematically related components: a public key that can be freely distributed to anyone, and a private key that must remain secret with its owner. These keys are generated together using algorithms grounded in computationally difficult mathematical problems, such as the problem for RSA or the discrete logarithm problem for schemes like ECDSA. The linkage ensures that operations performed with one key cannot be easily reversed without the other, allowing without the need to share a secret beforehand. In typical usage, the public key is employed by others to encrypt messages intended for the key owner or to verify digital signatures created by that owner, while the private key is used solely by the owner to decrypt those messages or to generate the signatures. This separation of roles enables and without direct . Prominent examples include the RSA algorithm, introduced in 1977 by , , and , which relies on the difficulty of factoring the product of two large primes and typically uses key sizes of 2048 bits or larger for adequate security. Another key example is (ECC), proposed in the 1980s but widely adopted in the 2000s following endorsements like the NSA's Suite B standards in 2005, where a 256-bit key provides security comparable to a 3072-bit RSA key due to the efficiency of elliptic curve mathematics. The primary advantages of asymmetric key pairs lie in their ability to facilitate secure for symmetric —such as establishing shared session keys over insecure channels—and to support digital signatures for and verification. They serve as the foundational building block for (PKI), which manages the distribution, validation, and revocation of public keys through certificates to enable scalable trust in digital systems. As advances threaten classical schemes like RSA and ECC, post-quantum asymmetric key pairs based on lattice problems (e.g., ML-KEM for key encapsulation and ML-DSA for signatures), hash functions (e.g., SLH-DSA for signatures), or code-based problems (e.g., HQC for key encapsulation) are emerging, with NIST finalizing initial standards in August 2024 and selecting additional algorithms such as HQC for standardization in March 2025 to ensure long-term security.

Applications and Purposes

In Encryption and Decryption

Cryptographic keys play a central role in ensuring confidentiality by enabling the transformation of data into through , and the reversal of this process via decryption, thereby protecting sensitive information from unauthorized access whether stored at rest or transmitted over networks. In symmetric encryption, a single shared key is used for both encrypting the data at the sender's end and decrypting it at the recipient's end, facilitating efficient bulk data protection in scenarios requiring mutual secrecy. For instance, in the (TLS) protocol, symmetric keys—such as those derived from AES—are generated during the handshake to encrypt session data, ensuring secure communication over the . In asymmetric encryption, also known as , a public key is employed to encrypt the data, while the corresponding private key is used solely by the recipient for decryption, allowing secure transmission without prior key sharing. This approach is exemplified in (PGP) for , where the sender uses the recipient's public key to encrypt a symmetric , which then encrypts the message body, combining efficiency with secure . Keys interact with modes of operation to process data in fixed-size blocks, addressing issues like data expansion or patterns in output; for example, the Electronic Codebook (ECB) mode applies the key independently to each block, while Counter (CTR) mode uses the key to generate a keystream for XORing with , providing better against block repetition attacks without requiring in all cases. schemes, such as , may be applied in certain modes to ensure aligns with block sizes when using the key for . In practical applications, full-volume file encryption tools like Microsoft's utilize symmetric AES keys in XTS mode to protect data on storage devices, rendering files inaccessible without the decryption key. Similarly, Virtual Private Networks (VPNs) employing with the Encapsulating Security Payload (ESP) protocol rely on symmetric keys to encrypt IP packets, safeguarding data in transit across untrusted networks.

In Authentication and Signing

In authentication and signing, cryptographic keys play a pivotal role in verifying the authenticity, , and origin of , ensuring that or entities cannot be forged or altered without detection. Asymmetric keys, in particular, enable digital where the private key signs a message digest (typically a hash of the ), producing a signature that the corresponding public key can verify, thus providing assurance that the data has not been tampered with and originates from the claimed signer. This mechanism contrasts with symmetric approaches but complements hybrid systems briefly referenced in broader protocols. Digital signatures rely on algorithms such as the (DSA), which uses a private key to generate a signature over a hash of the , verifiable by the public key to confirm and authenticity. Although DSA is now legacy for new generations under current standards, it exemplifies the process where the signer's private key creates a pair of integers (r, s) from the hash, and verification recomputes and matches them using the public key. More modern variants include the (EdDSA), which signs a hash with the private key—derived from a and hashed for security—and verifies with the public key point on the , offering high speed and resistance to side-channel attacks. For message authentication without full non-repudiation, symmetric keys are employed in constructs like the Hash-based (), where a key is combined with a (e.g., SHA-256) to produce a tag authenticating the message's and origin against an attacker lacking the key. The computation involves inner and outer padded hashes of the key and message, ensuring that any alteration invalidates the tag upon recomputation and verification with the same key. In (PKI), keys within certificates bind a public key to an entity's identity via a from a trusted (CA), enabling entity by verifying the certificate chain and using the public key for subsequent signature validations. The certificate's subjectPublicKeyInfo field specifies the public key and algorithm, while extensions like keyUsage indicate permitted uses such as digitalSignature for , ensuring the key's role in verifying signatures during protocols like TLS handshakes. Practical examples illustrate these roles: In (SSH) logins, a client authenticates using a key pair where the private key signs a challenge from the server, and the server verifies with the pre-registered public key to grant access without passwords. Similarly, in software distribution, such as Apple's notarization process, uses a developer's private key to sign binaries with a over their hash, allowing verifiers to confirm integrity and origin via the public key in a Developer ID certificate before execution. Asymmetric keys in these contexts provide , where a valid proves the signer's identity and intent, preventing denial of authorship since only the private key holder could have produced it, as validated by third-party verification. This property is foundational in legal and secure communications, supported by the mathematical unlinkability of signing from .

Security Considerations

Key Sizes and Strength

In cryptography, the size of a key is typically measured in bits, representing the length of the binary string used in the algorithm. For symmetric encryption algorithms like AES, a larger key size exponentially increases the computational effort required for a , where an adversary exhaustively tries all possible keys; for instance, breaking a 128-bit key would demand approximately 2^128 operations, which is infeasibly large with current technology. Similarly, in asymmetric cryptography, key size affects resistance to attacks like for RSA, though the relationship is not linear due to the underlying mathematical hardness assumptions. The strength of a cryptographic key extends beyond its size to encompass the algorithm's overall resistance to cryptanalytic attacks, including weaknesses in the design that could allow faster exploitation than brute force. For example, the (DES) with its 56-bit key was considered insecure by the late 1990s; in 1998, the Electronic Frontier Foundation's DES cracker hardware broke a DES-encrypted message in under three days by brute force, highlighting how short keys combined with maturing hardware render algorithms obsolete. In contrast, modern standards like AES-256 maintain high strength even against advanced attacks, providing 256 bits of security for symmetric operations against classical computers, far surpassing DES. Key strength is often quantified in "bits of security," a metric estimating the resources needed to break the key, accounting for the most efficient known attacks rather than just the nominal bit length. Current recommendations from the National Institute of Standards and Technology (NIST), based on classical security assessments in SP 800-57 Revision 5 (2020) and SP 800-131A Revision 2 (2019), specify minimum key sizes to achieve desired security levels against classical threats through at least 2030. For symmetric algorithms, NIST advises a minimum of 128 bits (e.g., AES-128), with 256 bits recommended for long-term confidentiality; for RSA, at least 2048 bits (providing 112 bits of security) until 2030, transitioning to 3072 bits or more (128 bits of security) thereafter; and for elliptic curve cryptography (ECC), 256 bits (128 bits of security). These guidelines derive from assessments of attack costs, where 128 bits of security is deemed adequate for most applications against classical computers. However, with the finalization of post-quantum cryptography (PQC) standards in August 2024 (FIPS 203 for ML-KEM key encapsulation, FIPS 204 for ML-DSA signatures, and FIPS 205 for SLH-DSA signatures), NIST recommends transitioning away from classical asymmetric algorithms like RSA and ECC, which are vulnerable to Shor's algorithm, toward PQC alternatives by 2035 to maintain security against quantum threats. For symmetric keys, Grover's algorithm reduces effective security by half, so AES-256 provides 128 bits post-quantum security, while AES-128 offers only 64 bits and should be avoided for long-term use. PQC key sizes vary; for example, ML-KEM at security level 1 (128 bits equivalent) uses a public key of 800 bytes. Key strength must be evaluated against various attack models, including brute force (exhaustive search), dictionary attacks (targeting predictable keys), and side-channel attacks (exploiting implementation leaks like timing or power consumption). Effective bits of security adjust the nominal size based on these vulnerabilities; for example, a 2048-bit RSA key offers approximately 112 bits of against the best-known methods, such as the general number field sieve. Emerging quantum threats, particularly for symmetric keys, necessitate adjustments like using AES-256 for 128-bit post-quantum , while renders current asymmetric keys like RSA vulnerable, prompting a shift to post-quantum algorithms such as those in FIPS 203-205. High-quality during is essential to realize these strength levels, as poor can reduce effective regardless of size. The following table compares recommended minimum key sizes across common algorithms for achieving at least 128 bits of classical , per NIST guidelines (SP 800-57 Rev. 5 and SP 800-131A Rev. 2); post-quantum equivalents are noted separately:
Algorithm TypeExample AlgorithmMinimum Key Size (bits)Effective Security (bits, classical)Notes
SymmetricAES256256128 bits minimum for short-term; AES-256 recommended for post-quantum (128 bits quantum security via resistance to ).
Asymmetric (RSA)RSA30721282048 bits (112 bits) acceptable until 2030; deprecation recommended post-2030 and with PQC transition by 2035.
Asymmetric (DH)Diffie-Hellman3072128Finite-field variant; ECC alternative preferred; both vulnerable to quantum, transition to PQC key agreement (e.g., ML-KEM, public key 800 bytes for level 1).
Elliptic CurveECDSA/ECDH256128Curve like NIST P-256; more efficient than RSA but vulnerable to Shor's; PQC alternatives like ML-DSA preferred.
Post-Quantum (KEM)ML-KEM ()N/A (byte-based)128Level 1: public key 800 bytes; standardized in FIPS 203 (2024).

Entropy and Randomness Requirements

In cryptography, entropy quantifies the degree of randomness or unpredictability in a data source, typically measured in bits, where higher values indicate greater uncertainty about the data's value. For cryptographic keys, full entropy is essential, meaning the minimum entropy of the key material must equal its bit length to ensure it cannot be feasibly guessed or predicted by an adversary. For instance, an AES-256 key requires 256 bits of full entropy to provide its intended level, as lower entropy would reduce the effective key space and vulnerability to brute-force attacks. This requirement aligns with key sizes serving as minimum entropy thresholds, where the security strength of a key is bounded by its entropy rather than just its length. Entropy sources for key generation include hardware random number generators (RNGs), such as Intel's instruction, which leverages on-chip thermal noise to produce high-quality random bits suitable for cryptographic use. Software-based sources, like Linux's /dev/urandom, draw from entropy pools seeded by events such as disk I/O and interrupts, providing a convenient interface for generating pseudorandom bits when properly initialized. However, predictable seeds must be avoided in all cases, as they can compromise the output's and lead to key or predictability across sessions. Standards such as NIST Special Publication 800-90A, released in 2012, specify requirements for deterministic random bit generators (DRBGs) and emphasize that inputs must meet or exceed the security strength needed for the application. This standard highlights risks from weak RNGs, exemplified by the 2008 vulnerability, where a change reduced the pool to just 15-18 bits, enabling attackers to predict SSH and SSL keys generated during that period. To validate RNG outputs, like Dieharder, which includes over 30 statistical tests for detecting non-random patterns, and the NIST Statistical Test Suite (STS), comprising 15 tests for cryptographic , are commonly employed. For enhanced true randomness, quantum random number generators (QRNGs) exploit quantum phenomena like photon detection statistics, offering provably unpredictable immune to classical prediction. Commercial adoption of QRNGs, such as those from ID Quantique, accelerated post-2010 with integrations into secure systems for high-stakes applications like in financial and government sectors.

Key Generation

Methods for Generating Keys

Cryptographic keys are typically generated using cryptographically secure pseudorandom number generators (CSPRNGs) to ensure high and unpredictability, which are essential for . The process begins with seeding the CSPRNG from a high- source, such as hardware noise or system events, followed by expansion to the desired key length through iterative cryptographic operations like hashing or modes. Notable CSPRNG designs include Yarrow, which employs a combination of hashing for accumulation and Triple-DES in counter mode for output generation, originally developed for software implementations. , an evolution of Yarrow, enhances resilience by pooling from multiple sources and reseeding periodically to resist attacks from biased inputs. Hardware-based methods provide enhanced security by isolating key generation within tamper-resistant environments. Trusted Platform Modules (TPMs) are dedicated secure processors that generate keys using internal generators compliant with standards like NIST SP 800-90, ensuring keys never leave the module unprotected. Similarly, smart cards utilize on-board cryptographic coprocessors to produce keys, often incorporating physical sources like ring oscillators, which prevents exposure during creation. Software libraries facilitate key generation in application contexts while leveraging underlying system CSPRNGs. The toolkit's rand command, for instance, draws from platform-specific pools to produce random bytes suitable for keys, as in openssl rand -hex 32 for a 256-bit AES key. Python's secrets module offers functions like secrets.token_bytes(32) for generating secure random data, explicitly designed for cryptographic use and avoiding weaker alternatives like the random module. Best practices emphasize generating keys in isolated, secure environments to minimize side-channel risks, such as using dedicated hardware or virtualized sandboxes, and immediately zeroizing temporary buffers after use to prevent memory leaks. Direct incorporation of user-provided input as should be avoided due to potential predictability; instead, rely on system-collected sources. Keys must possess adequate —typically at least the of the key itself—to resist brute-force attacks. A practical example is the generation of AES keys for in the (LUKS) format, where a random 256-bit master key is created using the kernel's CSPRNG during device formatting with cryptsetup luksFormat, enabling secure storage of encrypted data.

Deterministic vs Random Generation

In cryptographic , random approaches produce non-reproducible outputs with high , ensuring maximal unpredictability and against guessing attacks by relying on approved Random Bit Generators (RBGs) that incorporate from physical or environmental sources. These methods are essential for generating initial or master keys, as they provide the highest level of , typically matching or exceeding the desired strength (e.g., 128 bits for AES-128 keys), but they require robust sources to avoid predictability. A key drawback is the dependence on high-quality , which can be challenging in resource-constrained environments lacking sufficient . In contrast, deterministic key generation creates reproducible keys from a fixed or input keying material using (KDFs), such as the HMAC-based Extract-and-Expand (HKDF), which processes the seed through operations to yield pseudorandom-like outputs. This approach offers verifiability, as the same inputs always produce identical keys, facilitating testing and consistency in protocols, and is particularly useful in low- settings where direct is unavailable. However, it inherits the of the seed: compromise of the seed exposes all derived keys, potentially amplifying risks if the input lacks sufficient entropy. Random generation is typically employed for master keys, where unpredictability is paramount, while deterministic methods suit derived keys, such as session keys in protocols like TLS 1.3, which uses to expand handshake secrets into traffic keys and other materials in a reproducible manner. Standards like RFC 6979 exemplify deterministic techniques by specifying a method to generate nonces for DSA and ECDSA signatures using HMAC-DRBG from the private key and hash, ensuring reproducibility without relying on external randomness. These standards highlight trade-offs: reproducibility aids in avoiding nonce reuse vulnerabilities and simplifies implementation, but it sacrifices inherent uniqueness, potentially increasing side-channel risks or reducing anonymity in certain applications. A hybrid often mitigates these issues by initiating with a random master key for high and then applying deterministic derivation for subsequent keys, balancing security with practicality as recommended in guidelines.

Key Establishment

Key Exchange Protocols

Key exchange protocols enable two parties to securely establish a shared symmetric key over an insecure channel, typically leveraging asymmetric cryptography to avoid prior shared secrets. These protocols are foundational for secure communications, allowing the or of session keys used in symmetric encryption schemes like AES. Common approaches include key agreement methods based on problems and direct key transport using public-key encryption. The Diffie-Hellman (DH) key exchange, introduced in , allows two parties, , to compute a without transmitting it directly. Alice selects a private exponent aa and sends her public value gamod  pg^a \mod p to Bob, where gg is a generator and pp is a large prime; Bob responds with gbmod  pg^b \mod p using his private bb. Both then derive the gabmod  pg^{ab} \mod p by exponentiating the received public value with their private exponent. DH supports variants such as static DH, where long-term keys are used, and ephemeral DH (DHE), where temporary keys are generated per session to provide . Elliptic Curve Diffie-Hellman (ECDH) adapts the DH protocol to , replacing with on an for equivalent security with smaller key sizes. In ECDH, parties agree on a curve and base point GG; Alice computes aGaG from her private aa and sends it, Bob replies with bGbG, and both derive the from abGabG. This efficiency makes ECDH suitable for resource-constrained environments, and ephemeral ECDHE is widely deployed in modern TLS for secure web connections. RSA key transport provides an alternative by having one party generate the symmetric key and encrypt it directly with the recipient's public RSA key for secure delivery. The sender creates a random symmetric key, pads it according to standards like , and encrypts it using the recipient's RSA modulus and exponent; the recipient decrypts with their private key to recover the shared symmetric key. This method relies on the recipient's public key being pre-distributed or certified, and it was commonly used in earlier TLS versions for key establishment. Without , DH and ECDH are vulnerable to man-in-the-middle (MITM) attacks, where an adversary impersonates each party to the other, deriving separate shared secrets and decrypting/relaying traffic. To mitigate this, protocols incorporate digital signatures, such as using public-key certificates to authenticate exchanged values, ensuring the public parameters originate from the legitimate party. Signed variants, like those in TLS handshakes, bind the to verified identities. Practical implementations include SSH, which employs DH or ECDH during the handshake to establish session keys, authenticated via host public keys. Similarly, WhatsApp's , based on the since 2016, uses an initial extended DH exchange followed by a double ratchet mechanism—combining symmetric and DH ratchets—to derive and update per-message keys, providing forward and post-compromise security.

Key Agreement Schemes

Key agreement schemes enable two or more parties to derive a key over an insecure channel without directly transmitting the key itself, relying instead on the exchange of public values and the computational hardness of underlying mathematical problems. In these protocols, each party computes the shared key independently using their private inputs and the received public information, ensuring that an eavesdropper cannot obtain the key from the exchanged messages alone. The foundational example is the Diffie-Hellman (DH) key agreement protocol, introduced in 1976, where parties select private exponents and exchange public group elements raised to those exponents, allowing both to compute the shared secret as the group operation applied to the other's public value raised to their private exponent; security rests on the difficulty of the problem. A notable variant is the Supersingular Isogeny Diffie-Hellman (SIDH) scheme, developed in the 2010s as a post-quantum candidate resistant to attacks by large-scale quantum computers, based on the hardness of finding isogenies between supersingular elliptic curves. Proposed around 2011, SIDH allowed parties to exchange public keys derived from secret walks on the isogeny graph to compute a shared secret curve, positioning it as a potential replacement for classical DH in quantum-safe cryptography and submitting it as SIKE to NIST's post-quantum standardization process. However, in 2022, an efficient key recovery attack exploiting torsion point information broke SIDH's security, rendering it insecure and prompting NIST to standardize alternative post-quantum key agreement methods, such as the lattice-based ML-KEM in FIPS 203 (2024), with additional selections like code-based HQC in 2025. Password-authenticated key exchange (PAKE) schemes extend key agreement to scenarios with low-entropy secrets like passwords, preventing offline dictionary attacks by incorporating zero-knowledge proofs. A seminal PAKE is the Secure Remote Password (SRP) protocol from 1998, where a client and server, sharing a password-derived verifier, exchange blinded values to mutually and derive a shared key without revealing the password; SRP uses similar to DH but augments it with password hashing for authentication. These schemes are particularly useful in client-server settings where one party has limited entropy inputs. Key agreement schemes offer advantages such as perfect (PFS) when using ephemeral keys, meaning that compromise of long-term keys does not expose past session keys, as each agreement generates fresh secrets. This property is crucial for secure communications, and DH-based agreements are integrated into the (IKE) protocol for , where they establish shared keys for VPN tunnels while providing PFS to protect against future key compromises. Formally, the security of many key agreement protocols, including authenticated variants of DH, is proven in the standard model under the decisional Diffie-Hellman () assumption, which posits that distinguishing the from a random group element is computationally infeasible given public exchanges.

Key Management

Key Lifecycle

The key lifecycle in encompasses the complete progression of a cryptographic key from its initial creation through active utilization, maintenance, and eventual secure disposal. This structured approach ensures that keys maintain their security properties throughout their operational lifespan, minimizing risks such as compromise or degradation of cryptographic strength. According to NIST guidelines, the lifecycle is divided into distinct phases to address evolving threats and operational needs, with each phase incorporating specific . The process begins with generation, where keys are produced using approved cryptographic methods, such as deterministic random bit generators compliant with for symmetric keys or FIPS 186 for asymmetric keys, ensuring sufficient and strength. Following generation, distribution and activation involve securely sharing keys with intended parties—via encrypted transport for symmetric keys or (PKI) certificates for asymmetric public keys—and activating them for use within defined cryptoperiods. During the use phase, keys are employed for their designated cryptographic functions, such as or , while being protected against unauthorized access; usage is limited to specific purposes to prevent key reuse vulnerabilities. Long-term keys are inventoried to track their age and application, often within hardware security modules (HSMs) that monitor key lifespan metrics for compliance. As keys age, rotation or update becomes essential to reduce exposure windows to potential attacks; NIST recommends periodic replacement, such as every 1-2 years for symmetric keys, using independent key establishment methods to generate successors without relying on the existing key. This practice limits the impact of any undetected and aligns with the key's lifetime. Revocation or deactivation follows when a key is , superseded, or no longer needed; in PKI environments, this is achieved through Certificate Lists (CRLs) issued by certificate authorities or the (OCSP) for real-time status checks, particularly for private keys suspected of exposure. Best practices include key versioning via metadata to manage updates seamlessly and tailoring usage periods—short for ephemeral session keys (e.g., single-use) and longer for authority (CA) keys (e.g., several years)—to balance and operational efficiency. The lifecycle concludes with archival and destruction. Archival preserves keys for recovery, legal compliance, or future data decryption, retaining them in a deactivated state with strong controls until obsolete, while ephemeral keys are excluded from this step. Destruction securely erases all copies of secret or private keys—via multiple overwrites or zeroization—ensuring no recoverable remnants, though public keys and audit metadata may be retained. Throughout, HSMs facilitate key age tracking to enforce these phases automatically, preventing overuse of aging keys.

Storage, Distribution, and Revocation

Secure storage of cryptographic keys is essential to prevent unauthorized access and maintain their integrity. Hardware Security Modules (HSMs) are specialized physical devices designed to safeguard and manage digital keys, providing tamper-evident and tamper-resistant protection against physical and logical attacks. These modules must comply with standards such as , which specifies security requirements for cryptographic modules, including levels of , key zeroization, and operational environment controls. For software-based storage, key wrapping techniques encrypt keys using a symmetric master key to ensure both confidentiality and integrity, as outlined in NIST SP 800-57 for key management best practices. Tools like KeePass offer encrypted databases for storing keys, using strong algorithms such as AES-256 to protect the entire database, including associated metadata, with access controlled by a master password or key file. Key distribution requires secure channels to prevent interception or tampering during transfer. Initial distribution often occurs , such as through or trusted couriers, to establish trust without relying on potentially compromised networks. Subsequent distributions use encrypted channels, leveraging protocols like TLS to protect symmetric or asymmetric keys in transit. For public keys, Certificate Authorities (CAs) play a central role by issuing certificates that bind public keys to identities, enabling trusted distribution over public networks as defined in IETF RFC 5280. Revocation mechanisms ensure compromised keys can be invalidated promptly to mitigate risks. Certificate Revocation Lists (CRLs) provide periodic lists of revoked certificates, distributed via designated points in the certificate, allowing relying parties to check validity offline. For real-time verification, the enables direct queries to the CA, while allows servers to include signed status responses in TLS handshakes, reducing client latency and privacy concerns. In cases of key compromise, such as the 2014 vulnerability in , which exposed private keys in server memory, affected parties regenerated and revoked keys, reissued certificates, and patched systems to prevent further leaks. Key archival involves secure long-term storage for recovery or compliance, using encrypted backups with defined expiration policies to limit access duration. Upon end-of-life, keys must be destroyed securely; NIST SP 800-88 recommends overwriting media with patterns like all zeros or ones for clearing, or more robust methods like cryptographic erasure for purging, ensuring is infeasible. In modern environments, cloud-based Key Management Services (KMS) like AWS KMS, launched in 2014, centralize key storage, rotation, and using FIPS 140-3 validated HSMs, integrating with services for automated . Zero-trust models further enhance these practices by enforcing continuous verification of key access requests, assuming no inherent trust and requiring for all traffic with managed key lifecycles.

Keys vs Passwords

Key Differences

Cryptographic keys are high-entropy binary strings, typically generated as random bit sequences with at least 128 bits of for common algorithms like AES, designed specifically for direct input into cryptographic operations such as , decryption, and digital signatures. These keys are not intended for human memorization, as they are processed electronically within secure modules to ensure unpredictability and resistance to analysis. In contrast, passwords are human-readable strings, often consisting of printable characters like letters, numbers, and symbols, selected for ease of recall and used primarily for user authentication in systems. The of is generally low due to human predictability, with an average 8-character user-selected providing only about 18 to 40 bits of , rendering it vulnerable to guessing or attacks. This low stems from common patterns, such as words or simple variations, which users favor for memorability. Cryptographic keys, however, achieve high through approved random bit generators, making exhaustive search infeasible even with vast computational resources. In terms of security, the length and randomness of cryptographic keys provide strong resistance to brute-force attacks, as the grows exponentially—doubling the length quadruples the effort required for an exhaustive search. Passwords, prone to offline cracking due to their limited , necessitate protective measures like salting and hashing with adaptive functions such as , which thwart precomputed attacks by requiring unique computations for each password. Without such hashing, exposed password databases become trivial to reverse-engineer. Usage differs fundamentally: cryptographic keys are employed directly in algorithmic processes to secure data in transit or at rest, enabling services like and . Passwords, meanwhile, serve as authenticators for user verification, often requiring conversion to keys via derivation processes to interface with cryptographic systems. This derivation acts as a bridge, transforming human-chosen secrets into suitable cryptographic material. Risks also diverge: password reuse across multiple services amplifies compromise potential, enabling attacks that can breach numerous accounts from a single leak, as users frequently recycle weak credentials. In , key compromise triggers cascading failures, where a single exposed master or symmetric key can decrypt entire datasets or invalidate derived protections, leading to widespread breaches.

Key Derivation from Passwords

Key derivation functions (KDFs) transform low-entropy user into high-entropy cryptographic keys suitable for or , primarily by applying a pseudo-random function (PRF) iteratively to increase computational cost and resist brute-force attacks. This process incorporates a unique salt—a random value per derivation—to prevent precomputation attacks like rainbow tables, and multiple iterations to "stretch" the password, making exhaustive searches more resource-intensive for attackers. The resulting key matches the required length for the target algorithm, such as 256 bits for AES, while maintaining : the same inputs always yield the same output. Prominent algorithms for password-based key derivation include PBKDF2, scrypt, and Argon2, each designed to balance security and performance. PBKDF2, specified in 2000, applies a PRF (typically HMAC with SHA-1 or SHA-256) iteratively: the derived key is computed as DK=PBKDF2(PRF,P,S,c,dkLen)\text{DK} = \text{PBKDF2}(\text{PRF}, P, S, c, \text{dkLen}), where PP is the password, SS the salt, cc the iteration count, and dkLen the output length; internally, it chains blocks via Ti=F(P,S,c,i)T_i = F(P, S, c, i) with FF producing cc PRF applications XORed together. Scrypt, introduced in 2009, extends this with a memory-hard sequential function using a large parameter NN (e.g., 2202^{20}) to compute a pseudorandom stream via SMix, followed by PBKDF2-like finalization, aiming to thwart hardware-accelerated parallel attacks by requiring substantial RAM (e.g., 1 GiB). Argon2, finalized in 2015 as the winner of the 2013–2015 Password Hashing Competition, offers variants (Argon2d for data-dependent mixing, Argon2i for side-channel resistance, and hybrid Argon2id); it processes the password and salt through Blake2b hashing and a memory-hard compression via lanes and blocks, parameterized by time cost tt, memory cost mm (e.g., 1 GiB recommended), and parallelism pp, producing a key via H0=Blake2b(P∣∣S∣∣… )H_0 = \text{Blake2b}(P || S || \dots) followed by iterative XOR and permutation over a matrix. These functions find application in protocols requiring user-friendly secrets, such as (WPA2 and WPA3), where the (PSK) is derived from the passphrase and SSID (as salt) using -HMAC-SHA1 with 4096 iterations to yield a 256-bit pairwise master key (PMK) for generation. In disk encryption, (LUKS) employs (or configurable /scrypt in LUKS2) to derive the master key from a passphrase, using 2^18 iterations by default with a per-key-slot salt to unlock full-volume via . Despite these protections, password-based KDFs remain vulnerable if the input password has low (e.g., common phrases), as attackers can target the reduced search space regardless of iterations or memory hardness. Quantum threats are minimal, as offers only quadratic speedup on brute-force searches, which can be countered by doubling iteration counts, and the underlying hashes (e.g., SHA-256 in or Blake2b in ) provide sufficient security margins; however, side-channel attacks like cache-timing on or on implementations pose risks, necessitating constant-time variants.

References

  1. https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
  2. https://csrc.nist.gov/glossary/term/key
  3. https://csrc.nist.gov/projects/post-quantum-cryptography
  4. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
  5. https://web.mat.upc.edu/jorge.villar/doc/notes/Crypt_FME/symm.pdf
  6. https://pages.cs.wisc.edu/~rist/838-spring-2012/book/w-se.pdf
  7. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf
  8. https://learn.microsoft.com/en-us/answers/questions/25714/what-is-the-difference-between-a-key-and-a-secret
  9. https://math-sites.uncg.edu/sites/pauli/112/HTML/seccaesar.html
  10. https://www.montana.edu/csoutreach/CryptographyCaesarsCipher.pdf
  11. https://www.cs.trincoll.edu/cryptography/vigenere.html
  12. https://dda.ndus.edu/ddreview/the-unencrypted-history-of-cryptography/
  13. https://www.nsa.gov/portals/75/documents/about/cryptologic-heritage/historical-figures-publications/publications/wwii/german_cipher.pdf
  14. https://www.cia.gov/legacy/museum/artifact/enigma-machine/
  15. https://csrc.nist.gov/nist-cyber-history/cryptography/chapter
  16. https://ee.stanford.edu/~hellman/publications/24.pdf
  17. https://crypto.stanford.edu/~dabo/papers/RSA-survey.pdf
  18. https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197.pdf
  19. https://scout.wisc.edu/archives/g11641/f4
  20. https://plato.stanford.edu/archives/fall2022/entries/qt-quantcomp/
  21. https://csrc.nist.gov/projects/post-quantum-cryptography/faqs
  22. https://csrc.nist.gov/news/2024/nist-releases-first-three-post-quantum-encryption-standards
  23. https://csrc.nist.gov/glossary/term/symmetric_key
  24. https://csrc.nist.gov/glossary/term/symmetric_key_algorithm
  25. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r5.pdf
  26. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf
  27. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf
  28. https://datatracker.ietf.org/doc/html/rfc7539
  29. https://datatracker.ietf.org/doc/html/rfc7465
  30. https://www.cloudflare.com/learning/ssl/how-does-public-key-encryption-work/
  31. https://people.csail.mit.edu/rivest/Rsapaper.pdf
  32. https://static1.squarespace.com/static/5e78170a34645422d23f611b/t/5e9e4e779f796240d6ba08bb/1587433081630/EECS_475_Project.pdf
  33. https://www.ibm.com/think/topics/asymmetric-encryption
  34. https://csrc.nist.gov/pubs/sp/800/78/5/ipd
  35. https://math.mit.edu/~apost/courses/18.204-2016/18.204_Jeremy_Wohlwend_final_paper.pdf
  36. https://eprint.iacr.org/2021/894.pdf
  37. https://www.keyfactor.com/education-center/what-is-pki/
  38. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
  39. https://datatracker.ietf.org/doc/html/rfc5246
  40. https://www.rfc-editor.org/rfc/rfc4880.html
  41. https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/
  42. https://datatracker.ietf.org/doc/html/rfc4303
  43. https://doi.org/10.6028/NIST.FIPS.186-5
  44. https://doi.org/10.6028/NIST.FIPS.186-4
  45. https://datatracker.ietf.org/doc/html/rfc8032
  46. https://datatracker.ietf.org/doc/html/rfc2104
  47. https://datatracker.ietf.org/doc/html/rfc5280
  48. https://datatracker.ietf.org/doc/html/rfc4252
  49. https://developer.apple.com/documentation/security/signing-and-verifying
  50. https://csrc.nist.gov/pubs/fips/186-4/final
  51. https://csrc.nist.gov/glossary/term/non_repudiation
  52. https://w2.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/
  53. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-131ar2.pdf
  54. https://crypto.stackexchange.com/questions/378/what-is-entropy
  55. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-90ar1.pdf
  56. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-133.pdf
  57. https://www.intel.com/content/www/us/en/developer/articles/guide/intel-digital-random-number-generator-drng-software-implementation-guide.html
  58. https://www.2uo.de/myths-about-urandom/
  59. https://csrc.nist.gov/pubs/sp/800/90/a/r1/final
  60. https://www.debian.org/security/2008/dsa-1571
  61. http://webhome.phy.duke.edu/~rgb/General/dieharder.php
  62. https://csrc.nist.gov/pubs/sp/800/22/r1/upd1/final
  63. https://link.aps.org/doi/10.1103/RevModPhys.89.015004
  64. https://www.idquantique.com/random-number-generation/overview/
  65. https://www.schneier.com/wp-content/uploads/2016/02/paper-yarrow.pdf
  66. https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.07-2014-03-13.pdf
  67. https://docs.openssl.org/3.1/man7/RAND/
  68. https://docs.python.org/3/library/secrets.html
  69. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening
  70. https://datatracker.ietf.org/doc/html/rfc5869
  71. https://datatracker.ietf.org/doc/html/rfc8446
  72. https://datatracker.ietf.org/doc/html/rfc6979
  73. https://datatracker.ietf.org/doc/html/rfc8422
  74. https://signal.org/docs/specifications/doubleratchet/
  75. https://csrc.nist.gov/csrc/media/events/key-management-workshop-2001/documents/schemes-overview.pdf
  76. https://eprint.iacr.org/2022/975
  77. https://csrc.nist.gov/pubs/fips/203/final
  78. https://www.ndss-symposium.org/wp-content/uploads/2017/09/The-Secure-Remote-Password-Protocol.pdf
  79. https://datatracker.ietf.org/doc/html/rfc6071
  80. https://crypto.stanford.edu/~dabo/pubs/papers/DDH.pdf
  81. https://csrc.nist.gov/glossary/term/hardware_security_module_hsm
  82. https://csrc.nist.gov/pubs/fips/140-3/final
  83. https://keepass.info/help/base/security.html
  84. https://www.keyfactor.com/blog/what-is-a-certificate-revocation-list-crl-vs-ocsp/
  85. https://www.heartbleed.com/
  86. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf
  87. https://aws.amazon.com/kms/
  88. https://aws.amazon.com/blogs/security/aws-kms-is-now-fips-140-3-security-level-3-what-does-this-mean-for-you/
  89. https://www.cisa.gov/sites/default/files/2023-04/CISA_Zero_Trust_Maturity_Model_Version_2_508c.pdf
  90. https://pages.nist.gov/800-63-3/sp800-63b.html
  91. https://www.route-fifty.com/cybersecurity/2005/08/how-strong-is-your-password-nist-has-some-formulas/305798/
  92. https://crypto.stackexchange.com/questions/19632/is-it-true-the-longer-the-key-length-is-the-more-secure-the-encryption
  93. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
  94. https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/
  95. https://www.cryptomathic.com/blog/cryptographic-key-management-the-risks-and-mitigations
  96. https://www.ietf.org/rfc/rfc2898.txt
  97. https://www.tarsnap.com/scrypt/scrypt.pdf
  98. https://datatracker.ietf.org/doc/rfc9106/
  99. https://www.password-hashing.net/
  100. https://networklessons.com/wireless/introduction-to-wpa-key-hierarchy
  101. https://eprint.iacr.org/2016/274.pdf
  102. https://guptadeepak.com/bcrypt-scrypt-and-argon2-choosing-the-right-password-hashing-algorithm/
  103. https://crypto.stanford.edu/cs359c/17sp/projects/MarkAnderson.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.