Live data from Hacker News

GPG and Me

thoughtcrime.org

221–230 of 267 posts

Re: GPG and Me

#221

Earlier quoted context omitted.

I'd recommend going base32 instead of base64 (case sensitivity won't screw anything up) and not padding with = characters. I know not padding violates RFC 4648 but I don't know anyone who's used to a = in their email address.

Base32 would be too long, but maybe the equals sign could be elided, yeah.

Base58 it is, then (no non-alphanumeric characters so you can double click and it will select the whole string, no similarly-looking characters you could mistype (1 and l, 0 and O...))

(https://en.wikipedia.org/wiki/Base58)

Re: GPG and Me

#222
post #90

Earlier quoted context omitted.

What do you think that looks like, though? Is it TextSecure on the desktop, with file attachments? Is it Pond? Is it just email, but with a different crypto layer? I feel like a lot of the things GPG aims to do are fundamentally hard. It's not the technology that sucks, it's the problem . I completely agree that the answer will come from thinking about user interactions first, but I'm not sure that the solution will…

I don't have a definite answer. There's the path we're executing on at Open Whisper Systems, but there are a bunch of other projects working in this area as well (Mailpile, LEAP, etc). I think the problems are solvable, but only if we have a different design approach. So when I see projects trying not-PGP, I'm interested. When I see projects building on PGP, I'm less interested.

What do you think of Peerio?

Also, any vague timeline available for arrival of the desktop Signal version? What about video-chat support? Would that be possible with WebRTC? (although you should probably wait until ORTC is supported within WebRTC - v1.1 I think?) and then add ZRTP on top of it. Or is a desktop, Javascript version, just not secure enough for that to happen? What if you do it like Whatsapp's "web app", that basically only connects locally to the phone?

Re: GPG and Me

#223
post #88
post #54

Earlier quoted context omitted.

There's no other model than the web-of-trust. And it didn't fail because it's hard to grap (it's really not), it failed because a) almost no one needs it and b) the tech is hard to use. Imagining a world where the web-of-trust was succesful is not hard. It starts with everyone using Outlook instead of gmail. Then imagine Outlook having PGP support builtin. Then imagine in the contacts list, every contact was marked w…

> There's no other model than the web-of-trust. SPKI & SDSI had a different model: rather than trust people to tell you who someone is, one trusts them to tell you who they think they are. That is, rather than me verifying that key 0xDEADBEEF belongs to the individual known to the town council of Lower Shroppington as 'William Morris' (which is inherently fragile: I may not be an expert at verifying identity document…

So that's the authority model, or the 'tree-of-trust'. In a good trust model I think it can't be more than just a weighting or advisement over your web-of-trust, never your sole source of trust.

In the end a tree-of-trust rests on the fact that you trust the manufacturer of your laptop that they put trustworthy certificates there so you could verify the roots.

We're seeing the major browsers now turning that tree-of-trust into a web-of-trust by cross referencing domain certificates to see if there are duplicates or other shady things going on.

Re: GPG and Me

#224

As a member of the encrypt-everything clique I have to say, though Moxie has a point, Gnupg is infinitely better than alternative of nothing at all. Until someone comes up with a solution that preserves its power and flexibility and marries it with a functional UX -- I shall keep using it

I kinda like the solution of embedding public keys in email addresses: name+8znBcmtXJ2ZeSn7fWVCGfpQI9HnJH1pNBPK397SGrT8=@gmail.com Sure, you'll never actually tell someone this, but it's short enough to copy/paste.

Someone has started building this:

https://github.com/diafygi/emailpk

Re: GPG and Me

#225

Earlier quoted context omitted.

One of the biggest problems with GPG is keyex. Sure, we have key servers, but that's not really a secure way of doing things. Secure communication is as much a cultural change as a technological one.

GPG at least has the web of trust, with all its privacy problems. Most technologies just use "trust on first use".

That doesn't actually solve the problem though. It helps in theory, but it requires the user to understand what they're doing to a level most won't.

There is also the cultural issue of just exchanging fingerprints. Only techies put them on business cards, and even then only some. It needs to be common action.

Re: GPG and Me

#226

I am curious as to to know what mail clients people are using with GPG. In OSX I am not a big fan of the native mail client at all but it seems thats the only approach if you want to use GPG. I am currently on a quest to find a decent mail client that looks good and works well and I am currently trialling Airmail 2 but its GPG support is buggy at best.

I use KMail and the GPG integration is beautiful. But I can't speak to what KDE looks like on OSX.

Re: GPG and Me

#228
post #161

Earlier quoted context omitted.

HTTP is '90s tech. TCP/IP is '70s tech. There's nothing inherently wrong with that. 1400 lines of python that tries to pretend that an interactive program is a library is definitely a problem though. How's about this: rather than a protocol-up rewrite, how about just writing a library-up rewrite? Write a ground-up implementation of (maybe a subset of) RFC 4880, with opinionated choices of default ciphers (a bit like…

> HTTP is '90s tech. TCP/IP is '70s tech. There's nothing inherently wrong with that. Sure there is. For one, we were talking about encryption protocols. Those are not encrypted. The one that is encrypted, HTTPS, sucks (the whole CA system). So after Snowden's documents came out I would've expected more people to say "it's time to get rid of HTTPS". That hasn't quite happened yet, and I'm disappointed by that. In cas…

The CA system sucks but what would you replace it with? The only remotely viable alternative candidate is the OpenPGP web of trust, and, well, see the article.

Transport is the wrong layer to do encryption (much as I'd love to see more adoption of IPSec) because encryption and authentication are inextricably linked. Suppose you can confirm that you're absolutely, veritably talking to 174.16.23.46, and your messages can't be read by anyone but them. What good does that actually do you?

TLS is, despite all the problematic cipher suites, fundamentally sound infrastructure - which is why it hasn't been replaced. The same is true of OpenPGP. We don't need new protocols, just better implementations - an equivalent of LibreSSL for OpenPGP.

Re: GPG and Me

#229
post #48

A lot of the comments I've been getting are in the genre of "well... but GPG works." Yes, GPG is a powerful tool that makes some encrypted communication possible . But is it really "working" if it's the tool we've had for the past 20 years, and we still ended up in a world where surveillance is so ubiquitous and privacy is so rare? Having used GPG, it seems more likely to me that there are only ~50k GPG users in the…

What would be needed for adoption and ease of use would be for a registry to store public keys and salts... for webmail, a section of the message could be labelled as something like... [[SECURE_CONTENT abc@ez.im -> foo@bar.com BASE64-CONTENT ===== BASE64-SIGNATURE ]] The a browser or email plugin can then retrieve the public key for abc@ez.im and confirm the body was sent by who it says it was. Then if the user has a…

>The a browser or email plugin can then retrieve the public key for abc@ez.im and confirm the body was sent by who it says it was.

Well, that's the issue, right? How does it do this?

Re: GPG and Me

#230
One of the problems is the constant mantra: "crypto is hard--leave it to the experts", discouraging new tools from being written. Crypto is hard but there's a big community out there to help with auditing the codebase and fixing issues once a project gains traction.
Post reply on HN