> 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.
I thought that project is perennially under development, and at this point in time more like good thing to look at than having a real chance of getting merged with master?
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.
Session Tickets at CloudFlare
CloudFlare’s solution to this problem, documented in previous blog posts, is to frequently regenerate and synchronize these session ticket keys across our entire global network. We currently do this once per hour.
This means we need a mechanism for turning over session ticket keys. For instance, if a client instantiates an HTTPS session at 12:00pm and continues using that ticket past 1:00pm, our edge network will re-encrypt the ticket with a brand new session ticket key.
To accomplish this, our web servers must have both the full history of all previous keys that could have encrypted the ticket (i.e., one per hour dating back to the maximum session lifetime of 64,800 seconds) as well as immediate access to each newly generated key. The previous keys are used exclusively to decrypt tickets presented by the client, while the new keys are used to "refresh" the encryption on existing tickets and encrypt tickets for entirely new sessions.
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?
With Anycast I don't think you have the choice of not georeplicating the STEK. And latency is one of their biggest selling points. So you could say they are trying to make the best of a bad situation.
It is absolutely bizarre that the STEK-encrypted session key is not itself sent inside the session encrypted channel.
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.
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.
> 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.
On the question of whether it's intuitive or not: NP-complete problems tend to have fairly little structure. A problem like boolean satisfiability has basically no structure: all you have is a soup of clauses. The "tricky" problems that have solutions in P get their solutions from clever exploitation of structure.
At least, that's how it becomes more intuitive to me.
The structure of a problem specifies it; an unstructured problem is less well-specified, and that makes it intuitively more difficult to approach.
E.g. summation of a column of decimal numbers is a highly structured problem that's very easy to solve. Parsing the speech of yelling drunkards is not so structured, and much harder to solve.
Very informative, thanks for the detailed response. To be clear, was my statement incorrect in terms of the "16%" quotation (from [0], which I now realize I misquoted in my private notes), or in the claim that the RSA key space density is low due to the dependency on prime numbers?
My private notes include a claim (original source uncited, sadly) that because the prime density from 1..n decreases (approximately) as `1/ln(n)`, then the corresponding effective key space density for RSA decreases at a related rate, which was what led to the corresponding reduction in the "equivalent" key size. If my notes on this are complete bunk I'd love to hear it. (Even a simple 'yes' would suffice and I'll revisit the subject.) Ta!
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.
Just read the linked post in full and that's an awfully reductive comment on the experiences he describes there. I suggest taking a more intellectually honest look at that writing (not to defend any of his other writing or views, which I haven't read).
I think we're all pretty sure ESR is not in fact a god, and that nothing could have occurred with ESR or his magic flute to have demonstrated to him that he was. Rather, the story is more broadly illustrative of a pretty extreme narcissism and --- challenging --- variant of self-awareness. For a more down to earth example, consider how many of us would non-ironically write the following passage:
I’m wondering about this because my wife Cathy asked me a simple question last night, and I realized I didn’t have an answer to it. “Are you” she asked “the most famous programmer in the world?”
This was a question which I had, believe it or not, never thought about before. But it’s a reasonable one to ask, given recent evidence – notably, the unexpected success of my Patreon page. This is relevant because Patreon is mainly an arts-funding site – it’s clearly not designed for or by techies.
It goes on in this vein. Here, by the way, is a link to his Patreon page:
Apparently we value "the code that makes our digital world work" a bit less than we value the person who fries our french fries at McDonalds. If that sounds mean, well, it is, but it was also Eric Raymond who put forward the idea that his Patreon page may indicate that he's among the most famous programmers in the world.
For a nerdier take on ESR's merits, hunt down Terry Lambert's take on fetchmail. (You should know who Terry Lambert is, if you don't already).
Not to mention that ESR was, at some point, a multi-millionaire. Pretty sure he still is, in which case that Patreon page of his would be nothing but a con.
The English professor finished set 8 as well!