Moxie Marlinspike: GPG Has Run Its Course 309
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."
Same error, repeated (Score:5, Interesting)
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.
Re:Same error, repeated (Score:5, Interesting)
I know quite a few people who have started using GPG via the Enigmail plug-in for Thunderbird lately. The length of the man page is irrelevant and they never publish their keys so are effectively invisible to the statistics. That doesn't mean that it isn't an extremely useful, valuable piece of software though.
Now more than ever we need GPG, and I bet adoption has gone up a lot in the last year.
Re:Same error, repeated (Score:5, Informative)
I know quite a few people who have started using GPG via the Enigmail plug-in for Thunderbird lately. The length of the man page is irrelevant and they never publish their keys so are effectively invisible to the statistics. That doesn't mean that it isn't an extremely useful, valuable piece of software though.
I use Thunderbird with Enigmail, mostly to sign my emails to get other people used to seeing signed mails, with an attachment with the signature in it. I've got one question about this, a friend asking what that mysterious attachment was and I explained it. I created an IMAP mail account that I only use to make notes that I can easily share among different computers. All these notes are encrypted using my public key. I can open them on the computer which has my private key.
Your comment about being invisible to statistics does not mean being invisible to NSA and GCHQ. As they and several other agencies scan all mail, they will see these attachments, they will see mail headers and other signs that mail being encrypted, whatever method you use. So they will know that your friends use GPG.
Re: (Score:2)
So they will know that your friends use GPG.
Sure, but we are already on the terrorist watchlist anyway. Some of us are into flight simulators, some of us have Islamic sounding names, some of us just complain about surveillance a lot. I use a VPN constantly which is enough to make you interesting to them. At this stage encryption can only help.
To clarify, I was talking about Moxie's claim that there were not that many GPG users because there are only about 2 million public keys on known key servers. I'm sure there are loads of people like us who don't
Re: (Score:3)
There are also different keyservers. For example, Symantec has its own for its commercial PGP Desktop.
Then there is the need for a key for a transaction. For example, when helping a client out, he already had my key's fingerprint and ID, so there would be no need to publish that for an interchange that was just between the both of us.
Moxie might have a point... maybe it might be wise for some time to be spent improving the PGP/gpg keyserver network, adding more servers, working on better ways to propagate
Re: (Score:2)
I know quite a few people who have started using GPG via the Enigmail plug-in for Thunderbird lately. The length of the man page is irrelevant and they never publish their keys so are effectively invisible to the statistics. That doesn't mean that it isn't an extremely useful, valuable piece of software though.
Now more than ever we need GPG, and I bet adoption has gone up a lot in the last year.
Why use gpg instead of s/mime, which has native support in most e-mail programs, with no need for plugins? Thunderbird included.
Re:Same error, repeated (Score:5, Informative)
Re: (Score:2)
I use Enigmail daily and hate it because it makes my mail unsearchable. They've made the decision that all mail at-rest should remain encrypted. That's a great default because it's secure but I think there should be an option to store mail locally in plain text.
Re: (Score:3)
The problem is that OpenPGP products fill a need, and adding additional, usable features is hard, other than new algorithms.
However, nothing fills the role OpenPGP does with as much reliability, interoperability, and trust. I can encrypt a message on AIX, sign it on a Solaris box, validate the signature on a FreeBSD box, then decrypt and read the file on a QNX embedded machine.
The problem with people bashing PGP and gnupg is that usually they have their own encryption solution they want to peddle. There i
Oblig... (Score:4, Funny)
http://xkcd.com/1343/ [xkcd.com]
Re: (Score:2)
For e-mail encryption to be practical it needs to be extremely simple to use. It's not simple to use, so there's not much encouragement to use it, so it doesn't get adopted for wide use.
Re: (Score:3)
Original poster stated, "... it'd be kind of a shame to finally get there with 1990's cryptography."
The RSA encryption algorithm has been around a lot longer than the 1990s. In fact, it was released in 1977. Still, the technology and algorithm continue to work. However, due to advances in computing and hardware, the encryption keys have had to be extended. So, there is nothing wrong with the older technology.
When my brother and I started a business in 1994 to provide a secure communications platform for
Re: (Score:2, Insightful)
Here, let's have an example.
GNU findutils:
gpg (Score:4, Insightful)
Re: (Score:3)
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.
Not only that, but look at the Enigmail interface. Once it's installed and configured, it's only clicking the icons in the status bar and entering a password. I sign all mail as well.
Re: (Score:2)
How do you know how useful it is if you've never thought about how many people use it?
It could very well be for the most people you talk to your GPG signature would be about as useful as a disclaimer asking someone to delete the email if they were the wrong recipient, or the "Please think of the environment and don't print this mail" sign-off.
Re: (Score:3)
It's still potentially useful even if nobody else uses it; you can at least show later on that you or someone with access to your private key signed something.
GPG, PGP, SHA1, RSA... (Score:2)
It really is just an alphabet soup of acronyms with security systems. No wonder the average person just doesn't bother.
Re: (Score:2)
It matter a lot to the NSA, FBI, GCHQ, ...
That's great, but... (Score:5, Funny)
...what do the other characters from Harry Potter think?
Another bad omen for privacy and security (Score:5, Insightful)
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.
Re:Another bad omen for privacy and security (Score:5, Interesting)
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.
Crypto is easy. Ciphers are easy. Here's a key you can use it to sign and verify messages, open and seal envelopes.
Using crypto is hard. People lose keys, forget passwords, don't transmit keys in a secure way, don't store keys in a secure way, revoking keys, checking for revocation, using third party services like webmail and so on. Strong crypto is like losing your house key and being told that sucks, but since it's an impenetrable bunker with an unpickable lock there's nothing you can do but start from scratch.
People want recovery options. If my house burns down to the ground and I escape with no passport, no driver's license, no identification of any kind the government will get me a new one. Work will find a way to get me a new access badge and key fob. That's why all those ways to recover your account exist, they're not necessary per se and you don't have to answer the security questions seriously. But when you have fucked up big and the answer is just gibberish you're pretty screwed. That's why people answer those with actual facts.
Re: (Score:2)
Like many other administration chores, the key management needs almost an expert system to deal with the daily operations for the non-caring, lazy, or just "regular" people.
And the "expert" system most choose is simply having an account - everyting from e-mail accounts to forum accounts to social media accounts. The users keep their password safe - that's securing the endpoints - and then you trust the system to deliver the email to the recipient and not anybody else. Because if you're handing over the keys to a third party, you might as well hand over the communication too.
Re: (Score:2)
I agree with your post. In the 1990s there was a lot of enthusiasm around crypto.
I think what's happening though is groups like Apple and Google have made crypto pretty easy. Since the original article mentions email, for example in Apple's standard / free / included mail.app I can easily:
a) self sign a certificate and include the public key in my email
b) send an encrypted email to anyone who has ever sent me their certificate
Similarly with the iPhone / iPad application. That's a pretty good implement
git blame (Score:5, Insightful)
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.
Re: (Score:3)
Outlook and Apple Mail have supported S/MIME for years, and the UI for using it is way nicer than any GPG plugin I've used. But the trouble is, no-one else uses it so I ended up only ever doing encrypted e-mail to/from my wife.
Re: (Score:2)
Exchange has an easy to use encryption feature so that's not true.
Re: (Score:3)
Re:git blame (Score:5, Insightful)
Blame the users mostly for not giving a fuck about encryption.
That is stupid. It's like saying blame the drivers for not giving a fuck about fuel injection. Users should not have to care about encryption. They should care about having secure and private communication, and how to make that happen is our job, it's why we are being paid more than burger flippers.
Re: (Score:2)
You could check the gnupg users lists, or see if slashdot-userfoo has a key: "slashdot.com/~userfoo/pubkey"
I use GnuPG (Score:4, Interesting)
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.
Re: (Score:3)
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
So how does someone like me obtain your key securely? if you send me a message that is signed and say goto this link to get the pubkey so you can check the signature, I don't know the message is really from you and all the attacker needs to do is put his pubkey at the message url, assuming the message came from the attacker impersonating you.
Even if the message was legit how can I know my routing or DNS isn't be tampered with? How do I verify andycanfield.com is really yours? Am I supposed to use SSL/TLS
Re: (Score:3)
Good points.
I rely on the domain name www.andycanfield.com. If somebody is faking that on your network then there is nothing I can do about it. However, I point out that if the message "from me" is signed, then it was signed by my PRIVATE key and the public key you get from my web site should confirm the signature.
You left off the top level: Who the H* is "Andy Canfield" anyway? This body? That site? My passport? Police in this town wave to me every morning, but can't spell my name in English. I have d
Re: (Score:3)
Thanks for the reply.
I point out that if the message "from me" is signed, then it was signed by my PRIVATE key and the public key you get from my web site should confirm the signature.
Sure but what if I create a key pair, and send a message that claims to be from you but says please go download my public key at http://attackersite.com/andyca... [attackersite.com]
See the problem is I have this unauthenticated message and the only information I have about how I can authenticate the message is in the message. That is my biggest problem with your method.
Re: (Score:2)
PGP isn't a standard, but S/MIME is. And S/MIME is implemented in plenty of serious mail clients, including mutt, Outlook, Apple Mail, Kmail, Thunderbird, and even web-based shit like Horde.
Re:I use GnuPG (Score:5, Informative)
PGP isn't a standard
It most certainly is:
RFC 1991, 2440, 4880, 5581, 6637, 2015, 3156
http://en.wikipedia.org/wiki/P... [wikipedia.org]
The e-mail client I use has gnupg support by default.
Re: (Score:3)
What is the alternative? (Score:3)
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.
Back office (Score:5, Insightful)
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
Re: (Score:2)
I can buy encrypting email communications, but for this you should just use SFTP. Why would you ever use email for important data transmission? It's not a matter of encryption, it's everything else. It relies on DNS. It doesn't confirm the remote server's identity. Delivery is best effort and does not succeed or fail immediately. An
Moxie's security advice to me: (Score:5, Interesting)
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.
Re: (Score:3)
I'd like to add that I hate PGP signatures in email messages, too.
There is a lot that's wrong with the UI elements surrounding the crypto. For one, the operating systems and apps do not treat keys and sigs as first-class objects; they always end up looking like inlined ASCII barf, or little text files that have no informative icon + tooltips or associated apps. The presentation of crypto to the user practically begs the user to ignore it.
This is even true when you look as certs in web browsers. They are a m
Re: (Score:3)
For one, the operating systems and apps do not treat keys and sigs as first-class objects; they always end up looking like inlined ASCII barf,
Or you could install enigmail, which turns it into informative text [enigmail.net].
Your use of "always" is fail, as usual
Re: (Score:3)
I'll grant that Enigmail rectifies the display problem ...but Enigmail is neither the OS nor the application. By default, the uninitiated will see gross text and that is because (as I said) crypto isn't given first-class treatment in UIs.
TB sans Enigmail could at a bare minimum parse the guard lines and fold the contents into something like the UI for attachments. Or it could just incorporate Enigmail functions in the main program.
Re: (Score:2)
I'd like to add that I hate PGP signatures in email messages, too.
For one, the operating systems and apps do not treat keys and sigs as first-class objects; they always end up looking like inlined ASCII barf,,/quote>
pgp-mime is supposed to be preferred over pgp-inline, at least for e-mail/newsgroups.
or little text files that have no informative icon + tooltips or associated apps.
For the e-mail client I use, they do have a little key icon and a tooltip that says
Type: application/pgp-signature
Size: xxx
Description: OpenPGP Digital Signature"
No application is assigned to them though, but I don't really need it in my e-mail application.
Said this 14 years ago. We need to replace E-Mail. (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
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 disagre
Re: (Score:2)
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.
Re:Said this 14 years ago. We need to replace E-Ma (Score:4, Insightful)
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.)
Re: (Score:2)
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.
Re: (Score:2)
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 cont
Re: (Score:2)
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.
Re: (Score:2)
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 deli
Re: (Score:2)
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.
Re:Said this 14 years ago. We need to replace E-Ma (Score:4, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 commo
Re: (Score:2)
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 eit
Re: (Score:2)
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.
Comment removed (Score:3)
Let me explain.... :-) (Score:5, Insightful)
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.
Re: (Score:2)
"End to end [github.com]" is a project which creates that sandbox you speak about.
Also, see its "gossip protocol [github.com]" wiki page on how to solve the key distribution issue.
Re: (Score:3)
I've always thought the best people to handle community signatures is banks. Banks are already trusted. Banks are used to and setup for verifying identity. Generate a key on USB and submit to a bank which verifies your real life keys for a marginal fee. They could also optionally store a copy of the private key for you in case of loss.
For not tied to your real life accounts... there is no need for verification the email provider can just self sign.
Re: (Score:3, Interesting)
I've always thought the post office would be a great place to get your keys signed.
Re: (Score:2)
- Crypto doesn't play well with webmail
- Find a way to make it work with webmail.
It does already work with webmail, if you use a proper e-mail client to access your webmail, which is what people should be doing anyway.
Re: (Score:2)
Re: (Score:2)
- Crypto doesn't play well with webmail
But you've heard of Hushmail, yes?
We have the technology. If we want, we can make strong crypto work. Problem is that most of the big players with the money to make it happen don't want, and the small guys either don't understand the technology and complexity (users) or are incapable of making it actually usable (techies).
Blame email clients (Score:5, Insightful)
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.
Re: (Score:3)
The first mistake made by email clients is they added support for a broken-by-design protocol called S/MIME which used asymmetric encryption through the entire message and was thus cripplingly slow.
Who says it uses asymmetric encryption through everything? It makes up a symmetric key, and encrypts only that key with the public keys of all recipients.
Re: (Score:3)
The first mistake made by email clients is they added support for a broken-by-design protocol called S/MIME which used asymmetric encryption through the entire message and was thus cripplingly slow.
Slow? Who gives a shit? We're talking about email. I have never noticed the time it takes to encrypt anything, actually. Not even a little bit. The only time I've never noticed being taken by encryption was during key generation.
You're right about how PGP/GPG didn't do enough for integration. That is sad.
Re: (Score:2)
Re: (Score:2)
If you want to use crypto in GMail then you have to cut and paste and clearly it's too much effort.
You don't have to cut and paste...if you access your Gmail with a real e-mail client over IMAP or POP3, which is what you should be doing anyway...no advertisements that way.
Metadata (Score:3, Insightful)
In short, everything except the fact that you're using the system.
Re:Metadata (Score:5, Insightful)
Re: (Score:2)
You underestimate the value of signing. It's not all about secrecy.
Re: (Score:3)
To protect the metadata of the recipient is daft. How are intermediary servers ever supposed to know? And if you and the other end of the connection both set up a connection and know who it's for, that blows out the "fact that a message was sent" before you start.
Message length is also stupid to try to hide. Sure, it may not be exact but if I send a 200Mb email and you send 20 characters, how are you supposed to encrypt those to be indistinguishable without literally padding to the nearest 200Mb? And pa
Re: (Score:3)
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
Re:get to work (Score:5, Informative)
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/... [wikipedia.org]
Re: (Score:2)
Damn him for putting his money where his mouth is!
Re: (Score:2)
>I like your black & white world; mine has too many shades of gray.
50 of them ?
Re: (Score:2)
Hey! I've had that signature way before those books were a mere itch in their authors' belt-beaten bunghole.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
>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
Re: (Score:3)
I must be getting old when 6-digit UIDs are long time slashdotters. I for one welcome our newbie overlords.
Re: (Score:2)
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/... [wikipedia.org]
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 us
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:3)
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/... [pcmag.com]
Re:get to work (Score:5, Insightful)
And, of course, the whole thing is dependent on fixed servers which Moxie claims aren't easily replaced [github.com]. 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!
Re: (Score:3)
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
Re: (Score:3)
Show us your work. Talking is easy Moxie: PRODUCE SOMETHING USEFUL.
He is just being Marlinspitefull.
Re:get to work (Score:5, Informative)
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.
Re: (Score:3, Interesting)
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.
Re:Cock Chuggin' (Score:4, Informative)
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.
Re: get to work (Score:2)
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.
Re: (Score:2)
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.
Re:People are dumb, and don't care (Score:4, Interesting)
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.
Re:GPG is another TrueCrypt? (Score:5, Interesting)
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.
Re: (Score:3)
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