Live data from Hacker News

The PGP Problem

latacora.micro.blog

151–160 of 369 posts

Re: The PGP Problem

#151
post #145

Earlier quoted context omitted.

Correct, screenshots are a viable attack against both closed and open source platforms. Preventing casual retention is the best you can hope for, and is a worthy goal regardless that it does not result in the perfection of a Faraday cage’d clean room

So, your threat model includes MITM servers, but not cameras? It seems a little silly to worry about the MITM problem when you can simply snap a photo already.

If you have to get into a legal battle with someone about misuse of information, it's much better that you are able to focus on the sender and the recipient of the information as potential sources for that information instead of also having to go after every potential network hop as well.

Re: The PGP Problem

#152
post #148

Earlier quoted context omitted.

Any opinions about rclone? It seems to be fine for my mediocre backup needs

rclone is fine (in fact I use rclone with restic to synchronise my restic backup repository on BackBlaze B2) but it doesn't encrypt or deduplicate your backups -- it's just a synchronisation tool like rsync.

What about its 'crypt' encryption backend?

Afaik it uses scrypt which was designed for tarsnap

Re: The PGP Problem

#153

Earlier quoted context omitted.

I think the real problem is that nobody has ever created a decent PKI, and I doubt a sufficiently secure PKI is even possible. CAs require you to trust people that aren’t supposed to be party to the communication (trust both not to be hostile, and not to be insecure themselves). All other forms of PKI offer entirely impractical authentication mechanisms. With signal and the like, your options are 1) Verify keys by be…

I would regard the Web PKI as the only decent global public PKI, but sure, whatever. You don't seem to have understood what's going on in Signal. Ordinary key rotations, which happen automatically, do not change the verified status. What can happen is that another participant changes phone or wipes it, and so obviously trust can't survive that change. The problem isn't that somebody else may know the correct key, the…

The implementation details have some UX benefits, but all they do is kick the can down the road, not solve the problem. You need a secure channel to authenticate the keys (or “safety numbers”, or whatever you want to call them). This can only practically be done face-to-face (or by getting somebody you trust to do it face to face - to act as if they were a CA). You need to do this prior to first communication, and additionally every time somebody loses their key material.

Some people will be motivated enough to do this, most won’t, and this absolutely can’t scale.

All known PKI systems are either impractical, or require a level of trust that undermines the system entirely. You can say your threat model doesn’t require that much security, but in that case it probably doesn’t require a PKI either.

Re: The PGP Problem

#154
Messenger are not easier than email, only when 2 ore more communicate on one topic.

But with email you communicate with one or more people about many topcis.

To archieve the same structure in a messenger, you must create several discussions. So messenger are not the holy grail of communication, that is why people still use email.

We need an email user interface with open messenger protocols under the hood for secure communication and usability. None of the current messenger offer that.

Re: The PGP Problem

#156
The post is well-written and summarizes I think most major pain-points with PGP.

Comparison of all these tools to GnuPG is valid and it clearly shows not only implementation problems but design ones as well in gpg.

What I fear is future riddled with all these incompatible tools. Even if they're written by brilliant engineers and cryptographers they are not standards (e.g. IETF standards). Why is that important? For example rewriting libsignal from scratch (for example to publish it under permissive licenses) can be problematic [0].

[0]: https://news.ycombinator.com/item?id=12056673

Re: The PGP Problem

#157
post #94
post #78

Earlier quoted context omitted.

How does one list a public PGP key, is there a verified central listing service?

You can put it on your website or anywhere really. Some people use keybase.io for this.

You can't put it anywhere really, otherwise anyone could tie their key to your identity. Keybase.io is a good solution.

Re: The PGP Problem

#158
post #144

Earlier quoted context omitted.

For securely talking to people, often you may want non-repudiation, which is the exact opposite of deniability and anonymity. There are very different, incompatible needs for slightly different usecases.

Signal -- and all other OTR-like protocols -- have deniability (or if you prefer it has repudiation rather than non-repudiation). Neither conversation participant can prove to a third party that the other party said something in a conversation. Moxie wrote a blog post about this in 2013[1]. The only circumstance in which you want non-repudiation is if you are really sure that you are okay with the recipient of your m…

Sure, you usually don't want that feature in private setting, but you almost always want that feature in a commercial setting, and lots of communication happens in that context.

E.g. vendor-customer helpdesk chat, internal workplace communication including "less internal" things like different subsidiaries of international companies, etc, etc. Half of financial world runs on Thompson Reuters messenger which is essentially glorified chat. What if your boss sends you a message "hey, do that risky thing right now" - do you want that (likely informal) means of communication to have deniability? Does the company want deniability in the app in which random middle-managers message their subordinates? It makes sense for companies to mandate that teams choose only communications platforms that support authentication and nonrepudiation.

As soon as money, any kind of disputes, and the smallest chance for future legal proceedings are involved, anonymity and deniability are flaws and not features - as I said above, superficially similar use cases can have opposing and incompatible requirements.

Even going back to the commonly discussed use case of Signal for journalism. Let's say a journalist interviews a whistleblower over a mobile messaging app - you'd want anonymity and deniability there. And five minutes later that same journalist asks a clarifying question to the official head of that agency, likely also using a mobile messaging app, possibly the same one. Do you want the answer of that official to have deniability, or do you want that journalist to be able to cryptographically prove that the official lied?

Re: The PGP Problem

#159
post #115

The pass password manager uses PGP, what would be a better design?

Nothing at present, but the article did talk about work being done on a project that will be able to work as a direct replacement for pgp in this use case. Near the end, look for the mention of 'age'.

Re: The PGP Problem

#160
post #148

Earlier quoted context omitted.

rclone is fine (in fact I use rclone with restic to synchronise my restic backup repository on BackBlaze B2) but it doesn't encrypt or deduplicate your backups -- it's just a synchronisation tool like rsync.

What about its 'crypt' encryption backend? Afaik it uses scrypt which was designed for tarsnap

Ah, I wasn't aware it had an encryption backend. Just looking at the documentation I'm quite worried -- why on earth is there an "obfuscate" mode?

I would suggest using restic. It doesn't have any weird modes, it simply encrypts everything and there isn't any weird need to specify (for instance) that you want things like metadata or filenames encrypted. Also backups are deduplicated using content-defined-chunking -- giving you pretty massive storage savings. If you really need rclone since it supports some specific feature of your backend -- restic supports using rclone as a synchronisation backend (or you can do what I do, which is to batch-upload your local restic backup every day).

Post reply on HN