Slashdot Mirror
EFF Begins a Campaign For Secure and Usable Cryptography
Peter Eckersley writes: Over at EFF we just launched our Secure Messaging Scorecard, which is the first phase in a campaign to promote the development of communications protocols that are genuinely secure and usable by ordinary people. The Scorecard evaluates communications software against critical minimum standards for what a secure messaging app should look like; subsequent phases are planned to examine real world usability, metadata protection, protocol openness, and involve a deeper look at the security of the leading candidates. Right now, we don't think the Internet has any genuinely usable, genuinely secure messaging protocols — but we're hoping to encourage tech companies and the open source community to starting closing that gap.
Don't you mean that you've heard of?
I mean, "that you've heard of" is the entire purpose of the EFF post. There are more than a dozen protocols that are more secure than Facetime and iMessage. That's the point of the chart - to show people there are better alternatives.
If you can look at that chart and still think those two are your best bets, then you probably don't really care that much about security.
You are welcome on my lawn.
This reminds me, It's time to send my quarterly donation to EFF. They represent my interests better than any other political organization. And, they're more effective.
You are welcome on my lawn.
"usable by ordinary people"
We would have had encrypted communications long ago if PGP, etc were usable by ordinary people. The Scorecard is a good start in evaluating the security of different systems, but there is no effort whatsoever to evaluate usability.
...omphaloskepsis often...
The first requirement is that auditing must involve (0.5 x participants) + 1 who are not compromised, the minimum number guaranteed under The Byzantine General's Problem to result in provably correct information being transmitted to/from the head of the development team (who must also not be compromised).
The second requirement is that the audit not be done directly. In the case of seL4, the proof was done mathematically. In the case of extreme programming, development is done by producing test harnesses (essentially the same thing as the mathematical proof) which the code must comply with in order to pass inspection. Code itself is often very difficult to validate by inspection, inspecting the reasoning/logic is much cleaner and it's easier to prove that the inspection is itself correct.
The third requirement is that you must be able to establish that "traitor code" within the system, provided it is sufficiently small, cannot compromise security. In other words, there should be no single point of security failure, where a traitor module could transmit sufficient data to compromise the entire system. Obviously, there can always be sufficient traitor modules to betray the secrets between Alice and Bob. Nor is there any way to prove you have eliminated all of them. What you have to prove, however, is only that your detection threshold for such code is below the minimum number of such modules needed for a third-party to intercept Alice's lunch plans with Bob. Anything below threshold is unimportant.
This doesn't require you to use lots of duplicate code. It requires only that no block of code guaranteed to run gets to access clear-text and any form of network or storage device. Ever. Clear-text handling code should be able to read data, process it and hand it directly over to the next module. Nothing more. Then it doesn't matter what else it tries to do, it can't do anything toxic. Ideally, you'd write such code in its own totally isolated process that is loaded and run by the main program. If it's a distinct process, ideally under a non-privileged user, you can lock it down. Give it absolutely minimum rights to do what you specify and nothing more. It shouldn't have network access of any kind, for example, since it isn't to access any network.
Because nothing clear-text escapes that container, even via leakage over the heap or stack, it doesn't matter what has been added to the network code. There's nothing sensitive that can be leaked to third-parties at that point, if the cryptography is good.
Now, as previously noted, all this code is being audited by formal or semi-formal methods that have, themselves, been audited. This is still necessary, because the firewall isn't perfect. It's good, but a rootkit or hypervisor can see into the memory of multiple processes and can thus cross-contaminate without ever altering the code itself. The audit won't stop that, but it'll stop any code being added that assists in such a process.
Now, can you stop a third-party hypervisor at all? No. You cannot. That's what makes the NSA and GCHQ bleats so infuriating. If they were actually competent, they wouldn't care about what software you used, they could obtain anything they wanted in the clear anyway. It betrays severe incompetency and if there's anything more annoying than a spy agency conducting industrial espionage and moral supervision of the citizens of a country, it's a hopelessly incompetent spy agency conducting (largely successful) industrial espionage and moral supervision of the citizens of a country... whilst asking for assistance in doing so.
To get much more secure, to actually block software running outside the OS itself, you need far better security than you can achieve in software. With software, there is always something that can look in from outside. And if it can look in, it can both intercept and inject at every point in the code. Nothing, not even the data stream, can be assured. To go further, you must abandon plug-and-pray commodity hardware. If you want guaranteed inte
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Thus, any packet sniffer out there (be it by a credit card thief, the NSA - who may also be credit card thieves, or anyone else) can't look for context to decide what packets to grab. There is no context.
Actually, there is the very important context of who is transmitting to whom, and when, which IPSec is giving away. Each user, therefore, might as well be the subject of a pen register.
With I2P, all they see is a stream of encrypted packets to random points and even the 'when' is obscurred (I2P users onion-route traffic for other users by default and expectation, so you can think of this protocol as marrying ideas from IPSec, Tor and Bittorrent).
That means having to decrypt absolutely everything, including DNS lookups...
Speaking of DNS lookups: Why make your addressing dependant on centralized, establishment-controlled scheme? If PKI can be subverted to let them eavesdrop, then IP addresses and DNS certainly can be as well. Addresses that operate like public keys are much better.
Its already there on your TAILS disc... try it out. ;)