The previous lesson ended with a dead end: a physiotherapist's mobile app and the Nimbus API need a common symmetric key, but the only channel they have between them is exactly the one they want to protect. For four thousand years that problem had no solution; in the 1970s it was solved with an idea that sounds impossible the first time you hear it: use two different keys, one that is published and one that is never shared. This lesson develops that idea — the key pair, RSA, elliptic curve cryptography, the Diffie-Hellman exchange and forward secrecy, the hybrid encryption that explains how TLS really works, and the digital signature, the only primitive that gives non-repudiation. It matters because practically everything that makes the modern web secure, from HTTPS to passkeys and the signature on the Nimbus JWT, is asymmetric cryptography.

1. The idea of the key pair
2. What you do with the public key and what with the private key
3. RSA: the hard problem of factoring
4. Elliptic curve cryptography: the same security with much shorter keys
5. Diffie-Hellman key exchange
6. Ephemeral, ECDHE and forward secrecy
7. Hybrid encryption: how it is really used
8. Digital signature: what it guarantees and how it differs from a MAC
9. Signing a Nimbus booking receipt with Ed25519
10. Inspecting an RSA pair with openssl
11. The question that remains open and the quantum threat

In an asymmetric scheme, two mathematically related keys are generated:

• The public key: it can be published on a website, printed on a T-shirt or sent by unencrypted e-mail. Its circulation compromises nothing.
• The private key: it never leaves the system that generated it. Ideally it is not even exportable, as happens with the FIDO2 passkeys of 02-05.

The relationship between the two is a trapdoor: it is easy to compute the public key from the private one, and computationally infeasible to go the other way. All of asymmetric cryptography rests on mathematical problems with that asymmetry — multiplying two large primes is trivial, factoring the product is not.

This solves distribution at a stroke: to receive encrypted messages it is enough to publish the public key. And the number of keys stops growing quadratically: n participants need n pairs, not n(n-1)/2 shared keys. With 10,000 users, 10,000 pairs instead of fifty million keys.

This is the table people most often misremember, and getting it wrong inverts the guarantees completely:

The mnemonic: the private key is the one that "closes" your identity and "opens" your messages. You sign with what only you have; you decrypt with what only you have.

The usual mistake is to invert it, and the consequences differ in each direction:

• "We encrypt with the private key so that only our people can read it." False and dangerous: what is encrypted with the private key is decrypted by anybody with the public one, because the public key is public. That is not encrypting, it is — conceptually — signing.
• "We sign with the public key." Impossible: if anybody can sign, the signature proves nothing.

An important consequence for the design of Nimbus: in a system with thousands of customers, encrypting with a public key is not the usual thing; the usual thing is to agree a symmetric key using asymmetric cryptography and encrypt the data with it (section 7). Direct asymmetric encryption is reserved for very small data, such as a key.

RSA (Rivest, Shamir and Adleman, 1977) was the first practical asymmetric scheme and is still ubiquitous, especially in certificates and token signatures.

The intuition behind the hard problem. Multiplying two large primes is instantaneous:

The reverse — given n, find p and q — is easy with small numbers and becomes infeasible when n has 2048 or 3072 bits (more than 600 decimal digits). The public key contains n; the private one depends on knowing p and q. The security of RSA is exactly the difficulty of factoring.

Three things you have to know about RSA in order to use it well:

1. It is slow, above all the operation with the private key (signing or decrypting). Remember the performance table in 03-02: about a thousand operations per second against gigabytes per second for AES.
2. It cannot encrypt large data. With RSA-2048 the physical limit is the size of the modulus, and with the mandatory padding some 190 usable bytes remain. It is not a practical limitation you can get around with more keys: it is structural.
3. The padding matters as much as the algorithm. The old PKCS#1 v1.5 scheme has known attacks. Today you use OAEP for encryption and PSS for signatures. Serious libraries force you to choose it explicitly; never copy code that uses PKCS1v15 for new encryption.

Elliptic curve cryptography (ECC) rests on a different hard problem: the discrete logarithm over the points of an elliptic curve. Its great practical advantage is efficiency.

Read the highlighted row carefully: a 256-bit ECC key offers the same security as a 3072-bit RSA key. That means much smaller keys and signatures, faster handshakes and lower power consumption, which matters especially in the Nimbus mobile app and in any battery-powered device.

Curves you will see in practice:

Ed25519 and X25519 are the recommended default pair for new code. Not because they are "more mathematical", but because their design removes most of the decisions where a developer could go wrong: there is no padding to choose, no curves to validate by hand, and the signature algorithm is deterministic, which avoids the historical failure of ECDSA signatures with faulty randomness (the same kind of failure we saw in 03-01 with the Android generator).

A warning about naming, because it causes constant confusion: X25519 is for exchanging keys, Ed25519 is for signing. They are related curves but not interchangeable, and the libraries will not let you mix them.

This is the mechanism that solves the problem 03-02 closed with. Diffie-Hellman allows two parties who have never met to agree a shared secret talking over a channel the attacker listens to in full, without the attacker being able to deduce the secret.

1. Ana and the API publicly agree a base colour, say yellow. The attacker sees it.
2. Ana secretly picks a colour of her own, red, and mixes it with the yellow: she gets orange, and sends it. The attacker sees the orange.
3. The API secretly picks blue, mixes it with yellow and gets green, which it sends. The attacker sees the green.
4. Ana mixes the green she received with her secret red. The API mixes the orange it received with its secret blue. Both get the same brown.
5. The attacker has yellow, orange and green, and cannot obtain the brown, because separating a paint mixture into its components is far harder than mixing it.

That difficulty of "separating the mixture" is, in the real mathematics, the discrete logarithm problem.

Two fundamental clarifications:

• The shared secret is not used directly as a key. It is passed through a derivation function (HKDF, from 03-02) to obtain encryption keys with the correct format and domain separation.
• Diffie-Hellman on its own does not authenticate. An active attacker can run an exchange with each end and sit in the middle: it is the classic MITM of 02-02. The solution is to authenticate the exchange with a digital signature backed by a certificate — and that is where the module links to TLS (03-05) and to PKI (03-06).

In TLS you will see the acronym ECDHE: Elliptic Curve Diffie-Hellman Ephemeral. The key word is the last one.

• Static: the parties always use the same key pair for the exchange.
• Ephemeral: a new pair is generated for every session and destroyed when it ends.

From this comes the most valuable property in modern cryptography:

Forward secrecy (also called perfect forward secrecy): compromising the server's long-lived private key does not allow past sessions to be decrypted.

It is worth grounding this in Nimbus with a concrete scenario:

1. An attacker records all the encrypted traffic between the mobile apps and the API for months. They cannot read anything. They keep it anyway.
2. Two years later, they obtain the private key of the Nimbus server — through an intrusion, a badly wiped backup or a court order in another jurisdiction.

This is why TLS 1.3 removed from the standard every mode without forward secrecy and why RSA key exchange is forbidden in modern configurations (03-05). And it is also the direct answer to the "harvest now, decrypt later" scenario of section 11.

We now have the two pieces and their crossed limitations:

• Asymmetric cryptography solves distribution but is slow and cannot handle large data.
• Symmetric cryptography is extremely fast but cannot distribute its own key.

The solution is to combine them, and it is called hybrid encryption. It is the pattern behind TLS, PGP, cloud envelope encryption and almost everything else:

Why this is the correct answer and not a workaround:

• 190 bytes are encrypted with the asymmetric part instead of 3 MB. The cost of the slow part is constant and negligible.
• The message size stops having a limit.
• If ECDHE is used in step 3 instead of encrypting the key, you also get forward secrecy.

This same pattern, applied to storage instead of to communication, is called envelope encryption: a data key encrypts the object and a master key in the KMS encrypts the data key. It is how Nimbus encrypts the attachments in the A-05 bucket, and it is developed in 03-06 and 03-07.

Signing is not encrypting. A digital signature hides nothing: the message travels readable and the signature is attached. What it contributes is proof of origin.

The real flow — and it is important, because it explains why signing a 4 GB file is fast:

It is not the message that is signed: it is its hash. That is why the cost of signing does not depend on the size of the file, and why a broken hash function (MD5, SHA-1) breaks the signature too: if the attacker finds two documents with the same hash, a valid signature for one is valid for the other. Hashes are studied in 03-04.

The decisive difference is non-repudiation. If Nimbus and the gateway share an HMAC key, a webhook with a valid MAC proves that one of the two generated it, and since Nimbus also has the key, it is no good as proof before a third party: Nimbus could have fabricated it. With a signature, on the other hand, only the gateway's private key can produce it, and Nimbus does not have it; that is why a signature is proof.

The practical rule: use a MAC when the two parties know each other, share a secret and only need to detect tampering; use a signature when the verifier could be anybody or when you need evidence that stands up against the other party.

Nimbus wants to issue verifiable booking receipts: the clinic must be able to check, months later, that the receipt was issued by Nimbus and has not been altered.

Output:

What you need to grasp from this code:

• The public key in PEM takes three lines. Compare it with an RSA-3072 public key, which takes about fifteen. That is the ECC size advantage from section 4.
• Canonical serialisation is indispensable. sort_keys=True fixes the order of the keys and separators=(",", ":") removes the spaces. Without this, two serialisations of the same object would produce different bytes and the signature would fail for a reason that is not an attack. It is integration failure number one with signatures over JSON.
• private_key.sign(message) does the hashing internally. Ed25519 uses SHA-512 under the bonnet; you do not touch that part, and that is precisely the point.
• verify does not return True/False: it raises InvalidSignature. It is a deliberate design, so that it is impossible to ignore the result by accident with a badly written if. Never catch that exception without acting on it.
• Changing the amount invalidates the signature. A single modified field and verification fails: that is integrity and authenticity together.
• The receipt carries patient_ref, not the name. A signed document is hard to withdraw from the world and tends to end up filed away for years. Minimise the personal data it contains (02-04; the legal framework, in 06-03).

Professional validation note. If a signed receipt is going to be used as evidence with legal or tax effect in Spain, the cryptographic signature is a necessary but not sufficient condition: the electronic signature and electronic invoicing rules impose additional requirements on the certificate, the provider and the retention. Validate the design with legal advice before giving it evidential weight; the regulatory aspects are covered in module 6.

Even though the recommendation for new code is ECC, RSA is still in most certificates and in many JWT issuers, so you have to know how to handle it.

Output of step 3 (trimmed):

Output of step 4:

How to read these results:

• The modulus is the n = p*q from section 3, here 3072 bits (384 bytes). It is public. The factors p and q are only in the private key.
• The public exponent 65537 is the standard value: prime, small and with few bits set to one, which makes the public operation fast. Seeing something different is a warning sign.
• 2484 bytes against 119. The same table from section 4, made visible in the file system.
• chmod 600 is not decorative. A private key readable by every user on the system is a common audit finding, and it will come up again in 03-06 and in 05-06.
• Never use -des3 or weak passwords to protect the private key. If it needs encryption at rest, use modern encryption; and if it is a service key, the right answer is for it to live in a secrets manager or an HSM, not in a file (03-06).

The whole lesson has rested on an assumption we have not yet justified. Look again at the exchange in section 5: the mobile app receives a public key over the network and uses it to agree the secret. How does it know that key belongs to Nimbus and not to an attacker sitting in the middle?

If there is no way to check, the MITM works perfectly: the attacker runs an exchange with the app while pretending to be Nimbus and another with Nimbus while pretending to be the app, and decrypts and re-encrypts everything that goes past. Both ends would have impeccable encryption with the wrong person.

Asymmetric cryptography moves the problem, it does not eliminate it. You no longer have to distribute secrets, but you do have to authenticate public keys. That is the problem digital certificates and public key infrastructure solve, and it is the subject of 03-06. The specific way TLS applies it on every connection is covered in 03-05.

A sufficiently large quantum computer could run Shor's algorithm, which breaks RSA, Diffie-Hellman and elliptic curve cryptography all at once. It does not weaken them: it solves them. No such machine exists today, and public estimates talk of years or decades, but that does not make the subject irrelevant today:

Why it matters already: "harvest now, decrypt later". A well-resourced adversary can record encrypted traffic today that they cannot read, store it, and decrypt it once they have the machine. If the data is still sensitive fifteen years from now, the problem belongs to today.

For Nimbus, in practice: appointment data loses its value fairly quickly, so it is not a priority for this year. What is sensible is to (1) use forward secrecy always, which already limits the damage of scenarios of this kind; (2) keep the TLS software up to date, because browsers and libraries are switching on post-quantum hybrid modes (X25519 combined with ML-KEM) transparently; and (3) keep an inventory of where each algorithm is used, which is what will make the migration cheap when the time comes. That cryptographic agility — being able to change algorithm without rewriting the system — is the practical conclusion of the section, and it connects with the version byte we introduced in the encryption format of 03-02.

Conceptual mistakes

1. Inverting the use of the keys. You encrypt with the recipient's public key and sign with your own private key. "Encrypting with the private key" protects nothing.
2. Believing that a signature encrypts. A signature does not hide the content; it vouches for it. If confidentiality is also needed, you have to encrypt separately.
3. Confusing a MAC with a signature. Only the signature gives non-repudiation. If the verifier could be anybody, you need a signature.
4. Thinking ECC is "less secure" because it has shorter keys. P-256 is equivalent to RSA-3072. Length is not comparable between families.
5. Assuming that a public key received over the network belongs to whoever it claims. It does not, until something certifies it (03-06).

Implementation mistakes

6. Encrypting large data with RSA. It does not fit, and it is extremely slow. Use hybrid encryption.
7. Using PKCS#1 v1.5 in new code. OAEP for encryption, PSS for signatures; or simply Ed25519, which does not let you choose badly.
8. Signing JSON without canonical serialisation. A space or a reordering of fields breaks verification and produces incidents that look like attacks.
9. Generating keys with random or on devices without good entropy. It is the lesson of 03-01, and in ECDSA signatures it is lethal.
10. Leaving the private key in a world-readable file, in the repository or in the container image. The problem of 03-06.
11. Ignoring the result of verify. If it does not raise an exception it is valid; if it does, the message is discarded and the event is logged. Never "carry on just in case".

Tips

• For new code: Ed25519 for signing, X25519 for exchanging. If interoperability forces RSA on you, use 3072 bits with OAEP/PSS.
• Always store a key identifier (kid) alongside the signature. Without it, rotating the key forces you to stop the service; with it, rotation is transparent. It is exactly what the JWKS of 02-05 did and it is developed in 03-06.
• Publish your public keys over a channel the client can verify, and plan from the outset how you are going to rotate them.
• Note in your technical inventory which algorithm each component uses. On the day of the post-quantum migration, that document will be the difference between a project and a crisis.

For each Nimbus requirement, state: which primitive you would use (symmetric encryption, asymmetric encryption, key exchange, signature or MAC), with which specific algorithm, which key each party uses and why you rule out the alternatives.

1. The mobile app and the API must agree a session key without ever having met.
2. Nimbus must prove before a court, two years later, that a receipt was issued by its system.
3. The API must check that a webhook comes from the payment gateway, with which it shares a configured secret.
4. Nimbus wants to send the decryption key for a backup to the consultancy (A-19) for a one-off restore.
5. The updates to the agent Nimbus installs on some customers' servers must be verifiable by the customer.
6. An 18 MB attachment must be stored encrypted in the A-05 bucket.

Marta has read in an audit that "the server does not offer forward secrecy" and asks whether that means the traffic is unencrypted.

You are asked to: (a) answer Marta in two paragraphs without formulas; (b) describe the concrete damage scenario at Nimbus if the server's private key were to leak within three years, with and without forward secrecy; (c) explain which specific configuration guarantees it and why TLS 1.3 solves it by design; (d) relate this to the risk of "harvest now, decrypt later".

A developer proposes this design for the receipts:

You are asked to: (a) identify the problems in the three marked lines; (b) state which security property the author believes he is achieving and which one he actually achieves; (c) explain why this design does not work for the requirement that the clinic verify the receipt on its own; (d) propose the correct design and justify the primitive chosen.

Exercise 1

Exercise 2

(a) Answer to Marta. No: the traffic is encrypted just the same and nobody can read it today. "Forward secrecy" refers to something else — to what would happen in the future if somebody obtained the server's private key. Without forward secrecy, that key would allow every old conversation somebody had recorded to be decrypted retroactively; with it, each session uses an ephemeral secret that is destroyed when it ends, so the past is protected forever.

Put another way: without forward secrecy, the server key is a master key that also opens the historical archive; with forward secrecy, it opens only the doors from today onwards. That is why the audit flags it even though there is no visible problem right now.

(b) Scenario. An attacker records the mobile apps' traffic for eighteen months. Without forward secrecy, on obtaining the private key three years from now they decrypt all eighteen months: clinic diaries, e-mail addresses, telephone numbers and information that indirectly reveals health data. With forward secrecy, they do not decrypt a single session; they could only impersonate the server from that moment on, which is cut off by revoking the certificate and rotating the key (03-06).

(c) Configuration. Allow only suites with ECDHE and disable static RSA key exchange; in practice, require TLS 1.3 — which removed every mode without forward secrecy from the standard — and keep TLS 1.2 only with ECDHE suites while there are old clients. The configuration detail is in 03-05.

(d) Relation to "harvest now, decrypt later". It is the same pattern — record today, decrypt tomorrow — with a different enabler: there the stolen key, here a future quantum computer. Forward secrecy does not protect against the quantum threat on its own (the ephemeral exchange is itself vulnerable to Shor), but it eliminates the most likely and cheapest scenario, and it fits the same response: ephemeral keys, upgradable algorithms and an inventory of where each one is used.

Exercise 3

(a) Problems:

1. str(receipt) — non-canonical serialisation: it depends on the dictionary's insertion order and on Python's repr. The same receipt can produce different strings and failed verifications with no attack at all. It is also not interoperable with any other language.
2. sha256(SECRET_KEY + text) — this is the prefix-MAC construction, vulnerable to the length extension attack on SHA-2 style functions: an attacker can append data to the message and compute a valid signature without knowing the key. That is what HMAC exists for, and it is studied in 03-04. And the key, on top of that, is in the code and is a guessable string.
3. == — a comparison of secrets that is not constant-time: it opens a timing side channel (03-01). hmac.compare_digest must be used.

(b) The author believes he is achieving a signature with non-repudiation. At best he achieves a badly constructed MAC: fragile integrity and authenticity between parties that share the secret, without non-repudiation, and with the key within reach of anybody with access to the repository.

(c) Why it does not work. For the clinic to verify on its own, it would need SECRET_KEY. And as soon as it has it, it can fabricate receipts indistinguishable from Nimbus's. A shared-key scheme cannot provide public verification: that is the structural difference between a MAC and a signature.

(d) Correct design. An Ed25519 signature with Nimbus's private key held in the secrets manager or KMS, over a canonical serialisation (json.dumps(..., sort_keys=True, separators=(",", ":"))), including in the receipt itself a key identifier (kid) and the issue date, and publishing the public key at a verifiable endpoint. That way any clinic verifies without being able to forge, key rotation is possible thanks to the kid, and the receipt has technical evidential value — with the legal validation noted in section 9.

You have seen the idea that solved the problem the previous lesson closed with. A key pair related by a trapdoor function — easy in one direction, infeasible in the other — allows one half to be published without losing anything, and with that the need to distribute prior secrets disappears. You have the most-confused table nailed down: you encrypt with the public key and decrypt with the private one; you sign with the private key and verify with the public one. You know RSA and its hard problem, its current sizes — 2048 as a minimum, 3072 as the recommendation — and its two structural limits, slowness and the impossibility of encrypting large data; and you know elliptic curve cryptography, where 256 bits are equivalent to 3072 of RSA, with Ed25519 for signing and X25519 for exchanging as the default recommendation for new code.

You have understood Diffie-Hellman through the paint analogy and its ephemeral version, ECDHE, from which comes the most valuable property of the lot: forward secrecy, which means that stealing the server's private key three years from now does not allow anything recorded up to today to be read. You have seen hybrid encryption — a symmetric key for the data, asymmetric cryptography only to protect that key — which is the real pattern behind TLS and behind the envelope encryption of Nimbus's attachments. And you have precisely separated signature and MAC: both give integrity and authenticity, but only the signature gives non-repudiation, because the verifier cannot fabricate it. You have practised it by signing a booking receipt with Ed25519 in 64 bytes, checking that altering the amount invalidates the signature, and learning the detail that breaks most real integrations: canonical serialisation.

But the lesson ends with the same honesty as the previous one. Asymmetric cryptography does not eliminate the trust problem: it moves it. You no longer have to distribute secrets, but there is still a question to be answered, without which everything above collapses in the face of an attacker in the middle: this public key I have just received — does it really belong to Nimbus?

In Hash Functions, HMAC and Password Storage (03-04) we take a step back to the primitive that has already come up twice without explanation — the hash that is signed instead of the message — and we study it in depth: what properties it has, why MD5 and SHA-1 are broken, how an HMAC is correctly built to validate the payment gateway webhook, and, at last, how Nimbus should store its users' passwords with Argon2id, salt and calibrated parameters. The answer to the public key question will have to wait for 03-06.