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".

You were the first to finish set 7.

I assume most people don't know, so: Filippo was one of our earliest adopters of cryptopals. He is a monster. He demolished everything we put in front of him.

You should watch Filippo run set 8. I've read a bunch of his code via cryptopals, and I'm a better programmer because of it. I'm very excited to watch him work in realtime.

Our goal was to be accessible. If we were unsuccessful, we're happy to help fill the gaps. My email is [email protected].

I'm an author. My personal mail is [email protected]. I'm happy to help you get unblocked.

Quick plug: set 8 is out. It's all about attacks on elliptic curves and GCM.

This set is huge. There's as much content as in any two or three other sets.

This set is tough. It's easily the toughest set so far. And there is some math. But it's fascinating stuff and (I hope) pretty approachable.

This set is OG cryptopals. That means we're (for now) distributing it via email. If you want to check it out, send a mail to [email protected] with subject "Crazy Flamboyant for the Rap Enjoyment".

You are talking about quantum attacks, whereas tptacek is talking about classical attacks.

I don't think their bound is related to nonce-management issues. From the documentation:

> The GCM security limit is 2^56 bytes because:

> This is 2^52 AES blocks (each block is 16 bytes). The limit is based on the risk of birthday collisions being used to rule out plaintext guesses. The probability an attacker could rule out a random guess on a 2^56 byte plaintext is less than 1 in 1 million (roughly (2^52 * 2^52) / 2^128).

Where are you getting that number?

I think the free version of Burp Suite will handle all of this for you.

Not specifying the group/generator is a weak link, which is what David is taking advantage of. Curve25519 is a good counterexample of a DH function that leaves nothing to the imagination.

Yes, the posited attacker is an unprivileged spy process sharing a cache with the victim. The FLUSH+RELOAD cache-timing algorithm they use relies on a shared cache. See section 2.2.

Of course, there may be other ways to extract the same data remotely. Bernstein's earlier paper[1] demonstrating cache-timing attacks on AES over the network is an example. He sent many packets of different sizes to evict different lines from cache. Compared to FLUSH+RELOAD, Bernstein's technique is extremely low-resolution; I don't believe anyone has ever demonstrated it against a typical, real-world server configuration.

[1] https://cr.yp.to/antiforgery/cachetiming-20050414.pdf

I'm not familiar with all the details, but don't you just have an absence of proof that it's X?

If messages come from one known-good source (e.g. firmware updates), a digital signature is a valid message authenticator. Where this falls down is in multi-user settings (e.g. iMessage), where secret-key authentication via MAC becomes a necessity.

I'd still recommend always to use an authenticated cipher, since the above distinction can be very fine.

Some examples detailing the dangers of HTML corruption: http://lcamtuf.coredump.cx/postxss/.

> I mean, I'm not trying to be a conspiracy theorist, but certainly similar things have happened.

Could you list some?