[cypherpunks01]

Nice! With a denser 256 bit card you could store an entire age secret key, and so encrypt any amount of data directly to metal key asymmetrically, only needing the public key at encryption time (keeps metal key safer).

Then thresholding can be done with "sops" (which uses the Hashicorp vault shamir implementation) against groups of age keys. Making it so M of N metal backups are required to decrypt the nuclear codes you're storing.

[ciprian_craciun]

Indeed, this is another use case I've had in mind. (Protect a X25519 private key, and use the public key to encrypt against, without the need to have the private one online.)

However, the current scheme supports only 128 bits, thus requiring two cards per X25519 secret key. (One could of course, extend the sheet to another four blocks.)

Alternatively, one could do either one of the following:

* with the help of `age` (which uses X25519 keys), create a private / public key pair, and use a random secret as the private key password;

* given how X25519 secret keys work (i.e. almost any 256 bit random number, after some tweaking would do), one can just create a random 128 bit number, backup like described here, then to get to a X25519 key, use something like `HMAC-SHA256(key="00bbcc...", message="description of key")` to get the cryptographic material for the X25519 key; (thus one could have an infinite supply of X25519 keys, starting from just a simple 128 bit secret;)

(This second scheme, might reduce the strength of the resulting X25519 keys, however I doubt they can be broken, given the requirement to brute-force the HMAC-SHA256.)