bip-85: add example use for age key derivation

[dmonakhov]

Motivation

age is a widely-deployed file-encryption format. Both its classic (X25519, since 2021)
and post-quantum (X-Wing / HPKE-MLKEM768-X25519, age v1.3.0+ Dec 2024) identity types take a 32-byte uniform seed as the secret-key material — which is precisely what BIP-85's HEX application at num_bytes=32 already returns.

This PR adds a brief example-use subsection at the end of the HEX application section, documenting how to interpret the existing 32-byte HEX output as an age identity. No new application number, no normative MUSTs added, no changes required in existing implementations — the HEX application already produces exactly what age consumes; this PR just records the connection in the spec.

Documenting this gives users a single backup story: the same BIP-39 mnemonic that already secures their Bitcoin wallets can deterministically produce age identities, with no additional key-rotation infrastructure on top of what they already do.

It also unblocks downstream hardware-wallet firmware integration maintainers of firmware projects accept "implement this BIP-85 use case" much more readily than "implement a convention from a third-party repo." A spec-blessed convention turns the conversation from a bespoke contribution into a standards-conformance issue.

What changes

A new ====<code>age</code> file encryption keys==== subsection at
the end of the ===HEX=== section in bip-0085.mediawiki.

The subsection:

• Describes the bech32 encoding for both classic and PQ age identities + their corresponding recipients.
• Adds a worked test vector using the same master xprv as the existing HEX test vector, so a reader can derive both side-by-side from one master.

Scope

This amendment is intentionally minimal:

• No new application number — reuses the existing HEX
  application (128169').
• No normative MUSTs added beyond what BIP-85 already says
  about the HEX application.
• No changes required in existing implementations
  (bipsea, bip85-js, ethankosakovsky/bip85).

Possible follow-ups (not in this PR):

• A dedicated AGE subsection paralleling the existing RSA-GPG subsection, with full worked examples for each flavour and an optional index-partition recommendation (e.g. [0, 1000) for PQ identities, [1000, 2000) for classic identities, to avoid producing the same 32 bytes under two different HRPs when the same master is used for both flavours).
• A dedicated application number for age (e.g. 0x616765' = hex-pack of ASCII "age"), with independent paths per flavour.

These are noted only to clarify that this PR deliberately picks the minimal form; they can be raised separately if there is appetite.

Implementations

Per review, the spec text does not link a reference implementation.
A follow-up PR extending bipsea
with age derivation is planned.

Open question

Should the subsection also include the index-range partition guidance ([0, 1000) for PQ identities, [1000, 2000) for classic identities) to avoid producing the same 32 bytes under two different HRPs when both flavours are derived from one master? Including it would be useful guidance; excluding it keeps the amendment maximally minimal. Open to reviewer preference.

---

cc @ethankosakovsky @akarve — original BIP-85 authors per the
BIP header. Happy to revise based on review feedback.

[akarve]

A few requests for this section:

1. Please insert newlines every ~80-90 chars so this file reads well in a terminal
2. The Dec 2024 date is probably TMI, version makes sense but dates generally don't age well
3. You say "uniformly random" but the point is "cryptographically random"
4. Consider breaking most of the above into a small table for readability and using standard nomenclature like || for concat, etc.

Example: please check the math and semantics (assume what's here is wrong), but to give you the idea:

flavor	role	HRP	bytes encoded in data	encoded string
classic	identity	AGE-SECRET-KEY-	seed (32 B)	AGE-SECRET-KEY- || 1 || AG7WK…UKUMWQ || WNNT4U
classic	recipient	age	X25519(seed, G) (32 B)	age || 1 || m0hhzx…256wslq || mdz8e9
PQ (X-Wing)	identity	AGE-SECRET-KEY-PQ-	seed (32 B, same bytes)	AGE-SECRET-KEY-PQ- || 1 || AG7WK…UKUMWQ || 5AN2M5
PQ (X-Wing)	recipient	age1pq	XWing.pk(seed) (≈1216 B)	age1pq || 1 || (~1950 chars) || (6 chars)

And then define your terms below, G, etc.

[dmonakhov]

Please insert newlines every ~80-90 chars so this file reads well in a terminal
The Dec 2024 date is probably TMI, version makes sense but dates generally don't age well
You say "uniformly random" but the point is "cryptographically random"

Ack. fixed with new version.

please check the math and semantics (assume what's here is wrong),

Oh.. thank you very much for pointing this. Indeed original test vectors was not correct, shame on me.
Please see updated version. test vectors are now correct.

[akarve]

Suggested change

	====Example use: age key derivation====
	====<code>age</code> file encryption keys====

[akarve]

Mostly looks good. Left one and line comment. For the PR description please delete the test vectors as they might have diverged and distract from the PR contents.

[dmonakhov]

Mostly looks good. Left one and line comment. For the PR description please delete the test vectors as they might have diverged and distract from the PR contents.

Done. please see PR updated.