Harvest now, decrypt later

Someone is recording your HTTPS traffic. They can't read it. They're storing it anyway.

That's the whole threat, and notice what it doesn't require: a working quantum computer. It requires cheap disks and patience. Capture the ciphertext today, keep it and decrypt it on the day a machine exists that can. The attack is named after that shape: harvest now, decrypt later.

That's why this is a present-tense problem. The machine isn't here. The recording is.

The one paragraph of physics

Public-key cryptography rests on problems that are cheap in one direction and brutal in the other. Multiplying two large primes is instant; factoring the product back isn't. Multiplying a point on an elliptic curve by a scalar is instant; recovering the scalar isn't. A classical computer attacking a 2048-bit RSA key runs out of universe before it runs out of candidates. A large enough quantum computer, running an algorithm Peter Shor published in 1994, turns both problems into work that finishes. That's all the physics this course needs. How the machine gets there is a fascinating subject, and it isn't yours. Which of your data it reads when it arrives is very much yours.

Three numbers

The useful question isn't "when does the machine arrive?" It's a sum and a comparison, and you can do it today with numbers you already know. It's often called Mosca's inequality, after the researcher who framed it.

Take how long a piece of data must stay secret. Take how long your migration will take. Add them. If the sum lands past the day a capable machine exists, that data is already exposed, because the recording is happening now and nobody can un-record it.

The first number is the one teams never write down.

Read that table as a risk ranking and the panic drains out of the subject. A session cookie captured today is worthless to an attacker in 2040, because the session ended before lunch. A stored identity document with a thirty-year confidentiality requirement is a different matter. If it was encrypted with a key exchanged over a channel someone recorded, it's exposed.

Most of what a web application transmits has a short life. Some of it doesn't. The migration is about the second pile.

The reflex this course is here to correct

Ask a Rails team whether they're exposed and you get one of two answers, both wrong in the same way.

"We use encryption, so we're broken" is too broad. "We hash passwords with BCrypt, so we're fine" is too narrow. It answers a question nobody asked, because password hashing isn't the thing under threat.

The truth sits in between, and it's specific enough to act on. Lesson 2 draws the line: public-key cryptography is the casualty, while symmetric encryption and hashing survive with bigger parameters. Lesson 4 walks this application and says which of its parts fall on which side. The answer for this codebase is narrower than most engineers expect, and knowing why is worth more than any algorithm name.

A note on what this is

This is engineering guidance. It isn't security advice for your particular system, and it isn't legal or compliance advice. Regulated data, contractual obligations and national requirements all vary. They move faster than a course does, and people with a mandate decide them. Take the shape of the argument from here; take the deadlines from your own counsel and your own regulator.

What this course covers

Lesson 2 separates what breaks from what survives. It's the most load-bearing distinction in the subject and the one most often gotten wrong.

Lesson 3 covers the standards. It names the algorithms that were selected and the numbers they were published under, says what's still in draft and shows how to check the state of that list instead of trusting a course written months ago.

Lesson 4 walks a Rails application and marks the exposure honestly: the part your proxy owns, the part your platform owns and the small part your own code owns.

Lesson 5 is the real deliverable: crypto-agility. You'll migrate more than once, so the system has to change algorithm without a rewrite.

Lesson 6 is timelines and posture, including what deliberate inaction looks like and where it stops being deliberate.

Lesson 7 puts it together into a plan you could take to a review without overclaiming.

Start with the line between broken and merely bruised, because every decision after it depends on where that line falls.