T2 · Cryptography Fundamentals

A Real-World Problem

Logging in to your DApp needs no password.

A user clicks "Connect Wallet," sees a dialog, clicks "Sign," and is logged in. Your backend receives two things: an address and a 132-character hexadecimal string. From those alone, it accepts that the request came from the owner of that address.

A traditional backend would need registration, a stored password hash, a comparison, and a session. None appears here. The server has never met this user and stores no secret about them.

More unsettling, that hexadecimal string is public. It travels in an HTTP request, might land in access logs, could be seen by an intermediary, and might be printed to your console by accident.

Once someone sees it, why can they not impersonate you?

How can characters anyone may copy prove "it was me"?

Thought Experiment

Reduce the problem: in a strange city, you must prove to someone you have never met that "I wrote this note."

Three constraints: you share no secret; you cannot reveal your secret; anyone may see and copy the note.

Version one: agree on a secret code and write it at the end of the note.

The problem is immediate. Once the reader sees the code, they can write an identical note.**The verifier becomes a forger.**This is a structural dead end, not an implementation detail.

Version two: write a one-way scrambled value calculated from the code instead of the code itself.

The reader cannot reverse the value to recover the code. But they do not need to: they can copy the value onto another note. The proof is not bound to the content, so one copy works forever.

Version three: combine the code with the note's contents, then scramble them together.

Now the proof is bound to the content. A different note will not match. But to recalculate it, the verifier must know the code—and we are back to version one.

Either the reader can verify it or they cannot forge it. With this design, you cannot have both.

An ordinary one-way function has reached its limit. To escape, you need something stranger:

A pair of numbers: one generates the proof, the other checks it, and the checking number cannot reveal the generating number.

Make the checking number public, so anyone can verify. Never give anyone the generating number, so nobody else can forge. The dead end is resolved.

Now return to the opening question: the 132-character string is not your secret. It is a one-time result calculated using your secret. Seeing it is useless for other messages, because it is valid only for the message you signed.

Your Decision

The backend must confirm that "this request came from the owner of address A." Which approach do you take?

What Happens

The four approaches expose the same dimensions:

The last row has an ambiguity worth examining: replay protection depends on what you put in the message, not on the cryptography.

A signature remains valid forever. If you sign only the word "login," it may be reused at any time, on any site, and on any chain. To make it single-use and context-specific, put a nonce, domain, chain ID, and expiration time inside the signed content.

Cryptography will not design that content for you. You must.

Build a Model

Three primitives and one composite structure.

**Primitive one: a one-way hash.**It maps input of any length to fixed-length output. Identical input always yields identical output; one changed byte radically changes the result; reversing the result is computationally infeasible.

It serves three purposes: give arbitrary data a stable short name; detect changes; and compress "a lot of data" into "one value."

**Primitive two: a key pair.**A private key is a random number; a public key is derived from it in one direction. Forward calculation is fast, reversal infeasible. An address is in turn derived from a hash of the public key, forming a one-way chain:

**Primitive three: signing and verification.**Signing takes a private key and a message digest and returns a value—on Ethereum, the r, s, and v parts total 65 bytes. Verification takes the message and signature, recovers the signer's public key, and derives the address.

Note the direction: verification is not "decrypting with a public key." It is recovering the public key from the signature. You do not need to know in advance who signed; the verification process tells you. This is why an Ethereum transaction does not need to carry the sender address—it can be calculated.

A complete identity proof looks like this:

Composite structure: compress many items into one value while retaining proof that any individual item belongs.

Suppose a list contains 300,000 addresses, and an on-chain contract must decide whether one address is on it. Writing the full list into the contract would cost far too much.

Hash each of the 300,000 entries to get leaves. Combine and hash neighboring leaves to get 150,000 values. Repeat layer by layer until only one value remains. Store that one value on-chain.

To claim, a user submits their entry and the sibling value at each level on the path from their leaf to the top—only about 19 values for 300,000 entries. The contract recomputes the path. If its top value equals the stored value, it accepts.

In one sentence, the structure proves that one item is in a collection without revealing the entire collection.

It appears everywhere on-chain: block headers commit to transaction lists, airdrops commit to recipient lists, and bridges commit to batches of messages. The shape is the same.

What It Is Called

Hands-on

openssl ecparam -name secp256k1 -genkey -noout -out priv.pem
openssl ec -in priv.pem -pubout -out pub.pem
cat priv.pem pub.pem

printf 'transfer 100 to alice' > msg.txt
openssl dgst -sha256 -sign priv.pem -out sig.bin msg.txt
xxd sig.bin | head

openssl dgst -sha256 -verify pub.pem -signature sig.bin msg.txt

printf 'transfer 100 to blice' > tampered.txt
openssl dgst -sha256 -verify pub.pem -signature sig.bin tampered.txt

AI Lab

Step one:
In my chosen language, write a function to verify a Merkle proof.
Inputs: leaf, proof array, root. Output: true or false.
State your assumptions about the hash function, child order, and distinction between leaves and internal nodes.

Step two:
Now act as an attacker. Given the implementation you just wrote,
construct inputs that make it return true for an item that is not actually in the tree.
If you think this is impossible, identify the exact line that prevents it.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check