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.
Getting grandma and cousin alex to use it is actually very simple.
Can they use Imessage? sure they can!.
What if all of Imessage's backend systems were secure end to end.
Woudlnt change the look and feel, would certainly change the underlying security.
Getting platform vendors to adopt it is certainly the hard part.
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.
Its also worth noting that the I2P layer under I2P-Bote is general purpose: You can browse and even torrent with it, anonymously and securely.
Why make the focus so piecemeal??? We have experts going around saying the answer to mass surveillance is to make application-level crypo ubiquitous. I'm sorry, but that sounds like an unnecessary hassle that begs people to "just turn the crypto thingie off". Its better to have one tool that can provide security and anonymity for a large array of applications.
I respect the EFF's work, but I think their technical vision is very tiny and may meet up with the blind alley it deserves.
"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)
Agreed. Better to fix IPSec and have every packet encrypted - with keys when possible, opportunistically as fall-back - when communicating with any other computer for anything.
One of the advantages of IPSec is that absolutely everything is encrypted. 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. That means having to decrypt absolutely everything, including DNS lookups, spam emails, everything. Since keys expire frequently, the value of the data has to be extraordinary to be worth the cost of the effort.
The main disadvantage of IPSec is that it doesn't replace the unencrypted channel for the user, it's a distinct channel. That's bad. You don't want a trojan sneaking onto the computer and simply echoing all the juicy gossip over the plain wire.
The second disadvantage is that it's a very heavy protocol. Sun's SK/IP was lighter and it might be worth investigating why it was dropped and whether it might be a better choice.
The final disadvantage is that most implementations use crypto functions that are no longer regarded as secure or are horribly slow. Not that that matters anyway, as to get it to override the user-visible open channels, you'll have to rewrite it anyway.
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)
What about RedMatrix and its underlying protocol Zot? (This is what Friendica Red became.) Seems a shame that it isn't even mentioned. But most of the things on the list are oriented toward messaging, not more full-feature peer-to-peer sharing / networking. I think the only downside for Zot is the providor has the key. But you are free to be your own providor or choose one that you trust, and move if that relationship changes.
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. ;)
The notion of just having something computationally difficult of decoding is not enough. The codes have to be randomized not only in seed but in the syntax of the encoding system itself. What is more, we should look at ideas to split information up into packets that route through different communications systems so that anyone tapping one of those systems would be unable to decoding the message even if they knew how. And even if they were tapping all communication systems it would at least be more complicated to connect the two bits of information to run the decoding properly.
Beyond that... and this always makes people furious... we need to seriously think about using digital equivalents of "one time pads" for high security applications.
For example, lets say you download a new onetime pad for your bank. That information sits on your phone or your laptop or where ever. And it lets you complete a set number of transactions or access a set amount of banking data before you need a fresh pad. Then when you want to do something with your digital wallet... you can let the NSA, chinese, all the Nigerians, the russians, etc all have access to your transaction... and lets assume they have quantum computers, alien super technology, and whatever else short of that fucking password breaker from Sleepers. And they're not going to be able to break it. It will remain secure.
That is the sort of security I want. I want security that is either so fucking hard to break that the governments or criminals don't even try to break it. Or that is literally impossible to break with any technology or amount of time... Ever.
One time pads for all their inconvenience are unbreakable. That is a huge.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.