Live data from Hacker News

GPG and Me

thoughtcrime.org

31–40 of 267 posts

Re: GPG and Me

#31

Earlier quoted context omitted.

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.

With modern ECC this is actually feasible.

Isn't IBE quite slow? And also it requires a third party for keygen and so on.

Re: GPG and Me

#32

Earlier quoted context omitted.

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.

With modern ECC this is actually feasible.

Yeah, that's an actual ECC public key in my example above.

Re: GPG and Me

#34

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 used Thunderbird and Enigmail for a year or so. I later moved to Evolution for the better GPG experience (no flickering on opening the message as there is with Enigmail) and better GNOME integration. I used Evolution for another year, but its rough edges wore me down; I had to get in the habit of closing it if I wasn't using it, because it would noticeably slow my system down. It would take at least 5 seconds to open. Parts of the UI would often lock up and need a reset by switching between the panes.

I've been using Claws Mail for the past few months. It's simple, fast and stable, and GPG support is fine. That's all I need. It sucks for reading and writing HTML emails, but I'm okay with that. Parts of the UI are still rough (e.g. the main window isn't responsive while the "sending" dialog is open), but it's less worse than Evolution.

Re: GPG and Me

#35
post #28

GPG is an immense failure from the point of protecting person to person communications. It is largely a success in verifying the identities of the software developers. The entire Debian ecosystem relies on GPG in largely successful ways. Peter Todd suggests that PGP drop encrypted communications as a goal and focus only on identity and authentication. It appears the PGP just can't be bootstrapped into modernity from…

> Peter Todd suggests that PGP drop encrypted communications as a goal and focus only on identity and authentication.

Identity and authentication are the biggest reason that PGP hasn't caught on with non-technical users - the web-of-trust is necessary to do distributed identity and authentication properly (under the current model), and the importance of out-of-band verification can be hard to explain. Authentication (as opposed to authorization) is hard, even without factoring in state adversaries.

The fact that the web-of-trust hasn't succeeded doesn't mean that another model won't, but I don't think it makes sense for PGP to throw out the one goal it already does incredibly well (securing communications) in order to focus on the biggest problem we haven't been able to solve in 20 years.

Re: GPG and Me

#36

Earlier quoted context omitted.

With modern ECC this is actually feasible.

Yeah, that's an actual ECC public key in my example above.

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.

Re: GPG and Me

#37
post #19

It seems that the biggest problem with encryption in general is that of incentives. Great UX takes lots of design and iteration, which means someone has to pay for all those designers and front end devs. However, when you want good encryption, user experience always comes after security, which means you spend the majority of your resources on the security, not the design. So, we end up with great security and terribl…

> However, when you want good encryption, user experience always comes after security

I'm going to throw down a gauntlet: encryption design that doesn't start with designing for the human users is already fundamentally broken. Why? Because it cannot represent a solid system. This isn't machines in the Matrix talking to one another: the needs of the human users are the only thing that matters.

Combine that with the past few decades of experience in software encryption systems, and we realize that this is hard to achieve. The non-adoption and misuse of GPG that Moxie speaks of, the train-wreck of passwords, and so on. It really feels like we've hit a wall, where there are no significant gains to be had unless these design problems are taken seriously. "Perfect" cryptosystems that have major real-world usability flaws are in fact worthless. Implementing new systems of this kind is a waste of effort and a disservice to everyone who vitally needs the services of a robust encryption infrastructure.

Re: GPG and Me

#38

Earlier quoted context omitted.

Yeah, that's an actual ECC public key in my example above.

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.

Re: GPG and Me

#39
post #19

It seems that the biggest problem with encryption in general is that of incentives. Great UX takes lots of design and iteration, which means someone has to pay for all those designers and front end devs. However, when you want good encryption, user experience always comes after security, which means you spend the majority of your resources on the security, not the design. So, we end up with great security and terribl…

> However, when you want good encryption, user experience always comes after security I'm going to throw down a gauntlet: encryption design that doesn't start with designing for the human users is already fundamentally broken. Why? Because it cannot represent a solid system. This isn't machines in the Matrix talking to one another: the needs of the human users are the only thing that matters. Combine that with the pa…

If you can't even get two machines in the Matrix to talk to each other securely, how can you expect to succeed with human error thrown in the mix?

Re: GPG and Me

#40
post #24

The old adage is that perfect is the enemy of good enough, but the author is claiming that GPG isn't even good enough. I have to somewhat disagree. While the ideal product in this space would be as easy to use as clicking a 'Like' button, and just as ubiquitous, GPG works well enough for now. The most sensitive use case for GPG has to be sending correspondence that, if decrypted, could put you in severe physical dang…

Actually this is not correct. There are now situations (such as in the United States) where merely using GPG puts you on a list of suspicious people. So not only is GPG not "good enough", but using it today makes your life worse than it was before. There are places where using GPG can lead to death or torture, even if the message is simply your grocery list. In order for GPG (or its replacement) to fulfill the dream,…

> There are now situations (such as in the United States) where merely using GPG puts you on a list of suspicious people.

What's fun: using ssh might be similar.

Post reply on HN