undefined | Better HN

0 pointsdefanor6y ago0 comments

There seems to be quite a few light contradictions (or perhaps just varying views exposed) in both the post and the way it's referenced here.

I assume that OP's question implied that there generally are downsides to using separate tools (such as fragmentation, and then mostly UX ones: obtaining/installing them on all the machines that need them, managing keys differently, learning/using additional software, etc) when a task can be achieved with commonly available ones. But then the article criticizes GnuPG's UX, and suggests to use a bunch of different tools.

Then the article says "let's call both GnuPG and OpenPGP `PGP`", and proceeds to criticizing "PGP" standing for both GnuPG and OpenPGP.

Then it criticizes OpenPGP metadata leaks (possible attachment of a key to an identity), but suggests to use services such as Signal and WhatsApp (certain attachment of a key to an identity via a phone number, AFAIK). Or the ones using similar algorithms (I've only tried OMEMO out of those myself, which led to messages not even being shown in IM clients, apparently due to implementation inconsistencies).

Then it goes on suggesting to not encrypt email. I guess it's implied that one shouldn't use email for secret data, but a much more common practice seems to be actually using it for secret (but not "life and death" kind) data, and sending plaintext passwords and such; using PGP would still be a step forward. Perhaps it's the contrast between such criticizm (both here and of various other technologies) and common practices that makes me rather skeptical about the former: we can do better than X, but not doing even X.

WOT/PKI criticizm is present there too, but the suggested software either doesn't do/need it at all, or relies on a safe channel and direct verification (which is usable with OpenPGP as well).

I'm not advocating use of OpenPGP for everything, but finding those arguments to be rather strange.

0 comments

tptacek6y ago

I'm sure there was a question in there somewhere, but I'm not seeing it. I'm the author of the article that you're responding to. I'm happy to answer questions that I can parse as such.

You can do a lot better than OMEMO. Just use a serious secure messaging application: Signal or Wire are both fine options. Virtually every secure messaging application, including OMEMO, is better than attempting to make email cryptographically secure.

defanorOP6y ago

I didn't have a question, though perhaps not quite seeing where those advices are coming from (what are the threat model and underlying assumptions) can be stated as a question, as well as the definition of "better" here. For instance, phone number exposure and centralized systems (in case of Signal) or unreliable message delivery (in case of OMEMO implementations) seem rather bad to me, while properties such as deniable authentication seem to be useful in rather specific and rare cases (they still wouldn't harm if they were better supported though). It's also challenging to use OpenPGP, even with widespread email usage and the standards being around for a while, since people rarely care about encryption, and the most common case (AFAICT) is to send just plaintext emails with private/secret data. Given that, it seems counterproductive to advice not using it, but using systems with more obstacles instead. Do you view some of the properties they add as particularly useful in common cases, and/or as worthy trade-offs?

j / k navigate · click thread line to collapse