DEV Community: Tiago Sousa

Secure Remote Password (SRP) protocol

Tiago Sousa — Tue, 28 Oct 2025 20:21:16 +0000

Introduction

In this article, I’ll walk you through my implementation of the Secure Remote Password (SRP) [1] protocol, including its challenges, architecture, and testing strategies. You can find the full source code on my GitHub repository.

The Secure Remote Password (SRP) protocol is a type of password-authenticated key exchange (PAKE) protocol that has been specifically designed to avoid conflicts with existing patents. It falls under the category of augmented PAKE protocols, which offer enhanced security properties compared to traditional password-based systems.

As with all PAKE protocols, SRP ensures that an attacker who intercepts communication between the client and server cannot gather enough information to guess the password through brute force or dictionary attacks. This is because the protocol requires additional interactions for each password guess, making such attacks impractical. Moreover, since SRP is an augmented PAKE, the server does not store any data that is equivalent to the password. This means that even if an attacker gains access to the server's database, they cannot impersonate the client unless they first perform a computationally expensive brute-force search to recover the password.

In simpler terms, SRP allows a user (the "client") to prove to a server that they know their password without ever transmitting the password itself or any data that could be used to reconstruct it. The password remains securely on the client side and is never shared with the server. The server, on the other hand, stores only a "verifier," which is a cryptographic representation of the password that cannot be reversed to reveal the original password.

Additionally, SRP provides mutual authentication. The server must also prove its legitimacy to the client, ensuring that the client is not connecting to a malicious or fake server. This feature helps protect users from phishing attacks without requiring them to analyze complex URLs or other indicators of legitimacy [2].

SRP's primary mathematically proven security property is its equivalence to the Diffie-Hellman protocol when facing a passive attacker. While SRP is a mature and widely used protocol, it is based on an older design that has shown some subtle weaknesses in certain variants. For example, SRP is not universally composable (UC-secure), does not fully resist all precomputation attacks, has less robust formal security proofs, and lacks protection against some modern attack scenarios.

As a result, SRP is now considered somewhat outdated. Modern alternatives have emerged, such as OPAQUE, which is the preferred augmented PAKE protocol, and CPace or SPAKE2, which are better suited for balanced PAKE scenarios where both parties share the password. These newer protocols address many of the limitations found in SRP and are designed to meet the demands of contemporary security models [2].

Even so a detailed study of SRP protocol and its implementation is considered a good learning exercise as I will try to show.

The ins and outs of SRP protocol

SRP leverages the computational difficulty of the discrete logarithm problem. Both client and server perform complex mathematical operations involving large prime numbers, generating ephemeral keys and shared secrets that prove knowledge without revelation. The protocol ensures that even if someone intercepts all network traffic, they gain no advantage in discovering the client's password.

The result is an authentication that's both more secure and more private than anything passwords alone can provide.

There are two phases in the SRP protocol.

In the first phase the user makes the registration in the server, afterwards he can perform the authentication whenever he needs.

Registration at the SRP protocol

The registration process in the SRP serves one fundamental purpose: to establish a mathematical relationship that enables future authentication without ever requiring password transmission or storage.

The goal of the registration process is to the client and the server come into an agreement about the group parameters, namely the big prime number N and the generator g. Also in this phase the client defines the password and sends it to the server its verifier, without exposing by itself the password, figure 1.

Figure 1: Registration process at the SRP protocol.

Initially the client identifies itself by its username (U) and optionally the requested group ID, the server generates a cryptographically secure, unique per user, random salt and returns also the required N and g from the group ID that ensures the minimum level of security that is acceptable at the server side.

The N and g parameters are chosen according to the group ID defined at the RFC-5054, where the ID 1 correspond to the minimum security level with a smaller prime N (1024 bits size) and the group ID 7 correspond to the the maximum security level with the greater prime N (8192 bits size).

Full information of the groups ID defined at RFC-5054 can be found in this json file used in this implementation.

With a greater group ID, the size of the prime will increase and the hash algorithm will be more complex, that will bring more security but at the cost of extra computation every time this protocol needs to be executed.

After the successful conclusion of the registration process at the SRP protocol the client will have the corresponding salt of that session, and also the given N and g parameters from the required group ID to be used at the SRP protocol with that server.

At the server side, he will have the salt s generated for that given user U, and also the verifier of the password v.

Authentication of the SRP protocol

The authentication process in SRP serves one fundamental purpose: to enable mutual verification of identity between client and server without transmitting the password or any password-equivalent data.

Here is the communication flow between the client and the server at the authentication using the SRP protocol, figure 2:

Figure 2: Authentication process at the SRP protocol [1].

Primary Objectives:

Zero-Knowledge Password Verification

The authentication process allows the client to prove he knows the password without transmitting the password over the network, revealing any information that could be used to recover the password, giving the server access to password-equivalent data.

Mutual Authentication:

Unlike traditional password systems, SRP authentication provides bidirectional verification:
Client authenticates to Server: "I know my password" (via M proof)
Server authenticates to Client: "I have your legitimate verifier" (via M2 proof)

Secure session establishment:
The authentication process generates a shared session key (K) that both parties can compute independently:

Client: S = (B - k * g^x) ^ (a + u * x) mod N  

Server: S = (A * v^u)^b mod N

Implementation Details of the SRP protocol

The SRP protocol was implemented in C++, using the HTTP requests library from Crow and regarding the big number arithmetic, it was used the services available at the OpenSSL.

OpenSSL provides cryptographic primitives such as hashing (SHA-1, SHA-256, etc.) and big integer arithmetic (via BIGNUM), ensuring compliance with cryptographic standards and avoids reinventing the wheel for low-level operations.

The HTTP server Implements the SRP protocol as a web service with endpoints for:

registration (/srp/register/init, /srp/register/complete);
authentication (/srp/auth/init, /srp/auth/complete);

In this way the clients interact with the server over HTTP, simulating real-world use cases.

The validation of the protocol was performed against python scripts used to cross-validate the C++ implementation against RFC 5054 [1] test vectors, ensuring correctness of key computations (e.g., x, v, S, K, M, M2) by comparing results from both implementations.

The unit tests in C++ also validate all the intermediate results against the RFC 5054 [1] test vectors.

Architecture decisions

Modular Design

To manage the complexity of the SRP protocol, it was adopted a modular and extensible architecture, namely:

Client Class:

Handles the client-side computations (e.g., A, x, S, K, M).
Manages the registration and authentication flows from the client’s perspective.

Server Class:

Handles the server-side computations (e.g., B, S, M2).
Manages user sessions and validates client proofs during authentication.

SecureRemotePassword Class:

Encapsulates the SRP protocol logic, including cryptographic operations and parameter validation.
Acts as the core engine for both the client and server.

SessionData Class:

Manages session-specific data (e.g., ephemeral keys, group parameters, and state).
Ensures that each session is isolated and stateless between requests.

SrpParametersLoader:

Loads SRP group parameters (e.g., N, g) from a JSON file (SrpParameters.json).
Supports multiple groups (1024-8192 bits) as defined in RFC 5054 [1].

EncryptionUtility:

Provides helper functions for hashing, big integer operations, and padding.
Abstracts cryptographic details, making the code more readable and maintainable.

Multi-Group Support:

The implementation supports multiple SRP groups, allowing flexibility in cryptographic strength, accordingly to the server requirements in terms of security:

Groups Supported:

1024-bit (Group 1)
1536-bit (Group 2)
2048-bit (Group 3)
3072-bit (Group 4)
4096-bit (Group 5)
6144-bit (Group 6)
8192-bit (Group 7)

It exists a multi group support because different applications may require different levels of security. Smaller groups (e.g., 1024-bit) are faster but less secure, while larger groups (e.g., 8192-bit) provide stronger security at the cost of performance.

Group parameters (N, g) are loaded dynamically from SrpParameters.json. The client and server negotiate the group during the registration phase.

Multiple Hash Algorithms:

To ensure flexibility and compliance with RFC 5054 [1], it was included support for multiple hash algorithms,. namely:

SHA-1 (to validate against the RFC 5054 [1] test vectors)
SHA-256
SHA-384
SHA-512

Different systems and applications may require different hash algorithms based on security policies, as the requirements of each group varies in relation to the hash algorithms.

SHA-1 is included for compatibility with RFC 5054 [1] test vectors, but stronger hashes (e.g., SHA-256, SHA-512) are recommended for modern systems.

Hash functions are abstracted in the EncryptionUtility class. The hash algorithm is negotiated during the registration phase and stored as part of the session.

Architecture Highlights

The registration flow is composed of these requests by the client:

/srp/register/init: The client requests SRP parameters (e.g., N, g, salt) from the server;
/srp/register/complete: The client sends the computed verifier (v) to the server, which stores it for future authentication.

If the registration proceeds until completion then the client is then able to perform the authentication with the server afterwards.

The authentication flow is implemented as two HTTP endpoints:

/srp/auth/init: The client sends its username (U) to the server. The server responds with s, B, and groupId.
/srp/auth/complete: The client sends A and M to the server. The server validates M and responds with M2 for mutual authentication.

Both client and server compute the shared secret S independently. The session key K = H(S) is derived for secure communication.

The Class diagram of the implementation of the SRP protocol is available at the figure 3:

Figure 3: Class diagram of the SRP protocol implementation

Figure 4: Sequence diagram of the SRP protocol implementation

Testing & Validation Strategy

Testing and validation were critical to ensuring the correctness, security, and compliance the SRP implementation with RFC 5054[1]. A multi-layered approach was adopted to cover all aspects of the protocol, from individual components to full end-to-end flows.

Unit Tests: Test cases across all Components

Unit testing was the foundation of the validation strategy. Each component of the SRP protocol was tested in isolation to ensure correctness and robustness.

Key Areas Covered:

Mathematical Operations: Modular exponentiation, padding, and big integer arithmetic using OpenSSL's BIGNUM.
Hashing Functions: Validation of SHA-1, SHA-256, SHA-384, and SHA-512 wrappers.
Parameter Validation: Ensuring constraints like 1 < A < N and 1 < B < N are enforced.
Session Management: Testing the SessionData class for proper state handling.

Example Test Cases:

Verifying that calculateU produces the correct scrambling parameter u for given inputs.
Ensuring calculateX correctly derives the private key x from the salt, username, and password.
Validating calculateV to ensure the verifier v matches RFC 5054[1] test vectors.

RFC Vector Testing: Validation Against Official Test Vectors:

To ensure compliance with the SRP protocol as defined in RFC 5054 [1], the implementation was tested against the official test vectors provided in the specification.

Test Vector input parameters:

Username: "alice"
Password: "password123"
Salt: "BEB25379D1A8581EB5A727673A2441EE"
Group: 1024-bit (Group 1)
Hash Algorithm: SHA-1
Private key a: "60975527035CF2AD1989806F0407210BC81EDC04E2762A56AFD529DDDA2D4393"
Private key b: "E487CB59D31AC550471E81F00F6928E01DDA08E974A004F49E61F5D105284D20"

Validate Outputs:

Public keys (A, B)
Scrambling parameter (u)
Shared secret (S)
Session key (K)
Intermediate results: (k, x)

All computed values matched the RFC 5054 [1] test vectors, confirming the correctness the implementation, these test vector were essential to confirm the entire correctness of this implementation.

Cross-Language Validation: Python scripts for mathematical verification

To further validate the correctness of the C++ implementation, Python scripts were used to cross-check key computations.

Python Validation Scripts:

calculateX.py: Validates the private key x.
calculateV.py: Validates the verifier v.
calculateSClient.py and calculateSServer.py: Validate the shared secret S on both client and server sides.
calculateM.py and calculateM2.py: Validate the client and server proofs.
calculate_k_MultiplierParameter.py : Verifies the correctness of the multipliers k for each group.
calculateK.py: Validates the Key generation K.
calculatePublicKey.py: Validates the public key generation A and B.
calculateU.py: Validates the parameter u calculation.
testSRP_withRFC_vector.py: Test that the S at the client and server match with RFC-5054 test vectors.

Python’s simplicity and precision in handling big integers made it ideal for cross-referencing results. The scripts served as a secondary implementation to catch potential bugs in the C++ code during the development.

Integration Testing: Full Protocol Flows

Integration tests were designed to validate the entire SRP protocol flow, from registration to authentication.

Tested flow:

Registration: Ensuring the client computes v correctly and the server stores it securely.
Authentication: Verifying that both client and server compute the same shared secret S and session key K.

Edge cases:

Invalid usernames or passwords.
Mismatched group parameters (N, g).

Manual Testing: Curl Commands for Endpoint Validation

Manual testing was performed using curl's to simulate client-server interactions and validate the HTTP endpoints.

Endpoints Tested:

/srp/register/init: Validates the server’s response with group parameters and salt.
/srp/register/complete: Ensures the server correctly stores the verifier.
/srp/auth/init: Validates the server’s generation of B and response to the client.
/srp/auth/complete: Ensures mutual authentication and session key derivation.

Example curl command:

curl -X POST http://localhost:18080/srp/auth/init \
-H "Content-Type: application/json" \
-d '{
  "clientId": "alice"
}' | jq

This multi-layered approach to testing and validation was essential to build a robust and standards-compliant SRP implementation.

Lessons Learned & Best Practices

Implementing the Secure Remote Password (SRP) protocol from scratch was both a challenging and rewarding experience. Along the way, I encountered several key insights and developed best practices that are applicable not only to SRP but to cryptographic implementations in general.

Mathematical Precision is Crucial

Cryptographic protocols like SRP rely heavily on precise mathematical operations. Even small errors in modular arithmetic, padding, or hashing can lead to incorrect results or security vulnerabilities.

Lesson Learned: Always validate intermediate results against known test vectors (e.g., RFC 5054 [1]).
Best Practice: Use well-tested libraries like OpenSSL for low-level operations (e.g., BIGNUM) instead of implementing them from scratch.

Cross-Validation Saves Time

Cross-language validation was invaluable in catching subtle bugs. Python scripts were used to verify the correctness of key computations (e.g., x, v, S, K) against the C++ implementation.

Lesson Learned: A secondary implementation in a simpler language (like Python) can help identify discrepancies early.
Best Practice: Write small, focused scripts to validate each step of the protocol independently.

Comprehensive Testing is Essential

Testing was the backbone of this implementation. From unit tests to integration tests, every component was rigorously validated, this was the solution to handle the complexity of the protocol.

Lesson Learned: Cryptographic protocols require more than just functional testing; they need validation against edge cases and compliance with standards.
Best Practice: Use official test vectors (e.g., RFC 5054 [1]) to ensure compliance.Test with multiple group sizes (1024-bit to 8192-bit) and hash algorithms (SHA-1 to SHA-512). Include negative tests (e.g., invalid inputs, mismatched parameters).

Modular Design Simplifies Complexity

SRP is a complex protocol with multiple moving parts (registration, authentication, cryptographic computations). A modular design made it easier to manage and debug.

Lesson Learned: Breaking the implementation into smaller, reusable components (e.g., Client, Server, SecureRemotePassword) reduces complexity and improves maintainability.
Best Practice: Follow the single responsibility principle—each class or module should handle one specific aspect of the protocol.

Documentation is key for maintainability

Cryptographic protocols are inherently complex, and maintaining clarity is critical. Detailed documentation, including UML diagrams, helped keep the implementation organized and understandable to onboard future developers and manage complexity.

Lesson Learned: Clear documentation is as important as the code itself, especially for protocols with intricate flows like SRP.
Best Practice: Use UML diagrams to visualize class relationships and sequence flows. Document every step of the protocol, including assumptions, constraints, and edge cases.

Security is Non-Negotiable

SRP is designed to be secure, but the implementation must also follow best practices to avoid introducing vulnerabilities.

Lesson Learned: Security is not just about following the protocol; it’s about ensuring every detail is implemented correctly.
Best Practice: Use cryptographically secure random number generators for ephemeral keys. Validate all inputs (e.g., A, B, u) to ensure they meet protocol constraints. Clear sensitive data (e.g., passwords, session keys) from memory after use.

Cross-Disciplinary Knowledge is Key

Implementing SRP required knowledge of cryptography, software engineering, and network protocols. Understanding the theoretical foundations (e.g., zero-knowledge proofs, modular arithmetic) was just as important as writing the code.

Lesson Learned: Cryptographic implementations demand a balance of theoretical understanding and practical engineering skills.
Best Practice: Invest time in studying the underlying mathematics and security principles before diving into the implementation.

Iterative Development Works Best

The SRP implementation was built iteratively, starting with the registration flow, followed by the authentication flow, and finally the integration of all components.

Lesson Learned: Tackling one part of the protocol at a time reduces the risk of being overwhelmed and allows for focused testing.
Best Practice: Break the implementation into milestones and validate each step before moving to the next.

Standards Are Your Guide

RFC 5054 [1] provided a clear road map for implementing SRP. Adhering to the standard ensured that the implementation was interoperable and secure.

Lesson Learned: Standards like RFC 5054 [1] are invaluable for ensuring correctness and interoperability.
Best Practice: Always refer to the official specification and test against its requirements.

Quick Demo of the SRP protocol

In this section it is shown a quick demo of the SRP protocol, and in the end the unit tests are executed as well. The server process is launched first to ensure that the client's request reach it's destination, video 1: SRP protocol implementation demo in the first part, complete set of unit tests in the last part of the video.

Explore the Code

If you’re interested in diving deeper into the implementation, you can find the full source code, including all tests and Python validation scripts, on my GitHub repository: GitHub Repository - SRP Implementation.

References:

[1] D. Taylor, T. Wu, N. Mavrogiannopoulos, and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication," IETF RFC 5054, November 2007. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc5054.

[2] Wikipedia, "Secure Remote Password Protocol," [Online]. Available: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol.

Man in the Middle Attack to the Diffie Hellman key exchange: g parameter injection variant

Tiago Sousa — Sat, 02 Aug 2025 11:32:47 +0000

Introduction

The Diffie Hellman key exchange protocol [1] normally have the group values (prime p and generator g) defined statically containing a standardized list of values. In this article I will explain what can happen if those values are negotiated dynamically instead of statically from a few standardized values contained on the RFC 3526 [2].

What are the values negotiated via the RFC 3526 ?

RFC 3526 defines a standardized Modular Exponential Groups (MODP) to be used in the Diffie Hellman (DH) key exchange protocol. These values are public but critical for the security, efficiency and success of this protocol.

RFC 3526 provides predefined prime p and generator g for DH groups of various sizes, depending on the security requirements:

1536-bit MODP Group (not recommended anymore)
2048-bit MODP Group
3072-bit MODP Group
4096-bit MODP Group
6144-bit MODP Group
8192-bit MODP Group

Each group specifies:

prime p: a large safe prime, such that (p-1)/2 is also prime, called a Sophie Germain prime.
generator g: usually g = 2

The 1536 bit MODP group is not recommended anymore because as the computational capabilities increased, well funded adversaries can run precompute data used on the DH key exchange protocol for each (p, g) pair using the Number Field Sieve Algorithm (NFS) creating big tables of modular logarithms that can afterwards be used to access large number of websites that use that particular MODP group. This attack was already shown on the Logjam Attack paper (2015) [3].

Here is an example of a 6144-bit MODP Group present in the RFC 3526 in hexadecimal format:

p = 0xFFFFFFFF FFFFFFFF C90FDAA2 
      2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6
      3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D
      F25F1437 4FE1356D 6D51C245
      E485B576 625E7EC6 F44C42E9
      A637ED6B 0BFF5CB6 F406B7ED
      EE386BFB 5A899FA5 AE9F2411
      7C4B1FE6 49286651 ECE45B3D
      C2007CB8 A163BF05 98DA4836
      1C55D39A 69163FA8 FD24CF5F
      83655D23 DCA3AD96 1C62F356
      208552BB 9ED52907 7096966D
      670C354E 4ABC9804 F1746C08
      CA18217C 32905E46 2E36CE3B
      E39E772C 180E8603 9B2783A2
      EC07A28F B5C55DF0 6F4C52C9
      DE2BCBF6 95581718 3995497C
      EA956AE5 15D22618 98FA0510
      15728E5A 8AAAC42D AD33170D
      04507A33 A85521AB DF1CBA64
      ECFB8504 58DBEF0A 8AEA7157
      5D060C7D B3970F85 A6E1E4C7
      ABF5AE8C DB0933D7 1E8C94E0
      4A25619D CEE3D226 1AD2EE6B
      F12FFA06 D98A0864 D8760273
      3EC86A64 521F2B18 177B200C
      BBE11757 7A615D6C 770988C0
      BAD946E2 08E24FA0 74E5AB31
      43DB5BFC E0FD108E 4B82D120
      A9210801 1A723C12 A787E6D7
      88719A10 BDBA5B26 99C32718
      6AF4E23C 1A946834 B6150BDA
      2583E9CA 2AD44CE8 DBBBC2DB
      04DE8EF9 2E8EFC14 1FBECAA6
      287C5947 4E6BC05D 99B2964F
      A090C3A2 233BA186 515BE7ED
      1F612970 CEE2D7AF B81BDD76
      2170481C D0069127 D5B05AA9
      93B4EA98 8D8FDDC1 86FFB7DC
      90A6C08F 4DF435C9 34028492
      36C3FAB4 D27C7026 C1D4DCB2
      602646DE C9751E76 3DBA37BD
      F8FF9406 AD9E530E EE5DB382
      F413001A EB06A53E D9027D83
      1179727B 0865A891 8DA3EDBE
      BCF9B14E D44CE6CB ACED4BB1
      BDB7F144 7E6CC254 B3320515
      12BD7AF4 26FB8F40 1378CD2B
      F5983CA0 1C64B92E CF032EA1
      5D1721D0 3F482D7C E6E74FEF
      6D55E702 F46980C8 2B5A8403
      1900B1C9 E59E7C97 FBEC7E8F
      323A97A7 E36CC88B E0F1D45B
      7FF585AC 54BD407B 22B4154A
      ACC8F6D7 EBF48E1D 814CC5ED
      20F8037E 0A79715E EF29BE32
      806A1D58 BB7C5DA7 6F550AA3
      D8A1FBFF 0EB19CCB 1A313D55
      CDA56C9E C2EF2963 2387FE8D
      76E3C046 8043E8F6 63F4860E
      E12BF2D5 B0B7474D 6E694F91 
      E6DCC402 4FFFFFFF FFFFFFFF
      F

g = 0x02

During the TLS handshake, the first steps in the Diffie Hellman Key exchange protocol is to negotiate the DH group to use (e.g. MODP 2048-bit group), that defines the value of the prime p and the generator g.

These values are not secret, but are instead public and standardized.

These two values are important because the strength of the DH depends on the size of the prime p.

The use of standardized parameter groups allows or requires:

Security: The larger the prime p, the harder the discrete logarithm problem, as the problem space increases with the size of the prime. The RFC 3526 ensures well chosen, trusted primes to prevent backdoors.

Interoperability: predefined groups means all compliant system can interoperate without the necessity to generate new prime numbers every time, that is an expensive operation and error prone as the prime has to meet certain requirements such as to be of the form p = 2q+1 where p is prime. Also p should be generated using a verified random process.

The generator should also meet security requirements such as:

the correct sub group should be of the form that g ^ q = 1 mod p

Mitigating precomputation attacks: when a large number of websites uses the same group, attackers can precompute a database of discrete logarithms (Logjam attack) [3] and dilute the attack cost based on the access to that large number of users, so this is a trade-off that has to be taken into consideration, when the computational technology evolves or faster algorithms are published the minimum MODP security requirements should be reviewed.

Performance: large groups guarantee more security but are slower, as the computation will take more time to complete.

Negotiations on a case by case regarding security requirements allow a better balance of security and efficiency as a security and performance compromise.

What can happen if the prime p and generator g are negotiated dynamically ?

If the prime p and generator g are negotiated dynamically instead of statically via the already mentioned MODP Groups present on the RFC 3526, a MitM attack can inject weak or malicious parameters into the real server, breaking intended security of the DH key exchange protocol.

Here follows some of the malicious parameters that can be injected by a MitM attacker:

Weak prime p: if p is too small (e.g. 512 bits), the discrete log problem becomes easy, and the attacker can compute the shared key in real time using the Logjam Attack [3] by means of a precomputed table of discrete logarithms results using the NFS algorithm.

Composite or non-prime p: if the p is composite the security will depend on the strength of the smaller prime, so the bit security of the p will be much less than intended, and directly proportional to the strength of the smaller prime factor of that composite p.

Generator g set to 1, then:

at Alice side, for a given secret key a the calculation of the resulting public key A will result in the following: A = g ^ a mod p = 1 ^ a mod p = 1.
at Bob side, for a given secret key b the calculation of the resulting public key B will result in the following: B = g ^ b mod p = 1 ^ b mod p = 1.
The resulting shared key, will be computed at Alice side by means of: S = B ^ a mod p = 1 ^ a mod p = 1 and on Bob side: S = A ^ b mod p = 1 ^ b mod p = 1.

Generator g set to p, then:

at Alice side, for a given secret key a the calculation of the resulting public key A will result in the following: A = g ^ a mod p = p ^ a mod p = 0.
at Bob side, for a given secret key b the calculation of the resulting public key B will result in the following: B = g ^ b mod p = p ^ b mod p = 0.
The resulting shared key, will be computed at Alice side by means of: S = B ^ a mod p = 0 ^ a mod p = 0 and on Bob side: S = A ^ b mod p = 0 ^ b mod p = 0.

Generator g set to p-1, then:

at Alice side, for a given secret key a the calculation of the resulting public key A will result in the following: A = g ^ a mod p = (p-1) ^ a mod p = (-1) ^ a mod p = +/- 1 , with the signal depending on the parity of value a.
at Bob side, for a given secret key b the calculation of the resulting public key B will result in the following: B = g ^ b mod p = (p-1) ^ b mod p = (-1) ^ b mod p = +/- 1 , with the signal depending on the parity of value b.
The resulting shared key, will be computed at Alice side by means of: S = B ^ a mod p = (+/-1) ^ a mod p = +/- 1 and on Bob side: S = A ^ b mod p = (+/-1) ^ b mod p = +/-1
The signal of S will depend on the parity of number (ab). This manipulation will reduce the security to 1 bit of entropy.

MitM attack to the DH key exchange protocol implementation:

In this section is presented a practical implementation of the MitM attack to the DH key exchange protocol with a g parameter injection variant.

Mallory in this example is replacing the URL of the real server.

In a real word scenario the initial communication between the two would need to be downgraded to HTTP and Mallory would need to use a software like Wireshark or mitmproxy to catch the data between the two, change it and send it afterwards to the destiny.

The g and p parameters are being exchanged via REST messages, this example exemplifies the importance of adhering to the standard RFC 3526 [2] to avoid the values to be swapped dynamically by a third party in the middle of the communication channel.

The class diagram of this solution is present at figure 1:

The communication between the client and the server is done via HTTP requests and it is the client that has the initiative on this protocol.

The server exposes three endpoints:

one to execute the DH key exchange protocol via the POST /keyExchange.
one to retrieve all the session keys created on the server side via the GET /sessionsData.
one to perform a secure message exchange with a client after the DH key exchange protocol has been completed via the GET /messageExchange.

The sequence diagram of this attack is shown next, figure 2, it is possible to see in detail the actions that the attacker Mallory is performing to the DH key exchange protocol in the initial POST /keyExchange endpoint and afterwards on the GET/messageExchange itself.

Main results obtained during the attack:

The attack was perform for the different possible scenarios, here are the results:

For the substitution of g = 1 at the MitM, we got the following result for a given simulation at figure 3:

As we can see the shared secret at the server is equal to 1 and then the derived key material will be derive from the nonce's from the client and the server, that are public, so the security is eliminated.

For the substitution of g = p at the MitM, we got the following result for a given simulation at figure 4:

For the substitution of g = p-1 at the MitM, we got the two results for a given simulation, the first one is present at figure 6:

The second result, that is equal to p-1 can also appear for the substitution of g = p-1, being the resulting shared secret non deterministic, with the space result of {-1, 1}, figure 7.

Next follows a quick demo of this attack, video 1, with the client on the left screen, Mallory's fake server in the middle screen and the real server on the right. The client will try to perform the POST /keyExchange first, and as it succeeds, it will latter also perform the GET /messageExchange message, both communications will pass the client verification's, so he remains oblivious of the actions of Mallory the whole time.

All the requests from the client are relayed by the fake Mallory server to the real server, in spite of that, there is no error being triggered by the real server.

This demo is for the injection of the malicious parameter of g = 1 by the MitM. The resulting shared secret key on the server on the right is possible to observe, being equal to 1 as expected.

MitM attack with malicious g parameter injection g = 1 is present at the following link: demo.

How to protect against a MitM attack against the DH key exchange protocol

The MitM attack exposes a critical vulnerability in the original Diffie Hellman key exchange, namely the lack of authentication. While DH key exchange protocol was able to solve very cleverly the problem of establishing a shared secret over an insecure channel, it doesn't verify the identities of the parties involved.

To secure Diffie Hellman against MitM attacks, the messages exchanged between Alice and Bob, namely their public keys A and B, must be authenticated. This ensures that the public keys received truly belong to Alice and Bob, preventing Mallory from replacing her own keys [4].

In the case of the current attack in specific, it is also recommended to not publicly exchange and negotiate the p and g parameters but instead exchange the Diffie Hellman Groups for the Internet Key Exchange present on the RFC 3526 statically via their group identification.

References:

[1] T. Sousa, "Diffie-Hellman Key Exchange Protocol," LinkedIn, June 2025. [Online]. Available: https://www.linkedin.com/pulse/diffie-hellman-key-exchange-protocol-tiago-sousa-tlgpf.

[2] D. Kivinen and H. Krawczyk, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)," IETF RFC 3526, May 2003. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc3526.

[3] D. Adrian et al., "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice," in Proceedings of the 22nd ACM Conference on Computer and Communications Security (CCS), Oct. 2015. [Online]. Available: https://weakdh.org/imperfect-forward-secrecy.pdf.

[4] T. Sousa, "Man-in-the-Middle Attack in Diffie-Hellman Key Exchange Protocol," LinkedIn, July 2025. [Online]. Available: https://www.linkedin.com/pulse/man-middle-attack-diffie-hellman-key-exchange-protocol-tiago-sousa-7fdhf.

SVG's images advantages and use cases

Tiago Sousa — Fri, 11 Jul 2025 14:04:12 +0000

𝗦𝗩𝗚 (Scalable Vector Graphics) is an XML based vector image format for two-dimensional graphics.

Main characteristics of SVG files:

XML based: Unlike the binary image formats (e.g. PNG, JPEG or GIF) an SVG file is only a text file written in XML (eXtensible Markup Language). This means that it's file can be opened on a text editor and its content read. It can contain tags such as circle, rect, path or text, each with attributes that can define position, size, color and other properties.
This is an advantage for developers because being XML based make these files programmable and version controllable instead of static binary files such as PNP and JPEG formats.
Vector Graphics: SVG images are composed of vector graphics, this makes the difference from "raster graphics" used at PNG's and JPEG's image format.

Raster Images: The images of this kind such as PNG and JPEG are composed with a grid of individual pixels, when a zoom is done in a raster image, the individual pixels start to show up, leading to a blurry appearance and low resolution resulting in a low quality image.

Vector Images (SVG): These images of this kind, such as SVG are defined by mathematical equations and geometric objects such as points, lines, curves and shapes. With this type of image, instead of being stored pixel data, an SVG file stores instead how to draw the image.
This allows an unmatched scalability, allowing the images to be rendered perfectly at any size or resolution without any loss of quality.

Cons of SVG:

Not ideal for complex photographs: while it would also be possible to use SVG in complex photos, every pixel would need complex mathematical description, and the file's size would be very large.
Increased complexity for creation: as the complexity of the images increase the technical knowledge requirements of vector graphics software will also increase.

Best use cases in Software context for SVG image format:

Logos and icons;
User interface elements such as buttons, form controls and others;
Diagrams and flowcharts (Class, Sequence, Architecture): where scalability, traceability, edibility and programmatic generation are important;
Data visualizations: Interactive charts, graphs and maps;

On figure 1 is possible to see the advantage of svg images compared to a png, when there is the need to have a high resolution.

Figure 1: Side by side comparison between a png and a svg image

In conclusion:
SVG can be a good format if you want to work with an Icon, logo, diagram or interactive graphics, where scalability, editability, programmatic control, resolution independence and traceability are important.

Man in the middle attack in the Diffie Hellman key exchange protocol and how to defend against it

Tiago Sousa — Thu, 10 Jul 2025 12:54:35 +0000

Introduction

After having explained on the previous article what is the Diffie Hellman key exchange protocol, in this present article I will talk about a possible attack that this protocol can suffer if no authentication of any party involved is performed.

The article will touch upon the following topics:

what is and how it works the man in the middle attack in the context of the Diffie Hellman key exchange protocol;
what is and how it works the parameter injection in the context of the Diffie Hellman key exchange protocol;
what was the structure used in this prove of concept, and the results obtained;
a quick demo of the attack taken place;
a mitigation action to prevent this attack and why it works;

Man in the Middle Attack (MitM) explained

The Diffie Hellman key exchange protocol addresses the fundamental necessity of two independent parties to agree upon a secret key without any prior shared secret, even if their entire conversation is openly observed by an adversary.

The basic Diffie Hellman key exchange protocol, on its pure form, possesses a critical vulnerability, as it provides no inherent authentication of the parties involved.

This opens the door to a MitM attack, in such an attack, a malicious third party, often named Mallory, places itself between Alice and Bob, intercepting, passing or even altering their communications, all while each party believe they are communicating directly with each other.

Diffie Hellman (DH) key exchange quick recap

At its core, the DH key exchange protocol relies on the mathematical properties of the modular exponentiation and the computational difficulty of the Discrete Logarithm Problem (DLP), the main steps are:

Public agreed parameters: Alice and Bod first openly agreed on two large numbers, that are standardize [2].
- A large prime number, p.
- A generator g (a number whose powers modulo p generate a large set of number between [0, p-1] if p is a big prime number. These parameters are public and known to anyone, including the eavesdropper.
Private key generation: each party in this protocol uses a cryptographic secure pseudo random number generator (CSPRNG) to avoid predictability to choose a private key.
- Alice secretly chooses a large random integer number, her private key a such that 1<a<p-1.
- Bob secretly chooses a large random integer number, her private key b such that 1<b<p-1.
Public key generation: each party in this protocol performs the following calculation:
- Alice computes her public key: A = g^a (mod p)
- Bob computes his public key: B = g^b (mod p)
The exchange of public keys:
- Alice sends her public key A to Bob.
- Bob send his public key B to Alice. Even if a eavesdropper observes A, B, g and p, it is computationally infeasible for him to derive a and b due to the DLP difficulty.
Shared secret calculation:
- Alice computes the shared secret: K = B^a (mod p)
- Bob computes the shared secret: K = A^b (mod p)

They both arrive at the same exact shared secret K since:
B^a (mod p) = (g^b)^a (mod p) = g^ba (mod p) = K
A^b (mod p) = (g^a)^b (mod p) = g^ab (mod p) = K

The virtue of the DH key exchange protocol is that it provides the ability to establish a shared secret without never transmitting the secret itself. However, its main flaws is that it does not provide any mechanism for Alice to verify that she is truly exchanging keys with Bob, and on the same manner, that Bob is really exchanging keys with Alice, this is the reason why the MitM attack is possible.

Possible scenarios where the MitM attack can be executed

There are several practical scenarios where the MitM attack can be executed, here are some of them:

Public Wi-Fi eavesdropping:
- Scenario: A person connects to a free, open Wi-Fi newtwork in a public space.
- Attack: The attacker uses a rogue hotspot (e.g. "Free_Airport_WiFi") or is connected to the same network and uses packet sniffing tools (e.g. Wireshark or mitmproxy) to intercept unencrypted traffic.
- Result: If that person is visiting an unencrypted (non HTTPS) website, the attacker sees their persons credentials or session data.
SSL stripping:
- Scenario: A person is visiting a website that should be secure (HTTPS), but an attacker downgrades the connection to HTTP.
- Attack: The attacker intercepts the initial connection and removes the HTTPS encryption, forcing the user to use plain HTTP instead.
- Result: The attacker sees everything in plaintext.
ARP Spoofing (Local Network MitM):
- Scenario: A person is on the same local network as the attacker.
- Attack: The attacker sends fake ARP messages to associate their MAC address with the IP address of the gateway.
- Result: All the traffic of that user goes through the attacker's machine before reaching the service destination on the internet.
Compromised Router or internet service provider (ISP):
- Scenario: A home router is misconfigured or compromised.
- Attack: The attacker intercepts and alters the DNS queries or the HTTP traffic at the router level.
- Result: Redirected sites, credential theft or malware injection.
MitM in cryptography protocols (e.g.: Diffie Hellman key exchange protocol):
- Scenario: Alice and Bob are performing a key exchange protocol.
- Attack: The attacker intercepts the key exchange and establishes two independently and separated keys with Alice and Bob.
- Result: The attacker can read, modify and relay all encrypted messages between Alice and Bob.

MitM attack in Diffie Hellman key exchange protocol explained

The crucial part of this attack is that the attacker, Mallory, is able to set up two independent keys with Alice and Bob, here is a sequential walk through of the attack:

Alice initiates the Key Exchange: Alice generates her private key a and computes her public key A = g^a (mod p). She sends p, g and A to Bob.
Mallory intercepts Alice's public key: Mallory intercepts Alice's message containing p, g and A to Bob.
Mallory impersonates Alice to Bob: Instead of forwarding Alice's actual public key to Bob, Mallory generates his own private key, let's consider mA. He then computes his own public key MA =g^mA (mod p). Afterwards, Mallory sends p, g and MA to Bob, instead of the actual Alice's public key A.
Bob responds to Mallory (thinking it is Alice): Bob receives MA (thinking it is A instead). He generates his private key b, computes his public key B = g^b(mod p), and calculates a shared secret with Mallory public key, instead of Alice's:

Kbm = (MA)^b(mod p). Bob then sends his public key B back to Alice, unaware that is Mallory that is receiving it.
Mallory intercepts Bob's public key: Mallory intercepts Bob's message containing B.
Mallory impersonates Bob to Alice: Instead of forwarding Bob's actual public key B to Alice, Mallory generates another private key, mB. He computes his own public key MB = g^mB(mod p). Mallory them sends MB to Alice, pretending that MB is Bob's public key.
Alice completes the key exchange with Mallory (thinking it's Bob): Alice receives MB (thinking it is B). She then calculates a shared secret with Mallory instead of Bob: Kam = (MB)^a (mod p).

In the end of this exchange, Mallory is in the possession of two separate shared secrets, such that:

Alice believes she has established a shared secret Kam with Bob.
Bob believes he has established a shared secret Kbm with Alice.
Mallory knows both Kam and Kbm.

As Kam and Kbm are entirely different secrets, both Alice and Bob are communicating securely with Mallory instead with each other.

Attack in action

After Mallory has setup two distinct shared secrets with both Alice and Bob, he can now act as a transparent proxy, in the following manner:

Alice to Bob: When Alice encrypts a message using Kam and sends it to Bob, Mallory intercepts it and decrypts it using Kam also, reads the plaintext, and latter modifies or just pass the original message, encrypting it again now with Kbm before sending it to Bob.
Bob to Alice: When Bob encrypts a message using his symmetric key Kbm and then sends it to Alice, Mallory can intercept it and decrypt it, using Kbm. He can then read and/or potentially modify and afterwards re-encrypt it again using this time the Kam before sending it to Alice.

From both Alice and Bob's perspective, their communications seems secure and private, they have no clue that their messages are being read or potentially altered by a third party.

This complete failure on confidentiality and integrity is the consequence of MitM attack when there is no authentication on the Diffie Hellman key exchange protocol.

MitM attack with parameter injection with prime p

One variant of the MitM attack is the parameter injection, in this example with the prime p as the parameter injected. This attack forces the shared secret between the two parties to become a known and trivial value as I will try to show next.

This result is achieved by means of the properties of the modular arithmetic to fix the shared secret between Alice and Bob to zero o by injecting the prime p itself, here follows the steps with Mallory's injection strategy:

Alice initiates the Key Exchange: Alice generates her private key a and computes her public key A = g^a (mod p). She sends p, g and A to Bob.
Mallory intercepts Alice's public key (A): Mallory intercepts A. Instead of him generating his own public key he performs the substitution in the next step.
Mallory injects p to Bob: Mallory sends the large prime p instead of his public key, pretending it is Alice's public key, MA = p.
Bob's shared secret calculation: Bob receives MA = p (thinking it is Alice's A). He then computes his shared secret Kbm using this private key b.

Kbm = (MA)^p (mod p) <=> Kbm = p^p (mod p) <=> Kbm = 0 because any positive integer power of p will always be a multiple of p.
Bob's public key calculation: Bob computes his public key B = g^b (mod p) and sends it towards Alice.
Mallory intercepts Bob's public key (B): Mallory intercepts B and then performs the same substitution for p instead.
Mallory injects p to Alice: Mallory sends the large prime number p itself to Alice, pretending it is Bob's public key, so Alice receives MB = p.
Alice's shared secret calculation: Alice receives MB = p (thinking it is Bob's B). She then computes his shared secret Kam using this private key a.

Kam = (MB)^p (mod p) <=> Kam = p^p (mod p) <=> Kam = 0 because any positive integer power of p will always be a multiple of p.

At the end of this MitM attack variant, both Alice and Bob believe they have successfully established a shared secret, however, unknown to them, that shared secret is zero, so Mallory can do the following:

Trivial key derivation: If Alice and Bob then proceed to derived a symmetric encryption key (e.g. AES) hashing they shared secret (e.g. SHA-256(sharedSecret), they will both compute SHA-256(0) )
Mallory's advantage: Since Mallory also knows the shared secret 0, he can also independently compute the exact same SHA-256(0) symmetric key.
Complete compromise: Any further communication encrypted by Alice and Bob's using this derived key can be trivially decrypted so he then can read and potentially also modify and encrypt again the message.

This complete failure on confidentiality and integrity in this variant of the MitM attack is also the effect of having no authentication on the Diffie Hellman key exchange protocol.

MitM attack to the DH key exchange protocol implementation:

In this section is is presented a practical implementation of the MitM attack to the DH key exchange protocol, in this example the public parameters p and g are picked from the MODP groups present in the RFC3526 [2], each party also generates a nonce for each session created.

Mallory in this example is replacing the URL of the real server.

The class diagram of this solution is present at figure 1:

The communication between the client and the server is done via HTTP requests and it is the client that has the initiative on this protocol.

The server exposes three endpoints:

one to execute the DH key exchange protocol via the POST /keyExchange.
one to retrieve all the session keys created on the server side via the GET /sessionsData.
one to perform a secure message exchange with a client after the DH key exchange protocol has been completed via the GET /messageExchange.

Next follows a quick demo of this attack, video 1, with the client on the left screen, Mallory's fake server in the middle screen and real server on the right. The client will try to perform the POST /keyExchange first, and as it succeeds, it will latter also perform the GET /messageExchange message, both communications will pass the client verification's, so he remains oblivious of the actions of Mallory the whole time.

All the requests from the client are relayed by the fake Mallory server to the real server, in spite of that, there is no error being triggered by the real server as is possible to see on this demo.

In figure 3 it is possible to observe the output of the GET /sessionsData after the client has done the requests, both the Mallory's fake server and the real server have the same session id and client id on their databases but the other session's data such as nonce's and derived symmetric key's are different as the communication's channel session data are entirely different between those two sessions.

How to protect against a MitM attack against the DH key exchange protocol

The most common and effective way to authenticate public keys in a Diffie Hellman key exchange is through the use of digital signatures, often supported by a Public Key Infrastructure (PKI) and X.509 certificates.

X.509 certificates can contain the following main information:

public key associated with the entity that is trying to authenticate, Alice or Bob in this case.
Details about the entity, namely a domain name for a website or a user's name for a person.
Serial number: an unique identifier to identify the certificate.
Signature Algorithm: Indicates the cryptographic algorithm used to sign the certificate.
Validity period: defines the start and end dates during witch the certificate is considered valid.

With this update in the protocol, here is the how the DH key exchange would look like:

Introduction to a Trusted Certificate Authority (CA): Before the communication starts, Alice and Bob obtain a digital certificate from the CA, this certificate binds the public key to an identity (e.g. a domain name or a person). The CA digitally sign this certificate, ensuring the identity's ownership of the public key.

Built of the certificate:
- Subject's info
- Subject's public key
- Validity dates
- Extensions info
- Issuer info
Hashes the to be signed data (TBS)
Example: digest = SHA-256(TBS_data)

Signs the hash using the CA private key:
Signature = EncryptCA(digest, privateKeyCA)

Attaches the signature to the certificate:
the full certificate X.509 now has the following fields:
- To be signed data
- Signature algorithm (e.g.: SHA-256)
- Signature
Alice and Bob exchange certificates and their DH public keys:
- When Alice initiates the connection, she sends her Diffie Hellman public key (A = g^a (mod p)) along with her digital certificate.
- When Bob responds, he sends his Diffie Hellman public key (B = g^b (mod p)) along with his digital certificate.
Verification of identities and public keys:
- Receives the certificate (e.g. during TLS handshake) with the information about the other party involved.
- Extracts from the certificate the signature and the to be signed data.
- Recomputes the hash with the public key received with the signature algorithm, as an example: digest = SHA-256(to_be_signed_data)
- Decrypts de received signature using the CA's public key: decryptedDigest = decryptCA(signature, publicKeyCA)
- Compares the two digests: if digest == decryptedDigest: -> Certificate is valid and authentic, the public key is verified else: -> Certificate is invalid or tampered

This works because only the CA knows its private key, so only CA could have produced a valid signature. In the same manner, anyone with the CA's public key can verify that the certificate hasn't been forged and/or altered by some attacker.

In a real world scenario, such as TLS (HTTPS) the server sends the certificate to the client's browser, the client's browser then verifies the validity of the certificate received using for that matter the trusted CA root public key. [3]

If the certificate is verified, the client's browser trust the server's identity and public key, allowing the Diffie Hellman secure key exchange to proceed - Diffie Hellman with authentication.

References:

[1] Sousa, T. (2024, April 23). Diffie-Hellman Key Exchange Protocol. Available at LinkedIn: https://www.linkedin.com/pulse/diffie-hellman-key-exchange-protocol-tiago-sousa-tlgpf

[2] D. Kivinen and H. Krawczyk, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)," IETF RFC 3526, May 2003. Available at: https://datatracker.ietf.org/doc/html/rfc3526.

[3] Rescorla, E. The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446, IETF, August 2018. Available at: https://datatracker.ietf.org/doc/html/rfc8446