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.

Comments

Timeline

[cold fjord]

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:Timeline

[Anonymous Coward]

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:Timeline

[Noah Haders]

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:Timeline

[cold fjord]

I see you still haven't answered my other question. Any reason for that?

Not really interested in this reply.

Re:Timeline

[AHuxley]

That was already done and fully accessed by the NSA and GCHQ as shipped and offered over OS, products and software versions.
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 be ready for the next generations of Communications Assistance for Law Enforcement Act.
General availability just means a tame provider has plain text or voice or video access ready for the security services down to a city, state and federal level.

Re:Timeline

[rvw]

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.

popular = compromised

[Anonymous Coward]

Here's the problem. If any "secure messaging" should ever take off - I don't mean just among a few nerds, but I mean really take off on a Facebook-type scale among the genpop, it WILL be compromised and no longer be secure. The temptation is just too great, and the three letter agencies have far too many resources at their disposal to withstand. They can embed employees to insert very subtle backdoors that virtually nobody could see as one - whatever they have to do, they will do, if the target is that delicious. The weakness isn't the math. It's the implementation, and the social engineering.

To remain secure, it MUST be obscure. Yep, I know that's the exact opposite of the popular wisdom. But there you go. You have to both be secure algorithmically, and be small enough to fly under the radar.

Re:popular = compromised

[penguinoid]

By the same token, you should assume that your operating system (and perhaps hardware as well) already have backdoors for the government.

Re:popular = compromised

[Anonymous Coward]

I use Plan 9, you insensitive clod!

Re:popular = compromised

[Anonymous Coward]

I use Plan 9, you insensitive clod!

I use Multics you overly sensitive clod. ;-)

Re:popular = compromised

[jonwil]

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 that the userspace never sees the keys (again multiple implementations running on different FPGAs, MCUs etc, heck, build one that uses some obscure ancient CPU to reduce the chance the hardware is compromised)

Re:popular = compromised

[gweihir]

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 widespread use will get compromised. The TLAs and their masters are just so extremely afraid of the citizens they are supposed to serve that they cannot help it. Maybe if they had a shred of personal honor, things would be different, but the way politicians and TLA "leaders" get selected, that is not going to happen.

Re:popular = compromised

[gweihir]

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:popular = compromised

[gweihir]

Diversification does not really work for security, unless it is network security and the devices are in series.

Re:popular = compromised

[Raumkraut]

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:popular = compromised

[Wootery]

Off The Record 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: popular = compromised

[Anonymous Coward]

Its the military, not the tlas. They are the driving force and they have tje resources fot disruption and subversion.

Re:popular = compromised

[gweihir]

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:popular = compromised

[gweihir]

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: popular = compromised

[gweihir]

Well, it is both. The NSA is technically military, that is why it is led by a general.

Re: popular = compromised

[Anonymous Coward]

powwwwwww

We have to assume everything is compromised

[Anonymous Coward]

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

[jd]

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:We have to assume everything is compromised

[AHuxley]

In the 1950-80's most nations with complex embassy and other communications needs faced the same issues.
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 pads (use once).
The free tech product or bespoke product sold is the way in.
With more data to send, the only easy way was with a classic machine or now a computer. The NSA and GCHQ hope new projects buy into or code with one of the many tested, safe, existing standards.
This method was used in the 1920's, 30's, Enigma and can be seen from the Snowden press.
Once another nation has the code, box, staff or is working on the project its back to shared plain text all the time as over any decade.

Re:We have to assume everything is compromised

[gweihir]

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: We have to assume everything is compromised

[Anonymous Coward]

Your resoning is kinda complex. Just take a z80 and built a soft sigaba. Forget linux, windows etc.

Re: We have to assume everything is compromised

[Anonymous Coward]

Arduino will do also

Re: We have to assume everything is compromised

[Anonymous Coward]

Really ? They have folks like larry wall on their payroll. Or shannon. Or friedman.

Re: We have to assume everything is compromised

[gweihir]

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.

Re:We have to assume everything is compromised

[Anonymous Coward]

http://www.scribendi.com/advice/using_apostrophes.en.html

You're welcome.

Apple

[Anonymous Coward]

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

[PopeRatzo]

FaceTime and iMessage are the most secure protocols that you've heard of

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:Apple

[Anonymous Coward]

messages uses an unencrypted sqlite database file which you can read easily on os x, last i checked

Re:Apple

[Noah Haders]

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.

Re:Apple

[Anonymous Coward]

And this is why you have FileVault turned on.

Pony Up People

[PopeRatzo]

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:Pony Up People

[Anonymous Coward]

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.

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.

Of course it's nice to have at least someone fighting for our rights, even if it's mostly a failure in the long term.

Re:Pony Up People

[dotancohen]

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.

Re: Pony Up People

[Anonymous Coward]

On alibaba and ebay yoi can get all you need. No shiny icrap though.

Companies cannot provide working crypto

[fustakrakich]

The government already orders back doors, so they are worthless. If Open Source encounters effective cryptology. They can also be shut down. Only anonymous development can circumvent this problem.

Luck

Re:Companies cannot provide working crypto

[Kjella]

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. And with open source it's pretty hard to do anything in secret, there will have to be a git commit. There will be proof of who added it and why. I'm sure some would have been caught and confessed to being blackmailed to compromise their software, but I don't recall that ever happening.

In short, your claims seems heavy on tin foil. Feel free to do security reviews and locate these back doors then, I mean according do you they're everywhere and yet nobody can manage to find them? I'm sure it happens here and there, but if it was really that widespread they'd also get found more often.

Re:Companies cannot provide working crypto

[tepples]

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:Companies cannot provide working crypto

[Noah Haders]

I have dual citizenship so I can leave at any time mofos.

Re:Companies cannot provide working crypto

[Anonymous Coward]

I have dual citizenship so I can leave at any time mofos.

What good is dual citizenship, Mr. Anderson, when all your assets are frozen, world-wide?

Re:Companies cannot provide working crypto

[gweihir]

No. Development in countries that are still reasonably free works.

Would love to see how I2P-Bote fares.

[Burz]

"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 for the use of mail relays with variable length delays. As it is decentralized, there is no email server that could link different email identities as communicating with each other..."
https://en.wikipedia.org/wiki/...
https://thetinhat.com/tutorial...

Re:Would love to see how I2P-Bote fares.

[Burz]

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.

Re:Would love to see how I2P-Bote fares.

[jd]

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.

Re:Would love to see how I2P-Bote fares.

[Anonymous Coward]

The Botes rawks. Rawks hard. Distributed, secure, easy as pie to use, end to end encrypted, open source.

This bloody thing is the future of crypto for the masses.

Re:Would love to see how I2P-Bote fares.

[Burz]

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

[swell]

"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:missing from the Scorecard

[jd]

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:missing from the Scorecard

[Anonymous Coward]

The Botes is pretty damn easy to use!

Captcha: squid!

Re:missing from the Scorecard

[tepples]

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:missing from the Scorecard

[Anonymous Coward]

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 you need to worry about what you worry about, and most people just aren't that interesting. The real win is to defeat mass surveillance.

Re:missing from the Scorecard

[Anonymous Coward]

LOL! No. Easysec > the Botes in ease of use. Botes apologists can't understand that nobody outside a few techies are going to run it.

Re:missing from the Scorecard

[unrtst]

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:missing from the Scorecard

[drinkypoo]

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:missing from the Scorecard

[AmiMoJo]

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:missing from the Scorecard

[steelfood]

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 problem. Self-signed certs (or any other sufficiently-strong encryption key) centrally stored by the IM service and are pinned by the client would be sufficient.

Yes, an attacker can compromise the service, and either or both clients at the same time, but if either client is compromised, you have bigger issues than secure communications.

Re:missing from the Scorecard

[jd]

Yes. Not that I know of.

Apps?

[chihowa]

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 incompatible protocol is a security nightmare and only builds impediments to communication (users settle for the least secure, most commonly available protocol).

Re:Apps?

[Anonymous Coward]

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?

Because secure protocols are necessary but not sufficient for security. If the code is secret you should assume it's compromised.

A thousand messaging "apps", each with their own incompatible protocol is a security nightmare and only builds impediments to communication (users settle for the least secure, most commonly available protocol).

Many (if not on that list, in general) use XMPP.

Botes?

[Anonymous Coward]

Has anyone used the botes?

Re:Botes?

[Anonymous Coward]

yes! Also someone up above posted about the botes. The botes has end 2 end encryption with anonymizer relays for security and anonymity. Plus it's super easy to get going.

Re:Botes?

[Anonymous Coward]

I tried and it worked okay but it supposes that the remote end also be using botes.

Re:Botes?

[Anonymous Coward]

I have. Worked well, easy to install. Of course I didn't go read the code to verify it myself, but how many ppl ever od that? Trusting t hat other ppl have done, just like i trust say linux kernel.

Re:Botes?

[Anonymous Coward]

lol - no. Takes too much tech-fu. If your idea of "works well" is "needs config by a techie", then sure. But Botes is not grandmother proof. Not yet.

How Can User Ever Ensure Messaging is Secure?

[Irate Engineer]

The fundamental problem is that the average user cannot ever be certain that somewhere, someone has managed to tap in and listen. This would require that the user know the messaging system completely, and they also would have to have enough knowledge to understand all of the potential failure modes AND know without doubt that all of them were closed. For everyone else in the world, using this system would have to be a matter of faith that someone with the above capabilities vetted the software correctly AND didn't use their knowledge to corrupt the system for their own gain. This is impractical and probably impossible to achieve in a fool-proof fashion. The only way to ensure that your messages are not intercepted is to not send the message and assume messaging channels are compromised until proven otherwise (and good luck proving that). Everything else will involve a big leap of faith.

Re:How Can User Ever Ensure Messaging is Secure?

[AHuxley]

One time pad, number stations work if used correctly.
After all the news from http://cryptome.org/2013-info/... 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.

I don't get it.

[disambiguated]

I don't get it. This makes absolutely no sense. A page full of apps each with their own implementation of encryption is not what we need. Why are we doing this at the application level? Have we all gone insane?

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 that hasn't been compromised by the NSA?

Re:I don't get it.

[Anonymous Coward]

The only security is obscurity going forward. Look up. Yeah. Eye of fucking Mordor right there.

Re:I don't get it.

[Burz]

An answer a couple of replies down... http://it.slashdot.org/comment...

Re:I don't get it.

[AHuxley]

That crypto project for free, import, export, sale.. no questions, you can add code it all day with friends around the world
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 safe, user installed application.
As the text is entered as captured.
Crypto becomes the beacon to find users with the skills to install and use it daily to a good standard.

red matrix and zot

[Xylantiel]

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.

grandmotherproof

[Anonymous Coward]

The real problem to mass adoption is making it grandmotherproof. It's one thing if a nerd can install PGP but your grandmother can't do that. There are some attempts now like Botes or EasySec which try to address the grandmother problem. It's not easey. Most people won't want to learn how to do something different so you have to make it super super easy or it won't take off.

It's an ease of use problem at

Skype

[Anonymous Coward]

I thought Skype was widely believed to have backdoored encryption so the provider (MS) can read it? Any evidence either way?

Re:Skype

[gweihir]

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.)

Re:Skype

[Anonymous Coward]

Have people already forgotten? Microsoft is one of those revealed to freely cooperated with the NSA when all the recent surveillance revelations started. Believing something as popular and as big a target as Skype is not readable by them is absurd and puts the validity of the whole list in question.

Blackberry is also rather suspect. They have backdoored their encryption in various countries because these countries demanded it. Not exactly something I'd put much trust into.

Skype

[Anonymous Coward]

http://arstechnica.com/security/2013/05/think-your-skype-messages-get-end-to-end-encryption-think-again/

Yup. I expect better from the EFF. At least provide a summary of each provider.

Assumption Alert

[NotQuiteReal]

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. This is Slashdot!

But yes, passing around public keys is a nuisance that most people don't want to deal with.

Re:Assumption Alert

[Anonymous Coward]

... passing around public keys is a nuisance ...

Encryption has three problems: One, eliminating man-in-the-middle attacks caused by trusting certificate authorities; two, guaranteeing the identity of the sender; three, ensuring the message has not been altered by some other MITM attack. We use encryption to perform step three, which is wrong. We need a procedure that solves problems two and three together.

To solve the last two problems I envision every e-mail address has an encryption key-set used thus:

  1) Person writes a message and instructs the computer to 'send'.
  2) The email client generates a hash of the message.
  3) The email client encrypts the sender's signature and message hash with the sender's private key.
  4) Email client uses recipient's email address to download the recipient's public key.
  5) The encrypted signature and message are encrypted with the recipient's public key
  6) The SMTP headers are added and the message is sent to the email server via a SSL/TLS protocol.

  7) The email is received via a SSL/TLS protocol and decrypted with the recipient's private key.
  8) The email client uses the sender's email address to download the sender's public key.
  9) The signature is decrypted with the sender's public key.
10) A hash of the message is generated. It is compared with the hash received in the signature.
11) The message is displayed along with its verification success/failure.

For true security, the sender and recipient can generate new email addresses and encryption key-sets. To intercept messages, a black-hat must crack both computers and install malware that detects and forwards new encryption key-sets.

Imagine if everyone had a crypto-toeken

[Anonymous Coward]

So, almost everyone in Europe carries a crypto-token with them, in their chip & pin credit cards. If the banks would get on board, this would be an easy use for public key cryptography. Banks are already required to verify the identity of account holders, so signing the tokens is easy. They ahve websites, issuing revocation s is easy. It's not a "government issued ID", so there's some level of protection from whatever the right wing crazies are mad about. You also have options in the token provider (pick the bank) and the infrastructure is already there. Windows and mac already accept secure token logins, secure tokens for signing and encrypting email.

Problem solved, just needs to be implemented.

I don't trust my OS

[Anonymous Coward]

I welcome all these initiatives for anything crypto, however I have a problem with not being able to trust my Windows operating system nor the firmware (and bios) on my pc.

Please make a non-fluff linux version that actually would have to be considered reasonably secure. Offering security on demand.

For it to be secure, it has to be weird.

[Karmashock]

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:For it to be secure, it has to be weird.

[fisted]

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:For it to be secure, it has to be weird.

[Karmashock]

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 to be unencrypted or easily sussed out from a communication?

By all means, secure that transaction. And if you want to get really paranoid... have the pad delivered by snail mail. Not secure enough? Armed courier riding an armored bear... with bad attitude and worse breath.

The point is that once you have the pad and they don't... they can't decode anything secured by the pad. As in literally impossible with anything ever. And that is pretty fucking amazing for an encoding system as old as dirt.

The only burden of the system is that it requires a significant amount of information to maintain the code.

A play on book codes might also be interesting. That is technically decodable. But it would be a pain in the ass to compare the file against every edition of every digital book ever.

Re:For it to be secure, it has to be weird.

[coofercat]

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. Keep going to something secure by today's standards, and you put the cost of interception up by hundreds of times, if not thousands or millions. Today, you put intercepting you into the region of "only if you're in the top 100 people we care about". A one-time pad might put that up a bit more than that, but is it worth it?

Of course, the OTP means that "they" can't intercept your communications of today in 10-20 years time either. In that sense it pushes the cost up quite a bit, but for "them" to keep your comms for 20 years in the hope they might one day be able to decrypt them puts you in a relatively small subset of the population - especially if you talk a lot.

Re: For it to be secure, it has to be weird.

[Anonymous Coward]

If they have nice backdoors into windows an dlinux and macos you can encrypt with 10000000000 bits pf key and the cost wpnt rise serously

Re:For it to be secure, it has to be weird.

[Anonymous Coward]

Under US law the government can simply ask the bank for your account records. They don't need a warrant for third party business records. And,of course, a one time pad stored on your phone is only as secure as the phone itself.

Re:For it to be secure, it has to be weird.

[Karmashock]

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:For it to be secure, it has to be weird.

[Karmashock]

That's easily dealt with any of the crypto currencies.

Re:For it to be secure, it has to be weird.

[steelfood]

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:For it to be secure, it has to be weird.

[Karmashock]

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?

[kuzb]

Why exactly does the EFF need to "campaign" for this? Does it not contain programmers good enough to just do it?