Rich Kulawiec writes:
What all of this means is that once a list passes N members, where we can debate about N, the probability that at least one of those members has already been compromised even before they've joined the list starts rapidly increasing.
This is true, but you've omitted (well, hidden in the gloss about "correct usage") the most important source of compromise: the subscribers themselves.
The most important use case I have in mind is not actually encrypted lists per se, but rather anonymized and encrypted lists. If done properly (I have not even attempted the analysis yet, and may not be competent to conduct it), it may be useful against garden-variety stalkers, requiring them to access server logs or the particular user's client (in which case they're presumably already done for) to de-anonymize.
Of course, in most cases a competent (I'm not even going so far as "advanced") and persistent attacker will be able to compromise a server as well (thus "garden-variety" = script kiddie).
If nothing else, I hope to educate a half-dozen GSoC applicants that "encryption is at best a 10% solution, and more likely 7%". :-/
And then Rich Kulawiec writes:
In particular, note that entities like Whisper and Signal have been, as I've said for years, peddling snake-oil. They cannot possibly deliver on their promises *even if they do everything they say they can do* because all of it is immediately and completely undercut if the underlying system is compromised.
Compromise of the underlying systems still typically requires cooperation from the user. Agreed, most people who casually think, "oh, an encrypted list! that's useful", are already busted. "Caveat: that word ('encrypted') doesn't mean what you think it means" should be warning enough (for our CYA, anyway).
This is about building a system that is known 0% secure from the start.
Is that 0% Kelvin or 0% Celsius? ;-)
I think, in the end, this will serve the community poorly -- because people who don't grasp the contemporary security landscape will deploy it, will rely on it, and will not understand that they lost the game before they even started to play it. This will have consequences.
People are already affronted that pretty much anybody who wants to can read their email, but that's the fact and it has consequences. I'm not sure we need to take responsibility for that. I'm willing to hear more about that, but not on the basis of strawmen like "0% secure".
As Zeynep Tufekci has been at pains to point out since the Guardian WhatsApp fiasco, that doesn't mean we shouldn't provide tools imposing additional effort on the bad guys for use by those who do understand the risks in this environment.
If you want to point out what use cases are broken from the word "go", even if that includes my preferred applications, fine. But I think it's reasonable to expect that a number of user groups capable of taking advantage do exist.
And he persists:
Moreover, none of this comes for free: there is opportunity cost, complexity cost, maintenance cost, interoperability cost, etc.
It's nearly free, because there are a lot of GSoC wannabes out there who think this is "way cool". Disabusing them of that notion may be the most important contribution of this project.
In my view, it's not worth incurring all these costs to implement something that we already know, today, right now, is not going to work in the contemporary Internet environment -- because it relies on underlying assumptions about endpoint security that almost certainly won't be true as soon as the deployment scale reaches modest numbers.
I thought that it already wasn't true even before we thought up this project, let alone when deployment can be expected to reach "modest scale"? Rich, calm down -- inconsistency is unbecoming of a security professional. ;-)
Note my reply to Barry: it's not unreasonable to expect that the odds turn against you as soon as you *pass three subscribers*. So, yes, we are going to have to document that to the users, and tell them they are going to have to make serious effort to turn the odds in their favor for *any* use case they may have in mind.