Hacker News Reader

Comment by lilyball | Hacker News Reader

What problem is this solving that isn't already done by other tools?

This is like the engine underneath PGP, but modernized and with the misfeatures stripped out. You'd use it, instead of PGP (which is bad) for encrypting files, and as a building block for the operational tools that really are just straightforwardly encrypting files (ie: not messaging, which has its own distinct needs and has purpose-built cryptosystems for).

More on this: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

Your comment on purpose-built systems makes me want to ask a question I've been wondering about for a while:

What would be the best way to encrypt something with a lot of files in it (like, say, a home directory), assuming you wanted to access it across the network on multiple devices?

Sorry if this question's annoying, it seems like something you might get a lot.

Encrypted LVM, or any other block-device-level method.

I admit I grievously misworded my query, but (something like) Magic Wormhole seems to be the answer to the question I was meaning to ask.

in practice "the best" and securest way of encrypting a folder is zip-compressing it several times with passwords.

Wait what, excuse me?

I don't mean to insult you or anything but how did you came up with that idea?

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.

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.

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?

From the linked blog:

> A Swiss Army knife does a bunch of things, all of them poorly.

Counterexample: the Phillips head screwdriver in my Swiss Army knife is actually the best Phillips head I've ever found. It can easily turn without slipping a wider range of screw head diameters and depths than any other screwdriver I've used.

(Does anyone else have way more screwdrivers around than they can explain? I cannot think of any reason I would own more than two or three full sized screw drivers, and one set of small of jewelers screwdrivers...but I've got more than a dozen full sized ones and a couple sets of jewelers screwdrivers. I cannot remember buying, inheriting, finding, stealing, borrowing and not returning, or being gifted any of them--but there they are. Glitch in the matrix?)

One thing about the Phillips screw driver - perhaps it's Pozidriv[0] type, that's compatible with Phillips but different/better.

"Phillips" was originally designed to slip to prevent over-tighten. One more PH. screwdrivers come in various sizes (read the listed article for more). Using the correct one works significantly better for: flat/ph/pz, etc. For stuff like torx is not even possible to use incorrect screwdriver. Last screwdriver quality greatly varies, with some brands being exceptionally expensive or even pride material to own.

[0]: https://en.wikipedia.org/wiki/List_of_screw_drives#Pozidriv

I went to replace the memory in a 2018 Mac Mini yesterday. I have small Torx screwdrivers from doing this older Mac Minis and MacBooks. I have bigger security Torx bits (they have a pin in the center so ordinary Torx bits won't work) that I bought when replacing the fuse in a microwave.

What I don't have are small security Torx bits or screwdrivers. Which is what you need for the 2018 Mac Mini.

I had bought the small Torx screwdrivers as part of a kit with small Phillips, pentalobe, etc. Major use case was replacing broken screens on Chromebooks when the kids were littler. Secondary use was replacing hard drives in Mac Minis (2011, 2012) with small SSD/1 TB combos.

I buy most of my tools from jumble sales, the older tools are the best and with a bit of restoration work better than any new screw driver. I always carry a pocket knife and knife sharpener like the one here https://www.gearassistant.com/best-pocket-knife-sharpener/ but rarely use the screwdriver on it

I've read that article before and really enjoyed it. I don't know if it answers the question, though. So, if I want to message someone I use Signal, if I want to send someone a file I use Wormhole, if I want to sign something I use Minisign, if I want backups I use tarsnap. Is this for "if someone compromises this machine there's still something else they need to do to access this file?"

OK, the linked article talks about a downgrade attack and then uses that as an excuse to talk about a whole lot of OpenPGP stuff that no one actually uses anymore. But the article entirely fails to show how a downgrade attack is possible. I mostly just skimmed the article after that but did not see any real attacks even against the old stuff. So not really a strong argument against the OpenPGP standard.

The spec document has some more information on the rationale and goals that might be of interest.

https://age-encryption.org/v1

This reference from that spec is especially useful as an example of the kind of nuts-and-bolts modernization that makes cryptography engineers tear their hair out about PGP:

https://www.imperialviolet.org/2014/06/27/streamingencryptio...

I found their “Out of scope” list very interesting. In particular, they list signing and “anything to do with emails” as non-goals. From my fairly limited understanding of cryptography, isn’t signing almost identical to encrypting (at least with RSA)? I don’t understand why this would not be supported in a self-styled PGP replacement.

I also don’t understand the “anything to do with email” line. Sending my public key to a recipient on an out-of-band channel and then sending an encrypted email should be completely agnostic to the underlying encryption tools, no?

I don’t mean to sound critical - I’m very intrigued by this project and would love to have a better replacement for gpg!

Age is trying to avoid being an infinitely-flexible swiss army knife like GPG. It's been argued that GPG's do-everything design is the root of many problems both technically and in usability: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html.

Minisign is a good similarly-small tool for doing signatures + verification of signatures and nothing else. The cryptography is similar, but the use-cases are often different. The tools both follow the UNIX philosophy of trying to do one thing well. Blenders and belt sanders both operate with motors, but no one tries to combine them into one tool.

>I also don’t understand the “anything to do with email” line. Sending my public key to a recipient on an out-of-band channel and then sending an encrypted email should be completely agnostic to the underlying encryption tools, no?

Yes, you can do that.

Age doesn't want to involve web-of-trust, keyservers, key rotation, forward secrecy, post-compromise security, message repudiation, signing, email standards, and email client integration. All of these would be necessary for a good end-to-end encrypted messaging system. Try reading about the Signal protocol to see everything it does, and then try to figure out how to stuff it all into existing email systems. It's hard enough to get any of that stuff right even without the restriction of working inside email.

Please read this to stop thinking signing and encryption are related: https://security.stackexchange.com/a/87373/70830

They are related in the sense that encryption and signing algorithms use the same cryptographic operations. But the algorithms themselves are different, so having knowledge or faith in a certain encryption algorithm does not mean you have either in a related signing algorithm. They are separate domains.

> They are related in the sense that encryption and signing algorithms use the same cryptographic operations.

What is being encrypted in ECDSA? Or in Ed25519? You are wrong. Read the link.

tinco did not claim that anything is being encrypted in ECDSA nor in Ed25519.

I reacted to "isn’t signing almost identical to encrypting" and "encryption and signing algorithms use the same cryptographic operations".

I have a fun story to tell about how AGL and I couldnt use GPG to send each other emails about a vulnerability. For things like integrating with salt this is way easier then dealing with the busted web of trust.

> What problem is this solving that isn't already done by other tools?

It solves the problem of having to use the bloated monstrosity that gpg has become.

It’s not pgp

Reply on news.ycombinator.com