EFF Begins a Campaign For Secure and Usable Cryptography 96
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.
Timeline (Score:1)
Start today and maybe have widespread general availability in ordinary consumer products on Mac and Windows in 3-5 years. Maybe. Good luck. And good luck getting Grandma and cousin Alex to use it.
Re: (Score:2, Insightful)
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.
Re: (Score:2)
there's a couple exceptions. One, every iphone comes with imessage and facetime, so if gramps and granny have an iphone then they are using these. Another option is cell calls and SMS, which also are on every phone but are horribly insecure.
Re: (Score:2)
The US brands where tame, their network and products allowed the flow of voice, images and text back to other nations.
From Communications Assistance for Law Enforcement Act to the Snowden news. Tame cell or tame junk software encryption standards is now more understood..
An OS or software or device maker can talk of their encryption but their efforts always go back to needing to
Re: (Score:2)
And good luck getting Grandma and cousin Alex to use it.
Getting grandma en mom to use it won't be too difficult, if it only is a matter of configuration. We do that already, so if we can set it up to be secure without adding complex user actions, they will use it because we handle their computer setup and we decide how we do that. I hope they can find a way to get email work like that.
Re: (Score:1)
By the same token, you should assume that your operating system (and perhaps hardware as well) already have backdoors for the government.
Re: (Score:2)
Depends. As long as Linux and the xBSDs are not big on the desktop, they may remain secure if administrated well. Also take into account that as long as these are on high-value servers, any known backdoors will be used very sparingly as there always is a risk of discovery and loss of that backdoor as a consequence.
Re: (Score:2)
One way to at least try to make that harder is to have multiple implementations written totally differently (different code-bases, different languages, different development teams, different countries etc) so that you have different implementations both doing the same thing (harder to compromise multiple implementations like that)
Better yet, come up with a hardware box (open source, auditable and buildable by anyone but can be built secure and tamper-resistant too) that does the actual cryptography in a way
Re: (Score:2)
Diversification does not really work for security, unless it is network security and the devices are in series.
Re: (Score:2)
Diversification is the tradeoff between "some people get compromised sometimes" and "everyone gets compromised rarely".
If there is one development team, and one client, then if that client is found to be insecure, the only secure course of action is for everyone to stop using that protocol altogether.
If there are many teams, and many clients, if one client is found to be insecure, people can just switch to a different client and continue on as before.
Re: (Score:2)
Well, for the limited field of one-purpose applications that is true. I had not thought of that. Of course, unlike in-code diversity, the diversity does not help you find flaws though, just avoid them once they are known. Still a good thing, agreed.
Re: (Score:2)
It will not take off, at least not anything designed to be used securely. If you do it right, you type in your passphrase at least once per session, and your passphrase will be long and complicated enough to make it hard to remember. What ordinary users use can be brute-forced by amateurs (e.g. the local police).
As to "obscure", in software security that does not refer to it being not widely used, it refers to the source and design rationales not being available. I completely agree though that anything in w
Re: (Score:2)
Off The Record [wikipedia.org] works even if you never compare device fingerprints, but of course you then have no assurance that you're not being man-in-the-middle'd. (You could detect a man-in-the-middle at a later point if you later compare fingerprints, though.)
Re: (Score:2)
For practical purposes, that is already pretty good. PGP signatures on distributed code works on pretty much the same principle. One remaining problem is that people have to understand that limitation, i.e. that if they have any reason to suspect a man-in-the-middle attack may be conducted against them, they have to compare fingerprints.
Re: (Score:2)
Well, it is both. The NSA is technically military, that is why it is led by a general.
We have to assume everything is compromised (Score:1)
We can assume that governments will salt the groups of volunteer coders with their own people. That's not preventable. The question is how to produce a product in spite of that.
Re:We have to assume everything is compromised (Score:5, Interesting)
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
Re: (Score:2)
Send a lot with of information back standard equipment and the next generation product range was back to plain text for the NSA and GCHQ.
1950's France and Russia understood that over time.
The NSA and GCHQ always got into the supply and design stage. Top staff or as an entire front company. Plain text for the US and UK was easy then.
Security could only be established with number stations and one time
I don't get it. (Score:2)
In the face of widespread Internet surveillance, we need a secure and practical means of talking to each other from our phones and computers.
Agreed. I have a suggestion: internet layer encryption [wikipedia.org] that hasn't been compromised by the NSA?
Re: (Score:1)
The only security is obscurity going forward. Look up. Yeah. Eye of fucking Mordor right there.
Re: (Score:2)
An answer a couple of replies down... http://it.slashdot.org/comment... [slashdot.org]
Re: (Score:2)
All the encoded networking use stands out and is a path back to a user.
The special apps after text entry for network use are just the way to find a users who feels they need crypto.
A gov will just send down uniquely crafted malware for that user to grab every aspect of plain text entered.
Quality consumer grade behavioral and heuristic antivirus applications will see another saf
Re: (Score:2)
Depends. Doing clever backdoors is very, very hard. Doing obvious ones can, for example, get you yelled at and removed from the team. But what is really needed is a lot more peer-review, and since that is time-consuming by people that get paid for it form different sources.
Re: (Score:2)
So? The nice thing is that even if the lowest of low tech workers finds a flaw, no Shannon or Friedman or Larry Wall can claim successfully it is not there. You can prove properties of code pretty easily. The hard thing is to find what to prove.
Apple (Score:1, Insightful)
This eff effort validates my understanding that FaceTime and iMessage are the most secure protocols that you've heard of and are not tinfoil hat protocols. Apple is committed to the privacy of its users where other companies are not (likely to have something to advertise against).
Re:Apple (Score:5, Insightful)
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.
Re: (Score:2)
that was old. we're talking about the imessage platform that has always been in use on iphone, and two years ago came to mac as well. see the chart in the link for more info.
Pony Up People (Score:5, Insightful)
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.
Re: (Score:1)
Are they really? Seems like the way things are going in the world, the politicians are sure as hell doing a sweet job of ensuring we lost more and more of our rights and control over our hardware than ever before. Without the EFF this slide into despair would be faster, but they certainly aren't reversing it. Merely pushing against the tide.
O
Re: (Score:2)
Without the EFF this slide into despair would be faster, but they certainly aren't reversing it. Merely pushing against the tide.
Right, that is exactly why you should donate. I do it yearly, not quarterly, but it is important to donate regularly.
Companies cannot provide working crypto (Score:1)
The government already orders back doors, so they are worthless. If Open Source encounters effective cryptology. They can also be shut down [wikipedia.org]. Only anonymous development can circumvent this problem.
Luck
Re: (Score:2)
I guess you didn't bother to read your own link as it's all about what the US military invents and creates secret patents for, not really sure what they point of it is but probably to avoid paying patent royalties on stuff they already knew, but were classified so they couldn't tell they were first.
Also there's a whole lot of other countries outside the US, where the US can't just send gag orders as they please. Many cryptography projects won't accept any US contributors due to US export regulations anyway.
Re: (Score:2)
Also there's a whole lot of other countries outside the US, where the US can't just send gag orders as they please. Many cryptography projects won't accept any US contributors due to US export regulations anyway.
So what are people like me supposed to do? Somehow qualify for a work visa and emigrate from the United States?
Re: (Score:2)
I have dual citizenship so I can leave at any time mofos.
Re: (Score:2)
No. Development in countries that are still reasonably free works.
Would love to see how I2P-Bote fares. (Score:2)
"I2P-Bote is an I2P plugin, fully decentralized and distributed email system.[18] It supports different identities and does not expose email headers. Currently (2014), it is still in beta version and can only be accessed via its web application interface, but POP [also IMAP] support is planned. All bote-mails are transparently end-to-end encrypted and, optionally, signed by the sender's private key, thus removing the need for PGP or other privacy software. I2P-Bote offers additional anonymity by allowing fo
Re: (Score:3)
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 respec
Re: (Score:3)
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, incl
Re:Would love to see how I2P-Bote fares. (Score:4, Informative)
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. ;)
missing from the Scorecard (Score:5, Insightful)
"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.
Re: (Score:1)
If you can enter a password, you can use PGP.
That's fine for communicating with people whom you have met in person, such as your girlfriend. But how do you verify that a particular public key belongs to a particular person (or to the person in a particular role)? Before you say "web of trust", consider that just because you can vouch for someone's identity doesn't mean you can vouch for that person's ability to vouch for others' identities.
Re: (Score:1)
Well true but here's the thing: very few people need to worry about impersonation attacks. Sure if you are of particular interest to the NSA you are fucked. But for most person to person communication, it isn't of enough interest for anybody to bother. Encryption is good enough. Encryption alone solves a key problem: mass surveillance. It raises the bar for the surveillers. There are solutions like Botes which purport to address this, but in the interim, you have to be of particular interest before y
Assumption Alert (Score:2)
people whom you have met in person, such as your girlfriend
You can't assume that he has met his "girlfriend", in person. See, for examle, this [wikipedia.org]. This is Slashdot!
But yes, passing around public keys is a nuisance that most people don't want to deal with.
Re: (Score:3)
IPSec and SK/IP are usable by ordinary people, and since all applications can work over those, all applications can have secure and usable cryptography.
That's not the problem. The problem is that if it's not used by a critical mass of people, it doesn't do any good. Until people are forced, kicking and screaming, to not broadcast every private thought with the entire world, nothing will happen. I'll see you on the 6Bone before I'll see the average Joe so much as clicking a button in their own interest.
Re: (Score:2)
IPSec and SK/IP are usable by ordinary people, and since all applications can work over those, all applications can have secure and usable cryptography.
Does SK/IP implement opportunistic encryption? Has IPSEC's OE been fixed to not be a security fail?
Re: (Score:2)
Yes. Not that I know of.
Re: (Score:3)
The lack of a usability-by-ordinary-people rating was sad. That's the main reason I went to look at the page, and I see no rating regarding that at all.
Some of those are much more usable than others. Would be really nice to include that info, but I guess that gets more subjective (which is why I wanted to read it anyway).
It's still a nice (though small) start.
Re: (Score:1)
I set up GPG in Thunderbird for some friends that are not particularly tech-savvy and they get on okay. It's the initial set-up and key distribution that is a problem, after that it's just a question of entering your password when requested.
Re: (Score:2)
PGP was never usable by ordinary people. PGP is as close to perfect security as you can get. Perfect security is hard. Ordinary people can't deal with hard things. Ergo (and I repeat) PGP is not usable by ordinary people.
You don't need perfect security for normal, everyday communications. You don't need to be certain that "Alice" online is actually the Alice you know in real life. You only need to be certain that "Alice" online is "Alice" online and not "Eve" online or "Mallory" online. That's a much easier
Apps? (Score:2)
Why is the focus here on "apps" instead of protocols? Wouldn't it make the most sense to decide on suitable protocols and work forward from there? Many of the tools that are scored use the same underlying protocol and thus pass/fail the same criteria.
Several of the criteria are not ever likely to be met by most "tech companies" (available for independent review or audit), so why not push a set of robust protocols and encourage everyone to adopt them? A thousand messaging "apps", each with their own incompat
How Can User Ever Ensure Messaging is Secure? (Score:2)
Re: (Score:2)
After all the news from http://cryptome.org/2013-info/... [cryptome.org] any generation of computer or international standard is allowed to gain traction.
Once a gov has staff or front companies help set international standards, the plain text just flows for years from most users, most of the time.
red matrix and zot (Score:3)
Re: (Score:2)
There were some changes when MS took over that only make sense if Skype is compromised. Also, the Linux version got pulled, probably because it is easier to analyze. (I don't think MS not liking Linux would be a strong enough reason.)
For it to be secure, it has to be weird. (Score:3)
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.
Re: (Score:2)
you download a new onetime pad for your bank
And how do you secure that download? By another one-time-pad you downloaded somewhere else?
Re: (Score:2)
Simply having the pad download at a time other then the point of transaction makes it much harder to steal from them.
Lets say I download the pad at point "A" and that is intercepted by someone so they have the pad. The pad is only one factor of authentication. It doesn't include my account number, my pin, or even some biometric attribute that might be relevant.
Furthermore, you might have lots of pads being sent around so the context of the pad might not even be clear.
Furthermore again, who says the pad had
Re: (Score:2)
Understood, but the point of using crypto tech is to put the costs of interception up. Right now, with all comms in the clear, the cost of intercepting you is "1". If you used ROT13 on all your emails, you'd put the cost of intercepting them up by several times. If lots of people did it, then the cost would maybe average out at something 1.1 x clear text. Go to a 56 bit RSA (which is 'easily' breakable') and you put the costs of interception up many times, even if everyone in the world did the same thing. K
Re: (Score:2)
We have the technology to make codes that cannot be broken... EVER by any technology short of time travel, teleportation, and mind control.
We can make encryption that cannot be broken. Why not do it?
Re: (Score:2)
That's easily dealt with any of the crypto currencies.
Re: (Score:2)
we need to seriously think about using digital equivalents of "one time pads" for high security applications..
We do. But OTP's are not practical for normal, every day usage. And despite what you might think, normal every day communication is not a high security application. The idea is to make it difficult to break into everybody's communications, not to make it difficult to break into anybody's. See the difference there?
Re: (Score:2)
If people had the option to use them to correspond with their banks etc, they would. not everyone... but people would.
as to the objective... the objective is security.
Campaign? (Score:2)
Why exactly does the EFF need to "campaign" for this? Does it not contain programmers good enough to just do it?