sdevlin

> We talked English professors through the "number-theoretic" attacks on RSA in cryptopals set 6.

The English professor finished set 8 as well!

> Using "one-time-use combinations of three English words" is "fine" only if your definition of "fine" includes allowing someone with a minimal budget to find out the password in less than a year.

Magic Wormhole uses a PAKE to establish a secure channel from a low-entropy shared secret.

Emacs Lisp is most certainly not a Scheme.

Probably `M-x eww`.

They're not reading data out of the cache line. Often the contents of the cache are public anyway.

What they're detecting is whether a piece of memory is in the cache or not. This lets them infer the contents of some other piece of memory.

For example, an if-statement might check whether or not a secret bit is set, and that might lead the process to call function A or function B. By detecting whether it's A or B that lands in the instruction cache, you can infer the value of the secret bit.

These are great details, but they don't really answer my question.

You do have the choice. You don't need session tickets at all to run TLS. The cost of geographically-distinct STEKs would simply be an additional handshake if the client hops regions. (Is this common?)

This is a choice Cloud Flare is making in favor of performance, and it seems sort of risky with respect to a well-funded global adversary. This makes persistent access to any single endpoint server incredibly valuable.

But maybe regional STEKs are impractical from a performance perspective. I assume Cloud Flare has performance measurements to justify this choice. I'd be interested to read a blog post about it.

So it would be correct to say that if any of Cloud Flare's endpoint servers is compromised, the adversary can decrypt traffic passively on a global scale?

What is Cloud Flare's policy for managing STEKs? Are they distinct per geographic region as the article recommends?

I guess it depends what you mean by “crack”. Given f(1), which I assume is public, you can predict all future outputs.

It's impossible to bootstrap a secure connection without some preexisting trusted relationship. Otherwise, you'd always be vulnerable to middle-person attacks.

Browsers solve this problem by bundling a number of trusted root certificates. (This is what they mean by "my trusted keys".)

When you connect to some web site, the server sends you their certificate along with a chain of signing certificates up to some root of trust. Assuming the root certificate is among those your browser trusts, you can verify the signature chain and establish a trusted connection.

It's true that the space of valid RSA keys is sparse relative to size, but this isn't why we need big keys. As a counterexample, classic DH keys are also big (or they can be), even though the space of valid keys is dense.

We need big keys (or rather big fields) due to index calculus. This is a family of algorithms used to factor integers and compute discrete logarithms in finite fields. The fact that index calculus is (thus far) inapplicable to elliptic curve groups is the primary motivation for ECC.

> More specifically, because of the RSA dependency on prime numbers, the RSA effective key space is very sparse (which is why going from 2048-bit RSA to 4096-bit RSA only increases the effective key space by ~16%). With elliptic curves, the key space is very dense, which reduces the key size for an "equivalent" encryption strength.

This isn't correct.

The reason RSA (and classic DH) keys are gigantic is because index calculus techniques yield efficient attacks on systems based on finite fields. We need big keys to make them impractical.

EC systems are not susceptible to these attacks because the points on a curve comprise only a group and not a field. Counterintuitively (to me, at least!), they're safer because they have less structure.

Just read his blog.

ESR is a racist and a misogynist. And that document might as well be called "how to be ESR".