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

71–80 of 115 posts

Re: A thorough PGP tutorial

#71

Post by tehwalrus »

Tomte wrote: post #57

I have played with GPG time and again, my Enigmail/Thunderbird/OpenPGP card setup is fully functional. But what's holding me back is webmail. I don't use the web interface often, but it has proven to be absolutely crucial to be able to get some important mail (boarding pass, mail explaining how to get somewhere etc.) from any computer.

you need a cross-platform USB stick program, with all your secrets on it encrypted properly, for that kind of thing. (The simplest hack I can think of would probably be python binaries, with a local-webserver based interface.)

I don't know of such an application, or whether the approach is rigorous, I'm afraid. But I think that's the shape of the solution.

Re: A thorough PGP tutorial

#72

Post by nikcub »

tptacek wrote: post #56
rmoriz wrote: post #42

Earlier quoted context omitted.

CAs are not a single point of failure because your private key should never leave your computer. S/MIME is based on X.509, same thing that powers TLS/SSL.

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

Re: A thorough PGP tutorial

#73

Post by bigiain »

qnrq wrote: post #66
jakejake wrote: post #64

Earlier quoted context omitted.

Allow me to pimp my own lib which might be useful since roundcube is PHP: https://github.com/jasonhinkle/php-gpg I'm working on encryption and signing as well. Key generation would be nice as well. I need a little help with it though.

My plugin does nothing crypto based on the server side, everything is happening locally in the browser through JavaScript and in the future there will be an additional driver for performing crypto opts in GPG binaries as described in my comment above. I don't mean to be harsh but server sided crypto is far from a good idea. It provices violent regimes, such as America, a technical ground to force hosts into backdoori…

Given that practically all (to at least 4 significant digits) of my mail arrives at the mail server un-encrypted,I think there's still some value in encrypting it before the server stores it. I'm setting up some perl scripts to help exim encrypt to my public key any non-encrypted mail before it delivers it into the local mailbox. That's still subvert-able by anybody with enough power to lean on the hosting company, but then all that mail was interceptable in transit anyway - at least I've made sure that stored archives on the hosted server aren't in cleartext.

I'm also considering setting up some scripts for outbound mail - to automatically encrypt any (non-encrypted) mail I send if I've ever received encrypted mail from the recipient. Have the mail server keep a record of email addresses and public keys, and auto encrypt where possible.

(And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfortable having my private keys and passphrases hanging around in the process space where rogue javascript and/or plugins might be able to scoop them up…)

Re: A thorough PGP tutorial

#74

Post by qnrq »

bigiain wrote: post #73
qnrq wrote: post #66

Earlier quoted context omitted.

My plugin does nothing crypto based on the server side, everything is happening locally in the browser through JavaScript and in the future there will be an additional driver for performing crypto opts in GPG binaries as described in my comment above. I don't mean to be harsh but server sided crypto is far from a good idea. It provices violent regimes, such as America, a technical ground to force hosts into backdoori…

Given that practically all (to at least 4 significant digits) of my mail arrives at the mail server un-encrypted,I think there's still some value in encrypting it before the server stores it. I'm setting up some perl scripts to help exim encrypt to my public key any non-encrypted mail before it delivers it into the local mailbox. That's still subvert-able by anybody with enough power to lean on the hosting company, b…

That's a valid point, but you won't be effectively encrypt incoming email in the layer of a webmail client. You'd be better off incorporating that before the message is even saved to disk - in the mail delivery of your MTA. So once again it wouldn't be PHP (I hope for your sake!).

"(And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfortable having my private keys and passphrases hanging around in the process space where rogue javascript and/or plugins might be able to scoop them up…)"

Your sarcasm is entirely valid, but you didn't actually look at the project that you are criticizing. The entire point of what I linked in my comment is that nothing critical should be exposed to the JavaScript, just an API that it can interact with to send commands to: such as keygen, verify this message, send cleartext and receive ciphertext in response, etc. You're preaching to a believer here, :-)

Your ~/.gpg/ is -not- accessible to JavaScript. The interface, the GnuPG binary, is. That's the point. Now we can both agree that exposing private keys in such an API is a bad idea.

Re: A thorough PGP tutorial

#75

Post by bigiain »

qnrq wrote: post #74
bigiain wrote: post #73

Earlier quoted context omitted.

Given that practically all (to at least 4 significant digits) of my mail arrives at the mail server un-encrypted,I think there's still some value in encrypting it before the server stores it. I'm setting up some perl scripts to help exim encrypt to my public key any non-encrypted mail before it delivers it into the local mailbox. That's still subvert-able by anybody with enough power to lean on the hosting company, b…

That's a valid point, but you won't be effectively encrypt incoming email in the layer of a webmail client. You'd be better off incorporating that before the message is even saved to disk - in the mail delivery of your MTA. So once again it wouldn't be PHP (I hope for your sake!). "(And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfor…

On the incoming email encryption - yeah, that's in the MTA not the webmail software - having said that, I'm basing what I'm doing off this: https://grepular.com/Automatically_Encrypting_all_Incoming_E... at least partly because Perl is my goto hack-shit-together langiage, I could _easily_ imagine a lot of my cow-orkers choosing to do that in php.

And yeah, I hadn't followed your links, and made poor assumptions about your project. I just briefly skimmed through some of them and I've got a question - have you got a way to protect the passphrase from ending up somewhere the browser can see it? (or, if the decryption is "passphraseless" from the browsers point of view, how do you ensure rogue javascript could pass encrypted data in and retrieve cleartext?)

Re: A thorough PGP tutorial

#76

Post by Tomte »

tehwalrus wrote: post #71
Tomte wrote: post #57

I have played with GPG time and again, my Enigmail/Thunderbird/OpenPGP card setup is fully functional. But what's holding me back is webmail. I don't use the web interface often, but it has proven to be absolutely crucial to be able to get some important mail (boarding pass, mail explaining how to get somewhere etc.) from any computer.

you need a cross-platform USB stick program, with all your secrets on it encrypted properly, for that kind of thing. (The simplest hack I can think of would probably be python binaries, with a local-webserver based interface.) I don't know of such an application, or whether the approach is rigorous, I'm afraid. But I think that's the shape of the solution.

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.

Re: A thorough PGP tutorial

#77

Post by bigiain »

qnrq wrote: post #74
bigiain wrote: post #73

Earlier quoted context omitted.

Given that practically all (to at least 4 significant digits) of my mail arrives at the mail server un-encrypted,I think there's still some value in encrypting it before the server stores it. I'm setting up some perl scripts to help exim encrypt to my public key any non-encrypted mail before it delivers it into the local mailbox. That's still subvert-able by anybody with enough power to lean on the hosting company, b…

That's a valid point, but you won't be effectively encrypt incoming email in the layer of a webmail client. You'd be better off incorporating that before the message is even saved to disk - in the mail delivery of your MTA. So once again it wouldn't be PHP (I hope for your sake!). "(And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfor…

Oh, and I hadn't intended "sarcasm", apologies if it came off that way - I'd expected to be more likely accused of paranoia... I've actually got PGP and encfs installed and testing on my iPhone & iPad, but I've not managed to convince myself it's "safe" to put real (as opposed to "just created to see if this works") private keys for either of them onto an iOS device, with all the lack of transparency about who's actually "in control" of those devices.

While I'm reasonably sure GPG/encfs on my phone will reduce my exposure to "dragnet style, intercept and archive everything" surveillance, if the NSA are after _me_, I've no doubt that there are people at the NSA who've already worked out how to coerce Apple into pushing a software update to my phone that sniffs around with root access looking for things that look like private keys, and keylogs things that look like passphrases - and ships them all off to Utah.

(And, truth be told, I strongly suspect all my Windows and Mac OS X boxes would fall in exactly the same fashion, and it wouldn't surprise me too much to find the firmware in my bios or USB bridge or ethernet adaptor or hard drive on my linux boxes is equally traitorous and ready to "sell me out"…)

Re: A thorough PGP tutorial

#78

Post by DanBC »

joshuak wrote: post #27
jarrett wrote: post #14

There have been several calls in recent weeks for a nice UX wrapping GPG. I'm thinking of what Cryptocat aims to be, but with a sound implementation resting on GPG. The crypto community seems supportive of this idea. I'm not saying I'd be the one to implement this, but at the vert least, I'd like to start collecting ideas. Maybe I or someone else could realize them eventually. So let's talk. Please post your thoughts…

I don't understand why webmail seems to be such a conundrum for everyone. Can't we just write plugins that looks for encrypted messages, and signatures in a page or ajax request and if you have the key in your keychain you get promoted for it. It seems like this would be an even easier plugin then the Mail.app one. That being said I think the real solution is OS level integration. Perhaps a facebook app to help grand…

There's some stuff about trust of keys. When Alice uses Bob's public key she has to know that it actually is Bob's key.

Looking at other password / certificate mistakes (people use 123456 as a password for important accounts, people click through warnings) I think this might be harder than it seems.

See for example some of the hoax accounts on Twitter. People do get confused, even though it should be easy enough to spot the real account over the hoax account.

Online reputation and trust is important. It's a shame that Klout (totally irrelevant to this) is what most people think of when I say 'online reputation'.

Re: A thorough PGP tutorial

#79

Post by qnrq »

bigiain wrote: post #75
qnrq wrote: post #74

Earlier quoted context omitted.

That's a valid point, but you won't be effectively encrypt incoming email in the layer of a webmail client. You'd be better off incorporating that before the message is even saved to disk - in the mail delivery of your MTA. So once again it wouldn't be PHP (I hope for your sake!). "(And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfor…

On the incoming email encryption - yeah, that's in the MTA not the webmail software - having said that, I'm basing what I'm doing off this: https://grepular.com/Automatically_Encrypting_all_Incoming_E... at least partly because Perl is my goto hack-shit-together langiage, I could _easily_ imagine a lot of my cow-orkers choosing to do that in php. And yeah, I hadn't followed your links, and made poor assumptions about…

The questions that you raise is of course what I am interested in discussing. I can't think of any way that PGP/GPG protects you against keyloggers or a pre-infected computer. I agree that they are relevant threats but my question is if it's up really to the developers to prevent rogue JavaScript in third party software and user's localhost. The same threats can be applied on all existing cryptosystems, as for with one-time pads where someone could look you over the shoulder - but that itself is not considered to break the underlying strength of the design. Or another example, how does Enigmail for Thunderbird protect you against having code injected and keys stolen? I don't think it does, but Enigmail isn't considered insecure. I think the questions are fair to raise but I see them raised far more often when people confront new ideas in comparasion to established practice, which I truthfully consider is a bit unfair judgement.

One of the factors which can narrow the scope of attackers is to use products like crypto stick, but then again what is preventing a computer from being rootkitted and having it's keys stolen as soon as they are exposed in the system?

Developers can of course only address weaknesses in what they have control over. We can't stop your computer from being infected by neither rootkits nor rogue JavaScript from plugins that you have volontarily installed. My advice would be to be careful and audit everything that may be a threat in order to at least try and minimize the risks. Unfortunately I don't think many users do that but it's not something we as developers can address and prevent.

The dilemma here is the same as with filesharing: if it's accessible it can be copied and transferred. There's no patch against that.

Re: A thorough PGP tutorial

#80

Post by riquito »

qnrq wrote: post #62
jarrett wrote: post #14

There have been several calls in recent weeks for a nice UX wrapping GPG. I'm thinking of what Cryptocat aims to be, but with a sound implementation resting on GPG. The crypto community seems supportive of this idea. I'm not saying I'd be the one to implement this, but at the vert least, I'd like to start collecting ideas. Maybe I or someone else could realize them eventually. So let's talk. Please post your thoughts…

Hi, I'm glad I found your comment, I just pushed something like what you just described to one of my repos yesterday. Hear me out, I'm not self promoting myself out of context here. I'm currently working on an OpenPGP integration for the Roundcube webmail project and have so far added functionality from the OpenPGP.js library. The pros of this is of course usability and that no external applications are necessary, th…

You can't do cryptography in Javascript (yet). There is no point in encrypting client side if

1) the server provided the cryptographic libraries (so they may be compromised)

2) every kind of javascript code external to the crypto library can modify it, modify the environment, read everything that is passed around

I don't know how the not yet standardized window.crypto will adress 2), but as of now you can't trust DOM level encryption.

Post reply on HN