Elliptic Curve Cryptography (ECC) is a family of public-key techniques based on elliptic-curve groups. ECDH key agreement and signatures such as ECDSA have different roles; ECC is not one encryption operation that provides every security property. Alongside the overview of public keys, hashes and signatures, this article explains the mathematical and implementation conditions.
The C++ example is a variable-time mathematical demonstration using public secp256k1 parameters. It does not implement secret-key generation, authenticated key agreement, signatures or constant-time cryptography. We also explain why a ladder structure alone does not establish constant-time behavior.
1. Security and key sizes
Choose a large prime-order subgroup of order \(n\) with generator \(G\). Recovering \(d\) from \(Q=dG\) is the elliptic-curve discrete logarithm problem (ECDLP). The scalar is determined modulo \(n\). A private key is sampled uniformly from \(1\le d<n\) using a cryptographically secure random generator. Distinguish the field size \(p\), subgroup order \(n\) and private-key value.
For a suitable large prime-order subgroup, a generic classical attack such as Pollard rho takes approximately \(O(\sqrt n)\) group operations. This does not mean exhaustive search is the only attack, or that every elliptic curve has the same difficulty. Special curve structures and small subgroups permit other attacks. Parameters and schemes must be selected appropriately.
The following comparison reproduces the estimated maximum security strengths against classical computers in NIST SP 800-57 Part 1 Rev.5, Table 2. The RSA column gives the modulus bit length; the ECC column gives the bit length \(f\) of the base-point order \(n\), not the encoded public-key size.
| Estimated strength (bits) | RSA modulus (bits) | ECC \(f\) (bits) |
|---|---|---|
| At most 80 (historical comparison) | 1024 | 160–223 |
| 112 | 2048 | 224–255 |
| 128 | 3072 | 256–383 |
| 192 | 7680 | 384–511 |
| 256 | 15360 | At least 512 |
The 80-bit row is not a recommendation for a new system. The table does not certify a particular curve, implementation or deployment lifetime, or provide quantum resistance. Shorter parameters can reduce communication costs, but ECC is not necessarily faster than RSA for every operation.
2. Groups and finite fields
A group consists of a set and an operation satisfying closure, associativity, an identity and inverses for every element. A group that also satisfies commutativity is an abelian group. Elliptic-curve points, including the point at infinity and the addition law below, form an abelian group.
For a prime \(p\), represent elements of the prime field \(\mathbb F_p\) by \(0,\ldots,p-1\) and reduce addition, subtraction and multiplication modulo \(p\). Division \(u/v\) is defined as \(uv^{-1}\) only for nonzero \(v\).
\[vv^{-1}\equiv1\pmod p\]An inverse can be computed with the extended Euclidean algorithm or as \(v^{p-2}\bmod p\) using Fermat’s little theorem. Choosing the latter does not make an implementation constant-time. Exponentiation, multiplication, reduction and memory allocation must all be considered.
3. The curve and point at infinity
We restrict this article to the short Weierstrass form over a prime field with \(p>3\). This formula does not uniformly cover characteristic two or three, or Montgomery and Edwards models.
\[y^2\equiv x^3+ax+b\pmod p\]The coefficients are field elements, and nonsingularity requires the following condition in the field:
\[\Delta=-16(4a^3+27b^2)\not\equiv0\pmod p\]This condition alone does not make a curve cryptographically suitable. Add the identity, the point at infinity \(\mathcal O\), to the finite points satisfying the equation.
\[P+\mathcal O=\mathcal O+P=P\]\[-(x,y)=(x,-y\bmod p),\qquad P+(-P)=\mathcal O\]The real-number picture of intersecting a line with a curve and reflecting the intersection gives intuition for the group law. Over a finite field, we calculate with the corresponding algebraic formulas rather than a continuous drawn curve.
4. Addition, doubling and exceptional cases
Let \(P=(x_1,y_1)\) and \(Q=(x_2,y_2)\). First handle addition with \(\mathcal O\) and the case \(Q=-P\). The latter includes doubling when \(P=Q\) and \(y_1=0\); the result is \(\mathcal O\).
When \(x_1\ne x_2\), use:
\[\lambda\equiv(y_2-y_1)(x_2-x_1)^{-1}\pmod p\]When \(P=Q\) and \(y_1\ne0\), use the tangent formula:
\[\lambda\equiv(3x_1^2+a)(2y_1)^{-1}\pmod p\]Once these conditions ensure a nonzero denominator, compute the result with the common formulas:
\[x_3\equiv\lambda^2-x_1-x_2\pmod p\]\[y_3\equiv\lambda(x_1-x_3)-y_1\pmod p\]
graph TD
A["Valid points P, Q on the same curve"] --> B["Handle infinity, inverse and y=0 cases"]
B --> C["Compute slope with a nonzero denominator"]
C --> D["Use addition formulas for R = P + Q"]
Affine coordinates require inversions. Practical implementations can reduce their number with coordinate systems such as Jacobian coordinates. A change of coordinates alone does not establish constant-time behavior or security.
5. Scalar multiplication
For nonnegative \(k\), define \(kP\) by repeated addition, with \(0P=\mathcal O\). Double-and-add processes bits from most significant to least significant: double the accumulator and add \(P\) if the bit is one. It reduces the number of group operations from \(k\) naive additions to \(O(\log k)\). This says nothing about a constant cost per group operation or an absolute running time.
The following conceptual pseudocode is not part of the later C++ program. It branches on secret bits.
| |
A Montgomery-ladder-style update performs one addition and one doubling per bit. If the processed prefix represents \(r\), it can preserve \((R_0,R_1)=(rP,(r+1)P)\). The later example demonstrates this invariant using full affine points; it is not an implementation of RFC 7748’s X25519 or X448.
graph TD
A["R0 = O, R1 = P"] --> B["Process each bit from the most significant"]
B --> C["Swap according to the bit (branching in this demo)"]
C --> D["R1 = R0 + R1, R0 = 2R0"]
D --> E["Swap back according to the same bit"]
E --> B
B -.-> F["All bits processed: R0 = kP"]
6. ECDH: agreement and authentication
Public domain parameters include the curve, field, base point \(G\), its order \(n\) and the cofactor. Each party generates an appropriate private scalar and exchanges public points.
\[Q_A=d_AG,\qquad Q_B=d_BG\]\[S=d_AQ_B=d_BQ_A=(d_Ad_B)G\]
sequenceDiagram
participant A as Alice
participant B as Bob
A->>A: Sample private d_A uniformly from 1..n-1
B->>B: Sample private d_B uniformly from 1..n-1
A->>B: Q_A = d_A G
B->>A: Q_B = d_B G
A->>A: Validate and authenticate peer key, then S = d_A Q_B
B->>B: Validate and authenticate peer key, then S = d_B Q_A
Note over A,B: Derive purpose-specific keys with the scheme's encoding and KDF
Computing the shared value from the public points is the computational Diffie–Hellman problem (CDH), which is not the definition of ECDLP. Solving ECDLP lets an attacker compute the shared value; we do not assume a general equivalence in the reverse direction.
ECDH alone does not authenticate the peer or stop an attacker from substituting public keys. A real protocol binds keys, the exchange and peer identities, and applies its required checks for encoding, coordinate ranges, curve membership, infinity and subgroup conditions. Do not use the shared point or its x-coordinate directly as an AES key: follow the protocol’s encoding, context binding and key derivation, such as HKDF. The diagram is not a complete TLS handshake.
7. What constant-time implementation requires
Secret-dependent branches, memory accesses, exceptional cases and arithmetic timing can leak information under an appropriate observation model. The number of observations and whether a full key can be recovered depend on the implementation and attack. There is no universal guarantee that a few thousand measurements reveal every bit.
An equal number of additions per iteration does not establish constant-time behavior if those additions branch on secret intermediate values. A masked conditional swap is only part of a defense: integer representation, the compiler and target CPU also matter. RFC 7748 §5.1 explains that an identical field-operation sequence does not by itself prevent all side channels.
cpp_int is a variable-size integer type, and both conditionalSwapDemo and point addition below branch. The following code is not constant-time and must not handle secret keys in production cryptography.
8. A C++17 mathematical demonstration
Concatenate the following five C++ blocks in order into one file. Boost.Multiprecision headers are required. The program uses only public fixed parameters and test values; it does not generate, store or print secret keys.
8.1. Prime-field arithmetic
modInverse is specific to the fixed prime \(p\) used here and rejects zero. The Fermat inversion implemented with powerMod is also variable-time.
| |
8.2. Points and addition
A finite point must have coordinates \(0\le x,y<p\) and satisfy the curve equation. Infinity is permitted for group arithmetic but must be rejected separately as a peer ECDH public key. The cofactor of secp256k1 is one; these checks do not replace the subgroup validation needed for arbitrary curves.
| |
8.3. Simulating a swap
This function branches, hence Demo in its name.
| |
8.4. A ladder with input-range checks
The demonstration accepts \(0\le k<2^{256}\) and rejects values outside that range. This differs from the private-key range \(1\le d<n\). It never silently truncates higher bits.
| |
8.5. Checking public values
Use the secp256k1 generator from SEC 2 to check \(2G\) and \(nG=\mathcal O\). This self-check alone is not a proof that a cryptographic implementation is secure.
| |
For example, save the five blocks as ecc_demo.cpp and run them in an environment with the Boost include path configured:
| |
9. Conclusion
Distinguish the field, curve, subgroup and cryptographic scheme. Exceptional addition cases, scalar ranges, public-key validation, peer authentication and key derivation all matter. Correct ladder arithmetic and constant-time implementation are separate verification tasks.
This demonstration is for tracing group arithmetic. Actual key agreement and signatures require maintained, validated libraries supporting the intended protocol and curve.
References
- RFC 6090: Fundamental Elliptic Curve Cryptography Algorithms (§§2–4, 10)
- RFC 7748: Elliptic Curves for Security (§§5–5.1)
- NIST SP 800-57 Part 1 Rev.5 (§5.6.1.1, Table 2)
- Standards for Efficient Cryptography 2 (SEC 2), version 2.0 (§2.4.1, secp256k1)
- RFC 5869: HKDF (§§1, 3.2–3.3)
- Boost.Multiprecision: cpp_int
