UX: Make age take a passphrase from a non-terminal source

[sz-coder]

GnuPG has this implemented with a --passphrase-fd argument that takes an integer.

Should be pretty easy to implement from looking at the source code.

I know you want to keep the options limited, but it'd be pretty nice to specify a passphrase from another source than a TTY.

(I know, one can fake a TTY to provide age with a passphrase).

[sz-coder]

I created a pull request to add this feature.

Let me know what you think.

[FiloSottile]

I have previously resisted this not just to reduce CLI options, but also to generally disincentivize passphrases. Humans are bad at selecting them, and we want to steer people towards X25519 keys. See #256 (comment) and #257.

However, I have to admit it's a half-assed position, because we do let people select passphrases. Maybe that should only be a feature of the API, and the CLI should always generate a custom passphrase... I'll think about this. Thank you for the PR, and sorry if we don't end up merging it.

[FiloSottile]

Can you tell me about the use case you needed this for?

[n-hebert]

Linking: #257 (reply in thread)

[shula]

Can you tell me about the use case you needed this for?

Because:

1. i want to be able to extract my encrypted backups on any computer;

2. when restoring a backup, I usually don't have access to my key-files (which might be encrypted, or air-gapped, or whatever).
   so I need the passphrase to be memorable,

a plain password is my best solution.
Also, I want to create backups via a script;

a compromise could be, reading the passphrase from a file (to avoid getting into bash history), containing the password.

[sz-coder]

First of all, thank you so much for getting back to me so quickly.

I really appreciate the work you do because if I'm honest I'm not good when it comes to cryptography.

It's really awesome to have such a simple tool without much options to shoot yourself into the foot.

Now for my use case (I won't talk about --passphrase-fd specifically but my use case for age in general since I think this adds more to the discussion):

I'm intending to use age for encrypting server backups and private packages.

The private packages are available through a public URL, that's why I want them to be encrypted.

My first implementation used a long passphrase generated by age to encrypt all packages.

Something like lecture-mammal-random-update-embrace-gap-universe-guilt-pigeon-fruit.

Since I don't want to remember this long passphrase I encrypted the longer passphrase with a shorter passphrase (kind of like a password) that will be used to decrypt the long passphrase for decrypting a private package.

Illustration:

$ cat long-passphrase.txt
$ lecture-mammal-random-update-embrace-gap-universe-guilt-pigeon-fruit

$ cat package.tar | age --passphrase-file long-passphrase.txt --encrypt > package.age
$ cat long-passphrase.txt | age --passphrase > passphrase.age

$ wget -O package.age https://mydomain.com/package.age
$ wget -O passphrase.age https://mydomain.com/passphrase.age
$ cat passphrase.age | age --decrypt > long-passphrase.txt
$ cat package.age | age --decrypt --passphrase-file long-passphrase.txt > package.tar

And that's the reason why I wanted a way to provide age a passphrase from a non-terminal source (so I'm able to provide the longer passphrase to age automatically).

However, after thinking for a while I decided to change my implementation to use a key pair generated by age-keygen instead to encrypt and decrypt my packages. The private key is encrypted with a passphrase that is available on a public URL.

Now I'm not sure if I'd really need the option --passphrase-fd since age doesn't need a passphrase when decrypting with a private key.

I'd be very happy if you could give me a short feedback on the "publicly available encrypted private key" approach.

PS:

And if you won't merge my PR, that's totally fine! :)

[sz-coder]

The only attack vector I'm seeing right now is that someone can download the encrypted private key and try to bruteforce the passphrase. However, I'm assuming with a good password this is infeasible.

[FiloSottile]

Hi @sz-coder, thank you for your patience!

We spent a few hours discussing this with @str4d and we decided that we want to keep passphrases interactive in the main binary. There are a few reasons, including wanting to encourage age-keygen usage, and not wanting to grow a large API surface to cater to all the different reasonable ways of providing a passphrase from a script.

However, we reworked the upcoming plugin design so that it will be possible to write a plugin that encrypts and decrypts regular passphrase-encrypted age files, taking the passphrase from wherever it likes.

This is similar to how you can't script SSH password authentication, but there is a sshpass 3rd party tool for it.

However, after thinking for a while I decided to change my implementation to use a key pair generated by age-keygen instead to encrypt and decrypt my packages. The private key is encrypted with a passphrase that is available on a public URL.

We liked this approach a lot, and we want to encourage it for "encrypt from a script to a passphrase", also because this way the encryption side doesn't need to have the secret at all.

This tipped the scale in favor of implementing encrypted identity files, so as of the upcoming v1.0.0-rc.3, you can use such a file directly with -i. https://github.com/FiloSottile/age/blob/master/README.md#passphrase-protected-key-files

Thank you for sharing your use case, age is better for it!

[keisentraut]

we decided that we want to keep passphrases interactive in the main binary.

I fully understand this reasoning. However, would you mind to state the fact that it won't be implemented somewhere more prominently? From reading all the other issues, pull requests and discussions, I got the impression that you are still considering this. Thanks!

We liked this approach a lot, and we want to encourage it for "encrypt from a script to a passphrase", also because this way the encryption side doesn't need to have the secret at all.

I think this is what I will have to use, too, but there is one small downside of this approach: It is not post-quantum resistant anymore because it will use X25519. The encryption with a passphrase + scrypt is post-quantum resistant as it only uses scrypt and ChaCha20, i.e. no asymmetric crypto at all.

My usecase is to backup archives with very intimate data at cloud providers such as AWS Glacier Deep Archive for the rest of my lifetime. Examples are bank statements of account or private photos/videos from my family which I want to keep even if my house burns down. I think X25519 will be safe for at least 30 more years, but who knows?

Currently, I am using openssl enc -e -aes-256-ctr -pbkdf2 -iter 100000 which has the downside of 1) not being authenticated at all, 2) uses a non-memory-hard key derivation (PBKDF2) and 3) does not store parameters such as used cipher and PBKDF2 iteration count. age seems to be a better alternative, but now I have to decide if getting rid of those three downsides is worth giving up post-quantum resistancy.

[FiloSottile]

A very delayed note about post-quantum security: if you throw away the recipient string, and only encrypt to the X25519 private identity with -e -i, there is no QC attack because the recipient can't be recovered from the encrypted file, and it's mixed into the key.

[gabyx]

Whats the approach to provide the passphrase from lets say the gnome-keyring to age -d private-key.age > private-key
in 2024?

The private-key is from age-keygen.

[FiloSottile]

The new batchpass plugin handles non-interactive passphrase encryption. See #256 (comment) for usage and a warning.