Backing up your PGP key by hand

Fri May 6 02:45:35 CEST 2022

Sorry for the lame tracking links; that's apparently a setting
automatically enabled by SendGrid which I'm using to send out on my custom
email domain. Hopefully they're disabled now and below are showing the
original URLs as I had pasted them, else I give up, lol.

Demo:

   -
   https://gist.github.com/mattborja/475fa600604073780bd47ada019f98f3#file-demo-pgp-progmem-ino

See also:

   -
   https://www.arduino.cc/reference/en/language/variables/utilities/progmem/
   -
   https://forum.arduino.cc/t/maximum-progmem-data-size-arduino-mega/373448
   -
   https://www.arduino.cc/reference/en/language/functions/communication/wire/

Sorry about that :/

On Thu, May 5, 2022 at 5:30 PM Matt Borja <me at mattborja.dev> 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
> 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://gist.github.com/mattborja/475fa600604073780bd47ada019f98f3#file-demo-pgp-progmem-ino
> <https://u25119845.ct.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9IGbt1wm4vdbS70yUSppRsMQ5onvQAvzfk4AuG3VBsPrYrmXvCsmH2gOu2hhCVW-2FozFc-2BAJFdnKEEvcyDaqRDNxw2t1swznhe-2Byz9n3cIPh4W-2BYBrk-2BpyHiZIKYIQmoMug-3D-3DV0Ta_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDIPfe3Pjl-2BQZwS7yBZWMJnI8TTLxk-2ByGe4pgfFJvX4Bou5C1fI0D7YgUtxldOLGY2VAvmD-2BhNd5ZjVBI84zy0W6wYBQUW2egN3ZvTWqkVgr5Ki25FFuLtzJmFdhajt43EDNI9gvI1fPREu8rqww-2BAuc2ZiZpqBvtHDnygI3FFiPIA-3D-3D>
>
> See also:
>
>    -
>    https://www.arduino.cc/reference/en/language/variables/utilities/progmem/
>    <https://u25119845.ct.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9AQx4M1sn44MZVITLdjuhzbIZb0aXoHDzv0QZtQTVn5G6QeOWF0rMBkEnPOq-2Fj-2F-2Ff7zu1OGBDd7QcTgBhRzyDH4q1Qa4hKC1pW-2B5shivQuz2-pNK_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDIPfe3Pjl-2BQZwS7yBZWMJnIs0eLUh8X8mkQXRXN0qL-2BBI-2FP4WUNAdH68KatJpGY4XnBJc1O9Z-2Fp8uJZzHoJh8CO0VAx7LKYRpllB2X8hoINRB8LODQA9wxUxsUo3vaInLMOtnn1bG-2BPfHIe9vmiIIj8fYGCPCauytMO3gkg1bzIvg-3D-3D>
>    -
>    https://forum.arduino.cc/t/maximum-progmem-data-size-arduino-mega/373448
>    <https://u25119845.ct.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9D9Ta4eWZgsvBZTPHn95mwzOn9PJbOBmsTVroNkfZhHrDU5DGuJrYEOd2BgJLlbEzuoN-2BAHGFNFVmOtv5a8BCVv77dVdCk1P2ur7j9Lk4-2BlxudYJ_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDIPfe3Pjl-2BQZwS7yBZWMJnIOKWoTGe4DPfo8uZNGCmg5Fk1rcQH7bAWfFiVo2b79KBuCgeDyruSwox0wOeeujmNXVfuszbFsPmorLH3NH7EuqPFfGZ2lg7CAr-2B7afdkAYj6tFLteNf1Se9JcpxX7vfp8bl7nO58zU2vmWBMHg4ciw-3D-3D>
>
>
> I actually have another slightly more refined project sort of tabled until
> I have more time freed up (maybe next couple weeks or so). It involves
> allocating and managing zones on a much larger EEPROM space--available on a
> single AT24C256C (32 KB up from 1 KB) which is also I2c, meaning you can
> daisy chain about 8 of these out, if you want to get crazy. Latest
> estimates I came up with suggested I could fit close to 2-3 4096-bit PGP
> private keys on one of these things. And the implementation is much simpler
> using the Wire.h interface
> <https://u25119845.ct.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9AQx4M1sn44MZVITLdjuhzbIZb0aXoHDzv0QZtQTVn5Ge1KfTz6F6zMS-2FfP04-2Fjjt7iLi-2B-2BsXVWXxIkyqKKiRLAwROh2Z2sTwxGYJLPdBVaYSGU1_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDIPfe3Pjl-2BQZwS7yBZWMJnIfjLNgZ7IsVl1oWy83Y8SM8BK9HL-2FneeITNQy9izOirkQE-2BUYita4NN3ZMjmmmGw6yACC-2Fh8McICKg-2FYGQ9n3T131vam4C5Dz0CJQ9zu3V8-2BAEvt-2Ba2XFUtRLE0ggOEd6jWmzE3kdWH4gCZ0AEt8j-2BQ-3D-3D> because
> it actually has the room to store larger amounts of data without messing
> around with PROGMEM. And it's all offline writing too :)
>
> Ping me if you're interested. Otherwise, I'ma go back to what I was doing
> ;)
>
> On Thu, May 5, 2022 at 4:58 PM Jacob Bachmeyer via Gnupg-users <
> gnupg-users at gnupg.org> wrote:
>
>> Lars Noodén via Gnupg-users wrote:
>> > On 5/5/22 01:11, Jacob Bachmeyer wrote:
>> > > Lars Noodén via Gnupg-users wrote:
>> > >> A removable hard drive might be an option, if the storage time
>> > >> is less than a decade and there are decent storage conditions
>> > >> in regards to chemicals, temperature, humidity, and so on.  Flash
>> > >> memory seems to lose
>> > >> its charge rather quickly, measured in months.
>> > >
>> > > Write-once optical media is my preferred means of long-term backup for
>> > > nontrivial amounts of data,
>> > [snip]
>> >
>> > The number of years that the keys and the data they apply to will be
>> > stored unpowered, offline will influence which storage medium is
>> > acceptable for the task.
>> >
>> > Old CD-R were short-lived garage from my experience, but certain models
>> > of recently made CD-R should last a while even under slightly
>> > non-optimal storage conditions before they start flipping bits.
>>
>> This depends on the quality of the media.  I first got a CD-R drive in
>> the mid 2000s and have discs from back then that were still readable
>> when I last looked at them a few years ago.  Admittedly, these have been
>> stored under ordinary room conditions and protected in a disc binder or
>> jewel cases and were not the "bargain basement" media that was also
>> available at the time.  A friend once lamented having something like 3
>> to 5 discs out of a 100-pack of "Great Quality" branded CD-R media that
>> were actually usable; the rest were either rejected during burning or
>> failed immediately upon readback.  It is doubtful that those "Great
>> Quality" discs are still readable today.  There was a significant
>> difference in price:  the discs I used (Maxell/Memorex/Verbatim name
>> brands stand out thinking back) typically cost about $20 for a 50-pack
>> or similar for a 100-pack if on sale, while "Great Quality" was $5 for
>> 100.  You really did get what you paid for, however.
>>
>> There were also direct-write DVD-R camcorders fairly popular in the mid
>> to late 2000s.  I remember news stories about most of Barack Obama's
>> earlier speeches having been lost before his first term as US President
>> had ended because the only recordings had been made by his supporters
>> using those camcorders and cheap DVD-R media that did not last.
>>
>>
>> Note that "nontrivial amounts of data" excludes PGP keys; even a
>> mini-CD-R holds several megabytes.  I will admit that lack of a
>> reasonable backup strategy is one of the reasons I do not presently use
>> PGP for encryption.
>>
>> > [...]
>> >
>> > Whether that bit flip hits anything important is another matter, but
>> > they do add up over time and with enough of them they will eventually
>> > hit something, worse if it hit something compressed.  [...]
>>
>> CD-ROM format has considerable data expansion.  If I remember correctly,
>> a 650MB data CD actually stores something like 2.1GB after applying the
>> various ECC layers.  There are quite a few bits to flip before anything
>> is affected.
>>
>> > Air pollution, temperature, light, and humidity are some of the factors
>> > affecting the lifespan of the physical storage medium.
>>
>> One of the advantages of optical media generally is that the discs are
>> (supposed to be) sealed against their environment.  Absent extremes,
>> (polycarbonate has a melting point, the data is written using very
>> intense light that locally heats the dye layer) environmental effects
>> should be minimal.  Along these lines, while fire will obviously destroy
>> optical media, discs should remain readable after being in a flood, for
>> example.  (Some mold removal may be needed, and the data should be
>> copied to new media in case mold or the chemicals used to remove it
>> adversely affect the integrity of the environmental seal.)
>>
>> > > I have SD cards and USB sticks with data blocks last written
>> > > many years ago and still readable.  Granted, I have never used
>> > > low-end no-name
>> > [snip]
>> >
>> > And by reading them, they have powered up and refreshed the charge.  The
>> > problem applies to such flash storage devices which have been left
>> > unpowered for longer periods of time.
>>
>> No, it does not.  That is not how flash memory works.  Some flash
>> translation layers might do such things in some devices, but I strongly
>> doubt that flash-based microcontrollers have undocumented hardware
>> functions to periodically rewrite the program storage, for example.  In
>> any case, I have both USB sticks and SD cards that have been left
>> entirely unpowered for years and found the data to still be there,
>> certainly much longer than the "few months" you mentioned earlier.
>>
>> Theoretically, the stored charge does eventually leak off of the
>> floating gate, but EEPROMs (and flash, which is essentially the same
>> technology) are generally considered to hold data indefinitely.  The
>> data retention specifications are based on "accelerated aging" tests,
>> which generally involve elevated temperature.  The processes involved
>> are highly nonlinear with respect to temperature and may very easily
>> require centuries at room temperature or not occur at all without
>> elevated temperatures; we do not know because flash storage is only now
>> reaching the milestone of having existed long enough for even the oldest
>> imprints to be reaching even the "accelerated aging" estimated
>> lifespan.  So far, we are not seeing catastrophic losses of data stored
>> in flash.
>>
>>
>> -- Jacob
>>
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>> <https://u25119845.ct.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9EYEqtNOGKM5EVTRJHzYauGZHQfmaLnBrHl5qgXgVVD7vBRgqcz2jUvGsIaK0YTgxw-3D-3DNawK_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDIPfe3Pjl-2BQZwS7yBZWMJnI-2B0b8Q1mfwSefwiyj7U-2BBPFeSplVvSG98ApCuOMsEsulcQx-2B5zXMOh0SEa36HFdc4Dew4WvXJeCtXoTM2GpcCXXP8UP61mE-2FZr73O-2BMQzW2VePklc6-2FuEpTJBgZ6fU0pkoxJB91K-2FYORZOt0-2FYijcYg-3D-3D>
>>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220506/7558818a/attachment.html>