Hacker News Reader

Comment by wolf550e | Hacker News Reader

gpg does too many things. minisign does digital signatures (like for releases). age does encryption (like for backups).

Age and Minisign also don't have the ability to misconfigure them to use insecure primitives. GPG does.

Age is new to me, I immediately find there's a Go (age) and Rust (rage) implementation - which one is the encryption community at large favoring more? (stability, code quality, etc.)

https://github.com/FiloSottile/age

https://github.com/str4d/rage

I'm not involved with either, but I've looked at both for other projects[1]. The Rust implementation's CLI mirrors that of the reference (Go) implementation, and I haven't had stability issues with either. I found the Rust implementation's source code readable and decently documented.

[1]: https://github.com/woodruffw/kbs2

At the time there were implemented in GPG they were not insecure. If age and minisign are around 10 or 20 years for now, we'll see if your statement is still true.

Obviously Filippo Valsorda will release a new version that fixes whatever the issue is and will deprecate the old version immediately.

The new code might retain ability to decrypt the old version but not encrypt with the old version, for compatibility with old backup files or whatever. If he thinks it's safe to do.

Okay, so you're trust is completely in one person having perfect design decisions and that he chooses to continue to maintain these tools in perpetuity.

You also state that tool may or may not be able interact with past files. Which means it might be useless.

Git is in the process of deprecating sha1, and you end up having the put flexibility in after a tool expands. It will likely keep supporting sha1 even after it is much more trivial to create collisions.

No one is getting locked out of their files created by an old version. There will be a migration path. The old code will be in git. Worst case, the spec is open, I can implement the spec myself in python, using pycryptodome and pyca/cryptography, it wouldn't be hard.

I trust his judgement much more than I trust the group that maintains gpg. Of course, actually, there is a community, Filippo is not working in a vacuum. Worst case, if Filippo stops maintaining it or makes bad decisions, someone else (or a group of people) will maintain it.

Well neither does GPG. Insecure stuff gets removed. Stuff that people just have a funny feeling about gets retained.

Well, yes, this bridge is built out of LEGO, and yes, it does bend a lot and make concerning noises every time a car drives over it, but it hasn't actually come apart yet, so we'll keep sending traffic over it.

current versions of gpg support insecure settings and the defaults are not what you want.

Simply not true. Defaults are cryptographically strong.

The simple fact that they are not integrated together makes it easy to misuse them. http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

I can't seem to use minisign with git, which is my main use for gpg.

Signing git commits is broken anyway as you are basically signing the commit hash (which is a sha1, whose collision resistance is broken).

I recall hearing github is planning on Sha-256 some time

They're more likely to employ counter-cryptanalysis [1] in the meantime.

[1] https://github.com/cr-marcstevens/sha1collisiondetection

Can I store my key on a smartcard for either?

I guess you can use https://github.com/FiloSottile/yubikey-agent to store an ssh key on a yubikey, and then use age to encrypt to the ssh key.

Getting minisign to sign using a key in a ubikey is not supported out of the box, but should be possible in the same way yubikey-agent works (after all, that's what it does when you authenticate an ssh session using a yubikey).

You can ask Filippo Valsorda.

From project page:

https://github.com/FiloSottile/age#ssh-keys

> (ssh-agent is not supported.)

There is no way it integrates with smartcards.

Reply on news.ycombinator.com