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

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

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

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

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

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

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.

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

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

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

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.

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]

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

[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

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

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.

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

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.

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

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.

Campaign?

[kuzb]

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