From hakuntheeril at gmail.com Mon Mar 2 11:18:58 2026 From: hakuntheeril at gmail.com (Hakun_the_eril) Date: Mon, 2 Mar 2026 11:18:58 +0100 Subject: =?UTF-8?Q?Question_about_cryptographically_keyed_GDSS_=E2=80=94_is_t?= =?UTF-8?Q?his_known=3F?= Message-ID: Hello, I am a Norwegian with an interest in privacy and open source software. I have no formal background in cryptography or signal processing, so that is mentioned. I have read an open access paper from 2023 about Gaussian-Distributed Spread-Spectrum (GDSS) for covert communication: Shakeel et al., Sensors 2023, doi:10.3390/s23084081 The paper describes a spread spectrum scheme that makes radio transmissions largely statistically indistinguishable from thermal white noise. The masking in the original scheme uses the transmitter's own thermal noise as a random source. My question is whether it would improve the signal's masking - or whether it has already been tried - to replace the random source with a cryptographically keyed source: specifically a ChaCha20 keystream derived from a BrainpoolP256r1 ECDH key exchange via GnuPG, which was passed through a Box-Muller transform to produce Gaussian-distributed masking values. My reasoning is that this would make the masking sequence cryptographically secret rather than just random - so that an adversary could not remove the masking without the session key, even if they knew the full algorithm. It would also make traffic analysis more difficult, since each session's masking sequence would be unique. The practical implementation will use GNU Radio with gr-qradiolink (which has GDSS blocks) and gr-linux-crypto (which provides Brainpool and ChaCha20), both open source. I'm not sure if this method is already known, already tried, or if there is an obvious reason why it wouldn't work that I'm overlooking. Does anyone know anything about this ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakuntheeril at gmail.com Mon Mar 2 13:31:30 2026 From: hakuntheeril at gmail.com (Hakun_the_eril) Date: Mon, 2 Mar 2026 13:31:30 +0100 Subject: Cryptographic keyed gdss Message-ID: Hello, I am a Norwegian with an interest in privacy and open source software. I have no formal background in cryptography or signal processing, so that is mentioned. I have read an open access paper from 2023 about Gaussian-Distributed Spread-Spectrum (GDSS) for covert communication: Shakeel et al., Sensors 2023, doi:10.3390/s23084081 The paper describes a spread spectrum scheme that makes radio transmissions largely statistically indistinguishable from thermal white noise. The masking in the original scheme uses the transmitter's own thermal noise as a random source. My question is whether it would improve the signal's masking - or whether it has already been tried - to replace the random source with a cryptographically keyed source: specifically a ChaCha20 keystream derived from a BrainpoolP256r1 ECDH key exchange via GnuPG, which was passed through a Box-Muller transform to produce Gaussian-distributed masking values. My reasoning is that this would make the masking sequence cryptographically secret rather than just random - so that an adversary could not remove the masking without the session key, even if they knew the full algorithm. It would also make traffic analysis more difficult, since each session's masking sequence would be unique. The practical implementation will use GNU Radio with gr-qradiolink (which has GDSS blocks) and gr-linux-crypto (which provides Brainpool and ChaCha20), both open source. I'm not sure if this method is already known, already tried, or if there is an obvious reason why it wouldn't work that I'm overlooking. Does anyone know anything about this ? Is it viable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Mon Mar 2 19:42:09 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 2 Mar 2026 13:42:09 -0500 Subject: =?UTF-8?Q?Re=3A_Question_about_cryptographically_keyed_GDSS_?= =?UTF-8?B?4oCUIGlzIHRoaXMga25vd24/?= In-Reply-To: References: Message-ID: <8b4a5e09-a605-425d-8106-d357fdd9f0fc@sixdemonbag.org> > I'm not sure if this method is already known, already tried, or if there > is an obvious reason why it wouldn't work that I'm overlooking. > > Does anyone know anything about this ? I strongly encourage people to work on what interests them, so if this interests you, go for it! Seriously! Have fun with it! Here's why it doesn't interest me: it's another attempt to turn a steganographic system into a cryptographic system. History has shown this to be generally unwise. Instead of doing everything in one pass it's generally safer to encrypt what needs encrypting, then send that over a steganographic channel. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jordan.martinez at arista.com Wed Mar 11 18:12:08 2026 From: jordan.martinez at arista.com (Jordan Martinez) Date: Wed, 11 Mar 2026 12:12:08 -0500 Subject: Bad signatures issued on macOS In-Reply-To: <87qzqbvv90.fsf@haruna.fsij.org> References: <87qzqbvv90.fsf@haruna.fsij.org> Message-ID: Please see https://github.com/jam-awake/gpg-verify-bug It provides a reproducible repo. It demonstrates 4 RSA freshly-generated keys (public and private) that are not expired, not revoked, and have varying levels of key length which reproduce this issue. On Mon, Feb 23, 2026 at 6:30?PM NIIBE Yutaka wrote: > Jordan Martinez wrote: > > Using 2.5.17, I tried verifying the same signature 100 times via a script > > and got a bad signature on each attempt. Here's how I ran such a test. > Let > > me know whether or not this is a valid test run. > > It is a valid test run. > > My debug showed that the key used for signature validation was wrong for > some reason. I was not possible to determine why wrong key was selected. > > If it is possible to share the public key in question (6E628CC4145FD2ED) > and the signature (a single signature is enough) with input, please send > me those. ** Please never send the private key. ** > > # I tried to find the key on public keyservers and WKD, but it's not > # available. > > > If it is not possible, please investigate the public key. > > * Is the subkey expired? > * Is the subkey revoked? > * Is the subkey qualified for modern use cases? > (For example, it's possible to have short key length in current > standard.) > > I think that one of those could be a reason why wrong key was selected. > There might be other possibilities. > -- > -- Blessings, Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: From deceroadiez at gmx.es Wed Mar 11 17:57:04 2026 From: deceroadiez at gmx.es (Nombre y Apellidos) Date: Wed, 11 Mar 2026 17:57:04 +0100 Subject: Collision attack against long Key Ids Message-ID: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> Hello I'm a GPG user for a while, but I don't have any technical knowledge of cryptography, only basic understanding of the subject. I mention this to try and excuse my lack of knowledge. I see a blog post about collisions in key Id's in this blog: https://soatok.blog/2026/01/07/practical-collision-attack-against-long-key-ids-in-pgp/ According to the article itself, it can lead to cases of usurpation of signed data, such as software packages. Is it really a weakness in PGP/GNUPG? Best regards and thanks in advanced -- OpenPGP fingerprint ------------------- CBA7 480A 5FBC DB67 857F 54D3 434C 945C 1278 2FD7 -------------- 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 andrewg at andrewg.com Wed Mar 11 19:36:02 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 11 Mar 2026 18:36:02 +0000 Subject: Collision attack against long Key Ids In-Reply-To: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> References: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> Message-ID: On 11/03/2026 16:57, Nombre y Apellidos via Gnupg-users wrote: > > I see a blog post about collisions in key Id's in this blog: > https://soatok.blog/2026/01/07/practical-collision-attack-against-long-key-ids-in-pgp/ As usual, Soatok wraps technical correctness in hyperbole and self-promotion. > According to the article itself, it can lead to cases of usurpation of > signed data, such as software packages. > > Is it really a weakness in PGP/GNUPG? It's a weakness *if* people assume that key IDs are unique identifiers, rather than a convenience. In older user guides, key IDs were treated as unique identifiers but this has not been recommended for a long time. You will note that Soatok references a decade-old stackexchange answer, and even that text recommends the use of fingerprints instead. In the openpgp protocol itself, the only place that key IDs are used is as a label to help a receiving implementation find the correct key for decryption (or in older messages, signature verification). The security of openpgp has never relied upon key IDs though. To exploit a birthday attack against key IDs, an attacker would have to create two colliding keys, then use one for innocent purposes, get other people to trust it, then trick them into using the second one instead, and hope they only check the key ID and not the full fingerprint. But remember that the attacker *already controls both keys*. Swapping one key under the attacker's control for a second key under the same attacker's control doesn't get the attacker any privileges they didn't already have after convincing people to trust the first key. The best that Soatok can do is suggest that the colliding keys would give an attacker plausible deniablity after the fact, in the absence of other evidence. But given that a birthday attack is known to be feasible and a preimage attack is known to be technically infeasible (for now), nobody with any sense will believe them. Plausible deniability is as bulletproof as a piece of wet tissue paper. tl;dr: don't panic. A From bwalzer at 59.ca Wed Mar 11 20:37:37 2026 From: bwalzer at 59.ca (Bruce Walzer) Date: Wed, 11 Mar 2026 14:37:37 -0500 Subject: Collision attack against long Key Ids In-Reply-To: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> References: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> Message-ID: On Wed, Mar 11, 2026 at 05:57:04PM +0100, Nombre y Apellidos via Gnupg-users wrote: > Hello > > I'm a GPG user for a while, but I don't have any technical knowledge of > cryptography, only basic understanding of the subject. I mention this to > try and excuse my lack of knowledge. > > I see a blog post about collisions in key Id's in this blog: > https://soatok.blog/2026/01/07/practical-collision-attack-against-long-key-ids-in-pgp/ The blog post was ultimately in response to a comment of mine on news.ycombinator.com. You can dig through the comments for context if you like: * https://news.ycombinator.com/item?id=46403200 The following is my reply to the blog post from there. I never received any further reply. >Sorry that my, perhaps, poor wording caused you to waste your time >producing colliding 64 bit PGP key IDs. I should have used the term >"threat model". We were discussing how long key fingerprints should >be. My point was that even though 64 bit key IDs are trivially >collidable there did not seem to be any practical attacks based on >that. So you in a sense provided support for my argument. :) So we >can skip directly to your proposed attack... >I have to admit that I don't actually understand it. First the >attacker gets some kernel devs to sign key1 of the two keys with >colliding key IDs. Why? How does that help the attacker? Then I am >guessing that the attacker signs some software with key1. Are the >signatures important here? Then the attacker signs the malicious >software with key2? Key2 isn't signed by any developers so if that >was important the attack fails. If it wasn't important then why >mention it? >Could you please provide a more detailed description of the attack? >It seems to me that the sort of attack you are describing would >require some trusted third party to trick. Like a TLS certifying >authority for example. From gniibe at fsij.org Thu Mar 12 06:00:00 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 12 Mar 2026 14:00:00 +0900 Subject: Bad signatures issued on macOS In-Reply-To: References: <87qzqbvv90.fsf@haruna.fsij.org> Message-ID: <87wlzhd4mn.fsf@haruna.fsij.org> Hello, Jordan Martinez wrote: > Please see https://github.com/jam-awake/gpg-verify-bug Thank you for providing the data point. For all of those keys, I cannot replicate the issue on my machine (Debian x86-64). Those keys just work. (It looks like four RSA keys are all 2048-bit, though.) If possible, please test with gnupg at 2.4 of Homebrew to see if you can replicate the issue. I wonder if doing "make check" when building GnuPG works well or not on your build environment. -- From csabacsaba904 at gmail.com Thu Mar 12 14:28:52 2026 From: csabacsaba904 at gmail.com (Csaba) Date: Thu, 12 Mar 2026 14:28:52 +0100 Subject: Using GPG with Yubikey 5 series Message-ID: <0a405a60-4438-4487-9792-d4777d090999@gmail.com> Hi All, I am looking for a document, manual which describes in detail how can I use my Yubikey 5 with GPG. I have GPG 2.4.7 version under Debian Linux. I also want to use it under Windows 10 with GPG4Win, if possible. Can you please suggest me documents? Best regards: Csaba From jordan.martinez at arista.com Thu Mar 12 16:44:29 2026 From: jordan.martinez at arista.com (Jordan Martinez) Date: Thu, 12 Mar 2026 10:44:29 -0500 Subject: Bad signatures issued on macOS In-Reply-To: <87wlzhd4mn.fsf@haruna.fsij.org> References: <87qzqbvv90.fsf@haruna.fsij.org> <87wlzhd4mn.fsf@haruna.fsij.org> Message-ID: Ah! Sorry about the key bit length issue. I've pushed new keys to the repo that have the correct key bit length and still reproduce this issue. I've tested the new keys with both 2.4.9 (homebrew) and 2.5.17 (locally compiled), and they still produce the bad signature error. I've also noticed that I sometimes have to run the `./debug.sh` script a few times before I can produce the error. On Thu, Mar 12, 2026 at 12:00?AM NIIBE Yutaka wrote: > Hello, > > Jordan Martinez wrote: > > Please see https://github.com/jam-awake/gpg-verify-bug > > Thank you for providing the data point. > > For all of those keys, I cannot replicate the issue on my machine > (Debian x86-64). Those keys just work. (It looks like four RSA keys > are all 2048-bit, though.) > > If possible, please test with gnupg at 2.4 of Homebrew to see if you can > replicate the issue. > > > I wonder if doing "make check" when building GnuPG works well or not on > your build environment. > -- > -- Blessings, Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg-users at city17.xyz Thu Mar 12 20:51:59 2026 From: gnupg-users at city17.xyz (jman) Date: Thu, 12 Mar 2026 20:51:59 +0100 Subject: Using GPG with Yubikey 5 series In-Reply-To: <0a405a60-4438-4487-9792-d4777d090999@gmail.com> (Csaba via Gnupg-users's message of "Thu, 12 Mar 2026 14:28:52 +0100") References: <0a405a60-4438-4487-9792-d4777d090999@gmail.com> Message-ID: <87ms0c3jxc.fsf@nyarlathotep> Csaba via Gnupg-users writes: > Hi All, > I am looking for a document, manual which describes in detail how can > I use my Yubikey 5 with GPG. > I have GPG 2.4.7 version under Debian Linux. > I also want to use it under Windows 10 with GPG4Win, if possible. This guide goes into great detail about setting up a Yubikey with GnuPG on Linux https://github.com/drduh/YubiKey-Guide From gniibe at fsij.org Fri Mar 13 07:32:32 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 13 Mar 2026 15:32:32 +0900 Subject: Bad signatures issued on macOS In-Reply-To: References: <87qzqbvv90.fsf@haruna.fsij.org> <87wlzhd4mn.fsf@haruna.fsij.org> Message-ID: <87o6ksjl33.fsf@haruna.fsij.org> Hello, Thank you very much for your test case. I managed to replicate it on my machine. Jordan Martinez wrote: > I've tested the new keys with both 2.4.9 (homebrew) and 2.5.17 (locally > compiled), and they still produce the bad signature error. I've also > noticed that I sometimes have to run the `./debug.sh` script a few times > before I can produce the error. Great. I dug into libgcrypt and found the problem (I mean, located the possible bug). Attached is the log of gpg-agent when it generated a wrong signature. Please have a look at the values of "res", "p", and "q". Here, "res" value is NEGATIVE. You can see the minus sign in the log. This is wrong. This is the cause of the trouble afterwards, because the value is assumed unsigned in SEXP handling. The reason why it becames occasionally negative is that your keys has a property of: p > q. From viewpoint of GnuPG, this is wrong. GnuPG assumes p < q. In libgcrypt, when it generates RSA key, it ensures that p < q. And libgcrypt/cipher/rsa.c:secret_core_crt function may compute wrongly (to have negative result) when p > q. So, it's the keys which have interoperability issue wrt P and Q of RSA. I don't know how we can fix (which side?), as of now. (If I were you, my workaround for GnuPG is modifying the private key files in question.) After the import, I can modify the private key files under .gnupg/private-keys-v1.d/ (swapping p and d expressions. Note that the order matters, simply p->q and q->p doesn't work.). I confirmed that the problem gone when I did. -- -------------- next part -------------- 2026-03-13 11:35:40 gpg-agent[24369] DBG: rsa_sign data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: ffffffffffffffffffffff003031300d06096086480165030402010500042038 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 25783b4efe9a0576892f4ee4fe53853b629b23cbc0521c8ce904c7bd23ad46 2026-03-13 11:35:40 gpg-agent[24369] DBG: rsa_sign n:+d0ccc5f8310c1b920fb0cfa7c4d4a9478a3710fc1412b25845687ad88402b417 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 08a93f42cf4b6b17e1249d738af5d0bc1336e35134bf5fd46eb8480b7fea2473 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 38069b38feca71fb2f8f5713028aee1ed565a073db767cb7688571e6eb02fbc5 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 21f211797e99b6bda93b3eba0afd2f02a7d062112485ef30ff2c19fe98331176 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 570222fd9af25978de2e23beeda534dc6c0c6db47e409967e3f0ef0baeb13988 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 67980d97c438cb9d3fcc8699a1807f9317663d530b4dac2449518c3025eccaff \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: ee6fd1494e16e0cf3f46aa145735b953c003c73bbcc56a2ebd86de0f3f2be766 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: e04e0da33db16b45e45738854c134ec3b206e4cd2fd860c13ffa85802df91add 2026-03-13 11:35:40 gpg-agent[24369] DBG: rsa_sign e:+010001 2026-03-13 11:35:40 gpg-agent[24369] DBG: rsa_sign d:+b0b1d98662db4029a6a595d4ffb88758471aba80d7ebca88f093ae01b4152599 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: a876b156345e3a4e86f49959c1eaabadbd04e1f1429600dea0a3ca3411176fa9 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 216c55c731b6d8261ce54c6685ec53fe3bd038ac52b83e6a67452652a7e66a71 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 347cc954eb51e15736f32fedf886b155a9f5aa479f84c819ca96e39893ec0385 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 7d3a048ed52929a4661fb3c86bf98696905ed1b64346232bc3620b7fb2245919 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: f3101712228725251a48e94ac2a726e57ba92dfcb5c5aaf71ce08bfab9bc936e \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: bfc994b1a80d5b78601e7dfaa878210cce186051eb3bc9d310691c23331b503a \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 235a5dffe3a0b54258c5b46f04b2196b1915a59523e5140d2d4b82c8cc0baa71 2026-03-13 11:35:40 gpg-agent[24369] DBG: rsa_sign p:+f9cc692674be8a88092add770579e250871510b95057fa753db79090cd72d3a6 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: ce95be6b8a632eb3f1d535c593f1804133441ad20d158848b5c2683b653c95f2 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 844e5e168922bc2ff26d3f83f2ca76d29908c7e7bea46f55c591978824c06999 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: f362203b1ebff457ff4232ba9acb7af4aa13dc5323e8df5783c3f9dd0784f483 2026-03-13 11:35:40 gpg-agent[24369] DBG: rsa_sign q:+d5fbcc013d18f2f98c4d52e8d69074803ae89e98abae93f8bb063f821c2e0ae6 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 52db15180e5d659c7abff69dad6d6c4efb041fa21e3e3159e340131ed7962afe \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 260da2db570b21f49aca3f722327bb1644ff4058cb9aa6b1ed06d9b82a369887 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 80f175d33401f2d80af831f42829de914b8f68a8f98457950b8300e63290551f 2026-03-13 11:35:40 gpg-agent[24369] DBG: rsa_sign u:+66e7cb1540eb1357d5593170105abf30eb8102bc8398ddc205ec69bcbb4bec10 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: aa7177bc6832596b2fe0d687b6c22b801d3ba59645a18cc90ccdd881ddfc7981 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 499f2a2736f7fa878f040184343d92c4a6ce1da880ec5496fb4253ad606aa43f \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 75a2181443cfe319d0cb144d6c79327896efe4b965f1c0b0cafdbc17dcebd939 2026-03-13 11:35:40 gpg-agent[24369] DBG: rsa_sign res:-b34c4b8aee09d770397b916a902cfa3064b3e3b187a8b1e1a8ddba105cb51ed9 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: c297c8d5376e20bd894f43fefae76d9a5229035c38a1ea6dadc1b51e71013d6f \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 9d64f8d7955f5188a8bb6d31f92fdb1576315d4208409bed143ac386aacc8fe4 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: e5401deb3e15c78f9fa47623f17d9810583a2878d3dd901c78cf31d1479687e1 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: b1a10af356a174aa918270bdeb0df651b5533a431e1d150d4dbd877d08a6b245 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 906790267a5eca2dffe4e3e4ba436dd9fb4b2f60402bf40b00e72de13ce49f95 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 5edad033615f31f53111abd1d00a10463cac98fd1e1f06b8a99c34aab5d46bc1 \ 2026-03-13 11:35:40 gpg-agent[24369] DBG: 6d987b72142acc446813da4996158c04918ab45ec91263e842a916ac78063346 2026-03-13 11:35:40 gpg-agent[24369] DBG: rsa_sign => Success From wk at gnupg.org Fri Mar 13 08:26:10 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Mar 2026 08:26:10 +0100 Subject: Using GPG with Yubikey 5 series In-Reply-To: <0a405a60-4438-4487-9792-d4777d090999@gmail.com> (Csaba via Gnupg-users's message of "Thu, 12 Mar 2026 14:28:52 +0100") References: <0a405a60-4438-4487-9792-d4777d090999@gmail.com> Message-ID: <87ms0cjilp.fsf@jacob.g10code.de> On Thu, 12 Mar 2026 14:28, Csaba said: > I use my Yubikey 5 with GPG. The OpenPGP application is by default enabled on a Yubikey so it works like any other OpenPGP card. > I have GPG 2.4.7 version under Debian Linux. > I also want to use it under Windows 10 with GPG4Win, if possible. I don't think that you need any documents if you are using Windows or on Linux if you install Kleopatra as a frontend. The old manuals and howtos for smartcards still apply to the command line version. However, you may want to switch the Yubikey firs to Curve25519 (first and thurd slot ed25519, second slot cv25519). You use "gpg --card-edit", then "admin", then "key-attr" to change the key algorithms. Kleopatra can do that for you, though. 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: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From jordan.martinez at arista.com Fri Mar 13 16:16:53 2026 From: jordan.martinez at arista.com (Jordan Martinez) Date: Fri, 13 Mar 2026 10:16:53 -0500 Subject: Bad signatures issued on macOS In-Reply-To: <87o6ksjl33.fsf@haruna.fsij.org> References: <87qzqbvv90.fsf@haruna.fsij.org> <87wlzhd4mn.fsf@haruna.fsij.org> <87o6ksjl33.fsf@haruna.fsij.org> Message-ID: Excellent! Thank you for helping me root cause this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deceroadiez at gmx.es Sat Mar 14 14:40:14 2026 From: deceroadiez at gmx.es (Nadie) Date: Sat, 14 Mar 2026 14:40:14 +0100 Subject: Collision attack against long Key Ids In-Reply-To: References: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> Message-ID: Thank you all. I have the feeling that attacks against PGP/GNUPG are being launched based on alleged weaknesses that are later proven not to exist. I see people recommending against using it based on these assumptions. Best regards El 11/3/26 a las 20:37, Bruce Walzer escribi?: > On Wed, Mar 11, 2026 at 05:57:04PM +0100, Nombre y Apellidos via Gnupg-users wrote: >> Hello >> >> I'm a GPG user for a while, but I don't have any technical knowledge of >> cryptography, only basic understanding of the subject. I mention this to >> try and excuse my lack of knowledge. >> >> I see a blog post about collisions in key Id's in this blog: >> https://soatok.blog/2026/01/07/practical-collision-attack-against-long-key-ids-in-pgp/ > > The blog post was ultimately in response to a comment of mine on > news.ycombinator.com. You can dig through the comments for context if > you like: > > * https://news.ycombinator.com/item?id=46403200 > > The following is my reply to the blog post from there. I never received > any further reply. > >> Sorry that my, perhaps, poor wording caused you to waste your time >> producing colliding 64 bit PGP key IDs. I should have used the term >> "threat model". We were discussing how long key fingerprints should >> be. My point was that even though 64 bit key IDs are trivially >> collidable there did not seem to be any practical attacks based on >> that. So you in a sense provided support for my argument. :) So we >> can skip directly to your proposed attack... > >> I have to admit that I don't actually understand it. First the >> attacker gets some kernel devs to sign key1 of the two keys with >> colliding key IDs. Why? How does that help the attacker? Then I am >> guessing that the attacker signs some software with key1. Are the >> signatures important here? Then the attacker signs the malicious >> software with key2? Key2 isn't signed by any developers so if that >> was important the attack fails. If it wasn't important then why >> mention it? > >> Could you please provide a more detailed description of the attack? >> It seems to me that the sort of attack you are describing would >> require some trusted third party to trick. Like a TLS certifying >> authority for example. > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sat Mar 14 16:47:50 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 14 Mar 2026 11:47:50 -0400 Subject: Collision attack against long Key Ids In-Reply-To: References: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> Message-ID: <8bead434-ba1d-4d1a-b0fb-2bee512d123d@sixdemonbag.org> > I have the feeling that attacks against PGP/GNUPG are being launched > based on alleged weaknesses that are later proven not to exist. I see > people recommending against using it based on these assumptions. I've been involved in the PGP community since 1991. You are absolutely correct in what you're describing, but it's been this way for at least thirty-five years. It will likely always be this way. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From johnz at pleasantnightmare.com Sat Mar 14 17:33:52 2026 From: johnz at pleasantnightmare.com (John Z.) Date: Sat, 14 Mar 2026 10:33:52 -0600 Subject: Collision attack against long Key Ids In-Reply-To: <8bead434-ba1d-4d1a-b0fb-2bee512d123d@sixdemonbag.org> References: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> <8bead434-ba1d-4d1a-b0fb-2bee512d123d@sixdemonbag.org> Message-ID: If its an OK, albeit simplistic question to ask - is there a reason for this? I don't track HN (the discussions style doesn't match my preference), but I am very well aware of consistent and persistent campaign against GPG, and its precisely that activism style that doesn't sit well with me. While I'm not keen to trust HN users from the get go, I've read articles by Ptacek and Moxie and what brings up alarm flags for me is precisely that style; I'd expect more clinical, paper-supported proofs from engineers with such high profiles, not "This is horrible don't use it." Oh and for context, I completely admit, without shame, that I have very little clue about the actual domain. Sure, I know what various primitives do and best practices (and have ran through some Matasano challenges), but as soon as we get into details of specific threat models, my head starts to spin. -- John Z. "All my thoughts are burning, and I like how warm the fire can be..." On Sat, Mar 14, 2026 at 11:47:50AM -0400, Robert J. Hansen via Gnupg-users wrote: > > I have the feeling that attacks against PGP/GNUPG are being launched > > based on alleged weaknesses that are later proven not to exist. I see > > people recommending against using it based on these assumptions. > > I've been involved in the PGP community since 1991. You are absolutely > correct in what you're describing, but it's been this way for at least > thirty-five years. It will likely always be this way. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Sat Mar 14 19:33:06 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 14 Mar 2026 14:33:06 -0400 Subject: Collision attack against long Key Ids In-Reply-To: References: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> <8bead434-ba1d-4d1a-b0fb-2bee512d123d@sixdemonbag.org> Message-ID: <203e6d01-523d-47cf-93eb-93b6160636e9@sixdemonbag.org> > If its an OK, albeit simplistic question to ask - is there a reason > for this? There are many reasons. My personal b?te noire is there are a lot of people who derive their social status from the unholy union of (a) being a geek and (b) making people afraid. When you can make people afraid you can lead them into looking to you to tell them what to do. Making people afraid is usually a power play of some kind and it reminds me of high school. What pushes me over the edge into being a genuinely unpleasant person is when (c) they make people afraid about something the person is unable to find out for themselves. When Chicken Little told everyone the sky was falling, at least Chicken Little had the common decency to lie about something people could disprove just by looking up. There are a lot of (a) nerdy people (b) making people scared about (c) near-future events they have to take on faith. I don't see much difference between Sam Altman telling people "in eighteen months half of your jobs will be gone!" and somebody hiding behind a pseudonym saying "ackshually the new NSA listening center in Utah is going to be able to crack PGP because...". Either way it's the same spiel. These people make me very angry. ===== Then there are the people who deal in half-truth criticisms. For instance, a lot of people say that Open/LibrePGP don't offer forward secrecy, and "all modern designs offer perfect forward secrecy." Rubbish. PGP offered perfect forward secrecy in 1991. It was one of the first systems with perfect forward secrecy. It's so old it predates the term perfect forward secrecy. What perfect forward secrecy means is "the compromise of a key does not allow an attacker to read messages sent after the compromise." Well, Open/LibrePGP uses random per-session cryptographic keys. Compromising the key used for a specific message doesn't help you compromise any other message, in the past or in the future. Open/LibrePGP is, in that sense, providing perfect forward secrecy. At the same time, it's also plainly obvious that Open/LibrePGP uses long-term keys as well (your asymmetric keypair). And there, sure, there are criticisms that can be made from a PFS standpoint. Those are valid and worth listening to. But for every person who gives a nuanced and complete understanding of PFS in Libre/OpenPGP, there are a dozen who are just repeating "no perfect forward secrecy guarantees!" without ever talking about the subject in a realistic way. ===== Then there are academics who make highly academic criticisms, that although are offered in good faith often show a lack of consideration of real-world constraints on what we can do, or a lack of understanding of what the real problems are. For instance, from RFC2440 to the final draft of RFC4880, OpenPGP specified 3DES as a permissible algorithm. 3DES was designed in the 1970s and is by modern standards unbearably ugly. It has all the aesthetic qualities of Soviet New Realism art, all the elegance of a North Korean workers' housing bloc. When the movie _Tropic Thunder_ played in theaters, when Robert Downey Jr.'s character exclaimed "Behold, God's mistake!", every cryptographer in the audience perked up thinking 3DES was about to make its Hollywood appearance. But you'll notice I never said 3DES was weak. After fifty years (!!) of cryptanalytical research nobody knows of any practical attacks on 3DES when used in the standard OpenPGP use case. It's kind of impressive that way. (If you're using it for more than a few hundred megs of data in a single message you're doing it wrong, but how many of us actually do that?) Given all this, for many years we were slow to remove 3DES from the Open/LibrePGP cipher suites. It was on the TODO. It wasn't terribly high priority. And our attitude on this caused a lot of academics to say "they still require every client support 3DES; my God, what backwards heathens." ===== Some very serious people have made very serious criticisms of OpenPGP over the years. Matthew Green at Johns Hopkins, for starters, was really not a fan. See, for instance, this essay: https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ His criticisms in 2014 were pretty sharp and for the most part fair. Libre/OpenPGP took notice and have since taken steps to mitigate a lot of those concerns. (He's probably still not a fan, however.) But for every solid, well-thought-out, and occasionally devastating critique on Open/LibrePGP there are easily a dozen ones that vary from disingenuous to confused to genuinely dishonest and manipulative. Anyway. Hope this helps. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4583 bytes Desc: S/MIME Cryptographic Signature URL: From johnz at pleasantnightmare.com Sun Mar 15 17:56:06 2026 From: johnz at pleasantnightmare.com (John Z.) Date: Sun, 15 Mar 2026 10:56:06 -0600 Subject: Collision attack against long Key Ids In-Reply-To: <203e6d01-523d-47cf-93eb-93b6160636e9@sixdemonbag.org> References: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> <8bead434-ba1d-4d1a-b0fb-2bee512d123d@sixdemonbag.org> <203e6d01-523d-47cf-93eb-93b6160636e9@sixdemonbag.org> Message-ID: It helps a lot! Thank you for the time and effort put to write it all up - its not far away from what I presumed might be happening, but of course with far more detailed explanation. I find it even more interesting how you precisely analyzed what I just disliked about that 'HN style'. I mean, there were heated online opinion exchanges ever since there was internet, and they persist, but I don't recall so much 'activism' combined with these opinion exchanges, except only in past decade and a half. It concerns me to think what's going to happen and how will things evolve once all the people who were involved with GNU (or Linux) from beginning, or are the 'second generation' (like myself) - are gone, and there's no one left who has curiosity, or can even understand, let alone write and maintain such high-complexity code. Especially when you add LLM into the mix. I wish I had something more substantial or profound to add. -- John Z. "All my thoughts are burning, and I like how warm the fire can be..." On Sat, Mar 14, 2026 at 02:33:06PM -0400, Robert J. Hansen via Gnupg-users wrote: > > If its an OK, albeit simplistic question to ask - is there a reason > > for this? > > There are many reasons. > > My personal b?te noire is there are a lot of people who derive their social > status from the unholy union of (a) being a geek and (b) making people > afraid. When you can make people afraid you can lead them into looking to > you to tell them what to do. Making people afraid is usually a power play of > some kind and it reminds me of high school. What pushes me over the edge > into being a genuinely unpleasant person is when (c) they make people afraid > about something the person is unable to find out for themselves. When > Chicken Little told everyone the sky was falling, at least Chicken Little > had the common decency to lie about something people could disprove just by > looking up. > > There are a lot of (a) nerdy people (b) making people scared about (c) > near-future events they have to take on faith. > > I don't see much difference between Sam Altman telling people "in eighteen > months half of your jobs will be gone!" and somebody hiding behind a > pseudonym saying "ackshually the new NSA listening center in Utah is going > to be able to crack PGP because...". Either way it's the same spiel. These > people make me very angry. > > ===== > > Then there are the people who deal in half-truth criticisms. For instance, a > lot of people say that Open/LibrePGP don't offer forward secrecy, and "all > modern designs offer perfect forward secrecy." > > Rubbish. PGP offered perfect forward secrecy in 1991. It was one of the > first systems with perfect forward secrecy. It's so old it predates the term > perfect forward secrecy. > > What perfect forward secrecy means is "the compromise of a key does not > allow an attacker to read messages sent after the compromise." Well, > Open/LibrePGP uses random per-session cryptographic keys. Compromising the > key used for a specific message doesn't help you compromise any other > message, in the past or in the future. Open/LibrePGP is, in that sense, > providing perfect forward secrecy. > > At the same time, it's also plainly obvious that Open/LibrePGP uses > long-term keys as well (your asymmetric keypair). And there, sure, there are > criticisms that can be made from a PFS standpoint. Those are valid and worth > listening to. > > But for every person who gives a nuanced and complete understanding of PFS > in Libre/OpenPGP, there are a dozen who are just repeating "no perfect > forward secrecy guarantees!" without ever talking about the subject in a > realistic way. > > ===== > > Then there are academics who make highly academic criticisms, that although > are offered in good faith often show a lack of consideration of real-world > constraints on what we can do, or a lack of understanding of what the real > problems are. > > For instance, from RFC2440 to the final draft of RFC4880, OpenPGP specified > 3DES as a permissible algorithm. 3DES was designed in the 1970s and is by > modern standards unbearably ugly. It has all the aesthetic qualities of > Soviet New Realism art, all the elegance of a North Korean workers' housing > bloc. When the movie _Tropic Thunder_ played in theaters, when Robert Downey > Jr.'s character exclaimed "Behold, God's mistake!", every cryptographer in > the audience perked up thinking 3DES was about to make its Hollywood > appearance. > > But you'll notice I never said 3DES was weak. After fifty years (!!) of > cryptanalytical research nobody knows of any practical attacks on 3DES when > used in the standard OpenPGP use case. It's kind of impressive that way. (If > you're using it for more than a few hundred megs of data in a single message > you're doing it wrong, but how many of us actually do that?) > > Given all this, for many years we were slow to remove 3DES from the > Open/LibrePGP cipher suites. It was on the TODO. It wasn't terribly high > priority. And our attitude on this caused a lot of academics to say "they > still require every client support 3DES; my God, what backwards heathens." > > ===== > > Some very serious people have made very serious criticisms of OpenPGP over > the years. Matthew Green at Johns Hopkins, for starters, was really not a > fan. See, for instance, this essay: > > https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ > > His criticisms in 2014 were pretty sharp and for the most part fair. > Libre/OpenPGP took notice and have since taken steps to mitigate a lot of > those concerns. (He's probably still not a fan, however.) > > But for every solid, well-thought-out, and occasionally devastating critique > on Open/LibrePGP there are easily a dozen ones that vary from disingenuous > to confused to genuinely dishonest and manipulative. > > Anyway. Hope this helps. :) > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users From roam at ringlet.net Sun Mar 15 20:24:14 2026 From: roam at ringlet.net (Peter Pentchev) Date: Sun, 15 Mar 2026 21:24:14 +0200 Subject: Collision attack against long Key Ids In-Reply-To: References: <1f0600a01a74b3608bbb8485a289504b1dc6819d.camel@gmx.es> <8bead434-ba1d-4d1a-b0fb-2bee512d123d@sixdemonbag.org> <203e6d01-523d-47cf-93eb-93b6160636e9@sixdemonbag.org> Message-ID: On Sun, Mar 15, 2026 at 10:56:06AM -0600, John Z. wrote: > It helps a lot! Thank you for the time and effort put to write it all > up - its not far away from what I presumed might be happening, but of > course with far more detailed explanation. > I find it even more interesting how you precisely analyzed what I just > disliked about that 'HN style'. > > I mean, there were heated online opinion exchanges ever since there was > internet, and they persist, but I don't recall so much 'activism' combined > with these opinion exchanges, except only in past decade and a half. I think you may have missed some discussions on Slashdot... :) > It concerns me to think what's going to happen and how will things evolve > once all the people who were involved with GNU (or Linux) from beginning, > or are the 'second generation' (like myself) - are gone, and there's no > one left who has curiosity, or can even understand, let alone write and > maintain such high-complexity code. > Especially when you add LLM into the mix. I don't know, I can think offhand of more than a few packagers and developers for various Linux distributions who are all under the age of 25. I don't think the sky is falling just yet. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org peter at morpheusly.com PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gniibe at fsij.org Mon Mar 16 06:22:40 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 16 Mar 2026 14:22:40 +0900 Subject: P and Q in RSA (was: Bad signatures issued on macOS) In-Reply-To: References: <87qzqbvv90.fsf@haruna.fsij.org> <87wlzhd4mn.fsf@haruna.fsij.org> <87o6ksjl33.fsf@haruna.fsij.org> Message-ID: <87bjgoic0v.fsf@haruna.fsij.org> Hello, I created a ticket for this interoperability problem: https://dev.gnupg.org/T8171 And I put my proposal patch of GnuPG. (It's not only P and Q, but the value of U should be also updated.) I'd like to express my gratitude to you and John Soo. Without the report and help, we were not able to know the problem. Also, let me address a correction in my statements. To John Soo, I wrote on February 13th: > According to the other part of the log, it is your RSA public raw > material of your primary key 1510C86404E2F6ECA02871DB6E628CC4145FD2ED. > > The problem here is that: the subkey > 1B7E30E28F43D2F9469CF62AB67EB1E57374A315 was retrieved correctly, but > the key used for verification was > 1510C86404E2F6ECA02871DB6E628CC4145FD2ED for some reason. This analysis of mine was wrong. I had thought that it was verification of binding signature, but it must be verification of backsig actually. -- From dev at nixonnet.org Thu Mar 19 05:41:47 2026 From: dev at nixonnet.org (Bow) Date: Wed, 18 Mar 2026 21:41:47 -0700 Subject: GPG with PKCS#15 card References: Message-ID: I would like to clarify to what extent GPG 2.4.9 (not GPGSM) supports PKCS#15 cards. (In case it matters: I am working with a J3R180, not a Yubikey.) The SCDaemon section of the manual [1] says that PKCS#15 is used by GPGSM, from which I infer GPG can not use it - which makes sense to me as it is my understanding that PKCS#15 v1.1 stores X.509/etc certificates - but GPG can use PIV cards [2] which I believe to also store certificates. (And I understand this [3] user-list answer to mean GPG supports PKCS#15 cards.) So I am confused. Can I use a PKCS#15 v1.1 with GPG similarly to an OpenPGP card? (Not including card management, just signing and encryption.) If so, how can I generate key-stubs/associate on-card keys with OpenPGP subkeys? Would checkkeys work? Thank you for your time, Bow [1] https://www.gnupg.org/%28en%29/documentation/manuals/gnupg24/scdaemon.1.html [2] https://www.gnupg.org/documentation/manuals/gnupg/gpg_002dcard.html [3] https://lists.gnupg.org/pipermail/gnupg-users/2026-January/068092.html -------------- 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 Thu Mar 19 10:25:12 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Mar 2026 10:25:12 +0100 Subject: GPG with PKCS#15 card In-Reply-To: (Bow via Gnupg-users's message of "Wed, 18 Mar 2026 21:41:47 -0700") References: Message-ID: <87eclggohz.fsf@jacob.g10code.de> Hi! On Wed, 18 Mar 2026 21:41, Bow said: > I would like to clarify to what extent GPG 2.4.9 (not GPGSM) supports > PKCS#15 cards. Please first check whether the card is support. Just run "gpg-card" and it should show all availabale information. If that specific card works for you, you need to generate key on the crad (unless the card already comes with keys). This can be done with the the generate command of gpg-card: gpg/card> help generate GENERATE [--force] [--algo=ALGO{+ALGO2}] KEYREF Create a new key on a card. Use --force to overwrite an existing key. Use "help" for ALGO to get a list of known algorithms. For OpenPGP cards several algos may be given. Note that the OpenPGP key generation is done interactively unless a single ALGO or KEYREF are given. [Supported by: OpenPGP, PIV] The problem for an arbitrary card is to figure out the KEYREF (something like "P15.45"). And of course the card must use a key generation which is implemented. "gpg-card --debupg ipc" might give you more details. My suggestion is to use the tool coming with that specific card to generate the key(s). As soon as a card has keys, you should be able to generate *PGP keys: $ gpg --full-gen-key Please select what kind of key you want: (1) RSA and RSA (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECC (sign and encrypt) *default* (10) ECC (sign only) (11) ECC (set your own capabilities) (13) Existing key (14) Existing key from card (16) ECC and Kyber Your selection? 14 Serial number of the card: D276000124010200FFFE50FF6E060000 Available keys: (1) 1D538E0FA8DFC2ED7F0382ED25ADE1EF23D12C5C OPENPGP.1 ed25519 (cert,sign*) (2) EE5A80CF605C7B8A2402E9CB41B553F2E5069B33 OPENPGP.2 cv25519 (encr*) (3) F5E5774B2E70F188A078C715B2D8CE7FCC1E6550 OPENPGP.3 ed25519 (sign,auth*) Your selection? > store certificates. (And I understand this [3] user-list answer to > mean GPG supports PKCS#15 cards.) So I am confused. PKCS#15 is a specification for a file system on a card. This is supported but many cards use vendor specific commands (APDUs) to generate and use keys. We actually have support for a lot of PKCS#15 cards but your Java(?) card might not supported; YMMV. Put log-file /some/log/file debug card into ~/.gnupg/scdaemon.log to see many details of the P15 file system. You better use the stable version 2.5.18 because we have not backported support for newer cards to the 2.4 branch; for Debian based systems checkout https://repos.gnupg.org . Shalom-Salam, 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: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From jordan.martinez at arista.com Thu Mar 19 23:38:42 2026 From: jordan.martinez at arista.com (Jordan Martinez) Date: Thu, 19 Mar 2026 17:38:42 -0500 Subject: P and Q in RSA (was: Bad signatures issued on macOS) In-Reply-To: <87bjgoic0v.fsf@haruna.fsij.org> References: <87qzqbvv90.fsf@haruna.fsij.org> <87wlzhd4mn.fsf@haruna.fsij.org> <87o6ksjl33.fsf@haruna.fsij.org> <87bjgoic0v.fsf@haruna.fsij.org> Message-ID: Glad to be of help! FWIW, I'm trying to fix things on the ProtonMail/go-crypto side here by swapping the P and Q primes and then recomputing precomputed values: https://github.com/ProtonMail/go-crypto/pull/305. This seems in-line with what you originally proposed. Also, John has made them aware of your upcoming libgcrypt patch in the corresponding issue on that repo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at sethm.id.au Sun Mar 22 04:29:41 2026 From: dev at sethm.id.au (Seth McDonald) Date: Sun, 22 Mar 2026 13:29:41 +1000 Subject: Refreshing keyring via WKD Message-ID: <019d1378-4c10-7e60-aa5d-09ef44fd0d97@sethm.id.au> Hi all, To my understanding, GnuPG has been encouraging the use of WKD over keyservers for the distribution of public keys. I personally use WKD as the first method for attaining others' public keys. (I'm yet to set it up for myself, but I'm planning on it.) Though when it comes to updating my keyring via --refresh-keys, GnuPG seems to only be able to use keyservers to obtain the up-to-date keys. As such, I wish to ask if it is actually possible to refresh the keyring via WKD (other than manually one-by-one). And if not, if such a feature could be considered for future releases. To be clear, what I'm thinking of is: for each public key with a UID containing an email address, querying the WKD for that email address and updating the keyring with the received key, if any. Perhaps only considering the primary UID, since querying for multiple emails per key may be a bit much. I'm also not too familiar with how WKD works, so I apologise if my request demonstrates ignorance on the topic. In case it's relevant, here's some numbers about my environment. Debian GNU/Linux 13 (trixie) | gpg --version | apt show ----------+---------------+-------------------- gpg | 2.4.7 | 2.4.7-21+deb13u1+b2 libgcrypt | 1.11.0 | 1.11.0-7 Take care, Seth McDonald. -- E9D1 26A5 F0D4 9DF7 792B C2E2 B4BF 4530 D39B 2D51 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: not available URL: From wk at gnupg.org Sun Mar 22 18:31:30 2026 From: wk at gnupg.org (Werner Koch) Date: Sun, 22 Mar 2026 18:31:30 +0100 Subject: Refreshing keyring via WKD In-Reply-To: <019d1378-4c10-7e60-aa5d-09ef44fd0d97@sethm.id.au> (Seth McDonald via Gnupg-users's message of "Sun, 22 Mar 2026 13:29:41 +1000") References: <019d1378-4c10-7e60-aa5d-09ef44fd0d97@sethm.id.au> Message-ID: <87tsu7db4d.fsf@jacob.g10code.de> On Sun, 22 Mar 2026 13:29, Seth McDonald said: > To my understanding, GnuPG has been encouraging the use of WKD over > keyservers for the distribution of public keys. I personally use WKD as Right, except for organizational-wide LDAP keyservers. > Though when it comes to updating my keyring via --refresh-keys, GnuPG > seems to only be able to use keyservers to obtain the up-to-date keys. Yes, this is an open task. I think we have several tickets for that. For example https://dev.gnupg.org/T698 . Fortunately we know the origin of a key or user-id and are able to look it up using the original source. I would also like to see this feature. It is getting more important. 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: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From kloecker at kde.org Sun Mar 22 20:21:18 2026 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Sun, 22 Mar 2026 20:21:18 +0100 Subject: Refreshing keyring via WKD In-Reply-To: <87tsu7db4d.fsf@jacob.g10code.de> References: <019d1378-4c10-7e60-aa5d-09ef44fd0d97@sethm.id.au> <87tsu7db4d.fsf@jacob.g10code.de> Message-ID: <5034977.OV4Wx5bFTl@daneel> On Sonntag, 22. M?rz 2026 18:31:30 Mitteleurop?ische Normalzeit Werner Koch via Gnupg-users wrote: > On Sun, 22 Mar 2026 13:29, Seth McDonald said: > > To my understanding, GnuPG has been encouraging the use of WKD over > > keyservers for the distribution of public keys. I personally use WKD as > > Right, except for organizational-wide LDAP keyservers. > > > Though when it comes to updating my keyring via --refresh-keys, GnuPG > > seems to only be able to use keyservers to obtain the up-to-date keys. > > Yes, this is an open task. Kleopatra already can update multiple keys in one go. Simply select the OpenPGP certificates you want to update and then select "Update Certificates". Kleopatra queries WKD and the configured OpenPGP keyserver. If you just want to update via WKD then temporarily remove the configured keyserver. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 265 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Mon Mar 23 09:03:10 2026 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Mon, 23 Mar 2026 09:03:10 +0100 Subject: Refreshing keyring via WKD In-Reply-To: <5034977.OV4Wx5bFTl@daneel> References: <019d1378-4c10-7e60-aa5d-09ef44fd0d97@sethm.id.au> <87tsu7db4d.fsf@jacob.g10code.de> <5034977.OV4Wx5bFTl@daneel> Message-ID: <4869799.vXUDI8C0e8@daneel> On Sonntag, 22. M?rz 2026 20:21:18 Mitteleurop?ische Normalzeit Ingo Kl?cker wrote: > On Sonntag, 22. M?rz 2026 18:31:30 Mitteleurop?ische Normalzeit Werner Koch > > via Gnupg-users wrote: > > On Sun, 22 Mar 2026 13:29, Seth McDonald said: > > > To my understanding, GnuPG has been encouraging the use of WKD over > > > keyservers for the distribution of public keys. I personally use WKD as > > > > Right, except for organizational-wide LDAP keyservers. > > > > > Though when it comes to updating my keyring via --refresh-keys, GnuPG > > > seems to only be able to use keyservers to obtain the up-to-date keys. > > > > Yes, this is an open task. > > Kleopatra already can update multiple keys in one go. Simply select the > OpenPGP certificates you want to update and then select "Update > Certificates". Kleopatra queries WKD and the configured OpenPGP keyserver. > If you just want to update via WKD then temporarily remove the configured > keyserver. I forgot that one has to enable the option "Query certificate directories of providers for all user IDs" if all keys should be updated via WKD. Otherwise, only keys that were originally retrieved via WKD are updated via WKD. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 265 bytes Desc: This is a digitally signed message part. URL: From gnupg.ladder289 at passmail.net Tue Mar 24 20:19:58 2026 From: gnupg.ladder289 at passmail.net (gnupg.ladder289 at passmail.net) Date: Tue, 24 Mar 2026 19:19:58 +0000 Subject: Desig-revoke In-Reply-To: References: Message-ID: <177438000488.7.13031933245897121289.1248840126@passmail.net> Hello! I believe I have encountered a bug. I have created a new set of keys (not-default setup: main key to certify, subkeys to sign and decrypt, added another key to decrypt) and I have also added another key as a revoker. All was well, until - just for test - I tried to generate and import the revocation certificate from the designated revoker. Generation was fine, but on import gnupg was complaining about bad signature of the revoker key, and refused to actually revoke the key. The newly generated key could revoke itself. The problem was only about the desginated revoker. Therefore I generated a bunch of test-keys, with default settings. The results were the same. Designated revoker *can* generate the revocation certifiacte, but gnupg fails to import the revoked key compaining about bad signature. Can I get any assistance with it? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 343 bytes Desc: OpenPGP digital signature URL: From ablum at gnupg.com Wed Mar 25 11:50:07 2026 From: ablum at gnupg.com (Alexander Blum) Date: Wed, 25 Mar 2026 11:50:07 +0100 Subject: Desig-revoke In-Reply-To: <177438000488.7.13031933245897121289.1248840126@passmail.net> References: <177438000488.7.13031933245897121289.1248840126@passmail.net> Message-ID: Hello, > Designated revoker *can* generate the revocation certifiacte, but > gnupg fails to import the revoked key compaining about bad signature. Thanks for the report. I could replicate the bad signature line and created a ticket for this issue: https://dev.gnupg.org/T8189 In my test the revokation did work though (see the last part of the output in the ticket), so I wonder, why it's different on your side. Are you sure, that the revokation did not work? If yes, could you provide the exact steps you performed, preferably including the output? Which gnupg version did you use? Best, Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From gnupg.ladder289 at passmail.net Wed Mar 25 14:28:12 2026 From: gnupg.ladder289 at passmail.net (gnupg.ladder289 at passmail.net) Date: Wed, 25 Mar 2026 13:28:12 +0000 Subject: Desig-revoke In-Reply-To: References: <177438000488.7.13031933245897121289.1248840126@passmail.net> Message-ID: <177444529660.7.2010960896630978689.1250232362@passmail.net> Okay, so: 1) With `gpg --expert --full-gen-key` I generate only the main key, 'revoker' only able to certify other keys. 2) Then I add subkeys with `gpg --expert --edit-key revoker`: - ECC subkey to sign - ECC subkey to encrypt - Kyber-1024 subkey to encrypt 3) The same way I create a tbr (to be revoked) key. 4) With `addrevoker` in `gpg --expert --edit-key tbr` I add 'revoker' as a revoker key In this situation desginated revocation doesn't work. While using only ECC, as you have described, revocation works (although gnupg still complains about bad signature). I am using freshly-compiled gnupg 2.5.18. So I guess it has to do with these Kyber keys From ablum at gnupg.com Fri Mar 27 13:27:18 2026 From: ablum at gnupg.com (Alexander Blum) Date: Fri, 27 Mar 2026 13:27:18 +0100 Subject: Desig-revoke In-Reply-To: <177444529660.7.2010960896630978689.1250232362@passmail.net> References: <177438000488.7.13031933245897121289.1248840126@passmail.net> <177444529660.7.2010960896630978689.1250232362@passmail.net> Message-ID: > 1) With `gpg --expert --full-gen-key` I generate only the main key, 'revoker' only able to certify other keys. Thanks for the instructions. Looks like certify-only primary keys are the problem here. I created this ticket for it: https://dev.gnupg.org/T8196 Best, Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon Mar 30 05:28:05 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 29 Mar 2026 23:28:05 -0400 Subject: What do LLMs mean for GnuPG? Message-ID: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> I am not a GnuPG developer. I am, at best, some sort of semiofficial GnuPG mascot. Please don't mistake this for anything official. :) I've heard a lot of people talking about the advent of LLM-assisted coding. There seem to be as many ways to approach this as there are individual developers. I've read a great number of whitepapers on this (and have talked with some genuine Ph.Ds in artificial intelligence: thanks, Dr. Ezra Sidran of Riverview AI) and recently had cause to put them to the test for a piece of code that needed to be, if not bulletproof, hardened. From this, we can hopefully learn some lessons about LLMs in security-sensitive code. Werner and the rest of g10 Code can (and will!) do what they want, of course. I'm talking about my experiences only and what, based on those experiences, I imagine g10 Code would consider reasonable. If you have strong thoughts on the matter, here is the thread to comment on. 1. SO WHERE DO WE BEGIN? I needed to change my UNIX password. As I've done for the last quarter-century (yes, I'm old), I broke out Ted Ts'o's excellent pwgen tool. One invocation of 'pwgen -s 8 1' later and I had a new password. Bam, eight random characters, I'm done. Then I got to thinking, you know, who's maintaining this package nowadays? When was the last time someone gave it an overhaul? How sturdy is it? I wasn't able to quickly find the maintainer, nor a definitive code repo. Ted maintains a GitHub repo at https://github.com/tytso/pwgen but nothing's been touched in the last seven years, minimum. pwgen is a good tool. It also deserves new eyes and maybe an overhaul. So I decided to use it as an excuse to teach myself Rust. 2. RUST? Rust is emerging as an excellent general-purpose language for systems programming. 3. BUT I THOUGHT ... If you're thinking "but Sequoia forked from GnuPG over Rust!", well, no, it didn't. The division happened because of interpersonal reasons, not some simplistic "this side only loves Rust and that side only loves C." I am absolutely convinced that Werner enthusiastically supports well-working FOSS software written in any language, even C++. Let's put language choice aside and go forward to rpass. :) 4. RPASS rpass (https://github.com/rjhansen/rpass) is a reimplementation of pwgen in Rust. There are a couple of minor differences: namely, pwgen's -s flag is now mandatory and strong guarantees are made about per-glyph entropy, what random number generator is used, and so on. 5. ORIGINAL IMPLEMENTATION I firmly believe that as soon as code is usable for its chosen purpose and has no obvious defects, stamp it 1.0 and get it out there for the world to see. Every coder I know is afraid to do this because we all know the 1.0 codebase is utter crap. My advice to all of us: get over it. Nobody cares if your 1.0 is crap. It's expected. Release and start getting better quickly. I started by imagining a clean architecture: construct a configuration object from the command-line parameters, ensure it was internally self-consistent (no contradictory commands, etc.), and then use the configuration object to create a set of closures: * one set of closures to securely generate high-entropy passwords, * one set of closures to print them. Once these closures are in place, the actual heart of the code becomes ridiculously simple. It's literally, fn main() { let config = get_config_object(); let (mut generate, mut finalize) = make_genfin_closures(&config); let write = make_writer(&config); for _ in 0..config.password_count() { write(generate()); } finalize(); } This isn't ... quite ... ideal. Since the generate and finalize closures share sensitive state (the buffer of random data) the two closures have to share access via Rust's equivalent of a pointer. It has a bad code smell. The closures themselves also became large and kind of ugly. I didn't like it. But it worked! So, 1.0, here we go! 6. BRINGING IN CLAUDE 6a. EPISODE IV: CLAUDE.AI The first thing I told Claude.ai was, "Reimplement pwgen in Rust, paying close attention to modernization issues." Claude disappointed me... a lot. Although in many ways it faithfully performed the task, _how_ it performed the task was utterly incompetent. Instead of choosing a modern cryptographically secure pseudorandom number generator from one of the well-known packages on crates.io or the Rust standard library, it insisted on rolling its own *non-cryptographically secure* linear feedback shift register. Not only did it roll its own LFSR, it rolled its own LFSR that already existed in the Rust standard library! Likewise, when it came to pwgen's SHA-1 hash feature, Claude didn't notice that SHA-1 has been deprecated for pretty much every purpose and probably shouldn't be used in any new security-aware code as of 2026. Nope, it blithely went ahead and implemented the feature, and even rolled its own SHA-1 implementation instead of using Rust's built-in SHA-1. When determining the column width ('pwgen -C' gives columns of passwords), it insisted on checking for the existence of a COLUMNS environment variable and defaulting to 80 if it didn't exist. This is, to say the least, not the recommended way of discovering terminal width. rpass has a minimalist core that has a little bit of architectural beauty to it. It's kind of like the Picasso drawing of a penguin: it's fun because it's so small. https://www.pablopicasso.net/drawings/ -- look for "Penguin". I would compare the Claude version to a Jackson Pollack, except that Jackson Pollack created art and Claude created a mess. If I were teaching an undergraduate secure coding course and someone turned this in, they would get a very bad grade. 6b. EPISODE V: THE CLAUDE STRIKES BACK So I burned that one to the ground and felt pretty good about myself. Clearly, vibe coding was every bit as awful as I'd feared. But it deserved a second chance, so ... "Claude, look at the codebase at this git repo and criticize it on security grounds. Pay particular attention to issues of memory safety and whether sensitive data is being wiped." Ow. Ow. Ow. Ow. Ow. Claude found bugs -- and not a small number of them. Claude found subtle ones, like "you're not zeroizing this anonymous temporary variable you're implicitly creating", and it also found embarrassing ones, like how my finalizer wasn't actually firing. Yep. How in the world can this code NOT manage to hit the finalizer? fn main() { let config = get_config_object(); let (mut generate, mut finalize) = make_genfin_closures(&config); let write = make_writer(&config); for _ in 0..config.password_count() { write(generate()); } finalize(); } Answer: if the code panics between "let write..." and "finalize()", the app will immediately do a controlled crash. The finalizer won't get hit. If I were to wrap the finalizer in an RAII block I could get that guarantee, but it's not in an RAII block, and... Etc. Now, I don't _think_ there's a code path in rpass by which a panic can occur. But that's not the same thing as saying I've formally proven there is no such code path. Yow. I have to admit, Claude pointed out a couple of holes in my game. Part of this is undoubtedly due to my being new to Rust programming, but the bottom line remains: if I can make bugs like this, odds are good you can, too -- and Claude can potentially be a useful tool in helping to find them before they bite your users. 6c. EPISODE VI: THE RETURN OF THE HACKER So, armed with this critique I went back to the code and did some significant re-work on it. The ultimate architecture changed somewhat, so that the fragile generator/finalizer closures with their bad code smell and difficult-to-anticipate panic behavior were done away with in favor of a lightweight RAII object, but on balance my original architecture endured: fn main() { let mut pw = PasswordGenerator::new(); let mut printer = make_printer(); for _ in 0..get_count() { printer(pw.generate()); } } The basic architecture is intact, there are significantly fewer points by which sensitive memory can be returned to the system in a non-zeroed state, and on balance the code is a lot stronger. 7. SO WHAT'S THE UPSHOT FOR GNUPG? Well, based on my experience with Claude so far, here's what I suspect about the future of GnuPG development: * At some point LLMs will be used as part of GnuPG development. Used wisely, they offer real gains. * I am very much opposed to letting LLMs write even one line of code in GnuPG. * If you have any strong feelings about whether GnuPG development should embrace LLMs, and if so then how it should embrace them, the time to speak up is now. Sooner or later, and I'm betting on sooner, GnuPG will need to decide its LLM strategy, and it would be best if we all had a discussion about them before the decision needed to be made. Feel free to ask questions about my experiences with Claude. I'm happy to field them. Just remember, I'm not a GnuPG developer. I'm just a guy. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Mon Mar 30 06:36:56 2026 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 29 Mar 2026 23:36:56 -0500 Subject: What do LLMs mean for GnuPG? In-Reply-To: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> Message-ID: On 3/29/26 22:28, Robert J. Hansen via Gnupg-users wrote: > I am not a GnuPG developer. I am, at best, some sort of semiofficial > GnuPG mascot. Please don't mistake this for anything official. :) > > I've heard a lot of people talking about the advent of LLM-assisted > coding. There seem to be as many ways to approach this as there are > individual developers. I've read a great number of whitepapers on this > (and have talked with some genuine Ph.Ds in artificial intelligence: > thanks, Dr. Ezra Sidran of Riverview AI) and recently had cause to put > them to the test for a piece of code that needed to be, if not > bulletproof, hardened. From this, we can hopefully learn some lessons > about LLMs in security-sensitive code. > > Werner and the rest of g10 Code can (and will!) do what they want, of > course. I'm talking about my experiences only and what, based on those > experiences, I imagine g10 Code would consider reasonable. If you have > strong thoughts on the matter, here is the thread to comment on. > > 1. SO WHERE DO WE BEGIN? > > I needed to change my UNIX password. > > As I've done for the last quarter-century (yes, I'm old), I broke out > Ted Ts'o's excellent pwgen tool. One invocation of 'pwgen -s 8 1' > later and I had a new password. Bam, eight random characters, I'm done. > > [...] > > pwgen is a good tool. It also deserves new eyes and maybe an overhaul. > So I decided to use it as an excuse to teach myself Rust. > > [...] > > [...] there are significantly fewer points by which sensitive memory > can be returned to the system in a non-zeroed state, [...] This is a red herring on all modern systems, given the overall architecture of this tool.? The entire process virtual space will be wiped when the process exits, and the kernel is responsible for zeroing *every* physical page before reassigning it to another virtual space. The generator state may be gone, but the generated passwords are still sitting wherever you put them; your terminal emulator and window system are very unlikely to take the same precautions as your password generator, for example.? The generator would never be further used anyway, but the output is the actual valuable data. Put simply, for a "one-shot" tool that uses only a short-lived process, there is no need to be concerned about this issue.? There *are* good reasons for these concerns in long-running processes or modules linked into larger programs, but not for a tool this simple. > > 7. SO WHAT'S THE UPSHOT FOR GNUPG? > > Well, based on my experience with Claude so far, here's what I suspect > about the future of GnuPG development: > > * At some point LLMs will be used as part of GnuPG development. Used > wisely, they offer real gains. > > * I am very much opposed to letting LLMs write even one line of code > in GnuPG. I very strongly agree on this point.? This policy also avoids the potential copyright quagmires.? (Which are extra "fun" because different jurisdictions have different rules...) > * If you have any strong feelings about whether GnuPG development > should embrace LLMs, and if so then how it should embrace them, the > time to speak up is now. Sooner or later, and I'm betting on sooner, > GnuPG will need to decide its LLM strategy, and it would be best if we > all had a discussion about them before the decision needed to be made. You can use them to navigate, you can use them to analyze, but absolutely do not put code from an LLM into anything important! I do not have the citation close at hand but I remember seeing studies done that found that developers believed that using LLMs made them about 25% faster, but the actual data showed that LLM usage made them about 19% slower.? (Numbers retrieved from personal human memory, may not be exactly accurate.) Alarmingly, attempts to replicate the study in later years found that LLM-assisted programming appears to be *addictive*:? the researchers could not find enough developers willing to program without LLM assistance to have solid data, even when they offered to pay $50 an hour. This last point suggests to me that perhaps a strict prohibition on the use of LLMs to develop for GnuPG might be appropriate. -- Jacob From rjh at sixdemonbag.org Mon Mar 30 09:29:23 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 30 Mar 2026 03:29:23 -0400 Subject: What do LLMs mean for GnuPG? In-Reply-To: References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> Message-ID: > This is a red herring on all modern systems, given the overall > architecture of this tool. Yes and no. The general rule is to take responsibility for zeroizing sensitive memory. Defense in depth involves, you know, *depth*. I agree with your comments; I disagree with your conclusion. > Put simply, for a "one-shot" tool that uses only a short-lived process, > there is no need to be concerned about this issue. Save that it's a remarkably good habit to get into. :) > I do not have the citation close at hand but I remember seeing studies > done that found that developers believed that using LLMs made them about > 25% faster, but the actual data showed that LLM usage made them about > 19% slower.? (Numbers retrieved from personal human memory, may not be > exactly accurate.) Was it the METR survey? https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ > Alarmingly, attempts to replicate the study in later years found that > LLM-assisted programming appears to be *addictive*:? the researchers > could not find enough developers willing to program without LLM > assistance to have solid data, even when they offered to pay $50 an hour. I have opinions on that which I normally don't publicize, as I have very little backing it up except personal experience and a sickening feeling in the pit of my stomach. Subjective experience and subjective suspicions are not the same as reasoned discussion. I'll see if I can't write it up in a sensible way. > This last point suggests to me that perhaps a strict prohibition on the > use of LLMs to develop for GnuPG might be appropriate. I'm thinking it might be a good addition to the developer agreement, yes. Concur. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Mar 30 10:39:18 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 30 Mar 2026 04:39:18 -0400 Subject: What do LLMs mean for GnuPG? In-Reply-To: References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> Message-ID: > Alarmingly, attempts to replicate the study in later years found that > LLM-assisted programming appears to be *addictive*:? the researchers > could not find enough developers willing to program without LLM > assistance to have solid data, even when they offered to pay $50 an hour. Almost a year ago I had a major health crisis that left me unable to move, literally unable to even roll over in bed. I had partial use of one arm and that was it. (Details are on my website at https://sixdemonbag.org/?p=27 , but they're not relevant here.) After weeks in the hospital I was transferred to a rehabilitative care facility for another multi-week stay. My roommate was an elderly man. His mind was completely gone from dementia. He'd spend sixteen hours a day holding three-part conversations between himself, his future deceased self, and the self that had already gone on to heaven. It started off as a terrifying display of what dementia does to a mind and became a terrifying threat to my own mental health. The software of humanity is a separate thing from the hardware. Children raised as feral very rarely learn how to walk upright, use the toilet, or function as a member of a family unit. Having missed the developmental window for that software to be uploaded, those capabilities are forever foreclosed to them. This software also deteriorates over time. It needs consistent reinforcement for normal functioning. Long-term solitary confinement results in permanent psychological injury. I was getting very few visitors, no conversations from nurses, nothing, and sixteen hours a day of narrative nonsense from a guy who could not be distinguished from an LLM. Six weeks of that and I was a psychological basket case. I don't want to go into detail about how my mind went off the map, but -- I was in a scary place. So yes, when I hear people talk about how their workplace now demands the use of LLMs, I want to know "has anyone ever demonstrated the psychological, neurological, and psychiatric safety of spending forty hours a week interacting with LLMs?" I have not been able to find any consensus on the safety of long-term LLM interaction. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From hakuntheeril at gmail.com Mon Mar 30 11:10:54 2026 From: hakuntheeril at gmail.com (Hakun_the_eril) Date: Mon, 30 Mar 2026 11:10:54 +0200 Subject: What do LLMs mean for GnuPG? In-Reply-To: References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> Message-ID: I am a user of tools like Cursor,- and my personal opinion is that LMM is not perfect. But for those who cannot program because of neurological conditions, it is a valuable tool. Of course there are bad tools, and good tools. If the programming follows programming standards like PEP 8, rustfmt, clippy etc.. It has test modules who actually exercises code , it has been fuzzed, fuzzers have been running with AddressSanitizer + UBSan , it has been tested against Wycheproof test vectors, RFC 5639, and BSI specifications etc.. It also have self documented code , with documentation on what does what I personally dont have big issues with it. Of course,- it needs testing and human validation of important and sensitive functions. If all those criteria passes,- one its a good tool. Many people feel threatened by LMM's, and they have their right to be skeptical. But,- who can write 100% perfect code ? man. 30. mars 2026 kl. 10:42 skrev Robert J. Hansen via Gnupg-users < gnupg-users at gnupg.org>: > > Alarmingly, attempts to replicate the study in later years found that > > LLM-assisted programming appears to be *addictive*: the researchers > > could not find enough developers willing to program without LLM > > assistance to have solid data, even when they offered to pay $50 an hour. > > Almost a year ago I had a major health crisis that left me unable to > move, literally unable to even roll over in bed. I had partial use of > one arm and that was it. (Details are on my website at > https://sixdemonbag.org/?p=27 , but they're not relevant here.) > > After weeks in the hospital I was transferred to a rehabilitative care > facility for another multi-week stay. My roommate was an elderly man. > His mind was completely gone from dementia. He'd spend sixteen hours a > day holding three-part conversations between himself, his future > deceased self, and the self that had already gone on to heaven. It > started off as a terrifying display of what dementia does to a mind and > became a terrifying threat to my own mental health. > > The software of humanity is a separate thing from the hardware. Children > raised as feral very rarely learn how to walk upright, use the toilet, > or function as a member of a family unit. Having missed the > developmental window for that software to be uploaded, those > capabilities are forever foreclosed to them. > > This software also deteriorates over time. It needs consistent > reinforcement for normal functioning. Long-term solitary confinement > results in permanent psychological injury. > > I was getting very few visitors, no conversations from nurses, nothing, > and sixteen hours a day of narrative nonsense from a guy who could not > be distinguished from an LLM. > > Six weeks of that and I was a psychological basket case. I don't want to > go into detail about how my mind went off the map, but -- I was in a > scary place. > > So yes, when I hear people talk about how their workplace now demands > the use of LLMs, I want to know "has anyone ever demonstrated the > psychological, neurological, and psychiatric safety of spending forty > hours a week interacting with LLMs?" > > I have not been able to find any consensus on the safety of long-term > LLM interaction. > _______________________________________________ > 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 wk at gnupg.org Mon Mar 30 12:04:37 2026 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Mar 2026 12:04:37 +0200 Subject: Why Some Criticisms Matters More Than Others Message-ID: <874ilx8wga.fsf@jacob.g10code.de> Hi! Robert was kind enough to to turn one of his recent mailing list replies into an essay which is now available at https://gnupg.org/blog/20260320-some-criticism-matter.html 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: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon Mar 30 12:58:17 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 30 Mar 2026 06:58:17 -0400 Subject: What do LLMs mean for GnuPG? In-Reply-To: References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> Message-ID: <6ee3ad9d-93a7-481b-81d4-6be113f4f046@sixdemonbag.org> > I am a user of tools like Cursor,- and my personal opinion is that LMM > is not perfect. But for those who cannot program because? of > neurological conditions, it is a valuable tool. As a hacker who deals with mental illness, I am massively in favor of creating a community that is welcoming to people with psychological, psychiatric, and/or neurological troubles. But I draw the line at thinking we should lower our professional standards to accommodate these conditions. I do not believe LLMs should be authoring security-sensitive code, ever. > If the programming follows programming standards like? PEP 8, |rustfmt|, > clippy etc.. None of these verify quality code. The version of pwgen that Claude.ai created passed the normal clippy checks. > tested against Wycheproof test vectors, RFC 5639, and BSI specifications Having implemented more cryptographic algorithms in my life than I ever want to think about, "it passes the test vectors" does not create in me very much faith in the overall quality of the implementation. Circa 2008 at USENIX/EVT we gave a round of applause to a team of nerds who had implemented AES in Java, and given rigorous Floyd-Hoare proofs of correctness. It took them two and a half years of work. I once had to implement a highly reliable Galois counter mode. I yearned for the sweet release of death. > But,- who can write 100% perfect code ? It's hard but it's been done. The provably-correct AES implementation comes to mind, as does the RSRE VIPER processor. The IBM System 360 minicomputers that controlled the Space Shuttle never suffered a life-threatening bug, ever: even as _Challenger_ and _Columbia_ came apart the HAL/S software stack continued functioning correctly. https://en.wikipedia.org/wiki/VIPER_microprocessor https://en.wikipedia.org/wiki/HAL/S -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From hakuntheeril at gmail.com Mon Mar 30 15:27:35 2026 From: hakuntheeril at gmail.com (Hakun_the_eril) Date: Mon, 30 Mar 2026 15:27:35 +0200 Subject: What do LLMs mean for GnuPG? In-Reply-To: <6ee3ad9d-93a7-481b-81d4-6be113f4f046@sixdemonbag.org> References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> <6ee3ad9d-93a7-481b-81d4-6be113f4f046@sixdemonbag.org> Message-ID: I agree that actual code for ciphers must be 100% written by humans, and reviewed by humans,- but for everything else it can be a OK tool. man. 30. mars 2026, 13:01 skrev Robert J. Hansen via Gnupg-users < gnupg-users at gnupg.org>: > > I am a user of tools like Cursor,- and my personal opinion is that LMM > > is not perfect. But for those who cannot program because of > > neurological conditions, it is a valuable tool. > > As a hacker who deals with mental illness, I am massively in favor of > creating a community that is welcoming to people with psychological, > psychiatric, and/or neurological troubles. But I draw the line at > thinking we should lower our professional standards to accommodate these > conditions. > > I do not believe LLMs should be authoring security-sensitive code, ever. > > > If the programming follows programming standards like PEP 8, |rustfmt|, > > clippy etc.. > > None of these verify quality code. The version of pwgen that Claude.ai > created passed the normal clippy checks. > > > tested against Wycheproof test vectors, RFC 5639, and BSI specifications > > Having implemented more cryptographic algorithms in my life than I ever > want to think about, "it passes the test vectors" does not create in me > very much faith in the overall quality of the implementation. > > Circa 2008 at USENIX/EVT we gave a round of applause to a team of nerds > who had implemented AES in Java, and given rigorous Floyd-Hoare proofs > of correctness. It took them two and a half years of work. > > I once had to implement a highly reliable Galois counter mode. I yearned > for the sweet release of death. > > > But,- who can write 100% perfect code ? > > It's hard but it's been done. The provably-correct AES implementation > comes to mind, as does the RSRE VIPER processor. The IBM System 360 > minicomputers that controlled the Space Shuttle never suffered a > life-threatening bug, ever: even as _Challenger_ and _Columbia_ came > apart the HAL/S software stack continued functioning correctly. > > https://en.wikipedia.org/wiki/VIPER_microprocessor > https://en.wikipedia.org/wiki/HAL/S > > _______________________________________________ > 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 me at chandlerdavis.cc Mon Mar 30 15:14:43 2026 From: me at chandlerdavis.cc (Chandler Davis) Date: Mon, 30 Mar 2026 09:14:43 -0400 Subject: What do LLMs mean for GnuPG? In-Reply-To: <6ee3ad9d-93a7-481b-81d4-6be113f4f046@sixdemonbag.org> References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> <6ee3ad9d-93a7-481b-81d4-6be113f4f046@sixdemonbag.org> Message-ID: <8282a7c8-3368-4ed3-ae04-4d29907b16a4@app.fastmail.com> I'll preface this with saying the most I've ever done *for* GnuPG is contribute a line or two of documentation. I am simply an enthusiast that likes to read up on these discussions, so feel free to take my thoughts with a grain of salt. That being said, I do use LLMs professionally, and the company I work for also happens to be building an LLM-centric product. I feel like I've gotten as good of a grasp on it as I can without going mad. On one hand, I have noticed a fair amount of productivity gains, particularly with boilerplate but also across the board to some extent. It has also been an excellent (if not horrifyingly expensive) rubber duck. On the other... > I do not believe LLMs should be authoring security-sensitive code, ever. Absolutely agree. In my opinion, using LLMs to write code necessarily means letting things slip through the cracks. *That's* the tradeoff. Not to mention, they find solutions that tend towards the average (whether correct or flat-out wrong), and the average is not good enough for code that people stake their lives on. Writing good software is inconvenient, but as the saying goes, if was easy it wouldn't be worth doing. To boil it down to a point, I think LLMs are great as research tools and something to bounce ideas off of, and in the right environment, code generators. I think all but the last of those would seem reasonable for GnuPG development. If I'm not mistaken, the GnuPG project doesn't need to be developed quickly so much as it needs to be developed correctly and with much care and consideration, and that's roughly the antithesis of so-called "AI-driven development". As Robert said, I'm also happy to share my experiences with these tools in and out of the workplace if anyone's curious. ?A computer can never be held accountable, therefore a computer must never make a management decision.? - IBM Training Manual, 1979 From jcb62281 at gmail.com Tue Mar 31 05:45:28 2026 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Mon, 30 Mar 2026 22:45:28 -0500 Subject: Importance of memory hygiene (was: What do LLMs mean for GnuPG?) In-Reply-To: References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> Message-ID: <2d3186e1-ca08-4046-b711-5c93f49cfc5c@gmail.com> On 3/30/26 02:29, Robert J. Hansen wrote: >> This is a red herring on all modern systems, given the overall >> architecture of this tool. > > Yes and no. The general rule is to take responsibility for zeroizing > sensitive memory. Defense in depth involves, you know, *depth*. > > I agree with your comments; I disagree with your conclusion. In general, the general rule is correct and zeroing sensitive data upon expiry is a valid defense-in-depth practice.? :-) But the edge case that Claude identified is not actually a problem:? if the program panics, it will shortly exit, at which time the kernel is responsible for destroying its entire virtual address space. This actually leads to *another* possible problem that Claude seems to have missed:? what precautions are you taking to ensure that the generator state and/or generated passwords do not appear in a core dump? >> Put simply, for a "one-shot" tool that uses only a short-lived >> process, there is no need to be concerned about this issue. > > Save that it's a remarkably good habit to get into. :) I agree that it remains a good habit; in the DOS era, it was critical, lest your private key material eventually end up in the slack space in the last block of a file. Modern systems are "a bit stricter" about such information leaks.? :-) That said, the exception to the general rule is limited to exactly the type of tool you have written and a longer-lived process that only transiently needs sensitive information must take care to zero it, lest the sensitive information linger in swap or worse. >> I do not have the citation close at hand but I remember seeing >> studies done that found that developers believed that using LLMs made >> them about 25% faster, but the actual data showed that LLM usage made >> them about 19% slower. (Numbers retrieved from personal human memory, >> may not be exactly accurate.) > > Was it the METR survey? > > https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ That appears to be it. > [...] > >> This last point suggests to me that perhaps a strict prohibition on >> the use of LLMs to develop for GnuPG might be appropriate. > > I'm thinking it might be a good addition to the developer agreement, > yes. Concur. -- Jacob From jcb62281 at gmail.com Tue Mar 31 05:45:30 2026 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Mon, 30 Mar 2026 22:45:30 -0500 Subject: What do LLMs mean for GnuPG? In-Reply-To: References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> <6ee3ad9d-93a7-481b-81d4-6be113f4f046@sixdemonbag.org> Message-ID: <3e4ae71b-c796-4e3f-bad3-1f84ab42e258@gmail.com> On 3/30/26 08:27, Hakun_the_eril via Gnupg-users wrote: > I agree that actual code for ciphers must be 100% written by humans, > and reviewed by humans,-? but for everything else it can be a OK tool. No, no, no, no, and NO! Anything in the same process space where private or symmetric keys are handled is no less sensitive than the cipher implementation itself. Yes, this means lots of programs have really bad architectures for handling cipher keys. -- Jacob From rjh at sixdemonbag.org Tue Mar 31 06:46:57 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 31 Mar 2026 00:46:57 -0400 Subject: What do LLMs mean for GnuPG? In-Reply-To: <3e4ae71b-c796-4e3f-bad3-1f84ab42e258@gmail.com> References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> <6ee3ad9d-93a7-481b-81d4-6be113f4f046@sixdemonbag.org> <3e4ae71b-c796-4e3f-bad3-1f84ab42e258@gmail.com> Message-ID: <239bbcdd-013b-493f-8495-a772700a0dda@sixdemonbag.org> > No, no, no, no, and NO! Full agreement. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Mar 31 07:00:13 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 31 Mar 2026 01:00:13 -0400 Subject: Importance of memory hygiene In-Reply-To: <2d3186e1-ca08-4046-b711-5c93f49cfc5c@gmail.com> References: <9ed75726-642d-44a1-bccb-9b457b57713d@sixdemonbag.org> <2d3186e1-ca08-4046-b711-5c93f49cfc5c@gmail.com> Message-ID: > This actually leads to *another* possible problem that Claude seems to > have missed:? what precautions are you taking to ensure that the > generator state and/or generated passwords do not appear in a core dump? Internally, a 16384-glyph Vec:: buffer is maintained, and when a password is generated the characters are pulled from the buffer. When the buffer empties the contents are zeroized, a 12288-byte Vec:: is populated from the CSPRNG, base64ed to become the new buffer, and the u8 vector is zeroized. The glyph buffer is RAIIed to zeroize on a panic. The CSPRNG is just Rust's ChaCha20 CSPRNG. I haven't dived into the details of its implementation, but I do take the Rust Crypto team at their word when they say it is a CSPRNG meant for security-sensitive applications. If you could force a core dump during the particular nanosecond there's sensitive data in memory then it's possible you could recover sensitive data. I begin to think even at my level of paranoia that it's a bit excessive, though. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From hakuntheeril at gmail.com Tue Mar 31 15:36:14 2026 From: hakuntheeril at gmail.com (Hakun_the_eril) Date: Tue, 31 Mar 2026 15:36:14 +0200 Subject: Suggestions of standards added to openpgp/Gnupg/LibrePgp Message-ID: Hi! As the Baochip-x1 has the hardware to do a lot of cryptographic functions like active zeroisation, Ed25519 signed boot, Glitch sensors, security mesh, PV sensor, ECC-protected RAM,Algorithm-agnostic engine etc I think that these could be added to standards. . I suggest: # Authenticated Ephemeral ECDH Session Protocol and Cipher Profile Encoding ## Abstract This document specifies a **binary authenticated ephemeral ECDH handshake** (InitMessage and ResponseMessage), **HKDF-SHA256** key derivation with fixed UTF-8 labels, and a **compact binary encoding** for **named cipher profiles** (ECDHE curve, ordered AEAD layers, Shamir threshold metadata). The handshake provides **forward secrecy** for session keys: long-term keys authenticate ephemeral keys; ECDH uses ephemeral key pairs only. The format is intended for submission to the OpenPGP working group as an extension compatible in spirit with [RFC 9580](https://www.rfc-editor.org/rfc/rfc9580) algorithm and notation registries, without reusing OpenPGP packet syntax for the handshake octets themselves. --- ## 1. Introduction OpenPGP ([RFC 9580](https://www.rfc-editor.org/rfc/rfc9580)) specifies message formats, public-key encryption, signatures, and AEAD payloads. It does **not** define a standalone **ephemeral-ephemeral ECDH** session establishment with **mutual** authentication of ephemeral keys via **long-term** Brainpool signing keys. This document fills that gap for toolchains that require **forward secrecy** at the session layer while binding identity to existing long-term OpenPGP-compatible key material (fingerprint binding). **Cipher profiles** name a policy: **ECDHE curve**, **ordered list of symmetric AEAD layers** (encrypt order; decrypt reverse), and **Shamir (k, n)** metadata for long-term key handling. Profiles serialise to a **deterministic octet string** for storage and negotiation. This specification is written for **interoperability** among independent implementations that adopt the same octet layouts and labels. --- ## 2. Terminology The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and **OPTIONAL** are to be interpreted as described in BCP 14 ([RFC 2119](https://www.rfc-editor.org/rfc/rfc2119)) ([RFC 8174]( https://www.rfc-editor.org/rfc/rfc8174)) when, and only when, they appear in all capitals, as shown here. **Initiator:** The party that sends `InitMessage`. **Responder:** The party that sends `ResponseMessage`. **Long-term fingerprint:** SHA-256 digest (32 octets) over the uncompressed SEC1 encoding of the long-term **verifying** public key, represented on the wire as 64 ASCII hexadecimal digits. --- ## 3. Conventions - All multi-octet integers are **big-endian** unless stated otherwise. - **Curve public keys** are **uncompressed SEC1** points ([SEC 1]( https://www.secg.org/sec1-v2.pdf)). - **ECDSA** signatures on the wire are **DER**-encoded ([RFC 5480]( https://www.rfc-editor.org/rfc/rfc5480)-style ECDSA-Sig-Value). - **HKDF** follows [RFC 5869](https://www.rfc-editor.org/rfc/rfc5869) with **HMAC-SHA256**. --- ## 4. Protocol and encodings ### 4.1 Protocol version Implementations MUST support protocol version byte `0x01` for both `InitMessage` and `ResponseMessage`. Parsers MUST reject other version values unless a later specification defines them. ### 4.2 Curve identifiers (`curve_id`) | `curve_id` | Curve | SEC1 uncompressed length (octets) | |------------|--------|-----------------------------------| | `0x01` | brainpoolP256r1 [RFC 5639](https://www.rfc-editor.org/rfc/rfc5639) | 65 | | `0x02` | brainpoolP384r1 | 97 | | `0x03` | brainpoolP512r1 | 129 | Senders MUST set `curve_id` to one of these values. Receivers MUST verify that the ephemeral public key length field matches this table for the received `curve_id`. ### 4.3 InitMessage (normative layout) Serialisation order (concatenation): | Field | Size | Description | |-------|------|-------------| | `version` | 1 | MUST be `0x01`. | | `curve_id` | 1 | As in Section 4.2. | | `epk_len` | 1 | Length of initiator ephemeral public key; MUST equal SEC1 length for `curve_id`. | | `epk` | `epk_len` | Uncompressed SEC1 initiator ephemeral public key. | | `fp_len` | 1 | Length of fingerprint field; MUST be `64` when fingerprint is hex-encoded SHA-256. | | `fingerprint` | `fp_len` | 64 ASCII hex digits (`0-9`, `a-f` preferred; parsers MUST accept `A-F`). | | `sig_len` | 2 | Big-endian; length of DER signature. | | `signature` | `sig_len` | ECDSA-SHA256 over initiator **preimage** (Section 4.5). | The total serialised size MUST NOT exceed **512** octets. ### 4.4 ResponseMessage (normative layout) Fields 1?8 are identical in structure to InitMessage for `version`, `curve_id`, responder `epk_len`, responder `epk`, `fp_len`, responder long-term `fingerprint`, and `sig_len` / `signature` for the **responder** preimage. Additional fields: | Field | Size | Description | |-------|------|-------------| | (same as Init through responder signature) | | | | `iepk_len` | 1 | MUST equal initiator ephemeral length for `curve_id`. | | `initiator_epk_copy` | `iepk_len` | **Copy** of initiator ephemeral public key from InitMessage. | | `sig_len_r` | 2 | Big-endian; length of responder DER signature. | | `signature_r` | `sig_len_r` | ECDSA-SHA256 over responder **preimage** (Section 4.5). | The initiator MUST compare `initiator_epk_copy` to its own sent ephemeral key using a **constant-time** equality check. ### 4.5 Signature preimages (ECDSA-SHA256) Hash input is **raw concatenation** (no length prefixes except where lengths are fixed by `curve_id`): - **Initiator preimage:** `version || curve_id || initiator_ephemeral_sec1_uncompressed` - **Responder preimage:** `version || curve_id || responder_ephemeral_sec1 || initiator_ephemeral_sec1` The hash function is **SHA-256**; ECDSA is Brainpool with the long-term signing key associated with the fingerprint. ### 4.6 ECDH shared secret and HKDF 1. **ECDH** is performed on the agreed curve; the shared secret is the **x**-coordinate of the resulting point, packed to a fixed width per curve; **interoperating peers MUST use identical packing** (see Appendix A for conformance vectors). 2. **HKDF-Extract** salt: lexicographic ordering of the two ephemeral public key byte strings: if `epk_initiator <= epk_responder` (lexicographic octet compare), salt = `epk_initiator || epk_responder`; else salt = `epk_responder || epk_initiator`. If the salt is empty in a helper, implementations MUST use 32 zero octets as HMAC key per [RFC 5869]( https://www.rfc-editor.org/rfc/rfc5869) empty-salt handling where applicable. 3. **HKDF-Expand** with **SHA-256**; output length **32** octets per derived key unless a profile specifies otherwise. **HKDF `info` labels (UTF-8, exact octets):** | Label (exact) | Derived key role | |---------------|------------------| | `openpgp-ephemeral-session/payload-i2r/v1` | Payload AEAD, initiator to responder | | `openpgp-ephemeral-session/payload-r2i/v1` | Payload AEAD, responder to initiator | | `openpgp-ephemeral-session/gdss-mask/v1` | Optional GDSS masking stream | | `openpgp-ephemeral-session/gdss-sync/v1` | Optional GDSS sync | | `openpgp-ephemeral-session/gdss-timing/v1` | Optional GDSS timing | | `openpgp-ephemeral-session/mac/v1` | Optional HMAC key | Implementations MUST NOT reuse labels for distinct key roles. Changing any label octet breaks interoperability. ### 4.7 Cipher profile compact encoding A **cipher profile** serialises as: | Field | Size | Description | |-------|------|-------------| | `name_len` | 1 | Length of `name`; MUST be ? 64. | | `name` | `name_len` | UTF-8 profile identifier (e.g. `standard`, `conservative-shamir`). | | `desc_len` | 1 | Length of description; MUST be ? 128. | | `description` | `desc_len` | UTF-8 human-readable text. | | `curve_id` | 1 | Same as Section 4.2 (ECDHE curve for session). | | `layer_count` | 1 | Number of AEAD layers; MUST be 1?4. | | `layer_id` ? `layer_count` | each 1 | Symmetric layer type (see below). | | `shamir_k` | 1 | Shamir threshold **k** (1?255). | | `shamir_n` | 1 | Shamir total **n** (1?255); MUST satisfy `k ? n`. | **Layer type IDs (`layer_id`):** | `layer_id` | Algorithm | |------------|-----------| | `0x01` | AES-256-GCM | | `0x02` | ChaCha20-Poly1305 [RFC 8439]( https://www.rfc-editor.org/rfc/rfc8439) | | `0x03` | Twofish-256 (EtM construction as in implementation) | | `0x04` | Serpent-256 (EtM construction as in implementation) | **Encryption order:** layers are applied **in array order** (first layer = innermost plaintext); **decryption** applies **reverse** order. **Authentication** MUST be verified at each layer; failure MUST abort decryption. --- ## 5. Security Considerations **Threat model:** The handshake aims for **confidentiality** and **integrity** of session keys against passive and active network attackers, under the assumption that long-term signing keys remain uncompromised during the handshake. **Forward secrecy** holds for past sessions if ephemeral private keys are destroyed after use. **Limitations:** - This document does **not** specify transport binding to TLS or OpenPGP; bindings are application-defined. - **Side-channel** resistance of ECDH and ECDSA depends on the cryptographic library and hardware. - **Downgrade** of `curve_id` or profile MUST be prevented by policy at a higher layer if multiple options are offered. - **GDSS** optional keys are product-specific; implementations MAY omit derivation of those labels. **Guidance:** Implementations SHOULD use constant-time comparison for `initiator_epk_copy`. Implementations MUST zeroise ephemeral private keys after ECDH. --- ## 6. IANA Considerations This document requests IANA to create or extend registries under the **OpenPGP** umbrella (exact registry names subject to IESG and IANA review): | Registry | Request | |----------|---------| | **Ephemeral ECDH extension `curve_id`** (or sub-registry of Experimental / Private Use) | Reserve `0x01`?`0x03` as in Section 4.2; future values via IETF Review or Specification Required. | | **Cipher profile `layer_id`** | Reserve `0x01`?`0x04` as in Section 4.7. | | **HKDF info labels** | Register the six UTF-8 strings in Section 4.6 as **well-known** `info` labels for this protocol (reference: this document). | | **Notation names** (optional OpenPGP binding) | Register ` openpgp-cipher-profile at ietf.org` (example) for embedding profile fingerprints in signature notations if WG desires OpenPGP message binding. | Until IANA assigns numbers, private experimentation MAY use implementation-defined prefixes with **no** guarantee of global uniqueness. --- ## 7. References ### 7.1 Normative References | ID | Reference | |----|-----------| | RFC2119 | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. | | RFC5639 | Lochter, M. and Merkle, J., "Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation", RFC 5639, March 2010. | | RFC5869 | Krawczyk, H. and Eronen, P., "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010. | | RFC8174 | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. | | RFC8439 | Nir, Y. and Langley, A., "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018. | | SEC1 | SECG, "Elliptic Curve Cryptography", SEC 1, Version 2.0. | ### 7.2 Informative References | ID | Reference | |----|-----------| | RFC9580 | Wussler, S., et al., "OpenPGP", RFC 9580, July 2024. | --- ## Appendix A. Interoperability test anchors Implementations MUST demonstrate interoperability using **fixed test vectors** (to be published in a future revision of this document or a companion **Implementation Techniques** note). Until those vectors are published, conformance tests SHOULD cover: - Handshake serialisation round-trip for `InitMessage` and `ResponseMessage` per Sections 4.3?4.4. - HKDF label distinctness (no two roles share the same `info` string). - Brainpool ECDH and ECDSA with [RFC 5639]( https://www.rfc-editor.org/rfc/rfc5639) test vectors where applicable. - Side-channel review of comparison and scalar paths (implementation-dependent). # Shamir Secret Sharing for OpenPGP-Adjacent Key Material: Share Format and Field Arithmetic ## Abstract This document specifies **Shamir?s Secret Sharing** over **GF(256)** for secrets of **16 to 64 octets**, including **share index** and **share value** layout, **K-of-N** metadata, a **textual armour** format (**OPENPGP SHAMIR SHARE**), and **HKDF** labelling for post-recovery key derivation. It is intended for interoperability with hardware tokens and host tools that split or recover OpenPGP-relevant signing material. The format complements [RFC 9580](https://www.rfc-editor.org/rfc/rfc9580) OpenPGP messages by defining a **container** for shares that MAY be transported inside experimental packets or as standalone files. --- ## 1. Introduction Shamir?s method (1979) splits a secret into **N** shares such that any **K** shares suffice for reconstruction. This document **normatively** defines the **field**, **byte-wise sharing** construction, **wire formats**, and **armour** using **GF(256)** arithmetic compatible with the **AES** field (see `vsss_rs::Gf256` or equivalent **bit-identical** implementation). OpenPGP ([RFC 9580](https://www.rfc-editor.org/rfc/rfc9580)) does not define threshold splits of long-term private key material. This specification provides a **concrete** format implementors can adopt pending WG adoption of OpenPGP-native packet types. --- ## 2. Terminology The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and **OPTIONAL** are to be interpreted as described in BCP 14 ([RFC 2119](https://www.rfc-editor.org/rfc/rfc2119)) ([RFC 8174]( https://www.rfc-editor.org/rfc/rfc8174)) when, and only when, they appear in all capitals. **K:** Threshold number of shares required to reconstruct. **N:** Total number of shares generated. **Share index:** Non-zero octet in `1..=255` identifying the polynomial evaluation point. --- ## 3. Conventions - **Field:** GF(256) with the **same** reduction polynomial as the AES block field; implementations MUST produce **bit-identical** results to a **reference** `vsss_rs::Gf256` (or equivalent) definition across all split and recover operations. - **Secret length:** `L` octets where **16 ? L ? 64**. All shares for one split MUST use the same `L`. - **Threshold:** Integers **K** and **N** MUST satisfy **1 ? K ? N ? 255**. --- ## 4. Mathematical construction (normative) For each byte position **j** in `0..L` independently: 1. Let **s[j]** be the secret byte at position **j** (treated as an element of GF(256)). 2. Construct a polynomial **P** of degree **K ? 1** with coefficients in GF(256): the constant term is **s[j]**; coefficients **1..K?1** MUST be sampled uniformly at random using a cryptographically secure RNG. 3. For share index **i** (1 ? **i** ? **N**), the share byte at position **j** is **P(i)** evaluated in GF(256) with **i** mapped to the field element **i**. **Recovery:** Given **K** distinct shares with indices **i_1?i_K** and matching value vectors, the secret byte **s[j]** is **P(0)** computed via Lagrange interpolation in GF(256). Implementations MUST reject duplicate share indices during recovery. Implementations MUST NOT infer **K** solely from the number of shares without explicit parameter matching. --- ## 5. Binary share payload (normative minimum) A **share value** in memory or binary transport is: | Field | Size (octets) | Description | |-------|----------------|-------------| | `index` | 1 | Share index **i**, MUST be in `1..=255`. | | `value` | `L` | **16 ? L ? 64**; polynomial evaluation bytes aligned with Section 4. | The tuple `(index, value)` together with known **K**, **N**, and secret length **L** are REQUIRED for recovery. --- ## 6. OPENPGP SHAMIR SHARE armour (normative text format) Armour is **ASCII** and MUST use the following structure: 1. Line: `-----BEGIN OPENPGP SHAMIR SHARE-----` 2. Line: `Version: 1` 3. Line: `Profile: ` + UTF-8 profile name (policy label). 4. Line: `Threshold: ` + decimal **K**. 5. Line: `Total: ` + decimal **N**. 6. Line: `Index: ` + decimal share index **i**. 7. Line: `Fingerprint: ` + hexadecimal fingerprint of associated long-term key (implementation-defined encoding). 8. Line: `Created: ` + RFC 3339 timestamp. 9. Empty line. 10. Base64 ([RFC 4648](https://www.rfc-editor.org/rfc/rfc4648)) body encoding **only** the **`value`** octets (not the index). 11. Line: `-----END OPENPGP SHAMIR SHARE-----` Parsers MUST verify Base64 and length constraints. The **index** in the header MUST match the share; implementations MUST treat mismatch as fatal. **Note:** The index appears in the header; the **value** is Base64-only. Implementations MAY alternatively encode `index || value` in Base64 in a future version?**Version: 1** as specified ties index to header fields. --- ## 7. HKDF after recovery When expanding recovered material into operational keys, implementations **MUST** use [RFC 5869](https://www.rfc-editor.org/rfc/rfc5869) with **SHA-512** and `info` exactly: `openpgp-shamir/vault-recovery/v1` (UTF-8 octets) This label MUST NOT be reused for unrelated derivations. --- ## 8. Mapping to OpenPGP (informative operations) Implementations MAY: - Wrap armour in a **MIME** part or **file** attachment. - Place a **notation** on a signature: e.g. name `shamir-share-digest at openpgp.example` with a SHA-256 digest of the armour body (policy-specific). - Encapsulate binary payloads in **Private/Experimental** OpenPGP packets ([RFC 9580](https://www.rfc-editor.org/rfc/rfc9580) private packet conventions) once IANA assigns packet tags (Section 10). This document **does not** require OpenPGP implementations to parse shares inside literal data packets; it defines the **share format** independent of OpenPGP framing. --- ## 9. Security Considerations **Threat model:** Shares protect against single-point loss of the full secret only if **K** shares are required and **custody** is separated. An attacker with **K** shares reconstructs the secret. **Limitations:** - **GF(256)** Shamir is **not** post-quantum for the share reconstruction math; long-term risk is the same class as symmetric key recovery. - **RNG** quality for polynomial coefficients MUST be CSPRNG-backed. - **Armour** is **not encrypted**; implementations SHOULD encrypt shares at rest (e.g. OpenPGP-encrypted file) when distributed. - **Fingerprint** binding does not prevent substitution unless the fingerprint is verified out-of-band. **Guidance:** Implementations MUST zeroise recovered secrets after use. Implementations SHOULD use **constant-time** comparison where comparing share metadata to secrets. --- ## 10. IANA Considerations This document requests: | Item | Action | |------|--------| | **OpenPGP Packet Tag** | Assign an **Experimental** or **Private** packet tag for **OPENPGP-SHAMIR-SHARE** binary blob (optional encapsulation of Sections 5?6), or reserve from private-use range per [RFC 9580]( https://www.rfc-editor.org/rfc/rfc9580) IANA procedures. | | **Notation name** | Register `openpgp-shamir-share-v1 at ietf.org` (example) for signature notations pointing to external share custody. | | **HKDF info registry** | Register `openpgp-shamir/vault-recovery/v1` as a well-known `info` label for Shamir recovery KDF. | | **Media type** (optional) | `application/vnd.openpgp.shamir-share` for armour files. | Exact numbers are **TBD** pending IESG and IANA review. --- ## 11. References ### 11.1 Normative References | ID | Reference | |----|-----------| | RFC2119 | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119. | | RFC4648 | Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648. | | RFC5869 | Krawczyk, H. and Eronen, P., "HKDF", RFC 5869. | | RFC8174 | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174. | | SHAMIR79 | Shamir, A., "How to share a secret", Communications of the ACM, 1979. | ### 11.2 Informative References | ID | Reference | |----|-----------| | RFC9580 | "OpenPGP", RFC 9580. | --- ## Appendix A. Interoperability test anchors Implementations MUST validate split/recover using **published test vectors** (to be added in a future revision). Conformance tests SHOULD include: - Round-trip split and recover for fixed K, N, L. - Rejection of duplicate `index` values. - Boundary checks for L in {16, 64}. - **Fuzz** and timing-hardening (implementation-dependent). --- ## Document history | Version | Notes | |---------|--------| | 00 | Initial proposal: GF(256) Shamir, binary share payload, OPENPGP SHAMIR SHARE armour Version 1. | The baochips specs can be found here: https://www.baochip.com/ Or here: https://github.com/Supermagnum/Baochip-1x-firmware -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Tue Mar 31 16:24:05 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 31 Mar 2026 10:24:05 -0400 Subject: Suggestions of standards added to openpgp/Gnupg/LibrePgp In-Reply-To: References: Message-ID: Hakun, this list overwhelmingly prefers plain text, not HTML. Some list members (including Werner!) simply don't read HTML-composed emails. And sometimes, HTML emails render in a format that makes it impossible to read. > As the Baochip-x1 has the hardware to do a lot of cryptographic > functions like active zeroisation, Ed25519 signed boot, Glitch sensors, > security mesh, PV sensor, ECC-protected RAM,Algorithm-agnostic engine > etc I think that these could be added to standards. Why? That's the basic question here. What is the use case for LibrePGP that isn't being adequately addressed by the spec, and how would these changes mitigate that shortcoming? If you can give a good and terse answer to that question I'll be happy to consider this proposal. > The baochips specs can be found here: https://www.baochip.com/ Do you have any business relationship to this vendor? -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From hakuntheeril at gmail.com Tue Mar 31 17:09:08 2026 From: hakuntheeril at gmail.com (Hakun_the_eril) Date: Tue, 31 Mar 2026 17:09:08 +0200 Subject: Suggestions of standards added to openpgp/Gnupg/LibrePgp In-Reply-To: References: Message-ID: Oh I was not aware of that. My arguments are: Shamirs secret has been around since 1979,- I find it odd that it is not included in Openpgp. It could add things like distributed key custody, hardware enforced split custody. Right now,- if someone with a key leaves or dies important encrypted data gets lost. That would cause issues for any organization. It could also fix the plausible "only one person knows the password" to a " K of N can cooperate" situation. That would also work for a encrypted file system,- split into parts. If a hardware token has , say 256 GB space.. Then it can be a part of a Shamirs secret scheme. 4 out of 6 keys could be used to recreate the shared encrypted file system on a empty drive. Ephemeral signed elliptic curve diffie hellman is usable, because it will solve a forward security issue. If you encrypt say radio transmissions with the same key over long periods anyone who gets hold of that key can decrypt old transmissions. TLS 1.3 , the signal protocol and versions of openssh that is never than 5.7 supports this. I have no business relations with Baochip,- I just think its interesting and neat. tir. 31. mars 2026 kl. 16:27 skrev Robert J. Hansen via Gnupg-users < gnupg-users at gnupg.org>: > Hakun, this list overwhelmingly prefers plain text, not HTML. Some list > members (including Werner!) simply don't read HTML-composed emails. And > sometimes, HTML emails render in a format that makes it impossible to read. > > > As the Baochip-x1 has the hardware to do a lot of cryptographic > > functions like active zeroisation, Ed25519 signed boot, Glitch sensors, > > security mesh, PV sensor, ECC-protected RAM,Algorithm-agnostic engine > > etc I think that these could be added to standards. > > Why? > > That's the basic question here. What is the use case for LibrePGP that > isn't being adequately addressed by the spec, and how would these > changes mitigate that shortcoming? > > If you can give a good and terse answer to that question I'll be happy > to consider this proposal. > > > The baochips specs can be found here: https://www.baochip.com/ > > Do you have any business relationship to this vendor? > > _______________________________________________ > 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 andrewg at andrewg.com Tue Mar 31 18:32:47 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 31 Mar 2026 17:32:47 +0100 Subject: Suggestions of standards added to openpgp/Gnupg/LibrePgp In-Reply-To: References: Message-ID: <2459e847-8933-4826-97de-dc38c7359e91@andrewg.com> Hi, Hakun. On 31/03/2026 16:09, Hakun_the_eril via Gnupg-users wrote: > > My arguments are: > Shamirs secret has been around since 1979,- I find it odd that it is not > included in Openpgp. > It could add things like distributed key custody, hardware enforced > split custody. Right now,- if someone with a key leaves or dies > important encrypted data gets lost. It's relatively simple to combine Shamir with *PGP - for example, in keys.openpgp.org, we have used Shamir to split a strong encryption passphrase and used it to protect PGP secret key material using the standard string-to-key mechanism. There are also tools available to derive key material directly from a shared secret (e.g. https://git.distrust.co/public/keyfork/). Since it is technically nobody else's business what we do with those secret shares, it's not clear to me what a new specification would add (but I am open to argument!) > Ephemeral signed elliptic curve diffie hellman is usable, because it > will solve a forward security issue. > If you encrypt say radio transmissions with the same key over long > periods anyone who gets hold of that key can decrypt old transmissions. > TLS 1.3 , the signal protocol and versions of openssh that is never > than? 5.7 supports this. There are many implementation pitfalls inherent in any forward secrecy scheme, particularly when using a high-latency communications medium such as email, and in multi-device scenarios. Most forward-secrecy schemes rely on interactivity to ensure the stability of the ratchet; and this can fail catastrophically even in supposedly low-latency systems (google for "matrix unable to decrypt"). You may be interested in https://autocrypt2.org (work in progress), which addresses a lot of these practical issues without requiring a novel encryption algorithm. A From hakuntheeril at gmail.com Tue Mar 31 22:18:01 2026 From: hakuntheeril at gmail.com (Hakun_the_eril) Date: Tue, 31 Mar 2026 22:18:01 +0200 Subject: Suggestions of standards added to openpgp/Gnupg/LibrePgp In-Reply-To: <2459e847-8933-4826-97de-dc38c7359e91@andrewg.com> References: <2459e847-8933-4826-97de-dc38c7359e91@andrewg.com> Message-ID: Problems and pitfalls can be solved. tir. 31. mars 2026, 18:36 skrev Andrew Gallagher via Gnupg-users < gnupg-users at gnupg.org>: > Hi, Hakun. > > On 31/03/2026 16:09, Hakun_the_eril via Gnupg-users wrote: > > > > My arguments are: > > Shamirs secret has been around since 1979,- I find it odd that it is not > > included in Openpgp. > > It could add things like distributed key custody, hardware enforced > > split custody. Right now,- if someone with a key leaves or dies > > important encrypted data gets lost. > > It's relatively simple to combine Shamir with *PGP - for example, in > keys.openpgp.org, we have used Shamir to split a strong encryption > passphrase and used it to protect PGP secret key material using the > standard string-to-key mechanism. There are also tools available to > derive key material directly from a shared secret (e.g. > https://git.distrust.co/public/keyfork/). Since it is technically nobody > else's business what we do with those secret shares, it's not clear to > me what a new specification would add (but I am open to argument!) > > > Ephemeral signed elliptic curve diffie hellman is usable, because it > > will solve a forward security issue. > > If you encrypt say radio transmissions with the same key over long > > periods anyone who gets hold of that key can decrypt old transmissions. > > TLS 1.3 , the signal protocol and versions of openssh that is never > > than 5.7 supports this. > > There are many implementation pitfalls inherent in any forward secrecy > scheme, particularly when using a high-latency communications medium > such as email, and in multi-device scenarios. Most forward-secrecy > schemes rely on interactivity to ensure the stability of the ratchet; > and this can fail catastrophically even in supposedly low-latency > systems (google for "matrix unable to decrypt"). > > You may be interested in https://autocrypt2.org (work in progress), > which addresses a lot of these practical issues without requiring a > novel encryption algorithm. > > A > > > _______________________________________________ > 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 rjh at sixdemonbag.org Tue Mar 31 23:08:04 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 31 Mar 2026 17:08:04 -0400 Subject: Suggestions of standards added to openpgp/Gnupg/LibrePgp In-Reply-To: References: <2459e847-8933-4826-97de-dc38c7359e91@andrewg.com> Message-ID: Hakun, for the second time, please stop sending HTML to this list. The people you want to see your email, don't read HTML email. On 3/31/26 4:18 PM, Hakun_the_eril via Gnupg-users wrote: > Problems and pitfalls can be solved. I'm going to be blunt here: okay, then *you* do it. You're trying to persuade people to implement significant changes to the specification, to the architecture, and to the implementation, based on nothing more than your saying this is a good idea. If the people you are trying to convince to work for you *for free* say, "There are many implementation pitfalls inherent in [this]," and your response is to say "[p]roblems and pitfalls can be avoided," that tends to make us think you don't understand what you're asking for, or don't value our labor. Maybe both. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Mar 31 23:17:52 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 31 Mar 2026 17:17:52 -0400 Subject: Suggestions of standards added to openpgp/Gnupg/LibrePgp In-Reply-To: References: Message-ID: > Shamirs secret has been around since 1979,- I find it odd that it is not > included in Openpgp. LibrePGP (not OpenPGP) has very little to say about how keys are stored, accessed, or shared. It specifies a format by which keys can be output by one application and input to another, but specifying a common import/export format is pretty minimal. > It could add things like distributed key custody, hardware enforced > split custody. Right now,- if someone with a key leaves or dies > important encrypted data gets lost. No, because enterprises concerned about this use ADKs (which really should be called ARRs, but I lost that battle a quarter-century ago). > That would cause issues for any organization.? ?It could also fix the > plausible "only one person knows the password" to a " K of N can > cooperate" situation. So the sysadmin gets the private key, puts a strong 128-bit random passphrase on it, and then uses any of the commonly-available command-line Shamir implementations to do a K-of-N key breakup among the junior sysadmins. > That would also work for a encrypted file system,- split into parts. > If a hardware token has , say 256 GB space.. Then it can be a part of a > Shamirs secret scheme.? 4 out of 6 keys could be used to recreate the > shared encrypted file system on a empty drive. Why not just use the drive's full capacity, encrypt it with a 256-bit key, and use Shamir to do K-of-N on the key? This scheme seems wasteful. And why do you need Shamir in LibrePGP in order to achieve this? > Ephemeral signed elliptic curve diffie hellman is usable, because it > will solve a forward security issue. So far you don't appear to understand LibrePGP or Shamir very well. That is not an insult: everybody starts off not knowing this stuff. But your past track record so far makes me less willing to take your assertion on faith than if you were Ron Rivest. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: