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."
Show us your work. Talking is easy Moxie: PRODUCE SOMETHING USEFUL.
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
In today's society, using cryptography only means ending up singled out for some unpleasant stuff. Ending up as an unemployable martyr because I can't board a place is not something I can afford. This is the Surveillance Age, deal with it.
Which is the point, easy to bag GPG, but what do you have that's better ?
Discouraging good encryption, as with TrueCrypt?
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.
So when can we have end to end encryption on whatsapp for iOS in that case?
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.
DUMBER NAME THAN BENNETT HASELTON. Filter error: Don't use so many caps. It's like YELLING.
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!!!!!
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.
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?
How would you propose email's user experience be improved?
A/K/A Sammy van Hagar?
If you knew how FidoNet exchanged email amongst it's nodes, you'd realise that SMTP is superior in it's simplicity.
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.
I imagine that % of Slashdotters who use PGP is higher than the norm. The real issue is that people either don't believe in privacy, or have long given up on it, or are happy to trade it for security. And, people are dumb. We're talking about a nation of people with 00:00:00 still blinking on their VCRs. Private/public key encryption? A password trickier than 'joshua5' ? If it doesn't magically work like the Matrix, nobody is interested.
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.
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.
Is non-FOSS better? The only paid email encryption solutions other than S/MIME (which is also available in FOSS flavors) I've seen are all configured to allow anyone who can intercept messages on the account to decrypt any message sent to the account, which seems fairly useless.
The basic idea is here: https://github.com/kechel/secure-messenger-protocol/blob/master/secure-messenger-protocol.txt
In short, everything except the fact that you're using the system.
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.
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
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.
Solid, prove, dependable software is not exciting enough for whiny hipster.
"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."
And one national security letter later, that requires the 'secure' webmail provider to serve a trojaned JS file to certain users of interest, and the local key is compromised...
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
Come up with an alternative then. Pissing in the wind then moaning your shoes are getting wet is your own fault. FOSS is just a licence, prick.
Wow that is really easy. All I need to do is get Claws-Mail (or Thunderbird and install the Enigmail plugin). And then follow their details. Oh and get GPA? Wait no, its deprecated? Oh so I can get KGPG and something called Seahorse? It might be on my menu somewhere?
So easy!
Within my organization, I can sign and encrypt email. It is easy to use, I have a smart card and a PIN. To sign, I click a button, and there's a central database of people's public keys and I can encrypt email for them alone to decrypt.
However, I presume my organization has the capability to decrypt any message sent using their infrastructure. It is THEIR infrastructure after all, not mine.
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.'"
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.
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"?
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
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.
grown grammar nazis learned to write the painful way ... that is .. it got beat into them when they were kids : ]
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)
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.
So, does that mean it is possible that a secret agency is trying to get people to stop using GPG, as seems to have happened with TrueCrypt?
Furthermore, the actual, underlying problem is E-Mail.
This.
Great, now I have a key pair and a plugin for my email client.
Now for the hard part, how do I get it on the web of trust? My friends and coworkers aren't established GPG users, and I don't think anyone has held a key-signing party since about 1997...
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.
We remailer sysops can't do without it.
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.)
https://protonmail.ch/login
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.
Not quite - the keys can be stored on the server encrypted with a passphrase and downloaded with the rest of the webmail system, and decrypted in Javascript. This isn't ideal (as any scripts on the page can steal the password as it's entered/the decrypted key) but does make it necessary for a site to be actively compromised to obtain the key. Of course there are security problems with crypto in javascript:
http://tonyarcieri.com/whats-wrong-with-webcrypto
Best solution I can think of would be to put encryption handling in the browser, so a website can hand off an encrypted key, the browser can prompt for a passphrase, and once one is supplied any encrypt/decrypt operations are handled by the browser, without the key ever being directly available. Sure it won't stop a compromised server decrypting stuff you didn't ask it to, but it at least means there must be a browser with the passphrase entered anytime you wanted to do this.
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
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.