Live data from Hacker News

A thorough PGP tutorial

futureboy.us

61–70 of 115 posts

Re: A thorough PGP tutorial

#61
post #56
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.

Not necessarily true. There are certainly CAs that are able to keep their private keys out of the hands of most governments. But there is definite uncertainty about who to trust. For the truly cautious, wouldn't it make sense to explore setting up your own CA? Something like OpenCA or TinyCA should do the trick.

Re: A thorough PGP tutorial

#62
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, the cons are, amongst others, what you just wrote above.

To be able to support briding local GPG binaries and keyrings into graphical browsers without exposing any critical information I threw together an HTTPD which listens on the client's localhost. The concept is already proven to work, now it's a mere matter of implementation. It's based on the PyGPG library which wraps GPG into Python and is compatible with both Windows and *NIX systems as long as they can execute GPG and Python (which they can).

It's still a work in progress but currently supports key generation and key listing in response to HTTP requests. Through cross-origin resource sharing users can specify which domains should be allowed to speak to it in a simple text file separated by line breaks.

I wrote up more detailed info on the approach and usage here: https://github.com/qnrq/rc_openpgpjs/issues/64#issuecomment-... Source code currently available here, although it will be separated to its own repository later: https://github.com/qnrq/rc_openpgpjs/blob/pygpghttpd/pygpght...

I can conclude that what you are requesting is actively being built and partially already exists but still needs to be put to use. Hope you don't view this as shameless advertising, because it's not. I'm only responding because your ideas are spot on what I pushed yesterday.

Any form of feedback is greatly appreciated.

Much love!

Re: A thorough PGP tutorial

#63
post #47

The tutorial makes no mention of sub-keys. I thought using sub-keys was a generally accepted good practice? The use-case being that if the sub-key is compromised, you can invalidate it and issue a new one -- and others who trust the root don't need to update much. Is that still the case? Was it ever? I don't know enough about PGP to know, unfortunately.

Yes, using subkeys and rotating them is good practice. But really the hardest problem with pgp is getting people to use it in the first place, so let's not focus on subkey use, or upgrading from sha1 to sha256 (or better), or key length (the author uses 1024 bits only).

Though I'm not sure why the author focuses on non-threats like known plain text attacks, which gpg isn't vulnerable to, and not these issues.

Re: A thorough PGP tutorial

#64
post #62
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…

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.

Re: A thorough PGP tutorial

#65
post #4

Scary bit is it's not server on HTTPS, which is probably a must-have for sites that publish public-key information. Much easier to MITM attack the site and claim to be posting "his" public key and email address while really publishing your own info, etc. A great tutorial, however. Very accessible in my opinion and considering it's purpose my previous paragraph is more of an aside.

Install gpg-curl, use hkps (TLS key exchange)

https://we.riseup.net/riseuplabs+paow/openpgp-best-practices...

Edit: nevermind, i see you meant the site with the tutorial, not key exchange

Re: A thorough PGP tutorial

#66
post #62

Earlier quoted context omitted.

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…

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 backdooring their server sided crypto. Anything alike must be done on the client for safety and privacy to be ultimately achieved.

You should rethink that design strongly.

Re: A thorough PGP tutorial

#67
post #61
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.

Not necessarily true. There are certainly CAs that are able to keep their private keys out of the hands of most governments. But there is definite uncertainty about who to trust. For the truly cautious, wouldn't it make sense to explore setting up your own CA? Something like OpenCA or TinyCA should do the trick.

You're missing the point. If the UI says "yes, that's 23david" if I can get any CA to certify that, the security of the system is no better than that of the weakest CA. Sure, your CA may be perfect, but why would the attacker go for the strongest point?

Re: A thorough PGP tutorial

#68
post #46
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…

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…

> It's also worth saying that PGP isn't a particularly great cryptosystem. "Modern" PGP predates a lot of important stuff in crypto. But it's a very well studied cryptosystem.

Is there anything available today that you'd recommend over PGP, regardless of usability or ubiquity? e.g., if one has to include crypto inside an internal-use only email product, that requires both encryption and/or signatures - what's an alternative to PGP that would be considered reliable?

Re: A thorough PGP tutorial

#69
post #66

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…

[deleted]

Re: A thorough PGP tutorial

#70
post #61

Earlier quoted context omitted.

Not necessarily true. There are certainly CAs that are able to keep their private keys out of the hands of most governments. But there is definite uncertainty about who to trust. For the truly cautious, wouldn't it make sense to explore setting up your own CA? Something like OpenCA or TinyCA should do the trick.

You're missing the point. If the UI says "yes, that's 23david" if I can get any CA to certify that, the security of the system is no better than that of the weakest CA. Sure, your CA may be perfect, but why would the attacker go for the strongest point?

So perhaps that's an issue with the UI not clearly showing which CA is verifying the identity, and alerting you clearly if an encrypted email is using a different CA than prior ones.

Depending on the client you're using, it shouldnt be too hard to prune the trusted CA list to only include providers you choose to trust. If you want, only include your CA and remove all others.

Post reply on HN