undefined | Better HN

0 pointsstubish6y ago0 comments

We encrypt files:

- For offsite backups (disaster recovery), mirroring object stores and filesystems to cheap cloud storage.

- For encrypting secrets needed for maintaining IT systems (eg. all those shared passwords we never seem to be able to get rid of)

- For encrypting sensitive documentation for transfer (email attachment, shared via filesystem, shared via HTTP, shared via pastebin even)

Despite the awful UI, GnuPG does all of that in a standard way. We have tested disaster recovery with no more instructions than 'the files are in this S3 bucket'.

And the same tool is also useful for other tasks too: - public key distribution (needs care to do it securely, but functional) - commit signing, signed tags - package signing (per Debian)

We could use custom or multiple tools for all this, but a single tool to learn is a big advantage.

I think all use cases boil down to 'encrypt and/or sign a file' for one of the stages. In the article, 'talking to people', 'sending files', 'encrypting backups' are all really just 'encrypt/sign a file' followed by transmission. And some sort of keyring management is needed for usability. A tool that can pull keys from a repository and encrypt and/or sign a file to a standard format could be used to build all sorts of higher level tools. I imagine it would be quite possible to build this on top of libsodium, and if it gained mindshare, replace uses of GnuPG.

0 comments

cyphar6y ago

> I think all use cases boil down to 'encrypt and/or sign a file' for one of the stages. In the article, 'talking to people', 'sending files', 'encrypting backups' are all really just 'encrypt/sign a file' followed by transmission.

But they aren't the same thing. That's the whole point the article is making. Yes, if all you have is a tool that does "encrypt+sign a file", then all crypto problems will look like "encrypt+sign a file" problems.

For backups, tools like restic provide deduplication and snapshots as well as key rotation (and restic works flawlessly with dumb S3-like storage). You can't do that with PGP without reimplementing restic on top of it. Same with TarSnap. For talking to people, you want perfect forward secrecy and (usually) deniability. PGP actively works against you on both fronts. For sending files, there are also other considerations that Wormhole handles for you (though to be honest I haven't used it in anger).

While you can "solve" these problems with one tool, the best way of solving them is to have separate tools. That's the point the article is making.

PeterisP6y ago

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.

cyphar6y ago

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 message later posting cryptographic proof that you said something in a chat with them. I bet most people (if you asked them) would effectively never want that "feature" for private chats.

[1]: https://signal.org/blog/simplifying-otr-deniability/

1 more reply

j / k navigate · click thread line to collapse

0 pointsstubish6y ago0 comments

We encrypt files:

- For offsite backups (disaster recovery), mirroring object stores and filesystems to cheap cloud storage.

- For encrypting secrets needed for maintaining IT systems (eg. all those shared passwords we never seem to be able to get rid of)

- For encrypting sensitive documentation for transfer (email attachment, shared via filesystem, shared via HTTP, shared via pastebin even)

Despite the awful UI, GnuPG does all of that in a standard way. We have tested disaster recovery with no more instructions than 'the files are in this S3 bucket'.

And the same tool is also useful for other tasks too: - public key distribution (needs care to do it securely, but functional) - commit signing, signed tags - package signing (per Debian)

We could use custom or multiple tools for all this, but a single tool to learn is a big advantage.

0 comments

cyphar6y ago

While you can "solve" these problems with one tool, the best way of solving them is to have separate tools. That's the point the article is making.

PeterisP6y ago

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.

cyphar6y ago

[1]: https://signal.org/blog/simplifying-otr-deniability/

1 more reply

j / k navigate · click thread line to collapse