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: