From jcross at gmail.com Mon May 2 13:26:06 2022 From: jcross at gmail.com (Jonathan Cross) Date: Mon, 2 May 2022 13:26:06 +0200 Subject: Backing up your PGP key by hand In-Reply-To: References: Message-ID: Thank you for sharing this Francesco. Yes, having a secure, durable offline backup is important. Coming from the Bitcoin space, we've already explored many options in an effort to allow users easily to back up private keys. I have to say the effort involved in your method seems unrealistic for most users: > Considering a paperkey is less than 150 lines, that means it should take 50 sessions, or a little less than 2? months to get it on paper. The whole effort costs 50?10m ? 8 hours of your time. In Bitcoin, we can use the BIP39 standard to backup nearly infinite number of keys (trees of derived keys) with just 12 simple English words. It even has a checksum! Only in the first four letters of each word are even necessary as those are always distinct making input very quick and easy. GPG would benefit from something similar. Only 1% of the 1% of users, will put in the effort in that you did meaning that most users are not properly backing up their PGP keys and or are trusting computer hardware/printers. I see there is efforts like paperkey word list: https://github.com/vonshednob/paperkeywords But ideally such a system should be standardized and built into gpg so that users can be sure they will be able to restore keys. One can actually use the most popular Bitcoin hardware wallet as a PGP signing device. Since the device is backed up with a BIP39 "seed phrase", you can effectively say that it's a way to backup GPG keys with 12 or 24 words: https://support.ledger.com/hc/en-us/articles/115005200649-OpenPGP?docs=true The fact that It has a screen and you can input the words directly into the signing device means that you don't need an air gap computer as well. That might be a good option for some people. Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Mon May 2 16:26:33 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 02 May 2022 16:26:33 +0200 Subject: Backing up your PGP key by hand In-Reply-To: References: Message-ID: <2135148.NgBsaNRSFp@daneel> On Montag, 2. Mai 2022 13:26:06 CEST Jonathan Cross via Gnupg-users wrote: > I have to say the effort involved in your method seems unrealistic for most > users: > > > Considering a paperkey is less than 150 lines, that means it should take > > 50 sessions, or a little less than 2? months to get it on paper. The whole > > effort costs 50?10m ? 8 hours of your time. For a modern ed25519 key with cv25519 subkey paperkey outputs less than 10 lines of data and a final CRC-24 checksum. 1: 00 04 69 C7 01 A4 36 FD D4 96 FA E5 58 0A A1 51 BC 58 17 C2 28 CF 6A0F72 [...] 10: B2 47 15 98 62 69 A9 53 BC B2 16 8F 9B 78 B4 BAF5C6 11: BBEA88 In the old days computer magazines contained many pages of such hexdumps that you could hack into your computer to get some nice little games. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From fa-ml at ariis.it Tue May 3 21:08:22 2022 From: fa-ml at ariis.it (Francesco Ariis) Date: Tue, 3 May 2022 21:08:22 +0200 Subject: Backing up your PGP key by hand In-Reply-To: References: Message-ID: Hello Jonathan, Il 02 maggio 2022 alle 13:26 Jonathan Cross via Gnupg-users ha scritto: > Thank you for sharing this Francesco. > > Yes, having a secure, durable offline backup is important. > > Coming from the Bitcoin space, we've already explored many options in an > effort to allow users easily to back up private keys. > > I have to say the effort involved in your method seems unrealistic for most > users: > > [...] thanks for you feedback message! As you probably expect, I agree with (almost) everything you say. My experiment was to document something which ? as far as I know ? was not documented until now (although probably done numerous times) and a way to spur a discussion on the topic of ?backing up keys when you cannot trust or do not have access to some devices?. The pain points are manifold: some might be mitigated (as Ingo Kl?cker suggested, ed25519 keys are shorter, progressively moving to them would do a lot); some would need some reworking (or reimagining) of the tools we use today to sign out documents and encrypt out archives (as much as `paperkey` is convenient, a ?native? solution will always be more reliable, user-friendly, future-proof). > But ideally such a system should be standardized and built into gpg so that > users can be sure they will be able to restore keys. This would be amazing and hopefully one day a standardised approach will come to light for PGP too. Happy encrypting everyone ?F From me at mattborja.dev Tue May 3 21:52:21 2022 From: me at mattborja.dev (Matt Borja) Date: Tue, 03 May 2022 19:52:21 +0000 (UTC) Subject: Backing up your PGP key by hand In-Reply-To: References: Message-ID: 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 perhaps just as important, if not more. Private keys can be replaced all day long, but you can?t replace revocation certs once the private key is lost (requiring revocation). On Tue, May 3, 2022 at 12:17 Francesco Ariis wrote: > Hello Jonathan, > > Il 02 maggio 2022 alle 13:26 Jonathan Cross via Gnupg-users ha scritto: > > Thank you for sharing this Francesco. > > > > Yes, having a secure, durable offline backup is important. > > > > Coming from the Bitcoin space, we've already explored many options in an > > effort to allow users easily to back up private keys. > > > > I have to say the effort involved in your method seems unrealistic for > most > > users: > > > > [...] > > thanks for you feedback message! > > As you probably expect, I agree with (almost) everything you say. My > experiment was to document something which ? as far as I know ? was not > documented until now (although probably done numerous times) and a way > to spur a discussion on the topic of ?backing up keys when you cannot > trust or do not have access to some devices?. > > The pain points are manifold: some might be mitigated (as Ingo Kl?cker > suggested, ed25519 keys are shorter, progressively moving to them would > do a lot); some would need some reworking (or reimagining) of the tools > we use today to sign out documents and encrypt out archives (as much as > `paperkey` is convenient, a ?native? solution will always be more > reliable, user-friendly, future-proof). > > > But ideally such a system should be standardized and built into gpg so > that > > users can be sure they will be able to restore keys. > > This would be amazing and hopefully one day a standardised approach will > come to light for PGP too. Happy encrypting everyone > ?F > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://u25119845.ct.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9EYEqtNOGKM5EVTRJHzYauGZHQfmaLnBrHl5qgXgVVD7oMr9xT2-2FmICVLCVAwlw5rA-3D-3Dkqal_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDLD1wRHQ22pUznbAeW1KS-2FdIa6FC4L3OSGS4eMi13SJmdMoCsAM4QauLPgLSkTUmxcckyrs8qWq9hPVlcUr0rWoyhSMFe2wadsqqbPX2NoGeUTwVBVIh3zpoMQrA6U3pfn9vhU6EQgA9CzlMdUxY2JEC2wgCAdSAt7NqLYXDIFiAQ-3D-3D > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.nooden at gmx.com Wed May 4 20:17:49 2022 From: lars.nooden at gmx.com (=?UTF-8?Q?Lars_Nood=c3=a9n?=) Date: Wed, 4 May 2022 21:17:49 +0300 Subject: Backing up your PGP key by hand In-Reply-To: References: Message-ID: On 5/3/22 22:08, Francesco Ariis wrote: [snip] > As you probably expect, I agree with (almost) everything you say. My > experiment was to document something which ? as far as I know ? was > not documented until now (although probably done numerous times) and > a way to spur a discussion on the topic of ?backing up keys when you > cannot trust or do not have access to some devices?. 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. I can't find the original articles on that but here's a secondary source: https://www.ni.com/en-us/support/documentation/supplemental/12/understanding-life-expectancy-of-flash-storage.html Perhaps printing a QR code or barcode would work if it is possible to get the private key to a printer in a secure manner. If you are into further experimentation maybe some graph paper and a black magic marker could be used for making a QR code, with enough persistence or performance art funding. /Lars PS. Thanks for not top-posting. From jcb62281 at gmail.com Thu May 5 00:11:55 2022 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Wed, 04 May 2022 17:11:55 -0500 Subject: Backing up your PGP key by hand In-Reply-To: References: Message-ID: <6272FA2B.2040009@gmail.com> 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, but this view about flash losing data in months is completely ridiculous. Typical data retention specs for flash memory are for decades. If losing data in mere months were acceptable, just about nothing would work, including the computer you use for email -- its firmware is almost certainly in flash and it is probably more than a few months old. 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 Chinesium storage, so that may have something to do with it, but flash memory is far more durable than a few months. Battery-backed SRAM typically has batteries that last longer than that; if flash only held data for months, it would never have been commercially viable for displacing said SRAM. -- Jacob From lars.nooden at gmx.com Thu May 5 09:44:23 2022 From: lars.nooden at gmx.com (=?UTF-8?Q?Lars_Nood=c3=a9n?=) Date: Thu, 5 May 2022 10:44:23 +0300 Subject: Backing up your PGP key by hand In-Reply-To: <6272FA2B.2040009@gmail.com> References: <6272FA2B.2040009@gmail.com> Message-ID: <0c74adc0-580c-2828-6661-03c21a014705@gmx.com> 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. However, it's hard to know until it's too late. And all bets are off for bad storage condistions. Now that the quality has improved, under optimal storage conditions, they ought to retain data for decades: https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/canadian-conservation-institute-notes/longevity-recordable-cds-dvds.html https://www.loc.gov/preservation/resources/rt/NIST_LC_OpticalDiscLongevity.pdf 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. I'm sure BtrFS or OpenZFS might be relevant there. Air pollution, temperature, light, and humidity are some of the factors affecting the lifespan of the physical storage medium. > 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. Again, it depends a bit on what the planned retention period is for the keys and their data. /Lars From guru at unixarea.de Thu May 5 09:58:34 2022 From: guru at unixarea.de (Matthias Apitz) Date: Thu, 5 May 2022 09:58:34 +0200 Subject: Backing up your PGP key by hand In-Reply-To: <0c74adc0-580c-2828-6661-03c21a014705@gmx.com> References: <6272FA2B.2040009@gmail.com> <0c74adc0-580c-2828-6661-03c21a014705@gmx.com> Message-ID: I think, paper tapes as in the years 70 would be the best media for this approach. matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Peace instead of NATO! ??? ?????? ????! Frieden statt NATO! ?Paz en vez de OTAN! From jhs at berklix.com Thu May 5 14:12:34 2022 From: jhs at berklix.com (Julian H. Stacey) Date: Thu, 05 May 2022 14:12:34 +0200 Subject: Backing up your PGP key by hand In-Reply-To: Your message "Thu, 05 May 2022 09:58:34 +0200." Message-ID: <202205051212.245CCYuG030875@fire.js.berklix.net> Matthias Apitz wrote: > I think, paper tapes as in the years 70 would be the best media for this > approach. Paper tape had a high error rate (& tear rate). It chaffed & built dirt on reader, & absorbed finger grease & misread whether optical or capacitive readers. Mylar (plastic) was better, stronger. Often on long paper tapes we'd read several times & compare to ensure probably no errors. Checksums weren't so often available. Our pape tape flew so fast through the reader we held dustbins at ~ 45 degrees to catch it. & then reloaded slower back out of bin onto winder. Cheers, -- Julian Stacey http://berklix.com/jhs/ http://stolenVotes.uk Arm Ukraine, kill Putin mass murderer causing global grain & fuel shortage. From me at mattborja.dev Thu May 5 15:52:49 2022 From: me at mattborja.dev (Matt Borja) Date: Thu, 05 May 2022 13:52:49 +0000 (UTC) Subject: Backing up your PGP key by hand In-Reply-To: <202205051212.245CCYuG030875@fire.js.berklix.net> References: <202205051212.245CCYuG030875@fire.js.berklix.net> Message-ID: 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 building would have to come down to restore from backup, but it?d at least stand the test of weathering? On Thu, May 5, 2022 at 06:44 Julian H. Stacey wrote: > Matthias Apitz wrote: > > I think, paper tapes as in the years 70 would be the best media for this > > approach. > > Paper tape had a high error rate (& tear rate). It chaffed & built > dirt on reader, & absorbed finger grease & misread whether optical > or capacitive readers. Mylar (plastic) was better, stronger. > > Often on long paper tapes we'd read several times & compare to > ensure probably no errors. Checksums weren't so often available. > > Our pape tape flew so fast through the reader we held dustbins at > ~ 45 degrees to catch it. & then reloaded slower back out of bin > onto winder. > > Cheers, > -- > Julian Stacey https://u25119845.ct.sendgrid.net/ls/click?upn=2dQXn-2FuZ4IFXJrxoTvrldvqqxLcoXrCdV6gWFc3-2BDwiGSo0Z8d6K83e32R-2BJhBnZXZwc_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDK-2FZv-2Fiay3xKjt5SlrXDHfdtDQngQuGzQN2K051aIgKwfPvbq0YLpHqZ4AbECeyjWpF0B38q2NVsTI6-2FgwVz9FZ7mf80zRGHBfUF3K1FHgAGBB44fRL6RfIIVwP98xF41Bi5m6UuL2kUz5G-2BM1AGaX2blauQR9a-2Bvi1If-2BaWnVamQ-3D-3D https://u25119845.ct.sendgrid.net/ls/click?upn=2dQXn-2FuZ4IFXJrxoTvrldidM2r9fYLOd-2B1CSkNvZDPA-3Du8bN_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDK-2FZv-2Fiay3xKjt5SlrXDHfdwzZbLWnIj29Hth24AAHKE1l5x4N8SoEGFqhcyzlp9BZTwUzr2qSCkylH0lmM-2FVITWyw3dj91TaYp6XvmUwCGAClbR6POSl2nr3JWTt0bG-2Ft9BfvkU-2FphwsRZG1SUCKUAnTPynQF7YCHTkcZs-2BJ-2Bb1g-3D-3D > Arm Ukraine, kill Putin mass murderer causing global grain & fuel shortage. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://u25119845.ct.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9EYEqtNOGKM5EVTRJHzYauGZHQfmaLnBrHl5qgXgVVD7oMr9xT2-2FmICVLCVAwlw5rA-3D-3DvQcR_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDK-2FZv-2Fiay3xKjt5SlrXDHfdFkMvE8Hcl29FyG48kYmlLt10pWLtgDPW92k2a9zJN5kDephSphPp2-2FVwrSZLPmF1rhao05zPP2-2FvnFlqnwPrbWtMXWC7gdsh3C-2Bj2rZloPSR92Gf88OJ4TEqTIQsnZXEGyQzrhgHZS9kcWzqJnRoAw-3D-3D > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcb62281 at gmail.com Fri May 6 01:42:11 2022 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 05 May 2022 18:42:11 -0500 Subject: Backing up your PGP key by hand In-Reply-To: <0c74adc0-580c-2828-6661-03c21a014705@gmx.com> References: <6272FA2B.2040009@gmail.com> <0c74adc0-580c-2828-6661-03c21a014705@gmx.com> Message-ID: <627460D3.10402@gmail.com> 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 From me at mattborja.dev Fri May 6 02:25:56 2022 From: me at mattborja.dev (Matt Borja) Date: Fri, 06 May 2022 00:25:56 +0000 (UTC) Subject: Backing up your PGP key by hand In-Reply-To: <627460D3.10402@gmail.com> References: <6272FA2B.2040009@gmail.com> <0c74adc0-580c-2828-6661-03c21a014705@gmx.com> <627460D3.10402@gmail.com> Message-ID: 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.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9IGbt1wm4vdbS70yUSppRsMQ5onvQAvzfk4AuG3VBsPrYrmXvCsmH2gOu2hhCVW-2FozFc-2BAJFdnKEEvcyDaqRDNxw2t1swznhe-2Byz9n3cIPh4tmtJZbbj4eNxHx3QmzfV8g-3D-3DkevG_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDIPfe3Pjl-2BQZwS7yBZWMJnI-2F-2BW07si5qDvsgMp1WUyDq-2B7vWDN2JV-2B4L1ZHecivxc22dKrcUB5cbcYyYTx8pSJa9w8VTiC2AC3sotGpusq4jw-2Fk6gDJpa-2Bcmm9lMKhxfF7NTRoVvExf2glKlYOeM4S8OAO-2BJfbidgUYdi7zYOI-2BuQ-3D-3D See also: - https://u25119845.ct.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9AQx4M1sn44MZVITLdjuhzbIZb0aXoHDzv0QZtQTVn5G6QeOWF0rMBkEnPOq-2Fj-2F-2Ff7zu1OGBDd7QcTgBhRzyDH6BBXC0wtfcDwuVmYeObvg6coI4_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDIPfe3Pjl-2BQZwS7yBZWMJnI9hF-2FGHq3ueUG6rxidtqSlsMCnF4a-2B-2Fr0wPhEd3WHKLWjkHUB0NZN3Qd4o6hmF1WG7byhUwE-2FVIlacXPQ2PV2ji4Pw-2FnqpZqwNiGNXiZvjHvoIVtnoWv1Q6CYweQNM2VOCkazeKdCoN9nbWb6598Ivg-3D-3D - https://u25119845.ct.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9D9Ta4eWZgsvBZTPHn95mwzOn9PJbOBmsTVroNkfZhHrDU5DGuJrYEOd2BgJLlbEzuoN-2BAHGFNFVmOtv5a8BCVv8CDiB2IuRiauAKIGu9bRICNOG_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDIPfe3Pjl-2BQZwS7yBZWMJnIOMlScXfFpwRqgzeOoj-2BzS0pUROFKpH-2FmjVM120PshB2I1tx18tpqjHo7CN-2BvYULJiJK8GYsZ56FlPmVQTHgFK9rztyCjsSTi7nHcWekonmfBpogDYpawqHUnKFJcMs-2FzFF5dKcFP5JVXWWtU-2BB2c2Q-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 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://u25119845.ct.sendgrid.net/ls/click?upn=AWAj65NY2UMz4TnmUvFN9EYEqtNOGKM5EVTRJHzYauGZHQfmaLnBrHl5qgXgVVD7oMr9xT2-2FmICVLCVAwlw5rA-3D-3DZSQ7_RtEKULAgbs8GArutgsfJQJI1lr9pAjJUwpaVhpathDIPfe3Pjl-2BQZwS7yBZWMJnIaNZeES-2FvuI8enVsZnpzCQAeAMQ9aToEqX6In0wGW1siKL45MfHjp8-2FjKMYhbvzs9hYtBseE3UnkmINIAjCLkRsjw8zjCTbus64Kmm3oQWj3mtQb1m19-2FthQp3f5ruMZR1oHrAhH7mn4OWHh0UbsUig-3D-3D > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at mattborja.dev Fri May 6 02:45:35 2022 From: me at mattborja.dev (Matt Borja) Date: Fri, 06 May 2022 00:45:35 +0000 (UTC) Subject: Backing up your PGP key by hand In-Reply-To: References: <6272FA2B.2040009@gmail.com> <0c74adc0-580c-2828-6661-03c21a014705@gmx.com> <627460D3.10402@gmail.com> Message-ID: 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 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 > > > See also: > > - > https://www.arduino.cc/reference/en/language/variables/utilities/progmem/ > > - > https://forum.arduino.cc/t/maximum-progmem-data-size-arduino-mega/373448 > > > > 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 > 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 >> >> > _______________________________________________ > 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: From vinay_sajip at yahoo.co.uk Sun May 8 01:33:28 2022 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Sat, 7 May 2022 23:33:28 +0000 (UTC) Subject: Verification of a detached signature fails, what am I missing? References: <272705813.980978.1651966408063.ref@mail.yahoo.com> Message-ID: <272705813.980978.1651966408063@mail.yahoo.com> The following script fails at the verification step. It needs to be run with Bash in a scratch directory. command_status() { ??? if [ $1 = '0' ]; then ??????? echo $'\e[1;32m'Result: Success$'\e[0m' ??? else ??????? echo $'\e[1;31m'Result: Failure \(exit code = $1\)$'\e[0m' ??? fi } GPG=gpg2 rm -rf keys mkdir -p keys chmod 0700 keys killall gpg-agent > /dev/null 2>&1 cat << EOF > key_data.txt Key-Type: DSA Key-Length: 1024 Subkey-Type: ELG-E Subkey-Length: 2048 Name-Comment: A test user Name-Real: Andrew Able Name-Email: andrew.able at example.com Passphrase: aable Expire-Date: 0 %commit EOF COMMON_ARGS="--status-fd 2 --no-tty --no-verbose --fixed-list-mode --batch --with-colons --homedir keys" echo $'\e[1;33m'GPG version ...$'\e[0m' ${GPG} ${COMMON_ARGS} --version | head -1 echo $'\e[1;33m'Generating a key ...$'\e[0m' ${GPG} ${COMMON_ARGS} --gen-key < key_data.txt 2>&1 | tee key_info.txt command_status $? KEYID=$(tail -1 key_info.txt | awk? '{ print $(NF)}') # echo $'\e[1;33m'Key ID: ${KEYID}$'\e[0m' rm key_data.txt key_info.txt echo $'\e[1;33m'Creating random data to sign ...$'\e[0m' dd if=/dev/urandom of=data-to-sign bs=1 count=1024 > /dev/null 2>&1 echo $'\e[1;33m'Signing data, asking for a detached signature ...$'\e[0m' echo aable | ${GPG} --pinentry-mode loopback ${COMMON_ARGS} --passphrase-fd 0 -sa --detach-sign --default-key ${KEYID} | tee sig.asc command_status $? echo $'\e[1;33m'Trying to verify data ...$'\e[0m' ${GPG} ${COMMON_ARGS} --verify sig.asc data-to-sign command_status $? If I run the above, I get GPG version ... gpg (GnuPG) 2.3.6 Generating a key ... gpg: keybox '/disk2/vinay/projects/scratch/gnupg/keys/pubring.kbx' created gpg: /disk2/vinay/projects/scratch/gnupg/keys/trustdb.gpg: trustdb created gpg: directory '/disk2/vinay/projects/scratch/gnupg/keys/openpgp-revocs.d' created [GNUPG:] KEY_CONSIDERED 1ADA97672FD8E615012C75C295CEF1267475C187 0 gpg: revocation certificate stored as '/disk2/vinay/projects/scratch/gnupg/keys/openpgp-revocs.d/1ADA97672FD8E615012C75C295CEF1267475C187.rev' [GNUPG:] KEY_CREATED B 1ADA97672FD8E615012C75C295CEF1267475C187 Result: Success Creating random data to sign ... Signing data, asking for a detached signature ... gpg: using "1ADA97672FD8E615012C75C295CEF1267475C187" as default secret key for signing [GNUPG:] KEY_CONSIDERED 1ADA97672FD8E615012C75C295CEF1267475C187 2 [GNUPG:] BEGIN_SIGNING H2 [GNUPG:] SIG_CREATED D 17 2 00 1651965765 1ADA97672FD8E615012C75C295CEF1267475C187 -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQQa2pdnL9jmFQEsdcKVzvEmdHXBhwUCYnb/RQAKCRCVzvEmdHXB h3FGAJ9zUzSbkYbven89dQZekXn4FaogcwCfXJEoGE0Gar40OKJlNfAJrj4AYE8= =Gye9 -----END PGP SIGNATURE----- Result: Success Trying to verify data ... [GNUPG:] NEWSIG gpg: Signature made Sun 08 May 2022 00:22:45 BST gpg:??????????????? using DSA key 1ADA97672FD8E615012C75C295CEF1267475C187 [GNUPG:] KEY_CONSIDERED 1ADA97672FD8E615012C75C295CEF1267475C187 0 [GNUPG:] KEY_CONSIDERED 1ADA97672FD8E615012C75C295CEF1267475C187 0 gpg: checking the trustdb [GNUPG:] KEY_CONSIDERED 1ADA97672FD8E615012C75C295CEF1267475C187 0 gpg: marginals needed: 3? completes needed: 1? trust model: pgp gpg: depth: 0? valid:?? 1? signed:?? 0? trust: 0-, 0q, 0n, 0m, 0f, 1u [GNUPG:] BADSIG 95CEF1267475C187 Andrew Able (A test user) gpg: BAD signature from "Andrew Able (A test user) " [ultimate] [GNUPG:] FAILURE gpg-exit 33554433 Result: Failure (exit code = 1) What have I missed in terms of arguments passed to GnuPG, or anything else? All help gratefully received. The script is also available (in case the above gets manged by email software) at https://gist.github.com/vsajip/3f6b092d8d72e3b68b3ce21ec3e013b7 Regards, Vinay Sajip -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Sun May 8 15:39:47 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 08 May 2022 15:39:47 +0200 Subject: Verification of a detached signature fails, what am I missing? In-Reply-To: <272705813.980978.1651966408063@mail.yahoo.com> References: <272705813.980978.1651966408063.ref@mail.yahoo.com> <272705813.980978.1651966408063@mail.yahoo.com> Message-ID: <2242153.ElGaqSPkdT@daneel> On Sonntag, 8. Mai 2022 01:33:28 CEST Vinay Sajip via Gnupg-users wrote: > The following script fails at the verification step. It needs to be run with [...] > echo $'\e[1;33m'Creating random data to sign ...$'\e[0m' > dd if=/dev/urandom of=data-to-sign bs=1 count=1024 > /dev/null 2>&1 > echo $'\e[1;33m'Signing data, asking for a detached signature ...$'\e[0m' > echo aable | ${GPG} --pinentry-mode loopback ${COMMON_ARGS} --passphrase-fd > 0 -sa --detach-sign --default-key ${KEYID} | tee sig.asc command_status $? > echo $'\e[1;33m'Trying to verify data ...$'\e[0m' > ${GPG} ${COMMON_ARGS} --verify sig.asc data-to-sign [...] > What have I missed in terms of arguments passed to GnuPG, or anything else? You have missed that you are not passing the file data-to-sign to gpg. I think what happens is that gpg signs the text "aable\n" (and it doesn't use "aable" for the passphrase because it's still in the cache after the generation of the test key). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From sven.r.richter at protonmail.ch Sun May 8 18:24:24 2022 From: sven.r.richter at protonmail.ch (Sven Richter) Date: Sun, 08 May 2022 16:24:24 +0000 Subject: Backing up your PGP key by hand In-Reply-To: <0c74adc0-580c-2828-6661-03c21a014705@gmx.com> References: <6272FA2B.2040009@gmail.com> <0c74adc0-580c-2828-6661-03c21a014705@gmx.com> Message-ID: > 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. Again, it depends a bit on what > the planned retention period is for the keys and their data. A few months ago I rediscovered an old USB stick, whose existence I'd completely forgotten. Had not touched that thing in around eight or nine years. Despite that it read just fine. And we're not talking about some high quality premium device here. Named well known brand yes, but a cheap model. I highly doubt the "flash can only store for a few months". In my personal experience flash can survive for many years. Sure, sometimes new drives and cards can fail really quickly, but the same can be said about other media like HDDs too. If it survives the first couple months (or even weeks) then it will most likely last for years. I still remember buying some first generation consumer SSDs back in 2010. Back then everybody was wary, saying the tech is too new and flash doesn't life long enough. Used some of those drives in computers that run 24/7 and the last of them was replaced when it showed signs of dying about year ago (early 2021). I'd say eleven years was a decent lifespan. ;) In my opinion the longevity of flash, no matter the format, is greatly underestimated. Plus a real advantage I noticed is that many drives don't die suddenly like HDDs tend to do, instead they often die slowly giving you time to replace them. As such I wouldn't mind at all storing my keys on a flash drive. Also, if you have valuable data you should always store it on at least two devices that are physically separated anyway. So if one fails it shouldn't be a big deal. (With all of that being said, I'd still be in favor of an easy way to store on paper.) Greetings Sven ------- Original Message ------- On Thursday, May 5th, 2022 at 7:44 AM, 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. > However, it's hard to know until it's too late. And all bets are off > for bad storage condistions. Now that the quality has improved, under > optimal storage conditions, they ought to retain data for decades: > > https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/canadian-conservation-institute-notes/longevity-recordable-cds-dvds.html > > https://www.loc.gov/preservation/resources/rt/NIST_LC_OpticalDiscLongevity.pdf > > 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. I'm sure BtrFS or > OpenZFS might be relevant there. > > Air pollution, temperature, light, and humidity are some of the factors > affecting the lifespan of the physical storage medium. > > > 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. Again, it depends a bit on what > the planned retention period is for the keys and their data. > > /Lars > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - sven.r.richter at protonmail.ch - 0x141E8192.asc Type: application/pgp-keys Size: 1159 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From rik at oemail.nl Fri May 13 14:04:51 2022 From: rik at oemail.nl (rik at oemail.nl) Date: Fri, 13 May 2022 14:04:51 +0200 Subject: question Gnupg Message-ID: <00c001d866c1$a830c780$f8925680$@oemail.nl> dear GnuPG users, apologies if I'm asking something that is described in the documentation, but i could not find it there. Is there a way to sync your public search keys library in Kleopatra across multiple PCs? For example by syncing the folder in which the keys are stored? If so, which folder do you recommend to sync for this? Please CC (rik at oemail.nl ) me as I am not subscribed to this mailing list. thanks, Rik -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at enigmail.net Sun May 15 11:08:19 2022 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 15 May 2022 11:08:19 +0200 Subject: [openpgp-email] Invitation to the 6th OpenPGP Email Summit In-Reply-To: <4d0650c8-55da-1099-1f88-05fe1bff520a@enigmail.net> References: <4d0650c8-55da-1099-1f88-05fe1bff520a@enigmail.net> Message-ID: <895f5e87-cbb5-12dd-d5db-6a412e3f6c6c@enigmail.net> The OpenPGP Email Summit will start in 12 Days. If you want to attend, then please add your name to the following Cryptpad, such that we can plan for food, drinks etc. https://cryptpad.fr/pad/#/2/pad/edit/EtMIfWF2q6qP+c3iv8qNH+x0/ See you soon! -Patrick Patrick Brunschwig wrote on 18.04.2022 11:43: > I'm happy to announce the 6th OpenPGP Email Summit which will take place > > Friday, May 27 & Saturday, May 28, 2022 > in Geneva (Switzerland) at the offices of Proton AG > (the company behind ProtonMail and OpenPGP.js) > > For those who are interested in chatting, hacking or starting > discussions prior to the "real" summit, there is the option to already > meet on Thursday, May 26. > > REGISTRATION > ============ > > If you want to attend, please add yourself to the following cryptpad: > https://cryptpad.fr/pad/#/2/pad/edit/EtMIfWF2q6qP+c3iv8qNH+x0/ > > If you need funding for your travel/hotel expenses, then please get > in contact with me. > > > ABOUT THE OpenPGP EMAIL SUMMIT > ============================== > > This is an event open for anybody involved in the development of email > clients using OpenPGP for encryption, and related software. > > We already had 5 OpenPGP Email Summits at various locations in Europe. > These are meetings by technical experts of projects and tools dealing > with OpenPGP with a focus on email encryption. The goals are to better > get to know each other, and to discuss and work on several technical > issues that hopefully improve certain aspects of OpenPGP-based email > encryption. For details, see > https://wiki.gnupg.org/OpenPGPEmailSummits > > > > NOTES > ===== > This is a meeting of those who develop software. Thus, we will have a > lot of tech talk about key servers, key exchange, subject encryption, > password recovery, etc. > > Thus, feel free to join us if you are working in the area of > - TECHNICAL DETAILS > - for SENDING or PROCESSING ENCRYPTED EMAILS > - with OpenPGP > - in a project or product. > > Note that this is neither a well-organized conference nor a commercial > meeting. The agenda will be driven by the attendees. Anyone may propose > any topic for discussion, as long as he/she is ready to lead the discussion. > > More details are available on the web site: > https://wiki.gnupg.org/OpenPGPEmailSummit202205 > > > Looking forward to meeting you in Geneva > -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 834 bytes Desc: OpenPGP digital signature URL: From brandon753.ba at gmail.com Mon May 16 11:43:03 2022 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Mon, 16 May 2022 02:43:03 -0700 Subject: Question with Subkeys and Yubikeys Message-ID: Hello, I have a gpg key that was generated on a yubikey with the gpg card generate command. I now have a second yubikey, and I would like to generate and store a signature and authentication subkey on this second yubikey, but I am running into some issues. Ideally, I would like to be able to type in `gpg --expert --edit-key KeyID` and then go `addcardkey` with the secondary yubikey attached. This starts to work and generates a key on the secondary yubikey, but then it will ask me to insert the primary yubikey presumably to sign the change; however, even after I insert the primary yubikey, GPG does not recognize it, and if I remove the secondary yubikey the process is aborted. The other thing I tried was to run `generate` on the secondary yubikey so that it would generate its key slots and then once again run `gpg --expert --edit-key KeyID`, but this time called `addkey` and select option 13 to add an existing key hoping that it would just need the primary yubikey to sign off on the changes. Still, even after it asks for the pin of the primary yubikey, it then asks for the secondary yubikey and runs into the same issue. What is the best way to do this where the subkeys are generated on the yubikey and then signed by the primary yubikey? Also, unrelated question, but I could not find much information on this; on the Yubico website, it says if you call generate on the smartcard >When prompted, specify if you want to make an off-card backup of your encryption key. ?>Note: This is a shim backup of the private key, not a full backup, and cannot be used to restore to a new YubiKey. What exactly is a shim backup? Is this just the private encryption key but nothing else, or does it not actually include any private encryption key? Is there a way to generate this key where the encryption key is never exposed outside the yubikey? -- Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 15480 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From 2458099 at gmail.com Mon May 16 20:25:17 2022 From: 2458099 at gmail.com (Gilberto F da Silva) Date: Mon, 16 May 2022 15:25:17 -0300 Subject: question Gnupg In-Reply-To: <00c001d866c1$a830c780$f8925680$@oemail.nl> References: <00c001d866c1$a830c780$f8925680$@oemail.nl> Message-ID: I've never been able to do this through graphical interfaces. I put all public keys in a directory and use the command line: gpg --import *asc -- Stela dato:2.459.716,266 Loka tempo:2022-05-16 15:22:42 Lundo Mageia 8 -==- ?Sendu mesa?ojn nur al homoj a? retlistoj kiuj vere povas interesi?i pri ili. Se vi nepre volas sendi al multaj adresoj, metu ilin en la kampon bcc por ke ne komenci?u amasa respondado al ?iuj. --Retiketo On Fri, May 13, 2022 at 02:04:51PM +0200, rik at oemail.nl wrote: >dear GnuPG users, > >apologies if I'm asking something that is described in the documentation, but i >could not find it there. >Is there a way to sync your public search keys library in Kleopatra across >multiple PCs? For example by syncing the folder in which the keys are stored? >If so, which folder do you recommend to sync for this? > >Please CC (rik at oemail.nl) me as I am not subscribed to this mailing list. >thanks, >Rik > >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >https://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 390 bytes Desc: not available URL: From stuartl at longlandclan.id.au Mon May 23 05:01:27 2022 From: stuartl at longlandclan.id.au (Stuart Longland) Date: Mon, 23 May 2022 13:01:27 +1000 Subject: Backing up your PGP key by hand In-Reply-To: References: Message-ID: <20220523130127.7cb87dbb@longlandclan.id.au> On Tue, 03 May 2022 19:52:21 +0000 (UTC) Matt Borja wrote: > 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? If the USB flash drive does not fail, then yes, it would suffice. NAND Flash memory (the sort used in USB flash drives), relies on a static charge being placed on the gate of a MOSFET to "bias" the MOSFET on or off. In a perfect world, that gate is perfectly insulated and will not leak. We don't live in such a world, there is a non-infinite resistance that allows a leakage current, and the charge will eventually fade. How long will that take? Who knows? On the other hand, there are paper recordings that have lasted millennia. Personally, I'm eyeing off the A3 pen-plotter that's at my feet right now and wondering whether I could get it to "draw" a QR code or similar 2D barcode of a private key. Sure, it's computer-driven, but it's old enough to not have the storage capacity to "remember" an A3 image of a private key. Make such a program also emit G-code, and you could likely use any el-cheapo 3D printer mechanism to cobble together such a plotter. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. From jhs at berklix.com Mon May 23 13:44:47 2022 From: jhs at berklix.com (Julian H. Stacey) Date: Mon, 23 May 2022 13:44:47 +0200 Subject: Backing up your PGP key by hand In-Reply-To: Your message "Mon, 23 May 2022 13:01:27 +1000." <20220523130127.7cb87dbb@longlandclan.id.au> Message-ID: <202205231144.24NBilKg045052@fire.js.berklix.net> Stuart Longland via Gnupg-users wrote: > On Tue, 03 May 2022 19:52:21 +0000 (UTC) > Matt Borja wrote: > > > 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? > > If the USB flash drive does not fail, then yes, it would suffice. > > NAND Flash memory (the sort used in USB flash drives), relies on a > static charge being placed on the gate of a MOSFET to "bias" the MOSFET > on or off. > > In a perfect world, that gate is perfectly insulated and will not leak. > > We don't live in such a world, there is a non-infinite resistance that > allows a leakage current, and the charge will eventually fade. How > long will that take? Who knows? 1 of 2 electret condenser microphones (Unisound EM-850), bought ~ 1976, has failed so far with me. The industry did back then expect them to discharge eventually. They've only been used for minutes each decade, so it wasn't over use. Dometic storage temperate humidity & temperature, not hot or cold warehouse, not polar or tropics, boxed, no sunshine, no ionising radiaton beyond domestic terrestial. https://en.wikipedia.org/wiki/Electret_microphone Disk manufacturers' data sheets on error rates were a sobering experience years back. Probably the same for USB sticks now. Best copy on multiple media types from different manufacturers. Cheers, -- Julian Stacey http://berklix.com/jhs/ http://stolenVotes.uk Arm Ukraine, Zap killer Putin, grain & fuel loss hits poorest. From johanw at vulcan.xs4all.nl Wed May 25 21:13:06 2022 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 25 May 2022 21:13:06 +0200 Subject: Backing up your PGP key by hand In-Reply-To: <20220523130127.7cb87dbb@longlandclan.id.au> References: <20220523130127.7cb87dbb@longlandclan.id.au> Message-ID: <353b9b94-4d10-8814-b927-2e314aba146f@vulcan.xs4all.nl> On 2022-05-23 5:01, Stuart Longland via Gnupg-users wrote: > On the other hand, there are paper recordings that have lasted millennia. Since paper as we know it today doesn't even exist so long that can't be true. Maybe you are pointing to the few surviving papyrus texts? Most have not survived. 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). Even if the USB stick lasts for millennia, there may not be a reader for it around at that time. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From fa-ml at ariis.it Wed May 25 22:22:18 2022 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 25 May 2022 22:22:18 +0200 Subject: Backing up your PGP key by hand In-Reply-To: <353b9b94-4d10-8814-b927-2e314aba146f@vulcan.xs4all.nl> References: <20220523130127.7cb87dbb@longlandclan.id.au> <353b9b94-4d10-8814-b927-2e314aba146f@vulcan.xs4all.nl> Message-ID: Il 25 maggio 2022 alle 21:13 Johan Wevers via Gnupg-users ha scritto: > On 2022-05-23 5:01, Stuart Longland via Gnupg-users wrote: > > > On the other hand, there are paper recordings that have lasted millennia. > > Since paper as we know it today doesn't even exist so long that can't be > true. Maybe you are pointing to the few surviving papyrus texts? Most > have not survived. Paper was first made in the Chinese Empire, around two millennia ago. Sheets made with high quality pulp survived to this day. Process is slightly different today, archivists also know a lot more about what is dangerous to paper preservation. From rjh at sixdemonbag.org Thu May 26 03:48:16 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 25 May 2022 21:48:16 -0400 Subject: Backing up your PGP key by hand In-Reply-To: <353b9b94-4d10-8814-b927-2e314aba146f@vulcan.xs4all.nl> References: <20220523130127.7cb87dbb@longlandclan.id.au> <353b9b94-4d10-8814-b927-2e314aba146f@vulcan.xs4all.nl> Message-ID: <46c47226-a1c9-31f9-c5d9-0afc56751476@sixdemonbag.org> > Since paper as we know it today doesn't even exist so long that can't > be true. Maybe you are pointing to the few surviving papyrus texts? > Most have not survived. I've personally seen paper ballots from elections in the Senate of ancient Rome. Admittedly, this was 15 years ago so I can no longer say precisely which century they were from, but they were indeed paper and the marks on them were still legible. The reason why few paper texts survived to the modern day isn't that paper isn't durable. It's because paper *IS* durable. It's a fantastically useful material and, for most of human history, was incredibly expensive. Rather than preserve paper, people re-used it again and again until it just wore out. (They did the same thing with vellum, too, which was preferred not because it stood up to repeated use better, but because it was so much *cheaper*.) Many Gutenberg Bibles are still in fine condition today. Of about 160 copies printed, about fifty still exist today. The paper in question is linen, which is still used by archivists looking for long-term preservation. So, yeah. I'm going to be solidly on the side of "no, really, paper is a magic technology, just be sure to talk with an archivist first to ensure you're using the right kind of paper." From dirk.gottschalk1980 at googlemail.com Wed May 25 22:58:11 2022 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Wed, 25 May 2022 22:58:11 +0200 Subject: Error importing fetching key from wkd Message-ID: <6ba2f00166ce2ce5146dfd8a087758f4f5b6e1f9.camel@googlemail.com> Hello. IO tried to fetch a key from WKD, in this case the key of Werner Koch. Everytime I try this I get the following error: --- $ LANG=C gpg -v --locate-key wk at gnupg.org gpg: pub ed25519/63113AE866587D0A 2018-09-28 wk at gnupg.org gpg: error writing keyring '/home/dgottschalk/.gnupg/pubring.kbx': Unknown elliptic curve gpg: error reading '[stream]': Unknown elliptic curve gpg: Total number processed: 0 gpg: error retrieving 'wk at gnupg.org' via WKD: Unknown elliptic curve gpg: error retrieving 'wk at gnupg.org' via DANE: No name gpg: error retrieving 'wk at gnupg.org' via ?: No name gpg: Total number processed: 0 gpg: auto-key-locate found fingerprint A4D94E92B0986AB5EE9DCD755DE249965B0358A2 gpg: error retrieving 'wk at gnupg.org' via DNS CERT: No public key gpg: data source: https://keys.openpgp.org:443 gpg: error retrieving 'wk at gnupg.org' via keyserver: No data gpg: error reading key: No data --- Any hints what happens there? This also happens when I use an empty Keybox with this commnd: $ gpg -v --no-default-keyring --keyring=test/keyring.kbx --locate-key wk at gnupg.org My GnuPG-Version knows ed25519 as you can see below: --- $ gpg --with-colons --list-config curve cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;secp25 6k1 --- My GPG-Version: --- $ gpg --version --no-greeting gpg (GnuPG) 2.3.6 libgcrypt 1.10.1-unknown Copyright (C) 2021 Free Software Foundation, Inc. License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/dgottschalk/.gnupg Unterst?tzte Verfahren: ?ff. Schl?ssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Verschl?.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 AEAD: EAX, OCB Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2 --- Thank you in Advance. Kind Regards, Dirk -- Dirk Gottschalk GPG key Fingerprint: 7C5B 9D53 EED5 C7B3 A291 D5AA 086B 3660 27E3 5D06 Keyoxide:?https://keyoxide.org/7C5B9D53EED5C7B3A291D5AA086B366027E35D06 GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From bvea at tutanota.com Thu May 26 10:35:18 2022 From: bvea at tutanota.com (bvea at tutanota.com) Date: Thu, 26 May 2022 10:35:18 +0200 (CEST) Subject: npth1.6 integrity check issue Message-ID: Hello, I'm building gpg and its dependencies from source, using dependencies downloaded from the gnupg.org downloads page https://gnupg.org/download/index.html. I've imported the key specified on the website and have verified the gpg source and all of the dependencies except for npth1.6. When I try to verify npth, the output is gpg: Signature made Mon 16 Jul 2018 12:37:23 AM PDT gpg: ? ? ? ? ? ? ? ?using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 gpg: Can't check signature: No public key Looking around on the internet I can find some indication that this is an old key belonging to Werner Koch that expired in 2019, but I would like to be able to properly verify npth before building it. Can anyone advise on how best to proceed? Many thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Thu May 26 17:15:06 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 26 May 2022 17:15:06 +0200 Subject: npth1.6 integrity check issue In-Reply-To: References: Message-ID: <5829043.lOV4Wx5bFT@daneel> On Donnerstag, 26. Mai 2022 10:35:18 CEST bvea--- via Gnupg-users wrote: > I've imported the key specified on > the website and have verified the gpg source and all of the dependencies > except for npth1.6. When I try to verify npth, the output is > > gpg: Signature made Mon 16 Jul 2018 12:37:23 AM PDT > gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 > gpg: Can't check signature: No public key > > Looking around on the internet I can find some indication that this is an > old key belonging to Werner Koch that expired in 2019, but I would like to > be able to properly verify npth before building it. Can anyone advise on > how best to proceed? https://gnupg.org/download/integrity_check.html points to https://gnupg.org/signature_key.html At the end of this page you can download "a public key block with expired keys used to sign older releases". It contains 5 keys including Werner's key that expired in 2019 (and not just the 2 former signature keys that are confusingly mentioned on the page). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From maxime at cerno.tech Thu May 26 18:38:02 2022 From: maxime at cerno.tech (Maxime Ripard) Date: Thu, 26 May 2022 18:38:02 +0200 Subject: Moving subkey to TPM fails Message-ID: <20220526163802.qazoyhj5nwvkrd57@houat> Hi, I've been trying to setup two NIST P256 signing key and authorization key into the TPM of a laptop I just received. I generated the subkeys, but when running keytotpm, it fails with: error from TPM: Not supported The NIST P256 algorithm seems to be supported though, since it's mandatory in the TPM2 spec as far as I'm aware, and the TPM reports it as supported anyway: $ tpm2_getcap ecc-curves TPM2_ECC_NIST_P256: 0x3 TPM2_ECC_NIST_P384: 0x4 Is there any way to debug this further? Thanks! Maxime -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Sat May 28 20:29:38 2022 From: wk at gnupg.org (Werner Koch) Date: Sat, 28 May 2022 20:29:38 +0200 Subject: Error importing fetching key from wkd In-Reply-To: <6ba2f00166ce2ce5146dfd8a087758f4f5b6e1f9.camel@googlemail.com> (Dirk Gottschalk via Gnupg-users's message of "Wed, 25 May 2022 22:58:11 +0200") References: <6ba2f00166ce2ce5146dfd8a087758f4f5b6e1f9.camel@googlemail.com> Message-ID: <8735gty0h9.fsf@wheatstone.g10code.de> On Wed, 25 May 2022 22:58, Dirk Gottschalk said: > $ gpg --with-colons --list-config curve > cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;secp25 > 6k1 This should read cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1 Note the Brainpool curves. Seems that Redhat still patches them out of libgcrypt. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tmz at pobox.com Sat May 28 22:14:53 2022 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 28 May 2022 16:14:53 -0400 Subject: Error importing fetching key from wkd In-Reply-To: <8735gty0h9.fsf@wheatstone.g10code.de> References: <6ba2f00166ce2ce5146dfd8a087758f4f5b6e1f9.camel@googlemail.com> <8735gty0h9.fsf@wheatstone.g10code.de> Message-ID: Hi, Werner Koch via Gnupg-users wrote: > On Wed, 25 May 2022 22:58, Dirk Gottschalk said: > >> $ gpg --with-colons --list-config curve >> cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;secp25 >> 6k1 > > This should read > > cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1 > > Note the Brainpool curves. Seems that Redhat still patches them out of > libgcrypt. The question of whether these curves can be kept in Fedora was brought up on the fedora-legal list some time ago. The most recent status update? from Fedora Project Leader Matthew Miller on January 28, 2022 says: Sooooo, these things move slowly, but this _is_ being worked on. I'll let you know when I can. That sounds midly hopeful. With luck, the curves will be cleared for inclusion (at least eventually, even it not terribly soon). ? https://lists.fedoraproject.org/archives/list/legal at lists.fedoraproject.org/message/3ESF4KDVMLQPZX4H2S4L7BP5BHJPMPMB/ -- Todd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From johanw at vulcan.xs4all.nl Sun May 29 13:00:17 2022 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 29 May 2022 13:00:17 +0200 Subject: Backing up your PGP key by hand In-Reply-To: References: <20220523130127.7cb87dbb@longlandclan.id.au> <353b9b94-4d10-8814-b927-2e314aba146f@vulcan.xs4all.nl> Message-ID: On 2022-05-25 22:22, Francesco Ariis wrote: > Paper was first made in the Chinese Empire, around two millennia ago I see that that was indeed considered what we call paper today, unlike the ancient Egyptian papyrus. > Sheets made with high quality pulp survived to this day. Some sheets survive. I'm sure some CDR's and some USB sticks will also survive for many centuries, but most probably won't. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From johanw at vulcan.xs4all.nl Sun May 29 13:07:06 2022 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 29 May 2022 13:07:06 +0200 Subject: Error importing fetching key from wkd In-Reply-To: <8735gty0h9.fsf@wheatstone.g10code.de> References: <6ba2f00166ce2ce5146dfd8a087758f4f5b6e1f9.camel@googlemail.com> <8735gty0h9.fsf@wheatstone.g10code.de> Message-ID: On 2022-05-28 20:29, Werner Koch via Gnupg-users wrote: > Note the Brainpool curves. Seems that Redhat still patches them out of > libgcrypt. Why do they do that? BTW, when I search for brainpool I only find definitions and RFC's, I seem unable to find why they are needed (or why they would be peferred) over other curves. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From dirk.gottschalk1980 at googlemail.com Sun May 29 15:48:39 2022 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 29 May 2022 15:48:39 +0200 Subject: Error importing fetching key from wkd In-Reply-To: <8735gty0h9.fsf@wheatstone.g10code.de> References: <6ba2f00166ce2ce5146dfd8a087758f4f5b6e1f9.camel@googlemail.com> <8735gty0h9.fsf@wheatstone.g10code.de> Message-ID: <1ea9317fc2bc17ff7aac94c0c692f2c73880162a.camel@googlemail.com> Hello Werner. Am Samstag, dem 28.05.2022 um 20:29 +0200 schrieb Werner Koch: > On Wed, 25 May 2022 22:58, Dirk Gottschalk said: > > > $ gpg --with-colons --list-config curve > > cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;se > > cp25 > > 6k1 > > This should read > > cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;brai > npoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1 > > Note the Brainpool curves.? Seems that Redhat still patches them out > of > libgcrypt. Yes, they really do '--disable-brainpool' in the .spec file. Thank you very much for this hint. I did a custom Rebuild of the package after modifying the .spec and now everything woks as expected. Kind regards, Dirk -- Dirk Gottschalk GPG key Fingerprint: 7C5B 9D53 EED5 C7B3 A291 D5AA 086B 3660 27E3 5D06 Keyoxide:?https://keyoxide.org/7C5B9D53EED5C7B3A291D5AA086B366027E35D06 GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Sun May 29 20:24:38 2022 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 29 May 2022 20:24:38 +0200 Subject: Error importing fetching key from wkd In-Reply-To: References: <6ba2f00166ce2ce5146dfd8a087758f4f5b6e1f9.camel@googlemail.com> <8735gty0h9.fsf@wheatstone.g10code.de> Message-ID: <4c297d6a298758101f4cca0995a6100c46ec0157.camel@googlemail.com> Hello Todd. Am Samstag, dem 28.05.2022 um 16:14 -0400 schrieb Todd Zullinger via Gnupg-users: > Hi, > > Werner Koch via Gnupg-users wrote: > > On Wed, 25 May 2022 22:58, Dirk Gottschalk said: [...] > > > Note the Brainpool curves.? Seems that Redhat still patches them > > out of > > libgcrypt. > > The question of whether these curves can be kept in Fedora > was brought up on the fedora-legal list some time ago.? The > most recent status update? from Fedora Project Leader > Matthew Miller on January 28, 2022 says: > > ??? Sooooo, these things move slowly, but this _is_ being > ??? worked on. I'll let you know when I can. > > That sounds midly hopeful.? With luck, the curves will be > cleared for inclusion (at least eventually, even it not > terribly soon). A workaround for this is to download the SRPM, remove the line '-- disable-brainpool' and rebuild the package. Regards, Dirk -- Dirk Gottschalk GPG key Fingerprint: 7C5B 9D53 EED5 C7B3 A291 D5AA 086B 3660 27E3 5D06 Keyoxide:?https://keyoxide.org/7C5B9D53EED5C7B3A291D5AA086B366027E35D06 GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From vedaal at nym.hush.com Sun May 29 20:00:37 2022 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Sun, 29 May 2022 21:00:37 +0300 Subject: Backing up your PGP key by hand In-Reply-To: <46c47226-a1c9-31f9-c5d9-0afc56751476@sixdemonbag.org> References: <20220523130127.7cb87dbb@longlandclan.id.au> <353b9b94-4d10-8814-b927-2e314aba146f@vulcan.xs4all.nl> <46c47226-a1c9-31f9-c5d9-0afc56751476@sixdemonbag.org> Message-ID: <20220529180037.DCB1980F32C@smtp.hushmail.com> On 5/26/2022 at 12:52 AM, "Robert J. Hansen via Gnupg-users" wrote: So, yeah. I'm going to be solidly on the side of "no, really, paper is a magic technology, just be sure to talk with an archivist first to ensure you're using the right kind of paper." ===== The other thing to consider is the Ink. In Ancient and Medieval times, the ink was not standardized, and varied in the quantity of the ingredients. All were permanent but some were too acidic and burned through the paper. Many monastery manuscripts centuries old are still in very good condition. Today there are "Bulletproof" permanent inks (not resistant to real bullets, but resistant to water, alcohol, bleach, soap, and known solvents.) https://www.jetpens.com/blog/Noodler-s-Fountain-Pen-Inks-A-Comprehensive-Guide/pt/902#bulletproof The Noodler Eternal inks are available in a larger variety of permanent colors, and are all fountain pen safe. https://noodlersink.com/product/19208-eternal-polar-blue/ Vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmz at pobox.com Sun May 29 21:19:48 2022 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 29 May 2022 15:19:48 -0400 Subject: Error importing fetching key from wkd In-Reply-To: <4c297d6a298758101f4cca0995a6100c46ec0157.camel@googlemail.com> References: <6ba2f00166ce2ce5146dfd8a087758f4f5b6e1f9.camel@googlemail.com> <8735gty0h9.fsf@wheatstone.g10code.de> <4c297d6a298758101f4cca0995a6100c46ec0157.camel@googlemail.com> Message-ID: Hi, Dirk Gottschalk via Gnupg-users wrote: > A workaround for this is to download the SRPM, remove the > line '--disable-brainpool' and rebuild the package. Ahh, excellent. That's a relatively recent change. It's available in the Fedora (and RHEL) libgcrypt-1.10 packages which I believe are only in the freshly released Fedora 36 and RHEL 9. Previous releases contained a 'hobbled' libgcrypt tarball where the brainpool curves were removed entirely. (That's the usual practice for items which cannot be included for legal reasons.) It's good to see things are moving in the right direction, at least. -- Todd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From wk at gnupg.org Mon May 30 09:27:44 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 May 2022 09:27:44 +0200 Subject: Error importing fetching key from wkd In-Reply-To: (Johan Wevers via Gnupg-users's message of "Sun, 29 May 2022 13:07:06 +0200") References: <6ba2f00166ce2ce5146dfd8a087758f4f5b6e1f9.camel@googlemail.com> <8735gty0h9.fsf@wheatstone.g10code.de> Message-ID: <8735greaz3.fsf@wheatstone.g10code.de> On Sun, 29 May 2022 13:07, Johan Wevers said: > Why do they do that? BTW, when I search for brainpool I only find > definitions and RFC's, I seem unable to find why they are needed (or why > they would be peferred) over other curves. That is mostly a political issue: In Europe the use of NIST curves is not allowed due to security concerns. In the US the Brainpool curves are not yet part of the FIPS standard and thus may not be used by the government. However, Curve25519 is also not allowed by FIPS but still included in RedHat's Libgcrypt build. I am not aware of any patent issues with standard Weierstrass curves like NIST-P and Brainpool-P curves. All relevant patents expired a few years ago. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From me at mattborja.dev Mon May 30 21:52:07 2022 From: me at mattborja.dev (Matt Borja) Date: Mon, 30 May 2022 19:52:07 +0000 (UTC) Subject: Backing up your PGP key by hand In-Reply-To: <353b9b94-4d10-8814-b927-2e314aba146f@vulcan.xs4all.nl> References: <20220523130127.7cb87dbb@longlandclan.id.au> <353b9b94-4d10-8814-b927-2e314aba146f@vulcan.xs4all.nl> Message-ID: > > 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 seen mentioned as of yet: - What about using a laminator in conjunction with the paper hard copy in the interest of longevity; and perhaps one of these all-weather Plano cases (or perhaps cheaper/simpler: some ABS/PVC encasing)? - If we somehow trust the currently available cryptography systems used to protect our financial assets (i.e. TLS to encrypt your *connection* to your bank website, etc.) and identity and tax information (i.e. bank account information, social security, AGI, PII, business, etc.), could the same also not be trusted to: 1) encrypt your private key and enable you to 2) stored said encrypted private key to a redundant medium like a cloud-based vault (multiple). - Related to this approach: Is the passphrase on a private key not sufficient encryption strength to store the private key in a secure cloud vault for archival purposes; or could it not be paired with a second factor to derive the same archival benefit? Seems to me that achieving indefinite longevity could be more readily done on a computer system that makes it easy to *replicate* bytes on disk; if some encryption system trustworthy enough exists and could be used to protect said bytes before replication. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue May 31 10:12:56 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 May 2022 10:12:56 +0200 Subject: Backing up your PGP key by hand In-Reply-To: (Matt Borja's message of "Mon, 30 May 2022 19:52:07 +0000 (UTC)") References: <20220523130127.7cb87dbb@longlandclan.id.au> <353b9b94-4d10-8814-b927-2e314aba146f@vulcan.xs4all.nl> Message-ID: <87ee0ace7r.fsf@wheatstone.g10code.de> On Mon, 30 May 2022 19:52, Matt Borja said: > - Related to this approach: Is the passphrase on a private key not > sufficient encryption strength to store the private key in a secure cloud > vault for archival purposes; or could it not be paired with a The currently used protection of private keys as specified by OpenPGP allows to attack the key iff the attacker has a way to modify the protected key on the transport. This is not the old Klima/Rosa attack but a new attack which takes advantage of the fact that the public key parts are not bound to the encrypted private parts of the key. Thus the suggestion is to not rely on the OpenPGP private key protection but to convey those private keys with an additional OpenPGP encryption layer. Note that the internal format used by GnuPG to store the private keys is not affected buy this attack. This is because the public key parts in the files below private-keys-v1.d are included in the authenticated encryption of the private parts as additional data (openpgp-s2k3-sha1-aes-cbc and openpgp-s2k3-ocb-aes schemes) Always take care when conveying private keys. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tmz at pobox.com Tue May 31 18:17:05 2022 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 31 May 2022 12:17:05 -0400 Subject: Error importing fetching key from wkd In-Reply-To: References: <6ba2f00166ce2ce5146dfd8a087758f4f5b6e1f9.camel@googlemail.com> <8735gty0h9.fsf@wheatstone.g10code.de> <4c297d6a298758101f4cca0995a6100c46ec0157.camel@googlemail.com> Message-ID: Hello again, I wrote: > Dirk Gottschalk via Gnupg-users wrote: >> A workaround for this is to download the SRPM, remove the >> line '--disable-brainpool' and rebuild the package. > > Ahh, excellent. That's a relatively recent change. It's > available in the Fedora (and RHEL) libgcrypt-1.10 packages > which I believe are only in the freshly released Fedora 36 > and RHEL 9. For the future, you can now rebuild the libgcrypt rpm from Fedora 36 with brainpool support without having to edit the spec file manually?. You can pass `--with brainpool` to the rpmbuild command, e.g.: rpmbuild -rb --with brainbpool /path/to/libcgrypt.src.rpm Hopefully that makes life just a little easier for folks using Fedora who want or need brainpool support. ? https://src.fedoraproject.org/rpms/libgcrypt/c/6571417ff -- Todd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: