ECDSA (Elliptic Curve Digital Signature Algorithm) : Session 7

The closing session tied together concepts from every previous session — hashing, public-key cryptography, and elliptic curves — into a complete digital signature scheme. The group began by defining what a digital signature guarantees:

Authenticity — the message genuinely came from the claimed signer.

Integrity — the message was not altered after signing.

Non-repudiation — the signer cannot later credibly deny having signed the message.

The ECDSA signing process was walked through step by step:

The message is first hashed (directly reusing the hashing concepts from Session 1) to produce a fixed-length digest.

A random (or deterministically generated, per RFC 6979) value k is chosen for the signature.

Using the signer's private key, the elliptic curve point kG (where G is the curve's base point) is computed, and its x-coordinate becomes part of the signature (r).

A second signature component (s) is computed using the message hash, the private key, r, and k.

The signature (r, s) is attached to the message and distributed alongside the signer's public key.

The verification process was then covered:

The verifier hashes the received message using the same hash function.

Using the signer's public key and the signature components (r, s), the verifier performs an elliptic curve computation that should reconstruct a value matching r if and only if the signature is valid and the message hasn't been altered.

A critical security warning was discussed in detail: the random value `k` used during signing must never be reused across two different signatures, and must never be predictable. Reusing k allows an attacker to mathematically solve for the signer's private key — a real-world vulnerability that has previously compromised systems (including a well-documented case affecting a gaming console's signing system). This motivated the discussion of RFC 6979, which defines a way to deterministically derive k from the private key and message, eliminating the risk of weak or reused randomness while still keeping signatures verifiable and unpredictable to outsiders.

Real-world applications were discussed extensively:

Blockchain transactions — ECDSA (using secp256k1) is used to sign nearly all Bitcoin and Ethereum transactions, proving the sender authorized the transfer of funds.

TLS certificates — many modern certificates use ECDSA signatures instead of RSA for smaller certificate sizes and faster handshakes.

Code signing and software authenticity — ensuring software updates and packages genuinely originate from the claimed publisher and haven't been tampered with in transit.

The session closed by connecting ECDSA back to the DID/SSI session earlier in the series — verifiable credentials are typically signed using exactly this kind of signature scheme, closing the loop across the full curriculum.

Outcome :

• Participants can explain the full ECDSA sign-and-verify workflow.
• Understood why digital signatures provide authenticity, integrity, and non-repudiation.
• Learned the critical danger of k-value reuse and how RFC 6979 mitigates it.
• Connected the entire 7-session curriculum into a cohesive, applied understanding of modern cryptography — from hashing and encryption
• through key exchange and secret sharing, to identity systems and digital signatures.