Slashdot Mirror
Moxie Marlinspike: GPG Has Run Its Course
An anonymous reader writes: Security researcher Moxie Marlinspike has an interesting post about the state of GPG-encrypted communications. After using GPG for much of its lifetime, he says he now dreads getting a GPG-encrypted email in his inbox. "Instead of developing opinionated software with a simple interface, GPG was written to be as powerful and flexible as possible. It's up to the user whether the underlying cipher is SERPENT or IDEA or TwoFish. The GnuPG man page is over sixteen thousand words long; for comparison, the novel Fahrenheit 451 is only 40k words. Worse, it turns out that nobody else found all this stuff to be fascinating. Even though GPG has been around for almost 20 years, there are only ~50,000 keys in the "strong set," and less than 4 million keys have ever been published to the SKS keyserver pool ever. By today's standards, that's a shockingly small user base for a month of activity, much less 20 years." Marlinspike concludes, "I think of GPG as a glorious experiment that has run its course. ... GPG isn't the thing that's going to take us to ubiquitous end to end encryption, and if it were, it'd be kind of a shame to finally get there with 1990's cryptography."
Encryption is for terrorists! By imperial order all communication must be done using unencrypted VNC shared screens!!
... To their own opinion.
Get off my lawn
This sig can be distributed under the LGPL license
Ending up as an unemployable martyr because I can't board a place is not something I can afford.
They're even stopping you riding fish now! That's harsh
I suspect some of the cruft is due to its PGP heritage, but really, all the options aren't the problem. The length of the manpage, neither. Here you have a decently documented piece of software and you complain about the volume? Psah. No, that really isn't the issue. Nor is the ability to have multiple algorithms, as the state of the art keeps on advancing and so you need to replace algorithms now and then.*
The issue is that the interface, the way it packs up crypto for ease of use, is something only a crypto-nerd could love. The basic principles aren't hard to explain to an intelligent lay(wo)man, but understanding how the web of trust works, nevermind make intelligent decisions that make sense, that even crypto-using nerds usually don't manage. And that's just the model; the implementation is clunky to the point that even programs employ intermediate libraries that then barely work for this or that ill-conceived reason.** And then there's the interface as ment for humans. Again, it's nerd-only.
That nerd-only-ness is an obstacle to uptake, and that again is a problem. We desperately need crypto in email, but what bank even publishes GPG and S/MIME keys for securing email? I know of one, and it's a central bank so mere mortals cannot open accounts.
So for a long time GPG has only been supported by a single person, props to him, who evidently doesn't know much about usable user interfaces, not even CLI ones. Yet I'm not blaming just him for it, either. Look at openssl: Again a bit of crypto software that turns out to be pretty damn important, and there's only a few boobs holding down the fort. That is actually poorer documented and even clunkier to use. The code, starting from the APIs, isn't so hot either. No wonder it came crashing down spectacularly. But that too is a problem.
So we have a couple real problems, yet this security expert managed to pin only non-problems. And that itself is again a problem.
* One thing that is a problem is the headers inserted on top of the message that really ought to've been encoded in the signature, since they belong there and moreover there's no real need to put them anywhere else. In fact, the current practice causes transport problems making the format more brittle than it needs to be.
** Work out why gpgme doesn't work so well on 64-bit windows, especially where the individual programs may or may not actually be fully 64bit. It literally doesn't work because some maintainer disabled the workaround that made it work because that somehow "does not make sense" to him.
I've used GPG since... I don't even know, for a very long time. However, since I communicate a lot internationally, and I don't know (and I don't want to know) about every country's regulations regarding encryption, I gave up sending encrypted e-mails at the very beginning, but I still always sign my mails. I never even thought about how many people use or don't use GPG, it's just been there, ever so useful - and I think that's good so. I think "run its course" is harsh though. Why? Because one Moxie Marlinspike says so? Bollocks. If it's useful - and it is -, it's good to have it.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
It really is just an alphabet soup of acronyms with security systems. No wonder the average person just doesn't bother.
...what do the other characters from Harry Potter think?
systemd is Roko's Basilisk.
It's a bad sign when those who care about security lose interest. The NSA is doing their part to eradicate secure crypto. Law enforcement agencies are commonly breaking the law to fish for potential criminals. The only protection available is what's written by people who are not subject to influence from the NSA. That's increasingly meaning open source or non-US-based companies.
Crypto is hard to get right. It's hard for the average person to know what ciphers or tools to use and which are just snake oil. It's hard to implement correctly so that it is secure. New ciphers are written by people who have a lot of experience in breaking the old ones. As the old guard ages out, I don't see the same depth of interest in the next generation. With crypto, there's no quick fix, and the new hotness doesn't come overnight.
On the other hand, the 1990s cryptography he mentions would be a huge improvement over many things we have today. Since the 90s, I've wanted the ability to have cryptographically signed financial transactions. Instead of financial institutions and credit reporting agencies using shared secrets, I'd like to have the ability to authenticate with a public key. I'd like to provide my public key in person to my bank so they know I'm authorizing transactions. Instead, they rely on secrets which are available to anyone who's willing to spend a few bucks and maybe break a few laws. Identity theft is so prevalent because we're basically relying on writing (at least a 4000BC technology) for security instead of good crypto. Hell, bad crypto would be an improvement over most of what's being done today.
I hope his opinion isn't representative of more people who have been involved with security and privacy issues, but unfortunately, I think it will resonate with a lot of us.
Blame Google for not implementing it in Gmail -- Then they wouldn't be able to get ad revenue and user metrics from their "free" email service.
Blame MS for not integrating it into Outlook, but why would we expect MS to actually want security in any of their products?
Blame Mozilla for the creaky plugin and cumbersome import/export publish keys interface in Thunderbird, and support for SMIME over GPG by default.
Blame the users mostly for not giving a fuck about encryption.
Personally, I don't give a fuck. Most people don't care about encryption but the ones that do, do. Some take the time to setup GPG with an email client and it actually works quite well despite my complaints about the clunky interfaces.
I can tell you this much: Fuck publishing ANY open source software without signed and verified GPG signatures. You better have a replacement for the "experiment" that's securing the world's biggest open source projects source code, buddy, or you can GTFO for being a sensationalist maroon.
TL;DR: People who need GPG use GPG. Those that don't give a fuck don't give a fuck. Seriously, if the average person can figure out how to use the bullshit set-top box with horrible remote control interfaces, they COULD use GPG if they wanted to, but they don't.
My GnuPG public key is on my web site (www.andycanfield.com). It is not on any "KeyServer"; I don't believe in key servers, that's just another layer that the hackers can break and the NSA can subvert.
I use Thunderbird; the interconnection between that and encryption is clumsy [ e.g. if you haven't got a key for somebody, don't encrypt the message, dummy!]. But it works. As long as it's smarter than Keith Alexander and Vladimir Putin, I'm satisfied. The important thing is that PGP is a ***standard***. Any idiot can come up with something better, but he can't make it a standard, so my correspondant on the other end of the wire can't use it.
Oh, and my e-mail address is on Yandex, which is in Moscow.
Forward secrecy is desirable as we see the NSA hoover up messages then store them until they crack the keys.
Has anybody attempted to bolt forward secrecy on top of SMTP? I would assume that it would need some kind of session key exchange between sender and recipient which would preclude the use of SMTP.
SURELY NOT!!!!!
Yeah. If only there was an easy to use end2end encrypted mobile phone application for voice calls that Moxie had been involved in creating.
https://en.wikipedia.org/wiki/...
it's in my head
The point is that Moxie actually *does* something (has the OP done anything? We don't know).
I don't agree on everything with Moxie, but fact is that he's not sitting on his hands, by a long stretch.
Show us your work. Talking is easy Moxie: PRODUCE SOMETHING USEFUL.
He is just being Marlinspitefull.
DUMBER NAME THAN BENNETT HASELTON. Filter error: Don't use so many caps. It's like YELLING.
Has anyone ever seen Moxie Marlinspike and Bennett Haselton in the same room?
Thought not.
To have a right to do a thing is not at all the same as to be right in doing it
GnuPG is what is known as software for professionals, i.e. people who know what they are doing. It is not software that satisfies the "hold my hand" or "put me in a wheelchair" needs of an unsophisticated user. There are plenty of programs that cater to the helpless average user. GnuPG is for professionals, so such criticism as contained in the article does not apply.
Phones are insecure, crypto on phones is a joke.
I partially agree with Moxie, GPG/PGP as an email encryption standard is never going to reach the "my mother uses it" point of say Skype. That doesn't mean its run its course. I also think it's disingenuous to imply that the number of keys on the public key servers is a useful proxy for utilization rates.
In my company we use GPG every day. Most people who work there have no idea that we do. It's used in sensitive communications at high levels between organizations, e.g. to send documents to auditors. It's also used in a huge number of automated processes to encrypt data during the DB extract process so we can move that data out of the DB network and send it to partners.
We don't send those keys to a public keyshare. That would provide attackers information and we don't do that (ya, security through obscurity sucks if it's your only line of protection. If you're using it to make life just a bit more difficult for an attacker tho, well I'm always for that!)
Now all that having been said, I have great respect for Moxie, and maybe he has the Next Great Thing up his sleeve. I hope to see it at Defcon :).
Min
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
I simply asked him -- in a private email -- if there was a signature for Convergence someplace because I didn't see any online.
He accused me of being "inflammatory" and stated it was necessary to "take a leap of faith" (i.e. download and run it without verification). This was back in 2012, mind you. He appeared to be oddly anti-PGP back then, too.
Frankly, after that I had no appetite for any more of his, erm, style and forgot about Convergence. Years later, I had to abandon DoNotTrackMe (by a Moxie-run company, Abine) nee 'Blur' for Ghostery instead when the former got an update that kept hogging the CPU. An email to Abine just yielded a response to keep updating Blur, but the problem never went away.
I was saying all this 14 years ago.
FOSS Encryption is a mess. It is basically impossible for a regular user to set up encrypted mail.
I'm an expert, and I never even managed too. (The K-Mail crew basically lying about their GPG-features didn't help back then)
Furthermore, the actual, underlying problem is E-Mail.
That this piece of crap protocol/service could survive for so long totally amazes me. I remember using Fidonet and Crosspoint, back in the 90ies (which actually is a superiour solution to E-Mail) and then learning about E-Mail and thinking "Why is everybody using this and thinking it's great?".
The fact that E-Mail is so shitty is the sole reason Facebook has north of a billion users - for the simple reason that Facebook actually is a *better* user experience than E-Mail. Think about that for a moment.
Bottom line:
E-Mail needs a complete redo/replacement with hard asymetric encryption and zero-fuss key handling and exchange built in as a core specification. Top-notch FOSS clients for all major platforms included. That this whole field is in such a sad and sorry state is to the largest part the fault of us, the FOSS community.
We suffer more in our imagination than in reality. - Seneca
Most ordinary users I know actually like the idea of encryption. They just can't use it because no one has created a highly opinionated encryption API that is intended to be plugged into browsers, email applications, office suites, etc. and is dead simple to use. This is something that an open source desktop like KDE should take on as a proof of concept. I'm sure there's plenty of code in GPG that could be extracted, turned into a tight little module and then wrapped with really slick C or C++ APIs with really friendly dialogs in Qt or GTK.
This isn't entirely a mystery. For a technology to be widely adopted, it needs to be easy for everyone and provide demonstrable benefits. OR, it needs to provide benefits for a business who already has your custom. And there we begin to see the problem. There are two massive disincentives:
- Crypto doesn't play well with webmail
- Encrypted email can't be scanned for advert keywords
So you will never see the likes of Google or Microsoft championing this. Apple - just maybe, as they would rather promote devices, and I gather they actually DO have decent end to end crypto on iMessage and so on. But even then, it's VERY hard to do in a way that customers would actually appreciate. No-one wants to get email working 95% of the time. It needs to be 100%. If you can't read 5% of your email, you're in trouble. Or you can't read email on the 5% of time that you need to access from a borrowed PC.
It seems to me that the keys to making this work are:
- Concentrate on signing before crypto. Get banks to sign email. Have different security levels; get to a stage where by default, only signed email will download embedded images, make links clickable without a warning, etc..
- Find a way to make it work with webmail. Can we do this with JS? Or do we need browser support? End to end crypto It would require a way for a part of a page to be sandboxed, accept a secret to decrypt your keys, and not allow the plaintext info out. End to end signing is a little easier. This might also include retrieving the private keys from a distinct cloud service.
- Solve the centralized trust issue. Probably derive a format from S/MINE rather than GPG for email, but critically, signing of certs needs a community trust system so you can see who trusts who, and people can get their identities signed by people they know.
Finally, if that's widely deployed for signing then people can begin to encrypt with a hope of the other end being able to decrypt.
"The GnuPG man page is over sixteen thousand words long; for comparison, the novel Fahrenheit 451 is only 40k words."
sixteen thousand words = 16k words
When did 40k words become less then 16k words?
Yes, I've used Redphone. No strange setup process needed for the calls to be secure. That's what we're discussing, right?
The first time you start up RedPhone, the app prompts you to register your phone number by tapping a button. And then you're done; that's it. RedPhone doesn't ask for passwords, logins, or even for users to create an account. The app is designed with privacy in mind, so it requires as little from you as it can.
http://www.pcmag.com/article2/...
it's in my head
I wanted to post something on the Facebook pages about my town: A Facebook search which would bring up a couple of pages, I'd go to those pages, which would show a couple of associated pages. I'd click on join for each one and wait.
Then I went to the phone-book: Type in the town and a selection criteria; all the names appear, with a large percentage showing email addresses. I could immediately push my post to a large percentage of my target audience.
Facebook may be a better experience (Aside: I disagree) but phone and email provide the superior networking function. Social networking means only that I do less 'pushing' of the message.
Then PGP / GPG solved a lot of this bullshit, starting with generating keys for free but email clients never bothered to give it proper support. Instead they offered up some plugin APIs and unsurprisingly PGP / GPG ended up with half assed implementations too. Even fairly good extensions like Enigmail didn't integrate with the client as closely as they should.
And by this point cloud based email took off and crypto fell by the way side. If you want to use crypto in GMail then you have to cut and paste and clearly it's too much effort.
So I really don't blame GPG here. If the first thing an email did during setup was ENCOURAGE a user to create a key; and by default published that key; and attached the key sig to outgoing emails; and automatically looked up incoming email addresses; and automatically encrypted content when all recipients had their own key; and didn't hobble functionality for any of this (e.g. search still worked). THEN this wouldn't even be a problem. Encryption would have been the default and it would be an irrelevance if it was PGP or GPG was under the covers.
Damn him for putting his money where his mouth is!
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Enigmail is very easy to install and use in Thunderbird, and there are similarly easy plug-ins for other popular mail clients. It really isn't hard to set up and use at all.
What is holding adoption back is webmail. Until someone comes up with a really good solution for webmail the number of users will never get above some subset of the small minority who still use email clients.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
If you're comparing email to Facebook then you have a completely miss-guided view of one of the two applications. They are nothing alike, don't target the same group, don't do the same thing, don't do it in the same way, and don't do it for the same purpose either.
People have email to send text and small files around.
People have Facebook to send a one line message attached to the bottom of a picture of dinner with an Instagram filter.
Comparing the two is senseless. Facebook would actually have more in common with text messaging and twitter than email, and I don't know anyone who prefers to log in to facebook so they can write anything of length in a tiny square box in the bottom right corner of the screen when they could instead send an email.
>I like your black & white world; mine has too many shades of gray.
50 of them ?
Unicode killed the ASCII-art *
In short, everything except the fact that you're using the system.
Hey! I've had that signature way before those books were a mere itch in their authors' belt-beaten bunghole.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Oh I know, I'm a long-time slashdotter and have read your comments over the years - and they were mostly good, I just couldn't resist going offtopic for once to make that joke.
Especially since I think those books are terrible. They are about as representative of BDSM as the average Pentecostal service is and the writing is terrible too. Seriously the sentences read like the comments on a facebook post about a middle-school cheerleading competition, only with more spelling errors.
Unicode killed the ASCII-art *
The core idea is to toss messages around. I've done fido echomail, qwk and bluewave through bbses, email, usenet, and the one thing they all do is exactly that. The trouble lies in the crap people keep on putting in those messages. Even if it's not spam it's usually barely literate, unstructured, and generally a waste of time. I don't see facebook, youtube comments, twitter, whatsapp, etc. be more literate. The only difference is that they're geared toward shorter messages.
But you really cannot run deep discussions on stream-of-unconciousness derpage. You can see that in IRC: As soon as enter-fapping n00bs enter the fray, poof goes the content. You have to wait for that to die down so the more informed people start using longer sentences again and then the quality of the discussion goes up too.
It's no different with email. Using it poorly gives poor results. Most of us use it very poorly indeed. So tossing technology at the problem doesn't help, though it might illustrate the problem some more.
My fido and qwk mailers bitched at me for quoting too much. Now it's normal to stack up piles and piles of cruft with layers upon layers of quoting that nobody in his right mind wants to read. You might have to because you get pulled into a discussion and the other side is just not skilled enough to get you up to speed properly, despite having years of daily email use "experience". Even if the bandwidth cost is trivial, it still means lots of cruft in the old inbox and so a right drag to have to work through. Voicemail is a drag for similar reasons: A noisy channel and you can't just ask them to repeat what they just mumbled.
All the "alternatives" really aren't alternatives, but they have a major selling point in that the individual pieces are so small as to be seemingly effortless. That keeping up with all the little itsy bits now soaks up most of the day we carefully avoid to notice. It seems like less of a drag, but is actually more of one. You get done less useful work. It's a great way to stay distracted, though.
Want better email? Write better emails. Just stop quoting everything for starters, use your own archive and threading functions. If your software doesn't have that, get better software. if you want to get someone else up to speed there's a separate function for that, called "forwarding". New tools used just as badly aren't going to help. So start with learning to use the tools properly you do have.
That's not the problem with GPG.
The problem with it is that I could never be bothered to use it, not because of privacy (it would be incredibly convenient to send, say, a password required in an emergency via a verifiably-encrypted email) - but because it's such a faff. And it interferes with everything (searching, archiving, re-enveloping etc.). And to do so is all bolt-on-and-bodge-job methods. None of the major email clients offered anything like proper encryption by default.
And as soon as you get into using plugins, most people just won't bother. There are plugins for PFS for all your instant messenger programs, etc. - I had one installed for about 5 years, the only other person I know with one installed has a different, incompatible one. Now I don't use IM much any more anyway, so it's dead in the water.
And all email encryption is a ton of messing about with publishing keys in the right places, and having to verify against those places, etc. It's ugly.
The only place I've seen anything like GPG working is in package signing for third-party software. And there you have to download the package, download the key (either from the same website as the package - WOOP WOOP - or independently crowd-source a verified key), and then check it works. I've only ever bothered for Slackware, for which I believe the ISO images are signed with the official Slackware key.
GPG is just a pain in the butt and not automated at all. It's easier to compose and encrypt the message ENTIRELY OFFLINE and then send the encrypted text, and that shows you what kind of automation is missing, and what kind of trust system is actually in place.
Sure, there are plugins, helpers, hacks, extensions and all sorts. But none of them ever progressed to being "in" the software. Not even software designed to do nothing else but send email.
As an AC, you're a more probable expert on what NSA cock tastes like, so why don't you tell us?
Moxie has been in the trenches breaking drm to free our devices and thus has a good idea of what works & what doesn't.
Much like the "Real programmers" that bemoaned the death of really using the machines when we stopped programming directly in machine code, some will miss PGP, but not anyone who wants encryption to become widespread. PGP is convoluted and a poor base on which to build. We need to move on.
Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
webmail is ideologically incompatible with the very notion of secure communication that using encryption embodies.
To whit--
A webmail service holds not only the inbox itself, but also holds the contact list, and the presentation code. If one were to integrate encryption as well, then the webmail service would also have to manage keys, both private and public. Handing out BOTH keys is the very essence of insecure, but would be necessary. (The webmail service would need the private key to decrypt messages sent to you, coded with your public key, so it can display them! It would also need your public key if you wanted to read what was in your "sent" folder.) It would also need to hold all the public keys of all your contacts.
That's just one national security letter away from "Oh, sorry, we gave all those keys we had on file to the NSA, and couldnt tell you about it!" and one data breach away from a massive chain of trust catastrophe by identiy thieves (or worse).
Webmail is fundamentally incompatible with the very idea of secure communication of this type. This is something that you simply CANT put "In the cloud", because the main feature of webmail is being able to check it anywhere you can use a web browser. That feature goes away if the service does security correctly, and security goes away if the feature is retained. (To keep the keys outside of the webmail service, the keys would have to be stored on trusted workstations, or on a personal keystore on a portable device, like a USB keyfob-- Not all places with browser access will have provisions for this, and the added complexity will make users pissy. Putting the keys on the webmail server side fixes that problem, but destroys the security model fundamentally.)
There are secure webmail services where only the client can decrypt the message content. They are not perfect but the people running them are at least protected from being forced to decrypt messages since they don't have the keys.
Of course, you lose two of the most valuable aspects of webmail. You can't log in from any random location because you need to have a copy of your key on you. The service probably won't be free, because the service provider can't datarape your email account.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
FranÃois Truffaut, Jean-Luc Godard and Peter Bigdonavich were critics before they were filmmakers.
Roger Ebert was a screenwriter early in his career. He wrote Beyond the Valley of the Dolls, which is a strange movie but I cannot fault it's originality.
Don't blame me, I voted for Baltar.
webmail is ideologically incompatible with the very notion of secure communication that using encryption embodies.
Not really.
To whit--
No. That's one whit, or to wit.
Don't use words you don't understand. It helps. It really helps.
A webmail service holds not only the inbox itself, but also holds the contact list, and the presentation code.
The government already knows where you send your mail. They know where packets go over the internet. That's why they have taps at all the backbone providers, specifically so they can do that sort of thing.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
http://xkcd.com/1343/
I have determined that my sig is indeterminate.
The pedant pedant's antecedant was to see the point but fail to heed it.
Or
How getting bent out of shape over a simple and common mispelling exposes you as little more than a jackass that cant parse slightly malformed inputs.
------------
The government most certainly does track that messages were sent, and to what mail servers. (That's what they get at the backbone level). However, actually reading the messages sent requires a key. Correctly providing keys for security purposes implies a secure method of delivery-- such as sneakernet. Something that unless the government has developed ESP, they will not be able to obtain without a warrant, which requires probable cause/evidence to have issued, which would require that they have readable documentation and evidence for a specific criminal activity. Simply transmitting and recieving encrypted data is not a crime, and so they shouldnt be able to get one for that purpose.
The NSA and pals like to abuse national security letters to get things that they cant get warrants for, like fishing expeditions like the proposed problem. They would have to issue a national security letter to the key holder (The person sending the messages!) to get the keys, which would of course, alert that person that they were being investigated, which is counter-intuitive to their investigational process.
Basically, while they can hoover up the encrypted message bodies, unless they have the keys, they have to invest considerable resources to decrypt the messages. When coupled with widespread adoption, this makes the bulk collection methodology too costly to be viable, which is the whole point.
Putting the keys on the webmail server allows the NSA to send that central point of contact a single national security letter demanding those keys, without alerting the users of that service that their security has been compromised. This is against the purpose of having secure communication.
I was saying all this 14 years ago.
FOSS Encryption is a mess. It is basically impossible for a regular user to set up encrypted mail.
I'm an expert, and I never even managed too. (The K-Mail crew basically lying about their GPG-features didn't help back then)
First things first, there are easy button ways to create your keys. I used GPA for my first key, but that's deprecated/no longer used. We have KGPG and Seahorse now. (Seahorse might be the Passwords & Keys application in your menu)
But it's not that hard to do it on the command line. All you do is:
[code]
gpg --gen-key
[/code]
Then follow the prompts/instructions, which are actually fairly clear with reasonable defaults.
Then you need an e-mail client with good support for it. I personally recommend either Claws-Mail or Thunderbird with the Enigmail plugin. Then you follow their details on how to set up the e-mail client for gnupg.
What is holding adoption back is webmail. Until someone comes up with a really good solution for webmail
The solution is to use a proper e-mail client with your webmail service. I use gmail but I use it via IMAP with a real e-mail client.
That isn't really any better. Either the client has to have software the webserver does not control ( and then its not web mail anymore ) or you a couple of minor alterations to the Javascript that runs the thing from the client just posting the private keys back up to the server or anywhere else.
So if the service is compromised by an attacker be with an NSL or some technical means and they can alter the application even slightly you are totally boned.
Either you need to personally be in control of the content, keys, and client or they at least need be in the control of separate entities for you to have any hope whatsoever of a secure solution.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Oh I know, I'm a long-time slashdotter
I must be getting old when 7-digit UID"s are long time slashdotters. Get off my lawn! Hot Grits! CowboyNeal! Beowulf Clusters of Libraries of Congress!
Especially since I think those books are terrible. They are about as representative of BDSM as the average Pentecostal service is and the writing is terrible too. Seriously the sentences read like the comments on a facebook post about a middle-school cheerleading competition, only with more spelling errors.
The reason for that is obvious when you know that 50 Shades of Grey started out as Twilight fan-fiction.
How getting bent out of shape over a simple and common mispelling exposes you as little more than a jackass that cant parse slightly malformed inputs.
You have to be spectacularly stupid to believe that someone can't parse malformed inputs when they provided the correct substitution. But I knew that about you.
Putting the keys on the webmail server allows the NSA to send that central point of contact a single national security letter demanding those keys,
And isn't required for encrypting webmail. Don't be such an idiot.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
>I must be getting old when 7-digit UID"s are long time slashdotters
This is not my original account. I lost the access to it somehow during a leave I took a few years ago and ended up creating a new one. My original account dated from 1998.
>The reason for that is obvious when you know that 50 Shades of Grey started out as Twilight fan-fiction.
That sounds remarkably likely :P
Unicode killed the ASCII-art *
Yeah. If only there was an easy to use end2end encrypted mobile phone application for voice calls that Moxie had been involved in creating.
https://en.wikipedia.org/wiki/...
Indeed. Moxie is quite good. But he is wrong here: GPG/PGP is about as simple as you can be and still offer strong security. It can be put into wrappers for a little decrease in security and some increase to usability, but that is it. In security, you cannot make a hard task simple. That is not possible without massively decreasing security.The same thing happens when you say learning to read and write is too hard. Sure, speech recognition and synthesis does allow some help, but you will never be able to use a pen or a keyboard, and it does not help you at all with deciding what to write and what the meaning of some text is. This is a hard task as well, and cannot be automatized away.
The fact of the matter is that it takes real effort to learn to use encryption securely and that nothing can be done abut that.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Since the parent was a Linux user (obviously since they mentioned Kmail), I didn't feel the need to do a complete step by step detailed tutorial.
besides, doing either:
[code] sudo apt-get install seahorse claws-mail thunderbird -enigmail kgpg[/code]
or [code]sudo yum install seahorse claws-mail thunderbird-enigmail kgpg[/code]
Really isn't that hard. Just found out GPA isn't deprecated, updated version is available...it's not in the Fedora repos though.
And yet you contine to be bent out of shape about it. Fancy that.
----
I already addressed this. TWICE.
The option is binary. Either the webmail server has the keys, or the messages are decrypted on the client side using keys stored on the client side for presentation.
If the keys are stored on the wemail server, the NSA can demand them.
If the keys are stored on the client, then the main feature of webmail is broken.
They keys have to be stored SOMEPLACE for the messages to be encrypted and decrypted. The primary statement in my postings has been that properly secured encrypted email is not compatible with the use case of webmail. Webmail's use case is "email access that is independant on client platform, as long as a suitable browser is present" As soon as you put the keys on the client side, this goes away, because now the browser has to probe the local filesystem for the key store, or the browser itself has to have the keystore. This has all the problems of Enigmail for Thunderbird, (Or the GPG plugins for any of the other capable mail clients out there.) The keys are stored on a trusted workstation, that you cant just lug around with you-- OR-- if stored on a keyfob, accessing those keys requires extra steps above and beyond just logging in and checking your mail. This breaks the use case for webmail.
Rather than being an argumentative troll, you could explain your position instead of arguing impotently. Instead, you chose to complain about spelling mistakes, confabulate, and hurl ad-hominems.
To return your trite quip, I already knew that this is what you would do. Resorting to arguments about improper grammar, spelling mistakes, or improper word use is the hallmark of somebody with nothing of real substance to contribute, who instead just likes to feel superior. Congratulations.
And, of course, the whole thing is dependent on fixed servers which Moxie claims aren't easily replaced. Just like TextSecure on Android depends on Google's servers to function.
So the advantage over GPG is that the entire communication process can't be abstracted onto any other communication protocol (GPG on email/SMS/paper slips/etc), but depends on rickety infrastructure provided by somebody else. Progress!
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
Agreed. The CLI of gpg is horrible. There are some semi-acceptible GUI variants, not least Enigmail, and a good UI is is definitely going to be required if you are going to get general acceptance.
But the main reasons it continues to not get used are
0) Math* is hard!
1) The rise of webmail
2) Inverse network effects
* encryption being a subset of math.
0) It's hard to explain to people that they need encryption, how it works, what it is. People think email is secure! The "envelope" iconography is very misleading - email is more like a postcard, delivered by a random selection of disreputable postmen.
1) Webmail makes it much harder to do encrypted mail because to make it secure you'd have to install browser plugins. None of the webmail providers want to make one, because it will destroy their revenue stream of monetizing the analysis of your mail traffic.
2) If you want to actually use (G)PG(P) your recipient also has to grok it, install software to use it, and you have to exchange keys. This is a massive hurdle to overcome for all but the most dedicated cryptonerds. Until there is a majority of people who want to use encrypted mail, that will carry on being the case.
There are projects attempting to overcome some of these hurdles ; you have the likes of keybase.io that takes some of the sting out of key exchange (and verification).
But!
Until encryption comes with the communications software you are using out of the box, is enabled by default, interoperates with everything properly, and forces you to configure it to even use it, the vast mass people won't use it. And this is well known by the SIGINT agencies who view people actually using encryption AT ALL as a red flag that they should look closer at.
If it's so easy to use that people will actually _use_ strong encryption (end2end - who cares if there are central servers passing on the encrypted data) then yes - why not?
I fully agree with Moxie - and I'm hoping to get a lot of people to move from Skype to Wire. It might only be end2end encrypted for voice calls - not the text/group chats - but it's a lot _better_ than the alternatives, with a UI that has a chance of getting wide adoption.
More of the world's communication will be secured. That's progress.
it's in my head
If only there was an easy to use end2end encrypted mobile phone application for voice calls that Moxie had been involved in creating.
Too bad that his apps depend on proprietary Google software, so it's clearly not in the same ballpark as GnuPG.
OS Reviews: Free and Open Source Software
0) It's hard to explain to people that they need encryption, how it works, what it is. People think email is secure! The "envelope" iconography is very misleading - email is more like a postcard, delivered by a random selection of disreputable postmen.
This is incorrect at this point, I'd say it's more like a postcard pinned to a bulletin board in the hallway, with everyone passing being required to take whatever cards are going to where they are going, with the requirement that multiple copies be made and dropped at every corner on the trek. That's probably more accurate as an analogy of today's email situation. The implication being, obviously, that email is visible to everyone on the trip, and copies are made and kept.
As for the rest, there are ways around a lot of that, but we're not there yet. Your analysis of webmail is spot on, webmail as it lives today should die a very very quick death. The sooner, the better.
The cesspool just got a check and balance.
The Web Of Trust should make TLAs subversion near impossible, if correctly used.
There's the rub. How are you sure that nobody whose key you have signed in the past has since been compromised by the NSA, by Alzheimer's dementia, or by some other affliction that breaks the assumption of "correctly used"?
Not remotely. He's encouraging good encryption, but calling for some updates (it hasn't significantly changed since the mid-'90s) and a better wrapper. GPG is still largely by geeks, for geeks. I couldn't get my parents to use GPG because they'd dismiss it as too hard, even if one of them is happy to stick it to the man. The suggested minimum settings vary based on where you look and when they were posted.
Example: An RSA key size of 2048 bits is largely considered secure, but NIST recommends 3072 bits for anything that one would want to keep secure into the 2030s. People still often see their e-mail as their private papers and may be concerned over who can read them well past the 2030s. But does that mean they use 3072, or go with the random crypto weblog guy who says to always go with 4096? And why can't I create 8192- or 16384-bit keys like that software claims to over there?
And what to hash to use? Plenty of sites still say MD5, but they were written years ago. Some have updated to SHA1, but others point out weaknesses there. OK, SHA2, then. But then there's SHA256, which must be better, right? (I know SHA256 is a subset of the SHA2 family, but those unfamiliar with crypto will not.)
Until GPG-style crypto becomes relatively automated, it won't be embraced by more than a handful of people. HTTPS is widely used because people don't have to think much about it. This has some downsides for poorly-configured servers and Superfish/Comodo-style backdoors, but browsers and other software help take up the slack by rejecting poor configurations. PGP/GPG were designed to reach near-perfect levels of encryption, but that bar is clearly too high for significant uptake. We should instead be looking for something that encourages end-to-end encryption that is good enough. We can build on if the underlying structure is properly designed, and as people get more accustomed to crypto in their lives, they'll be able to adjust to improvements.
When the majority of communications are relatively well-secured, it makes it far more difficult for a surveillance state to conduct its operations. Perfect security can still be a long-term goal, but we need more realistic goals to encourage uptake in the meantime.
You can never go home again... but I guess you can shop there.
There are two items when people mention PGP:
The OpenPGP format.
The PGP implementation applications, like archaic PGP versions, NetPGP, APG, OpenKeyChain, GNU Privacy Guard, Symantec Encryption Desktop, and a number of others.
As far as I know, all the above have their source code available under various licenses, even the Symantec stuff either has, or used to have, its source available for examination.
I do agree that a revamp in some of the OpenPGP implementation programs is direly needed, because as of now, the most usable implementation (IMHO) is Symantec's version, which is a commercial product.
It might be nice to see about breaking the OpenPGP implementation programs up into to parts -- two library frameworks (one for BSD, and one for GPL v3), and the code that accesses the libraries.
As for the OpenPGP format itself, it does need some incremental improvements:
1: Additional encryption and the ability to chain encryption algorithms. This isn't meant to win a bitsize war, but so that if one algorithm like SERPENT gets broken, there is still AES and Twofish. TrueCrypt implements this.
2: Splitting how much you trust a key versus how much you trust a key's owner to sign, introduce, and validate other people's keys, with both of these values exportable. This way, if you are 100% sure you have a key of a cretin, you can pass that along.
3: Newer compression protocols like LZMA2, bzip2, and others, so that data is further shrunk before encryption.
4: An error correction protocol applied after encryption and signing, with a user selectable amount of ECC applied. This way, a signed OpenPGP file that suffers some damage can likely be repaired, and the signature still be valid.
5: Share splitting. This way, a user can select x out of y pieces be required to recover an OpenPGP packet.
However, all and all, the OpenPGP protocol has stood the test of time when it comes to security. Its main strength is that it is not tied to a communications or messaging protocol, so an OpenPGP packet can be sent on a file on a SD card, via E-mail, AIM, SMS, MMS, posted on a newsgroup or forum, or virtually any other means. There are people who bash OpenPGP, but oftentimes, they have their own solution, and have a vested interest in getting people to leave OpenPGP for a closed system.
OpenPGP fills a crucial need. Not just securing data over communications, but protecting data stashed away. Few encryption protocols can secure both data at rest, and data in motion.
I agree GPG is an unwieldy tool at best, I have tried since 97, on and off to use it. It is only now that I turned to emacs that a simple enough wrapper for me makes it usable. Yes you heard that right it took emacs to bring GPG in to my life.
I must be missing something. The standard used by anyone who wants to attempt secure encryption is GPG. I missed what Moxie is recommending as an alternative. What will whistleblowers use if GPG was to go away? I've worked at Microsoft for 15 years but I've also used GPG for a long time and I don't list my keys on a keyserver usually but instead hand people my business card which includes my fingerprint. Other people I know do the same thing.. Does any software encryption protect against hardware/BIOS/emf attacks? No. But someone has a chance of doing effective encryption on an offline computer and copying the encrypted content to another device to send it to someone else. I'd like to see GPG updated to add clean API's. I'd also like to see the code audited by open source and security advocates. I'd like to see products layered on top. Why not try to get Microsoft, Google and Apple to commit to support it in their products directly? That would be smart strategy. Full disclosure: I've previously voted to provide a small grant to PGP and I've also contributed $100 directly to the project to help keep it afloat. PGP 86FA 7F05 C665 5F7B 3CC4 0C40 FA84 2649 1A61 20DE
Unless you can deploy it widely, like Moxie did when it got the Textsecure protocol integrated into WhatsApp for Android. In my country, there are 9,3 milion WhatsApp account for 17 milion people. No serious security service can claim all those 9 milion are propably terrorists.
Store the private key on the server, but encrypt it using a key derived from a passphrase. Script would then fetch the encrypted private key from the server and decrypt it using the passphrase entered by the user. The NSA would have to crack your passphrase to get your private key, just as it would if it seized your workstation.
The solution is to use a proper e-mail client with your webmail service.
Do they even make "a proper e-mail client" for, say, a PlayStation Vita system? Sure, there's the included Email app, but I didn't see anything in its manual about PGP or S/MIME.
Even though GPG has been around for almost 20 years, there are only ~50,000 keys in the "strong set," and less than 4 million keys have ever been published to the SKS keyserver pool ever.
I've been using GPG heavily for as long as it has existed, but I have never published my keys to the keyserver pool, and probably never will. I suspect I'm far from the only one. I think that his metric may not indicate what he thinks it does.
If the client sends mail to the server over an encrypted connection, and the transport servers all communicate over TLS, and the receiving client connects to its server over an encrypted connection, the message will be pretty secure from prying eyes. The problem is that the big guns (Google, Microsoft, Yahoo) aren't willing to pull the trigger and accept TLS only connections. The first step in getting better encrypted communications is to upgrade every system to be able to understand the latest TLS.
Of the hundreds of people I exchange email with, about four regularly use encryption. Even amongst people who value privacy, GPG use is rare. It doesn't seem like it should be hard, but it is, and there are some confusing things about it. For example, adding a public key requires closing and restarting the email app for it to work, but there isn't even a popup that notifies about this. Recipe for frustration and rejection.
What changed under Obama? Nothing Good
You want the impossible. You want communications you can trust without having to understand how they happen. The usual compromise is to the Other Guy TM take care of the security for you, whether that's a dumbed down interface or cloud hosted services. Everyone's already doing this: its called Google and Facebook. It turns out the Other Guy TM isn't always so great at protecting you in all situations. So now you're back to square one: how do I have secure comms without needing to understand what's happening?
First, the complexity of the engine shouldn't matter. You will never get the bulk of users out there to use, or care about, the real power of the engine. They don't want to mess with the engine. The engine should be under the hood, in a black box, whatever engineering metaphor you want. Users just want things that work.
I remember way back when I was at university. There were various absolute rules for good software engineering. The first was that the user should be presented with a must-read manual no longer than one paragraph. Tips and tricks could be more extensive, but that one paragraph was all you needed.
The second was that the user absolutely must not care about how something was implemented. In the case of encryption, I take that to mean, in the case of e-mail, that the engine should not be visible outside of configuration. A supplied key should trigger any behind-the-scenes compatibility mode or necessary configuration to talk to that user. If the keys the user has aren't suitable to correspond with that person, the system should ask if one is needed and tie it to that protocol.
There should be no extra controls in e-mail, except at an advanced user level. If a key exists to correspond with a user, it should be used. If a key exists for inbound e-mail, the key should be applied. The process should be transparent, beyond getting passwords.
Any indexes (particularly if full indexes) should be as secure as the message, good security practices on both will take care of any issues.
Ideally, you want to have the same grades of authentication as for the early certification system, adapted to embed the idea that different people in the web of trust will have done different levels of validation and will be trusted to different degrees. The user should see, but not have to deal with, the level of trust.
Last, GnuPG is probably not the system I'd use. Compatibility cruft needs to be as an optional layer and I'm not confident in implementation.
There should be eight main libraries - public key methods, secret key methods, encryption modes, hashes (which encryption modes will obviously pull from), high level protocols, key store, index store and lacing store. (Lacing is how these are threaded together.) The APIs and ABIs to those libraries should be standardized, so that patching is minimally intrusive and you can exploit the Bazaar approach to get the best mix-n-match.
There should also be a trusted source in the community who can evaluate the code against the various secure and robust programming standards, any utilized theorum provers and the accepted best practices in cryptography. Essentially replicate the sort of work NIST does, but keeping it open and keeping it free of conflict of NSA interest.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I must be getting old when 6-digit UIDs are long time slashdotters. I for one welcome our newbie overlords.
enough to be easy to use. Right now I'm trying to get a full featured Lua system working on windows using only free stuff (no MS compilers), and THAT'S a pain because a lot of the libraries just barely build on windows, only with tweaks, and you still have to get them glued together right.
It's surprising how much software has the "it works, or some version did.. you just have to tweak it enough" problem. So GPG has an unreadable manual and you had to have a friend tell you how to set it up. Let's face it, that's the difference between free software and commercial software. The commercial software has enough people working on making sure that users can set it up easily.
While I did generate at my first gpg key on a PS2 Linux kit, that's a serious edge case there with that vita statement, tepples. There ARE clients with gpg support for Android.
You want the impossible. You want communications you can trust without having to understand how they happen.
See, there's the rub. Perhaps 10% of the geek community even _think_ they know how this stuff works, of which perhaps another 10% of that group have a reasonably up-to-date knowledge. Which would probably work out to 0.1% of the PC/phone/iThing/tablet-using public.
OTOH, we see people of all intellectual persuasions, most of whom haven't a clue how their cell phone works. But they are successfully using a device which has built-in encryption (which could probably be better, but that's aside the point) for their phone calls, without any significant setup other than buying the phone and providing certain details about themselves. So some level of trusted communications _can_ be provided without everyone becoming a geek, but (as you imply) it does require some kind of industry agreement - and government acceptance - to provide an uncompromised solution. And I think that is essentially impossible as long as we have even a few "bad guys" (for any definition of "bad guy") out there.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
I think that most agree that the biggest issue with end to end encryption adoption is mail client integration which at present its ridiculously bad.
One way the community can tackle this is to push for Mozilla foundation to work on a cross platform Thunderbird Mobile client and include GPG or similar encryption scheme baked into the core. With a mobile application and better working GPG encryption integration in desktop Thunderbird, many more would start using Thunderbird with encryption for all their communication needs and be able to drop the use of thin client apps from their usecases.
I don't think that commercial email client vendors, thick client or thin, will ever adopt end to end encryption unless end to end encryption is the primary selling point *and* the in such a case it must be fully cross platform (desktop and mobile) to be useful.
If you use Ubuntu or Debian, then you are using it every time you do an apt-get update to verify the resulting software lists (which includes the hashes of the software itself.)
No, those who want perfect solutions want the impossible. I want a framework that can be improved over time.
What's the goal? With maybe a handful of exceptions, everyone does something that can compromise their security. HTTPS relies on a trust architecture that we're being reminded recently (Superfish, PrivDog) is actually extremely fragile. And yet it's being encouraged to make the job of the average surveillance tool more difficult. It's very much letting The Other Guy(TM) (remember, three caps minimum on the TM'ed stuff) handle security. It has flaws, but it raises the bar.
That's what we need for end-to-end crypto. It can have flaws, but it needs to raise the bar, and be able to keep raising the bar.
As for understanding how it happens, how many people can describe how an RSA key is generated, much less how a proper PRNG produces a suitably random number and then how AES/Blowfish/whatever encrypts the data? Does the average person need to know that? Not really. And even if they did, they don't care, which is why they don't use it now.
Right now, we have options where you can let a CA provide you your TLS certificate (usually 2048-bit and SHA1). If you know what you're doing, you can roll your own with better security. We need something with that flexibility (though I recognize the flaws of that exact model) for end-to-end crypto, too. We need clients that auto-update, that add or deprecate algorithms as they arrive or are broken without the user having to worry about it, and that can provide safe (and revocable) storage for the keys so they survive a catastrophic loss or be deleted with near-absolute certainty if the user wishes. We need common libraries or protocols that can allow new or existing clients to safely implement connections to these services without having to build them from scratch, thereby preserving and encouraging competition.
These don't lead to a perfect system. They lead to a good enough system with room to grow and improve. But I would argue (as I think Moxie does) that what we have now is far from a perfect system because it's too difficult to use.
You can never go home again... but I guess you can shop there.
Where is a 3 digit grey beard when you need him. Note: not sexist; just assuming female grey beards are few and far between.
@Random_Adam
Sometimes a sig doesn't have to be funny!!
So then you're saying that it's not a matter of actually implementing secure communications, but adjusting expectations so that whatever we have is seen as secure by the people using it.
Everyone has and uses cell phones, but the encryption is weak and the implementation isn't end-to-end. Cell phones are emphatically not a medium for secure communications. If that's the stick by which we measure successfully deployed secure communications systems, then let's just declare Facebook to be secure and move on.
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
So then you're saying that it's not a matter of actually implementing secure communications, but adjusting expectations so that whatever we have is seen as secure by the people using it.
No, I'm saying that it is possible to make a system that is, at least for most purposes, both secure and not dependent on geekly knowledge. Using the cell network as an example, while the encryption actually used and the security model is not great for most cell networks, from what I've read the Blackberry's model seems to be pretty good, and some version of the Blackberry is, AFAIK, still in use by the politician in the White House, who "couldn't live without his Blackberry" and is certainly by no means a geek or significantly knowledgeable about how to implement or maintain a secure channel. Of course, we don't know how much or what kind of work was necessary to vet and maintain the system in that case - but it's significant that governments including the government of India were at least talking about blocking all Blackberry traffic unless the company allowed them access to the keys, or put the servers inside the country.
There are also other systems that, _once set up_ for a company, for instance, seem to be pretty transparent and easy to use for the employees. I suspect that in those cases as well as the Blackberry, there is a significant effort for the support and IT people to set up and maintain such a system, but that's OK. I just don't think it's right to tell some poor slob with a bad excuse for a high school diploma to become an expert in how to maintain the security on their phones. It's worth noting that historically (back in the paper mill days) janitors needed to have the highest security clearances in government installations, for pretty obvious reasons.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
GPG doesn't give end-to-end encryption. It gives at-rest encryption. It's for encrypting arbitrary files or chunks of data - but doesn't provide a way of delivering that data (like The Onion Router project does, or even a VPN does.)
The problem with that is in your email app. My personal experience is that I did need to work about 2 hours (distributed over a year or so) to get GPG integration in Mutt to work right, but it has worked nicely for the last 5 years or so.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
All good points if you're stopping run of the mill hackers or snoops. Some people are worried about Five Eyes, China, Russia, and other High Strength Attackers. Author misses that the only proven approach to surviving them are high assurance security engineering and/or obfuscation + diversity + battle-hardened software. There's no H.A. FOSS for this so gotta do the latter. GPG is specifically mentioned in leaked slides as a pain in the ass for NSA: true going back to Zimmerman's PGP. GPG also runs on many hardware architectures and buying old hardware (esp RISC) is a good way to dodge any subversion programs that are going on. So, the best route to high security email is GPG + FOSS OS + diverse, old hardware behind a guard for interface level protection and preventing them hitting the lowest (weak) layers of the old system. Easy to use, cheap, and pretty? No, but high security setups rarely* were.
This, with contractor developed implementations, is one of the ways the NSA's own black programs protect their information from their opponents. Same is true for Five Eye's. So, it has both stopped them and they rely on similar approaches. That's best endorsement an encryption product can get. That so few people use it has more correlations to NSA SIGINT effectiveness than GPG's. ;) So, per INFOSEC history's lessons, we let people develop (and PROVE!) better solutions that don't have GPG's problems. Meanwhile, we use GPG, improve its interface, and make solid workarounds to any issues with it that don't violate security arguments. Only new scheme I've seen with strong security properties is Tinfoil Chat. Everything else usually has a weak TCB allowing bypass or an unproven design/implementation they might covertly beat. I'll stick with what works until situation changes.
*Note: Capability, tagged, and language-based methods can be nearly identical to insecure product in functionality with better, easily-done security. They're the exception, though.
Nick P, Security Engineer/Researcher (high assurance focus)
Start by uploading the public key to the keyservers and putting it here:
https://slashdot.org/users.pl?...
Don't worry too much about the WoT, though carry around your key fingerprint with you so if you ever meet a gpg user in person you can show them that, they can copy it and then get your key. And sign your e-mail.
I'm an expert, and I never even managed too.
No, you aren't ... because:
E-Mail needs a complete redo/replacement with hard asymetric encryption and zero-fuss key handling and exchange built in as a core specification.
Its called S/MIME, look it up, expert.
Not all messages need to be encrypted, thats stupid. If you think Fidonet was so awesome compared to SMTP then I'm 100% certain you don't know jack shit about how fidonet or SMTP work under the hood, and I can safely assume this because you also make no actual example of why fidonet is 'better'.
Let me go ahead and quote official fidonet policy, which basically says using encryption is not allowed and that everyone along the path SHOULD BE ALLOWED TO READ EVERY MESSAGE:
2.1.4 Encryption and Review of Mail
FidoNet is an amateur system. Our technology is such that the privacy of
messages cannot be guaranteed. As a sysop, you have the right to review
traffic flowing through your system, if for no other reason than to ensure
that the system is not being used for illegal or commercial purposes.
Encryption obviously makes this review impossible. Therefore, encrypted
and/or commercial traffic that is routed without the express permission of
all the links in the delivery system constitutes annoying behavior. See
section 1.3.6 for a definition of commercial traffic.
Thats from http://www.fidonet.org/policy4...
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
from what I've read the Blackberry's model seems to be pretty good
Bruce Schneier put it perfectly - everyone wants you to be secure, just not from themselves. So Blackberry's model is great, safe from the government of India. But not safe from Blackberry and anyone capable of twisting Blackberry's arm. Don't worry, government of India also wants you to be safe - but not safe from government of India.
Google's security model is also very awesome. But Google's users are not safe from Google and anyone capable of twisting Google's arm. Microsoft's security model is also very awesome. But Microsoft's users are not safe from Microsoft and anyone capable of twisting Microsoft's arm. Such security has already been achieved some years ago, and it is demonstrably meaningless.
As long as you continue define as "secure" as something absolute, the security is meaningless.
Now show that it is possible to get meaningful security without understanding a lot more about security than the gadget freak joe sixpack.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
Well put. I work for a company that provides a secure "Proof of Knowledge" support for web logins. (Proofs of knowledge include text passwords, picture passwords, Captcha, etc. - things that require personal knowledge or cognitive self-tests.) The security model for this SAAS is highly motivated by user privacy and security concerns. The actual proof - the password, or whatever - is encrypted into a hash in the browser, and stored as a doubly-encrypted hash in the server. The SAAS never knows the user's identity, only an encrypted code that identifies the user to the requesting website. So connecting the user, the website's user ID, and the proof requires hacking or compromise of all three pieces of the puzzle.
It is even possible (though we haven't rolled out this capability to production yet) for the actual challenge to be encoded by the user in such a way that it's impossible for anyone but the user to even know what the test to be performed is. I won't say how this is done, as the patent is pending.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
Not among the dwarven folk!
To
It's not a cop-out. How many people put off or refuse to do day-to-day responsibilities at home, preventative care for themself, maintenance on vehicle, checking on PC backups, and so on? Varies per person but happens a lot. People will also opt out of even an easy to use tool because of a single extra step. Web research shows a web site taking just a few seconds too long to load will cause a huge chunk of business. Such things show that people's very nature is to take on risk rather than put forth effort. This can't be ignored in a security, usability discussion or design attempt. People will only protect themself if it takes *almost zero effort* and will otherwise let themselves be devoured by digital wolves.
Note: Zynga doesn't count because it's just a game that they *want* to play as an *escape from work* and other things. Security in day-to-day apps is something they *have* to do they usually see as *an obstacle* to fun. Totally different. Although, Zynga's psychological tricks might be copied.
The bigger effects, though, are legacy and networking. The legacy effect says the new thing must build on or integrate well with what's already invested in. Lead to all the COBOL, SAP, and Windows out there. Builiding security on something inherently so insecure without vendor participation puts a limit on both security and usability. We see something similar with Facebook's hold on people after they've put so many photos, comments, shares, etc into it that they don't know how to move. Both companies and individuals simply will not let go of a broken-by-design product to get even the most usable, secure-by-design products. This issue is unresolved and it's why I think the better stuff can only take hold for *new* deployments + niche that will give up bad stuff.
The networking effect is illustrated best by Facebook. They start as just a social media site. All kinds of people start using it. Now, people start using it because others are using it. Their API let's all kinds of third parties and services develop that people start using. A whole network and platform of people, apps, and so on. Problem 1: how do you get them adopt something similar if nobody they know is using it? Problem 2: how do you get the 3rd parties to build similar effort into your platform if nobody is using it? Problem 3 (for non-snooping): How can you do anything like this without the billions in ads that paid for Facebook and esp while solving 1 & 2?
So, in summary, human nature has always worked against even the best efforts. There are very usable apps out there right now for private communication, storage, etc. Threema, Silent Circle, SpiderOak, ZixMail/Hushmail, and so on. Apps do almost all the hard things for you inexpensively. Threema is only $1 more than WhatsApp. Pop quiz: how many people buy these over the insecure alternatives? Now you know how much the users care. ;)
Nick P
It's not a cop-out.
It's a cop-out if you say "laziness" as if it explains anything. That's like the police finding a crime scene and concluding that the gun killed the man, and then packing up their things and going home.
We need to figure out why people are lazy and check if we can address it. Maybe we're making it too difficult?
Here's an example: Backups. Even I didn't have a good backup regime until Apple came up with Time Machine. It's just too much stupid work. But someone sat his ass down and asked the right question. And that's not "why are these fuckers so fucking lazy?", but "how can we make it easier for the users?".
they usually see as *an obstacle* to fun
That exactly is the point. If people see our work as an obstacle - maybe every once in a while we should climb down from our high horse and admit that they could be right?
Threema is only $1 more than WhatsApp. Pop quiz: how many people buy these over the insecure alternatives? Now you know how much the users care. ;)
Messaging apps are driven purely by networks. If all your friends switched to Threema, you'd do it too. If nobody does it, you're unlikely to be the first. Security doesn't matter enough to lose contact with all your friends.
Assorted stuff I do sometimes: Lemuria.org
Time machine and backups are a good example of solving a usability problem. Thing is, much in INFOSEC or COMSEC needs a person in the loop to supply a secret or make a trust decision. GPG, for instance, forces you to think about keys because that's what you're trusting (not the person's name). Even if we simplify everything, the user still has to search for someone's name in a key database or click a link on their site. They might need to decrypt their private key. Then, they can see messages sent by that person automatically. Much simpler but still adds extra steps and time that people don't like.
Another example of the legacy problem is in more secure workstations. Every desktop OS is insecure. If you want security and desktop apps, the only known way to do it is a SKPP-style kernel separating them with a trusted piece of software for moving data between partitions. This is because security engineers can't control Windows or the apps. So, the user will have to tolerate loading up several VM's, switching between them for different types of work, and waiting for trusted apps to move (and check) data flowing through partitions. I can make the VM's start quick, have VM's pre-built, have drag n drop on domain transfers, and so on. Yet, simply hitting a key to change VM's or manually sharing a file between them is intolerable for most people.
So, you keep saying the INFOSEC people just need to build something that's secure and as easy to use as existing stuff. INFOSEC *has been doing that*. Especially in appliance market. Sidewinder firewall internally had SELinux-style protection while being easy to use. IBM's System/38 was easier to use, integrated core functions, and had security. Secure64 DNS is easier to use than many while defeating top red teams. There are many encryption products that are very simple and cheap. DefenseWall and Sandboxie both made HIPS *super* easy. In every case, the product is a tiny, minority player in the market where insecure options flourish. Lazy or lack of due diligence is my theory given the products are usable and affordable for their target markets. What's your theory?
"Messaging apps are driven purely by networks. If all your friends switched to Threema, you'd do it too."
"AND THE TRUTH... WILL SET YOU FREE" (Jim Carey, Liar Liar)
With that, you just totally contradicted your own position, supported mine implicitly on GPG, and supported mine for messaging apps in general. I argued GPG could improve to perfect usability and still would have no takeup. I said it's because users (1) use what other people use and (2) don't care about security. You agree on the network effect. For the other, what's one thing every famous messaging app or service had in common? No attempts at security for maximal convenience and cost-efficiency. People didn't care. Marketing departments aren't going to put massive work into security enhancements they see no demand for. Many companies tanked trying exactly that, with Intel losing over a billion on theirs. It's the user's and market's fault: they always kill off secure systems regardless of usability.