Slashdot Mirror
Encrypted Email Is Still a Pain in 2017 (incoherency.co.uk)
Bristol-based software developer James Stanley, who used to work at Netcraft, shares how encrypted emails, something which was first introduced over 25 years ago, is still difficult to setup and use for even reasonably tech savvy people. He says he recently tried to install Enigmail, a Thunderbird add-on, but not only things like GPG, PGP, OpenPGP were -- for no reason -- confusing, Enigmail continues to suffer from a bug that takes forever in generating keys. From his blog post: Encrypted email is nothing new (PGP was initially released in 1991 -- 26 years ago!), but it still has a huge barrier to entry for anyone who isn't already familiar with how to use it. I think my experience would have been better if Enigmail had generated keys out-of-the-box, or if (a.) gpg agreed with Enigmail on nomenclature (is it a secring or a private key?) and (b.) output the paths of the files it had generated. My experience would have been a lot worse had I not been able to call on the help of somebody who already knows how to use it.
Encrypted email is not âoeuser friendlyâ for the average Joe because for the most part, people arenâ(TM)t interested in it, and so brain-dead easy apps generally have not been developed. Encryption for business and government is the focus, while most âoeregularâ people â" excluding those with paranoia â" just donâ(TM)t seem to think it adds anything for them.
Having said that, my employer, the Department of Defense, uses Outlook and a card with a chip in it that stores my credentials, and I can encrypt an email simply by clicking on a button.
If you want news from today, you have to come back tomorrow.
Giving credit where credit is due. mail.app and keychain make it a breeze. You can drag and drop public keys, sign email, use 3rd party sources or generate keys all with a gui that is rather intuitive.
EFF has done a great job with their "Encrypt the Web" campaign and gotten a lot of big websites to switch to https as their default protocol. The difference is that people running those servers are usually more technically minded (they're admins), so the implementation goes a lot easier. When dealing with non-technical end users, you can't expect them to do anything extra to set it up for them; it's just gotta become the default and get pushed to them. Anything else is a recipe for non-adoptance.
use outlook with s/mime instead, it's a ton easier, although it still does require a bit of knowledge, like clicking "sign" on "encrypt", plus exchanging signed emails ahead of time so outlook can harvest the cert
I'd like to recommend mailvelope It's a plug-in based solution that works for all popular webmail clients. It's ease of use and integration makes using encrypted mail, and key handling easy.
I am a figment of my own imagination.
No it isnt.
Use Thunderbird with the Enigmail plugin.
This is still a tech site, right???
Netcraft confirms it.
No. Really.
The average user has difficulty clicking on a UI element that says "Generate key" and figuring out what it does.
Let alone understanding the differences between key types, and why some are better than others. (like why you shouldn't trust the RSA algo.)
People forget things all the time. At some point you are going to forget where or what the key is for your encrypted email, so what to do? Recovery of that key is going to be necessary. Which leads to an entire host of other problems, many of which are security related.
So yeah, until memory becomes infallible we're stuck with encrypted emails having a certain amount of pain that comes along with them.
Is he referring to someone who knows how to use encryption?
-- OR --
someone who knows how to use Enigmail?
or someone familiar to both?
I've had to mess with PKI encrypted email (as a job requirement) many times over the last 15 years. In my experience, the problem is the underlying PKI support. It's really hard to load & manage certificates, deal with revoked certificates (including preserving emails when a certificate expires), etc. Some of that is, I believe, due to the complexity of PKI itself, and some of it is due to poor (at least from a user experience perspective) support by the OS vendors. Much of my experience is with DoD PKI, including their huge chains of PKI certificate/trust.
If the PKI infrastructure worked well, encrypting/decrypting email should be easy. But if the PKI infrastructure makes it really hard to manage certificates, there's nt a lot the mail user agent can do about that!
a message that can be read by somebody other than the intended recipient, is not worthy of being called secure.
A message that can have the key derived from the data stream is a message that fails to prevent somebody other than the intended recipient from reading it.
The two are mutually exclusive.
This is much easier to manage, and it is not clear that encrypting the email itself is that much better.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
BS - not knowing the difference between key types doesn't make a user an idiot - it makes them a user. Computers and email are not for the experts, and any function that requires a high degree of tech savvy simply won't gain widespread adoption. Linux is a great example, it's simply too much of a pain for the average user. I've tried getting parents, friends, coworkers to migrate to the most user-friendly distros, and it simply doesn't work - they abandon for Microsoft or Apple within a year.
If encrypted email ever becomes widely adopted, it will be the result of making the process much, much simpler for a USER.
Yeah. I'm already facing this with passwords, and ironically it's home equipment that I have the biggest issues remembering simply because I don't have to reconfigure it often.
Some big automotive enthusiast forums company got breached and set draconian rules for passwords for the users (who themselves did nothing wrong) as a result. twelve characters, mixed case, numbers, and non-letter-number characters, must be changed monthly. Screw that. I don't need to talk about four by fours enough to bother with such a thing on a non-commerce site.
Do not look into laser with remaining eye.
If it were easy, you would get a knock at the door in the middle of the night telling you to fix your bug.
The problem is that most of the public still uses web-based email (GMail, Yahoo, etc) and mobile. Gmail won't support even the most basic of encryption because their entire business model depends on reading other people's emails.
What GMail COULD do is put some sort of header on GPG-signed emails saying that this is certified as from an account.
That proves hatred they have for us. It should be simple, but they want to shove public key encryption down our throats so they screw us. They man page is over 2,600 lines long. It should just give two easy example of how to encrypt and decrypt. That should be the damn point of any encryption program. Instead, it goes into pages of off-topic meandering about public key management when all people want to do is encrypt a damn file. So, instead of giving people an easy path starting with encryption, the GPG guys intentionally piss off and confuse new users. Out of my CS students, I require sending assignments GPG encrypted. The department head set that requirement just to be a jerk since he hates the students. I never have more than one or two that by the end of the semester successfully sent me something public key encrypted. It's sad that GPG has set back encryption for two decades.
I have given up on GPG. It is a great program and in principle it is all you need. Until you have tried setting it up for your parents, spouse or friends.
It cannot and will not work. It is too complicated. The best solution I have come up with is using tutanota (others exists as well) . It is not perfect, but now must of my family use encryption without really realising it:)
>like why you shouldn't trust the RSA algo
I'm very curious. Why shouldn't I?
I generally am skeptical of the public-key infrastructure system which requires 3rd parties, but I "trust" RSA for pretty much all https requests I do. I also understand that the RSA company's BSAFE library is considered compromised but this is not mean "RSA algo."
Nowadays all connections between your client and your server is encrypted. And connections between email servers are encrypted as well using TLS. The only hole is if your email server uses Verizon as an ISP, because they strip the request secure transit bits off of the server connection. So far none of the big email providers have felt like blocking off all Verizon customers. Once that hole is plugged, there won't be a single point where an email isn't encrypted.
Because #LoserDonald would have bragged about winning if he had won.
Cheers.
IF the underlying platform is faulty, what does it matter? Platform includes UEFI, sure those drivers are "right", Prism, yeah Google will not sell you out, iOs, right, nice theater but we know you'll sell us out too.
I was sent a message encrypted by https://www.virtru.com/ and it wasn't a problem to open it on my end, no account required.
I liked the idea and took about 5 minutes to get it setup on my end so I could send encrypted email, too.
It's about the simplest setup I've seen yet, and only downside is a couple of second lag opening an email (time it takes to decrypt)
That is not the pain .
Where I work it is the clueless clients who send us (another company) encrypted emails and then demand an answer ASAP and blame IT when it doesn't work.
Cisco iron mail is horrible! Requires outdated Java and times out on our network. MBAs have no idea the work required. Just to penelize my users if they don't respond ASAP with no warning
http://saveie6.com/
The article says "I DuckDuckGo'd for keywords like GPG..."
I feel like the idiom should be "I DuckDuckWent" instead.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Try talking your non-techie friends into a Linux desktop. Even after you show them that the "Start button" is right where they expect it to be, and that the email and browser clients work just like they're used to and that they can do what they've been doing as easily as they've been doing it, there will be concerns. It all falls apart when they say "Can I buy a disk and install my own software?" and you say "No, but here's an easier way to install software from a vast repository of packages", they're done. They don't even ask what's available or how it works, their eyes glaze over and they hold up a CD-ROM of Cute Kitteh Pics and proclaim that they can't live without that version of that software - and it has to look exactly like they expect it to look. Anything else might require their direct attention.
Now, back on subject - you say "encrypt your email". They say, "okay, how?". You install and configure it for them, you make sure they only have to click one button to encrypt any given email. They say "Cool! And my grandma will be able to read this, right?"
You start explaining how this will work. Their eyes glaze over and they say they'd like to encrypt emails to their friends when they discuss their legal but oh-so-risqué lives, but if they can't email grandma it won't work. It's too late to tell them they got it wrong because their eyes have already got that hundred yard stare thing going on. You made somebody think about something and rather than believe they can understand it, they take the easier path of not even trying.
Bottom line - you're not trying to teach a behavior, you're trying to change a behavior. I've go GPG implemented. It's completely unused because nobody I know cares. They're not afraid of the government reading their emails and they accept that Google, Apple and Microsoft won't do anything worse than target advertising at them. Even after I offer to make it one-click convenient for them, most of my associates don't want it.
PGP has pretty much been abandoned. The companies that need to securely deliver messages do so by sending an email with a link that requires you to authenticate and then view the actual contents in a secure browser session. I find it absolutely hilarious that Slashdot has been persistent for so many years in resurrecting this topic every so often even though it's clearly dead, Jim.
We'll make great pets
So, I'm thinking this through a bit further, and I'm wondering whether encrypted e-mail still makes sense...
How many people actually-communicate via e-mail anymore? Yes, e-mail is still necessary as it's a de facto identification method - virtually every sign-up form uses e-mail addresses in this manner, but it's highly irregular that I send an e-mail to another human after I leave work. Most of that communication takes place via Facebook (known insecure) or WhatsApp/Viber/Kik/Line/BBM/SMS, and most of that communication needn't be terribly secure - for most people, "I have nothing to hide" is a valid reason to not care that Facebook reads their messages.
But what about people who do care? Well, there's Telegram, there's Retroshare, and there's self-hosted RocketChat, offering different levels of security and functionality depending on the particular use case required. Sure, it requires agreement of protocol, but most of the go-to use cases would have defined endpoints that could agree on a secure messaging method beforehand, whereby these tools would make sense.
Now, let's get back to the "after work" qualifier. During work, yes, e-mail is still the way businesses communicate with each other. They don't need security from government actors, they need security largely for compliance purposes and liability. Letting Barracuda or Microsoft deal with the secure transmission is just fine, because most businesses would hand over records to government actors if asked anyway, so as long as their insurance company says "good enough for us", that's typically all that matters.
So, given the fact that virtually every use case is covered already, why is encrypted e-mail a problem worth solving? When it's not that serious, e-mail is fine. When it is that serious, it's not like there is still a lack of things like Retroshare that can provide the needed security. That covers basically everything, doesn't it?
People forget things all the time. At some point you are going to forget where or what the key is for your encrypted email, so what to do?
Use Keepass?
We'll make great pets
When the standards for eliptic curve signatures were being developed, the NSA, in response to the submission recommended (without, I believe, much explanation) a slight different set of constants used to define the curves, and those recommendations made it into the standard.
Did they suggest the new constants, because they knew the initially proposed ones had weaknesses? Or because the ones they suggested had properties that would allow the NSA to break those signatures?
S/MIME is built into every major email client, just import your cert (you can get a free email one from just about any trusted certificate authority) and it'll work out of the gate. You have to use 3rd party software for gmail.
The general wide spread use of email encryption lacks a use case. The situations where an ordinary person would require encrypted email is incredibly rare and it's most definitely not worth the hassle. Think of the use case for email: You're trying to send a message to someone. Like a letter it could be intercepted and read, but in general it's still just plain text. Like a letter we can take basic precautions such as encrypting attachments or sending separately documents to prevent accidental collection, but fundamentally it is still something that for the most part in general needs to be read.
I personally wouldn't have enabled email encryption if I didn't need to on a very rare occasion have to handle sensitive information, but even then it's simply easier to often send an encrypted attachment.
http://crypto.stackexchange.co...
Because end-to-end secured email is a pain, why not just use WhatsApp or one of the other messaging systems which provide end-to-end encryption?
I would use PGP encrypted email if they'd make it easier for everyone else to use. Is it stands, I unfortunately know too many people that don't even know what Thinderbird is, let alone Enigmail. So, what would the point of encryption be if they can't even open it via PGP. They do make an app for iOS called iPGMail, but it's not easy to use either. There is a service called Protonmail that I like a lot. I'm not sure if the emails themselves are encrypted (maybe for Protonmail to Protonmail users), but I know the servers are Swiss and uses two passwords and no way to recover them if lost. The downside for Linux buffs is that it uses Azure However, due to recent court decisions, Micro$oft can sue if emails are checked without warrants and notifying them. Azure is developed by Micro$oft, so a technicality may offer more protection in the future. They don't have any desktop apps yet, but you can sign in online and they have it for mobile devices. But honestly, you are better off not emailing anymore anyway. It's outdated and no one tried hard enough to make it secure and viable at the same time. I would just use Signal or a Tox client if I was worried about snooping. Don't use Whatsapp or Telegraph. Whatsapp is owned by Facebook and Telegraph has been caught with backdoors before. Also, any country that blocks one and not the other should tell you they are compromised. Matter of fact, Signal is always coming up with tricks to circumvent blocking. And Tox is just something else. Think Skype but encrypted and there's a client for just about every OS. Much easier to setup than Enigmail and you can copy the profile config file to other computers and mobile devices so you don't have to setup another profile. I think it uses P2P and a server to make the initial connection.
If you use gmail and chrome there is a extension named mailvelope that is super easy to use. Just saying not all PGP email encryption is hard.
you nerds
Let alone understanding the differences between key types, and why some are better than others. (like why you shouldn't trust the RSA algo.)
The end user has no need for understanding that. They even shouldn't need to care.
The only way we'll ever see e-mail encryption if it's as transparent as WhatsApp's end-to-end encryption or https transfers. The moment you have to bother the user with manual key management there's an issue. If the user has to choose what key to use, it's a disaster. He shouldn't have to know why to trust or not to trust RSA or other key algorithms. That's for the application writer to figure out, and only offer suitable protocols to begin with. Then why ask the user about different protocols? The developers know more about that, and I trust them to be better suited to make an appropriate choice than me who knows little to nothing about encryption.
I don't know what algorithm WhatsApp uses to encrypt my messages. I can read it, receiver can read it, no-one in between can read it. I'm good. Of course I have to trust WhatsApp to do it properly - I know there are really smart people all the time trying to break these things, and I have yet to hear about this having been broken even partly. That is enough for me as simple end user to get the feeling they've done it well. It's probably breakable, but it's for sure not easy, and they don't bother me with keyrings, secret/public keys, algorithms and other things that I know almost nothing about.
I like computers, have a strong interest in the subject, and I'm sure I know a lot more about all this than the average person. So if e-mail encryption is hard enough to make me not even bother, a lot has to be done to make it usable for the average Joe.
With Azure Rights Management and Azure Information Protection integration into Outlook, Exchange and mobile support, Microsoft is way ahead in terms of ease of use for encrypted emails. In most cases, internal company emails are secured and users don't even know it aside from the little banner at the top. For external sharing it has a fairly easy to use system to share docs or emails and it does federate with external IDs. Company to company emails work without any sort of extra accounts or hassle. Company to end user does have a couple requirements, but it works pretty well. Fully federated experiences are coming to Gmail users too so you won't even have to have a Microsoft ID of any sort if you don't want it. Yes, it works in email clients like Touchdown, and there is an attachment process that works in Apple Mail and such.
Why storing it in encrypted form? It only has to be encrypted while in transmission to be secure.
You receive an e-mail, your client automatically decrypts it (of course at some point in time you unlocked the key with a password or so), and then stores it in your local storage unencrypted. You may of course in turn encrypt your hard disk if you want. Same for sent e-mail: the moment you press Send, the client encrypts the mail before delivering it to the SMTP server, and at the same time stores an unencrypted copy in your Sent folder.
Okay.
But the RSA algorithm is not the same as the ECC algorithm and both were designed by different people.
Took us over two years, but we did it right. https://www.securemyemail.com.... Works with your current email address(es). Simple enough for anyone and everyone but with advanced PGP key management features for those that like that sort of thing. You can even import your current key as well as invite legacy PGP buddies w/o them having to use. Easy inviting and optional updated web of trust using social networks is built-in. Android and Thunderbird are available now. iOS, our own simple clients for Mac and Windows should be out, we hope, by March and April.Apple Mail plugin and Outlook will follow. 30 day free trial and only 99 cents a year per email account for unlimited use. all systems are in Switzerland and it's truly end-to-end encryption where even we don't have the means to decrypt. ever. and for those in-th-know, no webmail so no javascript vulnerabilities or other shenanigans are possible.
Hmm, those contraints rather limit the set of possible passwords, thus weakening the security of the system.
Ignoring the 12 character limit, would be better if mixed case, numbers, and non-letter-number characters were ALLOWED, but not required.
As to the character limit, I think I may have used a password that short this decade by personal choice. Maybe. Of course, passwords for websites (online bill pay, that sort of thing) frequently don't allow passwords that long....
"I do not agree with what you say, but I will defend to the death your right to say it"
This is why I maintain that we need identity/security providers that will manage the keys and encryption schemes for you. The real problems are:
* Slashdot nerds (and the like) get all freaked out about the idea of a 3rd party managing people's keys. In order to be truly secure, it's necessary that only you can ever possibly get access to your keys, which means that you need to manage them yourselves. Therefore, any scheme that requires trusting a 3rd party gets rejected.
* Each vendor/developer wants to create their own standard, and then have everyone use their solution. No one works on real standards anymore. Facebook wants you to use Facebook Messenger. Apple wants you to use iMessage. Google wants you to use Hangouts. Or whatever. The point is, major companies are not working to come up with a cohesive modern secure messaging standard.
Now in answer to the first problem, I think to some degree, these people just need to get over it. Most people are sending unencrypted emails, so if they had their email encryption managed by Microsoft or Google, it would still be substantially more secure than it is now. The idea that some people might entrust their keys to a 3rd party should not be a bad thing, since most people are not qualified to manage their own encryption scheme.
What the nerds should want is only to be able to set up their own encryption key management if they feel it's necessary. Similar to the way many people use cloud email services, but you *can* set up your own email server, there should be simple cloud encryption/identity services, but people should still be allowed to set up their own encryption/identity servers.
The second problem is much more difficult. How do you get ubiquitous adoption of security standards where companies have an interest in maintaining incompatibility? I really don't know. One of the historically successful methods of creating an adoption of standards is through some kind of governmental action (either direct regulation, or requirements for government contracts). However, nobody trusts the government to push an encryption scheme, since they only want communication security when they can preserve a backdoor.
It's a shame. We really could do so much better if people weren't such idiots. And the problem isn't that "the common man" is an idiot, but that the people running various companies, and the people running the government, are all a bunch of idiots.
Finder has always referred to executables as "applications". (Source: any screenshot of Finder going back to 0.97) This is true in both the user interface and the four-character file type code used in classic Mac OS to identify each file's content type. The file type code for executables is APPL, short for "application".
Do you also require a citation that the use of "app" as short for "application" predates July 2008 when iPhone OS 2 was released?
...netcraft confirms it!
Sorry. Flashbacks.
Bristol-based software developer James Stanley, who used to work at Netcraft, shares how encrypted emails, something which was first introduced over 25 years ago,
Got enough commas in there?
is still difficult
Uh, what? Emails is still difficult?
but not only things like GPG, PGP, OpenPGP were -- for no reason -- confusing
"Not only were things like..." would've been easier to parse, though this is borderline cromulent.
Enigmail continues to suffer from a bug that takes forever in generating keys.
The bug takes forever "in generating" keys?
Look, if English isn't the submitter's first language, that's no big deal. But somebody, somewhere, should be responsible for editing submissions if you want people to actually think you're a professional news aggregator.
systemd is Roko's Basilisk.
As an Enigmail user, I have to disagree. I've found it relatively easy to implement. Similarly on a Web interface, there are ample extensions for implementing public key encryption. The problem is a lack of good encryption education. Unfortunately, people either try to educate too much or don't try at all. Just as people need to understand "lock the door" and not the intricacies of a 5-pin tumbler lock, we don't need to drown people in the the math of cryptography as much as the importance of a having keys and "locking" sensitive data.
Why should a user have to "Generate Key" at all? Why shouldn't encryption just happen without the user having to take any specific action?
At our local LUG, a young lady without CS training didn't just set mail+gpg herself, but now teaches others (with disabilities!) how to do that. Yeah, she's smart, but still.
C'mon, people. How much did you pay for your education? Claim your money back right now.
I have been using GPG since 2003. That means publishing my key and making it available. The only encrypted email I have ever received in all that time is from that bastion of privacy and security.....Facebook! It's like bizarro world.
Encrypting email is a hassle because the protocols weren't designed with security in mind, but rather an afterthought. Any attempt to add it now is bound to fail. The solution in my mind is, use email as something that you just assume everyone can read. If you want to make sure you have end to end encryption, use one of the platforms that was designed for security, like Threema or Signal.
PGP and OpenPGP are obsolete. You should be using S/MIME - that is where all the work on getting the process right has been going on, and for that protocol the set up is accessible in anything modern.
mailbox.org uses the OX guard to make it easier using encrypted email.
"Is it friday yet?"
The average person doesn't think to that level. It appears to be that the reason for lack of adoption is that the average person doesn't know it's a thing, plus it's non-intuitive, and their email providers don't do it for them.
And ... you mixed up RSA and AES.
RSA just relies on prime factorization being NP-hard and P!=NP.
AES is the encryption with some unknown constants (which are still not proven as dangerous btw.)
So maybe the user is right about not knowing the details of this ... when even you, who are a bit more advanced, get it wrong.
Maybe it's time to stop teaching e-mail to users.
Let's face it, users stop using e-mail anyway. Many apps which required e-mail for signup now work with a phone number alone.
So let's stop forcing e-mail for every bit of communication.
Use XMPP. The user likes the chat interface anyway, encryption with OMEMO (which has forward secrecy, which isn't possible with e-mail) is secure and apps like Conversations work like a charm hiding all the details with a Trust-on-first-use model, which is enough for 99% of the users.
The other thing: USE XMPP.
There are a lot of shiny new easy crypto messengers. And many of them work real good, some seem to be pretty secure. But almost all of them use a central server or when they let you configure the server, all your friends need to be at the same server.
To be independend we need a federated system. We have such a system. The System is called XMPP, has good specifications and a lot of opensource server and client softwares and a infrastructure of many free servers around the world, which are already available.
Stop creating new crypto messenger protocols. USE XMPP!
Remind me, why does the end user even need to be aware of all that?
All they should need to do is enter a passphrase. Give them some tips on how to come up with one, and how to secure it.
Once you start talking about "generating keys", you've already overcomplicated it. As for 'key types' - who the hell cares? It's the software developer's job to know that kind of shit, not the user's. Your question is like a doctor complaining because his patient can't tell whether he's experiencing premature atrial contractions or premature ventricular contractions.
Not sure if I'm not getting the entire story here, but how can a guy who tested one method alone (a plugin to boot) can generalize that encrypted email is still a pain?
Encrypted messaging is also a pain if I use only SMS or smoke signals.
I have a Protonmail account. It's encrypted during transit, and completely encrypted from Protonmail to Protonmail account, and it all works seamlessly.
TFA reads like a classic example of "User refuses to learn to use screwdriver, complains all fasteners are hard to use."
* Author seems to think encryption is a simple magic bullet.
* Author doesn't even bother reading the manual for the tool.
* Author reviews only one tool in a large family of tools, blames the entire family of tools for his own ignorance and incompetence.
* Author doesn't know about the problem space, has expectations that reveal a tragic level of misunderstanding.
The bottom line is encryption is easy.... authenticity is not.
Without authenticity, encryption isn't terribly useful.
Authentication isn't a problem that's been remotely solved. If you have a better idea than the following two, you're going to make a fortune:
- A web of trust requires real effort on the part of the user to work - you have to attend a few keysigning parties for it to work. Even then, can you really trust a web of trust?
- A trusted third party model assumes a third party is actually trustworthy -- which experience has shown isn't really the case.
-- Sometimes you have to turn the lights off in order to see.
I am/was a full-fledged computer scientist, and always found PGP terribly difficult to comprehend, and even more frustrating to attempt to use, even in a research setting. Further, it was easy to become insulted if someone would refuse to vouch for you even if they not only should have trusted you but actually worked for you. The whole ring of trust thing seemed totally wrong-headed. On the other hand, the certificate-based private/public key system evolved from the beginning not the way most internet services did, as a free and open technology, but as a profit-making venture, where the cost of purchasing an organization certificate tended to suppress use. On the third hand, now that free certificate services exist, there still appears to be a barrier to the emergency of widespread use of end to end encryption. The best time to have initiated widespread use of these technologies was the early 1980's or so when they first appeared, where the universe of users was much smaller. Some triggering event would now be necessary, along with active deployment by someone like Google, to make truly private communications commonplace in the population. Thank your favorite deity for Truecrypt and its successors, anyhow.
The subject line's arrogance about non-technical users is the source of much that's wrong with computer security today.
Computer users are not idiots, they just don't have specialized knowledge that specialists have. They should not need to have such specialized knowledge, and they're absolutely right when they think we're nuts for wanting them to obtain that knowledge.
There are many different levels of this particular form of arrogance, too. One of my ambitions is to develop a crypto API which developers can use without having to understand cryptography. I've often seen other crypto experts shake their heads in disgust about "idiot" developers who foolishly MAC then encrypt rather than encrypt then MAC (hint: both have problems), or use some block cipher mode with a known weakness in certain usage without first proving that its safe (or, better yet, simply using a mode without the weakness), or using PKCS#1 v1.5 padding for RSA encryption rather than OAEP, or failing to understand why using an IND-CCA2 scheme is always better than IND-CCA1 even if they are sure that the latter is good enough.
For that matter, even most cryptographers would struggle to define an appropriate cipher suite for a TLS-capable web server. Knowing what makes sense there requires deep understanding of not just the ciphers, digests and signature algorithms, but the protocol and its history, and the state of browser support and the tradeoffs involved in particular choices.
Security, especially cryptographic security, is a field that is both intricately detailed and very fast-moving, with lots of extremely subtle issues. I've been doing crypto security professionally for 20+ years and I don't make a move without consulting serious, world-class experts (to whom I'm lucky enough to have access)... and their first step is always to review all of the literature that is relevant to the problem at hand. At every level of knowledge in this space you look like an idiot to those at a higher level, and those at the highest level look like idiots to their future selves.
So, no, the fact that non-technical computer users don't understand cryptography doesn't make them idiots. They shouldn't have to understand it. It's the job of experts to make it Just Work, securely. The fact that we've failed to do so is on us, not on them.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Sounds like his problem is more with Enigmail than GPG encryption itself. Had Enigmail worked as it should have he would have had no problem.
openKeychan for android is stupidly easy to use.
plaintext goes in, cyphertext comes out
cyphertext goes in, plaintext comes out
it even automates the sending to and grabbing from clipboard
encryption is only hard when you use poorly made tools
gaim-encrypt (back before it was pidgin) was easy as shit to use too, it was slow back in the days of sub ghz celerons it could freeze your whole machine and make winamp skip for a moment when a messagecame in, but it was literally easy enough for children to use.
Snowden and Manning are heroes.
Previously known as Lotus Notes and Domino. Been doing encrypted mail for decades. Key management is not a problem. Encrypted webmail? Check! You can even give Grandma and account and let her use iNotes lite. Works like a charm.
Then you are communicating the wrong message. Your users care about easy and not security, but you keep talking security to them. I'm not accusing you, just surveying the situation. So what can be done?
I am reminded of a time long ago, when Windows was new and users need to be trained. We got pretty good uptake by clients, most were willing to go to the classes and go through the learning process. Every so often though, you'd get someone who just didn't care. The computer was hard and scary, and they didn't view it as having anything to do with their jobs. It's an IT device so the whole thing is IT's problem, right? Let IT, or management , or anyone else really, figure things out.
What changed those attitudes? No, it wasn't firing the recalcitrant do-nothings, though that might have been satisfying. No, it was Solitaire. Once you showed them the game their attitude did a 180. Suddenly you weren't forcing a very reluctant individual towards the computer, they were sidling up to it. Suddenly they were demanding to know how the mouse worked, and where they could click.
Change the attitude and you change the game. So how do you do that? I don't know but it involves changing the message to something the user cares about. Make it about internet cat videos, or Nyan Cat, or Justin Beiber or something. Obviously those subjects won't do specifically, but it's the principle I'm going for here.
Change the attitude and you change the game.
Encrypted email is not âoeuser friendlyâ for the average Joe because for the most part, people arenâ(TM)t interested in it, and so brain-dead easy apps generally have not been developed.
Probably because it's basically impossible to make encryption easy AND simultaneously do it right. It's just not an easy problem. The difficulty is less in the encryption itself (thought that's not trivial) but in key management. It's very difficult to get people to do key management properly. Even tech savvy people have a hard time with it. For the technologically clueless it is simply beyond them. Good luck explaining encryption keys to your grandmother who just wants to see pictures of her grand kids. Furthermore both parties in a communication have to agree that keeping to contents secret is of sufficient value to bother with all the headaches encryption brings. And make no mistake it brings a lot of headaches if you are doing it right.
Speaking for myself I'd be happy to use encryption routinely. But I bet you can guess how man people I interact with feel the same way. The number is a pretty good approximation of zero. I don't see any way to make it easy enough that it is transparent to a typical person who doesn't work for the DOD or NSA.
Having said that, my employer, the Department of Defense, uses Outlook and a card with a chip in it that stores my credentials, and I can encrypt an email simply by clicking on a button.
Great. You have an employer who is willing to do the hard work of managing both ends of the communication chain and can employ people who actually understand it all and has a compelling interest in keeping communications secure. That describes almost nobody else outside of the DOD, NSA or similar organization. And it is utterly useless when communicating with people outside the DOD who do not have access to your tech.
He gave it away really, with this gem...
I think my experience would have been better if Enigmail had generated keys out-of-the-box
NSA shill perhaps?
Buy two of the same books. Learn how to use a one time pad.
Take a holiday or sabbatical and give one book to the person you want to communicate with.
Teach that person about the use of a one time pad on paper. Don't encode or decode the message on the computer.
Take up landscape photography. Any digital camera will do.
Include a small banner ad like landscape image with every email.
Learn steganography and hide a short one time pad like message in every small landscape image in every normal email.
Set some constrained writing https://en.wikipedia.org/wiki/... in the text of the message to show that a real message is in the image.
One time pad use should keep the message safe, if not reused or decoded or created on a computer.
Sending an image with every email sets up a pattern that is not new later when really needed.
The constant use of a one time pad message over the years build up a pattern, but if none are real, years of everyday tasks will get tracked by some gov or contractor.
Anonymity would need a numbers station. Years of been watch for no result might induce cost savings that would see more interesting people tracked.
The ability to trust any computer crypto from an OS, as software is low given the help US brands offer with decryption to 5 eye nations and other nations.
"Microsoft handed the NSA access to encrypted messages" (Friday 12 July 2013)
https://www.theguardian.com/wo...
FISA, NSL, and new laws make all US domestic data part of collect it all.
"NSA to share data with other agencies without “minimizing” American information" (1/13/2017)
https://arstechnica.com/tech-p...
Domestic spying is now "Benign Information Gathering"
Uh huh. That's an argument (if you're sufficiently paranoid) for not using elliptic curve algorithms, or not using the curves that were promoted by the NSA and NIST. That has nothing to do with RSA (the algorithm, not the company, which is what GP was asking about.)
(And for what it's worth, we know for a fact that the NSA backdoored Dual-EC, and even tried and failed to standardize a TLS extension designed to make that backdoor easier to exploit. But I haven't heard any credible reason to think the other NIST EC algorithms are compromised.)
Indeed, I recommend against ECDSA in general, but not because of possible NSA backdoors - because the algorithm is, inherently, absurdly difficult to implement correctly. If you need something that's faster and requires less bandwidth than RSA, use Ed25519. Otherwise, RSA is still the way to go, with key size to suit your level of paranoia. In a few years, post-quantum algorithms will hopefully make all the above obsolete.
Banks? They are highly trusted. They allow for key regeneration / recovery because they have physical locations and can check ID. They are technically savvy when they want to be. They have international and national bodies. They are regulated.
It would make it too easy to use.
Why doesn't anybody mention email providers like Protonmail?
We're getting close.
Username-password management is pretty much acknowledged as a broken system. I trust LastPass so I turn most of my password management over to it. Where I don't turn it over to them, I use KeePass. I back up my credentials in backups encrypted with two systems. (I trust three so I actually do combinations of each so that even if one is broken, the other backs it up.)
We're getting close to a solution. I predict that not far in the future, we'll have simple encrypted email. Not because people understand how to do it, but rather because we can't manage passwords ourselves and we're getting tools to do it for us. We won't do it because we desire to learn how, but rather because we're finally reaching a tipping point where everybody needs a tool that can manage it for us.
Computers *ARE* for the experts, that's one of the biggest problems these days... Despite various attempts and all kinds of false marketing, current operating systems are simply not suitable for end users (you cite linux as an example, but windows and osx are no better either). They are designed for experts, and should be used by experts. It's one thing when you have a system configured and managed by an IT department, but quite another expecting a user to manage such a system themselves.
Users are better off with a simpler system like a games console or an ipad.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Yes, Conversations/XMPP seems like a great solution, at least a worthy alternative to Whatsapp/Signal.
Unfortunately, there isn't a comparable desktop Linux client, so I would still have to depend on a phone (or Windows/OSX?).
Gajim comes very close, but this is a bummer.
If that ever gets implemented I intend to switch over my relatives.
But yes there is some great progress made!
Whoops, wrong URL.
What I'm still missing in Gajim is MUC history support.
You are right, in general PGP is a pain - however, purely in the context of this thread, I believe the use of modern, reliable and more usable tools are non-trivial - and one has appreciate their efforts towards making the digital world a more private and secure place. By the same token - I will advice Mailfence (https://www.mailfence.com), where we have dealt with those conventional usability issues and have came up with sound working models. Also, check following links too for best PGP encryption and digital signing practices... - https://blog.mailfence.com/ope... - https://blog.mailfence.com/ope...
Not sure what you mean by "not often used", but OSNews cites the Oxford English Dictionary in tracing the terms "app" and "killer app" back to the 1980s. An early (1985) Object Pascal framework for Macintosh Toolbox applications was called MacApp. Ashton-Tate's Framework II office suite likewise referred to bundled applications as "apps" to save space in the menu.
It's not a bad idea, but it seems like it could still have some problems because:
* Banks are only sort of technically savvy. For all of their capability "when they want to be", they're also stodgy old traditional institutions that don't like change and don't want to deal with technology. Unless it's high-frequency trading, or something like that.
* Much like tech companies, banks and credit card companies also don't like to work with each other to develop new standards. For as outdated and insecure as credit cards are, they still seemed to be avoiding the credit cards with chips. If banks would work together on new technical standards, we wouldn't be waiting for Apple/Google to develop their own competing payment services.
FWIW the banks are behind the Apple / Google solutions. The people being stodgy are the storefronts that want to keep their equipment costs low. The banks can't afford to alienate them so they side loading this technology into the ecosystem.
I've had a public gpg key out there for well over a decade. Tried to get others to encrypt. Nobody else will do it. Even tech people that really should know better. Even with step by easy step instructions. There's no interest in it. This is probably the norm, how many people want to encrypt their conversations with their siblings or other people. I have a feeling they're afraid they'll forget the password.