Live data from Hacker News

Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

arxiv.org

141–150 of 165 posts

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#141
post #67

Earlier quoted context omitted.

I've been using GPG since a while now, to sign my outgoing mail. I don't encrypt it as I don't know anyone who uses GPG. I'm still happy to use it, to get used to it, and to see alternative uses. Signing is in my view a big improvement, to make sure nobody has messed with the messages. I always use HTML, so the receiver gets an attachment with the signing hash in it, and no strange text in the mail. I use a signature…

The idea of including a link to your public key and a link the wiki on PGP is great! I'm going to do this as well. Would you mind showing me how you link to the above mentioned?

Mine http://www.explainxkcd.com/wiki/index.php/1553:_Public_Key

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#142
post #92

Earlier quoted context omitted.

Interesting; I'd really like to hear what issues you have with that scorecard.

Matthew Green and I had a bet for the last year, which just ended, over libotr's security; I bet him that nobody would find a sev:hi flaw in it all year, and, of course, won, because at this point all the low-hanging fruit in libotr has been shaken out. That bet was a reaction to the release of the EFF scorecard, which at the time gave Cryptocat(†) a perfect score but dinged ChatSecure, which is a libotr client, for…

What would be a better way to produce such a scorecard?

Is there already any collection of common criteria established by computer scientists and accepted by experts and / or any kind of standardization of requirements for secure software that was produced by leading security capacities that allows to extract data for a compact visual comparison like the eff scoreboard?

Would you like to provide or show me a link or any material that compares "the security" of products and offers an understandable and "industry-accepted" categorization?

Isn't it a bit strange that a small organization of non computer scientists produce something that was painfully missing for at least 50 years? Isn't it clear that a first approach to such a thing must fail and that this can only be a prototype for a process that should be adopted and worked out by people who understand what they are doing?

Isn't it a bit strange, that there is no such thing as that scoreboard produced by an international group of universities and industry experts, with a transparent documentation of the review process and plenty of room for discussion of different paradigms?

The eff scoreboard demonstrates painfully the obvious omissions of multiple generations of security experts who failed to establish a clear definition of what security exactly means, how to discuss it and how to find an acceptable approach to establish a thing that would allow to be named "review" in the scientific meaning of the word.

It is totally clear that Apple and Microsoft have very different ideas about security than OpenBSD developers, but it would still be of great value to have a space where people could follow that discussions and compare the results of different approaches and solutions to security related problems.

The eff scoreboard carries the embryo idea of a global crypto discussion, review, comparison and knowledge site that could also serve as a great resource for non-crypto people and students to learn a lot about that field. The highly valued information you and other experts are dropping here and there in HN threads and/or on various mailing lists should be visible in a place that collects all that stuff and allows for open discussion of these things in the public, so people can learn to decide what security means for them.

If such a thing exists, please show me.

If not, please build it.

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#143
I have a budding idea that involved using a blockchain to manage cryptographic credentials, but I'm having trouble finding proper blockchain libraries. Any recommendations?

I'd prefer Python or Go, since that's what I'm mostly using these days, but at this point I'll take brainfuck if that's my only choice...

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#144
post #67

Earlier quoted context omitted.

I've been using GPG since a while now, to sign my outgoing mail. I don't encrypt it as I don't know anyone who uses GPG. I'm still happy to use it, to get used to it, and to see alternative uses. Signing is in my view a big improvement, to make sure nobody has messed with the messages. I always use HTML, so the receiver gets an attachment with the signing hash in it, and no strange text in the mail. I use a signature…

The idea of including a link to your public key and a link the wiki on PGP is great! I'm going to do this as well. Would you mind showing me how you link to the above mentioned?

Here's the code that I used in Thunderbird. I make it small and light in color.

This message is signed using PGP" rel="nofollow">https://en.wikipedia.org/wiki/Pretty_Good_Privacy">PGP. Public key: " rel="nofollow">https://pgp.mit.edu/pks/lookup?op=get&search=0xBE5D1E31ABCD1... ABCD1234

I see the link in the code is not closed properly, so you need to fix this.

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#145

Earlier quoted context omitted.

I am in the same boat you are. I also appreciate your practical and concise point of view. Yes, it ought to work quite easily, but in practice it doesn't yet, does it? I'm planning to spin up a few servers in Amazon to test it there just to get some benchmarks. What kind of testing and experimentation have you done? In my use case I would put the traffic through a single machine across a ten gig link to another machi…

I've only messed with a single tunnel at a time. However, there's a whitepaper from Intel from several years ago that says that multiplexing over 6-12 tunnels should possibly work: http://www.intel.com/content/dam/www/public/us/en/documents/... The question remains on how to perform routing for this. It appears that running Quagga on both end points, speaking BGP to each other, will allow ECMP over the 6-12 IPsec tun…

I hesitate to post as my experience is a bit dated as well, but this topic continually seems to come up lately in my circles without a whole lot of authoritative information I've been hearing.

Single-stream IPSec is still a major performance issue. Maybe someone out there is getting more than about 2.5Gbps performance in the real world per stream out there, but I haven't talked to them. This is with some pretty idealistic assumptions too - I would expect most folks real-world performance is orders of magnitude lower.

Scaling it over multiple cores does work, but introduces the complexity that you mention. This still completely ignores the major problem of the fact that single flows are stuck with early-2000's level network performance! With ethernet moving to 40g in high-performance applications, being stuck with 2gbps TCP connections inside the datacenter is not ideal and makes doing global-infrastructure-level ipsec a non-starter. I briefly spent some time considering going 100% ipsec for all inter-cluster communications for a product we were building, but the performance implications put that dead in the water almost immediately. Moving it up the stack into the application was far less expensive - but of course carries with it the cost that you are no longer operating in a "fail safe" environment.

You could make the argument that anything high performance needs to horizontally scale across multiple streams and links - but that's being too idealistic for the current state of technology. Sometimes you just really need to make that legacy NFS transfer go faster.

With the advent of hardware acceleration built into "commodity" CPUs these days - I really did expect more real-world progress on this front both on the linux side and custom asics (e.g. switches/routers). Given the number of colleagues/customers who have asked for similar solutions ("I want 10gbps single stream ipsec") it's not an uncommon problem folks are running across.

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#146
It's unrealistic to expect naive subjects to learn how to use GnuPG in an hour. It takes longer than that to learn a new game! People need at least to know what public-key cryptography is before trying to use it. But unfortunately, the Wikipedia entry is rather intimidating.[0] The GnuPG FAQ (at 7.1) is clearer, but not so easy to find.[1]

[0] https://en.wikipedia.org/wiki/Pretty_Good_Privacy

[1] https://www.gnupg.org/faq/gnupg-faq.html

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#147

It's unrealistic to expect naive subjects to learn how to use GnuPG in an hour. It takes longer than that to learn a new game! People need at least to know what public-key cryptography is before trying to use it. But unfortunately, the Wikipedia entry is rather intimidating.[0] The GnuPG FAQ (at 7.1) is clearer, but not so easy to find.[1] [0] https://en.wikipedia.org/wiki/Pretty_Good_Privacy [1] https://www.gnupg.or…

You said "People need at least to know what public-key cryptography is before trying to use it." I think this is untrue. People really just need to know how to work with the technology, not understand what it's actually doing. Trying to explain the underlying principles makes it more confusing and thus, less safe.

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#148
post #145

Earlier quoted context omitted.

I've only messed with a single tunnel at a time. However, there's a whitepaper from Intel from several years ago that says that multiplexing over 6-12 tunnels should possibly work: http://www.intel.com/content/dam/www/public/us/en/documents/... The question remains on how to perform routing for this. It appears that running Quagga on both end points, speaking BGP to each other, will allow ECMP over the 6-12 IPsec tun…

I hesitate to post as my experience is a bit dated as well, but this topic continually seems to come up lately in my circles without a whole lot of authoritative information I've been hearing. Single-stream IPSec is still a major performance issue. Maybe someone out there is getting more than about 2.5Gbps performance in the real world per stream out there, but I haven't talked to them. This is with some pretty ideal…

For others who are interested, here's a thread that culminates in the 2.5Gbps number:

http://permalink.gmane.org/gmane.linux.network/280175

And here's some StrongSwan documentation about getting there:

https://wiki.strongswan.org/projects/strongswan/wiki/Pcrypt

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#149
post #64

I see two major barriers to mass adoption of any crypto system that requires a UI. 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet. So long as the "key…

> 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet. Do you mean something like the Yubikey USB dongle: https://www.yubico.com/products/yubikey-hardware/…

Yubikey NEO has support for using an OpenPGP applet over NFC with OpenKeychain on Android

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#150
post #40

Earlier quoted context omitted.

> While our results are disheartening, we also discuss several ways that participant experiences and responses indicate how PGP could be improved. Have you approached the developers of both Mailvelope and Gmail to discuss these improvements? How did they respond? Also, have you participated in usability discussion with the OpenPGP developer community at large? Any insights? I ask because it seems like everyone who is…

We haven't reached out to Mailvelope/Gmail developers, nor have we opened a usability dialogue with the OpenPGP community. We're still in the process of getting these results published. Your experience with that community is interesting though.

Please talk to the OpenKeychain developers. That's the best PGP implementation I know of. Also keybase.io.
Post reply on HN