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

121–130 of 165 posts

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

#121

Post by elipsey »

dlitz wrote: post #120
elipsey wrote: post #118

Earlier quoted context omitted.

Should we trust the implementation of AES-NI in this context? http://arstechnica.com/security/2013/12/we-cannot-trust-inte...

AES-NI and RDRAND are different beasts. AES-NI is deterministic, and thus much more difficult to practically backdoor.

Sorry if this is a dumb question, I'm just trying to think it through. It seems like it has to use the key you give it; it seems like the output stream has to be correct, or it just won't work.

I'm not really sure how this would work for network traffic, I guess for disks I would expect CBC mode, which would require an IV? Is that right?

So could the hardware be made to expose the key, or IV's, or leak information in some unexpected way?

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

#122

Post by kristopolous »

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…

My idea has been to have a system that works on top of email but sends out "fraud" email to other participants in the network. The encrypted payload gets unencrypted at each endpoint and has a marker as to whether it was, what i call a "fuzzer" email, in which case it's discarded - otherwise it gets graduated to the users inbox.

Under this system, Eve will see Alice exchanging encrypted messages with Bob and Carol but won't know if they're automated dummy messages or authentic communication.

It lowers the information fidelity through an intentional introduction of noise.

The "fuzzing model" has wide use cases: for instance, a web browser can programmatically "browse" a variety of websites so that Eve can't tell what Alice is truly looking at. Every user in a system will have "red flag" websites in the "auto browse" list.

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

#123

Post by epistasis »

Dylan16807 wrote: post #115
late2part wrote: post #75

Earlier quoted context omitted.

Correct. And now they encrypt all the inter-data center traffic. Question: Is that done on an end-to-end basis? Or do they encrypt the links between data centers? I want to encrypt a 10g ethernet and all the solutions look quite expensive. Has anyone done high speed encryption (i.e. 10gbps/1500 byte packets) with strongswan or similar?

With hardware acceleration, my quad core laptop can encrypt faster than 20gbps. Without it, it can still encrypt at at 4gbps. I was going to suggest you could place a couple servers at each end, but you only need one low end server. Anyone offering expensive solutions is doing you a disservice.

Is that at the network level? My experience is that packet handling in Linux and FreeBSD does not make high speed IPsec feasible.

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

#124

Post by anonbanker »

x5n1 wrote: post #11
squidlogic wrote: post #9

I think of it like this: usability can be a security feature. If you build a "perfectly secure" piece of software, but it takes a very high level of skill to use it, your users will use something else that is easier to use, but less secure. And then how has your ideologically perfect piece of software helped improve their security? If you make tradeoffs for usability, you will raise the bar because people will actual…

Fork Thunderbird or some such client, also make a web client available. Make a new service which offers only encrypted e-mail by default (with a new e-mail address that includes e-mail hosting for your own domain) and provides the key server and everything else. Advertise it as something different from e-mail like encrypted e-mail. Set a new precedent, create a new industry.

> also make a web client available. Make a new service which offers only encrypted e-mail by default

rainloop[1] already does this.

1. http://www.rainloop.net/

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

#125

Post by sigjuice »

XorNot wrote: post #119
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…

Backwards compatibility has nothing to do with it. No one can read GPG encrypted mail. It isn't built into their clients, they don't by default get their own keypairs, it is simply straight up impossible to send encrypted email to even friends and family and have them be able to read it. Everything else is window dressing to this problem.

How about S/MIME? At least, the programs that I use on a regular basis have it built in. (iOS and OS X Mail, Thunderbird, Outlook). It still does not help at all with the management and distribution of key pairs.

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

#126

Post by epistasis »

elipsey wrote: post #121
dlitz wrote: post #120

Earlier quoted context omitted.

AES-NI and RDRAND are different beasts. AES-NI is deterministic, and thus much more difficult to practically backdoor.

Sorry if this is a dumb question, I'm just trying to think it through. It seems like it has to use the key you give it; it seems like the output stream has to be correct, or it just won't work. I'm not really sure how this would work for network traffic, I guess for disks I would expect CBC mode, which would require an IV? Is that right? So could the hardware be made to expose the key, or IV's, or leak information in…

Leaking an IV isn't a problem, but leaking the key would be a problem. If AES could be made to leak the key it would be a huge problem with the cipher itself. Otherwise leaking the key would be restricted to some extremely complex timing level behavior of the CPU, which would be difficult to make it all the way to the network level, without network card cooperation (though many 10gbps network cards are intel made).

Perhaps feasible, but far far less likely than compromising the entropy of a random number generator.

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

#127

Post by bsdetector »

squidlogic wrote: post #9

I think of it like this: usability can be a security feature. If you build a "perfectly secure" piece of software, but it takes a very high level of skill to use it, your users will use something else that is easier to use, but less secure. And then how has your ideologically perfect piece of software helped improve their security? If you make tradeoffs for usability, you will raise the bar because people will actual…

For instance, Apple's fingerprint reader is not secure because with enough work you can make a mold of somebody's print and fool it. Except now virtually everybody with an iPhone has it set up so that in practice nobody else can access their phone.

Another thing is key generation. Encryption people demand perfect randomness for the key generation, and that means the key is this crucial piece of data that must be perfectly protected and copied about. That's unusable for most people. Instead, pick the key from 1 billion derived from a user's password. If they use a different computer, or reinstall their OS, or whatever reason then the software just takes a while to try each billion until it finds the one that works.

Or encrypted email. For perfect security you need a safe way to exchange keys beforehand and all kinds of trouble. No. Just have software attach your public key in unencrypted email to recipients. If you receive an email with somebody else's public key then the software starts encrypting to them using it. It's insecure in so many ways, but it would mean the majority of email being encrypted and if done right with almost no impact to the user (password-derived keys, password change automatically sending yourself a new-key-encrypted email with the old key, etc).

Security people need to stop seeing things in black and white. Something can be insecure and "broken", yet still raise the overall level security.

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

#128

Post by Dylan16807 »

epistasis wrote: post #123
Dylan16807 wrote: post #115

Earlier quoted context omitted.

With hardware acceleration, my quad core laptop can encrypt faster than 20gbps. Without it, it can still encrypt at at 4gbps. I was going to suggest you could place a couple servers at each end, but you only need one low end server. Anyone offering expensive solutions is doing you a disservice.

Is that at the network level? My experience is that packet handling in Linux and FreeBSD does not make high speed IPsec feasible.

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 can handle all the encryption and signing by themselves. Then you have 80% of the machine's resources free just to shovel packets in and out.

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

#129

Post by vxNsr »

At this point the only way for PGP or really any user-based encryption to get widespread use, gmail, yahoo and microsoft need to adopt it and integrate it into their webmail client, possibly as a semi-mandatory feature that's opt-out instead of opt-in.

Anything less will fail as no one is interested in getting a new email address.

Anecdotally, I've tried three of four times to learn how to use PGP and integrate it into my workflow and failed each time, so it definitely needs work (at least if they want me on board :))

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

#130

Post by epistasis »

Dylan16807 wrote: post #128
epistasis wrote: post #123

Earlier quoted context omitted.

Is that at the network level? My experience is that packet handling in Linux and FreeBSD does not make high speed IPsec feasible.

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 internet that has been successful.
Post reply on HN