Hacker News Reader

Comment by setheron | Hacker News Reader

I saw people starting to use `age` as a replacement to gpg. Can someone speak to that?

It's not a replacement: age is purely a file encryption tool. GPG is encryption, signing services, key management, web-of-trust, smartcard compat, and all sorts of bells and whistles. If you're just encrypting files and don't care about any of the other stuff it's probably a solid bet though.

The argument for people using age to replace GnuPG (PGP really) is that there are better signing tools that you really should be using (minisign/signify) and PGP should not be used for the web-of-trust anymore anyway. There are many good arguments against PGP for all of these things.

Age has authenticated encryption so it is slightly more convenient for stuff like encrypting backups that you think might undergo some sort of known plain text attack. To prevent that with gpg you have to also sign the backup.

This recent security thing makes it seem that GPG has also gained authenticated encryption. Dunno how I feel about that. OpenPGP stuff gets its security and reliability from simplicity. Adding stuff takes away from that. This security thing kind of supports that.

GPG adds something that they call MDC, which is kinda similar to a mac in authenticated encryption schemes. It is enabled by default.

The MDC scheme exists- it's also sketchy as all hell. Wouldn't trust it if serious adversaries are a reasonable threat for you.

https://github.com/gpg/gnupg/blob/master/g10/mainproc.c

Yeah, MDC was added as something better than nothing for unsigned messages/files. It has ended up being remarkably robust over the years, considering. The biggest deal is that you can entirely remove it. As a result stuff these days tends to consider a missing MDC as an invalid MDC.

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

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.

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

GnuPG has a lot of legacy cruft like two key parsers and support for CAST5. The trend seems to be towards bespoke, tailored tools for specific purposes and away from unified crypto tools that do many things.

Mostly I feel like gpg is too broad for one guy to maintain and needs to drop support for stuff to keep the scope manageable.

I’m looking forward to trying Sequoia PGP[1], a new OpenPGP implementation using Rust. Its opinionated high-level API and removal of MD5 and IDEA might just be the do-over OpenPGP needs.

[1] https://sequoia-pgp.org/talks/2018-08-introduction/sequoia-i...

Both IDEA and MD5 are depreciated in the published OpenPGP standard. So implementations don't have to implement them. If they do it doesn't make any difference other than a bit better backwards compatibility. Since everything these days prefers better algorithms there are no negative security aspects to supporting IDEA and MD5.

Aside: The word you wanted was "deprecated" not "depreciated"

Supporting obsolete and perhaps insecure algorithms can give your user false confidence. Adversaries do not prefer the better algorithms, they get to choose whatever suits their purpose and so by supporting an obsolete algorithm you let your adversary choose that if it suits them. So don't.

The diediedie draft (now more respectably named https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-... instead) deliberately tells people not just to support newer TLS versions but to stop supporting old ones, for exactly this reason.

The protecting data at rest problem (PGP and the like) is fundamentally different from protecting data in flight (TLS and the like). In the PGP case adversaries can not affect the choice of algorithm without breaking the fundamental public key cryptography (which is fixed).

Added: depreciated vs deprecated; Thanks. An error I have made before and hopefully will not make in the future.

Added2: I wrote an article that covers this: https://articles.59.ca/doku.php?id=pgpfan:downgrade

> In the PGP case adversaries can not affect the choice of algorithm without breaking the fundamental public key cryptography (which is fixed).

Again, this is an error because you've not remembered that an adversary isn't obliged to do what a good actor should do.

Your article explains how Alice gets to be quite sure that Bob would prefer she use a good algorithm, and doubtless as a result the conscientious Alice will use a good algorithm when sending messages to Bob. But alas an impostor sending messages to Bob purporting to be from Alice needn't care about this.

For that impostor it only matters whether Bob's client will foolishly accept the bad algorithm they deliberately picked, not whether Alice might ever have chosen to use that algorithm. Even if it would be quite impossible for the attack to read or modify any messages Alice writes, in this way they may be able to send a message to Bob that seems to be from Alice.

Perhaps the message should say "Hi Bob. Sorry, dreadful problems with PGP again. I had to create a new account, see next mail" followed shortly thereafter by a nice shiny PGP mail from... the impostor's account.

Thus, to defeat such an impostor it is necessary to remove/ disable obsolete algorithms entirely. In principle we could imagine client software that securely separates messages received prior to some cut-off date and permits the use of an obsolete algorithm to read/ verify those messages only, but in practice you're asking far too much and this is likely just to add another exploitation avenue.

I am not sure I understand your scenario in enough detail to understand the actual attack. At any rate the identity is established on the basis of Alice's public key. That is the part that is fixed. If it is, say, 2048 bit RSA then that is what Bob uses to confirm that a particular message is from Alice.

> That is the part that is fixed. If it is, say, 2048 bit RSA then that is what Bob uses to confirm that a particular message is from Alice.

A public key algorithm like RSA doesn't actually operate on large data structures like a whole message. Instead it's used on a digest of the message, a hash.

But the decision of which algorithms to accept for such a digest is up to Bob. So even though Alice wouldn't send a new message using a long obsolete hash, the impostor can present a message which claims to be from Alice using that hash and you apparently are enthusiastic about Bob's client trusting this bogus message.

Because OpenPGP shoves the hash identifier into the structure that actually gets signed with RSA, the impostor cannot easily just mis-attribute a modern signature to an older hash, but they can re-use any signatures they do have with a suitable identifier.

OK, I think I have come up with something that could work here...

1. Alice sends messages signed with a currently good hash (say, SHA512 because that is the current default).

2. The attacker gets a copy of one of those messages (perhaps Alice sent him such a message)

3. SHA512 gets broken in the worst way possible: arbitrary hashes can be produced in a way that is not entirely obvious.

4. The attacker generates a new message. They do it so that the SHA512 hash is the same as the SHA512 hash in the saved message. They then reuse the signature from the saved message to make the new message seem to be signed by Alice.

So my original statement was wrong as you said. It was too general to be true in all cases.

Thank you for the insight. I will likely use it to improve my article(s).

One great thing about gpg though is that if you have it, you have everything. And because it's so ubiquitous pretty much every distro has it by default. Not having to look for packages, being able to decrypt stuff even on a rescue image etc is great. On the mobile side there's also great clients like openkeychain.

And most of its shortcoming are mainly academic, and not everyone has the heaviest actors in their threat model.

One thing I really love about GPG is that you can use yubikeys and OpenPGP cards for your private keys and encrypt files to that. Any other tool would have to have at least that functionality. I use this all the time and it provides great protection against passphrase logging or key theft. Going back to private keys on disk is a huge step back IMO. I no longer use any such keys except for one backup key I have stored offline and which I throw in the mix in case all of my yubi's and cards break :)

Nice, It supports encrypting with SSH keys. I was looking for something just like that.

May I ask why?

Sending a newly created secret to a colleague. I already have his pubkey so I wouldn't have to worry about how trusted a channel is.

Age is a bit awkward if you want to store your private key encrypted.

  $ age-keygen -o key
  $ grep public key | cut -f ' ' -f 4 > key.pub
  $ age -p -a -o key.prv key
  (enter passphrase to protect private key)
  $ rm key

OK, now we have key.pub with a copy of our public key, and key.prv with the private key encrypted with a passphrase.

Now suppose we receive a file, msg.sec, that was encrypted using our public key. If our key file were not encrypted, we could decrypt the message as so:

  $ age -d -i key.prv msg.sec

With the private key encrypted, we need to decrypt it into a file, use the file with the above command, and then presumably get rid of the decrypted private key file. There are a few ways to do this on Unix and Unix-like systems.

1. Use an actual file.

  $ age -d key.prv -o key.tmp
  (enter passphrase)
  $ age -d -i key.tmp msg.sec
  $ rm key.tmp

I dislike this. What if something like Time Machine happens to take a snapshot right as I'm doing this, and key.tmp gets into the backup?

2. Use a named FIFO.

  $ mkfifo f
  $ age -d -i f -o msg msg.sec &
  $ age -d key.prv > f
  (enter passphrase)

3. It has been suggested that process substitution could be used instead of a named FIFO:

  $ age -d -i <(age -d key.prv) -o msg msg.sec

but this fails for me both on my Mac with bash or zsh, and on a Debian Stretch system with bash. On the Mac, with either shell, I get prompted for the passphrase, but it does not actually get read. If I kill the "age -d key.prv", the shell tries to execute my passphrase as a command. On the Debian system as soon as age prompts for the passphrase it them says "Error: could not read passphrase: could not read passphrase: input/output error" and exits.

4. On the Mac, use the clipboard.

  $ age -d key.prv | pbcopy
  $ age -d -i <(pbpaste) msg.sec; pbcopy < /dev/null

(If you want the plaintext of the message on the clipboard, you could try this for the second line:

  $ age -d -i <(pbpaste) msg.sec | pbcopy

That works most of the time, but occasionally I see it fail saying that there is a malformed key on /dev/fd/<some_number>).

Note that this does show that there is no inherent problem with using process substitution to provide the key "file" to age for decryption. The problem in #3 seems to be when age is used for the command within the substitution and it has to prompt for a passphrase.

6. Similar awkwardness arises if rather than storing you private key in an age passphrase encrypted file you store it in a password manager, such as in a 1Password secure note. If you copy the private key, you need to find a way to paste it to age.

Process substitution works:

  $ age -i <(echo AGE-SECRET-KEY-18CP0EEC6QAZ09FG9R423JMMWRFSGVR32ANET54EHQ7ZHW690DVKSR07ZHQ) -d msg.sec

You might not want the key echoed on the terminal. This would work to avoid that:

  $ mkfifo f
  $ SAVE=$(stty -g)
  $ age -d -i f msg.sec &
  $ stty -echo
  $ cat > f
  (paste the private key, hit return, hit ctrl-d)
  $ stty $SAVE
  $ rm f

It would be a lot less awkward if -i simply accepted encrypted key files.

Reply on news.ycombinator.com