Hi there,
Unless I’m missing something, this is a pattern I see used in release
management where a list of SHA256 checksums for deliverables are provided in a
file, and that checksum file is then clearsigned (or detached if you prefer).
Also known also “signing your checksums file.”
Examples:
>
> If you really care about such long preservation, carving the key into
> stone or baking it in a clay tablet are the only known methods that can
> reliably store data for so long (also because other methods don't exist
> for so long).
I'm also curious about a couple options I don't think I've
cc/reference/en/language/functions/communication/wire/
Sorry about that :/
On Thu, May 5, 2022 at 5:30 PM Matt Borja wrote:
> The EEPROM notes are intriguing to me, and if that's an option you're
> considering, I went ahead and tossed up some old code onto a gist if you're
&
The EEPROM notes are intriguing to me, and if that's an option you're
considering, I went ahead and tossed up some old code onto a gist if you're
interested. It's a crude example of storing PGP private key in flash (vs.
SRAM) using a little PROGMEM hack for the Arduino Uno:
https://u25119845.ct.se
So I guess all that leaves us with at this point is laser welded
inscriptions onto a block of metal, installed backwards as the cornerstone
of the next monument being preserved by a historic society.
It’ll be the next iteration of 3D printing: MIaaB (Metal Inscriptions as a
Backup).
Whole buildin
Does exporting your private key (which already comes encrypted and requires
password authentication) to encrypted USB flash drive then placed under
lock and key not suffice as an offline backup?
Aside: Private keys aren’t the only thing that should be getting backed up.
Revocation certs are perhap