Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arxiv.org

Post reply on HN
Print view View original

131–140 of 165 posts

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

#131

Post by Dylan16807 »

epistasis wrote: post #130
Dylan16807 wrote: post #128

Earlier quoted context omitted.

With things like kernel bypassing and bulk packet processing it's really not that hard to get to 10gbps on a single server. Heck, linux is getting close to ready for 100gbps https://lwn.net/Articles/629155/ I don't know exactly what resources IPSEC takes, but you can definitely get the "or similar" part of the question. AES-NI takes 3.5 cycles per byte. BLAKE2 takes 3.08 cycles per byte. That means that 2-2.5 cores c…

It's easy to get 10Gbps packet handling on Linux or FreeBSD, it's easy to encrypt at >10Gbps on Intel, but I would love to know how to get both into a working situation IPsec solution at >10Gbps. Speculation isn't interesting, because clearly all the pieces should work, so I'm looking for anybody with actual experience with it working. I've tried, and been unsuccessful, and also unable to find anybody else on the int…

Is IPsec a hard requirement?

I would expect it to be easier to encrypt and sign a megabit at a time instead of individual packets.

I'm having trouble picturing a situation where it has to be IPsec and it also has to be 10Gbps on a single box.

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

#132

Post by epistasis »

Dylan16807 wrote: post #131
epistasis wrote: post #130

Earlier quoted context omitted.

It's easy to get 10Gbps packet handling on Linux or FreeBSD, it's easy to encrypt at >10Gbps on Intel, but I would love to know how to get both into a working situation IPsec solution at >10Gbps. Speculation isn't interesting, because clearly all the pieces should work, so I'm looking for anybody with actual experience with it working. I've tried, and been unsuccessful, and also unable to find anybody else on the int…

Is IPsec a hard requirement? I would expect it to be easier to encrypt and sign a megabit at a time instead of individual packets. I'm having trouble picturing a situation where it has to be IPsec and it also has to be 10Gbps on a single box.

The original question referenced strongswan, which is IPsec, and where my investigations have focused in the past. But as I understand it strongswan is just for key exchange, and the decryption is still performed in the kernel, and often single-threaded.

It's easy to pass 10Gbps of TLS packets over a link with both sides of the connection doing their own encryption. But if you want to secure against possible unencrypted packets passing over a link, you'd want layer 3 or layer 2 encryption as well. Layer 2 means abstruse hardware, layer 3 means encapsulation of some sort, be it IPsec or whatever. That encapsulation is what I believe that kernels can not currently handle, though they should theoretically be able to. FreeBSD has made some noises about improvements to parallelization to support multi-gigabit IPsec, but I haven't been able to test them.

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

#133

Post by late2part »

epistasis wrote: post #130
Dylan16807 wrote: post #128

Earlier quoted context omitted.

With things like kernel bypassing and bulk packet processing it's really not that hard to get to 10gbps on a single server. Heck, linux is getting close to ready for 100gbps https://lwn.net/Articles/629155/ I don't know exactly what resources IPSEC takes, but you can definitely get the "or similar" part of the question. AES-NI takes 3.5 cycles per byte. BLAKE2 takes 3.08 cycles per byte. That means that 2-2.5 cores c…

It's easy to get 10Gbps packet handling on Linux or FreeBSD, it's easy to encrypt at >10Gbps on Intel, but I would love to know how to get both into a working situation IPsec solution at >10Gbps. Speculation isn't interesting, because clearly all the pieces should work, so I'm looking for anybody with actual experience with it working. I've tried, and been unsuccessful, and also unable to find anybody else on the int…

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 machine. So I could ensure that all the traffic passing through with it.

The practical use case is to encrypt traffic between data centers. I don't see a feasible way to do that on a megabyte at a time. It almost certainly has to be done on a per packet basis. Either at the application which is a little bit difficult to do in the short-term, or in some sort of IP sec or other similar solution.

No question that the right solution here is to make all the applications do encryption, but again, I need to have a practical solution now, and then the developers can put that in.

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

#134

Post by [deleted] »

baudehlo wrote: post #103
cbhl wrote: post #58

Earlier quoted context omitted.

But SMTP with TLS is opportunistic -- and if we're talking "national state secrets" it's trivial for a state to MITM the connection and do a TLS downgrade attack.

Not if the receiving smtp server implements DMARC

[deleted]

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

#135

Post by mikeokner »

nailer wrote: post #84
Decade wrote: post #46

Backwards compatibility is the killer. The whole design of PGP is to be the envelope to make email private, versus the plaintext postcard that everybody can read. It works with existing servers and existing mail clients. The biggest Snowden revelation is the importance of metadata. Just knowing whom you talk to, when, is frequently enough to compromise the parties involved. You might be doing something legal now, but…

Anyone on HN know what Signal does for envelope encryption? AFAICT it's the only crypto app that's OSS and still cares about usability.

I'm reasonably certain all communication with the routing servers is done via https. You could double check their source on GitHub

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

#136

Post by epistasis »

late2part wrote: post #133
epistasis wrote: post #130

Earlier quoted context omitted.

It's easy to get 10Gbps packet handling on Linux or FreeBSD, it's easy to encrypt at >10Gbps on Intel, but I would love to know how to get both into a working situation IPsec solution at >10Gbps. Speculation isn't interesting, because clearly all the pieces should work, so I'm looking for anybody with actual experience with it working. I've tried, and been unsuccessful, and also unable to find anybody else on the int…

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 tunnels. Each individual stream will still be capped at ~1Gbit, but at least the total throughput could be used and there's no traffic between the two endpoints that's not encrypted.

However, getting Quagga + BGP + ECMP + multiple IPsec tunnels + pinning tunnels to particular cores + setting up the RSS flows from the NIC to particular cores... Well it was a bit more than I could bite off at the time. The pieces feel sooo close to working, but it becomes a Rube Goldberg machine of systems software, with each piece operating at the limit of its design properties.

And honestly, I kind of want two orthogonal encryption technologies; TLS has bugs every other day it seems, and IPsec has always seemed a little bit suspicious, and really who knows if my random numbers are really random, so I wanted two layers.

Please do share if you make any progress!

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

#137

Post by [deleted] »

late2part wrote: post #133
epistasis wrote: post #130

Earlier quoted context omitted.

It's easy to get 10Gbps packet handling on Linux or FreeBSD, it's easy to encrypt at >10Gbps on Intel, but I would love to know how to get both into a working situation IPsec solution at >10Gbps. Speculation isn't interesting, because clearly all the pieces should work, so I'm looking for anybody with actual experience with it working. I've tried, and been unsuccessful, and also unable to find anybody else on the int…

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…

[deleted]

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

#138

Post by bluegate010 »

bhickey wrote: post #48
bluegate010 wrote: post #10

Hey HN, I'm one of the authors on this paper. I'd be happy to answer any questions.

Given the usability and technical problems with PGP, do you think it's worth saving?

For those who value security enough to take the pains to learn the system, yes, it's useful. For your average netizen, we feel a progressive approach would be more effective. Start out with a key escrow service and if the user wants more security, they can ratchet up to PGP.

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

#139

Post by bluegate010 »

diafygi wrote: post #40
bluegate010 wrote: post #10

Hey HN, I'm one of the authors on this paper. I'd be happy to answer any questions.

> 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.

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

#140

Post by lisper »

luvz2code wrote: post #85
mbrock wrote: post #43

Earlier quoted context omitted.

I just tried it and it seems like a pretty good start! It doesn't seem to have launched publically yet but I hope they will have a landing page with utterly clear copy in a large font written with the mindset that for example this sentence "Once you have entered your email address, SC4 will automatically provision you with a set of random keys." is terrifyingly incomprehensible gobbledygook. ...actually I might be co…

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.)
Post reply on HN