b2KIT

ECDH Key Exchange Simulator

Simulate Elliptic Curve Diffie-Hellman key exchange between two parties. Visualize the shared secret derivation process.

Tested tool guide Tested browser tools Checked August 16, 2026

What ECDH Key Exchange Simulator does and how it behaves

Follow an Elliptic Curve Diffie-Hellman exchange from each party's private value to its public key and then to the shared result. The simulator visualizes the two scalar-multiplication paths so you can see why Alice and Bob arrive at the same elliptic-curve value without sending their private values. The calculation runs entirely in the browser, so entered private material is not uploaded. The important surprise is that the displayed shared result is normally an intermediate secret, not a ready-to-use encryption key.

How the result is produced

1

Two matching calculations

For a curve with base point G, Alice's private scalar a produces public point A = aG, while Bob's private scalar b produces B = bG. Alice combines a with B, and Bob combines b with A. Both paths reach the same point because aB = a(bG) = b(aG) = bA.

2

Public exchange and private inputs

The visualization separates values that may be exchanged, such as public keys, from the private scalars that must remain secret. It then shows each participant deriving the common result using one private value and the other participant's public value. Both participants must use compatible curve parameters and valid public keys for the derivations to agree safely.

Good uses

  • Demonstrating in a cryptography lesson why two different private values can produce one matching shared result.
  • Tracing which ECDH values are public, which remain private, and which are derived independently by both parties.
  • Checking a hand-worked explanation of the relationships A = aG, B = bG, and aB = bA.

Limits and checks

  • ECDH creates a shared secret but does not authenticate either participant. A real protocol must prevent an attacker from substituting public keys.
  • Do not assume that a displayed point, coordinate, or encoded byte string is directly suitable as an encryption key. Protocols normally process ECDH output with a specified key-derivation procedure.
  • Equivalent values can look different when coordinate formats, byte order, leading zeros, or point encodings differ. Compare results only after confirming the same curve and representation.

Common questions

Why do Alice and Bob calculate the same shared secret?

Alice multiplies Bob's public point bG by her private scalar a, producing abG. Bob multiplies Alice's public point aG by his private scalar b, also producing abG. The private scalars remain different and are never recovered from this equality; only the resulting shared elliptic-curve value matches.

Can I use the simulator's shared result directly as an AES key?

No, not merely because its length appears suitable. Raw ECDH output is generally passed through the key-derivation procedure defined by the surrounding protocol, often with context that binds the resulting keys to the session and their purposes. The simulator illustrates agreement, but its displayed result alone does not define a complete authenticated encryption protocol.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools