UX: Allow passphrase protected private keys to include public key info

[btrepp]

What were you trying to do

Passphrase encrypt my identity file, but still also use it to encrypt

While I imagine a passphrase encrypted file we won't be able to use the read the public key from the comments, but ergonomically it would be nice to do. I thought perhaps a combination of --armor and adding the missing metadata might help.

# created: 2025-06-21T11:29:12Z
# public key: age1rnv4r73emdmpygaqaec8lcse4vs0wdhgzr04a7y7vsz9c8w6vp6qdg2cs4
-----BEGIN AGE ENCRYPTED FILE-----
ENCRYPTED KEY HERE
-----END AGE ENCRYPTED FILE-----

What happened

Error: identity file contains non-identity data on line 3

I imagine this is because it's expecting it to not be an encrypted key file.

Swapping and putting the comments after gives

Type passphrase for encrypted identity '/home/user/.config/age/key.txt'
Passphrase: 
Error: invalid armor (non-whitespace characters after end marker)

[ Did rage not do what you expected? Could an error be more useful? ]

From reading the trackers, I can understand this isn't really the normal case for rage/age, but in the purpose of my scripts it would be great to read the users pinentry once, and then update a file.

The current work around would be to maintain 2x files, like ssh does, but it starts getting a bit custom, so was trying to make the ergonomics of my script nice, but protect against someone accidentally leaking or having no security around the key files.
Eg I can write key.txt and key.pub, and read the different keys that way, but would be nicer if there was an understood combined format.

An emulated way of having the 2x files is below. There might be a better way of doing the recipients, but it works in my program.

set -e

AGE_DIR="${XDG_CONFIG_HOME:-$HOME/.config}/age"
PUB_FILE="$AGE_DIR/key.txt.pub"
PRIV_FILE="$AGE_DIR/key.txt"
TMP_KEY=$(mktemp)
trap 'rm -f "$TMP_KEY"' EXIT INT TERM HUP

mkdir -p "$AGE_DIR"

# Generate key and save to temp file
rage-keygen > "$TMP_KEY"

# Extract public key as single line (handles comment prefix)
grep '^# public key:' "$TMP_KEY" | sed 's/^# public key: //' > "$PUB_FILE"

# Encrypt private key with passphrase
rage -a -p -o "$PRIV_FILE" -e "$TMP_KEY"

echo "Public key saved to $PUB_FILE"
echo "Encrypted private key saved to $PRIV_FILE"

Here is the answer from chatgpt ----

Short answer
No — the age/rage format does not let you keep a pass‑phrase‑encrypted private identity and the clear‑text public key in the same file.
When a file starts with

-----BEGIN AGE ENCRYPTED FILE-----
rage (and age) treat the whole blob between the BEGIN/END markers as opaque ciphertext and reject every other line that is not part of the armour. Any extra text before the header raises

identity file contains non‑identity data on line …
and anything after the END marker raises

invalid armor (non‑whitespace characters after end marker)

This is intentional: as Filippo Valsorda (age’s author) notes, age expects you to **copy‑paste or script the public key** and keep it separate, “rather than always managed as files” :contentReference[oaicite:1]{index=1}.

---

### Why the tool behaves this way  

| File you hand to `-i/--identity` | What rage expects to find |
|---------------------------------|---------------------------|
| **Plain identity** (what `rage-keygen` emits) | One or more `AGE‑SECRET‑KEY‑…` lines. Comment lines (`# …`) *are* allowed here. |
| **Pass‑phrase protected identity** (`rage -p -o key.age …`) | A *stand‑alone* age‑encrypted blob, i.e. exactly the armour block with no extra lines. Comments are **not** allowed, because they would break the armour parser. |

Once you encrypt the key, the file is no longer parsed line‑by‑line; it must be fed to the decryptor as‑is so the scrypt header and payload can be processed. Mixing free‑form text with that ciphertext would make the MAC verification and delimiter search ambiguous, so the format forbids it.

---

### Practical ways to get the “ergonomics” you want  

| Need | Recommended approach |
|------|----------------------|
| ❔ Quickly obtain the public key when you have the encrypted identity | `rage-keygen -y key.age` (or `age-keygen -y key.age`) prints the corresponding recipient after you enter the pass‑phrase (introduced in age v1.0.0‑rc.1) :contentReference[oaicite:2]{index=2} |
| ❔ Avoid typing the pass‑phrase twice in the same run | Rely on **pinentry caching** (rage automatically uses `pinentry`), or export `RAGE_PASSPHRASE` for non‑interactive scripts. |
| ❔ Ship both pieces together | Store them side‑by‑side: `key.age` (private, encrypted) and `key.pub` (one‑line public key). That is exactly what OpenSSH does and is what age’s authors expect. |
| ❔ Single artefact that is safe to hand out | Hand out only `key.pub`. Including the encrypted private key in a bundle invites accidental leakage; that is why the format steers you away from it. |

---

### Example helper script (cleaned‑up)

```bash
#!/usr/bin/env bash
set -euo pipefail

AGE_DIR="${XDG_CONFIG_HOME:-$HOME/.config}/age"
mkdir -p "$AGE_DIR"

PUB_FILE="$AGE_DIR/key.txt.pub"
PRIV_FILE="$AGE_DIR/key.txt.age"   # note the .age extension

tmp=$(mktemp)
trap 'rm -f "$tmp"' EXIT

# 1. Generate a new identity
rage-keygen > "$tmp"

# 2. Capture the public key
grep '^# public key:' "$tmp" | sed 's/^# public key: //' > "$PUB_FILE"

# 3. Encrypt the private half
rage -p -o "$PRIV_FILE" "$tmp"

echo "➤ public key saved to $PUB_FILE"
echo "➤ encrypted identity saved to $PRIV_FILE"
Use it like this:

bash
Copy
# encrypt
rage -R "$PUB_FILE" -o secret.txt.age secret.txt

# decrypt (prompts once; pinentry caches for the duration)
rage -i "$PRIV_FILE" -d secret.txt.age > secret.txt
If you ever lose the .pub file you can recover it with:

bash
Copy
rage-keygen -y "$PRIV_FILE"   # prompts for the pass‑phrase once
Take‑away
The age design deliberately keeps encrypted identities “self‑contained” and comment‑free to avoid parsing ambiguities and to prevent users from accidentally distributing private material. The supported—and safest—pattern is therefore:

one encrypted file (key.age) containing only the private key, and

one public‑key file (key.pub) or a snippet you copy‑paste when you need it.

Trying to merge the two into a single, still‑usable file is not possible with the current format and unlikely to be added.