Fact-checked by Grok 2 weeks ago

Shared secret

A shared secret in cryptography is a piece of confidential data, known exclusively to the involved parties, that serves as the foundation for secure communication, often functioning directly as a symmetric cryptographic key without requiring additional derivation.^[1] This secret enables the encryption and decryption of data using the same key, ensuring confidentiality and integrity in symmetric-key systems, where both sender and receiver apply identical transformations to plaintext and ciphertext.^[2] Shared secrets are distinct from public-key mechanisms, as they rely on mutual knowledge rather than asymmetric pairs, making them efficient for high-volume data protection but challenging to distribute securely.^[3] Shared secrets can be established in two primary ways: through pre-shared keys (PSKs), which are manually or out-of-band distributed beforehand, or via dynamic key agreement protocols that compute the secret over an insecure channel without revealing it to eavesdroppers.^[4] A prominent example is the Diffie-Hellman key exchange, where two parties independently derive the same secret value—typically g^{xy} \mod p—from publicly exchanged parameters, providing a basis for session keys in protocols like IPsec.^[5] This method supports perfect forward secrecy when ephemeral keys are used, ensuring that past sessions remain secure even if long-term secrets are compromised.^[6] Beyond encryption, shared secrets underpin various authentication mechanisms, such as challenge-response protocols (e.g., CHAP) or PSK-based methods in the Internet Key Exchange (IKE) for VPNs, where the secret verifies identities without transmitting it openly.^[6] Their management is critical, as static or weak shared secrets are vulnerable to brute-force, dictionary, or offline attacks if intercepted, necessitating regular rotation and secure storage.^[3] In modern applications, shared secrets often seed key derivation functions to generate multiple sub-keys for diverse purposes, enhancing overall protocol resilience.^[1]

Fundamentals

Definition

A shared secret in cryptography refers to a piece of symmetric data, such as a cryptographic key, personal identification number (PIN), password, passphrase, or random byte string, that is known exclusively to two or more parties for the purpose of establishing secure communication channels.^[1]^[7] This data functions directly as a key in symmetric-key algorithms without needing further derivation in many cases.^[1] In contrast to asymmetric cryptography, which employs pairs of public and private keys where the public key can be freely distributed to anyone, a shared secret remains strictly confidential among the authorized parties to maintain security.^[8]^[9] A basic example involves two users agreeing on a passphrase as their shared secret, which they then use to derive a symmetric encryption key for protecting their exchanged messages.^[7] Conceptually, the shared secret underpins symmetric cryptosystems by enabling confidentiality via encryption of data and integrity through keyed mechanisms, such as message authentication codes that detect unauthorized modifications.^[10]^[11]

Key Characteristics

A shared secret, as a cryptographic key used in symmetric cryptosystems, must maintain absolute confidentiality to ensure its effectiveness; any unauthorized disclosure compromises the security of communications or data protected by it.^[12] This property of secrecy requires robust protection measures during storage, transmission, and use, such as encryption or physical safeguards, to prevent access by adversaries.^[12] The symmetry of a shared secret lies in its identical value being utilized by all authorized parties for both encryption and decryption operations, enabling efficient and reversible cryptographic processes without the need for distinct keys per direction.^[12] This shared nature underpins the core mechanism of symmetric cryptography, where the same key performs complementary functions to secure data integrity and confidentiality.^[12] To resist brute-force and other attacks, a shared secret must exhibit uniqueness through sufficient length and unpredictability, typically ranging from 128 to 256 bits for algorithms like AES, ensuring high entropy that aligns with the desired security strength.^[12] Keys generated via approved random bit generators achieve this by producing outputs that are computationally infeasible to guess.^[13] Shared secrets are often designed with volatility in mind, incorporating short cryptoperiods—such as one day for session keys—to minimize exposure risks and facilitate timely rotation or revocation if compromise is suspected.^[12] This temporal limitation helps bound potential damage from any breach. In practice, shared secrets frequently originate from human-memorable elements like passwords, which are then transformed via key derivation functions into high-entropy keys to overcome the inherent low entropy of such inputs.^[13] Methods outlined in standards like SP 800-132 employ iterative processes to amplify security, ensuring the derived key meets cryptographic strength requirements despite starting from weaker sources.^[14]

Generation and Distribution

Pre-shared Keys

A pre-shared key (PSK), also known as a shared secret key, is a symmetric cryptographic key that is established and distributed between communicating parties prior to the initiation of secure communication, typically through a secure out-of-band method to ensure its confidentiality.^[15] This key serves as the foundational secret for authentication and encryption in symmetric cryptography systems, where both parties must possess identical copies to derive session keys or directly encrypt data.^[16] Distribution of PSKs commonly occurs via physical delivery, such as handwritten notes or printed materials handed over in person, to minimize interception risks.^[17] Secure channels like trusted couriers, who transport keys without digital transmission, provide another method, particularly for high-security environments where electronic means are deemed vulnerable.^[18] In modern device setups, PSKs are often pre-installed during manufacturing or by administrators, as seen in Wi-Fi networks using WPA2-PSK mode, where the key is configured on access points and client devices alike.^[19] Historically, PSKs trace their roots to early cryptographic practices, including World War II codebooks—collections of pre-agreed substitution tables or keys—that were physically distributed to military units for encoding and decoding messages, ensuring only authorized personnel could access the secrets.^[17] This approach persisted into the postwar era and continues in contemporary applications like IoT device pairing, where manufacturers embed PSKs in firmware to enable initial secure bootstrapping between devices and gateways.^[20] The primary advantage of PSKs lies in their simplicity, requiring no computational overhead from complex protocols during key establishment, which makes them suitable for resource-constrained environments like legacy systems.^[21] However, they suffer from scalability limitations in large networks, as distributing unique keys to numerous parties becomes logistically challenging and increases the chance of compromise if a single distribution is intercepted.^[22] A representative example is the use of a static PSK hardcoded directly into software for legacy authentication systems, where the key is embedded in the binary code during development and shared identically across endpoints, though this practice is now discouraged due to exposure risks in source code repositories.^[23] In contrast to dynamic key agreement protocols, PSKs remain fixed once distributed, relying solely on the initial secure exchange for their integrity.^[24]

Key Agreement Protocols

Key agreement protocols enable two or more parties to compute a shared secret over an insecure channel without previously exchanging the secret itself, relying instead on public information exchanged between them and private inputs held by each party.^[25] This process ensures that the resulting shared secret is known only to the participating parties, assuming computational security holds.^[25] The foundational example is the Diffie-Hellman key exchange, introduced in 1976, where two parties, Alice and Bob, agree on a large prime modulus p and a generator g (a primitive root modulo p). Alice selects a private exponent a and computes her public value A = g^a \mod p, which she sends to Bob; similarly, Bob selects b and sends B = g^b \mod p to Alice. Alice then computes the shared secret K = B^a \mod p = (g^b)^a \mod p = g^{ab} \mod p, while Bob computes K = A^b \mod p = (g^a)^b \mod p = g^{ab} \mod p.^[25] This symmetry ensures both parties derive the identical K without transmitting it directly.^[25] Variants of Diffie-Hellman improve efficiency, such as elliptic curve Diffie-Hellman (ECDH), which operates over elliptic curve groups instead of modular exponentiation, reducing key sizes while maintaining security; for instance, a 256-bit ECDH key offers comparable strength to a 3072-bit classical Diffie-Hellman key. Another approach is the Kerberos protocol, which uses a trusted third party (the Key Distribution Center) to facilitate ticket-based key agreement between clients and services, enabling secure session keys without direct public exchanges.^[26] These protocols depend on the computational hardness of problems like the discrete logarithm problem, where extracting the private exponents a or b from public values A, B, g, and p is infeasible for large parameters.^[25] When implemented with ephemeral (temporary) private keys, Diffie-Hellman and its variants provide forward secrecy, meaning compromise of long-term keys does not expose past session secrets. In response to the threat of quantum computers, which can efficiently solve the discrete logarithm problem using Shor's algorithm, post-quantum key agreement protocols have been developed. As of August 2024, the National Institute of Standards and Technology (NIST) standardized ML-KEM (FIPS 203), a lattice-based key encapsulation mechanism that allows parties to establish quantum-resistant shared secrets over insecure channels. These protocols are increasingly integrated into standards like TLS to ensure long-term security.^[27]

Applications in Cryptography

Authentication Mechanisms

Shared secrets play a central role in challenge-response authentication mechanisms, where a verifier issues a challenge to a prover, who then generates a response derived from the shared secret without transmitting it directly. In this process, the prover computes a one-way function, such as a hash-based message authentication code (HMAC), applied to the secret and the challenge; the verifier independently computes the same value to confirm authenticity. For instance, the OATH Challenge-Response Algorithm (OCRA) employs HMAC-SHA-1 with the shared secret as the key and the challenge as input to produce a response, ensuring resistance to replay attacks through unpredictable challenges.^[28] Password-based authentication treats the shared secret as a human-memorizable password or a key derived from it, often enhanced with salting to thwart precomputed attacks like rainbow tables. Salting involves appending a unique, random value to the password before hashing, which forces attackers to compute hashes individually for each potential salt rather than reusing tables. The PKCS #5 standard specifies password-based key derivation functions (PBKDF1 and PBKDF2) that incorporate salt and iteration counts to produce secure outputs from weak passwords, with current guidelines from OWASP recommending at least 16 bytes (128 bits) of salt and 600,000 iterations for PBKDF2 using HMAC-SHA256.^[29]^[30] A prominent example is the Challenge-Handshake Authentication Protocol (CHAP) used in Point-to-Point Protocol (PPP) connections, where the authenticator sends a random challenge, and the peer responds with an MD5 hash of the peer identifier, shared secret, and challenge, allowing verification without exposing the secret over the link.^[31] Another is the Secure Remote Password (SRP) protocol, which enables secure remote authentication using a password-derived verifier stored on the server; the client and server perform a Diffie-Hellman-like exchange to mutually derive a session key and proofs without ever sending the password, protecting against eavesdropping and offline dictionary attacks.^[32] Shared secrets integrate into multi-factor authentication by serving as the "something you know" component alongside biometrics ("something you are") or hardware tokens ("something you have"), requiring presentation of multiple distinct factors for verification. According to NIST guidelines (as of Revision 4, 2025), for authenticator assurance level 2 (AAL2), a memorized secret like a password must combine with a possession-based factor, such as a single-factor one-time password device, using approved cryptographic protocols to bind and verify the factors securely.^[33] In protocols like Transport Layer Security (TLS), shared secrets—often pre-shared keys (PSKs)—facilitate mutual authentication during handshake phases, where both client and server prove possession of the secret to establish trust without certificates. TLS-PSK ciphersuites derive a premaster secret from the PSK identity and value exchanged in the handshake, enabling symmetric authentication and session key agreement.^[34]

Encryption and Key Derivation

Shared secrets serve as the foundation for key derivation functions (KDFs), which expand short, low-entropy secrets—such as passwords or pre-shared keys—into cryptographically secure, full-length keys suitable for encryption algorithms. This process enhances security by incorporating additional inputs like salts and iteration counts to resist brute-force and dictionary attacks. A prominent example is PBKDF2 (Password-Based Key Derivation Function 2), which applies a pseudorandom function (PRF), typically HMAC, iteratively to derive the output key. For password-based shared secrets, modern standards prefer memory-hard functions like Argon2id over PBKDF2 to better resist parallel attacks; for high-entropy secrets, HKDF is commonly used.^[29]^[35] The PBKDF2 algorithm takes a password P, salt S, iteration count c, and desired key length dkLen as inputs. It computes intermediate blocks T_i through the function F(P, S, c, i) = U_1 \oplus U_2 \oplus \cdots \oplus U_c, where U_1 = \text{PRF}(P, S \| \text{INT}(i)) and U_j = \text{PRF}(P, U_{j-1}) for j = 2 to c, with \text{INT}(i) as the four-octet encoding of the block index i. The final derived key DK is the concatenation of these blocks up to the required length: DK = T_1 \| T_2 \| \cdots \| T_k, where k = \lceil dkLen / hLen \rceil and hLen is the PRF output length. This iterative mixing ensures that even weak shared secrets produce strong keys resistant to parallel attacks.^[30] To further secure communications, shared secrets are often used to generate unique session keys for each message or session, preventing key reuse that could enable attacks like chosen-ciphertext exploitation. This involves combining the derived key with an initialization vector (IV) or nonce, which must be unpredictable and unique per invocation. For instance, in AES-GCM (Advanced Encryption Standard in Galois/Counter Mode), the session key—derived from the shared secret—is paired with a 96-bit nonce to produce a keystream for encryption while simultaneously computing an authentication tag for integrity verification. The mode operates as C_i = P_i \oplus GCTR(K, IV \| \text{counter}) for ciphertext blocks, with the Galois field multiplication providing the tag T = \text{GHASH}(H, A \| 0^{t} \| C \| 0^{64+t} ) \oplus GCTR(K, IV, 0), ensuring both confidentiality and authenticity without separate MACs.^[36] In practical applications, these techniques underpin symmetric encryption in virtual private networks (VPNs) via IPsec, where preshared keys authenticate peers during Internet Key Exchange (IKE) and derive session keys for encapsulating security payloads (ESP). The IKE process uses the preshared secret in a PRF to generate keying material, which is then expanded for per-session AES encryption, maintaining tunnel confidentiality across untrusted networks.^[6] Similarly, in secure messaging protocols like Signal, shared secrets from ratcheting key agreements are fed into KDF chains to derive ephemeral message keys. The Double Ratchet algorithm initializes chain keys from the shared secret and Diffie-Hellman outputs, advancing them per message via \text{KDF}_R and \text{KDF}_C to yield unique 32-byte encryption keys, enabling forward secrecy in end-to-end encrypted conversations.^[37] By enforcing per-session key uniqueness through IV/nonce incorporation and derivation, shared secrets mitigate reuse attacks, such as those exploiting predictable keystreams in stream ciphers. Additionally, they play a critical role in message authentication codes (MACs) for integrity, as exemplified by HMAC (Hash-based Message Authentication Code), which computes \text{HMAC}_K(m) = H((K \oplus \text{opad}) \| H((K \oplus \text{ipad}) \| m)) using the shared secret K and a hash function H, verifying that messages remain unaltered during transit.^[38]

Security Aspects

Potential Vulnerabilities

Shared secrets are susceptible to brute-force attacks, where an attacker systematically tries all possible combinations to guess the secret, particularly when the secret has low entropy, such as weak passwords derived from common words or patterns.^[39] Dictionary attacks, a variant of brute-force methods, exploit this by testing a precompiled list of likely candidates like dictionary words or leaked password databases, significantly reducing the search space compared to exhaustive enumeration.^[40] The computational cost of such attacks scales exponentially with the key length; for symmetric ciphers, each additional bit roughly doubles the required effort, making secrets with at least 128 bits generally resistant to brute-force attempts using current hardware.^[41] For long-term security against quantum computing threats, such as Grover's algorithm, NIST recommends using at least 256 bits for symmetric shared secrets to maintain equivalent security levels.^[42] Man-in-the-middle (MitM) attacks pose a threat during the generation and distribution of shared secrets, allowing an interceptor to impersonate one party and establish separate keys with each legitimate participant without detection. For instance, the basic Diffie-Hellman key agreement protocol lacks inherent authentication, enabling an attacker to intercept public values, substitute their own, and derive distinct secrets with each endpoint, thereby compromising confidentiality.^[43] Side-channel attacks exploit physical implementations of shared secret handling, leaking information through unintended emissions rather than algorithmic weaknesses. Timing attacks measure variations in computation duration to infer secret bits, as seen in early implementations of Diffie-Hellman where modular exponentiation times correlated with key values. Power analysis, including differential techniques, monitors electrical consumption during cryptographic operations to reconstruct secrets in hardware devices like smart cards, where power usage fluctuates based on processed data. Reusing the same shared secret across multiple sessions or messages introduces cryptanalytic risks, as patterns in the ciphertexts can reveal the underlying key through known-plaintext or related-message attacks. In stream ciphers, key reuse equates to a two-time pad scenario, where XORing two ciphertexts yields the XOR of the corresponding plaintexts, enabling recovery of sensitive information if partial plaintexts are guessed. A prominent historical example is the Wired Equivalent Privacy (WEP) protocol for Wi-Fi, which relied on a static 40- or 104-bit shared secret combined with a short initialization vector for RC4 keystream generation; this design was broken in 2001 through statistical analysis of IV reuse, allowing efficient key recovery with minimal captured traffic. These vulnerabilities highlight the need for careful implementation, with mitigations outlined in best practices.

Best Practices

When generating shared secrets, it is essential to ensure sufficient entropy to resist brute-force attacks, with a minimum of 128 bits recommended for symmetric cryptographic keys. Cryptographically secure pseudorandom number generators (CSPRNGs), such as those specified in NIST SP 800-90A, should be used to produce these secrets, avoiding deterministic or low-entropy sources like user passwords without enhancement.^[44] Secure storage of shared secrets is critical to prevent unauthorized access. Secrets should be encrypted at rest using approved algorithms like AES-256, and hardware security modules (HSMs) compliant with FIPS 140-3 or higher are preferred for high-security environments to provide tamper-resistant protection. Additionally, avoid storing secrets in plaintext in memory; instead, use secure memory handling practices, such as zeroing out buffers after use, to mitigate risks from memory dumps or debugging tools.^[44] Regular rotation of shared secrets limits the impact of potential compromises by reducing the cryptoperiod—the time during which a key is authorized for use—to appropriate durations based on usage volume and threat models, typically 1-2 years for symmetric keys in low-risk scenarios. Mechanisms for revocation and invalidation must be implemented post-compromise, including immediate key destruction and notification to all parties, followed by rekeying to restore security.^[44] In protocol selection for shared secret establishment, authenticated key exchange methods are preferred over unauthenticated ones to prevent man-in-the-middle attacks; for example, IKEv2 in IPsec provides mutual authentication and is recommended for VPNs. Incorporating perfect forward secrecy (PFS) ensures that session keys remain secure even if long-term secrets are later compromised, as achieved through ephemeral Diffie-Hellman exchanges in protocols like TLS 1.3 or IKEv2.^[45] For shared secrets derived from passwords, compliance with NIST SP 800-63 is advised, which emphasizes multi-round hashing functions like PBKDF2 with a sufficient number of iterations (tuned to take approximately 100-500 ms on the verifier's hardware), bcrypt, scrypt, or Argon2 to increase computational cost against offline attacks, along with salting to prevent rainbow table exploitation.^[33]

References

[1]
shared secret key - Glossary | CSRC
Definitions: A shared secret that can be used directly as a cryptographic key in symmetric-key cryptography. It does not require additional key derivation.
[2]
[PDF] Symmetric Key Cryptography - Stony Brook Computer Science
Feb 27, 2024 · Symmetric key cryptography uses a single, shared secret key for both encryption and decryption, converting between plaintext and ciphertext.
[3]
Shared Secret Key - an overview | ScienceDirect Topics
A 'Shared Secret Key' is a confidential piece of information used for data encryption in computer networks, which, when not changed regularly, can lead to ...
[4]
RFC 6617 - Secure Pre-Shared Key (PSK) Authentication for the ...
This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE). It is resistant to dictionary attack.
[5]
RFC 2631 - Diffie-Hellman Key Agreement Method - IETF Datatracker
Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary ...
[6]
RFC 2409: The Internet Key Exchange (IKE)
### Summary of RFC 2409: Mentions of Shared Secret in IKE and Diffie-Hellman Key Exchange
[7]
https://ldapwiki.com/wiki/Wiki.jsp?page=Shared%20Secret
[8]
What is Asymmetric Encryption? - IBM
Symmetric encryption requires a key exchange, in which the communicating parties agree on a shared secret key. Hackers can intercept the key during this ...What is asymmetric encryption? · How does asymmetric...
[9]
What is a Symmetric Key? - Thales
In cryptography, a symmetric key is one that is used both to encrypt and decrypt information. ... The keys, in practice, represent a shared secret between two or ...
[10]
What Is Symmetric Encryption? | IBM
Diffie-Hellman allows two parties to generate a shared secret—like a symmetric key—over an insecure channel without having prior shared secrets. · Alternatively, ...What is symmetric encryption? · What's the difference between...
[11]
message authentication code (MAC) - Glossary | CSRC
message authentication code (MAC) · A cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications of the ...
[12]
https://doi.org/10.6028/NIST.SP.800-57pt1r5
[13]
https://doi.org/10.6028/NIST.SP.800-133r2
[14]
https://doi.org/10.6028/NIST.SP.800-132
[15]
pre-shared key - Glossary | CSRC
Definitions: A secret key that has been established between the parties who are authorized to use it by means of some secure method (e.g., using a secure ...
[16]
RFC 4764 - The EAP-PSK Protocol: A Pre-Shared Key Extensible ...
EAP-PSK January 2007 Pre-Shared Key (PSK) A Pre-Shared Key simply means a key in symmetric cryptography. This key is derived by some prior mechanism and ...
[17]
[PDF] The Impact of the Allied Cryptographers on World War II
Dec 14, 2013 · The German government created and distributed code books and copies of the Enigma to the mil- itary. The code books contained the initial ...
[18]
Deploying hybrid quantum-secured infrastructure for applications
One possible solution is to use trusted couriers, which physically, by non-digital means, transfer cryptographic keys between places. Although this approach may ...Missing: delivery | Show results with:delivery<|separator|>
[19]
Configuration of WPA/WPA2 with Pre-Shared Key: IOS 15.2JB and ...
Oct 23, 2013 · This document describes a sample configuration for Wireless Protected Access (WPA) and WPA2 with a pre-shared key (PSK).
[20]
IoT Provisioning Process: Secure Onboarding and Lifecycle ...
Each device is assigned a private key paired with an X.509 certificate ... This typically involves presenting manufacturer certificates or pre-shared credentials ...
[21]
What are Pre-Shared Key Encryption Algorithms? - Nexus Group
Nov 14, 2024 · Learn about pre-shared key encryption algorithms and how to secure data with Nexus Group. Discover its benefits and applications in ...Common Applications Of Psk... · Comparing Psk Encryption To... · Best Practices For...
[22]
[PDF] Quantum Safe Cryptography and Security - ETSI
Pre-shared keys are also problematic in a large network because, if a global key is being used it is very hard to keep such a global key a secret ...<|separator|>
[23]
CWE-798: Use of Hard-coded Credentials
The cryptographic key is within a hard-coded string value that is compared to the password. It is likely that an attacker will be able to read the key and ...Missing: pre- | Show results with:pre-<|control11|><|separator|>
[24]
RFC 9257 - Guidance for External Pre-Shared Key (PSK) Usage in ...
Sep 19, 2023 · This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.Missing: methods trusted couriers
[25]
[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 ...
[26]
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 ...
[27]
RFC 6287: OCRA: OATH Challenge-Response Algorithm
### Summary of OCRA's Use of HMAC with Shared Secret in Challenge-Response
[28]
RFC 2898 - PKCS #5: Password-Based Cryptography Specification ...
This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message- ...<|separator|>
[29]
RFC 1994: PPP Challenge Handshake Authentication Protocol (CHAP)
### Summary of CHAP Using Shared Secret for Authentication
[30]
RFC 2945 - The SRP Authentication and Key Exchange System
This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol.
[31]
NIST Special Publication 800-63B
The secret key and its algorithm SHALL provide at least the minimum security length specified in the latest revision of SP 800-131A (112 bits as of the date of ...
[32]
RFC 4279 - Pre-Shared Key Ciphersuites for Transport Layer ...
This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs ...
[33]
SP 800-38D, Recommendation for Block Cipher Modes of Operation
SP 800-38D recommends GCM for authenticated encryption and GMAC for generating a message authentication code (MAC) on non-encrypted data.
[34]
Signal >> Specifications >> The Double Ratchet Algorithm
The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key.
[35]
RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
HMAC is a mechanism for message authentication using cryptographic hash functions, using a secret key for calculation and verification.
[36]
[PDF] Authenticated Key Exchange Secure Against Dictionary Attacks
The reason for this interest is simple: password-guessing attacks are a common avenue for break- ing into systems, and here is a domain where good cryptographic ...
[37]
[PDF] Password-Based Protocols Secure Against Dictionary Attacks
Classical cryptographic protocols based on user- chosen keys allow an attacker to mount password- guessing attacks. We introduce a novel combination.
[38]
[PDF] Minimal Key Lengths for Symmetric Ciphers to Provide Adequate ...
For adequate protection against serious threats, keys should be at least 75 bits long. For the next 20 years, keys should be at least 90 bits long.
[39]
[PDF] Diffie Hellman key exchange - People | MIT CSAIL
Mar 8, 2011 · ab mod p you actually need to know a or b. Man in the middle attack (MITM). What if Eve tampers with messages? - She can send g. e ...
[40]
https://www1.cs.columbia.edu/~smb/papers/neke.pdf
[41]
[PDF] Guide to IPsec VPNs - NIST Technical Series Publications
Jun 1, 2020 · Password Authenticated Key Exchange. PAP. Password Authentication Protocol. PFS. Perfect Forward Secrecy. PKCS. Public Key Cryptography ...
[42]
NIST Special Publication 800-63B
The secret key value SHALL be stored separately from the hashed passwords. It SHOULD be stored and used within a hardware-protected area, such as a hardware ...