paperback VS clevis

Yes. QR codes are meant to store only a few kilobytes at most. They are not suitable for encoding gigabytes of data.

At perhaps 2KB per page, you'd need 524288 pages to store a 1GB. That's 1048 reams. Please just use an archival optical disk instead.

Even if the scheme using multiple QR codes in sequence rather than a single large code block. The paper backup implementations that use QR codes https://github.com/intra2net/paperbackup https://github.com/cyphar/paperback are only meant to be used for private key backup.

There's a cool paper-based backup tool that also uses Shamir Secret Sharing to let you distribute a bunch of paper copies to your friends to restore a file optically:

https://github.com/cyphar/paperback

Paperback will do it automatically for you, open source and free. Thier README also has recommendations for long term storage of paper.

That exists: https://github.com/cyphar/paperback (or the paper-store script suggested by /u/nurupoga/ below).

there are ready-made solutions for that, like https://github.com/cyphar/paperback

You could encrypt your key info using paperback. This then requires at least X amount of people holding parts of the decrypt key to come together to decrypt your last will.

I know you're joking but there's actually software that was made just for that

Recently learned that Clevis also supports Shamir Secret Sharing, and it's in fact the only way to configure multiple pins even if they're of the same type and authority (ie. the RAID0 of SSS):

https://github.com/latchset/clevis#pin-shamir-secret-sharing

Have a look at clevis and tang. These allow you do have one server - which could be your remote you want to pull from - to be source of the LUKS decryption on the system using tang.

Interesting question. I think so?

https://access.redhat.com/documentation/en-us/red_hat_enterp...

Looks like clevis is gpl3 - so I expect it's not packaged as standard for any of the bsds?

https://github.com/latchset/clevis

See also:

https://security.stackexchange.com/questions/194081/use-tpm2...

https://security.stackexchange.com/questions/39329/how-does-...

https://superuser.com/questions/619721/can-i-use-the-tpm-on-...

I haven't used it myself, but a solution with LUKS, TPM2, and clevis is the way I've seen other people set it up https://github.com/latchset/clevis

There are 3 ways to unlock a volume in a headless environment: - use a keyfile, located on an already available volume - use your device's TPM and utilize systemd-cryptenroll - use Clevis/Tang to unlock volumes remotely

I don't think there is a turnkey solution, but you can build what you are looking for with clevis, LUKS, and dm-crypt

We use clevis against multiple tang servers to provide Network Bound Disk Encryption (NBDE). It's possible to also use TPM2 but it's easier to use multiple tang servers (requiring more than one server to decrypt) in the datacenter.