> We talked English professors through the "number-theoretic" attacks on RSA in cryptopals set 6.
The English professor finished set 8 as well!
1,326 karma · joined July 6, 2009
The English professor finished set 8 as well!
Magic Wormhole uses a PAKE to establish a secure channel from a low-entropy shared secret.
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.
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.
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.
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.
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.
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.
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 set8.cryptopals@gmail.com with subject "Crazy Flamboyant for the Rap Enjoyment".
> 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).
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.
I'd still recommend always to use an authenticated cipher, since the above distinction can be very fine.
Could you list some?