Live data from Hacker News

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

arxiv.org

161–165 of 165 posts

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

#161
post #140

Earlier quoted context omitted.

Keys are stored in local browser storage. How does this work when browser cache is cleared?

Cache is separate from localStorage. Clearing your cache should have no effect on your SC4 keys. (Also, if you're running one of the two standalone versions, your key is stored in a file.)

At least in Firefox, clearing cookies (not an unreasonable thing for users to do once in a while) will also clear localStorage.

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

#162
post #157
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…

So if the way the receiver gets hold of your public key is by a link in the signed email, what's to stop an attacker changing the link to a fake key and re-signing the email? Hmm. Why don't we have a standard place on our domains for public keys? For example for myname@mydomain.com the public key could be https://key.mydomain.com/myname .

Some part of a key exchange needs to be out-of-band.

Alice communicating to Bob what the hash of her public key is over the phone, in person, or otherwise is good enough. Doing that allows Bob to verify whether or not a specific public key belongs to Alice.

The problem with hosting a key on a website is that it only really works if the domain has an extended validation certificate, i.e. someone proved their identity to their domain registrar. Then things just become a question of how much you trust the CA.

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

#163
Hi guys,

Maybe you should try Jumble (www.jumble.io) for email encryption - works with Gmail, iOS and MS Outlook.

Jumble manage key pairs for users and encrypt the private key with the users password so they don't have access, this ultimately simplifies the whole process for the end user and frees them from the key management aspect which is the major pain-point with PGP-based solutions. Also, it integrates on top of existing emails clients so no need to change your email address or how you interact with emails.

Full disclaimer: I'm a co-founder of Jumble

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

#164
post #140

Earlier quoted context omitted.

Cache is separate from localStorage. Clearing your cache should have no effect on your SC4 keys. (Also, if you're running one of the two standalone versions, your key is stored in a file.)

At least in Firefox, clearing cookies (not an unreasonable thing for users to do once in a while) will also clear localStorage.

That's true. There are limits to what one can do when running in a browser. If you have a better idea for where to store keys, I'm all ears.

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

#165
post #107

Earlier quoted context omitted.

You have to encrypt the transport at the application layer when you're talking about the scale of major internet companies--there are so many links going out of each datacenter that it's not feasible to do IPsec or similar lower level encryption. There aren't many hardware devices sold that can do the encryption at the 10-100+ Gbps speeds that datacenter links use (if any), and it's much easier to amortize the encryp…

> There aren't many hardware devices sold that can do the encryption at the 10-100+ Gbps speeds You are vastly underestimating AES-NI. Most modern Intel CPUs can handle that kind of encryption throughput (when paired with fast enough memory). Even my old Sandy Bridge-E CPU from 2011 gives me ~96 Gbps of AES throughput (with quad channel memory).

I was replying to a question about whether or not you could encrypt the links between the datacenters, where you typically you have large core/cluster routers that handle traffic entering and leaving your datacenter. I was talking about the fact that these routers have dozens or hundreds of 10-100 Gbps ports on them, and are simply not built to do line rate IPsec on each port. So you can't just turn on IPsec for the routers at your datacenter border and magically get encrypted transport between your datacenters.

You can setup IPsec tunnels on your application nodes and use that to get transparent encryption of all traffic, but that is pretty complicated to configure and manage. It's much easier to just have your different applications use an encrypted and authenticated transport when talking to each other over the network, whether they are in the same datacenter, or talking to a remote datacenter. This is how Google and Facebook do their cross datacenter encryption.

Post reply on HN