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

A thorough PGP tutorial

futureboy.us

Post reply on HN
Print view View original

91–100 of 115 posts

Re: A thorough PGP tutorial

#91

Post by qnrq »

riquito wrote: post #83
qnrq wrote: post #82

Earlier quoted context omitted.

Check the links posted in the comment you replied to, it's not cryptography in JavaScript: it's JavaScript posting to a httpd on user's localhost which bridges GnuPG. It's not for doing cryptography in JavaScript, it's for doing cryptography in GnuPG and passing it through a httpd which the js talks to. But yes there is JS crypto in the project, as a planned separate optional driver.

Maybe I misinterpreted. 1) you connect to server A 2) you want to encrypt sensitive informations. You send them to (localhost) B 3) you receive encrypted data 4) you use them through server A Aren't you sending sensitive informations though javascript served by server A? Didn't you just loose the security that you wanted by encrypting on localhost?

"Didn't you just loose the security that you wanted by encrypting on localhost?"

No, the sensitive information isn't being protected from localhost but from server A and anything else on the path between user and message destination. localhost is the user. For clarification: GPG is on user's localhost, not the server.

1. Alice uses a web app served by server A

2. Alice wishes to send an encrypted message through the web app served by server A to Bob

3. Alice writes the message on her client sided browser

4. Alice finishes and clicks "Send"

5. The web app's client sided code, JavaScript, sends the message to Alice's pygpghttpd listening on localhost

6. pygpghttpd responds with the ciphertext to Alice's web browser

7. Alice's web browser replaces the cleartext content with the encrypted content

8. The encrypted content is sent to server A to be routed to Bob

---------------

1. Bob receives encrypted message from Alice on web app served by server 1

2. Web app's client sided JavaScript sends the encrypted message to Bob's pygpghttpd listening on Bob's localhost

3. pygpghttpd responds with the decrypted message

4. The decrypted message is rendered for Bob

Re: A thorough PGP tutorial

#92

Post by xradionut »

TillE wrote: post #90
xradionut wrote: post #84

Earlier quoted context omitted.

You can improve the written documentation with diagrams or produce a graphic novel for the reading impaired.

I've been using Enigmail for about a decade, and PGP longer than that, and I still think it's a pain in the ass. Whenever I'm configuring a new mail client, I have to fiddle with multiple settings just to get it to send encrypted mail. There's a real opportunity to build something much, much simpler on top of PGP. All you really have to do is pick some sensible defaults and automate a few steps. Look at how many nerd…

Making GPG and programs that use it easier to use would be nice. But the primary issue is that many people that should be able to comprehend PKI basics and necessary background material to use it, are too "busy" or "lazy" to spend the limited time to even scratch the surface.

I face this daily, since I'm the go-to guy at my office for scripting/coding solutions for these folks. They just want it to work without having to learn or understand their decisions. And these are the same people that will spend hours figuring out complex lunch accounting issues or read volumes on video game strategies or rebuild engines.

Re: A thorough PGP tutorial

#93

Post by DanBC »

TillE wrote: post #90
xradionut wrote: post #84

Earlier quoted context omitted.

You can improve the written documentation with diagrams or produce a graphic novel for the reading impaired.

I've been using Enigmail for about a decade, and PGP longer than that, and I still think it's a pain in the ass. Whenever I'm configuring a new mail client, I have to fiddle with multiple settings just to get it to send encrypted mail. There's a real opportunity to build something much, much simpler on top of PGP. All you really have to do is pick some sensible defaults and automate a few steps. Look at how many nerd…

I mostly agree, except there are some perils involved.

Bob has to make sure that the public key he thinks is Ann's really truly is Ann's, and not Eve's.

That would be a hard problem to solve.

Re: A thorough PGP tutorial

#94

Post by s-phi-nl »

lemming wrote: post #51
tptacek wrote: post #46

Earlier quoted context omitted.

My prediction is that the kernel of the idea that will make GPG usable is to dispense with the idea of a single keypair, and instead build features that generate ephemeral keypairs on the fly. Make the system workable for users even if they don't understand what a keypair is. Some of what makes OTR effective can be implemented using PGP as the underlying cryptosystem. When one suggests replacing OTR, one tends to get…

There are strong cryptographers who are working on much, much better systems than PGP. Could you give us some examples of these? How far away from prime time usage do you estimate they are? Are any of them usable right now?

I know tptacek was talking about systems still under development, but I immediately thought of DJB's NaCl (http://nacl.cr.yp.to/) when I read that statement.

Re: A thorough PGP tutorial

#95

Post by tptacek »

nikcub wrote: post #72
tptacek wrote: post #56

Earlier quoted context omitted.

CAs are a single point of failure if a government can get a key that your counterpart's UI will claim belongs to you.

then don't trust government controlled CA's, just as you wouldn't trust government controlled keyservers

The argument in favor of S/MIME is that it's already there and just works.

Re: A thorough PGP tutorial

#96

Post by tptacek »

tricolon wrote: post #60
tptacek wrote: post #52

Earlier quoted context omitted.

I would if I could, but another distinction between real cryptographers and amateur ones is a desire not to publicize things until the design is trustworthy. I think you'll have to take my word for this (but I'll try to think of one I can share).

Are they better in that they are easier to use (and thus promote security)?

What does this mean? We just got finished talking about a system that was profoundly less secure because it tried too hard to be easy to use.

Re: A thorough PGP tutorial

#97

Post by tptacek »

xradionut wrote: post #84
tptacek wrote: post #45

Earlier quoted context omitted.

It still requires users to understand that they have a public and a private key, and just one of them, and a "key ring" to which they add their counterparties public keys, and that those keys themselves have to be authenticated and "signed" if the system is to be secure.

You can improve the written documentation with diagrams or produce a graphic novel for the reading impaired.

You can do all that stuff, but it's the fact that you have to understand these concepts to use PGP that makes it difficult, not the way they're documented.

Re: A thorough PGP tutorial

#98

Post by DanBC »

tptacek wrote: post #96
tricolon wrote: post #60

Earlier quoted context omitted.

Are they better in that they are easier to use (and thus promote security)?

What does this mean? We just got finished talking about a system that was profoundly less secure because it tried too hard to be easy to use.

I understand this discussion is about avoiding snake oil, and only using good quality trusted respected systems, and using them carefully, but making them easier to use.

Some examples from PGP include Bob signing Ann's key without sufficient verification, or people publishing their private and public keys by accident.

Remembering that many people are just hopeless at security ('123456' used as passwords; people clicking through browser certificate warnings; people installing malware and ignoring OS warnings about untrusted sources) it seems a reasonable point to make: "Secure products can be made easier to use, and if they are both good and easy to use it will enhance security".

Re: A thorough PGP tutorial

#99

Post by Tomte »

rahoulb wrote: post #89
Tomte wrote: post #76

Earlier quoted context omitted.

Doesn't help. First, I'm not remotely interested in running my own mail infrastructur anymore. Been there, done that. Today it's much too hard to get mails accepted by others. But more important: iPads don't have an USB connector, my mobile phone doesn't have one. Friends have Macs, in other places there might be other crippled devices. The web is a universal building block. USB sticks are not.

I use Lastpass, which has a client for most platforms. They could be compromised, but they claim all data is encrypted locally before being sent to their servers. I have not verified that claim.

A password manager does not encrypt or sign mails.

Re: A thorough PGP tutorial

#100

Post by Joeboy »

qnrq wrote: post #91
riquito wrote: post #83

Earlier quoted context omitted.

Maybe I misinterpreted. 1) you connect to server A 2) you want to encrypt sensitive informations. You send them to (localhost) B 3) you receive encrypted data 4) you use them through server A Aren't you sending sensitive informations though javascript served by server A? Didn't you just loose the security that you wanted by encrypting on localhost?

"Didn't you just loose the security that you wanted by encrypting on localhost?" No, the sensitive information isn't being protected from localhost but from server A and anything else on the path between user and message destination. localhost is the user. For clarification: GPG is on user's localhost, not the server. 1. Alice uses a web app served by server A 2. Alice wishes to send an encrypted message through the…

> 5. The web app's client sided code, JavaScript, sends the message to Alice's pygpghttpd listening on localhost

So either you're trusting the web app's js, or there's some other unspecified mechanism for ensuring that it's behaving in a trustworthy way.

Post reply on HN