From bnsmith001 at gmail.com Fri May 1 05:07:11 2020 From: bnsmith001 at gmail.com (Barry Smith) Date: Thu, 30 Apr 2020 23:07:11 -0400 Subject: Maximum keypair length... Message-ID: Summary -- Maximum standard pubkey plus seckey pair length is what I'm asking about. Let me continue by explaining some back up information for my question. - I am asking in terms of the latest standards implemented in distros and Windows .exe auto-install packages. - I am trying to create a group calendar file and app for a private group. - Original concept for my project -- use an annual calendar file that has December (year minus 1) to January (year plus 1), so 14 months of days. I want one keypair per day for the group. I want the app to encrypt based upon date. I want the app to decrypt based upon based upon 3 keys... Date minus 1, Date, and Date plus 1. So, I need a keygen script that generates 427 (365+31+31) keypairs for a single ics file. THEN I'm thinking about field lengths in an ics, and realized that I don't know the ABSOLUTE longest key that can be created for a secret or public key. I have used DSA and RSA, and I moved from DSA to RSA years ago because at the time there were security concerns with DSA... and i think the max RSA can have as a discussion example is 8192... (that's bits, not bytes... so that's 1024 bytes max)... Not sure about ELG's max length... SO I chose to ask the expert users here. NO i didn't ask the devel group because I don't want devels confusing what they are working on for future versions, and I didn't ask docs group because they are also working in the future. ;) SO, users, help! I need to know the absolute longest key that GnuPG can create RIGHT NOW. Not previous versions, not future versions, but the current stable Windows auto-install .exe version RIGHT now. Then I can decide if I can have two fields in an .ics file, or if I need to create a data file for my app. ;) Thank you. Sorry that my email is so long for a simple question. Summary -- Maximum standard pubkey plus seckey pair length is what I'm asking about. -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at linuxfoundation.org Fri May 1 18:01:40 2020 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Fri, 1 May 2020 12:01:40 -0400 Subject: Maximum keypair length... In-Reply-To: References: Message-ID: <20200501160140.twytot4kvmrndt3j@chatter.i7.local> On Thu, Apr 30, 2020 at 11:07:11PM -0400, Barry Smith via Gnupg-users wrote: > Let me continue by explaining some back up information for my > question. > - I am asking in terms of the latest standards implemented in distros and > Windows .exe auto-install packages. > - I am trying to create a group calendar file and app for a private group. > - Original concept for my project -- use an annual calendar file that has > December (year minus 1) to January (year plus 1), so 14 months of days. I > want one keypair per day for the group. I'm not sure what kind of risk scenario you're working against, but this sounds extreme and will probably have all sorts of usability corner cases. > SO, users, help! > I need to know the absolute longest key that GnuPG can create RIGHT > NOW. It depends on the algorithm. RSA keys have the default maximum length of 8192 set at compile-time. Elliptic Curve cryptography requires much shorter keys, so maximums will be different there. In general, the length of the key is only part of the picture when we're talking about encryption "strength." Many cryptographers consider RSA keys longer than 2048 bits to be a "feel-good security theatre", because classical computers are not likely to be able to successfully break 2048-bit keys in the foreseeable future, even given state-level funding. If/once we get to the point where quantum computers are powerful enough to defeat 2048-bit RSA, then we should consider all classical public-key crypto irreversibly compromised (RSA, DSA, ECC, etc) -- longer keypair lengths will merely buy a bit of time before failing to cryptanalysis. So, if you want decent modern-day encryption, use 256-bit ECC keys and don't worry about key lengths longer than 256 (or 4096 for RSA). -K From klarsen at neweralife.com Tue May 5 14:09:44 2020 From: klarsen at neweralife.com (Kent A. Larsen) Date: Tue, 5 May 2020 12:09:44 +0000 Subject: gpg-agent connection errors Message-ID: As part of a server upgrade, we recently replaced a GnuPG 1.4.x installation with GnuPG 2.2.19, from the Gpg4win package (3.1.11). The server is running Windows Server 2016. We have an un-attended application that runs on that same server that needs to sign+encrypt a file (4 to 6 distinct files each weekday)for transfer to an external client. Since the upgrade, invoking gpg to sign+encypt a file periodically fails with the message "gpg: can't connect to the agent: IPC call failed" followed by messages indicating "No agent running". The failure appears to occur on the first file processed (in a group of 3 or more files), and the remaining files are processed without error. We are relying on gpg to automatically start gpg-agent (as needed). Does gpg-agent auto-terminate after a certain period of inactivity? Would appreciate any help you can provide that would allow us to eliminate these errors. Thanks. Kent A. Larsen, FLMI Systems Analyst New Era/Philadelphia American Life Insurance Companies klarsen at neweralife.com Direct: (402) 905-2179 HIPAA requires covered entities to safeguard Protected Health Information (PHI) related to a person's health care. Information in this email may include PHI that has been provided after appropriate authorization from the patient or under certain circumstances that do not require the patient's authorization. You, the recipient, are obligated to maintain PHI in a safe and secure manner. You may not use or disclose this email without additional patient consent unless required by law. Unauthorized use or disclosure of or failure to safeguard PHI could subject you to penalties under state and/or federal law. The information contained in this email and any attachments is also confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, please notify us immediately and delete this email from your email system. Please also shred any hard copy of this email and attachments, if any. If you have received this email in error, please notify our Privacy Officer immediately at (281)368-7200 (in Houston) or toll free at (800)552-7879. From klarsen at neweralife.com Tue May 5 20:08:25 2020 From: klarsen at neweralife.com (Kent A. Larsen) Date: Tue, 5 May 2020 18:08:25 +0000 Subject: gpg-agent connection errors Message-ID: As part of a server upgrade, we recently replaced a GnuPG 1.4.x installation with GnuPG 2.2.19, from the Gpg4win package (3.1.11). The server is running Windows Server 2016. We have an un-attended application that runs on that same server that needs to sign+encrypt a file (4 to 6 distinct files each weekday)for transfer to an external client. Since the upgrade, invoking gpg to sign+encypt a file periodically fails with the message "gpg: can't connect to the agent: IPC call failed" followed by messages indicating "No agent running". The failure appears to occur on the first file processed (in a group of 3 or more files), and the remaining files are processed without error. We are relying on gpg to automatically start gpg-agent (as needed). Does gpg-agent auto-terminate after a certain period of inactivity? Would appreciate any help you can provide that would allow us to eliminate these errors. Thanks. Kent A. Larsen, FLMI Systems Analyst New Era/Philadelphia American Life Insurance Companies klarsen at neweralife.com Direct: (402) 905-2179 HIPAA requires covered entities to safeguard Protected Health Information (PHI) related to a person's health care. Information in this email may include PHI that has been provided after appropriate authorization from the patient or under certain circumstances that do not require the patient's authorization. You, the recipient, are obligated to maintain PHI in a safe and secure manner. You may not use or disclose this email without additional patient consent unless required by law. Unauthorized use or disclosure of or failure to safeguard PHI could subject you to penalties under state and/or federal law. The information contained in this email and any attachments is also confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, please notify us immediately and delete this email from your email system. Please also shred any hard copy of this email and attachments, if any. If you have received this email in error, please notify our Privacy Officer immediately at (281)368-7200 (in Houston) or toll free at (800)552-7879. From klarsen at neweralife.com Tue May 5 21:14:48 2020 From: klarsen at neweralife.com (Kent A. Larsen) Date: Tue, 5 May 2020 19:14:48 +0000 Subject: gpg-agent connection errors Message-ID: As part of a server upgrade, we recently replaced a GnuPG 1.4.x installation with GnuPG 2.2.19, from the Gpg4win package (3.1.11). The server is running Windows Server 2016. We have an un-attended application that runs on that same server that needs to sign+encrypt a file (4 to 6 distinct files each weekday)for transfer to an external client. Since the upgrade, invoking gpg to sign+encypt a file periodically fails with the message "gpg: can't connect to the agent: IPC call failed" followed by messages indicating "No agent running". The failure appears to occur on the first file processed (in a group of 3 or more files), and the remaining files are processed without error. We are relying on gpg to automatically start gpg-agent (as needed). Does gpg-agent auto-terminate after a certain period of inactivity? Would appreciate any help you can provide that would allow us to eliminate these errors. Thanks. Kent A. Larsen, FLMI Systems Analyst New Era/Philadelphia American Life Insurance Companies klarsen at neweralife.com Direct: (402) 905-2179 HIPAA requires covered entities to safeguard Protected Health Information (PHI) related to a person's health care. Information in this email may include PHI that has been provided after appropriate authorization from the patient or under certain circumstances that do not require the patient's authorization. You, the recipient, are obligated to maintain PHI in a safe and secure manner. You may not use or disclose this email without additional patient consent unless required by law. Unauthorized use or disclosure of or failure to safeguard PHI could subject you to penalties under state and/or federal law. The information contained in this email and any attachments is also confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, please notify us immediately and delete this email from your email system. Please also shred any hard copy of this email and attachments, if any. If you have received this email in error, please notify our Privacy Officer immediately at (281)368-7200 (in Houston) or toll free at (800)552-7879. From wk at gnupg.org Wed May 6 13:57:53 2020 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 May 2020 13:57:53 +0200 Subject: gpg-agent connection errors In-Reply-To: (Kent A. Larsen's message of "Tue, 5 May 2020 12:09:44 +0000") References: Message-ID: <877dxpwa0u.fsf@wheatstone.g10code.de> On Tue, 5 May 2020 12:09, Kent A. Larsen said: > needed). Does gpg-agent auto-terminate after a certain period of > inactivity? No. Fruther, gpg-agent and all other background processes are always started on demand. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Thu May 7 00:30:47 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 7 May 2020 00:30:47 +0200 Subject: slightly OT - looking for sq.exe (sq 0.16.0) Message-ID: Hi all, just compiled sequoia pgp under Debian and now I am looking for a kind soul who can provide a Windows .exe, because I have no clue yet on how to do this successfully, in order to replace the not so good performing GnuPG on my old Windows 7 Notebook. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From sac at 300baud.de Thu May 7 02:32:11 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 7 May 2020 02:32:11 +0200 Subject: slightly OT - looking for sq.exe (sq 0.16.0) Message-ID: Stefan Claas wrote: > Hi all, > > just compiled sequoia pgp under Debian and now I am looking > for a kind soul who can provide a Windows .exe, because I have > no clue yet on how to do this successfully, in order to replace > the not so good performing GnuPG on my old Windows 7 Notebook. Ok, just installed MSYS2 and now it compiled properly the .exe and .dll files. :-) Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From carlotta_123 at hotmail.it Thu May 7 00:15:59 2020 From: carlotta_123 at hotmail.it (carla carlaa) Date: Wed, 6 May 2020 22:15:59 +0000 Subject: Efail or OpenPGP is safer than S/MIME Message-ID: p.ark3 From bnsmith001 at gmail.com Thu May 7 13:33:06 2020 From: bnsmith001 at gmail.com (Barry Smith) Date: Thu, 7 May 2020 07:33:06 -0400 Subject: Maximum keypair length... In-Reply-To: <20200501160140.twytot4kvmrndt3j@chatter.i7.local> References: <20200501160140.twytot4kvmrndt3j@chatter.i7.local> Message-ID: Thank you for your excellent response. I laid out my scenario. >> RSA keys have the default maximum length of 8192 set at compile-time. >> Perfect. that was the answer that I was looking for. My "risk scenario" was an attempt to understand the maximum defaults of the current maximum protection available in the standard distributed packages. >From the position of a data scientist, I am trying to compute the security available. ;) Thank you... 8196 on an RSA key. :) On Fri, May 1, 2020, 12:01 Konstantin Ryabitsev < konstantin at linuxfoundation.org> wrote: > On Thu, Apr 30, 2020 at 11:07:11PM -0400, Barry Smith via Gnupg-users > wrote: > > Let me continue by explaining some back up information for my > > question. > > - I am asking in terms of the latest standards implemented in distros and > > Windows .exe auto-install packages. > > - I am trying to create a group calendar file and app for a private > group. > > - Original concept for my project -- use an annual calendar file that has > > December (year minus 1) to January (year plus 1), so 14 months of days. I > > want one keypair per day for the group. > > I'm not sure what kind of risk scenario you're working against, but this > sounds extreme and will probably have all sorts of usability corner > cases. > > > SO, users, help! > > I need to know the absolute longest key that GnuPG can create RIGHT > > NOW. > > It depends on the algorithm. RSA keys have the default maximum length of > 8192 set at compile-time. Elliptic Curve cryptography requires much > shorter keys, so maximums will be different there. > > In general, the length of the key is only part of the picture when we're > talking about encryption "strength." Many cryptographers consider RSA > keys longer than 2048 bits to be a "feel-good security theatre", because > classical computers are not likely to be able to successfully break > 2048-bit keys in the foreseeable future, even given state-level funding. > If/once we get to the point where quantum computers are powerful enough > to defeat 2048-bit RSA, then we should consider all classical public-key > crypto irreversibly compromised (RSA, DSA, ECC, etc) -- longer keypair > lengths will merely buy a bit of time before failing to cryptanalysis. > > So, if you want decent modern-day encryption, use 256-bit ECC keys and > don't worry about key lengths longer than 256 (or 4096 for RSA). > > -K > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roam at ringlet.net Thu May 7 17:00:38 2020 From: roam at ringlet.net (Peter Pentchev) Date: Thu, 7 May 2020 18:00:38 +0300 Subject: Maximum keypair length... In-Reply-To: References: <20200501160140.twytot4kvmrndt3j@chatter.i7.local> Message-ID: <20200507150038.GB140052@straylight.m.ringlet.net> On Thu, May 07, 2020 at 07:33:06AM -0400, Barry Smith via Gnupg-users wrote: [formatting fixed; top-posting considered weird] > On Fri, May 1, 2020, 12:01 Konstantin Ryabitsev < > konstantin at linuxfoundation.org> wrote: > > > On Thu, Apr 30, 2020 at 11:07:11PM -0400, Barry Smith via Gnupg-users > > wrote: > > > Let me continue by explaining some back up information for my > > > question. > > > - I am asking in terms of the latest standards implemented in distros and > > > Windows .exe auto-install packages. > > > - I am trying to create a group calendar file and app for a private > > group. > > > - Original concept for my project -- use an annual calendar file that has > > > December (year minus 1) to January (year plus 1), so 14 months of days. I > > > want one keypair per day for the group. > > > > I'm not sure what kind of risk scenario you're working against, but this > > sounds extreme and will probably have all sorts of usability corner > > cases. > > > > > SO, users, help! > > > I need to know the absolute longest key that GnuPG can create RIGHT > > > NOW. > > > > It depends on the algorithm. RSA keys have the default maximum length of > > 8192 set at compile-time. Elliptic Curve cryptography requires much > > shorter keys, so maximums will be different there. > > > > In general, the length of the key is only part of the picture when we're > > talking about encryption "strength." Many cryptographers consider RSA > > keys longer than 2048 bits to be a "feel-good security theatre", because > > classical computers are not likely to be able to successfully break > > 2048-bit keys in the foreseeable future, even given state-level funding. > > If/once we get to the point where quantum computers are powerful enough > > to defeat 2048-bit RSA, then we should consider all classical public-key > > crypto irreversibly compromised (RSA, DSA, ECC, etc) -- longer keypair > > lengths will merely buy a bit of time before failing to cryptanalysis. > > > > So, if you want decent modern-day encryption, use 256-bit ECC keys and > > don't worry about key lengths longer than 256 (or 4096 for RSA). > > > > -K > > Thank you for your excellent response. > > I laid out my scenario. > >> > RSA keys have the default maximum length of > 8192 set at compile-time. > >> > Perfect. that was the answer that > I was looking for. > My "risk scenario" was an attempt to understand the maximum defaults of the > current maximum protection available in the standard distributed packages. > > From the position of a data scientist, I am trying to compute the security > available. ;) > > Thank you... 8196 on an RSA key. :) Leaving aside the fact that I agree with Konstantin about the pure futility of using 8K RSA keys (but, well, if you're asking from the standpoint of "this is something that somebody who wants to use my program at some point in the future may want"... but even from that standpoint, there may also be people who build their own versions of cryptography tools with even crazier limits, so even 8K might not be enough)... ...so leaving all that aside, when you speak of field lengths, you do realize, don't you, that the raw key material is only a part of even the information that is stored in the keyring, not to mention the information that is exported as a certificate (what most people think of when they say "my public key")? There are user IDs, there are self-signatures, there are signatures from other parties that let you actually trust the key... and most of these do not really have a fixed count, limit, or length. Then there is the export format, the fact that if you want to transmit the key and certificate through a text medium, you'll have to encode it and make it even larger... G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org pp at storpool.com PGP key: http://people.FreeBSD.org/~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 szczepan at nitrokey.com Fri May 8 07:12:32 2020 From: szczepan at nitrokey.com (Szczepan Zalega | Nitrokey) Date: Fri, 8 May 2020 07:12:32 +0200 Subject: GnuPG 2.2.20 under Termux (Android) ... In-Reply-To: <20200427185037.00001181@300baud.de> References: <20200427151529.00005cc7@300baud.de> <31c649f5-9d6e-9ad7-23f7-6a45695a58c8@nitrokey.com> <20200427185037.00001181@300baud.de> Message-ID: <73c6ed0a-c92d-51c4-c87c-9ed62d84791a@nitrokey.com> On 4/27/20 6:50 PM, Stefan Claas wrote: > I see in your address 'Nitrokey' and I was wondering (I have USB on my Samsung > A40) that a Nitrokey USB device would work properly with my Termux set-up, i.e. > Nitrokey drivers which must be detected via Termux, so that it would work? > > Are you aware of if this was ever been tested? Hi! Sorry for the delay. Nitrokey devices were tested with OpenKeychain [1] (available on F-Droid and Google Play), but not with the Termux. I will keep in mind to check this. Regarding smart card related features no additional drivers are needed, only the usual GnuPG requirements apply: device access and scdaemon service running for the actual device communication. [1] https://www.openkeychain.org/ -- Best regards, Szczepan From sac at 300baud.de Fri May 8 09:43:04 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 8 May 2020 09:43:04 +0200 Subject: GnuPG 2.2.20 under Termux (Android) ... In-Reply-To: <73c6ed0a-c92d-51c4-c87c-9ed62d84791a@nitrokey.com> References: <20200427151529.00005cc7@300baud.de> <31c649f5-9d6e-9ad7-23f7-6a45695a58c8@nitrokey.com> <20200427185037.00001181@300baud.de> <73c6ed0a-c92d-51c4-c87c-9ed62d84791a@nitrokey.com> Message-ID: Szczepan Zalega | Nitrokey via Gnupg-users wrote: > On 4/27/20 6:50 PM, Stefan Claas wrote: > > I see in your address 'Nitrokey' and I was wondering (I have USB on > > my Samsung A40) that a Nitrokey USB device would work properly with > > my Termux set-up, i.e. Nitrokey drivers which must be detected via > > Termux, so that it would work? > > > > Are you aware of if this was ever been tested? > > Hi! > > Sorry for the delay. Nitrokey devices were tested with OpenKeychain > [1] (available on F-Droid and Google Play), but not with the Termux. > I will keep in mind to check this. > Regarding smart card related features no additional drivers are > needed, only the usual GnuPG requirements apply: device access and > scdaemon service running for the actual device communication. > > > [1] https://www.openkeychain.org/ > Thanks for your reply, much appreciated! Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From gk at leniwiec.biz Fri May 8 12:49:03 2020 From: gk at leniwiec.biz (Grzegorz Kulewski) Date: Fri, 8 May 2020 12:49:03 +0200 Subject: Performance of Yubikey fw >= 5.2.3 and Curve25519 in OpenPGP Message-ID: Hello, Some time ago Yubico released Yubikeys 5 with new firmware capable of doing Curve25519 in OpenPGP (and not only). Unfortunately they don't offer any benchmarks so one can't be sure if the performance is decent vs. for example RSA 2048 and 4096. Also it seems that nobody published such benchmarks independently. Does anybody here have Curve25519 enabled Yubikey and did/could do such benchmarks? Thank you in advance! -- Grzegorz Kulewski From dgouttegattat at incenp.org Fri May 8 15:48:02 2020 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Fri, 8 May 2020 14:48:02 +0100 Subject: Performance of Yubikey fw >= 5.2.3 and Curve25519 in OpenPGP In-Reply-To: References: Message-ID: <20200508134802.xll2dfqjccxl3yxr@dynein.local.incenp.org> On Fri, May 08, 2020 at 12:49:03PM +0200, Grzegorz Kulewski wrote: >Does anybody here have Curve25519 enabled Yubikey and did/could do such >benchmarks? I have the following tokens: * a Yubikey NEO with a RSA-2048 key; * a Yubikey 5 with a Ed25519 key; * a FST-01G/Gnuk token with a Ed25519 key. I have not done any proper benchmark, but from my usage, my feeling is that the Yubikey 5 and the FST-01G have similar performances, and that they both outperform the Yubikey NEO with the RSA-2048 key. A quick decryption test seems to confirm that impression: * Yubikey NEO, RSA-2048: 0.795s ? 0.011s * Yubikey 5, Ed25519: 0.096s ? 0.005s * FST-01G, Ed25519: 0.075s ? 0.006s Note that the comparison between the RSA-2048 key on the Yubibey NEO and the Ed25519 key on the Yubikey 5 probably tells a lot more about the difference between the two generations of Yubikeys that it does about the difference between RSA and Ed25519. With the Yubikey NEO, even listing the card?s contents (with `gpg --card-status`) already takes ~0.7s, compared to ~0.05s with the Yubikey 5. - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From bnsmith001 at gmail.com Fri May 8 19:27:22 2020 From: bnsmith001 at gmail.com (Barry Smith) Date: Fri, 8 May 2020 13:27:22 -0400 Subject: Maximum keypair length... In-Reply-To: <20200507150038.GB140052@straylight.m.ringlet.net> References: <20200501160140.twytot4kvmrndt3j@chatter.i7.local> <20200507150038.GB140052@straylight.m.ringlet.net> Message-ID: Thank you, Peter. My question is purely about the security of the encryption. There is no need in my proposed scenario for extra signing or overhead. Understand that I am suggesting the creation of a set of keys, one per day, less than 33 keys, generated by one central admin. Second, i am looking to export the "sec" file for each calender day key... so that EACH group member will recieve both the pubkey AND the sec key on the group keyring from the group admin. Again, my focus was NOT on signatures or "bloat" involved in the keyring. My focus is on security. Thank you for your inclusion of valid points, but my point is only on security for group communication, not overhead involved in keyring export size. :) thank you. :) On Thu, May 7, 2020, 11:00 Peter Pentchev wrote: > On Thu, May 07, 2020 at 07:33:06AM -0400, Barry Smith via Gnupg-users > wrote: > [formatting fixed; top-posting considered weird] > > On Fri, May 1, 2020, 12:01 Konstantin Ryabitsev < > > konstantin at linuxfoundation.org> wrote: > > > > > On Thu, Apr 30, 2020 at 11:07:11PM -0400, Barry Smith via Gnupg-users > > > wrote: > > > > Let me continue by explaining some back up information for my > > > > question. > > > > - I am asking in terms of the latest standards implemented in > distros and > > > > Windows .exe auto-install packages. > > > > - I am trying to create a group calendar file and app for a private > > > group. > > > > - Original concept for my project -- use an annual calendar file > that has > > > > December (year minus 1) to January (year plus 1), so 14 months of > days. I > > > > want one keypair per day for the group. > > > > > > I'm not sure what kind of risk scenario you're working against, but > this > > > sounds extreme and will probably have all sorts of usability corner > > > cases. > > > > > > > SO, users, help! > > > > I need to know the absolute longest key that GnuPG can create RIGHT > > > > NOW. > > > > > > It depends on the algorithm. RSA keys have the default maximum length > of > > > 8192 set at compile-time. Elliptic Curve cryptography requires much > > > shorter keys, so maximums will be different there. > > > > > > In general, the length of the key is only part of the picture when > we're > > > talking about encryption "strength." Many cryptographers consider RSA > > > keys longer than 2048 bits to be a "feel-good security theatre", > because > > > classical computers are not likely to be able to successfully break > > > 2048-bit keys in the foreseeable future, even given state-level > funding. > > > If/once we get to the point where quantum computers are powerful enough > > > to defeat 2048-bit RSA, then we should consider all classical > public-key > > > crypto irreversibly compromised (RSA, DSA, ECC, etc) -- longer keypair > > > lengths will merely buy a bit of time before failing to cryptanalysis. > > > > > > So, if you want decent modern-day encryption, use 256-bit ECC keys and > > > don't worry about key lengths longer than 256 (or 4096 for RSA). > > > > > > -K > > > > Thank you for your excellent response. > > > > I laid out my scenario. > > >> > > RSA keys have the default maximum length of > > 8192 set at compile-time. > > >> > > Perfect. that was the answer that > > I was looking for. > > My "risk scenario" was an attempt to understand the maximum defaults of > the > > current maximum protection available in the standard distributed > packages. > > > > From the position of a data scientist, I am trying to compute the > security > > available. ;) > > > > Thank you... 8196 on an RSA key. :) > > Leaving aside the fact that I agree with Konstantin about the pure > futility of using 8K RSA keys (but, well, if you're asking from > the standpoint of "this is something that somebody who wants to use > my program at some point in the future may want"... but even from > that standpoint, there may also be people who build their own > versions of cryptography tools with even crazier limits, so even > 8K might not be enough)... > > ...so leaving all that aside, when you speak of field lengths, > you do realize, don't you, that the raw key material is only > a part of even the information that is stored in the keyring, > not to mention the information that is exported as a certificate > (what most people think of when they say "my public key")? > There are user IDs, there are self-signatures, there are > signatures from other partied that let you actually trust > the key... and most of these do not really have a fixed > count, limit, or length. Then there is the export format, > the fact that if you want to transmit the key and certificate > through a text medium, you'll have to encode it and make it > even larger... > > G'luck, > Peter > > -- > Peter Pentchev roam at ringlet.net roam at debian.org pp at storpool.com > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roam at ringlet.net Fri May 8 20:51:36 2020 From: roam at ringlet.net (Peter Pentchev) Date: Fri, 8 May 2020 21:51:36 +0300 Subject: Maximum keypair length... In-Reply-To: References: <20200501160140.twytot4kvmrndt3j@chatter.i7.local> <20200507150038.GB140052@straylight.m.ringlet.net> Message-ID: <20200508185136.GI9891@straylight.m.ringlet.net> On Fri, May 08, 2020 at 01:27:22PM -0400, Barry Smith wrote: [formatting fixed, top-posting still considered weird] > On Thu, May 7, 2020, 11:00 Peter Pentchev wrote: > > > On Thu, May 07, 2020 at 07:33:06AM -0400, Barry Smith via Gnupg-users > > wrote: > > [formatting fixed; top-posting considered weird] > > > On Fri, May 1, 2020, 12:01 Konstantin Ryabitsev < > > > konstantin at linuxfoundation.org> wrote: > > > > > > > On Thu, Apr 30, 2020 at 11:07:11PM -0400, Barry Smith via Gnupg-users > > > > wrote: > > > > > Let me continue by explaining some back up information for my > > > > > question. > > > > > - I am asking in terms of the latest standards implemented in > > distros and > > > > > Windows .exe auto-install packages. > > > > > - I am trying to create a group calendar file and app for a private > > > > group. > > > > > - Original concept for my project -- use an annual calendar file > > that has > > > > > December (year minus 1) to January (year plus 1), so 14 months of > > days. I > > > > > want one keypair per day for the group. > > > > > > > > I'm not sure what kind of risk scenario you're working against, but > > this > > > > sounds extreme and will probably have all sorts of usability corner > > > > cases. > > > > > > > > > SO, users, help! > > > > > I need to know the absolute longest key that GnuPG can create RIGHT > > > > > NOW. > > > > > > > > It depends on the algorithm. RSA keys have the default maximum length > > of > > > > 8192 set at compile-time. Elliptic Curve cryptography requires much > > > > shorter keys, so maximums will be different there. > > > > > > > > In general, the length of the key is only part of the picture when > > we're > > > > talking about encryption "strength." Many cryptographers consider RSA > > > > keys longer than 2048 bits to be a "feel-good security theatre", > > because > > > > classical computers are not likely to be able to successfully break > > > > 2048-bit keys in the foreseeable future, even given state-level > > funding. > > > > If/once we get to the point where quantum computers are powerful enough > > > > to defeat 2048-bit RSA, then we should consider all classical > > public-key > > > > crypto irreversibly compromised (RSA, DSA, ECC, etc) -- longer keypair > > > > lengths will merely buy a bit of time before failing to cryptanalysis. > > > > > > > > So, if you want decent modern-day encryption, use 256-bit ECC keys and > > > > don't worry about key lengths longer than 256 (or 4096 for RSA). > > > > > > > > -K > > > > > > Thank you for your excellent response. > > > > > > I laid out my scenario. > > > >> > > > RSA keys have the default maximum length of > > > 8192 set at compile-time. > > > >> > > > Perfect. that was the answer that > > > I was looking for. > > > My "risk scenario" was an attempt to understand the maximum defaults of > > the > > > current maximum protection available in the standard distributed > > packages. > > > > > > From the position of a data scientist, I am trying to compute the > > security > > > available. ;) > > > > > > Thank you... 8196 on an RSA key. :) > > > > Leaving aside the fact that I agree with Konstantin about the pure > > futility of using 8K RSA keys (but, well, if you're asking from > > the standpoint of "this is something that somebody who wants to use > > my program at some point in the future may want"... but even from > > that standpoint, there may also be people who build their own > > versions of cryptography tools with even crazier limits, so even > > 8K might not be enough)... > > > > ...so leaving all that aside, when you speak of field lengths, > > you do realize, don't you, that the raw key material is only > > a part of even the information that is stored in the keyring, > > not to mention the information that is exported as a certificate > > (what most people think of when they say "my public key")? > > There are user IDs, there are self-signatures, there are > > signatures from other partied that let you actually trust > > the key... and most of these do not really have a fixed > > count, limit, or length. Then there is the export format, > > the fact that if you want to transmit the key and certificate > > through a text medium, you'll have to encode it and make it > > even larger... > > Thank you, Peter. > > My question is purely about the security of the encryption. > There is no need in my proposed scenario for extra signing or overhead. > > Understand that I am suggesting the creation of a set of keys, one per day, > less than 33 keys, generated by one central admin. > > Second, i am looking to export the "sec" file for each calender day key... > so that EACH group member will recieve both the pubkey AND the sec key on > the group keyring from the group admin. > > Again, my focus was NOT on signatures or "bloat" involved in the keyring. > My focus is on security. > > Thank you for your inclusion of valid points, but my point is only on > security for group communication, not overhead involved in keyring export > size. :) Um. You asked about keys that GnuPG supports. This indicates to me that you intend to use GnuPG as an implementation of OpenPGP to encrypt/decrypt/sign data using OpenPGP keys. I really do not understand how you would go about accomplishing that without the 'signatures or "bloat"' :) If by 'export the "sec" file' you mean the GnuPG keyring that contains the secret key data, it does indeed contain user IDs, signatures, and everything else. If by "export" you mean "export in some kind of text format for transmission through a text-only medium", this does indeed invole the armoring that I mentioned in my last sentence. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org pp at storpool.com PGP key: http://people.FreeBSD.org/~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 angel at pgp.16bits.net Sun May 10 00:18:47 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 10 May 2020 00:18:47 +0200 Subject: Maximum keypair length... In-Reply-To: References: <20200501160140.twytot4kvmrndt3j@chatter.i7.local> <20200507150038.GB140052@straylight.m.ringlet.net> Message-ID: <1589062727.1099.63.camel@16bits.net> On 2020-05-08 at 13:27 -0400, Barry Smith via Gnupg-users wrote: > Understand that I am suggesting the creation of a set of keys, one per > day, less than 33 keys, generated by one central admin. > > Second, i am looking to export the "sec" file for each calender day > key... so that EACH group member will recieve both the pubkey AND the > sec key on the group keyring from the group admin. > > Again, my focus was NOT on signatures or "bloat" involved in the > keyring. My focus is on security. > > Thank you for your inclusion of valid points, but my point is only on > security for group communication, not overhead involved in keyring > export size. :) Sorry, but your scenario is really weird, to the point I suspect you are not understanding/taking things into account properly. What do you try to achieve? What's your threat model? If everyone involved will have both the public and secret daily keys, I don't see the need for using public cryptography. Just generate all those daily keys? as a random 128 bit passphrase each and use a symmetric cipher such as AES.? In fact, if everyone receives all the keys at once, someone that got hold of one daily client by compromised a client, would get hold of all of them. So your daily keys add about nothing here, and you can use a single keypair or a single symmetric key. A neat way to still change keys daily, rather than using that symmetric directly, would be to use a HMAC of that key with the given day. But really, an attacker won't recover your key through cryptanalysis,? malware, wrenches and people's stupidity are more important threats. A part when key rotation would help would be when people joins and parts such group. A new member only needs to receive the keys from now on, so if everyone used a different key each day, even if the new member somehow had the ciphertext for the day previous to joining the private group, he wouldn't be able to read it. However, if in the above process we changed: Daily_key[today] = HMAC(, Today) Encryption_key = Daily_key[today] with something like Daily_key[today] = HMAC(first 128 bits of Daily_key[yesterday], Today) Encryption_key = last 128 bits of Daily_key[today] then we also get that property of protecting old messages from an attacker with the key for the current day. This allows the app to daily forget the keys of the day before yesterday, so it cannot be obtained by an attacker that compromised the device. In both cases, when people leaves the group you will need to rekey, distributing new key(s) to everyone. As for your usage of an ics file to store gpg keys, they have not-before and not-after dates, so just distributing keys (or subkeys) with those values properly set would have any implementation do the right thing of picking the correct key. However, there is little reason to create such keypairs, per above. A more usual approach if you were using public key cryptography would be to use a key per user and simply interchange pgp messages. Have a look at how deltachat implements that. Also review the Signal protocol,? which is much more complete (and complex) than everything layered out here. Cheers ? Initially you mentioned 427 keys, but later mentioned they were "less than 33 keys" ? You still need to properly use a block cipher mode such as GCM, don't reuse iv, etc. You may use pgp for the encryption, but you would not be using gpg keys. ? if everything is implemented properly ? https://en.wikipedia.org/wiki/Signal_Protocol From listofactor at mail.ru Sun May 10 05:35:10 2020 From: listofactor at mail.ru (LisToFacTor) Date: Sun, 10 May 2020 03:35:10 +0000 Subject: Maximum keypair length... In-Reply-To: <1589062727.1099.63.camel@16bits.net> References: <20200501160140.twytot4kvmrndt3j@chatter.i7.local> <20200507150038.GB140052@straylight.m.ringlet.net> <1589062727.1099.63.camel@16bits.net> Message-ID: > If everyone involved will have both the public and secret > daily keys, I don't see the need for using public cryptography. > Just generate all those daily keys? as a random 128 bit > passphrase each and use a symmetric cipher such as AES.? It is actually an interesting contemporary phenomenon: there are quite a few instances I've encountered, where the threat model is never properly defined, and therefore the cryptography system architecture is not what fits any particular threat model, and where public key crypto is used where the "common", symmetrical crypto would do the trick quite nicely. It is my theory that this is happening with such surprising regularity because too many system architects view GPG as a "magic box", without even understanding that in reality it is only a public key crypto "wrapper" around the conventional, symmetric crypto hiding inside. In other words, symmetric crypto is *always used* by their system, if the wrapper around it is used in addition, there better be a justifiable reason for it. From rjh at sixdemonbag.org Tue May 12 00:11:27 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 11 May 2020 18:11:27 -0400 Subject: Fwd: The GnuPR FAQ In-Reply-To: References: Message-ID: <129a1392-0a0c-f527-0ec3-076222e2693d@sixdemonbag.org> This arrived in my inbox: I'm presenting it here without comment. My response will be following in a moment. -------- Forwarded Message -------- Subject: The GnuPR FAQ Date: Mon, 11 May 2020 14:19:07 -0600 From: James Long To: rjh at sixdemonbag.org Greetings! I'm just getting?started on a write-up with instructions explaining?how to use all of the new options in GnuPG to set it up in the various email clients and browsers. I noticed on this page: https://www.gnupg.org/faq/gnupg-faq.html? You've advised people to use a HORRIBLE practice of using dictionary words solely for their password. I tested this theory myself back in the day, so I can 100% guaranty you of this fact: A brute force dictionary based attack can crack a password like that in LESS THAN 5 minutes!! I once stretched that out to 20 minutes by cleverly picking words that I already knew were at the opposite ends of the dictionary. This was back in the Pentium II days!! Processors these days could likely crack a dictionary based password in a matter of seconds.? I'm sorry, but that particular bit of advise is terrible and needs to be changed. If you guys accept public assistance, I could go through the instruction / FAQ pages for you, update them, then submit them to you for approval. Since I'm already writing updated instructions anyway. ;)? ?- James T. Long ------------ There are 10 kinds of people in the world - those who understand binary, and those who don't. From rjh at sixdemonbag.org Tue May 12 00:13:11 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 11 May 2020 18:13:11 -0400 Subject: The GnuPR FAQ In-Reply-To: References: Message-ID: > This was back in the Pentium II days!! Processors these days could > likely crack a dictionary based password in a matter of seconds. Tell you what: try it. :) If you choose only from the thousand most-common English words (a keyspace of about 2^10), a six-word passphrase gives a work factor of 2^60. The key derivation function means you're spending at least 2^-10 seconds for each attempt, which means you've got 50/50 odds of breaking the passphrase after 2^49 seconds -- or about 18 million years. A four-word passphrase could be broken after 2^29 seconds, or about 17 years. It's parallelizable, of course, if you want to rent out 18 million AWS instances. But at present, the sense of the community is that the FAQ advice, which gives people between 17 years and 18 million years of resistance to a brute-force attack, is sufficient. > I'm sorry, but that particular bit of advise is terrible and needs to be > changed. I have forwarded your criticism on to the community and invited them to give their own feedback. The FAQ is the collective opinion of the community, not just myself -- all I do is write the thing. If the community concurs with your sentiments, I'll change the text. > If you guys accept public assistance, I could go through the > instruction / FAQ pages for you, update them, then submit them to you > for approval. We welcome any useful contributions. :) From vedaal at nym.hush.com Tue May 12 01:00:19 2020 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Mon, 11 May 2020 19:00:19 -0400 Subject: Fwd: The GnuPR FAQ In-Reply-To: <129a1392-0a0c-f527-0ec3-076222e2693d@sixdemonbag.org> References: <129a1392-0a0c-f527-0ec3-076222e2693d@sixdemonbag.org> Message-ID: <20200511230019.C9334E0772@smtp.hushmail.com> On 5/11/2020 at 6:15 PM, "Robert J. Hansen" wrote: > >This arrived in my inbox: I'm presenting it here without comment. >My >response will be following in a moment. > > >-------- Forwarded Message -------- >Subject: The GnuPR FAQ >Date: Mon, 11 May 2020 14:19:07 -0600 >From: James Long >To: rjh at sixdemonbag.org ----- >You've advised people to use a HORRIBLE practice of using >dictionary words solely for their password. I tested this theory myself back >in the day, so I can 100% guaranty you of this fact: A brute force >dictionary based attack can crack a password like that in LESS THAN 5 >minutes!! ===== How many words were in your passphrase?? Here is some data on the Diceware list: https://theworld.com/~reinhold/diceware.html The Diceware list has only 7776 words. A complete dictionary has almost 2 orders of magnitude more. "Webster's Third New International Dictionary, Unabridged, together with its 1993 Addenda Section, includes some 470,000 entries. The Oxford English Dictionary, Second Edition, reports that it includes a similar number." https://www.merriam-webster.com/help/faq-how-many-english-words 10 diceware words provides a greater Brute Force space, than 2^128 (a gnupg session key for older defaults of CAST-5) ( 7776^10 = 8.08x10^38 2^128 = 3.40?10^38 ) 20 Diceware words provides a greater Brute Force space, than 2^256 ( 7776^20 = 6.53?10^77 2^256 =1.157?10^77 ) Even using only English words greater than 5 letters and unrelated to each other, an extremely low-bound estimate, would be 77760 words. (in reality, far greater, but let's use an example people would agree on). So using 8 words chosen semi-randomly from a dictionary, 77760^8 = 1.336?10??, still greater than a a 2^128 Brute Force Space. So, not only is is NOT *horrible* advice, it should be enough for anyone's threat model. vedaal From azbigdogs at gmx.com Tue May 12 02:22:13 2020 From: azbigdogs at gmx.com (Mark) Date: Mon, 11 May 2020 17:22:13 -0700 Subject: Updating of Keys Message-ID: <89dce43a-7e99-5cd0-0cf8-d230f84081fd@gmx.com> Kinda of a stupid question here about updating your keys. I'm curious as to what changes would require you to re-upload it to a keyserver.??? I assume updating the passphrase would not because that is tied to the private key but does it change anything in the public key where that might be require it to be updated?? How about changing the expiration date of the primary and secondary keys? I assume that would be needed to be updated to the keyserver.? Which then brings me to another question, what happens when you re-upload your key to a keyserver. Does it overwrite the older one or ?? Thanks From azbigdogs at gmx.com Tue May 12 02:15:18 2020 From: azbigdogs at gmx.com (Mark) Date: Mon, 11 May 2020 17:15:18 -0700 Subject: Comparison of RSA vs elliptical keys Message-ID: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> I'm trying to understand the differences in strength between an RSA key and an elliptical one such ed25519 with cv25519. I know with RSA it is pretty easy to "gauge" the strength 1024 vs 2048 vs 4096.? I could not really find anything to say how strong these elliptical keys are and how they compare to RSA ones.? Thanks From pete at heypete.com Tue May 12 03:46:24 2020 From: pete at heypete.com (Pete Stephenson) Date: Mon, 11 May 2020 18:46:24 -0700 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> Message-ID: <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> On Mon, May 11, 2020, at 5:15 PM, Mark wrote: > I'm trying to understand the differences in strength between an RSA key > and an elliptical one such ed25519 with cv25519. I know with RSA it is > pretty easy to "gauge" the strength 1024 vs 2048 vs 4096.? > > I could not really find anything to say how strong these elliptical keys > are and how they compare to RSA ones.? Good question! Broadly, and with several assumptions, elliptic curves have the same security level as symmetric (e.g., AES) keys that are half the elliptic key's length. See https://en.m.wikipedia.org/wiki/Key_size and the references therein as a starting point. For example, a 256 bit elliptic curve key has a similar strength to a symmetric key of 128 bits. Due to various reasons, not all ECC keys are powers of 2 in length. For example, NIST P-521 is 521 bits long rather than 512 bits, and has equivalent security to a 256 bit symmetric key. Cheers! -Pete -- Pete Stephenson From gnupg at raf.org Tue May 12 02:52:29 2020 From: gnupg at raf.org (raf) Date: Tue, 12 May 2020 10:52:29 +1000 Subject: Fwd: The GnuPR FAQ In-Reply-To: <20200511230019.C9334E0772@smtp.hushmail.com> References: <129a1392-0a0c-f527-0ec3-076222e2693d@sixdemonbag.org> <20200511230019.C9334E0772@smtp.hushmail.com> Message-ID: <20200512005229.ajzysvbkbgealura@raf.org> vedaal via Gnupg-users wrote: > On 5/11/2020 at 6:15 PM, "Robert J. Hansen" wrote: > > > >This arrived in my inbox: I'm presenting it here without comment. > >My > >response will be following in a moment. > > > > > >-------- Forwarded Message -------- > >Subject: The GnuPR FAQ > >Date: Mon, 11 May 2020 14:19:07 -0600 > >From: James Long > >To: rjh at sixdemonbag.org > ----- > >You've advised people to use a HORRIBLE practice of using > >dictionary words solely for their password. I tested this theory myself back > >in the day, so I can 100% guaranty you of this fact: A brute force > >dictionary based attack can crack a password like that in LESS THAN 5 > >minutes!! > > ===== > How many words were in your passphrase?? > > Here is some data on the Diceware list: > https://theworld.com/~reinhold/diceware.html > > The Diceware list has only 7776 words. A complete dictionary has almost 2 orders of magnitude more. > > "Webster's Third New International Dictionary, Unabridged, together with its 1993 Addenda Section, includes some 470,000 entries. The Oxford English Dictionary, Second Edition, reports that it includes a similar number." > https://www.merriam-webster.com/help/faq-how-many-english-words > > 10 diceware words provides a greater Brute Force space, than 2^128 (a gnupg session key for older defaults of CAST-5) > ( 7776^10 = 8.08x10^38 2^128 = 3.40?10^38 ) > > 20 Diceware words provides a greater Brute Force space, than 2^256 > ( 7776^20 = 6.53?10^77 2^256 =1.157?10^77 ) > > Even using only English words greater than 5 letters and unrelated to each other, an extremely low-bound estimate, would be 77760 words. (in reality, far greater, but let's use an example people would agree on). > > So using 8 words chosen semi-randomly from a dictionary, 77760^8 = 1.336?10??, still greater than a a 2^128 Brute Force Space. > > So, not only is is NOT *horrible* advice, it should be enough for anyone's threat model. I can only assume that James must have thought that a *single* dictionary word was what was meant, not a large number of randomly-chosen dictionary words. I love diceware passwords. Sometimes you even get lucky and generate a funny one. > vedaal > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From mgorny at gentoo.org Tue May 12 07:31:06 2020 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Tue, 12 May 2020 07:31:06 +0200 Subject: Updating of Keys In-Reply-To: <89dce43a-7e99-5cd0-0cf8-d230f84081fd@gmx.com> References: <89dce43a-7e99-5cd0-0cf8-d230f84081fd@gmx.com> Message-ID: W dniu pon, 11.05.2020 o godzinie 17?22?-0700, u?ytkownik Mark napisa?: > Kinda of a stupid question here about updating your keys. I'm curious > as > to what changes would require you to re-upload it to a keyserver. > > I assume updating the passphrase would not because that is tied to > the > private key but does it change anything in the public key where that > might be require it to be updated? No, this does not change anything about the public key. > How about changing the expiration date of the primary and secondary > keys? I assume that would be needed to be updated to the keyserver. Yes, that adds new signatures to the key that need to be uploaded for new expiration dates to be seen by other people. > Which then brings me to another question, what happens when you > re-upload your key to a keyserver. Does it overwrite the older one or > ?? > This depends on the keyserver implementation. Generally, the new key gets merged into the old one. Sometimes the stale data is cleaned up, sometimes it remains. The same happens when you fetch updated key from the keyserver. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 642 bytes Desc: This is a digitally signed message part URL: From a at 0au.de Tue May 12 10:56:19 2020 From: a at 0au.de (Valentin Ochs) Date: Tue, 12 May 2020 10:56:19 +0200 Subject: Checking multiple smart cards before asking for one Message-ID: <20200512085619.GD24751@mileva> Hi there, I have two smart cards, a regular card that I plug into the builtin reader of my laptop and a yubikey, that have two different keys on them. I store some passwords in a file that is encrypted with both keys. When I try to access the passwords, pinentry will always ask me to insert the yubikey first, even if the other card is already inserted. Is there a way to define the order this is checked per machine (the laptop will usually use the card reader, other machines the yubikey), or to force gpg to check for all cards before asking me to provide one? I'm up for trying to patch this myself, if somebody will point me in a rough direction :) Cheers, Valentin From listofactor at mail.ru Tue May 12 11:46:13 2020 From: listofactor at mail.ru (LisToFacTor) Date: Tue, 12 May 2020 09:46:13 +0000 Subject: Fwd: The GnuPR FAQ In-Reply-To: <129a1392-0a0c-f527-0ec3-076222e2693d@sixdemonbag.org> References: <129a1392-0a0c-f527-0ec3-076222e2693d@sixdemonbag.org> Message-ID: On 5/11/20 10:11 PM, Robert J. Hansen - rjh at sixdemonbag.org wrote: > This arrived in my inbox: I'm presenting it here without comment. >> You've advised people to use a HORRIBLE practice of using dictionary >> words solely for their password. I tested this theory myself back in the >> day, so I can 100% guaranty you of this fact: A brute force dictionary >> based attack can crack a password like that in LESS THAN 5 minutes!! I >> once stretched that out to 20 minutes by cleverly picking words that I >> already knew were at the opposite ends of the dictionary. In order to discuss the feasibility of brute forcing a set of a few random dictionary words, we would have to agree on a few numbers: 1) how many words in the passphrase 2) how many words in a dictionary 3) how many dictionaries 4) how many slightly different forms can average word of the dictionary take due to the declension, conjugation and noun/adjective gender matching. This happens to be an English-only language mailing list, but very few users of this program speak (only) English. It always surprises me how contributors native-language-centric some Internet discussions on a technical subject that transgresses language borders are. Overall, the original suggestion in the FAQ is perfectly valid, and all I would add is point out the benefit of (3) and (4) above. From johanw at vulcan.xs4all.nl Tue May 12 11:24:57 2020 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 12 May 2020 11:24:57 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> Message-ID: <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> On 12-05-2020 3:46, Pete Stephenson via Gnupg-users wrote: > For example, a 256 bit elliptic curve key has a similar strength to a symmetric key of 128 bits. Until, of course, a working quantum computer with more than a few qubits is constructed. Then ECC is much more vulnerable than RSA or ElGamal due to its smaler keysize (of course once a 256 bit quantum computer gets constructed I would also worry about 8192 bit RSA being vulnerable too in the very near future). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From wiktor at metacode.biz Tue May 12 14:08:07 2020 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 12 May 2020 14:08:07 +0200 Subject: Checking multiple smart cards before asking for one In-Reply-To: <20200512085619.GD24751@mileva> References: <20200512085619.GD24751@mileva> Message-ID: <7b311c9c-8f0d-3a2b-6b40-f0b252ff806a@metacode.biz> Hi Valentin, I believe this will work seamlessly in GnuPG 2.3. You can track this ticket: https://dev.gnupg.org/T4695 Kind regards, Wiktor -- https://metacode.biz/@wiktor From a at 0au.de Tue May 12 14:21:49 2020 From: a at 0au.de (Valentin Ochs) Date: Tue, 12 May 2020 14:21:49 +0200 Subject: Checking multiple smart cards before asking for one In-Reply-To: <7b311c9c-8f0d-3a2b-6b40-f0b252ff806a@metacode.biz> References: <20200512085619.GD24751@mileva> <7b311c9c-8f0d-3a2b-6b40-f0b252ff806a@metacode.biz> Message-ID: <20200512122149.GE24751@mileva> Wiktor Kwapisiewicz [2020-05-12 14:08] wrote: > Hi Valentin, > > I believe this will work seamlessly in GnuPG 2.3. > > You can track this ticket: https://dev.gnupg.org/T4695 Hi Wiktor, thanks for the reply. That issue is indeed what initially prompted me to make a second key for the second card, but seems a bit different from my current use case - I have two completely different keys, but two card readers. Do you think that with that ticket resolved it will allow me to have either key available? Cheers, Valentin From kloecker at kde.org Tue May 12 16:38:41 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 12 May 2020 16:38:41 +0200 Subject: Checking multiple smart cards before asking for one In-Reply-To: <20200512085619.GD24751@mileva> References: <20200512085619.GD24751@mileva> Message-ID: <15290310.zXGmXr661u@breq> On Dienstag, 12. Mai 2020 10:56:19 CEST Valentin Ochs wrote: > Hi there, > > I have two smart cards, a regular card that I plug into the builtin reader > of my laptop and a yubikey, that have two different keys on them. I store > some passwords in a file that is encrypted with both keys. > > When I try to access the passwords, pinentry will always ask me to insert > the yubikey first, even if the other card is already inserted. > > Is there a way to define the order this is checked per machine (the laptop > will usually use the card reader, other machines the yubikey), or to force > gpg to check for all cards before asking me to provide one? I'm up for > trying to patch this myself, if somebody will point me in a rough direction Maybe you should optimize for what appears to be your usual scenario (laptop + card reader versus other machines + yubikey) and simply remove the yubikey key from the laptop and the card reader key from the other machines. If gpg only knows about one of the two keys, then it shouldn't ask for the wrong key. If you ever want to use the yubikey on the laptop, then you can simply (re-)import the yubikey key on the laptop. The downside is that this will make synchronization of ~/.gnupg between your laptop and the other machines more difficult. But then you really only need a single key per machine for decrypting your passwords, i.e. you could use dedicated GNUPG_HOMEs just for the encryption keys. Regards, Ingo From rjh at sixdemonbag.org Tue May 12 16:41:09 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 12 May 2020 10:41:09 -0400 Subject: Fwd: The GnuPR FAQ In-Reply-To: <20200511230019.C9334E0772@smtp.hushmail.com> References: <129a1392-0a0c-f527-0ec3-076222e2693d@sixdemonbag.org> <20200511230019.C9334E0772@smtp.hushmail.com> Message-ID: > Even using only English words greater than 5 letters and unrelated to > each other, an extremely low-bound estimate, would be 77760 words. > (in reality, far greater, but let's use an example people would agree > on). This is probably not the best metric. The length of the word is irrelevant: if one of your words is "zoo", that's no easier or harder to guess than "prolix" or "antediluvian". The words are all equally random. Much more important than length is memorability. "Coulrophobia" is a great word but I'd be looking up how to spell it all the time. You can get by just fine in most everyday English with a vocabulary of 5,000 words. Stick to those words and you'll have an easy-to-remember passphrase. Or, you know, learn coulrophobia, enhance your vocabulary, and get down with your clown-fearing self. It's up to you. :) From sylvain.besencon at unifr.ch Tue May 12 17:04:10 2020 From: sylvain.besencon at unifr.ch (=?UTF-8?Q?Sylvain_Besen=c3=a7on?=) Date: Tue, 12 May 2020 17:04:10 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> Message-ID: <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> Le 12.05.20 ? 11:24, Johan Wevers a ?crit?: > On 12-05-2020 3:46, Pete Stephenson via Gnupg-users wrote: > >> For example, a 256 bit elliptic curve key has a similar strength to a symmetric key of 128 bits. > > Until, of course, a working quantum computer with more than a few qubits > is constructed. Then ECC is much more vulnerable than RSA or ElGamal due > to its smaler keysize (of course once a 256 bit quantum computer gets > constructed I would also worry about 8192 bit RSA being vulnerable too > in the very near future). > Hi, In the FAQ, it is written: > Will GnuPG ever support RSA-3072 or RSA-4096 by default? > Probably not. The future is elliptical-curve cryptography, which will bring a level of safety comparable to RSA-16384. Every minute we spend arguing about whether we should change the defaults to RSA-3072 or more is one minute the shift to ECC is delayed. Frankly, we think ECC is a really good idea and we?d like to see it deployed as soon as humanly possible. (https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048) So, I guess the key size is not the only criteria to evaluate the strength of a cipher and ECC still provides better results despite shorter keys. However, I would be interested to know which ECC cipher would you recommend to replace RSA. I am not a cryptographer and I don't find any information (or more honestly: information that I can understand) about Curve 25519, NIST P-256 (and greater), Brainpool, or secp256k1. Thanks for the feedback, Best, Sylvain From sac at 300baud.de Tue May 12 18:41:27 2020 From: sac at 300baud.de (Stefan Claas) Date: Tue, 12 May 2020 18:41:27 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> Message-ID: <20200512184127.00001c28.sac@300baud.de> Sylvain Besen?on via Gnupg-users wrote: > Le 12.05.20 ? 11:24, Johan Wevers a ?crit?: > > On 12-05-2020 3:46, Pete Stephenson via Gnupg-users wrote: > > > >> For example, a 256 bit elliptic curve key has a similar strength > >> to a symmetric key of 128 bits. > > > > Until, of course, a working quantum computer with more than a few > > qubits is constructed. Then ECC is much more vulnerable than RSA or > > ElGamal due to its smaler keysize (of course once a 256 bit quantum > > computer gets constructed I would also worry about 8192 bit RSA > > being vulnerable too in the very near future). > > > > Hi, > > In the FAQ, it is written: > > Will GnuPG ever support RSA-3072 or RSA-4096 by default? > > Probably not. The future is elliptical-curve cryptography, which > > will bring a level of safety comparable to RSA-16384. Every minute > > we spend arguing about whether we should change the defaults to > > RSA-3072 or more is one minute the shift to ECC is delayed. > > Frankly, we think ECC is a really good idea and we?d like to see it > > deployed as soon as humanly possible. > (https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048) > > So, I guess the key size is not the only criteria to evaluate the > strength of a cipher and ECC still provides better results despite > shorter keys. > > However, I would be interested to know which ECC cipher would you > recommend to replace RSA. I am not a cryptographer and I don't find > any information (or more honestly: information that I can understand) > about Curve 25519, NIST P-256 (and greater), Brainpool, or secp256k1. I am no cryptographer either, but what I have observed is that most apps nowadays use djb's Curve 25519. secp256k1 could be interesting if you have a Bitcoin Wallet or use Bitmessage and want to use those GnuPG subkeys also for Bitcoin transactions[1], or for Bitmessage. [1] I once send Niibe-san (GnuPG dev.) some Satoshi to his Bitcoin address, which he has as GnuPG sec256k1 subkey. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From konstantin at linuxfoundation.org Tue May 12 18:48:44 2020 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Tue, 12 May 2020 12:48:44 -0400 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> Message-ID: <20200512164844.v3rmouw256hmbgm4@chatter.i7.local> On Tue, May 12, 2020 at 11:24:57AM +0200, Johan Wevers wrote: > > For example, a 256 bit elliptic curve key has a similar strength to > > a symmetric key of 128 bits. > > Until, of course, a working quantum computer with more than a few qubits > is constructed. Don't worry, there's literally trillions of dollars worth of bitcoins riding on the premise that this will never happen. ;) -K From gk at leniwiec.biz Tue May 12 19:27:04 2020 From: gk at leniwiec.biz (Grzegorz Kulewski) Date: Tue, 12 May 2020 19:27:04 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> Message-ID: W dniu 12.05.2020 o?17:04, Sylvain Besen?on via Gnupg-users pisze: > In the FAQ, it is written: >> Will GnuPG ever support RSA-3072 or RSA-4096 by default? >> Probably not. The future is elliptical-curve cryptography, which will bring a level of safety comparable to RSA-16384. Every minute we spend arguing about whether we should change the defaults to RSA-3072 or more is one minute the shift to ECC is delayed. Frankly, we think ECC is a really good idea and we?d like to see it deployed as soon as humanly possible. > (https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048) > > So, I guess the key size is not the only criteria to evaluate the strength of a cipher and ECC still provides better results despite shorter keys. > > However, I would be interested to know which ECC cipher would you recommend to replace RSA. I am not a cryptographer and I don't find any information (or more honestly: information that I can understand) about Curve 25519, NIST P-256 (and greater), Brainpool, or secp256k1. Disclaimer: I am not a cryptographer either, let's just say I am an advisor. So, anybody, please correct me, if needed. 1. In terms of key size Curve 25519 and P-256 should have same strength: ~128 bits (== comparing with good symmetric cipher, like AES). Generally decent ECC strength = ~0.5 * key_length_in_bits. 2. Curve 25519 is very easy to implement in such a way that the implementation is fast. Implementations of other curves are usually slower. 3. Curve 25519 is generally easier to implement and easier to implement in such a way that avoids many common security pitfalls, like vulnerability to timing attacks. 4. The design of Curve 25519 is public, (is believed to be) software patent free and all constants in it are derived in an easily explainable ways. There are no "magic numbers" out of nowhere that may be just random or maybe were chosen by designers to make some kind of backdoor - but you can never prove that they are innocent since obviously you can't prove that random number was indeed chosen truly randomly. 5. Curve 25519 was designed by DJB, an (mostly) independent security expert while others were designed/standardized by big organizations that (given indirect evidence and rumors) may not be that trustworthy. 6. This is why many new (and not only, see SSH) protocols tend to choose Curve 25519. But in PGP you should be careful because many implementations (and/or older versions) don't support it. So if you want portability/interoperability you may want some other curve or RSA, especially for the main and signing key. 7. If you want something stronger than Curve 25519 that (is believed to) share similar benefits try Curve 448 (~224 bits of security). But I am not sure if PGP implements it (yet?). -- Grzegorz Kulewski From johanw at vulcan.xs4all.nl Tue May 12 21:35:06 2020 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 12 May 2020 21:35:06 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> Message-ID: <68f045b1-f3cb-9f80-39ba-7e1c2898adca@vulcan.xs4all.nl> On 12-05-2020 17:04, Sylvain Besen?on via Gnupg-users wrote: >> Probably not. The future is elliptical-curve cryptography, which will >> bring a level of safety comparable to RSA-16384. Yes, if attacked by classical computers. > However, I would be interested to know which ECC cipher would you > recommend to replace RSA. None at all. I'd say probably one of these: https://en.wikipedia.org/wiki/Post-quantum_cryptography but I am no expert. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Tue May 12 22:29:28 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 12 May 2020 16:29:28 -0400 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> Message-ID: > However, I would be interested to know which ECC cipher would you > recommend to replace RSA. "Yes". :) Back when we got these questions -- Elgamal? RSA? DSA? Help? -- we used to tell people what mattered far, far more than which algorithm they used was how much care they gave to their system. Keep your system malware-free. Don't sign things willy-nilly without reading them first. Be careful who you share your system with. Etcetera. I have never ever heard of a cryptographic break against OpenPGP. I've seen people be careless many times. I'm far more worried about that than I am which algorithm you use. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From fsantiago at garbage-juice.com Tue May 12 23:30:24 2020 From: fsantiago at garbage-juice.com (=?utf-8?q?fsantiago=40garbage-juice=2Ecom?=) Date: Tue, 12 May 2020 17:30:24 -0400 Subject: Question / sync keyrings between devices Message-ID: <7F6F65D3-386B-4C4A-AA05-38EC48691F7F@garbage-juice.com> Question, Is there anything out there, think bittorrent-sync, that allows for syncing your full keyring between devices? Would it be enough to simply use bittorrent-sync to sync your .gnupg folder? I get the ?export / ?import but what about automating it a lil? bit? Something peer to peer preferably. Sent from my iPhone From vedaal at nym.hush.com Wed May 13 03:36:17 2020 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 12 May 2020 21:36:17 -0400 Subject: Fwd: The GnuPR FAQ Message-ID: <20200513013618.227CB40654@smtp.hushmail.com> Robert J. Hansen rjh at sixdemonbag.org wrote on Tue May 12 16:41:09 CEST 2020: >You can get by just fine in most everyday English with a vocabulary of >5,000 words. Stick to those words and you'll have an easy-to-remember >passphrase. ===== That's absolutely correct, Horse! Battery Staple https://xkcd.com/936/ 8^) vedaal From sylvain.besencon at unifr.ch Wed May 13 10:02:14 2020 From: sylvain.besencon at unifr.ch (=?UTF-8?Q?Sylvain_Besen=c3=a7on?=) Date: Wed, 13 May 2020 10:02:14 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> Message-ID: Le 12.05.20 ? 19:27, Grzegorz Kulewski a ?crit?: > Disclaimer: I am not a cryptographer either, let's just say I am an advisor. So, anybody, please correct me, if needed. > > 1. In terms of key size Curve 25519 and P-256 should have same strength: ~128 bits (== comparing with good symmetric cipher, like AES). Generally decent ECC strength = ~0.5 * key_length_in_bits. > 2. Curve 25519 is very easy to implement in such a way that the implementation is fast. Implementations of other curves are usually slower. > 3. Curve 25519 is generally easier to implement and easier to implement in such a way that avoids many common security pitfalls, like vulnerability to timing attacks. > 4. The design of Curve 25519 is public, (is believed to be) software patent free and all constants in it are derived in an easily explainable ways. There are no "magic numbers" out of nowhere that may be just random or maybe were chosen by designers to make some kind of backdoor - but you can never prove that they are innocent since obviously you can't prove that random number was indeed chosen truly randomly. > 5. Curve 25519 was designed by DJB, an (mostly) independent security expert while others were designed/standardized by big organizations that (given indirect evidence and rumors) may not be that trustworthy. > 6. This is why many new (and not only, see SSH) protocols tend to choose Curve 25519. But in PGP you should be careful because many implementations (and/or older versions) don't support it. So if you want portability/interoperability you may want some other curve or RSA, especially for the main and signing key. > 7. If you want something stronger than Curve 25519 that (is believed to) share similar benefits try Curve 448 (~224 bits of security). But I am not sure if PGP implements it (yet?). > Hello, Thank you all for your quick answers, it is very useful! RJH's answer sounds like a good piece of advice, but still, at the end, we HAVE to to choose which algorithm to use when creating new key pairs. This doesn't prevent me to (try to) be cautious about the general health of my system. Grzegorz's points convince me to give a try to Curve 25519. I have another though: > But in PGP you should be careful because many implementations (and/or older versions) don't support it. So if you want portability/interoperability you may want some other curve or RSA, especially for the main and signing key. I am not sure to fully grasp the consequences of this... Does that mean that, if I use Curve 25519, some people won't be able to use my public key to encrypt stuff? Or does that mean that some people won't be able to read or verify stuff that I encrypt and signs? Would it be because they use older versions or because some software programs don't implement Curve 25519? I guess that Curve 25519 is mentioned in the IETF standard, isn't it? Many thanks, Best, Sylvain From dgouttegattat at incenp.org Wed May 13 11:54:12 2020 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 13 May 2020 10:54:12 +0100 Subject: Comparison of RSA vs elliptical keys In-Reply-To: References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> Message-ID: <20200513095412.zx4rou7uehosnflx@dynein.local.incenp.org> On Wed, May 13, 2020 at 10:02:14AM +0200, Sylvain Besen?on via Gnupg-users wrote: >RJH's answer sounds like a good piece of advice, but still, at the end, >we HAVE to to choose which algorithm to use when creating new key >pairs. No you don?t. You can simply use `gpg --gen-key` and let GnuPG create a keypair with the default algorithm (which is currently RSA 2048). Only if you call GnuPG with the `--full-gen-key` command will you be asked to explicitly choose which type of key of want. >I am not sure to fully grasp the consequences of this... Does that mean >that, if I use Curve 25519, some people won't be able to use my public >key to encrypt stuff? If their software does not support Curve 25519, yes. >Or does that mean that some people won't be able to read or verify >stuff that I encrypt and signs? You encrypt messages to your correspondants with *their* public keys, so the type of *your* key does not matter for that purpose. But they won?t be able to verify your signatures. >Would it be because they use older versions or because some software >programs don't implement Curve 25519? Yes. That being said, most modern implementations do seem to support curve 25519. As far as I know, it is supported at the very least by * GnuPG (? 2.1) * OpenPGP.js * Sequoia-PGP * RNP ? which should already cover most of the OpenPGP user base. Of note, it is *not* supported by Symantec PGP, though [1]. >I guess that Curve 25519 is mentioned in the IETF standard, isn't it? Not yet. Officially, only the NIST P-256, P-384, and P-521 curves are part of the standard (since RFC 6637). The first mention of Curve 25519 for OpenPGP was in a draft by Werner in 2014 [2]. The draft never made it to a RFC but the 25519 curve is now part of the draft for RFC4880bis, the next revision of the OpenPGP standard [3]. - Damien [1] https://knowledge.broadcom.com/external/article/175932/encryption-desktop-cannot-import-ecc-pgp.html [2] https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-00 [3] https://gitlab.com/openpgp-wg/rfc4880bis -------------- 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 Wed May 13 12:18:36 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 13 May 2020 06:18:36 -0400 Subject: Comparison of RSA vs elliptical keys In-Reply-To: References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> Message-ID: <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> > RJH's answer sounds like a good piece of advice, but still, at the end, > we HAVE to to choose which algorithm to use when creating new key pairs. rjh at maggie:~$ gpg --gen-key gpg: WARNING: using experimental features from RFC4880bis! Note: Use "gpg --full-generate-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: Delete Me Email address: delete at example.org You selected this USER-ID: "Delete Me " Change (N)ame, (E)mail, or (O)kay/(Q)uit? o We need to generate a lot of random bytes. It is a good idea... [snip] Where in there was I ever asked to choose an algorithm? "Unless you know what you're doing and why, use the defaults." I've been saying that for twenty years now. I keep thinking that someday someone will actually take it seriously... From sac at 300baud.de Wed May 13 15:09:43 2020 From: sac at 300baud.de (Stefan Claas) Date: Wed, 13 May 2020 15:09:43 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> Message-ID: <20200513150943.00001d15.sac@300baud.de> Robert J. Hansen wrote: > > RJH's answer sounds like a good piece of advice, but still, at the > > end, we HAVE to to choose which algorithm to use when creating new > > key pairs. > > rjh at maggie:~$ gpg --gen-key > gpg: WARNING: using experimental features from RFC4880bis! > Note: Use "gpg --full-generate-key" for a full featured key generation > dialog. > > GnuPG needs to construct a user ID to identify your key. > > Real name: Delete Me > Email address: delete at example.org > You selected this USER-ID: > "Delete Me " > > Change (N)ame, (E)mail, or (O)kay/(Q)uit? o > We need to generate a lot of random bytes. It is a good idea... > > [snip] > > Where in there was I ever asked to choose an algorithm? In older versions, like 2.0.x for example, it asked for ... > "Unless you know what you're doing and why, use the defaults." I've > been saying that for twenty years now. I keep thinking that someday > someone will actually take it seriously... Super modern OpenPGP implementations like the super awesome sequoia pgp defaults to cv25519... (and does not need to generate a UID for privacy reasons, simply fantastic!) Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From sylvain.besencon at unifr.ch Wed May 13 15:30:12 2020 From: sylvain.besencon at unifr.ch (=?UTF-8?Q?Sylvain_Besen=c3=a7on?=) Date: Wed, 13 May 2020 15:30:12 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> Message-ID: Le 13.05.20 ? 12:18, Robert J. Hansen a ?crit?: > "Unless you know what you're doing and why, use the defaults." I've > been saying that for twenty years now. I keep thinking that someday > someone will actually take it seriously... > Thanks for the demonstration! At least, I will now know what I am doing when I'll use the defaults! :) Sylvain From sylvain.besencon at unifr.ch Wed May 13 15:34:54 2020 From: sylvain.besencon at unifr.ch (=?UTF-8?Q?Sylvain_Besen=c3=a7on?=) Date: Wed, 13 May 2020 15:34:54 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200513095412.zx4rou7uehosnflx@dynein.local.incenp.org> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <20200513095412.zx4rou7uehosnflx@dynein.local.incenp.org> Message-ID: <04421b8e-db2c-d1e8-4424-bc18791cb466@unifr.ch> Le 13.05.20 ? 11:54, Damien Goutte-Gattat a ?crit?: > On Wed, May 13, 2020 at 10:02:14AM +0200, Sylvain Besen?on via > Gnupg-users wrote: >> RJH's answer sounds like a good piece of advice, but still, at the >> end, we HAVE to to choose which algorithm to use when creating new key >> pairs. > > No you don?t. > > You can simply use `gpg --gen-key` and let GnuPG create a keypair with > the default algorithm (which is currently RSA 2048). Only if you call > GnuPG with the `--full-gen-key` command will you be asked to explicitly > choose which type of key of want. > > >> I am not sure to fully grasp the consequences of this... Does that >> mean that, if I use Curve 25519, some people won't be able to use my >> public key to encrypt stuff? > > If their software does not support Curve 25519, yes. > > >> Or does that mean that some people won't be able to read or verify >> stuff that I encrypt and signs? > > You encrypt messages to your correspondants with *their* public keys, so > the type of *your* key does not matter for that purpose. But they won?t > be able to verify your signatures. > > >> Would it be because they use older versions or because some software >> programs don't implement Curve 25519? > > Yes. That being said, most modern implementations do seem to support > curve 25519. As far as I know, it is supported at the very least by > > * GnuPG (? 2.1) > * OpenPGP.js > * Sequoia-PGP > * RNP > > ? which should already cover most of the OpenPGP user base. Of note, it > is *not* supported by Symantec PGP, though [1]. > > >> I guess that Curve 25519 is mentioned in the IETF standard, isn't it? > > Not yet. Officially, only the NIST P-256, P-384, and P-521 curves are > part of the standard (since RFC 6637). The first mention of Curve 25519 > for OpenPGP was in a draft by Werner in 2014 [2]. The draft never made > it to a RFC but the 25519 curve is now part of the draft for RFC4880bis, > the next revision of the OpenPGP standard [3]. > > > - Damien > > [1] > https://knowledge.broadcom.com/external/article/175932/encryption-desktop-cannot-import-ecc-pgp.html > > > [2] https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-00 > > [3] https://gitlab.com/openpgp-wg/rfc4880bis Thanks a lot for all these explanations. It's very useful and instructive. I appreciate your patience towards my dummy questions..! :) From sac at 300baud.de Wed May 13 19:39:31 2020 From: sac at 300baud.de (Stefan Claas) Date: Wed, 13 May 2020 19:39:31 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200512164844.v3rmouw256hmbgm4@chatter.i7.local> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <20200512164844.v3rmouw256hmbgm4@chatter.i7.local> Message-ID: <20200513193931.000066dc.sac@300baud.de> Konstantin Ryabitsev wrote: > On Tue, May 12, 2020 at 11:24:57AM +0200, Johan Wevers wrote: > > > For example, a 256 bit elliptic curve key has a similar strength > > > to a symmetric key of 128 bits. > > > > Until, of course, a working quantum computer with more than a few > > qubits is constructed. > > Don't worry, there's literally trillions of dollars worth of bitcoins > riding on the premise that this will never happen. ;) Who knows, maybe in the future it is possible for researchers/companies etc. to build cheaper and easier to produce alternatives? https://www.nature.com/articles/d41586-019-02742-x Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From vesely at tana.it Thu May 14 09:56:29 2020 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 14 May 2020 09:56:29 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200513095412.zx4rou7uehosnflx@dynein.local.incenp.org> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <20200513095412.zx4rou7uehosnflx@dynein.local.incenp.org> Message-ID: <17aa0c35-f1e2-f4ee-c820-6cda58f619d8@tana.it> On Wed 13/May/2020 11:54:12 +0200 Damien Goutte-Gattat via Gnupg-users wrote: > On Wed, May 13, 2020 at 10:02:14AM +0200, Sylvain Besen?on via Gnupg-users wrote: > >> I guess that Curve 25519 is mentioned in the IETF standard, isn't it? > > Not yet. Officially, only the NIST P-256, P-384, and P-521 curves are part of > the standard (since RFC 6637). The first mention of Curve 25519 for OpenPGP was > in a draft by Werner in 2014 [2]. The draft never made it to a RFC but the > 25519 curve is now part of the draft for RFC4880bis, the next revision of the > OpenPGP standard [3]. However, its signing flavor, Ed25519, is described in RFC 8032: This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. https://tools.ietf.org/html/rfc8032 Its use is standardized for DKIM signatures by RFC 8463. Best Ale -- > > [2] https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-00 > > [3] https://gitlab.com/openpgp-wg/rfc4880bis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu May 14 21:43:14 2020 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 May 2020 21:43:14 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200513095412.zx4rou7uehosnflx@dynein.local.incenp.org> (Damien Goutte-Gattat via Gnupg-users's message of "Wed, 13 May 2020 10:54:12 +0100") References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <20200513095412.zx4rou7uehosnflx@dynein.local.incenp.org> Message-ID: <87wo5e9ub1.fsf@wheatstone.g10code.de> On Wed, 13 May 2020 10:54, Damien Goutte-Gattat said: > Not yet. Officially, only the NIST P-256, P-384, and P-521 curves are > part of the standard (since RFC 6637). The first mention of Curve RFC-6637 allows for arbitrary curves because curves are specified using an ASN.1 OID. So for example the Brainpool curves can as well be used. The problem is similar to using RSA (which was optional in the old OpenPGP specs) or to use large RSA keys or even RSA keys which odd lengths on which some implementations choke. For a public key algorithm we unfortunately can't use the preference system. The worst thing which can happen to a user is that they can't verify a signature or encrypt to a key. But there are no backward compatibility issues related to data etc. > 25519 for OpenPGP was in a draft by Werner in 2014 [2]. The draft > never made it to a RFC but the 25519 curve is now part of the draft For Ed25519 we actually added a new algorithm id so that it is indeed not covered by RFC-6637. Anyway, the two Curve22519 algorithms (ed25519 for signing, and cv25519 for encryption) are available in GnuPG as "future-default". Given that older GnuPG versions reached end-of-life 2.5 years ago I consider it okay to change the default and create new keys using ed25519/cv25519. GnuPG master, which will eventually be 2.3, uses them as default. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu May 14 21:48:43 2020 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 May 2020 21:48:43 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200513150943.00001d15.sac@300baud.de> (Stefan Claas's message of "Wed, 13 May 2020 15:09:43 +0200") References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> Message-ID: <87sgg29u1w.fsf@wheatstone.g10code.de> On Wed, 13 May 2020 15:09, Stefan Claas said: > defaults to cv25519... (and does not need to generate a UID for privacy > reasons, simply fantastic!) And willfully violating the the standard. Not requiring a user id was bug in PGP 2 and fixed more than 25 years about with PGP 2.6.3in. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Thu May 14 23:01:26 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 14 May 2020 23:01:26 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <87sgg29u1w.fsf@wheatstone.g10code.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> Message-ID: <20200514230126.00001289.sac@300baud.de> Werner Koch wrote: > On Wed, 13 May 2020 15:09, Stefan Claas said: > > > defaults to cv25519... (and does not need to generate a UID for > > privacy reasons, simply fantastic!) > > And willfully violating the the standard. Not requiring a user id was > bug in PGP 2 and fixed more than 25 years about with PGP 2.6.3in. With all due respect, do you think when Hagrid and even good old SKS key servers supports this feature that people would not applaud you if you would consider including it in GnuPG too and reflecting it in the respective RFC? At least, the 'P' in OpenPGP and in the name GnuPG stands for privacy. :-) Best regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From rjh at sixdemonbag.org Thu May 14 23:23:00 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 14 May 2020 17:23:00 -0400 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200514230126.00001289.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> Message-ID: > With all due respect, do you think when Hagrid and even good old SKS > key servers supports this feature that people would not applaud you if > you would consider including it in GnuPG too and reflecting it in the > respective RFC? Speaking for myself, I have "rfc4880" in my gpg.conf for damned good reasons. I *do not* want GnuPG to generate UID-less certificates in strict compliance mode, I *do not* want GnuPG to use them in strict compliance mode. I have no opinion on "--allow-broken-certificates" and only allowing them to be generated in expert mode after a clear warning about it being noncompliant. I also think this is the wrong place to talk about how the RFC should be changed. Take it to the WG, please. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Fri May 15 00:41:00 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 15 May 2020 00:41:00 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> Message-ID: <20200515004100.00005d5c.sac@300baud.de> Robert J. Hansen wrote: > > With all due respect, do you think when Hagrid and even good old SKS > > key servers supports this feature that people would not applaud you > > if you would consider including it in GnuPG too and reflecting it > > in the respective RFC? > > Speaking for myself, I have "rfc4880" in my gpg.conf for damned good > reasons. > > I *do not* want GnuPG to generate UID-less certificates in strict > compliance mode, I *do not* want GnuPG to use them in strict > compliance mode. > > I have no opinion on "--allow-broken-certificates" and only allowing > them to be generated in expert mode after a clear warning about it > being noncompliant. When you work in compliance mode it should be IHMO possible that people wishing to communicate with you (from foreign countries) and may have a different opinion about privacy, GnuPG should accept such public keys, without using extra parameters and that you can easily add them to your key ring, with a simple label, thus not revealing the identity of them, in case your computer or smartphone gets later compromised or is searched at an airport etc. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From andrewg at andrewg.com Fri May 15 00:51:14 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 14 May 2020 23:51:14 +0100 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200515004100.00005d5c.sac@300baud.de> References: <20200515004100.00005d5c.sac@300baud.de> Message-ID: > On 14 May 2020, at 23:42, Stefan Claas wrote: > > When you work in compliance mode it should be IHMO possible that people > wishing to communicate with you (from foreign countries) and may have a > different opinion about privacy, GnuPG should accept such public keys, > without using extra parameters and that you can easily add them to your > key ring, with a simple label, thus not revealing the identity of them, > in case your computer or smartphone gets later compromised or is > searched at an airport etc. So your device is compromised by the feds and you?re worried about your gpg keyring leaking contact information, but not your inbox or your address book? And how does your encryption system work if it doesn?t maintain a mapping between email IDs and keys? I?m not convinced this threat model has been fully thought through. A From sac at 300baud.de Fri May 15 02:05:00 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 15 May 2020 02:05:00 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <665264269.20200515005157@mail.riseup.net> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> Message-ID: <20200515020500.00001ba5.sac@300baud.de> MFPA wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi > > > On Thursday 14 May 2020 at 11:41:00 PM, in > , Stefan Claas wrote:- > > > > > GnuPG should accept > > such public keys, > > without using extra parameters and that you can > > easily add them to your > > key ring, with a simple label, thus not revealing the > > identity of them, > > in case your computer or smartphone gets later > > compromised or is > > searched at an airport etc. > > Does that mean the "simple label" doesn't identify whose key it is? Or > have I misunderstood? It simply says that you can assign to such a label whatever you like, say a nickname or whatever. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From sac at 300baud.de Fri May 15 02:07:35 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 15 May 2020 02:07:35 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: References: <20200515004100.00005d5c.sac@300baud.de> Message-ID: <20200515020735.000032f8.sac@300baud.de> Andrew Gallagher wrote: > > > On 14 May 2020, at 23:42, Stefan Claas wrote: > > > > When you work in compliance mode it should be IHMO possible that > > people wishing to communicate with you (from foreign countries) and > > may have a different opinion about privacy, GnuPG should accept > > such public keys, without using extra parameters and that you can > > easily add them to your key ring, with a simple label, thus not > > revealing the identity of them, in case your computer or smartphone > > gets later compromised or is searched at an airport etc. > > So your device is compromised by the feds and you?re worried about > your gpg keyring leaking contact information, but not your inbox or > your address book? And how does your encryption system work if it > doesn?t maintain a mapping between email IDs and keys? I?m not > convinced this threat model has been fully thought through. Good question! First of all I do not keep an address book on my computer nor on my smartphone and I use not only simple smpts channels. Regarding the mapping of email IDs and keys. When I use labels for my keys, in my keyring, it contains only simple stuff like a nickname for example, because the peoples email addresses I know also without using GnuPG, hence I use command line mode and no common plug-ins. I do not say that people should follow this procedure, but like I previously said GnuPG should allow such an option. I am also used to use other communication channels, beside standard smpts, where this works too. I don't know if you, for example, knows RSA public key encryption before PGP was invented. There was no such things like key-IDs email mappings etc. and people lived with it, while using email. If you check out GitHub, GitLab etc. for public key encryption software you will rarely find tools, if any, which use the same email, key-ID mapping approach GnuPG uses. and people do not complain about it. And last but not least, GnuPG is a very flexible tool with many many command line parameters, so why not allow this option too for users, wishing to use UID-less public keys? I see no harm in it, only an enrichment in it's feature set. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From sac at 300baud.de Fri May 15 02:22:53 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 15 May 2020 02:22:53 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200515020500.00001ba5.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200515020500.00001ba5.sac@300baud.de> Message-ID: <20200515022253.0000632c.sac@300baud.de> Stefan Claas wrote: > MFPA wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Hi > > > > > > On Thursday 14 May 2020 at 11:41:00 PM, in > > , Stefan Claas wrote:- > > > > > > > > > GnuPG should accept > > > such public keys, > > > without using extra parameters and that you can > > > easily add them to your > > > key ring, with a simple label, thus not revealing the > > > identity of them, > > > in case your computer or smartphone gets later > > > compromised or is > > > searched at an airport etc. > > > > Does that mean the "simple label" doesn't identify whose key it is? > > Or have I misunderstood? > > It simply says that you can assign to such a label whatever you like, > say a nickname or whatever. Sorry, and this label is assigned to public keys of course. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From 2017-r3sgs86x8e-lists-groups at riseup.net Fri May 15 01:51:57 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Fri, 15 May 2020 00:51:57 +0100 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200515004100.00005d5c.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> Message-ID: <665264269.20200515005157@mail.riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 14 May 2020 at 11:41:00 PM, in , Stefan Claas wrote:- > GnuPG should accept > such public keys, > without using extra parameters and that you can > easily add them to your > key ring, with a simple label, thus not revealing the > identity of them, > in case your computer or smartphone gets later > compromised or is > searched at an airport etc. Does that mean the "simple label" doesn't identify whose key it is? Or have I misunderstood? - -- Best regards MFPA Maybe YOU have nothing to hide; that still leaves plenty you want to hide from! -----BEGIN PGP SIGNATURE----- iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl692adfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 MEM4NjI4RDU5MkZGOENERThCQjBCRkUwRTJERUUxRDZDOEVFRkHNeiYAmQINBFmF 3poBEACjmnBUOd79vOc6sywdw7d85ItYQDeSh5WhTguXkt84+8C+oLXYbWelVmyj tZ+vOsZSXb44tE2zNCWouNK/wcE16JmmIV3VVn9I/EpMTK/iFx3e/SGk6C56uopg sQFlDjbYRZ6bPc+ImsEdfaj3DyYrWJO3dCEBEEOv4/u7UZ/ulBJOEW4pCJjgk7es mT9LmG0AvSSUZhZQqqMo5wvrfz07uDbJ6MFjPXgBIThtJPjKSpTXCaaCs2GJZVkK agR1rexytIgsEU3OYHAl+qYfHqcFqa1xbrdEjC8RDFIU0vJc3aGpRufGEVlnDw/L fWN6qX4NE9IC/QyKFXEQOybP9UEl9ti/dE6FUSHT+g/M4zCdSL1RFMkz91/Unjgr ZAboMoKgBZqYLpawjYIyVMYTdIerDQYiymCdD+Ifkgc3FwgTsfSFnFJXwLL2hqJG oZSz6jHKKiDDKathLQqWEvAbCo6FP5VsqILi2Tu+6IWOeLp07YXzDiDNR7/yqDGO CavYmwN3mt5TwdNeOd22LFWHLBcsDc5gIB2EkJoMpemG1TJi60FX9P2WI8K7ICBm FzwnvH9i2xBln+4+YDHyod7clC1I0wE2BbO6ttNaUR/6Xczm8gjx0zzKsvOZZDTX jXtO8ss41j7Rg0TS3C4+QWMcmHCJCiu8tD4GS5du/V5xw8TJ8QARAQABtBIweEFD RTU2OTcxRDU1NURBQTWJAl4EEwEKAEgCGwECHgECF4ACGQELCw0JCAwHAwsKBAIG FQoJCAsDBRYDAgEAFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGFwFCQnQtEIA CgkQrOVpcdVV2qU6AQ/9EaAae++qSxy9iM2a3Jfbqr5kEV+mJ//r6SIoDJPVANfb 5oHF/KZtF0a+SXR+cPPBMVKsppZ0Qr80FkjAUOH5YuUbTq2B+YvqMo5DLqBa2QiC ax6x11udSI0IM2CL7I5vMcRuY+Z/P3FZ9RI+C7ALL+EgJ6xtFyYHOcVVYd/a0O/O TH9KOVwcdtDChrRZBOC46+5hlcFxd3nwMUmXpRD1PE5+20vUbmyz2uKjHn93fOh2 MNMLhoO9qci+kKliawuU7UQ42VTO6FtUSoUpgPh37sVMImezC4jYm/1d3AFPCxpA jP7mHgKxOwP6fw+hIEWoybv0Ws3BEhM4TInobQUs0wdsWLQ83x5L9IvEcL643mkL bxCA48Fiw2YTWyuEdhIeSOtLTrM2k5xDVX5kPASGqG7rTP/exBo5Vg2UZWhPJuiE fYaJR7PAl0i+318yQShIWg0Zt1Ob3K7/3yqvHDFzaAaKOlN9CZR5XVEcyq9G6M2u u5cOZ0LQJTn/UFHYOK8D9/T33Zfac8tIjiIn916i1YvqYIzS14GKS8oqISy3FkD3 2tQf8ok/8PvnXe1xQPTAtIj3UqpiQf0L8xt96hLJHKphmR/ksKYBDdZFWRD/U0Na kXjnepP0ek68fR3wO4lbYKG9x94YDM/7pQ1BpfZZMLrp+3xvTBxmgQCtAuUiJem5 Ag0EWYXwgAEQAO+wh3g3SgeBWkzLaIHo3p7Z92CyEnssgvZnfaWNBowuv1INtprq a15yRpaIr8eFlchlVqCiQ2FN54tWkND5qlallwi2YSUW+nkEXCvyUR1S///MmwI5 qos0A+Sil3uPsuBQtRezCaNEghM5a83Lfvv9kYqzfa9D6gCYUCv6NtbH/yeshOuR hT2P3jFK0+kIObyPO26XsbfdbocutYA3c/27TAsE8VJvu4yqL5CUvz5H+EzGAdmr XVYD/VFxMrbIkKjmb7I0Tnl8RF3IUsL3SK/AKWYPOI4mMp5dv4yO/gYVoWX5Fd4d v6EQmvHMfiIvsxP8EBOTNVEtj/rac4P7Trdsc7CWsL5zzpofxIFQibo3JVNTRs/P PIlVmPROYLbXaolufgAmi+E8BCer780yc4nkmWOEcepuk3cQCM3l6OrgI8aWQyrc f4uW4Jtn98AldJ21PhtN4A0d5PF0YvX/OrXoi3XBROUVLY6IF5QbkSMeOvqJWzgk txvULI53Q3jtZvgtmF2dZ5rFgJCy3PjuXRBi2ZTz47eW94E7xDr04euhFnyMaiDM KS0XAj978kyCUrtDsssWp83j1IZt5Bd7JmtohThlEZCQ3Y0u3Gjmj9Nkv18qmF8O 21Qe0LzG8Ad9HPTbQd9Rk+GQz57WxlcsjK2bC0WG7f6R5BHq1YmuoD8nABEBAAGJ AjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb74QAK CRCs5Wlx1VXapXcrD/9ktCowTIi5PtKUCjuttsaZzVRnAeTee3WvPJwbrFR7L3Jk x3OM1KeSni+YsAfBrLi7xag4IIt8alQ6cYww2/q1aFPrs6opl2ou6NLxM4ynxkV8 Gb2kqiwUVlf5QFUVJOoNeVwoiNelklUj5jGq3KZGqhq4OSC5fkcCtOsjOffWWD1Y ACZL4aHrxUM/njHq8k+WBNocYtdmbFH8Iujzf27tsV8b0yIKGs6L5jjkFpSDQo+/ jiGafLVsddu9TeZr9Jm7OGo/u6q8ozCxaTg/G7fLF9DGrj1+AakN9sujxRgXkccI znci5qPW0dzOzhVUcaVPDdhfv/O3RXbky2qMSk+uxB5drqJ7LbOkPVTbDadspla8 2oJw3OoWuR0uC0aK7eibuFlurms6CcG/UQYQv9cjS4wGVe44S6/wiUBjfJXT3ITo rl38PcBigpF0XYWk2FAdE40xPN3REKv2Byulmjnc3ia2R+zBWuPg30LsQtFWgiwN tYJ5n/J08Ek+gqA6lNX9pRKT8lq6RQgQrvir7d/9Zw+RGaaVB1EnBUJi49O0Sfqs voFLstR1XnlhQubkhk5jhZ582Pug6K2H3b9sgU5ycTaWSEBr1B0AbvIetF5qO+pJ Y/vT452Br2g6CKXSpS2y6wwcqC0e/dkB31uFl1s4fRUmGxmBXnK4GFu/ufjNzrgz BFmF9HQWCSsGAQQB2kcPAQEHQIvVCKWPutMpY7ED7YDL8qev9tgCb5RSXPkzirJJ WjDZiQKzBBgBCgAmAhsCFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGK8FCQhD yzoAgXYgBBkWCAAdFiEElgyGKNWS/4zei7C/4OLe4dbI7voFAlmF9HQACgkQ4OLe 4dbI7vpdcAEA2GBaDiUbWapujHFGfh/a3MH1mXU/7Vrf+6aCBSoqwlABAOlljw5f 6gCnD6b8LjBIsS2W/U5jTtAt1aouzFDvhioICRCs5Wlx1VXapcvPD/0bteHRI4dW 3r4XqFKKVbKsc6gRaQRfUOZq3L0Pcadx0BoJorjnzCRY1KytAqyAjYH2ossd10Fm MLL5RTkNBvdcWTD6ZKIJQICEu0o2BJcPzKXVB2pJNsHJSMQyhAqbgUKfnePJza+4 p80PL6eBWttufKcNtJwYgkTJhchKoa+Se2h2mt53v6jdIusKwM91dW+0U5E6Jkom v3CKsSSsWIh8F5OpPJVz7/+2lThO2NOzLth762cV+yqsPGr9Dr9zsCkiIhRfr7hj 2L4AxO0ljYzd6FuR17WSvqHx3x2Sz8D2B5HxNQ0o6wxlnH3AlEti6/zSTtc0+AOx nOTZwj/CPQrly4MP8fNbhjOVNoLcfyq4u2/HB843/IWv+S7rob6qHF3rJ49Ltl8+ nsUJ2JKBUue9L5RnEPgIHuuFwDXp9XRXoj0+s2W2N0IScpYFj0HRW9/0NV3pn+t3 C2L5aCiCFSX9Ueg42RoPQR8szYyrhpmLVdNkuTSX5l86RLVMNw8ncuhpHvClOoRM REjLwYgf9g7T3kygf97LzAjlPSVcAw98HkdEV+h5V6AqOJkHNXfRHPiCLglF0S24 ePGprxeIN8ufmOdkdkpH91RhQRybVOtyQdrgIPnpBFBaFMfV0sDb+DcSx7hvYgHW kJqXDu2iDN2W3ZySYVrR/yLkuuawf9Lpcbg4BFmF99oSCisGAQQBl1UBBQEBB0CC RNDhUo58xjQ/zW1Kebdb8evrP6QU27xuMfpj0WRRfwMBCAeJAjwEGAEKACYCGwwW IQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb0hwAKCRCs5Wlx1VXapSc0 D/9JxkCkLkyOYx+rnOUugdwfQ7kRuUVkxLIIxf0UwEf9B2fsxEDIJJJO9DJOBnGt FHLI0k6nxCsk6QNz8TIpBGx1oH8k17gJgmQuZHED+xQBYbAx3G3Kj5jIj9oCnFJd P3ADM+Dzgwvm4hUuRD2gLEIwC0dpcPu+g2gQ+jRG9Gl3NT6qC6mvp2w7P0hW8+7o 7oZN5T2Lpi5s86yMuaoUlItj6a4Cjg4xJdTBHstJTWGfvclobVaxoas1udf/TzFN A6FUFQpRsgqymPS7MOK6GaQgvctT9/fP6jUwydhheDwYiFQzWaNaCjGfNq6/QlIm DQryAuWV7mWknygKR4uaqem48vhaea9XBMdghunv4tp/4fVELe0DDdV6D99cwvB+ 27gu3UlE0bz2gNq24IBq6Ew0jsKu0vTOyyiR49MEqjgdQna0CScO5fHv2DnJmYnC f1S5g36mlWm8HG3XM1OHizdjcB4hcSs9ETWYi1W5f0nZ94rv+BgZ6J+MOBybtfkx b1jYpf7rTx6bJbHQuYad879Sts5u6Ya36cRE/D7nHgSasxL5Kekr0eBM5EuGXQIN YlQItw0yfrM9NUgfePqZumNrrkxjqxcsh0aBJROm1FW6RSa4KnnIQNRu5jAWM7Md +aQQEj/YdJgS6uLzteKZBwUEe7jqNmTRtevMZtln9JNjcwAKCRDg4t7h1sju+hI7 AP9qkaDeJL+sLKrNECYHX85Eeyrv5ppLFLc84OZBbEXviQEAgQzCkKlp5/ifZ7MH fs1i2EZUaf89nRVMAQwuu3PrMwKJFGkEAQEKElMWIQRSX6konxd5jbM7JygTDfUW ES/A/wUCXr3Zp18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdw LmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMwREY1 MTYxMTJGQzBGRtEUJgCZAg0EWYXemgEQAKOacFQ53v285zqzLB3Dt3zki1hAN5KH laFOC5eS3zj7wL6gtdhtZ6VWbKO1n686xlJdvji0TbM0Jai40r/BwTXomaYhXdVW f0j8SkxMr+IXHd79IaToLnq6imCxAWUONthFnps9z4iawR19qPcPJitYk7d0IQEQ Q6/j+7tRn+6UEk4RbikImOCTt6yZP0uYbQC9JJRmFlCqoyjnC+t/PTu4NsnowWM9 eAEhOG0k+MpKlNcJpoKzYYllWQpqBHWt7HK0iCwRTc5gcCX6ph8epwWprXFut0SM LxEMUhTS8lzdoalG58YRWWcPD8t9Y3qpfg0T0gL9DIoVcRA7Js/1QSX22L90ToVR IdP6D8zjMJ1IvVEUyTP3X9SeOCtkBugygqAFmpgulrCNgjJUxhN0h6sNBiLKYJ0P 4h+SBzcXCBOx9IWcUlfAsvaGokahlLPqMcoqIMMpq2EtCpYS8BsKjoU/lWyoguLZ O77ohY54unTthfMOIM1Hv/KoMY4Jq9ibA3ea3lPB01453bYsVYcsFywNzmAgHYSQ mgyl6YbVMmLrQVf0/ZYjwrsgIGYXPCe8f2LbEGWf7j5gMfKh3tyULUjTATYFs7q2 01pRH/pdzObyCPHTPMqy85lkNNeNe07yyzjWPtGDRNLcLj5BYxyYcIkKK7y0PgZL l279XnHDxMnxABEBAAG0EjB4QUNFNTY5NzFENTU1REFBNYkCXgQTAQoASAIbAQIe AQIXgAIZAQsLDQkIDAcDCwoEAgYVCgkICwMFFgMCAQAWIQR5EMRfifyMwsvSSrCs 5Wlx1VXapQUCXrAYXAUJCdC0QgAKCRCs5Wlx1VXapToBD/0RoBp776pLHL2IzZrc l9uqvmQRX6Yn/+vpIigMk9UA19vmgcX8pm0XRr5JdH5w88ExUqymlnRCvzQWSMBQ 4fli5RtOrYH5i+oyjkMuoFrZCIJrHrHXW51IjQgzYIvsjm8xxG5j5n8/cVn1Ej4L sAsv4SAnrG0XJgc5xVVh39rQ785Mf0o5XBx20MKGtFkE4Ljr7mGVwXF3efAxSZel EPU8Tn7bS9RubLPa4qMef3d86HYw0wuGg72pyL6QqWJrC5TtRDjZVM7oW1RKhSmA +HfuxUwiZ7MLiNib/V3cAU8LGkCM/uYeArE7A/p/D6EgRajJu/RazcESEzhMieht BSzTB2xYtDzfHkv0i8RwvrjeaQtvEIDjwWLDZhNbK4R2Eh5I60tOszaTnENVfmQ8 BIaobutM/97EGjlWDZRlaE8m6IR9holHs8CXSL7fXzJBKEhaDRm3U5vcrv/fKq8c MXNoBoo6U30JlHldURzKr0boza67lw5nQtAlOf9QUdg4rwP39Pfdl9pzy0iOIif3 XqLVi+pgjNLXgYpLyiohLLcWQPfa1B/yiT/w++dd7XFA9MC0iPdSqmJB/QvzG33q EskcqmGZH+SwpgEN1kVZEP9TQ1qReOd6k/R6Trx9HfA7iVtgob3H3hgMz/ulDUGl 9lkwuun7fG9MHGaBAK0C5SIl6bkCDQRZheBoARAArGP94En3E7nyvb+5DTBuBVEK rQcI+bG2SiCKqXNkFUZEKdqAXJomm2oNNMugMLeoSncORSkQRMFlzGjaK84f7S+i vsP4WL/F5+h1A9AbhZsRe46FC+GBDf1/1gcf+TXjoe8r3WrY3OutFxJmsFqqayaf z5u6gr66pKHVSNZQD9drFt2c/L4A2OcEUO1VBGJmu/vuz7/yueFZubYU7udkeHJX 2bplLjUxjOjUZaDSeXSYGinBs6UVTQNumIjZrd++QPhj2G5VnsZx4d2/JPDD/r0r cYZQctiWnlj60o+fK4/GcDcPCQjKKC74eQwqVjynFYBVRGj/xp/hmARQROIajapK 7E7aFEN897NK9X906dRF81W809jycSSka+LFQ93f34oNrnrAO0xmzgyhg5wsTbxm Hv7Iml/0bwnMDMiOAca8+oNAGWTZ9xmScBq8zRTfoECYMqV1974/7OqL3L9msQ37 dnkEGlio/zEWbbpOYQusiJUZW/W499oz80rsBSnXvF+ba3lnRqF9YU4ZI4MJtO3h VBhgwV/uRw1WDRM8MITKixNBIyYqpfD81fQ5jjXLU3oKI1aASllJiyHS2e/ITTOH ljL+TLeCdpiU0ssT+/ygB4c1Xoq/Fb61kBbJaI2sZObSYvGotOkJxxFdqF29UVE2 B4T8emCi7Lxp6Eco4qEAEQEAAYkEcgQYAQoAJgIbAhYhBHkQxF+J/IzCy9JKsKzl aXHVVdqlBQJesBiuBQkIQ99GAkDBdCAEGQEIAB0WIQRSX6konxd5jbM7JygTDfUW ES/A/wUCWYXgaAAKCRATDfUWES/A/xgsD/9ilpI8Ku4mWcy8Jus/5yHHfT8V4ieR ZfvTVykh1NVdVCyAiRaftrjXRkBMpJgowIXsMQetMZIp1mjYOdfNryb4gD0hifl3 TLl9yp1qXRAeVxpzVx+LgS+Q+HjIFmXhq+rQhnJWjjqgVHiQpkVUlZYRYttK0w6l kToWyY0oRqjsv4UY2NNsI4Ufb9+EXx/W1cvgcf9lBpDll345NH96r6gZBZAZfU8K 51Qdap2oG/FTr11Dc8G4n1riAwM0T+1qpCUgAdmshq/tRMZ90oYICClNUcn44qqv jtVPmtUURa0yybzki83+RxTRfWxVbIg5m7W6qcXm4K852Mj33VLBrH4ufiZbZnla Iqz3i9VCLUcG0eCt0HmuX8P0Lv5jT03isOB2JtXyec7puoXMIYA7FiQKzsppbfbr RC90nsJ5KI4tuba6wHvgLNvnTqP8iURrkxi/Tkcz48bfcOrrKk6CPvB30f5psUBL e51ItMv2oQcJe85PQtPjClT6qgBZY8mmu0vuzTDVsEXLSEPAObVnVHc+jN1SbVCe CYQETPi2Ul10w+yWx7D5G6iIH2kKxqZzlix+j10MJ7IVmjhANoQXc2vjflfM891N omgWlOjyWEB7/0UHBlFNFk+17tyDM5FIDzf4DH6Bu0oBkfcgVCme80x3XgQr5TCB WLcruxXOwVBDLgkQrOVpcdVV2qXsVw/+MxaSn/excv/noT6F65jXz8ghJhb1DXvF lVNUNKFYxOwAOL4w89sIFIoZBu8yFO7vxhxfqigY/TCWU+fqNBk1jsPUuD4Tj9Lk izwmDkdj+oHztoJi0BuS2ld8myqyMan5NxL9Bsqm0F4KYYaOwNGK6S/AGrpejerx 8z6y8tck8QJjlQI0zUWqeBMxW4c/GBFtTSMmKb9+a4lvI6OwbVKwvd1+51sj2Mzh BY9ne9UTUhXx8FQiCFgJbsIMzs8aR5jjB4vYPohLwBPsXR+cQClIsrc6n8vYNpn/ W1RC8C41VWL8bvLkNCKbWkVSmEXQSAj8p7kHilSsHjDVT6gqCUgoWqSuD+4qflKq Y3XVQ2TVx++xKEUpCZZFHd8QlX1ixZTnmO5n1zbFsqpMtr0PcbUZtyjmjvIGqF4l vrp9WXGJatbhE4G805PYa8Eg87jHxJWK7NnCe+8+wnY5D0T0FsJbdfJ7Y+GAgK6j vBpYGl8CdcWaa0ksYHj7TbgrjGOZQF/Z2n1r0fIhEZMGDwijuH77iiNVXuWMvJ81 RJxUbp1dnYTBnNnIUS+458gBGs3jFgl6mzsEKzVvWf5vS7XK5Beaqu7FQd6WUrkQ VLH6pyaZu1NVW/Il6LbrRB4co1aReC0Ei5AOcWz2ayJoISXBJ3GRgiiyQ8XG/sfD h4I3q6mbJ8m5Ag0EWYXwgAEQAO+wh3g3SgeBWkzLaIHo3p7Z92CyEnssgvZnfaWN Bowuv1INtprqa15yRpaIr8eFlchlVqCiQ2FN54tWkND5qlallwi2YSUW+nkEXCvy UR1S///MmwI5qos0A+Sil3uPsuBQtRezCaNEghM5a83Lfvv9kYqzfa9D6gCYUCv6 NtbH/yeshOuRhT2P3jFK0+kIObyPO26XsbfdbocutYA3c/27TAsE8VJvu4yqL5CU vz5H+EzGAdmrXVYD/VFxMrbIkKjmb7I0Tnl8RF3IUsL3SK/AKWYPOI4mMp5dv4yO /gYVoWX5Fd4dv6EQmvHMfiIvsxP8EBOTNVEtj/rac4P7Trdsc7CWsL5zzpofxIFQ ibo3JVNTRs/PPIlVmPROYLbXaolufgAmi+E8BCer780yc4nkmWOEcepuk3cQCM3l 6OrgI8aWQyrcf4uW4Jtn98AldJ21PhtN4A0d5PF0YvX/OrXoi3XBROUVLY6IF5Qb kSMeOvqJWzgktxvULI53Q3jtZvgtmF2dZ5rFgJCy3PjuXRBi2ZTz47eW94E7xDr0 4euhFnyMaiDMKS0XAj978kyCUrtDsssWp83j1IZt5Bd7JmtohThlEZCQ3Y0u3Gjm j9Nkv18qmF8O21Qe0LzG8Ad9HPTbQd9Rk+GQz57WxlcsjK2bC0WG7f6R5BHq1Ymu oD8nABEBAAGJAjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY 4QUJBrb74QAKCRCs5Wlx1VXapXcrD/9ktCowTIi5PtKUCjuttsaZzVRnAeTee3Wv PJwbrFR7L3Jkx3OM1KeSni+YsAfBrLi7xag4IIt8alQ6cYww2/q1aFPrs6opl2ou 6NLxM4ynxkV8Gb2kqiwUVlf5QFUVJOoNeVwoiNelklUj5jGq3KZGqhq4OSC5fkcC tOsjOffWWD1YACZL4aHrxUM/njHq8k+WBNocYtdmbFH8Iujzf27tsV8b0yIKGs6L 5jjkFpSDQo+/jiGafLVsddu9TeZr9Jm7OGo/u6q8ozCxaTg/G7fLF9DGrj1+AakN 9sujxRgXkccIznci5qPW0dzOzhVUcaVPDdhfv/O3RXbky2qMSk+uxB5drqJ7LbOk PVTbDadspla82oJw3OoWuR0uC0aK7eibuFlurms6CcG/UQYQv9cjS4wGVe44S6/w iUBjfJXT3ITorl38PcBigpF0XYWk2FAdE40xPN3REKv2Byulmjnc3ia2R+zBWuPg 30LsQtFWgiwNtYJ5n/J08Ek+gqA6lNX9pRKT8lq6RQgQrvir7d/9Zw+RGaaVB1En BUJi49O0SfqsvoFLstR1XnlhQubkhk5jhZ582Pug6K2H3b9sgU5ycTaWSEBr1B0A bvIetF5qO+pJY/vT452Br2g6CKXSpS2y6wwcqC0e/dkB31uFl1s4fRUmGxmBXnK4 GFu/ufjNzrg4BFmF99oSCisGAQQBl1UBBQEBB0CCRNDhUo58xjQ/zW1Kebdb8evr P6QU27xuMfpj0WRRfwMBCAeJAjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx 1VXapQUCXrAY4QUJBrb0hwAKCRCs5Wlx1VXapSc0D/9JxkCkLkyOYx+rnOUugdwf Q7kRuUVkxLIIxf0UwEf9B2fsxEDIJJJO9DJOBnGtFHLI0k6nxCsk6QNz8TIpBGx1 oH8k17gJgmQuZHED+xQBYbAx3G3Kj5jIj9oCnFJdP3ADM+Dzgwvm4hUuRD2gLEIw C0dpcPu+g2gQ+jRG9Gl3NT6qC6mvp2w7P0hW8+7o7oZN5T2Lpi5s86yMuaoUlItj 6a4Cjg4xJdTBHstJTWGfvclobVaxoas1udf/TzFNA6FUFQpRsgqymPS7MOK6GaQg vctT9/fP6jUwydhheDwYiFQzWaNaCjGfNq6/QlImDQryAuWV7mWknygKR4uaqem4 8vhaea9XBMdghunv4tp/4fVELe0DDdV6D99cwvB+27gu3UlE0bz2gNq24IBq6Ew0 jsKu0vTOyyiR49MEqjgdQna0CScO5fHv2DnJmYnCf1S5g36mlWm8HG3XM1OHizdj cB4hcSs9ETWYi1W5f0nZ94rv+BgZ6J+MOBybtfkxb1jYpf7rTx6bJbHQuYad879S ts5u6Ya36cRE/D7nHgSasxL5Kekr0eBM5EuGXQINYlQItw0yfrM9NUgfePqZumNr rkxjqxcsh0aBJROm1FW6RSa4KnnIQNRu5jAWM7Md+aQQEj/YdJgS6uLzteKZBwUE e7jqNmTRtevMZtln9JNjcwAKCRATDfUWES/A/2X2D/0XqTVlrImVggor6ACWDNV4 JQfdkLpQWyaI4jdwW5WXP/Xd09fqA43AiVuNTV+KzI1vhAJkMmEH/cH6IR89Wb1s 3XAgkNvU897me3mg1gLe5kL2agOUwth6tM7Neew7EiydhZBumf8FE2yarmJSvdDx xZrBcfDPx5Ld8eghsMcV9jzHlRz9OvjeWkvEax7RBr+UvLHDtdUal8Ats4DGJXa1 KFSOvfoC3RGuNxGZyoH2YttG62F1Nokh8j8YWVzy+KXTNex2XZyvhEOOwoh2ynSZ +fUUaEmrSMwblDPRudnWt25Svae/tHqrptgN1Y9tyuiZt1YLQipnVqYyifq5/Pl3 Biq1ECJdl1ym8fQweJZdhaQ4J5mjuIIL/L0j9X2zsczTjwrl8p5NbaQ808IADtHB xOyPW3gzrCPX4zQxVJInemBZmMGL4071faLpl/uGCEaS2KLE8iLKIQV2itrGSHj8 h/wvVhjVfqPdrTfR3N1n70KfAHNnrR6N5d6euqJrTaB4DPempI8IR5HGDzdq1J1V GeH5Vhqq9ihzxXVRTrRP2c9RoAWYNBYF37bxRH5lcjFgYBNyHjzfozZ+AZdE0WcA RjfdBwsdZJrUrgtu7YTLAf0/v9mZZBAXfvO8CgNySZfWWZ5IP0BvHLgkUXI0r7Qt kuQMuu7LJiMJFrPQKIL1cQ== =XcGg -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Fri May 15 03:56:32 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 14 May 2020 21:56:32 -0400 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200515004100.00005d5c.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> Message-ID: <62d1684c-59b9-4e73-e4e1-3acbc5eb9bab@sixdemonbag.org> > When you work in compliance mode it should be IHMO possible that people > wishing to communicate with you (from foreign countries) and may have a > different opinion about privacy, Sure. And if they're important enough for me to justify breaking compliance, I am perfectly capable of removing the "rfc4880" flag from my gpg.conf file. There is no excuse for willfully breaking RFC4880 compliance *when the user has explicitly requested strict compliance*. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Fri May 15 09:04:13 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 15 May 2020 09:04:13 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <62d1684c-59b9-4e73-e4e1-3acbc5eb9bab@sixdemonbag.org> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <62d1684c-59b9-4e73-e4e1-3acbc5eb9bab@sixdemonbag.org> Message-ID: <20200515090413.00002c93.sac@300baud.de> Robert J. Hansen wrote: > > When you work in compliance mode it should be IHMO possible that > > people wishing to communicate with you (from foreign countries) and > > may have a different opinion about privacy, > > Sure. And if they're important enough for me to justify breaking > compliance, I am perfectly capable of removing the "rfc4880" flag from > my gpg.conf file. > > There is no excuse for willfully breaking RFC4880 compliance *when the > user has explicitly requested strict compliance*. Certainly there are many reasons to extend the standard, which is not set in stone and which is not a politically adopted law, for meaningful things. Of course, a program author has the right to design his program as he sees fit, but please don't be surprised if far-sighted pioneers expand this standard to meet the needs of a user base who would also like to use this standard. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From wk at gnupg.org Fri May 15 10:48:19 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 May 2020 10:48:19 +0200 Subject: keys require a user-id (was: Comparison of RSA vs elliptical keys) In-Reply-To: <20200514230126.00001289.sac@300baud.de> (Stefan Claas's message of "Thu, 14 May 2020 23:01:26 +0200") References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> Message-ID: <87mu69a8j0.fsf_-_@wheatstone.g10code.de> On Thu, 14 May 2020 23:01, Stefan Claas said: > you would consider including it in GnuPG too and reflecting it in the > respective RFC? The User-IDs are an integral part of OpenPGP and at the core of its design. All kind of important information is bound to the user ids and thus a key w/o a user ID is basically useless. There is one exception for this: Derek Atkins (one of the original PGP authors) requested certain features to allow the use of a stripped down OpenPGP key by space and CPU constrained devices. We integrated this into the standard because it is better to use even a stripped down format than to come up with just another format. Direct key signatures were never intended to replace User-IDs and their self-signatures. And no, it is not a privacy issue. If you don't want to put your name or mail address into the user ID, just don't do it but use a random string or even the keys fingerprint. For the majority of use cases a mail address is still the best way to identify and even lookup a key. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Fri May 15 13:29:31 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 15 May 2020 13:29:31 +0200 Subject: keys require a user-id In-Reply-To: <87mu69a8j0.fsf_-_@wheatstone.g10code.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> Message-ID: <20200515132931.00006da2.sac@300baud.de> Werner Koch wrote: > On Thu, 14 May 2020 23:01, Stefan Claas said: > > > you would consider including it in GnuPG too and reflecting it in > > the respective RFC? > > The User-IDs are an integral part of OpenPGP and at the core of its > design. All kind of important information is bound to the user ids > and thus a key w/o a user ID is basically useless. I understand that a UID is an integral part, for example if people need a certification from a trusted CA, which usually requires a full name and email address. What I don't understand is why you are not liking the idea to allow GnuPG to automatically import and process UID-less public key blocks, if people who trust the GnuPG brand ask for this? Nobody is asking for UID-less key creation as default behavior. > There is one exception for this: Derek Atkins (one of the original PGP > authors) requested certain features to allow the use of a stripped > down OpenPGP key by space and CPU constrained devices. We integrated > this into the standard because it is better to use even a stripped > down format than to come up with just another format. > > Direct key signatures were never intended to replace User-IDs and > their self-signatures. > > And no, it is not a privacy issue. If you don't want to put your name > or mail address into the user ID, just don't do it but use a random > string or even the keys fingerprint. For the majority of use cases a > mail address is still the best way to identify and even lookup a key. GnuPG always asks IIRC new users for their Name and email address and does not tell them in advance that they can use a free form UID, without an email address, thus being able to use a key for multiple accounts or purposes, without adding additional UIDs. Best regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From kloecker at kde.org Fri May 15 14:35:44 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 15 May 2020 14:35:44 +0200 Subject: keys require a user-id In-Reply-To: <20200515132931.00006da2.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> Message-ID: <15143917.RxENNiKXH9@breq> On Freitag, 15. Mai 2020 13:29:31 CEST Stefan Claas wrote: > What I don't understand is why you are not liking the idea to allow > GnuPG to automatically import and process UID-less public key blocks, > if people who trust the GnuPG brand ask for this? Because in GnuPG the validity of keys is bound to validity and owner trust of UIDs. No UID -> invalid key. Why do you want to be able to import a key in GnuPG that would be utterly unusable? > GnuPG always asks IIRC new users for their Name and email address > and does not tell them in advance that they can use a free form UID, > without an email address, thus being able to use a key for multiple > accounts or purposes, without adding additional UIDs. To cite Robert J. Hansen: "Unless you know what you're doing and why, use the defaults." Consequently, it's a good thing that GnuPG, by default, doesn't bother new users with difficult decisions. Regards, Ingo From wiktor at metacode.biz Fri May 15 15:01:08 2020 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 15 May 2020 15:01:08 +0200 Subject: keys require a user-id In-Reply-To: <15143917.RxENNiKXH9@breq> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <15143917.RxENNiKXH9@breq> Message-ID: <398600de-c9b9-9396-0337-1f7320dcdd0d@metacode.biz> Hi Ingo, On 15.05.2020 14:35, Ingo Kl?cker wrote: > Because in GnuPG the validity of keys is bound to validity and owner trust of > UIDs. No UID -> invalid key. Why do you want to be able to import a key in > GnuPG that would be utterly unusable? AFAIK key validity and owner trust are per key not per User ID. Third-party signatures are made for key fingerprint and User ID but then it takes one fully trusted UID (or 3 marginally by default) for the key to be considered valid. And then if that valid key signs some other User ID the process starts anew. For signing other keys only the primary key is needed, not User IDs. The distinction is important because it affects only the Web of Trust and only in one way. That is if you owner-trusted that UID-less key it could become trust introducer in your WoT. Also you could encrypt to that key and verify signatures just fine (it just wouldn't display anything meaningful). Is this useful? I'm not sure, but wanted to point out this one detail. Kind regards, Wiktor -- https://metacode.biz/@wiktor From andrewg at andrewg.com Fri May 15 15:02:34 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 15 May 2020 14:02:34 +0100 Subject: keys require a user-id In-Reply-To: <15143917.RxENNiKXH9@breq> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <15143917.RxENNiKXH9@breq> Message-ID: <47715aae-9830-f123-b865-910697ffab5c@andrewg.com> I think we are conflating two related but distinct ideas here. On 15/05/2020 13:35, Ingo Kl?cker wrote: > Why do you want to be able to import a key in > GnuPG that would be utterly unusable? There are use cases where you might want to transfer only the modifications to a key, without necessarily distributing the entire key. Publicly revoking a primary key without disclosing its user IDs, for example. But this is distinct from being able to create a new key with no user IDs at all, which I see no reasonable use for - if your user ID is sensitive, then use an alias. Even in the use case described above the keys have aliases. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Fri May 15 15:21:51 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 15 May 2020 14:21:51 +0100 Subject: keys require a user-id In-Reply-To: <398600de-c9b9-9396-0337-1f7320dcdd0d@metacode.biz> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <15143917.RxENNiKXH9@breq> <398600de-c9b9-9396-0337-1f7320dcdd0d@metacode.biz> Message-ID: On 15/05/2020 14:01, Wiktor Kwapisiewicz via Gnupg-users wrote: > AFAIK key validity and owner trust are per key not per User ID. Ownertrust is per-key, but validity is per-UID. On my local machine `gpg --list-keys wiktor at metacode.biz` shows: ``` pub rsa4096/0x6C8857E0D8E8F074 2017-01-01 [C] [expires: 2021-01-01] Key fingerprint = 6539 09A2 F0E3 7C10 6F5F AF54 6C88 57E0 D8E8 F074 uid [ unknown] Wiktor Kwapisiewicz uid [ unknown] [unknown attribute of size 83] sub rsa4096/0xB97A1EE09DB417EC 2017-10-18 [S] [expires: 2021-01-01] sub rsa2048/0x60D2F50529E2DE4F 2018-07-06 [E] [expires: 2021-01-01] sub rsa2048/0x97FDEF34DAB8F82B 2018-07-06 [S] [expires: 2021-01-01] sub rsa2048/0x3B6DFCC964CFEBC4 2018-07-06 [A] [expires: 2021-01-01] ``` Each of those `[ unknown]`s represents the validity of that particular UID only. I could right now add a new UID to my primary key. The invalidity of would not invalidate . -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri May 15 15:21:47 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 15 May 2020 09:21:47 -0400 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200515090413.00002c93.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <62d1684c-59b9-4e73-e4e1-3acbc5eb9bab@sixdemonbag.org> <20200515090413.00002c93.sac@300baud.de> Message-ID: <06a65d70-6d01-6de0-ec03-c841d64c829b@sixdemonbag.org> > Certainly there are many reasons to extend the standard, which is not > set in stone and which is not a politically adopted law, for meaningful > things. Yes. If you want to talk about changing the standard please bring it up to the proper mailing list. Here is not the place for it. If you can persuade people to change the standard I'll be wildly in favor of GnuPG implementing the standard. > Of course, a program author has the right to design his program as he > sees fit, but please don't be surprised if far-sighted pioneers expand > this standard to meet the needs of a user base who would also like to > use this standard. This is irrelevant. We're talking about what GnuPG should do if someone specifies strict RFC conformance. The answer to that question is simple: it should strictly conform to the RFC and treat UID-free certificates as the malformed entities they are. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri May 15 15:32:34 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 15 May 2020 09:32:34 -0400 Subject: keys require a user-id In-Reply-To: <20200515132931.00006da2.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> Message-ID: > GnuPG always asks IIRC new users for their Name and email address > and does not tell them in advance that they can use a free form UID, > without an email address, thus being able to use a key for multiple > accounts or purposes, without adding additional UIDs. It is not the job of the command-line interface to teach users the subtleties and nuances of OpenPGP. If users want to know the many different ways GnuPG can be used they need to read the documentation. If you think this use-case is important enough it should go in the manpage or FAQ, let's discuss that. But the command-line user interface is the wrong place to be teaching people about unusual use cases. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From wiktor at metacode.biz Fri May 15 15:34:31 2020 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 15 May 2020 15:34:31 +0200 Subject: keys require a user-id In-Reply-To: References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <15143917.RxENNiKXH9@breq> <398600de-c9b9-9396-0337-1f7320dcdd0d@metacode.biz> Message-ID: <0872074d-a303-5493-d941-3e32a2e61101@metacode.biz> On 15.05.2020 15:21, Andrew Gallagher wrote: > Ownertrust is per-key, but validity is per-UID. Andrew there are two validity values: $ gpg --edit-key andrewg pub rsa4096/FB73E21AF1163937 created: 2013-07-02 expires: 2021-01-07 usage: SCA --> trust: unknown validity: marginal <--- here (A) sub rsa4096/6B09069314549D4B created: 2013-07-02 expires: 2021-01-07 usage: E sub rsa4096/5C1EC404D5906629 created: 2015-04-26 expires: 2021-01-07 usage: S sub rsa4096/85FDF561DA8C0C46 created: 2015-04-26 expires: 2021-01-07 usage: A [marginal] (1). Andrew Gallagher <-- and here (B) [marginal] (2) Andrew Gallagher Value from (A) is calculated from User IDs (B). When you sign someone else User ID it's not your User ID that is doing the signing it it's your key that's why you need a key validity that's separated from User ID (key validity is calculated from User ID validity). Kind regards, Wiktor -- https://metacode.biz/@wiktor From andrewg at andrewg.com Fri May 15 16:43:37 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 15 May 2020 15:43:37 +0100 Subject: keys require a user-id In-Reply-To: <0872074d-a303-5493-d941-3e32a2e61101@metacode.biz> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <15143917.RxENNiKXH9@breq> <398600de-c9b9-9396-0337-1f7320dcdd0d@metacode.biz> <0872074d-a303-5493-d941-3e32a2e61101@metacode.biz> Message-ID: On 15/05/2020 14:34, Wiktor Kwapisiewicz wrote: > > When you sign someone else User ID it's not your User ID that is doing > the signing it it's your key that's why you need a key validity that's > separated from User ID (key validity is calculated from User ID validity). The inputs to the WoT are the signatures and the ownertrust values, and the outputs are UID validities. "Key validity" is neither an input nor a meaningful output of the system. It is useful only as an intermediate step, together with the ownertrust, in the calculation of another UID's validity. The practical outworking of any validity calculation is not "Is this key valid?" but "Is this key valid for this UID?". Also, the following is incorrect: > Third-party signatures are made for key fingerprint and User ID but then > it takes one fully trusted UID (or 3 marginally by default) for the key > to be considered valid. It takes one fully trusted certifier (*), or three marginally trusted certifiers (*) on the *same UID*, for a UID to be considered valid. Three different UIDs of the same key signed by marginal certifiers do not increase the validity of the key, otherwise increasing the number of UIDs on a key could boost its validity, which is perverse. ;-) (* certification by a key that has at least one valid UID and (full|marginal) ownertrust) -- Andrew Gallagher From taboolust at secmail.pro Fri May 15 14:58:51 2020 From: taboolust at secmail.pro (Arthur Dasaviour) Date: Fri, 15 May 2020 05:58:51 -0700 Subject: new subscriber Message-ID: <5d1e3dd6e2e4c31ae60ec2a938a53342.squirrel@giyzk7o6dcunb2ry.onion> Hi, I'm checking if my subscription is valid. I look forward to hearing from you. This message has been digitally signed by Arthur Dasaviour From wk at gnupg.org Fri May 15 17:37:01 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 May 2020 17:37:01 +0200 Subject: keys require a user-id In-Reply-To: <15143917.RxENNiKXH9@breq> ("Ingo \=\?utf-8\?Q\?Kl\=C3\=B6cker\=22's\?\= message of "Fri, 15 May 2020 14:35:44 +0200") References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <15143917.RxENNiKXH9@breq> Message-ID: <8736819plu.fsf@wheatstone.g10code.de> On Fri, 15 May 2020 14:35, Ingo Kl?cker said: > UIDs. No UID -> invalid key. Why do you want to be able to import a key in > GnuPG that would be utterly unusable? FWIW, the expiration time of a key is also bound to the user-id as well as key preferences and all kind of other possiblke gadgets. And no, a direct-key signature is no replacement for this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Fri May 15 18:16:06 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 15 May 2020 18:16:06 +0200 Subject: keys require a user-id In-Reply-To: References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> Message-ID: <20200515181606.00003609.sac@300baud.de> Robert J. Hansen wrote: > > GnuPG always asks IIRC new users for their Name and email address > > and does not tell them in advance that they can use a free form UID, > > without an email address, thus being able to use a key for multiple > > accounts or purposes, without adding additional UIDs. > > It is not the job of the command-line interface to teach users the > subtleties and nuances of OpenPGP. If users want to know the many > different ways GnuPG can be used they need to read the documentation. > > If you think this use-case is important enough it should go in the > manpage or FAQ, let's discuss that. But the command-line user > interface is the wrong place to be teaching people about unusual use > cases. We now have the situation that either parents or teachers, etc. can choose between a software which allows UID-less public key generation, for their minors / students, themselves, or a software which does not accept this and has no guidelines for free-form UIDs in their FAQ / man page, nor an equal treatment in the standard key generation process. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From rjh at sixdemonbag.org Fri May 15 18:30:57 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 15 May 2020 12:30:57 -0400 Subject: keys require a user-id In-Reply-To: <20200515181606.00003609.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> Message-ID: <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> > We now have the situation that either parents or teachers, etc. can > choose between a software which allows UID-less public key > generation, for their minors / students, themselves... They are free to use whatever identifier they like for a UID, even just the key ID. A UID-free certificate is in no way required for user privacy. You're being dishonest. I hate to say that, but I believe it's true. You insist on pretending that you're the only one concerned about privacy and that UID-free certificates are necessary for privacy of personally identifying information. The reality is the UID system in no way requires personally identifying information and everyone you're accusing of not caring about privacy cares a great deal about it. You're being dishonest. Please stop. > or a software which does not accept this and has no guidelines for > free-form UIDs in their FAQ / man page, nor an equal treatment in the > standard key generation process. If you want the documentation to reflect PII-free UIDs, please say that. This could be a useful discussion. If the community believes PII-free UIDs should be in the FAQ I will happily write up an entry for it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From remco at webconquest.com Fri May 15 17:02:33 2020 From: remco at webconquest.com (Remco =?utf-8?Q?R=C4=B3nders?=) Date: Fri, 15 May 2020 11:02:33 -0400 Subject: new subscriber In-Reply-To: <5d1e3dd6e2e4c31ae60ec2a938a53342.squirrel@giyzk7o6dcunb2ry.onion> References: <5d1e3dd6e2e4c31ae60ec2a938a53342.squirrel@giyzk7o6dcunb2ry.onion> Message-ID: <20200515150233.GH25401@settler> On Fri, May 15, 2020 at 05:58:51AM -0700, Arthur wrote in <5d1e3dd6e2e4c31ae60ec2a938a53342.squirrel at giyzk7o6dcunb2ry.onion>: >Hi, I'm checking if my subscription is valid. Your subscription is... >This message has been digitally signed by Arthur Dasaviour ...your signature is not. Just writing that you've signed something does not make it so (from a gnupg perspective). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From sac at 300baud.de Fri May 15 19:07:40 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 15 May 2020 19:07:40 +0200 Subject: keys require a user-id In-Reply-To: <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> Message-ID: <20200515190740.00006d15.sac@300baud.de> Robert J. Hansen wrote: > > We now have the situation that either parents or teachers, etc. can > > choose between a software which allows UID-less public key > > generation, for their minors / students, themselves... > > They are free to use whatever identifier they like for a UID, even > just the key ID. A UID-free certificate is in no way required for > user privacy. > > You're being dishonest. I hate to say that, but I believe it's true. > You insist on pretending that you're the only one concerned about > privacy and that UID-free certificates are necessary for privacy of > personally identifying information. The reality is the UID system in > no way requires personally identifying information and everyone you're > accusing of not caring about privacy cares a great deal about it. > > You're being dishonest. Please stop. Mind you, I have only asked that GnuPG should support the import and processing of UID-less public key blocks and did not requested that this should be a default behaviour in the key generation process. It is also interesting when you folks seem to run out of arguments that you try to get personal, but I don't mind and stop, as per request! :-) > > or a software which does not accept this and has no guidelines for > > free-form UIDs in their FAQ / man page, nor an equal treatment in > > the standard key generation process. > > If you want the documentation to reflect PII-free UIDs, please say > that. This could be a useful discussion. If the community believes > PII-free UIDs should be in the FAQ I will happily write up an entry > for it. Please discuss it with the community and try to add it later to the documentation as equally treated, in the key generation process. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From wiktor at metacode.biz Fri May 15 20:14:41 2020 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 15 May 2020 20:14:41 +0200 Subject: keys require a user-id In-Reply-To: References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <15143917.RxENNiKXH9@breq> <398600de-c9b9-9396-0337-1f7320dcdd0d@metacode.biz> <0872074d-a303-5493-d941-3e32a2e61101@metacode.biz> Message-ID: On 15.05.2020 16:43, Andrew Gallagher wrote: > The inputs to the WoT are the signatures and the ownertrust values, and > the outputs are UID validities. "Key validity" is neither an input nor a > meaningful output of the system. Key validity directly influences the "WARNING: This key is not certified with sufficiently trusted signatures" message that I think is pretty significant for end-users. If it wasn't meaningful it wouldn't be printed in the --edit-key dialog. > It is useful only as an intermediate > step, together with the ownertrust, in the calculation of another UID's > validity. The practical outworking of any validity calculation is not > "Is this key valid?" but "Is this key valid for this UID?". The argument could be reversed stating that "User ID validity is useful only as an intermediate step to calculate key validity" and we wouldn't draw any new knowledge from this. My original point was that key validity exists. Also: thanks for bringing my mental shortcut to technical correctness: > It takes one fully trusted certifier (*), or three marginally trusted > certifiers (*) on the *same UID*, for a UID to be considered valid. This could of course be further refining by mentioning ownertrust or that 0x11: Persona certifications do not contribute to this or that trust signatures affect the algorithm or... Kind regards, Wiktor -- https://metacode.biz/@wiktor From roam at ringlet.net Fri May 15 21:33:11 2020 From: roam at ringlet.net (Peter Pentchev) Date: Fri, 15 May 2020 22:33:11 +0300 Subject: keys require a user-id In-Reply-To: <20200515190740.00006d15.sac@300baud.de> References: <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> Message-ID: <20200515193311.GR140052@straylight.m.ringlet.net> On Fri, May 15, 2020 at 07:07:40PM +0200, Stefan Claas wrote: > Robert J. Hansen wrote: > > > > We now have the situation that either parents or teachers, etc. can > > > choose between a software which allows UID-less public key > > > generation, for their minors / students, themselves... > > > > They are free to use whatever identifier they like for a UID, even > > just the key ID. A UID-free certificate is in no way required for > > user privacy. > > > > You're being dishonest. I hate to say that, but I believe it's true. > > You insist on pretending that you're the only one concerned about > > privacy and that UID-free certificates are necessary for privacy of > > personally identifying information. The reality is the UID system in > > no way requires personally identifying information and everyone you're > > accusing of not caring about privacy cares a great deal about it. > > > > You're being dishonest. Please stop. > > Mind you, I have only asked that GnuPG should support the import and > processing of UID-less public key blocks and did not requested that > this should be a default behaviour in the key generation process. And the answer has been given: because those blocks violate the OpenPGP standard and, as I understand Robert J. Hansen (and I apologize to him if I'm putting the wrong words into his mouth), his position is that there is no reason for this violation to exist at all, there is no reason for UID-less key blocks to exist at all, so GnuPG is quite right in following the OpenPGP standard and not accepting them. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org pp at storpool.com PGP key: http://people.FreeBSD.org/~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 roam at ringlet.net Fri May 15 21:34:19 2020 From: roam at ringlet.net (Peter Pentchev) Date: Fri, 15 May 2020 22:34:19 +0300 Subject: keys require a user-id In-Reply-To: <20200515193311.GR140052@straylight.m.ringlet.net> References: <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> Message-ID: <20200515193419.GA1054174@straylight.m.ringlet.net> On Fri, May 15, 2020 at 10:33:12PM +0300, Peter Pentchev wrote: > On Fri, May 15, 2020 at 07:07:40PM +0200, Stefan Claas wrote: > > Robert J. Hansen wrote: > > > > > > We now have the situation that either parents or teachers, etc. can > > > > choose between a software which allows UID-less public key > > > > generation, for their minors / students, themselves... > > > > > > They are free to use whatever identifier they like for a UID, even > > > just the key ID. A UID-free certificate is in no way required for > > > user privacy. > > > > > > You're being dishonest. I hate to say that, but I believe it's true. > > > You insist on pretending that you're the only one concerned about > > > privacy and that UID-free certificates are necessary for privacy of > > > personally identifying information. The reality is the UID system in > > > no way requires personally identifying information and everyone you're > > > accusing of not caring about privacy cares a great deal about it. > > > > > > You're being dishonest. Please stop. > > > > Mind you, I have only asked that GnuPG should support the import and > > processing of UID-less public key blocks and did not requested that > > this should be a default behaviour in the key generation process. > > And the answer has been given: because those blocks violate the OpenPGP > standard and, as I understand Robert J. Hansen (and I apologize to him > if I'm putting the wrong words into his mouth), his position is that > there is no reason for this violation to exist at all, there is no > reason for UID-less key blocks to exist at all, so GnuPG is quite right > in following the OpenPGP standard and not accepting them. ...and he actually said pretty much that in 06a65d70-6d01-6de0-ec03-c841d64c829b at sixdemonbag.org :) G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org pp at storpool.com PGP key: http://people.FreeBSD.org/~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 sac at 300baud.de Fri May 15 22:54:32 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 15 May 2020 22:54:32 +0200 Subject: keys require a user-id In-Reply-To: <20200515193311.GR140052@straylight.m.ringlet.net> References: <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> Message-ID: <20200515225432.000050db.sac@300baud.de> Peter Pentchev wrote: > On Fri, May 15, 2020 at 07:07:40PM +0200, Stefan Claas wrote: > > Mind you, I have only asked that GnuPG should support the import and > > processing of UID-less public key blocks and did not requested that > > this should be a default behaviour in the key generation process. > > And the answer has been given: because those blocks violate the > OpenPGP standard and, as I understand Robert J. Hansen (and I > apologize to him if I'm putting the wrong words into his mouth), his > position is that there is no reason for this violation to exist at > all, there is no reason for UID-less key blocks to exist at all, so > GnuPG is quite right in following the OpenPGP standard and not > accepting them. You know what, the most interesting thing of this ML for me is that when people, do a request or suggestion the old guard is always there to defend some standard and are not accepting that a new product on the OpenPGP market, with a new feature included, add an enrichment to a given standard, which people may like to use and appreciate. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From roam at ringlet.net Sat May 16 00:12:31 2020 From: roam at ringlet.net (Peter Pentchev) Date: Sat, 16 May 2020 01:12:31 +0300 Subject: keys require a user-id In-Reply-To: <20200515225432.000050db.sac@300baud.de> References: <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> Message-ID: <20200515221231.GP9891@straylight.m.ringlet.net> On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote: > Peter Pentchev wrote: > > > On Fri, May 15, 2020 at 07:07:40PM +0200, Stefan Claas wrote: > > > > Mind you, I have only asked that GnuPG should support the import and > > > processing of UID-less public key blocks and did not requested that > > > this should be a default behaviour in the key generation process. > > > > And the answer has been given: because those blocks violate the > > OpenPGP standard and, as I understand Robert J. Hansen (and I > > apologize to him if I'm putting the wrong words into his mouth), his > > position is that there is no reason for this violation to exist at > > all, there is no reason for UID-less key blocks to exist at all, so > > GnuPG is quite right in following the OpenPGP standard and not > > accepting them. > > You know what, the most interesting thing of this ML for me is that > when people, do a request or suggestion the old guard is always there > to defend some standard and are not accepting that a new product on the > OpenPGP market, with a new feature included, add an enrichment to a > given standard, which people may like to use and appreciate. OK, but *how* is it an enrichment? What does a UID-less key provide over a randomly-generated UID? Why go to the bother of supporting a new special case when you can get the same result in another way, with zero additional code in any of the existing implementations and only a couple more lines of code in the special client that will have to generate a random UID? G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org pp at storpool.com PGP key: http://people.FreeBSD.org/~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 sac at 300baud.de Sat May 16 01:36:10 2020 From: sac at 300baud.de (Stefan Claas) Date: Sat, 16 May 2020 01:36:10 +0200 Subject: keys require a user-id In-Reply-To: <20200515221231.GP9891@straylight.m.ringlet.net> References: <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <20200515221231.GP9891@straylight.m.ringlet.net> Message-ID: <20200516013610.00002d06.sac@300baud.de> Peter Pentchev wrote: > On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote: > > You know what, the most interesting thing of this ML for me is that > > when people, do a request or suggestion the old guard is always > > there to defend some standard and are not accepting that a new > > product on the OpenPGP market, with a new feature included, add an > > enrichment to a given standard, which people may like to use and > > appreciate. > > OK, but *how* is it an enrichment? What does a UID-less key provide > over a randomly-generated UID? Why go to the bother of supporting a > new special case when you can get the same result in another way, > with zero additional code in any of the existing implementations and > only a couple more lines of code in the special client that will have > to generate a random UID? Fact is this function is available for users of OpenPGP software. We should better think of how this will pan out in the future, if users start to use OpenPGP software with UID-less public keyblocks and how GnuPG users can interact with them, or not? Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From azbigdogs at gmx.com Sat May 16 01:52:06 2020 From: azbigdogs at gmx.com (Mark) Date: Fri, 15 May 2020 16:52:06 -0700 Subject: Best Keyserver Message-ID: I know this may be a subjective question but what is the best keyserver to use?? I use GPG4Win with the Enigmail plugin for Thunderbird.? The keyservers listed in Enigmail are: vks://keys.openpgp.org, hkps://hkps.pool.sks-keyservers.net, hkps://pgp.mit.edu The keyserver that is used in Kelopatra (GPG4Win) is: hkp://keys.gnupg.net I would think it would be a good idea for both to be configured to use the same keyserver, so which one is "the best" Thanks From mgorny at gentoo.org Sat May 16 08:55:29 2020 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Sat, 16 May 2020 08:55:29 +0200 Subject: Best Keyserver In-Reply-To: References: Message-ID: <2eced9d63b331ff7ac5118fc04f98df01a05ea75.camel@gentoo.org> On Fri, 2020-05-15 at 16:52 -0700, Mark wrote: > I know this may be a subjective question but what is the best keyserver > to use? I use GPG4Win with the Enigmail plugin for Thunderbird. The > keyservers listed in Enigmail are: > > vks://keys.openpgp.org, hkps://hkps.pool.sks-keyservers.net, > hkps://pgp.mit.edu > > The keyserver that is used in Kelopatra (GPG4Win) is: > > hkp://keys.gnupg.net $ host keys.gnupg.net keys.gnupg.net is an alias for hkps.pool.sks-keyservers.net. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From rjh at sixdemonbag.org Sat May 16 03:29:12 2020 From: rjh at sixdemonbag.org (rjh at sixdemonbag.org) Date: Fri, 15 May 2020 21:29:12 -0400 Subject: keys require a user-id In-Reply-To: <20200516013610.00002d06.sac@300baud.de> Message-ID: An HTML attachment was scrubbed... URL: From sac at 300baud.de Sat May 16 15:35:43 2020 From: sac at 300baud.de (Stefan Claas) Date: Sat, 16 May 2020 15:35:43 +0200 Subject: keys require a user-id In-Reply-To: References: <20200516013610.00002d06.sac@300baud.de> Message-ID: <20200516153543.00004731.sac@300baud.de> rjh at sixdemonbag.org wrote: > (Sent from my phone) > > If and when people insisting on UID-less keys want to communicate > with me, I'll tell them the same thing I told users of Imad Faiad's > PGP 6.5.8ckt builds, Disastry's PGP builds, and many more: > > "I'm sorry, but you're not confirming to the specification. If you > wish for me to make sense of your messages, please resend in a > conformant message." > > The community has literally been dealing with devs breaking the > standard for 25 years. We have learned from bitter experience how > important standards conformance is. > > UIDless certs will get the same response as people using TIGER192 as > a hash. So, when you like to communicate with a person who uses such a new key how do you proceed then? And you bring up also one interesting point, I like to ask, for the interested ML reader here. How does this work in general, let's say I am a dev and would add this too, to my OpenPGP app. Is there an OpenPGP board where devs can vote for or against a feature, so that Werner has then to follow suite, or is he in the position to say no and every dev has to follow his GnuPG specs? P.S. Really to bad that Mr. Zimmermann, Bruce Schneier, Prof. Bernstein, Prof. Green and other crypto experts are not on this ML. I would really like to hear what they would say to such an OpenPGP feature in 2020. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From roam at ringlet.net Sat May 16 15:55:11 2020 From: roam at ringlet.net (Peter Pentchev) Date: Sat, 16 May 2020 16:55:11 +0300 Subject: keys require a user-id In-Reply-To: <20200516013610.00002d06.sac@300baud.de> References: <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <20200515221231.GP9891@straylight.m.ringlet.net> <20200516013610.00002d06.sac@300baud.de> Message-ID: <20200516135511.GW140052@straylight.m.ringlet.net> On Sat, May 16, 2020 at 01:36:10AM +0200, Stefan Claas wrote: > Peter Pentchev wrote: > > > On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote: > > > > You know what, the most interesting thing of this ML for me is that > > > when people, do a request or suggestion the old guard is always > > > there to defend some standard and are not accepting that a new > > > product on the OpenPGP market, with a new feature included, add an > > > enrichment to a given standard, which people may like to use and > > > appreciate. > > > > OK, but *how* is it an enrichment? What does a UID-less key provide > > over a randomly-generated UID? Why go to the bother of supporting a > > new special case when you can get the same result in another way, > > with zero additional code in any of the existing implementations and > > only a couple more lines of code in the special client that will have > > to generate a random UID? > > Fact is this function is available for users of OpenPGP software. Is it though? It is not part of the OpenPGP standard, is it? It is available for users of software that implements the OpenPGP standard *with some local extensions*, which is a bit different. > We should better think of how this will pan out in the future, if users > start to use OpenPGP software with UID-less public keyblocks and how > GnuPG users can interact with them, or not? GnuPG users can interact perfectly well with people who use OpenPGP software :) As Robert J. Hansen said, if you (or somebody else) want to extend the standard, there is an IETF working group and mailing list for that. The way I see it, there are two types of standards: - ones that are discussed and written before being implemented, so that all the implementors have the same idea and nobody comes up with, say, using the same magic numbers for completely different purposes or having a function accept one more argument than anyone else and break if it is called with fewer arguments - ones that standardize existing behavior, like the POSIX standard for operating systems, system calls, libraries, command shell, etc. Now, I've been on the POSIX mailing list for well nigh 20 years now, and let me tell you, trying to standardize something when different implementors have come up with *all kinds* of slightly different ways of doing *almost* the same thing can be... crazy. Insane. Amazingly, astonishingly, horrifyingly weird, and very time- and nerve-consuming. It seems to me that the people involved in developing the OpenPGP standard did, at one point, decide to go the other way: yes, sure, start with the existing PGP and GnuPG and other implementations, but then, when thinking about future work, decide to discuss things before implementing them (recent threads on the OpenPGP mailing list notwithstanding), so that it is sorta kinda expected that once various implementations gain the new features, they *will* be able to interoperate. That sounds... kind of reasonable to me. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org pp at storpool.com PGP key: http://people.FreeBSD.org/~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 roam at ringlet.net Sat May 16 15:57:30 2020 From: roam at ringlet.net (Peter Pentchev) Date: Sat, 16 May 2020 16:57:30 +0300 Subject: keys require a user-id In-Reply-To: <20200516135511.GW140052@straylight.m.ringlet.net> References: <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <20200515221231.GP9891@straylight.m.ringlet.net> <20200516013610.00002d06.sac@300baud.de> <20200516135511.GW140052@straylight.m.ringlet.net> Message-ID: <20200516135730.GA1093331@straylight.m.ringlet.net> On Sat, May 16, 2020 at 04:55:11PM +0300, Peter Pentchev wrote: > On Sat, May 16, 2020 at 01:36:10AM +0200, Stefan Claas wrote: > > Peter Pentchev wrote: > > > > > On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote: > > > > > > You know what, the most interesting thing of this ML for me is that > > > > when people, do a request or suggestion the old guard is always > > > > there to defend some standard and are not accepting that a new > > > > product on the OpenPGP market, with a new feature included, add an > > > > enrichment to a given standard, which people may like to use and > > > > appreciate. > > > > > > OK, but *how* is it an enrichment? What does a UID-less key provide > > > over a randomly-generated UID? Why go to the bother of supporting a > > > new special case when you can get the same result in another way, > > > with zero additional code in any of the existing implementations and > > > only a couple more lines of code in the special client that will have > > > to generate a random UID? > > > > Fact is this function is available for users of OpenPGP software. > > Is it though? It is not part of the OpenPGP standard, is it? It is > available for users of software that implements the OpenPGP standard > *with some local extensions*, which is a bit different. > > > We should better think of how this will pan out in the future, if users > > start to use OpenPGP software with UID-less public keyblocks and how > > GnuPG users can interact with them, or not? > > GnuPG users can interact perfectly well with people who use OpenPGP > software :) As Robert J. Hansen said, if you (or somebody else) want to > extend the standard, there is an IETF working group and mailing list for > that. > > The way I see it, there are two types of standards: > > - ones that are discussed and written before being implemented, so that > all the implementors have the same idea and nobody comes up with, say, > using the same magic numbers for completely different purposes or > having a function accept one more argument than anyone else and break > if it is called with fewer arguments > > - ones that standardize existing behavior, like the POSIX standard for > operating systems, system calls, libraries, command shell, etc. > > Now, I've been on the POSIX mailing list for well nigh 20 years now, and > let me tell you, trying to standardize something when different > implementors have come up with *all kinds* of slightly different ways of > doing *almost* the same thing can be... crazy. Insane. Amazingly, > astonishingly, horrifyingly weird, and very time- and nerve-consuming. > > It seems to me that the people involved in developing the OpenPGP > standard did, at one point, decide to go the other way: yes, sure, start > with the existing PGP and GnuPG and other implementations, but then, > when thinking about future work, decide to discuss things before > implementing them (recent threads on the OpenPGP mailing list > notwithstanding), so that it is sorta kinda expected that once various > implementations gain the new features, they *will* be able to > interoperate. That sounds... kind of reasonable to me. Just one more point that I forgot to write: *of course* it's fine for people to implement experimental things to see if they'll work... within reasonable bounds, of course, like not implementing new algorithm identifiers outside the space reserved for experimental ones. But it is also fine for other people to say "okay, sure, you have your experimental features, but I'll wait until they're standardized until I do the work on implementing them myself; also, let's discuss whether they are even needed." G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at debian.org pp at storpool.com PGP key: http://people.FreeBSD.org/~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 sac at 300baud.de Sat May 16 16:16:27 2020 From: sac at 300baud.de (Stefan Claas) Date: Sat, 16 May 2020 16:16:27 +0200 Subject: keys require a user-id In-Reply-To: <20200516135730.GA1093331@straylight.m.ringlet.net> References: <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <20200515221231.GP9891@straylight.m.ringlet.net> <20200516013610.00002d06.sac@300baud.de> <20200516135511.GW140052@straylight.m.ringlet.net> <20200516135730.GA1093331@straylight.m.ringlet.net> Message-ID: <20200516161627.00004538.sac@300baud.de> Peter Pentchev wrote: > On Sat, May 16, 2020 at 04:55:11PM +0300, Peter Pentchev wrote: > > On Sat, May 16, 2020 at 01:36:10AM +0200, Stefan Claas wrote: > > > Peter Pentchev wrote: > > > > > > > On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote: > > > > > > > > You know what, the most interesting thing of this ML for me > > > > > is that when people, do a request or suggestion the old guard > > > > > is always there to defend some standard and are not accepting > > > > > that a new product on the OpenPGP market, with a new feature > > > > > included, add an enrichment to a given standard, which people > > > > > may like to use and appreciate. > > > > > > > > OK, but *how* is it an enrichment? What does a UID-less key > > > > provide over a randomly-generated UID? Why go to the bother of > > > > supporting a new special case when you can get the same result > > > > in another way, with zero additional code in any of the > > > > existing implementations and only a couple more lines of code > > > > in the special client that will have to generate a random UID? > > > > > > Fact is this function is available for users of OpenPGP software. > > > > Is it though? It is not part of the OpenPGP standard, is it? It is > > available for users of software that implements the OpenPGP standard > > *with some local extensions*, which is a bit different. > > > > > We should better think of how this will pan out in the future, if > > > users start to use OpenPGP software with UID-less public > > > keyblocks and how GnuPG users can interact with them, or not? > > > > GnuPG users can interact perfectly well with people who use OpenPGP > > software :) As Robert J. Hansen said, if you (or somebody else) > > want to extend the standard, there is an IETF working group and > > mailing list for that. > > > > The way I see it, there are two types of standards: > > > > - ones that are discussed and written before being implemented, so > > that all the implementors have the same idea and nobody comes up > > with, say, using the same magic numbers for completely different > > purposes or having a function accept one more argument than anyone > > else and break if it is called with fewer arguments > > > > - ones that standardize existing behavior, like the POSIX standard > > for operating systems, system calls, libraries, command shell, etc. > > > > Now, I've been on the POSIX mailing list for well nigh 20 years > > now, and let me tell you, trying to standardize something when > > different implementors have come up with *all kinds* of slightly > > different ways of doing *almost* the same thing can be... crazy. > > Insane. Amazingly, astonishingly, horrifyingly weird, and very > > time- and nerve-consuming. > > > > It seems to me that the people involved in developing the OpenPGP > > standard did, at one point, decide to go the other way: yes, sure, > > start with the existing PGP and GnuPG and other implementations, > > but then, when thinking about future work, decide to discuss things > > before implementing them (recent threads on the OpenPGP mailing list > > notwithstanding), so that it is sorta kinda expected that once > > various implementations gain the new features, they *will* be able > > to interoperate. That sounds... kind of reasonable to me. > > Just one more point that I forgot to write: *of course* it's fine for > people to implement experimental things to see if they'll work... > within reasonable bounds, of course, like not implementing new > algorithm identifiers outside the space reserved for experimental > ones. But it is also fine for other people to say "okay, sure, you > have your experimental features, but I'll wait until they're > standardized until I do the work on implementing them myself; also, > let's discuss whether they are even needed." Thanks for the write up, this mostly anwsers my question I had for Robert. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From rjh at sixdemonbag.org Sat May 16 17:56:47 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 16 May 2020 11:56:47 -0400 Subject: keys require a user-id In-Reply-To: <20200516153543.00004731.sac@300baud.de> References: <20200516013610.00002d06.sac@300baud.de> <20200516153543.00004731.sac@300baud.de> Message-ID: <8e59c733-31ba-fbc1-bdcb-16186cce4aae@sixdemonbag.org> > So, when you like to communicate with a person who uses such a new > key how do you proceed then? I tell them, "I will not be able to use OpenPGP with you until such time as you UID conforms to the standard. Would you like help in making your user ID standards-conformant in a way that reveals nothing about your real-world identity?" This is, in fact, the preferred GNU way. "I'd love to be able to work with you on this document, but you're using a proprietary format I can't read. There's an open format we can both use, though, and I'd be happy to help you get started with it." > How does this work in general, let's say I am a dev and would add this > too, to my OpenPGP app. Is there an OpenPGP board where devs can vote > for or against a feature, so that Werner has then to follow suite, or > is he in the position to say no and every dev has to follow his GnuPG > specs? The RFC is maintained under auspices of the Internet Engineering Task Force (IETF), just like every other RFC. The IETF's motto is "rough consensus and running code". Werner sits as secretary of the (largely dormant) group that guides OpenPGP development, but there are a lot of non-GnuPG people who are deeply involved in giving feedback on proposed changes. He's the secretary, not the dictator. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sat May 16 18:04:07 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 16 May 2020 12:04:07 -0400 Subject: keys require a user-id In-Reply-To: <20200516135511.GW140052@straylight.m.ringlet.net> References: <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <20200515221231.GP9891@straylight.m.ringlet.net> <20200516013610.00002d06.sac@300baud.de> <20200516135511.GW140052@straylight.m.ringlet.net> Message-ID: <61375c2d-8640-580a-7257-ff4b28eb0409@sixdemonbag.org> > GnuPG users can interact perfectly well with people who use OpenPGP > software :) As Robert J. Hansen said, if you (or somebody else) want to > extend the standard, there is an IETF working group and mailing list for > that. Please, just "Rob". :) I share a name with Robert "rsnake" Hansen of SecTheory. He and I have both spoken at Black Hat and DEF CON (which has sometimes led to hilarious results when journalists have tried to track us down to talk about our research). In order to reduce confusion I always use my middle initial professionally. But I go by Rob. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Sat May 16 19:17:17 2020 From: sac at 300baud.de (Stefan Claas) Date: Sat, 16 May 2020 19:17:17 +0200 Subject: keys require a user-id In-Reply-To: <8e59c733-31ba-fbc1-bdcb-16186cce4aae@sixdemonbag.org> References: <20200516013610.00002d06.sac@300baud.de> <20200516153543.00004731.sac@300baud.de> <8e59c733-31ba-fbc1-bdcb-16186cce4aae@sixdemonbag.org> Message-ID: <20200516191717.00002cd5.sac@300baud.de> Robert J. Hansen wrote: > > How does this work in general, let's say I am a dev and would add > > this too, to my OpenPGP app. Is there an OpenPGP board where devs > > can vote for or against a feature, so that Werner has then to > > follow suite, or is he in the position to say no and every dev has > > to follow his GnuPG specs? > > The RFC is maintained under auspices of the Internet Engineering Task > Force (IETF), just like every other RFC. The IETF's motto is "rough > consensus and running code". > > Werner sits as secretary of the (largely dormant) group that guides > OpenPGP development, but there are a lot of non-GnuPG people who are > deeply involved in giving feedback on proposed changes. He's the > secretary, not the dictator. Thanks for your reply, much appreciated! Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From johanw at vulcan.xs4all.nl Sat May 16 20:47:56 2020 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 16 May 2020 20:47:56 +0200 Subject: keys require a user-id In-Reply-To: <20200516135730.GA1093331@straylight.m.ringlet.net> References: <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <20200515221231.GP9891@straylight.m.ringlet.net> <20200516013610.00002d06.sac@300baud.de> <20200516135511.GW140052@straylight.m.ringlet.net> <20200516135730.GA1093331@straylight.m.ringlet.net> Message-ID: <690d9df5-9804-fea4-e1c4-dd7c44113117@vulcan.xs4all.nl> On 16-05-2020 15:57, Peter Pentchev wrote: > But it is > also fine for other people to say "okay, sure, you have your > experimental features, but I'll wait until they're standardized until > I do the work on implementing them myself; also, let's discuss whether > they are even needed." Have the bureaucrats who define standards have finally fixed the DOS issues about keys spammed with signatures or is it still being "discussed whether they are even needed."? This strictly following standards removes all flexibility from implementations. I am beginning to understand Moxie Marlinspike's ideas about all these committees holding back progress better and better. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Sat May 16 20:49:57 2020 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 16 May 2020 20:49:57 +0200 Subject: keys require a user-id In-Reply-To: <8e59c733-31ba-fbc1-bdcb-16186cce4aae@sixdemonbag.org> References: <20200516013610.00002d06.sac@300baud.de> <20200516153543.00004731.sac@300baud.de> <8e59c733-31ba-fbc1-bdcb-16186cce4aae@sixdemonbag.org> Message-ID: On 16-05-2020 17:56, Robert J. Hansen wrote: > I tell them, "I will not be able to use OpenPGP with you until such time > as you UID conforms to the standard. You confuse "not being able to" with "not willing to". -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sat May 16 22:28:58 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 16 May 2020 16:28:58 -0400 Subject: keys require a user-id In-Reply-To: <690d9df5-9804-fea4-e1c4-dd7c44113117@vulcan.xs4all.nl> References: <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <20200515221231.GP9891@straylight.m.ringlet.net> <20200516013610.00002d06.sac@300baud.de> <20200516135511.GW140052@straylight.m.ringlet.net> <20200516135730.GA1093331@straylight.m.ringlet.net> <690d9df5-9804-fea4-e1c4-dd7c44113117@vulcan.xs4all.nl> Message-ID: > Have the bureaucrats who define standards have finally fixed the DOS > issues about keys spammed with signatures or is it still being > "discussed whether they are even needed."? GnuPG had a bug in the key importation code which made it run in time proportional to the square of the number of signatures. Importing a certificate with 100,000 signatures was literally a hundred million times slower than importing a certificate with 10. That bug has since been fixed. With judicious use of the various -clean options, the key spamming bug is effectively dead... on the GnuPG side: on the SKS side, people are still filling up SKS keyservers with spam. SKS is a completely separate project from GnuPG, and has no RFC guiding it. So the "bureaucratic" project has it resolved, and the "free to innovate" project has been unable to innovate. (Note: I'm not blaming SKS. This is a hard problem. I personally don't think SKS can be saved.) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Sat May 16 22:49:55 2020 From: sac at 300baud.de (Stefan Claas) Date: Sat, 16 May 2020 22:49:55 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <665264269.20200515005157@mail.riseup.net> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> Message-ID: <20200516224955.00005826.sac@300baud.de> MFPA wrote: [...] > -----BEGIN PGP SIGNATURE----- > > iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl692adfFIAAAAAALgAo [...] > RjfdBwsdZJrUrgtu7YTLAf0/v9mZZBAXfvO8CgNySZfWWZ5IP0BvHLgkUXI0r7Qt > kuQMuu7LJiMJFrPQKIL1cQ== > =XcGg > -----END PGP SIGNATURE----- Hi, out of curiosity, you signed the reply with two sub keys, but what makes the signature so large, the hash algo used? I must admit I have never seen such a large signature before. And slightly OT, when not counting the two last short lines in the signature, 378 NaClbox public keys would fit in in the signature! :-) Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From sac at 300baud.de Sat May 16 23:00:41 2020 From: sac at 300baud.de (Stefan Claas) Date: Sat, 16 May 2020 23:00:41 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200516224955.00005826.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> Message-ID: <20200516230041.00005617.sac@300baud.de> Stefan Claas wrote: > MFPA wrote: > > [...] > > > -----BEGIN PGP SIGNATURE----- > > > > iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl692adfFIAAAAAALgAo > [...] > > > RjfdBwsdZJrUrgtu7YTLAf0/v9mZZBAXfvO8CgNySZfWWZ5IP0BvHLgkUXI0r7Qt > > kuQMuu7LJiMJFrPQKIL1cQ== > > =XcGg > > -----END PGP SIGNATURE----- > > Hi, > > out of curiosity, you signed the reply with two sub keys, but > what makes the signature so large, the hash algo used? I must > admit I have never seen such a large signature before. > > And slightly OT, when not counting the two last short lines > in the signature, 378 NaClbox public keys would fit in in > the signature! :-) Correction, a NaClbox key is 32 bytes but in an ASCII representation 64 ASCII chars long in the key ring, so it would 'only' be 189 public keys. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From dgouttegattat at incenp.org Sat May 16 23:07:22 2020 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 16 May 2020 22:07:22 +0100 Subject: keys require a user-id In-Reply-To: References: <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <20200515221231.GP9891@straylight.m.ringlet.net> <20200516013610.00002d06.sac@300baud.de> <20200516135511.GW140052@straylight.m.ringlet.net> <20200516135730.GA1093331@straylight.m.ringlet.net> <690d9df5-9804-fea4-e1c4-dd7c44113117@vulcan.xs4all.nl> Message-ID: <20200516210722.et65rec3xuutwgqz@dynein.local.incenp.org> On Sat, May 16, 2020 at 04:28:58PM -0400, Robert J. Hansen wrote: >With judicious use of the various -clean options, the key spamming bug >is effectively dead... I?d like to point out that the options you are referring to are actually enabled by default nowadays (since 2.2.17). So from an user?s point of view, the judicious thing to do is simply to use the latest GnuPG version available. I am pointing that out because people could interpret your comment as meaning that GnuPG requires some tinkering of its options in order to be safely usable with regard to the SKS spamming issue. That?s not the case; the default configuration is fine. - Damien -------------- 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 Sat May 16 23:09:00 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 16 May 2020 17:09:00 -0400 Subject: keys require a user-id In-Reply-To: <20200516210722.et65rec3xuutwgqz@dynein.local.incenp.org> References: <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <20200515221231.GP9891@straylight.m.ringlet.net> <20200516013610.00002d06.sac@300baud.de> <20200516135511.GW140052@straylight.m.ringlet.net> <20200516135730.GA1093331@straylight.m.ringlet.net> <690d9df5-9804-fea4-e1c4-dd7c44113117@vulcan.xs4all.nl> <20200516210722.et65rec3xuutwgqz@dynein.local.incenp.org> Message-ID: > I?d like to point out that the options you are referring to are actually > enabled by default nowadays (since 2.2.17). Thank you, Damien. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From angel at pgp.16bits.net Sun May 17 04:33:14 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 17 May 2020 04:33:14 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200516224955.00005826.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> Message-ID: <1589682794.1744.76.camel@16bits.net> On 2020-05-16 at 22:49 +0200, Stefan Claas wrote: > out of curiosity, you signed the reply with two sub keys, but > what makes the signature so large, the hash algo used? I must > admit I have never seen such a large signature before. It is quite large, indeed. This Radix 64 block of 12375 bytes contains two signatures, of 3857 and 5225 bytes respectively. The first one EdDSA (22) and the second a normal RSA one. In both cases, most of the signature space is taken by a hashed subpacket of type 38. This value is not assigned, but looking at https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=common/openpgpdefs.h#l123 it is used to store the whole key used. Cheers From jscott at posteo.net Sun May 17 05:24:23 2020 From: jscott at posteo.net (John Scott) Date: Sat, 16 May 2020 23:24:23 -0400 Subject: Help setting gpgsm to do LDAP lookup Message-ID: <1981097.e7OUTunqB3@t450> Hi, I'm stumped getting gpgsm to lookup S/MIME certificates in my organization. I've got a temporary working solution with ldapsearch after logging into my VPN with NetworkManager+OpenConnect: ldapsearch -Wt -b OU=Accounts,DC=ads,DC=foo,DC=com -D CN=jscott,OU=Accounts,DC=ads,DC=foo,DC=com '(mailNickname=[recipient])' userSMIMECertificate This saves the signed message to a temporary file which I do gpgsm --verify on, although the certs themselves are also stored in the userCertificate record IIRC. ldapsearch also works if I use only LDAPv2. My dirmngr_ldapservers.conf reads ads.foo.com:636:ads\jscott:PassPhrase:ou=Accounts,dc=ads,dc=foo,dc=com and to be extra safe I've put an explicit no-use-tor and ldapserverlist-file dirmngr_ldapservers.conf in my dirmngr.conf. Reloading dirmngr and gpgsm after getting on the VPN doesn't help. Looking up recipients with both dirmngr-client and gpgsm --verbose --list-external-keys [recipient] are fruitless whether I drop the ads\ from my username or not. I've bumped the ldaptimeout to 25. Still both commands finish instantaneously?not unlike ldapsearch however. $ gpgsm --debug-level expert -vvvvv --list-external-keys anything gpgsm: enabled debug flags: x509 crypto cache ipc gpgsm: DBG: chan_3 <- # Home: /home/john/.gnupg gpgsm: DBG: chan_3 <- # Config: /home/john/.gnupg/dirmngr.conf gpgsm: DBG: chan_3 <- OK Dirmngr 2.2.20 at your service gpgsm: DBG: connection to the dirmngr established gpgsm: DBG: chan_3 -> GETINFO version gpgsm: DBG: chan_3 <- D 2.2.20 gpgsm: DBG: chan_3 <- OK gpgsm: DBG: chan_3 -> OPTION audit-events=1 gpgsm: DBG: chan_3 <- OK gpgsm: DBG: chan_3 -> LOOKUP anything gpgsm: DBG: chan_3 <- OK secmem usage: 0/16384 bytes in 0 blocks I'm using 2.2.20 on Debian Bullseye. Other options set are add-servers in dirmngr.conf and auto-issuer-key-retrieve in gpgsm.conf. $ systemctl --user status dirmngr ? dirmngr.service - GnuPG network certificate management daemon Loaded: loaded (/usr/lib/systemd/user/dirmngr.service; static; vendor preset: enabled) Active: active (running) since Sat 2020-05-16 22:52:38 EDT; 23min ago TriggeredBy: ? dirmngr.socket Docs: man:dirmngr(8) Main PID: 26309 (dirmngr) CGroup: /user.slice/user-1000.slice/user at 1000.service/dirmngr.service ??26309 /usr/bin/dirmngr --supervised I also use GnuPG's SSH agent emulation and have in my .bashrc export GPG_TTY=$(tty) export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket) gpg-connect-agent updatestartuptty /bye >/dev/null -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From look at my.amazin.horse Sun May 17 10:03:46 2020 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sun, 17 May 2020 10:03:46 +0200 Subject: keys require a user-id In-Reply-To: <8e59c733-31ba-fbc1-bdcb-16186cce4aae@sixdemonbag.org> References: <8e59c733-31ba-fbc1-bdcb-16186cce4aae@sixdemonbag.org> <20200516013610.00002d06.sac@300baud.de> <20200516153543.00004731.sac@300baud.de> Message-ID: <3HVBSNFAJ8J0P.2U8VJGRXSGLDM@my.amazin.horse> > Werner sits as secretary of the (largely dormant) group that guides > OpenPGP development, but there are a lot of non-GnuPG people who are > deeply involved in giving feedback on proposed changes. He's the > secretary, not the dictator. Not everyone agrees. https://mailarchive.ietf.org/arch/msg/openpgp/XxZt89Eh7XUenuVRajbgtcWzWdA/ - V From look at my.amazin.horse Sun May 17 10:48:43 2020 From: look at my.amazin.horse (Vincent Breitmoser) Date: Sun, 17 May 2020 10:48:43 +0200 Subject: keys require a user-id In-Reply-To: <20200515221231.GP9891@straylight.m.ringlet.net> References: <20200515221231.GP9891@straylight.m.ringlet.net> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> Message-ID: <2M6532HHN1IW3.3HP964935JLXC@my.amazin.horse> Hey folks, this thread touches on userid-less keys, and keyservers. I agree with Peter and Rob's points that userid-less keys are questionable for use as-is. OpenPGP transfers information in the self-signatures of user ids. If we use keys without any known UID, we might miss out on e.g. expiration dates, or key flags. There is one more angle to this topic: key updates. keys.openpgp.org uses userid-less keys in some cases, to distribute revocations and subkey updates. More specifically, this happens when no User ID on a key has been verified. The logic is simple: 1. Without consent, we don't distribute email addresses. 2. We want to distribute revocations and subkey updates regardless. 3. Revocations and key updates are cryptographically independent from User IDs. A key store that already has a UserID for some key can integrate revocation certificates and subkey updates from such a userid-less key into its local certificate. Implementation-wise, this is easy to do. GnuPG upstream rejects such updates. Conretely, if you hand a primary key with only a revocation signature to GnuPG, it will parse the revocation, verify that it is cryptographically valid, and then throw it away. For those interested, this issue has been discussed at length here: https://dev.gnupg.org/T4393 Cheers - V From sac at 300baud.de Sun May 17 13:12:40 2020 From: sac at 300baud.de (Stefan Claas) Date: Sun, 17 May 2020 13:12:40 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <1589682794.1744.76.camel@16bits.net> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> <1589682794.1744.76.camel@16bits.net> Message-ID: <20200517131240.00004c16.sac@300baud.de> ?ngel wrote: > On 2020-05-16 at 22:49 +0200, Stefan Claas wrote: > > out of curiosity, you signed the reply with two sub keys, but > > what makes the signature so large, the hash algo used? I must > > admit I have never seen such a large signature before. > > It is quite large, indeed. This Radix 64 block of 12375 bytes contains > two signatures, of 3857 and 5225 bytes respectively. The first one > EdDSA (22) and the second a normal RSA one. > > In both cases, most of the signature space is taken by a hashed > subpacket of type 38. This value is not assigned, but looking at > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=common/openpgpdefs.h#l123 > it is used to store the whole key used. Interesting, thanks for the explanation! Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From azbigdogs at gmx.com Mon May 18 01:21:48 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 17 May 2020 16:21:48 -0700 Subject: keys require a user-id In-Reply-To: <8e59c733-31ba-fbc1-bdcb-16186cce4aae@sixdemonbag.org> References: <20200516013610.00002d06.sac@300baud.de> <20200516153543.00004731.sac@300baud.de> <8e59c733-31ba-fbc1-bdcb-16186cce4aae@sixdemonbag.org> Message-ID: <48cac95e-c843-b32b-210b-a17c53b43a30@gmx.com> I'm just curious as to what this "GNU" way is? I assume you would just a non identifiable email address and then either leave your name blank, incomplete, or just plain incorrect. Is there another way I am missing? Thanks On 5/16/2020 8:56 AM, Robert J. Hansen wrote: >> So, when you like to communicate with a person who uses such a new >> key how do you proceed then? > I tell them, "I will not be able to use OpenPGP with you until such time > as you UID conforms to the standard. Would you like help in making your > user ID standards-conformant in a way that reveals nothing about your > real-world identity?" > > This is, in fact, the preferred GNU way. "I'd love to be able to work > with you on this document, but you're using a proprietary format I can't > read. There's an open format we can both use, though, and I'd be happy > to help you get started with it." > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From azbigdogs at gmx.com Mon May 18 01:23:21 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 17 May 2020 16:23:21 -0700 Subject: Best Keyserver In-Reply-To: <2eced9d63b331ff7ac5118fc04f98df01a05ea75.camel@gentoo.org> References: <2eced9d63b331ff7ac5118fc04f98df01a05ea75.camel@gentoo.org> Message-ID: <65b7b856-ed70-ddfe-e8ff-32b6e21471f1@gmx.com> Thanks I will update it and make sure both Kleopatra and Enigmail are using the same one so they are "on the same page" On 5/15/2020 11:55 PM, Micha? G?rny wrote: > On Fri, 2020-05-15 at 16:52 -0700, Mark wrote: >> I know this may be a subjective question but what is the best keyserver >> to use? I use GPG4Win with the Enigmail plugin for Thunderbird. The >> keyservers listed in Enigmail are: >> >> vks://keys.openpgp.org, hkps://hkps.pool.sks-keyservers.net, >> hkps://pgp.mit.edu >> >> The keyserver that is used in Kelopatra (GPG4Win) is: >> >> hkp://keys.gnupg.net > $ host keys.gnupg.net > keys.gnupg.net is an alias for hkps.pool.sks-keyservers.net. > From azbigdogs at gmx.com Mon May 18 01:32:44 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 17 May 2020 16:32:44 -0700 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> Message-ID: <7ad36213-8e34-b995-265f-87aabfc3087a@gmx.com> Thanks to all the people that chimed in on my question. I was trying to get an idea how they compared. It was (for me) even more confusing with the 25519 choices as I didn't know the size of those keys until someone explained them better. On 5/11/2020 6:46 PM, Pete Stephenson via Gnupg-users wrote: > On Mon, May 11, 2020, at 5:15 PM, Mark wrote: >> I'm trying to understand the differences in strength between an RSA key >> and an elliptical one such ed25519 with cv25519. I know with RSA it is >> pretty easy to "gauge" the strength 1024 vs 2048 vs 4096.? >> >> I could not really find anything to say how strong these elliptical keys >> are and how they compare to RSA ones.? > Good question! Broadly, and with several assumptions, elliptic curves have the same security level as symmetric (e.g., AES) keys that are half the elliptic key's length. See https://en.m.wikipedia.org/wiki/Key_size and the references therein as a starting point. > > For example, a 256 bit elliptic curve key has a similar strength to a symmetric key of 128 bits. > > Due to various reasons, not all ECC keys are powers of 2 in length. For example, NIST P-521 is 521 bits long rather than 512 bits, and has equivalent security to a 256 bit symmetric key. > > Cheers! > -Pete > From rjh at sixdemonbag.org Mon May 18 02:23:23 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 17 May 2020 20:23:23 -0400 Subject: keys require a user-id In-Reply-To: <48cac95e-c843-b32b-210b-a17c53b43a30@gmx.com> References: <20200516013610.00002d06.sac@300baud.de> <20200516153543.00004731.sac@300baud.de> <8e59c733-31ba-fbc1-bdcb-16186cce4aae@sixdemonbag.org> <48cac95e-c843-b32b-210b-a17c53b43a30@gmx.com> Message-ID: <38f4a84e-a5e3-8812-7a5f-7be509d1d625@sixdemonbag.org> > I'm just curious as to what this "GNU" way is? I assume you would > just a non identifiable email address and then either leave your > name blank, incomplete, or just plain incorrect. GNU is a project by the Free Software Foundation. They're very focused on what they call "free software", where freedom is about liberty and not price. (Most people call it "open source software" instead, but FSF and GNU are very particular about the language they use.) FSF and GNU are both very concerned about the spread of proprietary formats. For instance, for many years only Microsoft Word could read .doc files. This was a problem for people who wished to only use free software. So the FSF/GNU way was, whenever someone tried to send them a document in a proprietary format, was to tell the sender > "I'd love to be able to work with you on this document, but you're > using a proprietary format I can't read. There's an open format we > can both use, though, and I'd be happy to help you get started with > it." GnuPG is part of the GNU project. I think we should use the standard GNU response when people want us to use certificate formats that don't comply with the OpenPGP standard. You can learn more about the FSF at: https://www.fsf.org/about/ You can learn more about GNU at: http://www.gnu.org/gnu/about-gnu.html Hope this helps. From wk at gnupg.org Mon May 18 08:14:14 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 May 2020 08:14:14 +0200 Subject: keys require a user-id In-Reply-To: <2M6532HHN1IW3.3HP964935JLXC@my.amazin.horse> (Vincent Breitmoser via Gnupg-users's message of "Sun, 17 May 2020 10:48:43 +0200") References: <20200515221231.GP9891@straylight.m.ringlet.net> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <2M6532HHN1IW3.3HP964935JLXC@my.amazin.horse> Message-ID: <87a72593d5.fsf@wheatstone.g10code.de> On Sun, 17 May 2020 10:48, Vincent Breitmoser said: > 1. Without consent, we don't distribute email addresses. And by that changing the distributed system of keyservers into a centralized key database like PGP tried this with their Universal Server. Which unavoidable will change OpenPGP to a centralized systems. If you want that use X.509 or to get complete centralization use Signal. > 2. We want to distribute revocations and subkey updates regardless. Go readup on the failures and impracticalities of CRLs and OCSP. > GnuPG upstream rejects such updates. Conretely, if you hand a primary > key with only a revocation signature to GnuPG, it will parse the > revocation, verify that it is cryptographically valid, and then throw There is a simple reason for that: You don't want to type in an entire keyblock in the case you need to revoke your key and you only got the printout of the revocation certificate. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon May 18 08:33:47 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 May 2020 08:33:47 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <1589682794.1744.76.camel@16bits.net> (=?utf-8?Q?=22=C3=81nge?= =?utf-8?Q?l=22's?= message of "Sun, 17 May 2020 04:33:14 +0200") References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> <1589682794.1744.76.camel@16bits.net> Message-ID: <875zct92gk.fsf@wheatstone.g10code.de> On Sun, 17 May 2020 04:33, ?ngel said: > In both cases, most of the signature space is taken by a hashed > subpacket of type 38. This value is not assigned, but looking at You are using --include-key-block; this is intended to be used by MUAs to send the encryption key along with a signature to allow for immediate encrypted reply. This is similar to what has been done in S/MIME for decades and a mitigation to the comedown of the keyservers. MUAs may decide not to use this on mailing lists - if short mails are important. Or use it only with ECC keys. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon May 18 08:53:55 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 May 2020 08:53:55 +0200 Subject: Help setting gpgsm to do LDAP lookup In-Reply-To: <1981097.e7OUTunqB3@t450> (John Scott via Gnupg-users's message of "Sat, 16 May 2020 23:24:23 -0400") References: <1981097.e7OUTunqB3@t450> Message-ID: <87y2pp7myk.fsf@wheatstone.g10code.de> On Sat, 16 May 2020 23:24, John Scott said: > Looking up recipients with both dirmngr-client and > gpgsm --verbose --list-external-keys [recipient] > are fruitless whether I drop the ads\ from my username or not. I've bumped the > ldaptimeout to 25. Still both commands finish instantaneously?not unlike I just did a quick test using using ldap.pca.dfn.de::::o=DFN-Verein,c=DE:ldap which works as expected. It has no username and password, though. To better debug this you should add --8<---------------cut here---------------start------------->8--- verbose log-file socket:// debug ipc,lookup,extprog no-use-tor --8<---------------cut here---------------end--------------->8--- (if you are not using watchgnupg, repalce socket:// by a regular file name) This gives more specifc debug output. (BTW, "dirmngr --debug help" shows all debug options). Instead of using gpgsm it is often easier to use gpg-connect-agent: $ gpg-connect-agent --dirmngr > /hex > lookup Werner D[0000] 30 82 05 AF 30 82 04 97 A0 03 02 01 02 02 0C 1D 0...0........... D[0010] B0 E4 78 EA 1D 5C 64 E5 03 8C 9E 30 25 30 44 06 ..x..\d....0%0D. [...] END S TRUNCATED 3 OK Look at the log file while running these commands; hopefully you see an error message. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Mon May 18 13:12:02 2020 From: sac at 300baud.de (Stefan Claas) Date: Mon, 18 May 2020 13:12:02 +0200 Subject: keys require a user-id In-Reply-To: <20200515190740.00006d15.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> Message-ID: <20200518131202.00004579.sac@300baud.de> Stefan Claas wrote: > Robert J. Hansen wrote: > > If you want the documentation to reflect PII-free UIDs, please say > > that. This could be a useful discussion. If the community believes > > PII-free UIDs should be in the FAQ I will happily write up an entry > > for it. > > Please discuss it with the community and try to add it later to the > documentation as equally treated, in the key generation process. I would like to start the discussion, because I like to point out one more thing, why I like the UID-less and label approach, compared to a freeform UID. Let's say I would regularly communicate with you, dkg and Werner etc. In sequoia I would import the public keyblocks and could label them, for example with rjh or rob, dkg and wk and would then use for the recipient parameter -r rob -r dkg -r wk, which I can easily memorize. With the freeform approach, when I would have to use (auto) generated random chars or the fingerprint then I would have problems memorizing if this was your, dkg's or Werner's public keyblock and it could be also more error prone (typos), when using this method, in CLI mode. You can argue now that you can give a freeform UID the name rob or rjh too, but this would maybe not so good, because your are publicity known as rob or rjh, thus defeating the purpose a bit. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From andrewg at andrewg.com Mon May 18 13:28:27 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 18 May 2020 12:28:27 +0100 Subject: keys require a user-id In-Reply-To: <20200518131202.00004579.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200518131202.00004579.sac@300baud.de> Message-ID: <5c627438-68f0-593c-dfa2-736f53bb5e21@andrewg.com> On 18/05/2020 12:12, Stefan Claas wrote: > You can argue now that you can give a freeform UID the name rob or rjh > too, but this would maybe not so good, because your are publicity known > as rob or rjh, thus defeating the purpose a bit. If your threat model includes your endpoint device being compromised and leaking your contact list, then you should be implementing an extra layer of protection such as Tails and/or a hidden VeraCrypt volume. In the vast majority of scenarios, endpoint compromise is Game Over, and tinkering with obfuscation will not help you. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Mon May 18 14:05:41 2020 From: sac at 300baud.de (Stefan Claas) Date: Mon, 18 May 2020 14:05:41 +0200 Subject: keys require a user-id In-Reply-To: <5c627438-68f0-593c-dfa2-736f53bb5e21@andrewg.com> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200518131202.00004579.sac@300baud.de> <5c627438-68f0-593c-dfa2-736f53bb5e21@andrewg.com> Message-ID: <20200518140541.00001c8a.sac@300baud.de> Andrew Gallagher wrote: > On 18/05/2020 12:12, Stefan Claas wrote: > > You can argue now that you can give a freeform UID the name rob or > > rjh too, but this would maybe not so good, because your are > > publicity known as rob or rjh, thus defeating the purpose a bit. > > If your threat model includes your endpoint device being compromised > and leaking your contact list, then you should be implementing an > extra layer of protection such as Tails and/or a hidden VeraCrypt > volume. In the vast majority of scenarios, endpoint compromise is > Game Over, and tinkering with obfuscation will not help you. Agreed! It should be also mentioned, that if UID-less public keyblocks end up more and more on keyservers it is harder for 3rd parties to maintain a database, since as you know, everybody is still be able to download complete keyserver dumps from SKS. Thanks to Vincent this is no longer possible with Hagrid! Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From rjh at sixdemonbag.org Mon May 18 18:16:58 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 18 May 2020 12:16:58 -0400 Subject: keys require a user-id In-Reply-To: <87a72593d5.fsf@wheatstone.g10code.de> References: <20200515221231.GP9891@straylight.m.ringlet.net> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <2M6532HHN1IW3.3HP964935JLXC@my.amazin.horse> <87a72593d5.fsf@wheatstone.g10code.de> Message-ID: > And by that changing the distributed system of keyservers into a > centralized key database like PGP tried this with their Universal > Server. Which unavoidable will change OpenPGP to a centralized systems. I think that's a little excessive, Werner. OpenPGP was always intended to be flexible on the subject of certificate distribution, and there are many use cases where a single authoritative keyserver is preferred over a distributed federation. In 2001 I was the chief system administrator for a law firm which used OpenPGP to secure client communications. (It didn't require clients to use OpenPGP but provided it as an option for clients who were concerned about email privacy.) The procedure was simple: when you opted into OpenPGP you showed up at your attorney's office in person with your certificate burned on a CD. Your attorney then called in a member of the sysadmin staff (usually me) who would check fingerprints with you, before signing it with the firm's trusted-introducer key and uploading it to the firm's own keyserver. Doing it this way meant we could skip long conversations about, "but can't anybody get my certificate if it's on the internet?" Instead of spending 30 minutes talking about why it's okay if public certificates are shared, we could instead just say "we're not going to share your public key with anyone without your written consent" and spend those 30 minutes talking abut more productive things. Centralized key management schemes are sometimes very useful. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Mon May 18 21:08:16 2020 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Mon, 18 May 2020 21:08:16 +0200 Subject: keys require a user-id In-Reply-To: References: <20200515221231.GP9891@straylight.m.ringlet.net> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <2M6532HHN1IW3.3HP964935JLXC@my.amazin.horse> <87a72593d5.fsf@wheatstone.g10code.de> Message-ID: <7cf33de1-0b42-1306-1a55-10191cc9903f@vulcan.xs4all.nl> On 18-05-2020 18:16, Robert J. Hansen wrote: > Instead of > spending 30 minutes talking about why it's okay if public certificates > are shared, we could instead just say "we're not going to share your > public key with anyone without your written consent" and spend those 30 > minutes talking abut more productive things. Which might be a good thing for those customers, the fact alone that someone is a customer of a certain law firm might be sensitive information in some cases. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon May 18 22:56:04 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 May 2020 22:56:04 +0200 Subject: keys require a user-id In-Reply-To: (Robert J. Hansen's message of "Mon, 18 May 2020 12:16:58 -0400") References: <20200515221231.GP9891@straylight.m.ringlet.net> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <2M6532HHN1IW3.3HP964935JLXC@my.amazin.horse> <87a72593d5.fsf@wheatstone.g10code.de> Message-ID: <875zct6jyz.fsf@wheatstone.g10code.de> On Mon, 18 May 2020 12:16, Robert J. Hansen said: > Centralized key management schemes are sometimes very useful. I fully agree and I personally known that this is a common use case. However, people requiring such a use case do not talk in the public about their specific infrastructure and are also not affected by the alleged privacy enhancements needs people are talking about. The nice thing with OpenPGP is that you can implement any kind of PKI with it and you are not as restricted as with X.509/PKIX. And it is just one RFC and not several dozens RFCs and other documents you all need to read, analyze, and guess like we see the PKIX world. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue May 19 16:29:26 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 19 May 2020 10:29:26 -0400 Subject: keys require a user-id In-Reply-To: <20200518131202.00004579.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200518131202.00004579.sac@300baud.de> Message-ID: <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> > With the freeform approach, when I would have to use (auto) generated > random chars or the fingerprint then I would have problems memorizing > if this was your, dkg's or Werner's public keyblock and it could be > also more error prone (typos), when using this method, in CLI mode. --group {name=value} Sets up a named group, which is similar to aliases in email pro? grams. Any time the group name is a recipient (-r or --recipi? ent), it will be expanded to the values specified. Multiple groups with the same name are automatically merged into a single group. The values are key IDs or fingerprints, but any key description is accepted. Note that a value with spaces in it will be treated as two different values. Note also there is only one level of expansion --- you cannot make an group that points to another group. When used from the command line, it may be necessary to quote the argument to this option to prevent the shell from treating it as multiple arguments. The feature you want, GnuPG already has. If my certificate had no email address listed, you could put group rjh at sixdemonbag.org=0x1DCBDC01B44427C7 ... and then whenever you asked GnuPG to encrypt something for rjh at sixdemonbag.org, GnuPG would silently substitute my certificate. So let's recap: * PII-free UIDs are possible today * Nobody is forced to put PII in a UID * Certificates can be relabeled with the 'group' option It really seems like after all this discussion the only thing left is you think GnuPG ought do a better job documenting how to create a PII-free UID. And if you can get the community to back you on that I'll draft it myself. From sac at 300baud.de Tue May 19 17:22:18 2020 From: sac at 300baud.de (Stefan Claas) Date: Tue, 19 May 2020 17:22:18 +0200 Subject: keys require a user-id In-Reply-To: <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200518131202.00004579.sac@300baud.de> <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> Message-ID: <20200519172218.00002279.sac@300baud.de> Robert J. Hansen wrote: > > With the freeform approach, when I would have to use (auto) > > generated random chars or the fingerprint then I would have > > problems memorizing if this was your, dkg's or Werner's public > > keyblock and it could be also more error prone (typos), when using > > this method, in CLI mode. > --group {name=value} > Sets up a named group, which is similar to aliases in email > pro? grams. Any time the group name is a recipient (-r or --recipi? > ent), it will be expanded to the values specified. > Multiple groups with the same name are automatically merged into a > single group. > > The values are key IDs or fingerprints, but any key > description is accepted. Note that a value with spaces in it will be > treated as two different values. Note also there is only one level > of expansion --- you cannot make an group that points to another > group. When used from the command line, it may be necessary > to quote the argument to this option to prevent the shell from > treating it as multiple arguments. > > The feature you want, GnuPG already has. If my certificate had no > email address listed, you could put > > group rjh at sixdemonbag.org=0x1DCBDC01B44427C7 > > ... and then whenever you asked GnuPG to encrypt something for > rjh at sixdemonbag.org, GnuPG would silently substitute my certificate. Thanks for the info, I was not aware of it. > So let's recap: > > * PII-free UIDs are possible today > * Nobody is forced to put PII in a UID > * Certificates can be relabeled with the 'group' option > > It really seems like after all this discussion the only thing left is > you think GnuPG ought do a better job documenting how to create a > PII-free UID. And if you can get the community to back you on that > I'll draft it myself. I doubt that I can get the community to back this ... But thanks for the offer. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From 2017-r3sgs86x8e-lists-groups at riseup.net Wed May 20 01:41:22 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Wed, 20 May 2020 00:41:22 +0100 Subject: keys require a user-id In-Reply-To: <20200515221231.GP9891@straylight.m.ringlet.net> References: <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <20200515221231.GP9891@straylight.m.ringlet.net> Message-ID: <46734971.20200520004122@mail.riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 15 May 2020 at 11:12:31 PM, in , Peter Pentchev wrote:- > to generate a random UID? Would a random UID be the way to go? How about a placeholder UID that was replaced at the end of key generation by a UID that matches the key-ID or fingerprint? - -- Best regards MFPA Do what you can, with what you have, where you are. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXsRutl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +jZJAQDVaEo+PB3C0QTUfb7gctrOWZKtXCKPDkqCiv8V++1K5wD8CHrq0AOsORzX Kv5zqkj8FJDcQvRdK4UkUv3LNKtUQwCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXsRutl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/+7PEACgIrT0WJ11w3B/IXOxr8CtFVCW 4cCUlu2mWyGC2ZJolwtWvvEf5MPkd5qlBJ78y8sjG7VovZQeyd058dhFO6ScO7xs zhdcPDGG88XE0KuHyPDaabty5s3/ZeTRIELcOf7WmKWO28MlDIe62b6uS9/10Hj6 HkGFbJovrX3x/NLdGo9Icg2UD4OduXQga+AA+qDWrqZQUeqAQSKA5+4YKqrviaZF QBaYzUuUoAkjoVQ8DqB0a04qgvQ+ctcW+5OL6d2hMLEAFE5WWHS2MSDNAlUsESKP Uo1zWal7DwlRCXta6QQVji4oX5w8/GPvXMNqVJkqcu6+KFDimBKSg1Rasl+BTBln OZHY0YWGW1wTXC7xqHa/AHjW+MbL/n2IOMIxIWxmVWqbAV6WpSt+CMj5x0pnRc7V lwN8mXA1Fh9PgLnPzPJnr/BSvNbH+yGKv3KZXLm3s97QI7KZjX0S2uXDdKNhoZe2 I9lmneUP44OHXBxODdPdPF0pBPZ1H5eLn4QB1LLYWk0Q/zby0UIa+XOKAoQ+F3ub 41OjN3ocImQj7FsqWjWZ9hOB8QyvN1e+3hVYzwwp3+nksx+q+357oyXj+m1adwGG DZj2y5AgWdvgp82VneBNI2i8AJfGiOvJ6bRusjAUe3CbgulQvjict6MOULTZ6uDI 9AeVasGsXEmmIn6KPA== =Xl+u -----END PGP SIGNATURE----- From azbigdogs at gmx.com Wed May 20 07:31:27 2020 From: azbigdogs at gmx.com (Mark) Date: Tue, 19 May 2020 22:31:27 -0700 Subject: keys require a user-id In-Reply-To: <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200518131202.00004579.sac@300baud.de> <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> Message-ID: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> Just to test this out I tried creating a new key in Kleopatra with no name and then with just a single name and it would not let me do it. It had to have a first and at least a last initial.? On 5/19/2020 7:29 AM, Robert J. Hansen wrote: >> With the freeform approach, when I would have to use (auto) generated >> random chars or the fingerprint then I would have problems memorizing >> if this was your, dkg's or Werner's public keyblock and it could be >> also more error prone (typos), when using this method, in CLI mode. > --group {name=value} > Sets up a named group, which is similar to aliases in email pro? > grams. Any time the group name is a recipient (-r or --recipi? > ent), it will be expanded to the values specified. Multiple > groups with the same name are automatically merged into a single > group. > > The values are key IDs or fingerprints, but any key description > is accepted. Note that a value with spaces in it will be treated > as two different values. Note also there is only one level of > expansion --- you cannot make an group that points to another > group. When used from the command line, it may be necessary to > quote the argument to this option to prevent the shell from > treating it as multiple arguments. > > The feature you want, GnuPG already has. If my certificate had no email > address listed, you could put > > group rjh at sixdemonbag.org=0x1DCBDC01B44427C7 > > ... and then whenever you asked GnuPG to encrypt something for > rjh at sixdemonbag.org, GnuPG would silently substitute my certificate. > > So let's recap: > > * PII-free UIDs are possible today > * Nobody is forced to put PII in a UID > * Certificates can be relabeled with the 'group' option > > It really seems like after all this discussion the only thing left is > you think GnuPG ought do a better job documenting how to create a > PII-free UID. And if you can get the community to back you on that I'll > draft it myself. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From andrewg at andrewg.com Wed May 20 09:27:49 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 20 May 2020 08:27:49 +0100 Subject: keys require a user-id In-Reply-To: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> Message-ID: > On 20 May 2020, at 06:32, Mark wrote: > > Just to test this out I tried creating a new key in Kleopatra with no > name and then with just a single name and it would not let me do it. It > had to have a first and at least a last initial. This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line. Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example. A From andrewg at andrewg.com Wed May 20 11:55:51 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 20 May 2020 10:55:51 +0100 Subject: keys require a user-id In-Reply-To: <87a72593d5.fsf@wheatstone.g10code.de> References: <20200515221231.GP9891@straylight.m.ringlet.net> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200515193311.GR140052@straylight.m.ringlet.net> <20200515225432.000050db.sac@300baud.de> <2M6532HHN1IW3.3HP964935JLXC@my.amazin.horse> <87a72593d5.fsf@wheatstone.g10code.de> Message-ID: On 18/05/2020 07:14, Werner Koch via Gnupg-users wrote: > Go readup on the failures and impracticalities of CRLs and OCSP. While I agree that revocation is a Very Hard Problem, I'm not convinced that its abandonment is warranted. Letsencrypt have sidestepped the issue by issuing short-expiration certs and requiring users to continually refresh. This is practical for servers under X509 (where automation is easy and the trust model is centralised) but not for hyper-distributed PGP. So while revocation cannot be entirely relied upon, it's still better than nothing and I think we should continue to support it as best we can. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed May 20 18:07:35 2020 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 May 2020 18:07:35 +0200 Subject: keys require a user-id In-Reply-To: <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 19 May 2020 10:29:26 -0400") References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200518131202.00004579.sac@300baud.de> <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> Message-ID: <87sgfu4mk8.fsf@wheatstone.g10code.de> On Tue, 19 May 2020 10:29, Robert J. Hansen said: > * PII-free UIDs are possible today Well, according to European law this is not that easy because a public key is in most cases an attribute which identifies a natural person. This is the same as with phone numbers and mail addresses. In Germany even dynamically assigned IP addresses are attributes which can be used to identify a person and thus are subject to GDPR. OTOH, the GDPR does not forbid the use of this data, there are just rules on how they can be used. WP describes the basic rules as: Unless a data subject has provided informed consent to data processing for one or more purposes, personal data may not be processed unless there is at least one legal basis to do so. Article 6 states the lawful purposes are: (a) If the data subject has given consent to the processing of his or her personal data; (b) To fulfill contractual obligations with a data subject, or for tasks at the request of a data subject who is in the process of entering into a contract; (c) To comply with a data controller's legal obligations; (d) To protect the vital interests of a data subject or another individual; (e) To perform a task in the public interest or in official authority; (f) For the legitimate interests of a data controller or a third party, unless these interests are overridden by interests of the data subject or her or his rights according to the Charter of Fundamental Rights (especially in the case of children). IMHO, point d covers the case of distributing and using a public key for the purpose of securing the communication with the data subject. The key may of course not be used for any other purpose (i.e. tracking behaviour etc). Hacker be aware, the lay is not a machine, it works different than we tend to assume. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Wed May 20 19:06:32 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Wed, 20 May 2020 18:06:32 +0100 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <875zct92gk.fsf@wheatstone.g10code.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> <1589682794.1744.76.camel@16bits.net> <875zct92gk.fsf@wheatstone.g10code.de> Message-ID: <1337448496.20200520180632@mail.riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 18 May 2020 at 7:33:47 AM, in , Werner Koch via Gnupg-users wrote:- > You are using --include-key-block; this is intended > to be used by MUAs > to send the encryption key along with a signature to > allow for immediate > encrypted reply. I forgot I had added that to my gpg.conf file. If the recipient has --auto-key-import set, they auto-import my key after signature verification. But my choice to not include my email address in my UID means they would not easily locate my key to send me an encrypted reply. > Or use it only with ECC keys. Does (or will) --include-key-block have an argument that can be set to tell it to only include ECC keyblocks, or to set a maximum keyblock size? - -- Best regards MFPA Volvo, Video, Velcro. (I came, I saw, I stuck around.) -----BEGIN PGP SIGNATURE----- iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl7FY6hfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 MEM4NjI4RDU5MkZGOENERThCQjBCRkUwRTJERUUxRDZDOEVFRkHNeiYAmQINBFmF 3poBEACjmnBUOd79vOc6sywdw7d85ItYQDeSh5WhTguXkt84+8C+oLXYbWelVmyj tZ+vOsZSXb44tE2zNCWouNK/wcE16JmmIV3VVn9I/EpMTK/iFx3e/SGk6C56uopg sQFlDjbYRZ6bPc+ImsEdfaj3DyYrWJO3dCEBEEOv4/u7UZ/ulBJOEW4pCJjgk7es mT9LmG0AvSSUZhZQqqMo5wvrfz07uDbJ6MFjPXgBIThtJPjKSpTXCaaCs2GJZVkK agR1rexytIgsEU3OYHAl+qYfHqcFqa1xbrdEjC8RDFIU0vJc3aGpRufGEVlnDw/L fWN6qX4NE9IC/QyKFXEQOybP9UEl9ti/dE6FUSHT+g/M4zCdSL1RFMkz91/Unjgr ZAboMoKgBZqYLpawjYIyVMYTdIerDQYiymCdD+Ifkgc3FwgTsfSFnFJXwLL2hqJG oZSz6jHKKiDDKathLQqWEvAbCo6FP5VsqILi2Tu+6IWOeLp07YXzDiDNR7/yqDGO CavYmwN3mt5TwdNeOd22LFWHLBcsDc5gIB2EkJoMpemG1TJi60FX9P2WI8K7ICBm FzwnvH9i2xBln+4+YDHyod7clC1I0wE2BbO6ttNaUR/6Xczm8gjx0zzKsvOZZDTX jXtO8ss41j7Rg0TS3C4+QWMcmHCJCiu8tD4GS5du/V5xw8TJ8QARAQABtBIweEFD RTU2OTcxRDU1NURBQTWJAl4EEwEKAEgCGwECHgECF4ACGQELCw0JCAwHAwsKBAIG FQoJCAsDBRYDAgEAFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGFwFCQnQtEIA CgkQrOVpcdVV2qU6AQ/9EaAae++qSxy9iM2a3Jfbqr5kEV+mJ//r6SIoDJPVANfb 5oHF/KZtF0a+SXR+cPPBMVKsppZ0Qr80FkjAUOH5YuUbTq2B+YvqMo5DLqBa2QiC ax6x11udSI0IM2CL7I5vMcRuY+Z/P3FZ9RI+C7ALL+EgJ6xtFyYHOcVVYd/a0O/O TH9KOVwcdtDChrRZBOC46+5hlcFxd3nwMUmXpRD1PE5+20vUbmyz2uKjHn93fOh2 MNMLhoO9qci+kKliawuU7UQ42VTO6FtUSoUpgPh37sVMImezC4jYm/1d3AFPCxpA jP7mHgKxOwP6fw+hIEWoybv0Ws3BEhM4TInobQUs0wdsWLQ83x5L9IvEcL643mkL bxCA48Fiw2YTWyuEdhIeSOtLTrM2k5xDVX5kPASGqG7rTP/exBo5Vg2UZWhPJuiE fYaJR7PAl0i+318yQShIWg0Zt1Ob3K7/3yqvHDFzaAaKOlN9CZR5XVEcyq9G6M2u u5cOZ0LQJTn/UFHYOK8D9/T33Zfac8tIjiIn916i1YvqYIzS14GKS8oqISy3FkD3 2tQf8ok/8PvnXe1xQPTAtIj3UqpiQf0L8xt96hLJHKphmR/ksKYBDdZFWRD/U0Na kXjnepP0ek68fR3wO4lbYKG9x94YDM/7pQ1BpfZZMLrp+3xvTBxmgQCtAuUiJem5 Ag0EWYXwgAEQAO+wh3g3SgeBWkzLaIHo3p7Z92CyEnssgvZnfaWNBowuv1INtprq a15yRpaIr8eFlchlVqCiQ2FN54tWkND5qlallwi2YSUW+nkEXCvyUR1S///MmwI5 qos0A+Sil3uPsuBQtRezCaNEghM5a83Lfvv9kYqzfa9D6gCYUCv6NtbH/yeshOuR hT2P3jFK0+kIObyPO26XsbfdbocutYA3c/27TAsE8VJvu4yqL5CUvz5H+EzGAdmr XVYD/VFxMrbIkKjmb7I0Tnl8RF3IUsL3SK/AKWYPOI4mMp5dv4yO/gYVoWX5Fd4d v6EQmvHMfiIvsxP8EBOTNVEtj/rac4P7Trdsc7CWsL5zzpofxIFQibo3JVNTRs/P PIlVmPROYLbXaolufgAmi+E8BCer780yc4nkmWOEcepuk3cQCM3l6OrgI8aWQyrc f4uW4Jtn98AldJ21PhtN4A0d5PF0YvX/OrXoi3XBROUVLY6IF5QbkSMeOvqJWzgk txvULI53Q3jtZvgtmF2dZ5rFgJCy3PjuXRBi2ZTz47eW94E7xDr04euhFnyMaiDM KS0XAj978kyCUrtDsssWp83j1IZt5Bd7JmtohThlEZCQ3Y0u3Gjmj9Nkv18qmF8O 21Qe0LzG8Ad9HPTbQd9Rk+GQz57WxlcsjK2bC0WG7f6R5BHq1YmuoD8nABEBAAGJ AjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb74QAK CRCs5Wlx1VXapXcrD/9ktCowTIi5PtKUCjuttsaZzVRnAeTee3WvPJwbrFR7L3Jk x3OM1KeSni+YsAfBrLi7xag4IIt8alQ6cYww2/q1aFPrs6opl2ou6NLxM4ynxkV8 Gb2kqiwUVlf5QFUVJOoNeVwoiNelklUj5jGq3KZGqhq4OSC5fkcCtOsjOffWWD1Y ACZL4aHrxUM/njHq8k+WBNocYtdmbFH8Iujzf27tsV8b0yIKGs6L5jjkFpSDQo+/ jiGafLVsddu9TeZr9Jm7OGo/u6q8ozCxaTg/G7fLF9DGrj1+AakN9sujxRgXkccI znci5qPW0dzOzhVUcaVPDdhfv/O3RXbky2qMSk+uxB5drqJ7LbOkPVTbDadspla8 2oJw3OoWuR0uC0aK7eibuFlurms6CcG/UQYQv9cjS4wGVe44S6/wiUBjfJXT3ITo rl38PcBigpF0XYWk2FAdE40xPN3REKv2Byulmjnc3ia2R+zBWuPg30LsQtFWgiwN tYJ5n/J08Ek+gqA6lNX9pRKT8lq6RQgQrvir7d/9Zw+RGaaVB1EnBUJi49O0Sfqs voFLstR1XnlhQubkhk5jhZ582Pug6K2H3b9sgU5ycTaWSEBr1B0AbvIetF5qO+pJ Y/vT452Br2g6CKXSpS2y6wwcqC0e/dkB31uFl1s4fRUmGxmBXnK4GFu/ufjNzrgz BFmF9HQWCSsGAQQB2kcPAQEHQIvVCKWPutMpY7ED7YDL8qev9tgCb5RSXPkzirJJ WjDZiQKzBBgBCgAmAhsCFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGK8FCQhD yzoAgXYgBBkWCAAdFiEElgyGKNWS/4zei7C/4OLe4dbI7voFAlmF9HQACgkQ4OLe 4dbI7vpdcAEA2GBaDiUbWapujHFGfh/a3MH1mXU/7Vrf+6aCBSoqwlABAOlljw5f 6gCnD6b8LjBIsS2W/U5jTtAt1aouzFDvhioICRCs5Wlx1VXapcvPD/0bteHRI4dW 3r4XqFKKVbKsc6gRaQRfUOZq3L0Pcadx0BoJorjnzCRY1KytAqyAjYH2ossd10Fm MLL5RTkNBvdcWTD6ZKIJQICEu0o2BJcPzKXVB2pJNsHJSMQyhAqbgUKfnePJza+4 p80PL6eBWttufKcNtJwYgkTJhchKoa+Se2h2mt53v6jdIusKwM91dW+0U5E6Jkom v3CKsSSsWIh8F5OpPJVz7/+2lThO2NOzLth762cV+yqsPGr9Dr9zsCkiIhRfr7hj 2L4AxO0ljYzd6FuR17WSvqHx3x2Sz8D2B5HxNQ0o6wxlnH3AlEti6/zSTtc0+AOx nOTZwj/CPQrly4MP8fNbhjOVNoLcfyq4u2/HB843/IWv+S7rob6qHF3rJ49Ltl8+ nsUJ2JKBUue9L5RnEPgIHuuFwDXp9XRXoj0+s2W2N0IScpYFj0HRW9/0NV3pn+t3 C2L5aCiCFSX9Ueg42RoPQR8szYyrhpmLVdNkuTSX5l86RLVMNw8ncuhpHvClOoRM REjLwYgf9g7T3kygf97LzAjlPSVcAw98HkdEV+h5V6AqOJkHNXfRHPiCLglF0S24 ePGprxeIN8ufmOdkdkpH91RhQRybVOtyQdrgIPnpBFBaFMfV0sDb+DcSx7hvYgHW kJqXDu2iDN2W3ZySYVrR/yLkuuawf9Lpcbg4BFmF99oSCisGAQQBl1UBBQEBB0CC RNDhUo58xjQ/zW1Kebdb8evrP6QU27xuMfpj0WRRfwMBCAeJAjwEGAEKACYCGwwW IQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb0hwAKCRCs5Wlx1VXapSc0 D/9JxkCkLkyOYx+rnOUugdwfQ7kRuUVkxLIIxf0UwEf9B2fsxEDIJJJO9DJOBnGt FHLI0k6nxCsk6QNz8TIpBGx1oH8k17gJgmQuZHED+xQBYbAx3G3Kj5jIj9oCnFJd P3ADM+Dzgwvm4hUuRD2gLEIwC0dpcPu+g2gQ+jRG9Gl3NT6qC6mvp2w7P0hW8+7o 7oZN5T2Lpi5s86yMuaoUlItj6a4Cjg4xJdTBHstJTWGfvclobVaxoas1udf/TzFN A6FUFQpRsgqymPS7MOK6GaQgvctT9/fP6jUwydhheDwYiFQzWaNaCjGfNq6/QlIm DQryAuWV7mWknygKR4uaqem48vhaea9XBMdghunv4tp/4fVELe0DDdV6D99cwvB+ 27gu3UlE0bz2gNq24IBq6Ew0jsKu0vTOyyiR49MEqjgdQna0CScO5fHv2DnJmYnC f1S5g36mlWm8HG3XM1OHizdjcB4hcSs9ETWYi1W5f0nZ94rv+BgZ6J+MOBybtfkx b1jYpf7rTx6bJbHQuYad879Sts5u6Ya36cRE/D7nHgSasxL5Kekr0eBM5EuGXQIN YlQItw0yfrM9NUgfePqZumNrrkxjqxcsh0aBJROm1FW6RSa4KnnIQNRu5jAWM7Md +aQQEj/YdJgS6uLzteKZBwUEe7jqNmTRtevMZtln9JNjcwAKCRDg4t7h1sju+iSH AP9NPs+OVWpOueQXbaZUE2iswd1FICjB201gdKRIvJhhJAD/bE04wUKuAyhLpuu8 LD5ZU8/oHefq89CP3m/OduhGOASJFGkEAQEKElMWIQRSX6konxd5jbM7JygTDfUW ES/A/wUCXsVjqF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdw LmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMwREY1 MTYxMTJGQzBGRtEUJgCZAg0EWYXemgEQAKOacFQ53v285zqzLB3Dt3zki1hAN5KH laFOC5eS3zj7wL6gtdhtZ6VWbKO1n686xlJdvji0TbM0Jai40r/BwTXomaYhXdVW f0j8SkxMr+IXHd79IaToLnq6imCxAWUONthFnps9z4iawR19qPcPJitYk7d0IQEQ Q6/j+7tRn+6UEk4RbikImOCTt6yZP0uYbQC9JJRmFlCqoyjnC+t/PTu4NsnowWM9 eAEhOG0k+MpKlNcJpoKzYYllWQpqBHWt7HK0iCwRTc5gcCX6ph8epwWprXFut0SM LxEMUhTS8lzdoalG58YRWWcPD8t9Y3qpfg0T0gL9DIoVcRA7Js/1QSX22L90ToVR IdP6D8zjMJ1IvVEUyTP3X9SeOCtkBugygqAFmpgulrCNgjJUxhN0h6sNBiLKYJ0P 4h+SBzcXCBOx9IWcUlfAsvaGokahlLPqMcoqIMMpq2EtCpYS8BsKjoU/lWyoguLZ O77ohY54unTthfMOIM1Hv/KoMY4Jq9ibA3ea3lPB01453bYsVYcsFywNzmAgHYSQ mgyl6YbVMmLrQVf0/ZYjwrsgIGYXPCe8f2LbEGWf7j5gMfKh3tyULUjTATYFs7q2 01pRH/pdzObyCPHTPMqy85lkNNeNe07yyzjWPtGDRNLcLj5BYxyYcIkKK7y0PgZL l279XnHDxMnxABEBAAG0EjB4QUNFNTY5NzFENTU1REFBNYkCXgQTAQoASAIbAQIe AQIXgAIZAQsLDQkIDAcDCwoEAgYVCgkICwMFFgMCAQAWIQR5EMRfifyMwsvSSrCs 5Wlx1VXapQUCXrAYXAUJCdC0QgAKCRCs5Wlx1VXapToBD/0RoBp776pLHL2IzZrc l9uqvmQRX6Yn/+vpIigMk9UA19vmgcX8pm0XRr5JdH5w88ExUqymlnRCvzQWSMBQ 4fli5RtOrYH5i+oyjkMuoFrZCIJrHrHXW51IjQgzYIvsjm8xxG5j5n8/cVn1Ej4L sAsv4SAnrG0XJgc5xVVh39rQ785Mf0o5XBx20MKGtFkE4Ljr7mGVwXF3efAxSZel EPU8Tn7bS9RubLPa4qMef3d86HYw0wuGg72pyL6QqWJrC5TtRDjZVM7oW1RKhSmA +HfuxUwiZ7MLiNib/V3cAU8LGkCM/uYeArE7A/p/D6EgRajJu/RazcESEzhMieht BSzTB2xYtDzfHkv0i8RwvrjeaQtvEIDjwWLDZhNbK4R2Eh5I60tOszaTnENVfmQ8 BIaobutM/97EGjlWDZRlaE8m6IR9holHs8CXSL7fXzJBKEhaDRm3U5vcrv/fKq8c MXNoBoo6U30JlHldURzKr0boza67lw5nQtAlOf9QUdg4rwP39Pfdl9pzy0iOIif3 XqLVi+pgjNLXgYpLyiohLLcWQPfa1B/yiT/w++dd7XFA9MC0iPdSqmJB/QvzG33q EskcqmGZH+SwpgEN1kVZEP9TQ1qReOd6k/R6Trx9HfA7iVtgob3H3hgMz/ulDUGl 9lkwuun7fG9MHGaBAK0C5SIl6bkCDQRZheBoARAArGP94En3E7nyvb+5DTBuBVEK rQcI+bG2SiCKqXNkFUZEKdqAXJomm2oNNMugMLeoSncORSkQRMFlzGjaK84f7S+i vsP4WL/F5+h1A9AbhZsRe46FC+GBDf1/1gcf+TXjoe8r3WrY3OutFxJmsFqqayaf z5u6gr66pKHVSNZQD9drFt2c/L4A2OcEUO1VBGJmu/vuz7/yueFZubYU7udkeHJX 2bplLjUxjOjUZaDSeXSYGinBs6UVTQNumIjZrd++QPhj2G5VnsZx4d2/JPDD/r0r cYZQctiWnlj60o+fK4/GcDcPCQjKKC74eQwqVjynFYBVRGj/xp/hmARQROIajapK 7E7aFEN897NK9X906dRF81W809jycSSka+LFQ93f34oNrnrAO0xmzgyhg5wsTbxm Hv7Iml/0bwnMDMiOAca8+oNAGWTZ9xmScBq8zRTfoECYMqV1974/7OqL3L9msQ37 dnkEGlio/zEWbbpOYQusiJUZW/W499oz80rsBSnXvF+ba3lnRqF9YU4ZI4MJtO3h VBhgwV/uRw1WDRM8MITKixNBIyYqpfD81fQ5jjXLU3oKI1aASllJiyHS2e/ITTOH ljL+TLeCdpiU0ssT+/ygB4c1Xoq/Fb61kBbJaI2sZObSYvGotOkJxxFdqF29UVE2 B4T8emCi7Lxp6Eco4qEAEQEAAYkEcgQYAQoAJgIbAhYhBHkQxF+J/IzCy9JKsKzl aXHVVdqlBQJesBiuBQkIQ99GAkDBdCAEGQEIAB0WIQRSX6konxd5jbM7JygTDfUW ES/A/wUCWYXgaAAKCRATDfUWES/A/xgsD/9ilpI8Ku4mWcy8Jus/5yHHfT8V4ieR ZfvTVykh1NVdVCyAiRaftrjXRkBMpJgowIXsMQetMZIp1mjYOdfNryb4gD0hifl3 TLl9yp1qXRAeVxpzVx+LgS+Q+HjIFmXhq+rQhnJWjjqgVHiQpkVUlZYRYttK0w6l kToWyY0oRqjsv4UY2NNsI4Ufb9+EXx/W1cvgcf9lBpDll345NH96r6gZBZAZfU8K 51Qdap2oG/FTr11Dc8G4n1riAwM0T+1qpCUgAdmshq/tRMZ90oYICClNUcn44qqv jtVPmtUURa0yybzki83+RxTRfWxVbIg5m7W6qcXm4K852Mj33VLBrH4ufiZbZnla Iqz3i9VCLUcG0eCt0HmuX8P0Lv5jT03isOB2JtXyec7puoXMIYA7FiQKzsppbfbr RC90nsJ5KI4tuba6wHvgLNvnTqP8iURrkxi/Tkcz48bfcOrrKk6CPvB30f5psUBL e51ItMv2oQcJe85PQtPjClT6qgBZY8mmu0vuzTDVsEXLSEPAObVnVHc+jN1SbVCe CYQETPi2Ul10w+yWx7D5G6iIH2kKxqZzlix+j10MJ7IVmjhANoQXc2vjflfM891N omgWlOjyWEB7/0UHBlFNFk+17tyDM5FIDzf4DH6Bu0oBkfcgVCme80x3XgQr5TCB WLcruxXOwVBDLgkQrOVpcdVV2qXsVw/+MxaSn/excv/noT6F65jXz8ghJhb1DXvF lVNUNKFYxOwAOL4w89sIFIoZBu8yFO7vxhxfqigY/TCWU+fqNBk1jsPUuD4Tj9Lk izwmDkdj+oHztoJi0BuS2ld8myqyMan5NxL9Bsqm0F4KYYaOwNGK6S/AGrpejerx 8z6y8tck8QJjlQI0zUWqeBMxW4c/GBFtTSMmKb9+a4lvI6OwbVKwvd1+51sj2Mzh BY9ne9UTUhXx8FQiCFgJbsIMzs8aR5jjB4vYPohLwBPsXR+cQClIsrc6n8vYNpn/ W1RC8C41VWL8bvLkNCKbWkVSmEXQSAj8p7kHilSsHjDVT6gqCUgoWqSuD+4qflKq Y3XVQ2TVx++xKEUpCZZFHd8QlX1ixZTnmO5n1zbFsqpMtr0PcbUZtyjmjvIGqF4l vrp9WXGJatbhE4G805PYa8Eg87jHxJWK7NnCe+8+wnY5D0T0FsJbdfJ7Y+GAgK6j vBpYGl8CdcWaa0ksYHj7TbgrjGOZQF/Z2n1r0fIhEZMGDwijuH77iiNVXuWMvJ81 RJxUbp1dnYTBnNnIUS+458gBGs3jFgl6mzsEKzVvWf5vS7XK5Beaqu7FQd6WUrkQ VLH6pyaZu1NVW/Il6LbrRB4co1aReC0Ei5AOcWz2ayJoISXBJ3GRgiiyQ8XG/sfD h4I3q6mbJ8m5Ag0EWYXwgAEQAO+wh3g3SgeBWkzLaIHo3p7Z92CyEnssgvZnfaWN Bowuv1INtprqa15yRpaIr8eFlchlVqCiQ2FN54tWkND5qlallwi2YSUW+nkEXCvy UR1S///MmwI5qos0A+Sil3uPsuBQtRezCaNEghM5a83Lfvv9kYqzfa9D6gCYUCv6 NtbH/yeshOuRhT2P3jFK0+kIObyPO26XsbfdbocutYA3c/27TAsE8VJvu4yqL5CU vz5H+EzGAdmrXVYD/VFxMrbIkKjmb7I0Tnl8RF3IUsL3SK/AKWYPOI4mMp5dv4yO /gYVoWX5Fd4dv6EQmvHMfiIvsxP8EBOTNVEtj/rac4P7Trdsc7CWsL5zzpofxIFQ ibo3JVNTRs/PPIlVmPROYLbXaolufgAmi+E8BCer780yc4nkmWOEcepuk3cQCM3l 6OrgI8aWQyrcf4uW4Jtn98AldJ21PhtN4A0d5PF0YvX/OrXoi3XBROUVLY6IF5Qb kSMeOvqJWzgktxvULI53Q3jtZvgtmF2dZ5rFgJCy3PjuXRBi2ZTz47eW94E7xDr0 4euhFnyMaiDMKS0XAj978kyCUrtDsssWp83j1IZt5Bd7JmtohThlEZCQ3Y0u3Gjm j9Nkv18qmF8O21Qe0LzG8Ad9HPTbQd9Rk+GQz57WxlcsjK2bC0WG7f6R5BHq1Ymu oD8nABEBAAGJAjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY 4QUJBrb74QAKCRCs5Wlx1VXapXcrD/9ktCowTIi5PtKUCjuttsaZzVRnAeTee3Wv PJwbrFR7L3Jkx3OM1KeSni+YsAfBrLi7xag4IIt8alQ6cYww2/q1aFPrs6opl2ou 6NLxM4ynxkV8Gb2kqiwUVlf5QFUVJOoNeVwoiNelklUj5jGq3KZGqhq4OSC5fkcC tOsjOffWWD1YACZL4aHrxUM/njHq8k+WBNocYtdmbFH8Iujzf27tsV8b0yIKGs6L 5jjkFpSDQo+/jiGafLVsddu9TeZr9Jm7OGo/u6q8ozCxaTg/G7fLF9DGrj1+AakN 9sujxRgXkccIznci5qPW0dzOzhVUcaVPDdhfv/O3RXbky2qMSk+uxB5drqJ7LbOk PVTbDadspla82oJw3OoWuR0uC0aK7eibuFlurms6CcG/UQYQv9cjS4wGVe44S6/w iUBjfJXT3ITorl38PcBigpF0XYWk2FAdE40xPN3REKv2Byulmjnc3ia2R+zBWuPg 30LsQtFWgiwNtYJ5n/J08Ek+gqA6lNX9pRKT8lq6RQgQrvir7d/9Zw+RGaaVB1En BUJi49O0SfqsvoFLstR1XnlhQubkhk5jhZ582Pug6K2H3b9sgU5ycTaWSEBr1B0A bvIetF5qO+pJY/vT452Br2g6CKXSpS2y6wwcqC0e/dkB31uFl1s4fRUmGxmBXnK4 GFu/ufjNzrg4BFmF99oSCisGAQQBl1UBBQEBB0CCRNDhUo58xjQ/zW1Kebdb8evr P6QU27xuMfpj0WRRfwMBCAeJAjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx 1VXapQUCXrAY4QUJBrb0hwAKCRCs5Wlx1VXapSc0D/9JxkCkLkyOYx+rnOUugdwf Q7kRuUVkxLIIxf0UwEf9B2fsxEDIJJJO9DJOBnGtFHLI0k6nxCsk6QNz8TIpBGx1 oH8k17gJgmQuZHED+xQBYbAx3G3Kj5jIj9oCnFJdP3ADM+Dzgwvm4hUuRD2gLEIw C0dpcPu+g2gQ+jRG9Gl3NT6qC6mvp2w7P0hW8+7o7oZN5T2Lpi5s86yMuaoUlItj 6a4Cjg4xJdTBHstJTWGfvclobVaxoas1udf/TzFNA6FUFQpRsgqymPS7MOK6GaQg vctT9/fP6jUwydhheDwYiFQzWaNaCjGfNq6/QlImDQryAuWV7mWknygKR4uaqem4 8vhaea9XBMdghunv4tp/4fVELe0DDdV6D99cwvB+27gu3UlE0bz2gNq24IBq6Ew0 jsKu0vTOyyiR49MEqjgdQna0CScO5fHv2DnJmYnCf1S5g36mlWm8HG3XM1OHizdj cB4hcSs9ETWYi1W5f0nZ94rv+BgZ6J+MOBybtfkxb1jYpf7rTx6bJbHQuYad879S ts5u6Ya36cRE/D7nHgSasxL5Kekr0eBM5EuGXQINYlQItw0yfrM9NUgfePqZumNr rkxjqxcsh0aBJROm1FW6RSa4KnnIQNRu5jAWM7Md+aQQEj/YdJgS6uLzteKZBwUE e7jqNmTRtevMZtln9JNjcwAKCRATDfUWES/A//VxEACiOUdJ+MqOg+65lKU1h5ad tNbXEEySjB/zsDBzrwqNQops8/pRuoKUpIHOvl3q0bsx9PCsOkOyrj8CdoVVgafd o5Un4tlyMg6zdr9pfLQmhRsWxNyRvpwywbKHuxHpkYyyUOtxTaUO5Ke63SnUrQWY Qfumf15mDQ2YD+mQiAkUijIUH3sSTotCaOzU5FKTXE+KKJsLEEO5RYLIs1QLc8eC zSUZlmbMeZMQuwp6LiPuZAYFIzObuNxnnSsWECYvTaAovn2aJHCw1z1nJAhw3r23 CLJsqAMw+u2wZCWIrD6WqM6f81EkGaO1apuPZ7MflPzm6krob8a/BTxNnjDefHya o5mGqeigm2U6iqTe9wI7HxuMcg5Bf59IRPzVaWxgaMyUvmxSqrBNSAQ6Iyoz+6mM VAc0u0hlWfxUGyQDugDuQ3MIv6zaIXiiIEWWX/IWikvVIdIvc3HtVanKInCwAqYt whJ/AtohKR276c4Uko42ksJwT5atzo1vw7A061eynlvWT0Pydxb4FjE2aZ4lXXC+ av3fyWvUBIACgTBPl9JEgYxTpSR9NyDkmFbqolHcBnLZ3a4tfV2Qz4pw4guiMZ2S UPxm8H7u0s6bblQVplFDwNiJN10ipK92rlwDfxVv7QPsr1j725fF3qUVCPsSbuVG TNdnYVAJTwfSJtyNS6Ncig== =DhgZ -----END PGP SIGNATURE----- From sac at 300baud.de Wed May 20 19:11:47 2020 From: sac at 300baud.de (Stefan Claas) Date: Wed, 20 May 2020 19:11:47 +0200 Subject: keys require a user-id In-Reply-To: <87sgfu4mk8.fsf@wheatstone.g10code.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200518131202.00004579.sac@300baud.de> <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> <87sgfu4mk8.fsf@wheatstone.g10code.de> Message-ID: <20200520191147.000007a0.sac@300baud.de> Werner Koch via Gnupg-users wrote: > On Tue, 19 May 2020 10:29, Robert J. Hansen said: > > > * PII-free UIDs are possible today > > Well, according to European law this is not that easy because a public > key is in most cases an attribute which identifies a natural person. Curious as I am, did Mr Sch?nbohm never asked you why your public keyblock is not signed by Governikus? I ask, because don't you think that this could not have an impact on the spread and usage of GnuPG in the EU for business purposes etc. and for example if you would accept UID-less public keyblocks, privacy concerned parents could for example allow their minors to use GnuPG, while mom, dad or their teacher could sign their public keyblock? Best regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From 2017-r3sgs86x8e-lists-groups at riseup.net Wed May 20 19:18:18 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Wed, 20 May 2020 18:18:18 +0100 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <20200516224955.00005826.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> Message-ID: <16910653803.20200520181818@mail.riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 16 May 2020 at 9:49:55 PM, in , Stefan Claas wrote:- > out of curiosity, you signed the reply with two sub > keys, The RSA signature is for the benefit of recipients who can't handle ECC keys/signatures. Probably not needed anymore. > the hash algo > used? I'm hopefully using SHA512. - -- Best regards MFPA Ballerinas are always on their toes. We need taller ballerinas! -----BEGIN PGP SIGNATURE----- iQ8RBAEWCg65FiEElgyGKNWS/4zei7C/4OLe4dbI7voFAl7FZlpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 MEM4NjI4RDU5MkZGOENERThCQjBCRkUwRTJERUUxRDZDOEVFRkHNeiYAmQINBFmF 3poBEACjmnBUOd79vOc6sywdw7d85ItYQDeSh5WhTguXkt84+8C+oLXYbWelVmyj tZ+vOsZSXb44tE2zNCWouNK/wcE16JmmIV3VVn9I/EpMTK/iFx3e/SGk6C56uopg sQFlDjbYRZ6bPc+ImsEdfaj3DyYrWJO3dCEBEEOv4/u7UZ/ulBJOEW4pCJjgk7es mT9LmG0AvSSUZhZQqqMo5wvrfz07uDbJ6MFjPXgBIThtJPjKSpTXCaaCs2GJZVkK agR1rexytIgsEU3OYHAl+qYfHqcFqa1xbrdEjC8RDFIU0vJc3aGpRufGEVlnDw/L fWN6qX4NE9IC/QyKFXEQOybP9UEl9ti/dE6FUSHT+g/M4zCdSL1RFMkz91/Unjgr ZAboMoKgBZqYLpawjYIyVMYTdIerDQYiymCdD+Ifkgc3FwgTsfSFnFJXwLL2hqJG oZSz6jHKKiDDKathLQqWEvAbCo6FP5VsqILi2Tu+6IWOeLp07YXzDiDNR7/yqDGO CavYmwN3mt5TwdNeOd22LFWHLBcsDc5gIB2EkJoMpemG1TJi60FX9P2WI8K7ICBm FzwnvH9i2xBln+4+YDHyod7clC1I0wE2BbO6ttNaUR/6Xczm8gjx0zzKsvOZZDTX jXtO8ss41j7Rg0TS3C4+QWMcmHCJCiu8tD4GS5du/V5xw8TJ8QARAQABtBIweEFD RTU2OTcxRDU1NURBQTWJAl4EEwEKAEgCGwECHgECF4ACGQELCw0JCAwHAwsKBAIG FQoJCAsDBRYDAgEAFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGFwFCQnQtEIA CgkQrOVpcdVV2qU6AQ/9EaAae++qSxy9iM2a3Jfbqr5kEV+mJ//r6SIoDJPVANfb 5oHF/KZtF0a+SXR+cPPBMVKsppZ0Qr80FkjAUOH5YuUbTq2B+YvqMo5DLqBa2QiC ax6x11udSI0IM2CL7I5vMcRuY+Z/P3FZ9RI+C7ALL+EgJ6xtFyYHOcVVYd/a0O/O TH9KOVwcdtDChrRZBOC46+5hlcFxd3nwMUmXpRD1PE5+20vUbmyz2uKjHn93fOh2 MNMLhoO9qci+kKliawuU7UQ42VTO6FtUSoUpgPh37sVMImezC4jYm/1d3AFPCxpA jP7mHgKxOwP6fw+hIEWoybv0Ws3BEhM4TInobQUs0wdsWLQ83x5L9IvEcL643mkL bxCA48Fiw2YTWyuEdhIeSOtLTrM2k5xDVX5kPASGqG7rTP/exBo5Vg2UZWhPJuiE fYaJR7PAl0i+318yQShIWg0Zt1Ob3K7/3yqvHDFzaAaKOlN9CZR5XVEcyq9G6M2u u5cOZ0LQJTn/UFHYOK8D9/T33Zfac8tIjiIn916i1YvqYIzS14GKS8oqISy3FkD3 2tQf8ok/8PvnXe1xQPTAtIj3UqpiQf0L8xt96hLJHKphmR/ksKYBDdZFWRD/U0Na kXjnepP0ek68fR3wO4lbYKG9x94YDM/7pQ1BpfZZMLrp+3xvTBxmgQCtAuUiJem5 Ag0EWYXwgAEQAO+wh3g3SgeBWkzLaIHo3p7Z92CyEnssgvZnfaWNBowuv1INtprq a15yRpaIr8eFlchlVqCiQ2FN54tWkND5qlallwi2YSUW+nkEXCvyUR1S///MmwI5 qos0A+Sil3uPsuBQtRezCaNEghM5a83Lfvv9kYqzfa9D6gCYUCv6NtbH/yeshOuR hT2P3jFK0+kIObyPO26XsbfdbocutYA3c/27TAsE8VJvu4yqL5CUvz5H+EzGAdmr XVYD/VFxMrbIkKjmb7I0Tnl8RF3IUsL3SK/AKWYPOI4mMp5dv4yO/gYVoWX5Fd4d v6EQmvHMfiIvsxP8EBOTNVEtj/rac4P7Trdsc7CWsL5zzpofxIFQibo3JVNTRs/P PIlVmPROYLbXaolufgAmi+E8BCer780yc4nkmWOEcepuk3cQCM3l6OrgI8aWQyrc f4uW4Jtn98AldJ21PhtN4A0d5PF0YvX/OrXoi3XBROUVLY6IF5QbkSMeOvqJWzgk txvULI53Q3jtZvgtmF2dZ5rFgJCy3PjuXRBi2ZTz47eW94E7xDr04euhFnyMaiDM KS0XAj978kyCUrtDsssWp83j1IZt5Bd7JmtohThlEZCQ3Y0u3Gjmj9Nkv18qmF8O 21Qe0LzG8Ad9HPTbQd9Rk+GQz57WxlcsjK2bC0WG7f6R5BHq1YmuoD8nABEBAAGJ AjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb74QAK CRCs5Wlx1VXapXcrD/9ktCowTIi5PtKUCjuttsaZzVRnAeTee3WvPJwbrFR7L3Jk x3OM1KeSni+YsAfBrLi7xag4IIt8alQ6cYww2/q1aFPrs6opl2ou6NLxM4ynxkV8 Gb2kqiwUVlf5QFUVJOoNeVwoiNelklUj5jGq3KZGqhq4OSC5fkcCtOsjOffWWD1Y ACZL4aHrxUM/njHq8k+WBNocYtdmbFH8Iujzf27tsV8b0yIKGs6L5jjkFpSDQo+/ jiGafLVsddu9TeZr9Jm7OGo/u6q8ozCxaTg/G7fLF9DGrj1+AakN9sujxRgXkccI znci5qPW0dzOzhVUcaVPDdhfv/O3RXbky2qMSk+uxB5drqJ7LbOkPVTbDadspla8 2oJw3OoWuR0uC0aK7eibuFlurms6CcG/UQYQv9cjS4wGVe44S6/wiUBjfJXT3ITo rl38PcBigpF0XYWk2FAdE40xPN3REKv2Byulmjnc3ia2R+zBWuPg30LsQtFWgiwN tYJ5n/J08Ek+gqA6lNX9pRKT8lq6RQgQrvir7d/9Zw+RGaaVB1EnBUJi49O0Sfqs voFLstR1XnlhQubkhk5jhZ582Pug6K2H3b9sgU5ycTaWSEBr1B0AbvIetF5qO+pJ Y/vT452Br2g6CKXSpS2y6wwcqC0e/dkB31uFl1s4fRUmGxmBXnK4GFu/ufjNzrgz BFmF9HQWCSsGAQQB2kcPAQEHQIvVCKWPutMpY7ED7YDL8qev9tgCb5RSXPkzirJJ WjDZiQKzBBgBCgAmAhsCFiEEeRDEX4n8jMLL0kqwrOVpcdVV2qUFAl6wGK8FCQhD yzoAgXYgBBkWCAAdFiEElgyGKNWS/4zei7C/4OLe4dbI7voFAlmF9HQACgkQ4OLe 4dbI7vpdcAEA2GBaDiUbWapujHFGfh/a3MH1mXU/7Vrf+6aCBSoqwlABAOlljw5f 6gCnD6b8LjBIsS2W/U5jTtAt1aouzFDvhioICRCs5Wlx1VXapcvPD/0bteHRI4dW 3r4XqFKKVbKsc6gRaQRfUOZq3L0Pcadx0BoJorjnzCRY1KytAqyAjYH2ossd10Fm MLL5RTkNBvdcWTD6ZKIJQICEu0o2BJcPzKXVB2pJNsHJSMQyhAqbgUKfnePJza+4 p80PL6eBWttufKcNtJwYgkTJhchKoa+Se2h2mt53v6jdIusKwM91dW+0U5E6Jkom v3CKsSSsWIh8F5OpPJVz7/+2lThO2NOzLth762cV+yqsPGr9Dr9zsCkiIhRfr7hj 2L4AxO0ljYzd6FuR17WSvqHx3x2Sz8D2B5HxNQ0o6wxlnH3AlEti6/zSTtc0+AOx nOTZwj/CPQrly4MP8fNbhjOVNoLcfyq4u2/HB843/IWv+S7rob6qHF3rJ49Ltl8+ nsUJ2JKBUue9L5RnEPgIHuuFwDXp9XRXoj0+s2W2N0IScpYFj0HRW9/0NV3pn+t3 C2L5aCiCFSX9Ueg42RoPQR8szYyrhpmLVdNkuTSX5l86RLVMNw8ncuhpHvClOoRM REjLwYgf9g7T3kygf97LzAjlPSVcAw98HkdEV+h5V6AqOJkHNXfRHPiCLglF0S24 ePGprxeIN8ufmOdkdkpH91RhQRybVOtyQdrgIPnpBFBaFMfV0sDb+DcSx7hvYgHW kJqXDu2iDN2W3ZySYVrR/yLkuuawf9Lpcbg4BFmF99oSCisGAQQBl1UBBQEBB0CC RNDhUo58xjQ/zW1Kebdb8evrP6QU27xuMfpj0WRRfwMBCAeJAjwEGAEKACYCGwwW IQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY4QUJBrb0hwAKCRCs5Wlx1VXapSc0 D/9JxkCkLkyOYx+rnOUugdwfQ7kRuUVkxLIIxf0UwEf9B2fsxEDIJJJO9DJOBnGt FHLI0k6nxCsk6QNz8TIpBGx1oH8k17gJgmQuZHED+xQBYbAx3G3Kj5jIj9oCnFJd P3ADM+Dzgwvm4hUuRD2gLEIwC0dpcPu+g2gQ+jRG9Gl3NT6qC6mvp2w7P0hW8+7o 7oZN5T2Lpi5s86yMuaoUlItj6a4Cjg4xJdTBHstJTWGfvclobVaxoas1udf/TzFN A6FUFQpRsgqymPS7MOK6GaQgvctT9/fP6jUwydhheDwYiFQzWaNaCjGfNq6/QlIm DQryAuWV7mWknygKR4uaqem48vhaea9XBMdghunv4tp/4fVELe0DDdV6D99cwvB+ 27gu3UlE0bz2gNq24IBq6Ew0jsKu0vTOyyiR49MEqjgdQna0CScO5fHv2DnJmYnC f1S5g36mlWm8HG3XM1OHizdjcB4hcSs9ETWYi1W5f0nZ94rv+BgZ6J+MOBybtfkx b1jYpf7rTx6bJbHQuYad879Sts5u6Ya36cRE/D7nHgSasxL5Kekr0eBM5EuGXQIN YlQItw0yfrM9NUgfePqZumNrrkxjqxcsh0aBJROm1FW6RSa4KnnIQNRu5jAWM7Md +aQQEj/YdJgS6uLzteKZBwUEe7jqNmTRtevMZtln9JNjcwAKCRDg4t7h1sju+k0e AQCfiRfpOjjbdjPTfFb86ennD8UtgB4YPuUEFlfPifek0AEArYx52C9uVEezpOzE wrgxbv+gM3tdtA+lgrDUrC0bDAuJFGkEAQEKElMWIQRSX6konxd5jbM7JygTDfUW ES/A/wUCXsVmWl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdw LmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMwREY1 MTYxMTJGQzBGRtEUJgCZAg0EWYXemgEQAKOacFQ53v285zqzLB3Dt3zki1hAN5KH laFOC5eS3zj7wL6gtdhtZ6VWbKO1n686xlJdvji0TbM0Jai40r/BwTXomaYhXdVW f0j8SkxMr+IXHd79IaToLnq6imCxAWUONthFnps9z4iawR19qPcPJitYk7d0IQEQ Q6/j+7tRn+6UEk4RbikImOCTt6yZP0uYbQC9JJRmFlCqoyjnC+t/PTu4NsnowWM9 eAEhOG0k+MpKlNcJpoKzYYllWQpqBHWt7HK0iCwRTc5gcCX6ph8epwWprXFut0SM LxEMUhTS8lzdoalG58YRWWcPD8t9Y3qpfg0T0gL9DIoVcRA7Js/1QSX22L90ToVR IdP6D8zjMJ1IvVEUyTP3X9SeOCtkBugygqAFmpgulrCNgjJUxhN0h6sNBiLKYJ0P 4h+SBzcXCBOx9IWcUlfAsvaGokahlLPqMcoqIMMpq2EtCpYS8BsKjoU/lWyoguLZ O77ohY54unTthfMOIM1Hv/KoMY4Jq9ibA3ea3lPB01453bYsVYcsFywNzmAgHYSQ mgyl6YbVMmLrQVf0/ZYjwrsgIGYXPCe8f2LbEGWf7j5gMfKh3tyULUjTATYFs7q2 01pRH/pdzObyCPHTPMqy85lkNNeNe07yyzjWPtGDRNLcLj5BYxyYcIkKK7y0PgZL l279XnHDxMnxABEBAAG0EjB4QUNFNTY5NzFENTU1REFBNYkCXgQTAQoASAIbAQIe AQIXgAIZAQsLDQkIDAcDCwoEAgYVCgkICwMFFgMCAQAWIQR5EMRfifyMwsvSSrCs 5Wlx1VXapQUCXrAYXAUJCdC0QgAKCRCs5Wlx1VXapToBD/0RoBp776pLHL2IzZrc l9uqvmQRX6Yn/+vpIigMk9UA19vmgcX8pm0XRr5JdH5w88ExUqymlnRCvzQWSMBQ 4fli5RtOrYH5i+oyjkMuoFrZCIJrHrHXW51IjQgzYIvsjm8xxG5j5n8/cVn1Ej4L sAsv4SAnrG0XJgc5xVVh39rQ785Mf0o5XBx20MKGtFkE4Ljr7mGVwXF3efAxSZel EPU8Tn7bS9RubLPa4qMef3d86HYw0wuGg72pyL6QqWJrC5TtRDjZVM7oW1RKhSmA +HfuxUwiZ7MLiNib/V3cAU8LGkCM/uYeArE7A/p/D6EgRajJu/RazcESEzhMieht BSzTB2xYtDzfHkv0i8RwvrjeaQtvEIDjwWLDZhNbK4R2Eh5I60tOszaTnENVfmQ8 BIaobutM/97EGjlWDZRlaE8m6IR9holHs8CXSL7fXzJBKEhaDRm3U5vcrv/fKq8c MXNoBoo6U30JlHldURzKr0boza67lw5nQtAlOf9QUdg4rwP39Pfdl9pzy0iOIif3 XqLVi+pgjNLXgYpLyiohLLcWQPfa1B/yiT/w++dd7XFA9MC0iPdSqmJB/QvzG33q EskcqmGZH+SwpgEN1kVZEP9TQ1qReOd6k/R6Trx9HfA7iVtgob3H3hgMz/ulDUGl 9lkwuun7fG9MHGaBAK0C5SIl6bkCDQRZheBoARAArGP94En3E7nyvb+5DTBuBVEK rQcI+bG2SiCKqXNkFUZEKdqAXJomm2oNNMugMLeoSncORSkQRMFlzGjaK84f7S+i vsP4WL/F5+h1A9AbhZsRe46FC+GBDf1/1gcf+TXjoe8r3WrY3OutFxJmsFqqayaf z5u6gr66pKHVSNZQD9drFt2c/L4A2OcEUO1VBGJmu/vuz7/yueFZubYU7udkeHJX 2bplLjUxjOjUZaDSeXSYGinBs6UVTQNumIjZrd++QPhj2G5VnsZx4d2/JPDD/r0r cYZQctiWnlj60o+fK4/GcDcPCQjKKC74eQwqVjynFYBVRGj/xp/hmARQROIajapK 7E7aFEN897NK9X906dRF81W809jycSSka+LFQ93f34oNrnrAO0xmzgyhg5wsTbxm Hv7Iml/0bwnMDMiOAca8+oNAGWTZ9xmScBq8zRTfoECYMqV1974/7OqL3L9msQ37 dnkEGlio/zEWbbpOYQusiJUZW/W499oz80rsBSnXvF+ba3lnRqF9YU4ZI4MJtO3h VBhgwV/uRw1WDRM8MITKixNBIyYqpfD81fQ5jjXLU3oKI1aASllJiyHS2e/ITTOH ljL+TLeCdpiU0ssT+/ygB4c1Xoq/Fb61kBbJaI2sZObSYvGotOkJxxFdqF29UVE2 B4T8emCi7Lxp6Eco4qEAEQEAAYkEcgQYAQoAJgIbAhYhBHkQxF+J/IzCy9JKsKzl aXHVVdqlBQJesBiuBQkIQ99GAkDBdCAEGQEIAB0WIQRSX6konxd5jbM7JygTDfUW ES/A/wUCWYXgaAAKCRATDfUWES/A/xgsD/9ilpI8Ku4mWcy8Jus/5yHHfT8V4ieR ZfvTVykh1NVdVCyAiRaftrjXRkBMpJgowIXsMQetMZIp1mjYOdfNryb4gD0hifl3 TLl9yp1qXRAeVxpzVx+LgS+Q+HjIFmXhq+rQhnJWjjqgVHiQpkVUlZYRYttK0w6l kToWyY0oRqjsv4UY2NNsI4Ufb9+EXx/W1cvgcf9lBpDll345NH96r6gZBZAZfU8K 51Qdap2oG/FTr11Dc8G4n1riAwM0T+1qpCUgAdmshq/tRMZ90oYICClNUcn44qqv jtVPmtUURa0yybzki83+RxTRfWxVbIg5m7W6qcXm4K852Mj33VLBrH4ufiZbZnla Iqz3i9VCLUcG0eCt0HmuX8P0Lv5jT03isOB2JtXyec7puoXMIYA7FiQKzsppbfbr RC90nsJ5KI4tuba6wHvgLNvnTqP8iURrkxi/Tkcz48bfcOrrKk6CPvB30f5psUBL e51ItMv2oQcJe85PQtPjClT6qgBZY8mmu0vuzTDVsEXLSEPAObVnVHc+jN1SbVCe CYQETPi2Ul10w+yWx7D5G6iIH2kKxqZzlix+j10MJ7IVmjhANoQXc2vjflfM891N omgWlOjyWEB7/0UHBlFNFk+17tyDM5FIDzf4DH6Bu0oBkfcgVCme80x3XgQr5TCB WLcruxXOwVBDLgkQrOVpcdVV2qXsVw/+MxaSn/excv/noT6F65jXz8ghJhb1DXvF lVNUNKFYxOwAOL4w89sIFIoZBu8yFO7vxhxfqigY/TCWU+fqNBk1jsPUuD4Tj9Lk izwmDkdj+oHztoJi0BuS2ld8myqyMan5NxL9Bsqm0F4KYYaOwNGK6S/AGrpejerx 8z6y8tck8QJjlQI0zUWqeBMxW4c/GBFtTSMmKb9+a4lvI6OwbVKwvd1+51sj2Mzh BY9ne9UTUhXx8FQiCFgJbsIMzs8aR5jjB4vYPohLwBPsXR+cQClIsrc6n8vYNpn/ W1RC8C41VWL8bvLkNCKbWkVSmEXQSAj8p7kHilSsHjDVT6gqCUgoWqSuD+4qflKq Y3XVQ2TVx++xKEUpCZZFHd8QlX1ixZTnmO5n1zbFsqpMtr0PcbUZtyjmjvIGqF4l vrp9WXGJatbhE4G805PYa8Eg87jHxJWK7NnCe+8+wnY5D0T0FsJbdfJ7Y+GAgK6j vBpYGl8CdcWaa0ksYHj7TbgrjGOZQF/Z2n1r0fIhEZMGDwijuH77iiNVXuWMvJ81 RJxUbp1dnYTBnNnIUS+458gBGs3jFgl6mzsEKzVvWf5vS7XK5Beaqu7FQd6WUrkQ VLH6pyaZu1NVW/Il6LbrRB4co1aReC0Ei5AOcWz2ayJoISXBJ3GRgiiyQ8XG/sfD h4I3q6mbJ8m5Ag0EWYXwgAEQAO+wh3g3SgeBWkzLaIHo3p7Z92CyEnssgvZnfaWN Bowuv1INtprqa15yRpaIr8eFlchlVqCiQ2FN54tWkND5qlallwi2YSUW+nkEXCvy UR1S///MmwI5qos0A+Sil3uPsuBQtRezCaNEghM5a83Lfvv9kYqzfa9D6gCYUCv6 NtbH/yeshOuRhT2P3jFK0+kIObyPO26XsbfdbocutYA3c/27TAsE8VJvu4yqL5CU vz5H+EzGAdmrXVYD/VFxMrbIkKjmb7I0Tnl8RF3IUsL3SK/AKWYPOI4mMp5dv4yO /gYVoWX5Fd4dv6EQmvHMfiIvsxP8EBOTNVEtj/rac4P7Trdsc7CWsL5zzpofxIFQ ibo3JVNTRs/PPIlVmPROYLbXaolufgAmi+E8BCer780yc4nkmWOEcepuk3cQCM3l 6OrgI8aWQyrcf4uW4Jtn98AldJ21PhtN4A0d5PF0YvX/OrXoi3XBROUVLY6IF5Qb kSMeOvqJWzgktxvULI53Q3jtZvgtmF2dZ5rFgJCy3PjuXRBi2ZTz47eW94E7xDr0 4euhFnyMaiDMKS0XAj978kyCUrtDsssWp83j1IZt5Bd7JmtohThlEZCQ3Y0u3Gjm j9Nkv18qmF8O21Qe0LzG8Ad9HPTbQd9Rk+GQz57WxlcsjK2bC0WG7f6R5BHq1Ymu oD8nABEBAAGJAjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx1VXapQUCXrAY 4QUJBrb74QAKCRCs5Wlx1VXapXcrD/9ktCowTIi5PtKUCjuttsaZzVRnAeTee3Wv PJwbrFR7L3Jkx3OM1KeSni+YsAfBrLi7xag4IIt8alQ6cYww2/q1aFPrs6opl2ou 6NLxM4ynxkV8Gb2kqiwUVlf5QFUVJOoNeVwoiNelklUj5jGq3KZGqhq4OSC5fkcC tOsjOffWWD1YACZL4aHrxUM/njHq8k+WBNocYtdmbFH8Iujzf27tsV8b0yIKGs6L 5jjkFpSDQo+/jiGafLVsddu9TeZr9Jm7OGo/u6q8ozCxaTg/G7fLF9DGrj1+AakN 9sujxRgXkccIznci5qPW0dzOzhVUcaVPDdhfv/O3RXbky2qMSk+uxB5drqJ7LbOk PVTbDadspla82oJw3OoWuR0uC0aK7eibuFlurms6CcG/UQYQv9cjS4wGVe44S6/w iUBjfJXT3ITorl38PcBigpF0XYWk2FAdE40xPN3REKv2Byulmjnc3ia2R+zBWuPg 30LsQtFWgiwNtYJ5n/J08Ek+gqA6lNX9pRKT8lq6RQgQrvir7d/9Zw+RGaaVB1En BUJi49O0SfqsvoFLstR1XnlhQubkhk5jhZ582Pug6K2H3b9sgU5ycTaWSEBr1B0A bvIetF5qO+pJY/vT452Br2g6CKXSpS2y6wwcqC0e/dkB31uFl1s4fRUmGxmBXnK4 GFu/ufjNzrg4BFmF99oSCisGAQQBl1UBBQEBB0CCRNDhUo58xjQ/zW1Kebdb8evr P6QU27xuMfpj0WRRfwMBCAeJAjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx 1VXapQUCXrAY4QUJBrb0hwAKCRCs5Wlx1VXapSc0D/9JxkCkLkyOYx+rnOUugdwf Q7kRuUVkxLIIxf0UwEf9B2fsxEDIJJJO9DJOBnGtFHLI0k6nxCsk6QNz8TIpBGx1 oH8k17gJgmQuZHED+xQBYbAx3G3Kj5jIj9oCnFJdP3ADM+Dzgwvm4hUuRD2gLEIw C0dpcPu+g2gQ+jRG9Gl3NT6qC6mvp2w7P0hW8+7o7oZN5T2Lpi5s86yMuaoUlItj 6a4Cjg4xJdTBHstJTWGfvclobVaxoas1udf/TzFNA6FUFQpRsgqymPS7MOK6GaQg vctT9/fP6jUwydhheDwYiFQzWaNaCjGfNq6/QlImDQryAuWV7mWknygKR4uaqem4 8vhaea9XBMdghunv4tp/4fVELe0DDdV6D99cwvB+27gu3UlE0bz2gNq24IBq6Ew0 jsKu0vTOyyiR49MEqjgdQna0CScO5fHv2DnJmYnCf1S5g36mlWm8HG3XM1OHizdj cB4hcSs9ETWYi1W5f0nZ94rv+BgZ6J+MOBybtfkxb1jYpf7rTx6bJbHQuYad879S ts5u6Ya36cRE/D7nHgSasxL5Kekr0eBM5EuGXQINYlQItw0yfrM9NUgfePqZumNr rkxjqxcsh0aBJROm1FW6RSa4KnnIQNRu5jAWM7Md+aQQEj/YdJgS6uLzteKZBwUE e7jqNmTRtevMZtln9JNjcwAKCRATDfUWES/A/wkjEACYsz8ACkkmk94Do7ujLdzz ggB0/oj2ICN15aXxOFKyHFkdCaXk+iU4ee467Gbv4k6W0FvfJuL9812Z2unoUjeM IkqeZACasx2BCpZ5B2v5eJHASyCwTZlcy6WaNZNaYlrY3ZwRjctmRK8cPC0WEJu1 coOAt0nT2ZLb6AXl1Y/Y4cabbCORWJI72okgXwZKxADzrb5kslDdmN7BI+KfQyln wBJgizjfBkA0PXkVz8+hlLYWaq9Aj1gjagG0IfFCIdEU2FwpxChy89t0474MKvMm Wimvx1798oeMw/RR581WAjFBQvZizp25g73emF/GnQBL4MxJZRhombfhCdMo3aAY E6YiATNZH21SwTKjkOgIukKp48m9uWn9Z7PRdt4ID7S7TRjeDkB2GZW6i6WJYRih hoNjfA+GZAhb96UYDc0CUptCcm5xSU2c/Udkqsg6Ig1bIVRJLC7C9qXpHm6RzRAs gjv2KlbFbjFn+8uLLzm/KOt2uc6lfrZ06btQdHG6ttqiJMRIWmGZkpWh3fj2q+1+ nvsFeYlTCK/Yv40hlmt3BUqBBFFL2Rcq+wRhwqd+5BSFwfcFkijAD4o6hhBp3u7J H6TTZBlYR/amVCCuVbUsq52Z8pnr4jqIAQJ1R9soYaeyBAr5YEfjw2RaAmtMDUdQ Sn1E+IddN6AmjSkvSe30FA== =pVGi -----END PGP SIGNATURE----- From listofactor at mail.ru Wed May 20 18:03:53 2020 From: listofactor at mail.ru (LisToFacTor) Date: Wed, 20 May 2020 16:03:53 +0000 Subject: "just invent something..." In-Reply-To: References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> Message-ID: On 5/20/20 7:27 AM, Andrew Gallagher wrote: > > Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example. Demanding a piece of information from someone who would prefer not to give it is equally user-hostile, especially so if he who demands it does so only because it is required by some internal mechanics of the system he constructed. Answering user's objection to such request by telling him: "well, if you don't want to give me this information, just invent something..." is wrong on so many levels that I feel no need to get into. From sac at 300baud.de Wed May 20 20:03:38 2020 From: sac at 300baud.de (Stefan Claas) Date: Wed, 20 May 2020 20:03:38 +0200 Subject: keys require a user-id In-Reply-To: <20200520191147.000007a0.sac@300baud.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200518131202.00004579.sac@300baud.de> <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> <87sgfu4mk8.fsf@wheatstone.g10code.de> <20200520191147.000007a0.sac@300baud.de> Message-ID: <20200520200338.00003c5a.sac@300baud.de> Stefan Claas wrote: > I ask, because don't you think that this could not have an impact on > the spread and usage of GnuPG in the EU for business purposes etc. With that I mean the acceptance of GnuPG Signatures, compared to costly eIDAS solutions. Best regards Stefan > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From andrewg at andrewg.com Wed May 20 20:52:56 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 20 May 2020 19:52:56 +0100 Subject: "just invent something..." In-Reply-To: References: Message-ID: > On 20 May 2020, at 18:51, LisToFacTor via Gnupg-users wrote: > > Demanding a piece of information from someone who would prefer not > to give it is equally user-hostile, especially so if he who demands > it does so only because it is required by some internal mechanics > of the system he constructed ?Demand? is a strong word that I don?t believe is justified here, and only serves to inflame the debate. Most implementations of email require that you enter a ?real name? of some kind. OpenPGP/GPG strongly encourage you to use the same real name on your key as you use on your email profile - this is for the benefit of your correspondents, since using different IDs will likely cause confusion. You are free to ignore this recommendation but I don?t think the documentation should encourage novices to do so. A From klarsen at neweralife.com Wed May 20 20:22:55 2020 From: klarsen at neweralife.com (Kent A. Larsen) Date: Wed, 20 May 2020 18:22:55 +0000 Subject: FW: gpg-agent connection errors In-Reply-To: References: Message-ID: Werner, If that's the case, then why do we continue to intermittently get the following messages when issuing a command to sign+encrypt (or decrypt) a file? gpg: can't connect to the agent: IPC connect call failed gpg: keydb_search failed: No agent running gpg: skipped "0x8A811544": No agent running gpg: //neofs1/Userdata/IT/FileRetrieval/Chase/PositivePay/Positive_Pay_LifePRO.txt: sign+encrypt failed: No agent running I've adding logging to our gpg-agent.conf file, and when these errors occur the gpg-agent log file has the following error: 2020-05-18 09:36:07 gpg-agent[3800] error binding socket to '\\Neofs1\Userapps\Apps\GnuPG\Keys\S.gpg-agent': Unknown error Have had three of these just this week already. What could be causing this, and what can we do to prevent it? Thanks. Kent A. Larsen, FLMI Systems Analyst New Era/Philadelphia American Life Insurance Companies klarsen at neweralife.com Direct: (402) 905-2179 ----Reply---- No. Fruther, gpg-agent and all other background processes are always started on demand. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -----Original Message----- From: Kent A. Larsen Sent: Tuesday, May 05, 2020 7:10 AM To: gnupg-users at gnupg.org Subject: gpg-agent connection errors As part of a server upgrade, we recently replaced a GnuPG 1.4.x installation with GnuPG 2.2.19, from the Gpg4win package (3.1.11). The server is running Windows Server 2016. We have an un-attended application that runs on that same server that needs to sign+encrypt a file (4 to 6 distinct files each weekday)for transfer to an external client. Since the upgrade, invoking gpg to sign+encypt a file periodically fails with the message "gpg: can't connect to the agent: IPC call failed" followed by messages indicating "No agent running". The failure appears to occur on the first file processed (in a group of 3 or more files), and the remaining files are processed without error. We are relying on gpg to automatically start gpg-agent (as needed). Does gpg-agent auto-terminate after a certain period of inactivity? Would appreciate any help you can provide that would allow us to eliminate these errors. Thanks. Kent A. Larsen, FLMI Systems Analyst New Era/Philadelphia American Life Insurance Companies klarsen at neweralife.com Direct: (402) 905-2179 HIPAA requires covered entities to safeguard Protected Health Information (PHI) related to a person's health care. Information in this email may include PHI that has been provided after appropriate authorization from the patient or under certain circumstances that do not require the patient's authorization. You, the recipient, are obligated to maintain PHI in a safe and secure manner. You may not use or disclose this email without additional patient consent unless required by law. Unauthorized use or disclosure of or failure to safeguard PHI could subject you to penalties under state and/or federal law. The information contained in this email and any attachments is also confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, please notify us immediately and delete this email from your email system. Please also shred any hard copy of this email and attachments, if any. If you have received this email in error, please notify our Privacy Officer immediately at (281)368-7200 (in Houston) or toll free at (800)552-7879. From ryan at digicana.com Wed May 20 21:21:18 2020 From: ryan at digicana.com (Ryan McGinnis) Date: Wed, 20 May 2020 19:21:18 +0000 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <16910653803.20200520181818@mail.riseup.net> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> <16910653803.20200520181818@mail.riseup.net> Message-ID: <5cfOcUfdntiMBCGvKMu8V4EekJzx6SLAvTbpi9OK6mRmCeNmhZ-SU_lOyVcrBuvhVUAfIdqVKT-fFMZWEMbsNoMIrAGQ_3A2IkszUCwD6YY=@digicana.com> Interestingly enough, this breaks the Thunderbird/Protonmail integration, so your message just shows up as the raw PGP blob that Protonmail is pushing to the Protonmail client. It returns the error " Decryption error Decryption of this message's encrypted content failed. openpgp: unsupported feature: nested signatures " -Ryan McGinnis http://www.bigstormpicture.com Sent via ProtonMail ??????? Original Message ??????? On Wednesday, May 20, 2020 12:18 PM, MFPA via Gnupg-users wrote: > Hi > > On Saturday 16 May 2020 at 9:49:55 PM, in > mid:20200516224955.00005826.sac at 300baud.de, Stefan Claas wrote:- > > > out of curiosity, you signed the reply with two sub > > keys, > > The RSA signature is for the benefit of recipients who can't handle > ECC keys/signatures. Probably not needed anymore. > > > the hash algo > > used? > > I'm hopefully using SHA512. > > ------------------------------ > > Best regards > > MFPA mailto:2017-r3sgs86x8e-lists-groups at riseup.net > > Ballerinas are always on their toes. We need taller ballerinas! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 823 bytes Desc: OpenPGP digital signature URL: From listofactor at mail.ru Thu May 21 00:14:40 2020 From: listofactor at mail.ru (LisToFacTor) Date: Wed, 20 May 2020 22:14:40 +0000 Subject: "just invent something..." In-Reply-To: References: Message-ID: On 5/20/20 6:52 PM, Andrew Gallagher wrote: > >> On 20 May 2020, at 18:51, LisToFacTor via Gnupg-users wrote: >> >> Demanding a piece of information from someone who would prefer not >> to give it is equally user-hostile, especially so if he who demands >> it does so only because it is required by some internal mechanics >> of the system he constructed > > ?Demand? is a strong word that I don?t believe is justified here, and only serves to inflame the debate. > > Most implementations of email require that you enter a ?real name? of some kind. OpenPGP/GPG strongly encourage you to use the same real name on your key as you use on your email profile - this is for the benefit of your correspondents, since using different IDs will likely cause confusion. You are free to ignore this recommendation but I don?t think the documentation should encourage novices to do so. English is not my native tongue, and the word I've chosen is based on my interpretation of the dialog presented by the program when generating the key: > GnuPG needs to construct a user ID to identify your key. > that the Old Guard (somebody used the term in one of the previous posts) just can't even > Real name: upon entering an empty string, the response is: ... > gpg: [internal]: no User-ID specified (and the program quits with no further explanation) To me, this appears to qualify as a demand for user's "Real name". It is not up to a program designer to decide that it is mandatory for a user to provide a piece of personally identifiable information because "this is for the benefit of your correspondents, since using different IDs will likely cause confusion." User is the one to decide what personally identifiable information to provide, when and to whom. And if the is demand for such information is refused, and the service is summarily denied, (as outlined above) then it is not okay for the program designer to wash his hands with "...so why didn't you just invent something...". Of course, it would be a one-minute job to change the prompt to "enter a ?real name? of some kind..." (or something to that effect, better formulated). But with that, the whole "Web of Trust" structure would collapse, and that is something to horrible to even contemplate. From azbigdogs at gmx.com Thu May 21 00:16:52 2020 From: azbigdogs at gmx.com (Mark) Date: Wed, 20 May 2020 15:16:52 -0700 Subject: keys require a user-id In-Reply-To: References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> Message-ID: <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> It must be... With all the talk of "anonymous" keys I wanted to see if I could create one with Kleopatra, especially since it says optional for name. On 5/20/2020 12:27 AM, Andrew Gallagher wrote: >> On 20 May 2020, at 06:32, Mark wrote: >> >> Just to test this out I tried creating a new key in Kleopatra with no >> name and then with just a single name and it would not let me do it. It >> had to have a first and at least a last initial. > This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line. > > Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example. > > A From azbigdogs at gmx.com Thu May 21 00:27:28 2020 From: azbigdogs at gmx.com (Mark) Date: Wed, 20 May 2020 15:27:28 -0700 Subject: keys require a user-id In-Reply-To: <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> Message-ID: <33e5c289-3a76-8c1d-34a6-4734cc9fc405@gmx.com> Did a bit more experimenting with it.? You can have something only in the first name field but it has to be a minimum of 5 characters and the first one must be a letter. ..? On 5/20/2020 3:16 PM, Mark wrote: > It must be... With all the talk of "anonymous" keys I wanted to see if I > could create one with Kleopatra, especially since it says optional for > name. > > On 5/20/2020 12:27 AM, Andrew Gallagher wrote: >>> On 20 May 2020, at 06:32, Mark wrote: >>> >>> Just to test this out I tried creating a new key in Kleopatra with no >>> name and then with just a single name and it would not let me do it. It >>> had to have a first and at least a last initial. >> This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line. >> >> Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example. >> >> A > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From kloecker at kde.org Thu May 21 12:52:38 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 21 May 2020 12:52:38 +0200 Subject: "just invent something..." In-Reply-To: References: Message-ID: <1973874.izRjBTkQyM@breq> On Donnerstag, 21. Mai 2020 00:14:40 CEST LisToFacTor via Gnupg-users wrote: > English is not my native tongue, and the word I've chosen is based > on my interpretation of the dialog presented by the program when > generating the key: > > > GnuPG needs to construct a user ID to identify your key. > > > > Real name: > upon entering an empty string, the response is: > ... > > > gpg: [internal]: no User-ID specified > > (and the program quits with no further explanation) > > To me, this appears to qualify as a demand for user's "Real name". I suppose you also entered an empty string for "Email address": ``` $ gpg --gen-key Note: Use "gpg2 --full-generate-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: Email address: You selected this USER-ID: "" Change (N)ame, (E)mail, or (O)kay/(Q)uit? o gpg: [internal]: no User-ID specified ``` Generating a key with empty "Real name" and non-empty "Email address" (and vice versa) works: ``` $ gpg --gen-key Note: Use "gpg2 --full-generate-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: Email address: foo at example.com You selected this USER-ID: "foo at example.com" Change (N)ame, (E)mail, or (O)kay/(Q)uit? o [...] ``` A key with above User-ID is generated. I agree that there could be a more user-friendly error message than "gpg: [internal]: no User-ID specified". In particular, it makes little sense to ask the user if everything is okay if the empty values the user entered do not result in a valid User-ID. Regards, Ingo From listofactor at mail.ru Thu May 21 15:34:48 2020 From: listofactor at mail.ru (LisToFacTor) Date: Thu, 21 May 2020 13:34:48 +0000 Subject: "just invent something..." In-Reply-To: <1973874.izRjBTkQyM@breq> References: <1973874.izRjBTkQyM@breq> Message-ID: <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> On 5/21/20 10:52 AM, Ingo Kl?cker - kloecker at kde.org wrote: > On Donnerstag, 21. Mai 2020 00:14:40 CEST LisToFacTor via Gnupg-users wrote: > I suppose you also entered an empty string for "Email address": > `` > Real name: > Email address: foo at example.com > You selected this USER-ID: > "foo at example.com" > > Change (N)ame, (E)mail, or (O)kay/(Q)uit? o > [...] > ``` > A key with above User-ID is generated. You are correct, the e-mail address was likewise an empty string. First, let me mention that Web of Trust is to me not a useful public key verification mechanism, as it is compromises my privacy. I use other methods to make it possible for my correspondents to verify the key. I do not have a/one e-mail address either. At any point in time, I might be using any number of addresses, depending on who I'm communicating with, and none of those addresses is likely to remain in use as long as the key I am generating. None of such e-mail correspondents would have any idea whatsoever what to do with a gpg-encrypted message received from me anyways. On the other hand, for the exchange of personal and confidential messages, I do not use the "conventional" e-mail at all - the encrypted text is exchanged by other means, of which there are myriad. I do know I could have given my name as "Peter P. Pumpkineater" and the e-mail address as "peter.p.pumpkineater at example.com" and the program would generate the key-pair for me. But the question begs: is inventing false information the proper way of preventing the leakage of personally identifiable information, completely unnecessarily, via programs constructed by system architects whose thinking about the privacy is stuck in the time long behind us? The proper thing for gpg program to do would be to allow the personally identifiable information in the key to be optional, and to warn the user generating such key that he will not be able to participate in the Web of Trust. Wouldn't that be a better system design than demanding the user to provide the false information and treating such information as valid? Especially as one would not be able to participate in the Web of Trust as "Peter P. Pumpkineater", but there is no way for a program to issue any warning for that? From sac at 300baud.de Thu May 21 16:30:11 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 21 May 2020 16:30:11 +0200 Subject: keys require a user-id In-Reply-To: <33e5c289-3a76-8c1d-34a6-4734cc9fc405@gmx.com> References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> <33e5c289-3a76-8c1d-34a6-4734cc9fc405@gmx.com> Message-ID: <20200521163011.00005e1e.sac@300baud.de> Mark wrote: Hi, > Did a bit more experimenting with it.? You can have something only in > the first name field but it has to be a minimum of 5 characters and > the first one must be a letter. .. If you are familiar with GnuPG in command line mode you may try out sequoia pgp, which I compiled a Windows binary for, so that you can see how easy it is to have UID-less public keyblocks and how to assign labels for such keys. dkg once said IIRC 'less is more', not in this context but this is what I love about sequoia pgp. https://keybase.pub/stefan_claas/software/sequoia-pgp_Win64.zip https://docs.sequoia-pgp.org/sq/index.html Regards Stefan? -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From andrewg at andrewg.com Thu May 21 16:32:16 2020 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 21 May 2020 15:32:16 +0100 Subject: "just invent something..." In-Reply-To: <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> Message-ID: On 21/05/2020 14:34, LisToFacTor via Gnupg-users wrote: >> The proper thing for gpg program to do would be to allow the > personally identifiable information in the key to be optional, > and to warn the user generating such key that he will not be able > to participate in the Web of Trust. I think you're getting overly hung up on the web of trust. The contents of the User ID are independent of the WoT - they exist to tell your email program which keys belong to which correspondents. You can use a WoT with keys that have no email addresses in them, so long as the verification chain is cryptographically valid and you have the appropriate settings in your trustdb. Your WoT could be made up of Donald Duck, Mickey Mouse and Goofy - the only time the UID's contents become important (as opposed to its certifications) is when you want to send an email to president at whitehouse.gov you should have a valid key that has "president at whitehouse.gov" in either its User ID or local alias (as RJH pointed out above). -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mwood at iupui.edu Thu May 21 15:48:44 2020 From: mwood at iupui.edu (Mark H. Wood) Date: Thu, 21 May 2020 09:48:44 -0400 Subject: keys require a user-id In-Reply-To: <33e5c289-3a76-8c1d-34a6-4734cc9fc405@gmx.com> References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> <33e5c289-3a76-8c1d-34a6-4734cc9fc405@gmx.com> Message-ID: <20200521134844.GA27039@IUPUI.Edu> On Wed, May 20, 2020 at 03:27:28PM -0700, Mark wrote: > Did a bit more experimenting with it.? You can have something only in > the first name field but it has to be a minimum of 5 characters and the > first one must be a letter. ..? *sigh* https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ > On 5/20/2020 3:16 PM, Mark wrote: > > It must be... With all the talk of "anonymous" keys I wanted to see if I > > could create one with Kleopatra, especially since it says optional for > > name. > > > > On 5/20/2020 12:27 AM, Andrew Gallagher wrote: > >>> On 20 May 2020, at 06:32, Mark wrote: > >>> > >>> Just to test this out I tried creating a new key in Kleopatra with no > >>> name and then with just a single name and it would not let me do it. It > >>> had to have a first and at least a last initial. > >> This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line. > >> > >> Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From rjh at sixdemonbag.org Thu May 21 18:48:01 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 May 2020 12:48:01 -0400 Subject: "just invent something..." In-Reply-To: <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> Message-ID: <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> > First, let me mention that Web of Trust is to me not a useful public > key verification mechanism, as it is compromises my privacy. Only if your sigs are exportable. Local sigs are a perfectly legitimate way to use the WoT. If Alice locally signs Bob's certificate and sets Bob up as a trusted introducer, Alice can benefit from Bob vouching for Charlotte's certificate without revealing her identity to Charlotte -- or even the fact that she (Alice) even exists. > But the question begs: is inventing false information the proper way > of preventing the leakage of personally identifiable information, > completely unnecessarily, via programs constructed by system > architects whose thinking about the privacy is stuck in the time long > behind us? The question is irrelevant. OpenPGP allows you to use true identity information, false information, or true information about a persona, or false information about a persona, or a recipe for a nice habanero salsa. Do what's right for you, and understand that what's right for you may well be different from what's right for others. (Saute two thinly-sliced cloves of garlic in a little oil for a few minutes until they start releasing the garlicky goodness. Add a pinch of ground cumin; saute another minute. Add 500g finely-diced tomatoes and their juices, one habanero finely-diced, cook over low heat for ten minutes stirring constantly. Once the tomatoes and peppers are well-cooked, pour into a blender or food processor. Add cilantro and the juice of one lime, puree the mixture, pour into a bowl. Decorate with lime slices. And here you thought this mailing list was only good for nerd stuff...) > The proper thing for gpg program to do would be to allow the > personally identifiable information in the key to be optional, It already is. > and to warn the user generating such key that he will not be able to > participate in the Web of Trust. But they can. From sac at 300baud.de Thu May 21 19:51:16 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 21 May 2020 19:51:16 +0200 Subject: "just invent something..." In-Reply-To: <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> Message-ID: <20200521195116.0000780a.sac@300baud.de> Robert J. Hansen wrote: > > First, let me mention that Web of Trust is to me not a useful > > public key verification mechanism, as it is compromises my privacy. > > Only if your sigs are exportable. Local sigs are a perfectly > legitimate way to use the WoT. If Alice locally signs Bob's > certificate and sets Bob up as a trusted introducer, Alice can > benefit from Bob vouching for Charlotte's certificate without > revealing her identity to Charlotte -- or even the fact that she > (Alice) even exists. > > > But the question begs: is inventing false information the proper > > way of preventing the leakage of personally identifiable > > information, completely unnecessarily, via programs constructed by > > system architects whose thinking about the privacy is stuck in the > > time long behind us? > > The question is irrelevant. OpenPGP allows you to use true identity > information, false information, or true information about a persona, > or false information about a persona, or a recipe for a nice habanero > salsa. Do what's right for you, and understand that what's right for > you may well be different from what's right for others. > > (Saute two thinly-sliced cloves of garlic in a little oil for a few > minutes until they start releasing the garlicky goodness. Add a pinch > of ground cumin; saute another minute. Add 500g finely-diced tomatoes > and their juices, one habanero finely-diced, cook over low heat for > ten minutes stirring constantly. Once the tomatoes and peppers are > well-cooked, pour into a blender or food processor. Add cilantro and > the juice of one lime, puree the mixture, pour into a bowl. Decorate > with lime slices. And here you thought this mailing list was only > good for nerd stuff...) > > > The proper thing for gpg program to do would be to allow the > > personally identifiable information in the key to be optional, > > It already is. > > > and to warn the user generating such key that he will not be able to > > participate in the Web of Trust. > > But they can. I miss dkg here on the ML ... Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From angel at pgp.16bits.net Fri May 22 03:18:40 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 22 May 2020 03:18:40 +0200 Subject: FW: gpg-agent connection errors In-Reply-To: References: Message-ID: <1590110320.1078.11.camel@16bits.net> On 2020-05-20 at 18:22 +0000, Kent A. Larsen wrote: > I've adding logging to our gpg-agent.conf file, and when these errors > occur the gpg-agent log file has the following error: > 2020-05-18 09:36:07 gpg-agent[3800] error binding socket to '\\Neofs1 > \Userapps\Apps\GnuPG\Keys\S.gpg-agent': Unknown error > Have had three of these just this week already. > What could be causing this, and what can we do to prevent it? > Thanks. Is the program installed on a remote server? I would place the gpg-agent socket on a local filesystem. I don't know how this AF_UNIX socket is actually implemented on Gpg4win (as a named pipe, perhaps?), but your issues might be related to having it on a network filesystem (I'm surprised it works, actually). Cheers From angel at pgp.16bits.net Fri May 22 04:07:37 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Fri, 22 May 2020 04:07:37 +0200 Subject: "just invent something..." In-Reply-To: References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> Message-ID: <1590113257.1078.37.camel@16bits.net> Given the number of people that still manage to create (and distribute) their keys with glaring mistakes, such as misspelling their own domain name/tld, or providing a key which doesn't match their email address. Too many people is sending and receiving openpgp emails by actually encrypting the content on a separate application, then pasting it on their MUA (often resulting in the openpgp armor contained in a html/text block! ?). Which then leads to the occasional mistake of the wrong key being manually chosen. People should *really* use a MUA supporting OpenPGP if they are going to send or receive OpenPGP emails. It's a big mistake that end users think it's normal to process that separately. I don't think relaxing the current uid validation would help with that. Quite the opposite. The stated issue could be solved, while keeping rfc4880 conformance, by adding a skip path on the key creation: > You have chosen not to provide a uid to the new key. It is recommended > to add an identifier. A key specifying no email address will be > severely limited if it is going to be used to send or receive mail, as > it won't be linked with that account. > > If not providing a uid, usage of this key will have to be done using > the user-unfriendly key fingerprint. By continuing with no explicit > uid, GnuPG will automatically fill the uid field with the key > fingerprint A1786ADB27E946D5DC1B5A989EED09D63FCD9AB7 > > > Do you want to create such a key anyway? [y/N] I still wonder if it's worth adding that code for this limited use case, though. On 2020-05-21 at 15:32 +0100, Andrew Gallagher wrote: > you should have a valid key > that has "president at whitehouse.gov" in either its User ID or local > alias (as RJH pointed out above). Note you may need to set your alias for "", not "president at whitehouse.gov". It will depend on how is gnupg called by the MUA. Best regards From azbigdogs at gmx.com Fri May 22 06:20:13 2020 From: azbigdogs at gmx.com (Mark) Date: Thu, 21 May 2020 21:20:13 -0700 Subject: keys require a user-id In-Reply-To: <20200521163011.00005e1e.sac@300baud.de> References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> <33e5c289-3a76-8c1d-34a6-4734cc9fc405@gmx.com> <20200521163011.00005e1e.sac@300baud.de> Message-ID: Thanks I may take a look at it and just see what it does. I'm still VERY much a novice in regards to all this so just trying to learn more. My "experiment" with Kleopatra was just to see if I could since it said "optional" for the name part.? Sorry, not sure who dkg is but have seen those initials mentioned a few times. On 5/21/2020 7:30 AM, Stefan Claas wrote: > Mark wrote: > Hi, > >> Did a bit more experimenting with it.? You can have something only in >> the first name field but it has to be a minimum of 5 characters and >> the first one must be a letter. .. > If you are familiar with GnuPG in command line mode you may try out > sequoia pgp, which I compiled a Windows binary for, so that you > can see how easy it is to have UID-less public keyblocks and how > to assign labels for such keys. > > dkg once said IIRC 'less is more', not in this context but this > is what I love about sequoia pgp. > > https://keybase.pub/stefan_claas/software/sequoia-pgp_Win64.zip > > https://docs.sequoia-pgp.org/sq/index.html > > Regards > Stefan? > From azbigdogs at gmx.com Fri May 22 06:21:35 2020 From: azbigdogs at gmx.com (Mark) Date: Thu, 21 May 2020 21:21:35 -0700 Subject: keys require a user-id In-Reply-To: <20200521134844.GA27039@IUPUI.Edu> References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> <33e5c289-3a76-8c1d-34a6-4734cc9fc405@gmx.com> <20200521134844.GA27039@IUPUI.Edu> Message-ID: <9af82c2d-7fd0-53c1-8691-98e90c2814cf@gmx.com> That is very true.? I have a friend whose first name is M'Lou and she's had all kinds of issues when systems freak out over her first name. On 5/21/2020 6:48 AM, Mark H. Wood via Gnupg-users wrote: > On Wed, May 20, 2020 at 03:27:28PM -0700, Mark wrote: >> Did a bit more experimenting with it.? You can have something only in >> the first name field but it has to be a minimum of 5 characters and the >> first one must be a letter. ..? > *sigh* > https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ > >> On 5/20/2020 3:16 PM, Mark wrote: >>> It must be... With all the talk of "anonymous" keys I wanted to see if I >>> could create one with Kleopatra, especially since it says optional for >>> name. >>> >>> On 5/20/2020 12:27 AM, Andrew Gallagher wrote: >>>>> On 20 May 2020, at 06:32, Mark wrote: >>>>> >>>>> Just to test this out I tried creating a new key in Kleopatra with no >>>>> name and then with just a single name and it would not let me do it. It >>>>> had to have a first and at least a last initial. >>>> This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line. >>>> >>>> Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example. >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sac at 300baud.de Fri May 22 09:19:02 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 22 May 2020 09:19:02 +0200 Subject: keys require a user-id In-Reply-To: References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> <33e5c289-3a76-8c1d-34a6-4734cc9fc405@gmx.com> <20200521163011.00005e1e.sac@300baud.de> Message-ID: <20200522091902.00001919.sac@300baud.de> Mark wrote: > Thanks I may take a look at it and just see what it does. I'm still > VERY much a novice in regards to all this so just trying to learn > more. My "experiment" with Kleopatra was just to see if I could since > it said "optional" for the name part.? > > Sorry, not sure who dkg is but have seen those initials mentioned a > few times. Hi, dkg stands for Daniel Kahn Gillmor. He is a highly respected member in the GnuPG/OpenPGP scene and maintains GnuPG for the Linux Debian OS. He is also author of the Abuse-Resistant OpenPGP Keystores Internet Draft and also author of the Stateless OpenPGP command line interface framework. If you do a Google look-up for him you can learn more about him. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From wk at gnupg.org Fri May 22 10:48:55 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 May 2020 10:48:55 +0200 Subject: FW: gpg-agent connection errors In-Reply-To: <1590110320.1078.11.camel@16bits.net> (=?utf-8?Q?=22=C3=81nge?= =?utf-8?Q?l=22's?= message of "Fri, 22 May 2020 03:18:40 +0200") References: <1590110320.1078.11.camel@16bits.net> Message-ID: <87a7204ao8.fsf@wheatstone.g10code.de> On Fri, 22 May 2020 03:18, ?ngel said: > how this AF_UNIX socket is actually implemented on Gpg4win (as a named > pipe, perhaps?), but your issues might be related to having it on a It is a regular file with a nonce and a port. The server listens on localhost:THATPORT for connections and checks that the client provides the nonce in an initial handshake. Now if some plain stupid firewall software (Symantec _used_ to be one) blocks connections from localhost to localhost things won't work. But that can't be the problem of the OP because it worked most of the times. FWIW, Named pipes are not used because there is no mechanism on Windows to restrict them to the local machine. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Fri May 22 10:52:35 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 May 2020 10:52:35 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <1337448496.20200520180632@mail.riseup.net> (MFPA via Gnupg-users's message of "Wed, 20 May 2020 18:06:32 +0100") References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> <1589682794.1744.76.camel@16bits.net> <875zct92gk.fsf@wheatstone.g10code.de> <1337448496.20200520180632@mail.riseup.net> Message-ID: <875zco4ai4.fsf@wheatstone.g10code.de> On Wed, 20 May 2020 18:06, MFPA said: > Does (or will) --include-key-block have an argument that can be set to > tell it to only include ECC keyblocks, or to set a maximum keyblock No, it is better to let the caller (ee.g. the MUA) pass this option than to have it in a config file. (I initially used this too in my gpg.conf with the result that all my Git commits carried my key, which is useless). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Fri May 22 10:58:14 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 May 2020 10:58:14 +0200 Subject: keys require a user-id In-Reply-To: <20200520191147.000007a0.sac@300baud.de> (Stefan Claas's message of "Wed, 20 May 2020 19:11:47 +0200") References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200518131202.00004579.sac@300baud.de> <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> <87sgfu4mk8.fsf@wheatstone.g10code.de> <20200520191147.000007a0.sac@300baud.de> Message-ID: <871rnc4a8p.fsf@wheatstone.g10code.de> On Wed, 20 May 2020 19:11, Stefan Claas said: > Curious as I am, did Mr Sch?nbohm never asked you why your public > keyblock is not signed by Governikus? I don't know a Mr. Sch?nbohm. I know Governikus and recently noticed that their software does not even support the recommended set of algorithm for ECC in S/MIME. > https://keybase.io/stefan_claas Mandating no user id and using a service which by design is the quite the opposite of it ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Fri May 22 11:07:29 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 May 2020 11:07:29 +0200 Subject: keys require a user-id In-Reply-To: <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> (Mark's message of "Wed, 20 May 2020 15:16:52 -0700") References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> Message-ID: <87wo542v8u.fsf@wheatstone.g10code.de> On Wed, 20 May 2020 15:16, Mark said: > It must be... With all the talk of "anonymous" keys I wanted to see if I > could create one with Kleopatra, especially since it says optional for > name. The name should indeed be optiona; If that has not been fixed in the latest version, please file a bug. GPG has always allowed to create a key with just a mail address: --8<---------------cut here---------------start------------->8--- $ gpg --gen-key Note: Use "gpg --full-generate-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: Email address: foo at example.org You selected this USER-ID: "foo at example.org" Change (N)ame, (E)mail, or (O)kay/(Q)uit? o --8<---------------cut here---------------end--------------->8--- Or with the not anymore new quick command: --8<---------------cut here---------------start------------->8--- $ gpg --quick-gen-key foo at example.org About to create a key for: "foo at example.org" Continue? (Y/n) --8<---------------cut here---------------end--------------->8--- Now, if you want to have the fingerprint as a User-ID, that needs a bit of extra work: First create a key with some arbitrary user-id, then use --edit-key to add a new User-ID containg the fingerprint, delete the original User-ID, save, and publish the key. I do not suggest such user IDs because they would only confuse users. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Fri May 22 11:19:51 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 22 May 2020 11:19:51 +0200 Subject: keys require a user-id In-Reply-To: <871rnc4a8p.fsf@wheatstone.g10code.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <87mu69a8j0.fsf_-_@wheatstone.g10code.de> <20200515132931.00006da2.sac@300baud.de> <20200515181606.00003609.sac@300baud.de> <194a4735-5ca5-7ddd-cfee-1105e0d92aae@sixdemonbag.org> <20200515190740.00006d15.sac@300baud.de> <20200518131202.00004579.sac@300baud.de> <684c9cac-1451-d628-e0b6-981121f6dd63@sixdemonbag.org> <87sgfu4mk8.fsf@wheatstone.g10code.de> <20200520191147.000007a0.sac@300baud.de> <871rnc4a8p.fsf@wheatstone.g10code.de> Message-ID: <20200522111951.00006e18.sac@300baud.de> Werner Koch wrote: > On Wed, 20 May 2020 19:11, Stefan Claas said: > > > Curious as I am, did Mr Sch?nbohm never asked you why your public > > keyblock is not signed by Governikus? > > I don't know a Mr. Sch?nbohm. I know Governikus and recently noticed > that their software does not even support the recommended set of > algorithm for ECC in S/MIME. Ok, I thought at least he knows you. > > https://keybase.io/stefan_claas > > Mandating no user id and using a service which by design is the quite > the opposite of it ;-) Well, that is easy to explain. I use keybase for file storage (250 GB per user) and for chatting there with friends or in teams with other people. Nice free service IMHO. Regards Stefan -- Signal (Desktop) +4915172173279 https://keybase.io/stefan_claas From kloecker at kde.org Fri May 22 11:24:39 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 22 May 2020 11:24:39 +0200 Subject: FW: gpg-agent connection errors In-Reply-To: <87a7204ao8.fsf@wheatstone.g10code.de> References: <1590110320.1078.11.camel@16bits.net> <87a7204ao8.fsf@wheatstone.g10code.de> Message-ID: <2448998.9D425lGOHK@breq> On Freitag, 22. Mai 2020 10:48:55 CEST Werner Koch via Gnupg-users wrote: > On Fri, 22 May 2020 03:18, ?ngel said: > > how this AF_UNIX socket is actually implemented on Gpg4win (as a named > > pipe, perhaps?), but your issues might be related to having it on a > > It is a regular file with a nonce and a port. The server listens on > localhost:THATPORT for connections and checks that the client provides > the nonce in an initial handshake. Now if some plain stupid firewall > software (Symantec _used_ to be one) blocks connections from localhost > to localhost things won't work. But that can't be the problem of the OP > because it worked most of the times. Could also be caused by antivirus software. Such software prevents access to new files until it has checked those files. Maybe telling the antivirus software to ignore S.gpg-agent files helps. As for gpg-agent, maybe it could retry binding the socket a few times (with some delay) if an unknown error occurs. Regards, Ingo From rjh at sixdemonbag.org Fri May 22 13:50:21 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 22 May 2020 07:50:21 -0400 Subject: keys require a user-id In-Reply-To: <20200522091902.00001919.sac@300baud.de> References: <3fccf6cb-960f-7790-759b-87a8ae623189@gmx.com> <2fbbebc7-b696-61ae-9a8f-ef8646b593a1@gmx.com> <33e5c289-3a76-8c1d-34a6-4734cc9fc405@gmx.com> <20200521163011.00005e1e.sac@300baud.de> <20200522091902.00001919.sac@300baud.de> Message-ID: <565f7644-4a92-febe-2285-2a16010c064d@sixdemonbag.org> > dkg stands for Daniel Kahn Gillmor. He is a highly respected member > in the GnuPG/OpenPGP scene and maintains GnuPG for the Linux Debian > OS. He would prefer you refer to Debian as the GNU/Linux Debian OS. :) dkg is also a genuinely pleasant person. I've met him a couple of times at conferences. He's very nice. We need more kind people in the community. :) From 2017-r3sgs86x8e-lists-groups at riseup.net Fri May 22 16:08:27 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Fri, 22 May 2020 15:08:27 +0100 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <875zco4ai4.fsf@wheatstone.g10code.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> <1589682794.1744.76.camel@16bits.net> <875zct92gk.fsf@wheatstone.g10code.de> <1337448496.20200520180632@mail.riseup.net> <875zco4ai4.fsf@wheatstone.g10code.de> Message-ID: <1888339675.20200522150827@mail.riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 22 May 2020 at 9:52:35 AM, in , Werner Koch wrote:- > No, it is better to let the caller (ee.g. the MUA) > pass this option How would it be used only with ECC keys? The MUA doesn't know the flavour of key/subkey. - -- Best regards MFPA There is no snooze button for a cat that wants breakfast -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXsfc218UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +u+dAP499g1GlTd1mJXXE6GVhWp4OUGdcspAJ1qpLJDkTV0bwwEA0q53yxehqA1a jl+5cgVZu3ZpJiEMtzp+6P8If0a9eAo= =U1MD -----END PGP SIGNATURE----- From klarsen at neweralife.com Fri May 22 14:24:53 2020 From: klarsen at neweralife.com (Kent A. Larsen) Date: Fri, 22 May 2020 12:24:53 +0000 Subject: FW: gpg-agent connection errors In-Reply-To: <87a7204ao8.fsf@wheatstone.g10code.de> References: <1590110320.1078.11.camel@16bits.net> <87a7204ao8.fsf@wheatstone.g10code.de> Message-ID: It is installed on the local file system of one of our internal servers, a portion of which is shared on our internal network. The server is running Windows Server 2016, and all of the clients that can access it are running Windows 10 or Windows Server 2012 R2 or higher. FWIW, GnuPG 1.x (latest probably 1.4.20 or 21) ran flawlessly in a similar installation arrangement for almost 15 years, before we upgraded to GnuPG 2.2.19 (via gpg4win 3.1.11) as part of the migration of the server to Windows Server 2016. As far as AV goes, a current version of ESET is running on the server, but I've already tried excluding the entire Keys subfolder (where those connection files and the keyring reside) from its scanning. I'll have our Network Administrator look into the firewall configuration, but as Werner observed, it doesn't fail ALL the time. Thanks. Kent A. Larsen, FLMI Systems Analyst New Era/Philadelphia American Life Insurance Companies klarsen at neweralife.com Direct: (402) 905-2179 -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Werner Koch via Gnupg-users Sent: Friday, May 22, 2020 3:49 AM To: ?ngel Cc: gnupg-users at gnupg.org Subject: Re: FW: gpg-agent connection errors ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown or unexpected emails. On Fri, 22 May 2020 03:18, ?ngel said: > how this AF_UNIX socket is actually implemented on Gpg4win (as a named > pipe, perhaps?), but your issues might be related to having it on a It is a regular file with a nonce and a port. The server listens on localhost:THATPORT for connections and checks that the client provides the nonce in an initial handshake. Now if some plain stupid firewall software (Symantec _used_ to be one) blocks connections from localhost to localhost things won't work. But that can't be the problem of the OP because it worked most of the times. FWIW, Named pipes are not used because there is no mechanism on Windows to restrict them to the local machine. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. HIPAA requires covered entities to safeguard Protected Health Information (PHI) related to a person's health care. Information in this email may include PHI that has been provided after appropriate authorization from the patient or under certain circumstances that do not require the patient's authorization. You, the recipient, are obligated to maintain PHI in a safe and secure manner. You may not use or disclose this email without additional patient consent unless required by law. Unauthorized use or disclosure of or failure to safeguard PHI could subject you to penalties under state and/or federal law. The information contained in this email and any attachments is also confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, please notify us immediately and delete this email from your email system. Please also shred any hard copy of this email and attachments, if any. If you have received this email in error, please notify our Privacy Officer immediately at (281)368-7200 (in Houston) or toll free at (800)552-7879. From listofactor at mail.ru Sat May 23 00:18:10 2020 From: listofactor at mail.ru (LisToFacTor) Date: Fri, 22 May 2020 22:18:10 +0000 Subject: "just invent something..." In-Reply-To: <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> Message-ID: Robert, Hi and thanks for the reply. Salsa is cooking. And since you are so kind: It would help a whole lot if GPG included some authoritative documentation on how to use the program in the following scenario: - The trust in the correspondent's public key is established only by comparing the key fingerprint derived programmatically from the locally stored key-file and a copy independently obtained from the owner. The only identification of a public key is its fingerprint. Since the public key is either known to an adversary, or it is very hard to guard against such eventuality, the public key itself should not provide the adversary with any useful information. - All gpg operations (key generation, encryption, decryption) are carried out on a device not connected to the Internet. - There is no e-mail. (It's not just "resting", it is DEAD). It would really, really help. p.s. Out-of-channel fingerprint dissemination and exchange of ciphertext without the benefit of the e-mail system has been dealt with, so there is no need at all to address that. From cyrus.segura at gmail.com Sat May 23 09:42:15 2020 From: cyrus.segura at gmail.com (Cyrus Segura) Date: Sat, 23 May 2020 03:42:15 -0400 Subject: MacOSX help - beginner installation, first time Message-ID: Hi everyone, I'm new to GnuPG. I'm trying to install it for MacOSX, and I have a beginner's question. ***Do I need to verify more information about the validity of GnuPG if: 1.) The SHA-256 checksum on my Mac's Terminal matches the one on SourceForge where the Mac installer (.dmg) file is? 2.) The Mac installer (.dmg) and the Mac signature for the installer (.dmg.sig) are both verified on my Mac's separate program "GPG Suite" (made by "https://gpgtools.org/")? ***The files in question are "GnuPG-2.2.20.dmg", "GnuPG-2.2.20.dmg.sig", and "Enigmail_public_key.asc". The link for the Mac downloads is " https://sourceforge.net/p/gpgosx/docu/Download/" Thank you very much for your time! Cyrus -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sat May 23 18:30:30 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 23 May 2020 12:30:30 -0400 Subject: "just invent something..." In-Reply-To: References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> Message-ID: > - The trust in the correspondent's public key is established only > by comparing the key fingerprint derived programmatically from the > locally stored key-file and a copy independently obtained from > the owner. The only identification of a public key is its fingerprint. > Since the public key is either known to an adversary, or it is very > hard to guard against such eventuality, the public key itself should > not provide the adversary with any useful information. Okay, but this seems largely redundant with section 8.12 of the FAQ, which, uh ... does exactly this. What exactly are you objecting to? ===== 8.12 How do I use another person?s certificate? In order to send an encrypted message or verify a signature, you must obtain the certificate for the recipient?s/signer?s public key. Occasionally you might obtain the certificate physically, by meeting the certificate holder face-to-face and exchanging the certificate on some storage medium such as a USB stick, memory card, or portable disk. Or you might download a copy of the certificate from the holder?s web site. Once obtained in one of these ways, you can add the certificate to your collection of public keys by doing: gpg --import certificate.txt More commonly, you?ll download a correspondent?s certificate from a keyserver. [snip keyserver instructions] *Why do I need to validate certificates?* If you were to receive a letter in the mail that claimed to be from the President of the United States, would you believe it? Probably not, because anyone can put together official-looking letterhead: you?d insist on doing some kind of checking to make sure that no one was fooling with you. The same applies to email. A certificate can claim to be from anyone. You have to make sure that the certificate really belongs to whom it claims it belongs to. That process of making sure is called ?validation?. *How do I validate certificates?* This advice is controversial. It?s controversial for a simple reason: every Tom, Dick and Harry has their own idea about the ?right way? to validate certificates. Some of these people are well-informed and some of them are just plain unhinged. In the end, you are responsible for making your own decisions. That said, the following is generally agreed upon as being a reasonable procedure: 1. Meet the certificate holder face-to-face. 2. Ask to see two forms of government-issued identification. 3. Upon verifying the person really is who they claim to be, ask this person to provide their certificate?s fingerprint, their email address, and where you can obtain a copy of their certificate. (Example: ?My fingerprint is 4541 BB01 8EA4 8F99 19CA 3701 2380 6BE5 D6B9 8E10, and you can find it on pool.sks-keyservers.net.?) 4. On your own computer, retrieve the person?s certificate from the specified location. Check to make sure the email address they gave you is one that?s also listed on the certificate. Check to make sure the fingerprint of the certificate you?ve downloaded matches the fingerprint the person gave you. 5. gpg --edit-key [their certificate ID] sign 6. Once signed, gpg --armor --output signed_cert.asc --export [their certificate ID] 7. Send the file signed_cert.asc to the address they gave you By following this process you first ensure that you?re speaking to the right person. By comparing the fingerprints of the certificate you have against the fingerprint they specified, you?re ensuring that you have the right certificate. Checking to make sure the email address they gave you is also listed on the certificate is one more check to make sure. Once that?s done, presto, Bob?s your uncle: there?s nothing left to do except sign it and return the newly-signed certificate to the other person. ===== I mean, this seems like 95% of what you want. You just want the reference to an email address in step 4 removed? If you can get the community to agree, I'm all in favor. > - All gpg operations (key generation, encryption, decryption) are > carried out on a device not connected to the Internet. The FAQ covers both online and offline use. From sac at 300baud.de Sat May 23 21:03:34 2020 From: sac at 300baud.de (Stefan Claas) Date: Sat, 23 May 2020 21:03:34 +0200 Subject: "just invent something..." In-Reply-To: References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> Message-ID: <20200523210334.00002a78.sac@300baud.de> Robert J. Hansen wrote: > > - The trust in the correspondent's public key is established only > > by comparing the key fingerprint derived programmatically from the > > locally stored key-file and a copy independently obtained from > > the owner. The only identification of a public key is its > > fingerprint. Since the public key is either known to an adversary, > > or it is very hard to guard against such eventuality, the public > > key itself should not provide the adversary with any useful > > information. > > Okay, but this seems largely redundant with section 8.12 of the FAQ, > which, uh ... does exactly this. What exactly are you objecting to? [...] I think that many people have multiple email accounts and would like to see a way to have a procedure in place with GnuPG that would allow them to use such a public key, with only one UID (or none), covered in the FAQ. The problem is that we IMHO still stick to procedures Mr Zimmermann, while not being a cryptographer back then, has invented in the early 90s, which may no longer fit in 2020. It should be also pointed out, to the interested reader, that 99% of public key crypto software, I am aware of, does not require an email address, a UID, to manage public keys (in a key ring). Regards Stefan -- https://keybase.io/stefan_claas From angel at pgp.16bits.net Sun May 24 04:56:02 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 24 May 2020 04:56:02 +0200 Subject: "just invent something..." In-Reply-To: References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> Message-ID: <1590288962.1660.31.camel@16bits.net> On 2020-05-23 at 12:30 -0400, Robert J. Hansen wrote: > > - The trust in the correspondent's public key is established only > > by comparing the key fingerprint derived programmatically from the > > locally stored key-file and a copy independently obtained from > > the owner. The only identification of a public key is its fingerprint. > > Since the public key is either known to an adversary, or it is very > > hard to guard against such eventuality, the public key itself should > > not provide the adversary with any useful information. > > Okay, but this seems largely redundant with section 8.12 of the FAQ, Handy link to the FAQ: https://gnupg.org/faq/gnupg-faq.html#using_certificates I see a big hole in the validation part. The steps providex are validating the offline identity but not matching it to the certificate uid. > *How do I validate certificates?* > > This advice is controversial. > > It?s controversial for a simple reason: every Tom, Dick and Harry has > their own idea about the ?right way? to validate certificates. Some of > these people are well-informed and some of them are just plain unhinged. > In the end, you are responsible for making your own decisions. That > said, the following is generally agreed upon as being a reasonable > procedure: > > 1. Meet the certificate holder face-to-face. I meet Rob, face-to-face > 2. Ask to see two forms of government-issued identification. He shows me two ids that I consider acceptable > 3. Upon verifying the person really is who they claim to be, ask > this person to provide their certificate?s fingerprint, their email > address, and where you can obtain a copy of their certificate. He gives me his email address , its certificate fingerprint and place to download (WKD). > 4. On your own computer, retrieve the person?s certificate from the > specified location. Check to make sure the email address they gave you > is one that?s also listed on the certificate. Check to make sure the > fingerprint of the certificate you?ve downloaded matches the fingerprint > the person gave you. I download the certificate, I verify that it has the provided fingerprint and that the provided email address does appear on the certificate: ?Donald Trump ? > 5. gpg --edit-key [their certificate ID] sign > 6. Once signed, gpg --armor --output signed_cert.asc --export [their > certificate ID] > 7. Send the file signed_cert.asc to the address they gave you I sign the certificate, and send it to donaldtrump at sixdemonbag.org, so he can share my signature attesting his identity. > By following this process you first ensure that you?re speaking to the > right person. By comparing the fingerprints of the certificate you have > against the fingerprint they specified, you?re ensuring that you have > the right certificate. Checking to make sure the email address they gave > you is also listed on the certificate is one more check to make sure. > Once that?s done, presto, Bob?s your uncle: there?s nothing left to do > except sign it and return the newly-signed certificate to the other person. And yet, I find something unsettling about that key with a Donald Trump name just by meeting Rob Hansen face-to-face ;) I would _probably_ keep some records somewhere that I had signed that key based on meeting a certain Robert Hansen, but that actually means keeping your own out-of-keyring identity map. There might be an unwritten assumption that the name must match, too. But in that case it should be explicit It's also not clear what should be there. Consensus seem to be that there must be _some_ kind of loose matching. Maybe, but for Robert Hansen vouching for that certificate, the identity might be * Robert J. Hansen * Robert Hansen * Rob Hansen * Rob J. Hansen * rjh And he's far from being the only Robert Hansen, anyway: https://en.wikipedia.org/wiki/Robert_Hansen_(disambiguation) Nonetheless, a name of ?Donald Trump? should probably not be accepted, unless he is the name he goes by in certain circles. (In fact, on [some] common law jurisdictions, it is possible to change your name just by asking to be called that way) Another scenario would be an identity where only an email was provided, although in that case, it's not clear why you would want a government-issued identification. You only need an attestation that the key is owned by the mailbox owner. It is already quite long, but I think this part should be expanded to explain about how to treat the names in the certificates. I'd also clarify that 7 is optional, and you don't *need* to send your signature to the other party. This is actually much easily fixed. Best regards From rjh at sixdemonbag.org Sun May 24 06:14:20 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 24 May 2020 00:14:20 -0400 Subject: "just invent something..." In-Reply-To: <1590288962.1660.31.camel@16bits.net> References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> <1590288962.1660.31.camel@16bits.net> Message-ID: > I see a big hole in the validation part. The steps providex are > validating the offline identity but not matching it to the certificate > uid. Correct, and that's by design. There is no -- *NO* -- generally understood meaning for user IDs beyond "the name here is a meaningful term of address for an individual or individuals who control this email address". Many years ago I was in Germany and tried to persuade a friend of mine to do the hard right thing as opposed to the easy wrong thing. She rolled her eyes at me and declared "du bist Rob, der Ritter". ("You're Rob, the knight.") She was attempting to be sarcastic. Bystanders misheard her as "du bist ein Raubritter" and a new nickname for me was born.[1] So let's say I give you my ID and you're one of these people who knows me as Raubritter. Would you sign raubritter at sixdemonbag.org? Probably. Should you? Sure, why not? You know there's a specific person, me, who answers that email address and you know exactly who I am in the eyes of the law, thanks to seeing my ID. So why shouldn't you sign a pseudonym, if you know the pseudonym maps to an individual person? And if you're going to sign a pseudonym, why not sign donald_trump at sixdemonbag.org if you happen to know there's a person or persons at that domain which answer to that name? [1] This was thirty years ago. Words tend to change their cultural and slang meanings over the years. I don't know what the current implications of "Raubritter" are, and for that reason I don't use it or advertise it to others... but yeah, there are people who have known me for thirty years who still call me that. From azbigdogs at gmx.com Sun May 24 06:35:54 2020 From: azbigdogs at gmx.com (Mark) Date: Sat, 23 May 2020 21:35:54 -0700 Subject: Backup of Keys Message-ID: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> I'm sure this is a pretty stupid question but I'm trying to figure out which files I need to backup to safeguard my keys. All the docs I have seen so far are for the older versions of GNUPG before it changed the format of the keys.?? Anyway what files (and/or folders) should I be backing up to a secondary location. Thanks From dgouttegattat at incenp.org Sun May 24 14:52:21 2020 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 24 May 2020 13:52:21 +0100 Subject: Backup of Keys In-Reply-To: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> Message-ID: <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> On Sat, May 23, 2020 at 09:35:54PM -0700, Mark wrote: >I'm sure this is a pretty stupid question No, it?s not. >I'm trying to figure out which files I need to backup to safeguard my >keys. I?m assuming you are using GnuPG 2.2 on Windows here (based on your User-Agent). Everything that needs to be saved is in GnuPG?s home directory, which on Windows should be `C:\Documents and Settings\\Application Data\gnupg`. In that folder you should save: * the private keys (in the `private-keys-v1.d` subfolder; * the public keys (the `pubring.kbx` file); * the trust data (the `trustdb.gpg` file, plus the `tofu.db` file of you are using the TOFU trust model); * any configuration file (`*.conf`); * if you are using GpgSM, the `policies.txt` and `trustlist.txt` files. For the private and public keys however, instead of saving the files directly I?d recommend exporting them from GnuPG: % gpg -o private-keys.gpg --export-secret-keys % gpg -o public-keys.gpg --export The rationale for doing so is that the exported files are in the standard OpenPGP format, from which you can re-import them without worrying about changes from one GnuPG version to another. To restore: % gpg --import private-keys.gpg % gpg --import public-keys.gpg (You can also do that with a graphical interface, of course.) Of note, there is also a much simpler option which could replace everything above: use the Sherpa tool [1], which does exactly what you need. It backs up a complete GnuPG profile into an archive and later allows you to restore it. Do mind the warning about Sherpa not being ?ready for regular users?, though. For what it?s worth, I?ve used it a few times and never had any issues with it. Hope that helps, - Damien [1] https://github.com/rjhansen/sherpa -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From felix at crowfix.com Sun May 24 16:05:39 2020 From: felix at crowfix.com (Felix Finch) Date: Sun, 24 May 2020 07:05:39 -0700 Subject: Backup of Keys In-Reply-To: <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> Message-ID: <20200524140539.GC2584@crowfix.com> On 20200524, Damien Goutte-Gattat via Gnupg-users wrote: >On Sat, May 23, 2020 at 09:35:54PM -0700, Mark wrote: >>I'm trying to figure out which files I need to backup to safeguard >>my keys. > >Everything that needs to be saved is in GnuPG?s home directory, which >on Windows should be `C:\Documents and Settings\\Application >Data\gnupg`. In that folder you should save: > >* the private keys (in the `private-keys-v1.d` subfolder; >* the public keys (the `pubring.kbx` file); >* the trust data (the `trustdb.gpg` file, plus the `tofu.db` file of >you are using the TOFU trust model); >* any configuration file (`*.conf`); >* if you are using GpgSM, the `policies.txt` and `trustlist.txt` files. Out of curiosity ... how safe are these files as is, assuming the private key file has a good strong passphrase? If they are backed up on a USB stick which gets lost and found by someone else, or stolen, how much damage can be done? How hard is it to crack a good passphrase? I realize that's kind of a loose question, and "strong passphrase" doesn't help. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / felix at crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o From listofactor at mail.ru Sun May 24 17:26:11 2020 From: listofactor at mail.ru (LisToFacTor) Date: Sun, 24 May 2020 15:26:11 +0000 Subject: "just invent something..." In-Reply-To: References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> Message-ID: On 5/23/20 4:30 PM, Robert J. Hansen wrote: > > I mean, this seems like 95% of what you want. You just want the > reference to an email address in step 4 removed? > > If you can get the community to agree, I'm all in favor. > >> - All gpg operations (key generation, encryption, decryption) are >> carried out on a device not connected to the Internet. > > The FAQ covers both online and offline use. I maintain two short internal documents on "WOT-less" and "e-mail-less" off-line gpg use: one can be thought as "tutorial" the other as "reference". When I get some free time I'll merge them, remove group-specific stuff and post in a new thread. Would that be okay? Would that be worthwhile? From peter at digitalbrains.com Sun May 24 18:03:34 2020 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 24 May 2020 18:03:34 +0200 Subject: Backup of Keys In-Reply-To: <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> Message-ID: On 24/05/2020 14:52, Damien Goutte-Gattat via Gnupg-users wrote: > No, it?s not. Absolutely not ;-) > For the private and public keys however, instead of saving the files > directly I?d recommend exporting them from GnuPG: > > % gpg -o private-keys.gpg --export-secret-keys > % gpg -o public-keys.gpg --export Note, however, that the first of these two is interactive in that it asks for your passphrase(s). This is because it needs to be re-encrypted because the storage format is different. So you could do the first one manually every time you add (or remove) private keys or change a passphrase. Anything else, including changing key preferences, key expiry, etcetera, is equally reflected in public-keys.gpg from the second line. The second can be done regularly and automatically. Do back up other stuff from that directory as well. It's important, non-public data: your ownertrust declarations, TOFU bindings and history. You might want to omit the file random_seed. I forgot how important this is these days. I believe it has gotten less important at some time. But using Sherpa is probably a good bet. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sun May 24 18:16:39 2020 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 24 May 2020 18:16:39 +0200 Subject: Backup of Keys In-Reply-To: <20200524140539.GC2584@crowfix.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> Message-ID: Hi, On 24/05/2020 16:05, Felix Finch wrote: > Out of curiosity ... how safe are these files as is, assuming the > private key file has a good strong passphrase? The safety of the private key purely depends on the strength of the passphrase. Note that backups will have the passphrase that was set when the backup was _made_. Changing the passphrase on your computer will not change the passphrase in any older backups. But there is more data in your GnuPG homedir that is not encrypted but is privacy-sensitive. If you ever assign someone ownertrust, that will be reflected there. It indicates how much you trust people to correctly verify other people's identities and how well you trust them to keep their private key private. Your brother-in-law might be offended by you assigning him "NEVER TRUST", and your partner might not appreciate you apparently having somewhat recently assigned positive trust to that ex you swore you never saw anymore. And then there is the history data for TOFU, which exposes some data about when you verified signatures by other people or when you encrypted something to someone. This data is there to help you analyse trustworthiness about the third party in question when so prompted, but it is also communication metadata about you. These pieces of data might not exist for your particular configuration, but they can exist. > How hard is it to crack a good passphrase? I think the definition of a good passphrase is that it is infeasible to crack it. That makes it circular reasoning. A well-executed "Correct Horse Battery Staple" passphrase or a long enough diceware passphrase cannot be cracked. The problem is determining whether you did it right or are misunderstanding some vital detail of creating a good passphrase. For instance, actually choosing "Correct Horse Battery Staple" is about the worst thing you can do... :-) HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun May 24 18:18:51 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 24 May 2020 12:18:51 -0400 Subject: Backup of Keys In-Reply-To: References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> Message-ID: <9926d6b5-18a7-937d-6ed3-6168e18b866c@sixdemonbag.org> > But using Sherpa is probably a good bet. Good Lord, it's been a while since I wrote that. The Windows MSI installer should still work, though. If there's interest in other formats, I'll see about updating it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sun May 24 18:28:09 2020 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 24 May 2020 18:28:09 +0200 Subject: Backup of Keys In-Reply-To: References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> Message-ID: On 24/05/2020 18:03, Peter Lebbing wrote: >> % gpg -o public-keys.gpg --export Oh! That is perhaps not good enough :-). You need $ gpg --export-options export-local-sigs -o public-keys.gpg --export so you don't lose any non-exportable signatures. There's also --export-options backup, which implies export-local-sigs. I just tested that because I did not know. So I think for backup purposes this is the best: $ gpg --export-options backup -o public-keys.gpg --export Check the manual for more --export-options. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From azbigdogs at gmx.com Sun May 24 18:54:00 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 24 May 2020 09:54:00 -0700 Subject: Backup of Keys In-Reply-To: <9926d6b5-18a7-937d-6ed3-6168e18b866c@sixdemonbag.org> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <9926d6b5-18a7-937d-6ed3-6168e18b866c@sixdemonbag.org> Message-ID: <2410896e-75bb-5d59-9394-343f3ccff2fb@gmx.com> I have yet to try it but it sounds like a good idea. Does it run under Windows 10? On 5/24/2020 9:18 AM, Robert J. Hansen wrote: >> But using Sherpa is probably a good bet. > Good Lord, it's been a while since I wrote that. The Windows MSI > installer should still work, though. If there's interest in other > formats, I'll see about updating it. > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From azbigdogs at gmx.com Sun May 24 18:55:17 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 24 May 2020 09:55:17 -0700 Subject: Backup of Keys In-Reply-To: <20200524140539.GC2584@crowfix.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> Message-ID: <3e854e7f-4a4e-43ec-411b-42b3a0ce72d7@gmx.com> I think that could be addressed if all those files and directories are stored within an encrypted archive (whatever your favorite is) On 5/24/2020 7:05 AM, Felix Finch wrote: > On 20200524, Damien Goutte-Gattat via Gnupg-users wrote: >> On Sat, May 23, 2020 at 09:35:54PM -0700, Mark wrote: >>> I'm trying to figure out which files I need to backup to safeguard >>> my keys. >> >> Everything that needs to be saved is in GnuPG?s home directory, which >> on Windows should be `C:\Documents and >> Settings\\Application Data\gnupg`. In that folder you >> should save: >> >> * the private keys (in the `private-keys-v1.d` subfolder; >> * the public keys (the `pubring.kbx` file); >> * the trust data (the `trustdb.gpg` file, plus the `tofu.db` file of >> you are using the TOFU trust model); >> * any configuration file (`*.conf`); >> * if you are using GpgSM, the `policies.txt` and `trustlist.txt` files. > > Out of curiosity ... how safe are these files as is, assuming the > private key file has a good strong passphrase?? If they are backed up > on a USB stick which gets lost and found by someone else, or stolen, > how much damage can be done?? How hard is it to crack a good > passphrase?? I realize that's kind of a loose question, and "strong > passphrase" doesn't help. > From azbigdogs at gmx.com Sun May 24 19:02:23 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 24 May 2020 10:02:23 -0700 Subject: Backup of Keys In-Reply-To: <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> Message-ID: <3a01ff43-a131-f523-534b-53c8889a11fe@gmx.com> Thanks for all the tips on which files to backup and how to export to for use in other apps (which is another thing I want to do later). MANY years ago (mid 90s) I created some PGP keys with the old Norton PGP program I was beta testing... Unfortunately those private keys are long lost (several computers ago) and have no idea where any backups of them are. Learning from my mistake here so want to make sure I have backups of what I need. Yes I am using GnuPG 2.2 as part of GPG4Win and Enigmail. I will take a look at if I have all those files, some don't look familiar plus take a look at that Sherpa program On 5/24/2020 5:52 AM, Damien Goutte-Gattat wrote: > On Sat, May 23, 2020 at 09:35:54PM -0700, Mark wrote: >> I'm sure this is a pretty stupid question > > No, it?s not. > > >> I'm trying to figure out which files I need to backup to safeguard my >> keys. > > I?m assuming you are using GnuPG 2.2 on Windows here (based on your > User-Agent). > > Everything that needs to be saved is in GnuPG?s home directory, which > on Windows should be `C:\Documents and Settings\\Application > Data\gnupg`. In that folder you should save: > > * the private keys (in the `private-keys-v1.d` subfolder; > * the public keys (the `pubring.kbx` file); > * the trust data (the `trustdb.gpg` file, plus the `tofu.db` file of > you are using the TOFU trust model); > * any configuration file (`*.conf`); > * if you are using GpgSM, the `policies.txt` and `trustlist.txt` files. > > For the private and public keys however, instead of saving the files > directly I?d recommend exporting them from GnuPG: > > % gpg -o private-keys.gpg --export-secret-keys > % gpg -o public-keys.gpg? --export > > The rationale for doing so is that the exported files are in the > standard OpenPGP format, from which you can re-import them without > worrying about changes from one GnuPG version to another. To restore: > > % gpg --import private-keys.gpg > % gpg --import public-keys.gpg > > (You can also do that with a graphical interface, of course.) > > Of note, there is also a much simpler option which could replace > everything above: use the Sherpa tool [1], which does exactly what you > need. It backs up a complete GnuPG profile into an archive and later > allows you to restore it. Do mind the warning about Sherpa not being > ?ready for regular users?, though. For what it?s worth, I?ve used it a > few times and never had any issues with it. > > Hope that helps, > > - Damien > > > [1] https://github.com/rjhansen/sherpa From azbigdogs at gmx.com Sun May 24 19:11:29 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 24 May 2020 10:11:29 -0700 Subject: Backup of Keys In-Reply-To: References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> Message-ID: <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> Interesting points... I'm not sure I have all those files such as the TOFU (have to actually read more about it).? I think if all the important files are stored in an encrypted container, they should be pretty secure. On 5/24/2020 9:16 AM, Peter Lebbing wrote: > Hi, > > On 24/05/2020 16:05, Felix Finch wrote: >> Out of curiosity ... how safe are these files as is, assuming the >> private key file has a good strong passphrase? > The safety of the private key purely depends on the strength of the > passphrase. Note that backups will have the passphrase that was set when > the backup was _made_. Changing the passphrase on your computer will not > change the passphrase in any older backups. > > But there is more data in your GnuPG homedir that is not encrypted but > is privacy-sensitive. If you ever assign someone ownertrust, that will > be reflected there. It indicates how much you trust people to correctly > verify other people's identities and how well you trust them to keep > their private key private. Your brother-in-law might be offended by you > assigning him "NEVER TRUST", and your partner might not appreciate you > apparently having somewhat recently assigned positive trust to that ex > you swore you never saw anymore. > > And then there is the history data for TOFU, which exposes some data > about when you verified signatures by other people or when you encrypted > something to someone. This data is there to help you analyse > trustworthiness about the third party in question when so prompted, but > it is also communication metadata about you. > > These pieces of data might not exist for your particular configuration, > but they can exist. > >> How hard is it to crack a good passphrase? > I think the definition of a good passphrase is that it is infeasible to > crack it. That makes it circular reasoning. > > A well-executed "Correct Horse Battery Staple" passphrase or a long > enough diceware passphrase cannot be cracked. The problem is determining > whether you did it right or are misunderstanding some vital detail of > creating a good passphrase. > > For instance, actually choosing "Correct Horse Battery Staple" is about > the worst thing you can do... :-) > > HTH, > > Peter. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun May 24 19:11:28 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 24 May 2020 13:11:28 -0400 Subject: Backup of Keys In-Reply-To: <2410896e-75bb-5d59-9394-343f3ccff2fb@gmx.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <9926d6b5-18a7-937d-6ed3-6168e18b866c@sixdemonbag.org> <2410896e-75bb-5d59-9394-343f3ccff2fb@gmx.com> Message-ID: <57b98a60-a48c-f602-4f4f-327907372183@sixdemonbag.org> > I have yet to try it but it sounds like a good idea. Does it run under > Windows 10? Let's see what I wrote: >> The Windows MSI installer should still work, though. Knock yourself out. https://github.com/rjhansen/sherpa/releases/download/0.4.0/sherpa-0.4.0.msi From peter at digitalbrains.com Sun May 24 19:23:54 2020 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 24 May 2020 19:23:54 +0200 Subject: Backup of Keys In-Reply-To: <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> Message-ID: <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> On 24/05/2020 19:11, Mark wrote: > I think if all the important files are stored in an encrypted > container, they should be pretty secure. Just watch out for the catch-22 of "I lost my hard drive, let me restore from that encrypted container. Hmmm, my only backup of my private key is inside a container encrypted to that private key..." HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From felix at crowfix.com Sun May 24 19:38:25 2020 From: felix at crowfix.com (Felix Finch) Date: Sun, 24 May 2020 10:38:25 -0700 Subject: Backup of Keys In-Reply-To: References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> Message-ID: <20200524173825.GC22975@crowfix.com> On 20200524, Peter Lebbing wrote: >Hi, > >On 24/05/2020 16:05, Felix Finch wrote: >> Out of curiosity ... how safe are these files as is, assuming the >> private key file has a good strong passphrase? > >The safety of the private key purely depends on the strength of the >passphrase. Note that backups will have the passphrase that was set when >the backup was _made_. Changing the passphrase on your computer will not >change the passphrase in any older backups. > >But there is more data in your GnuPG homedir that is not encrypted but >is privacy-sensitive. If you ever assign someone ownertrust, that will >be reflected there. It indicates how much you trust people to correctly >verify other people's identities and how well you trust them to keep >their private key private. Your brother-in-law might be offended by you >assigning him "NEVER TRUST", and your partner might not appreciate you >apparently having somewhat recently assigned positive trust to that ex >you swore you never saw anymore. > >And then there is the history data for TOFU, which exposes some data >about when you verified signatures by other people or when you encrypted >something to someone. This data is there to help you analyse >trustworthiness about the third party in question when so prompted, but >it is also communication metadata about you. > >These pieces of data might not exist for your particular configuration, >but they can exist. > >> How hard is it to crack a good passphrase? > >I think the definition of a good passphrase is that it is infeasible to >crack it. That makes it circular reasoning. > >A well-executed "Correct Horse Battery Staple" passphrase or a long >enough diceware passphrase cannot be cracked. The problem is determining >whether you did it right or are misunderstanding some vital detail of >creating a good passphrase. > >For instance, actually choosing "Correct Horse Battery Staple" is about >the worst thing you can do... :-) Yes, it does. My passphrase is about ten words which only make sense to me, not even to people who know me, are not grammatically correct, etc. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / felix at crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o From felix at crowfix.com Sun May 24 19:44:02 2020 From: felix at crowfix.com (Felix Finch) Date: Sun, 24 May 2020 10:44:02 -0700 Subject: Backup of Keys In-Reply-To: <3e854e7f-4a4e-43ec-411b-42b3a0ce72d7@gmx.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <3e854e7f-4a4e-43ec-411b-42b3a0ce72d7@gmx.com> Message-ID: <20200524174402.GD22975@crowfix.com> On 20200524, Mark wrote: >I think that could be addressed if all those files and directories are >stored within an encrypted archive (whatever your favorite is) Yes, but then that needs a passphrase, and so on. I'm trying to cut back on how many I have to remember. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / felix at crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o From angel at pgp.16bits.net Sun May 24 20:15:44 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 24 May 2020 20:15:44 +0200 Subject: MacOSX help - beginner installation, first time In-Reply-To: References: Message-ID: <1590344144.1538.14.camel@16bits.net> On 2020-05-23 at 03:42 -0400, Cyrus Segura via Gnupg-users wrote: > Hi everyone, > > > I'm new to GnuPG. I'm trying to install it for MacOSX, and I have a > beginner's question. > > > ***Do I need to verify more information about the validity of GnuPG > if: > > > 1.) The SHA-256 checksum on my Mac's Terminal matches the one on > SourceForge where the Mac installer (.dmg) file is? > > > 2.) The Mac installer (.dmg) and the Mac signature for the installer > (.dmg.sig) are both verified on my Mac's separate program "GPG > Suite" (made by "https://gpgtools.org/")? > > > ***The files in question are "GnuPG-2.2.20.dmg", > "GnuPG-2.2.20.dmg.sig", and "Enigmail_public_key.asc". The link for > the Mac downloads is "https://sourceforge.net/p/gpgosx/docu/Download/" > > > Thank you very much for your time! > > Cyrus What's your threat model? What are the capabilities of an attacker? Are they able to modify the files you are being showed? (maybe by compromising the sourceforge page, or tampering with your connection) Let's suppose you verified the dmg file GnuPG-2.2.20.dmg has SHA-256 39970099819616d4b66a4e471ce26db97384948d0f375e02aae9d9de1d69baa5 You downloaded Enigmail_public_key.asc and checked it has fingerprint 4F9F 89F5 505A C1D1 A260 631C DB11 87B9 DD5F 693B You performed this checks with programs known to be honest (a hard-to-prove problem on its own, we probably take that as an axiom). The values above are those I am being shown there. If they match those you view, that suggest either: * your connection is not tampered with (you are shown the same as me) * those values are tampered on its source. It's hard that both your and my connection are tampered by the same actor, but perhaps they modified the web server. * I sent you the correct values I was seeing, but that malicious actor changed them before/after they arrived into your inbox. * I am part of the cabal that is trying to foil you into accepting those malicious files Even if those you got are the 'real' files, that only means those are the ones produced by Patrick Brunschwig. Do you trust him? Do you trust all the code he used to produce that package? Do you trust the build machine or his key wasn't compromised? Best regards From azbigdogs at gmx.com Sun May 24 21:36:16 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 24 May 2020 12:36:16 -0700 Subject: Backup of Keys In-Reply-To: <20200524174402.GD22975@crowfix.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <3e854e7f-4a4e-43ec-411b-42b3a0ce72d7@gmx.com> <20200524174402.GD22975@crowfix.com> Message-ID: <09c6b0a4-2a38-7282-b2fd-785cf590bef7@gmx.com> Good point, unless you can use some other passwordless authentication. On 5/24/2020 10:44 AM, Felix Finch wrote: > On 20200524, Mark wrote: >> I think that could be addressed if all those files and directories are >> stored within an encrypted archive (whatever your favorite is) > > Yes, but then that needs a passphrase, and so on.? I'm trying to cut > back on how many I have to remember. > From azbigdogs at gmx.com Sun May 24 21:39:10 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 24 May 2020 12:39:10 -0700 Subject: Backup of Keys In-Reply-To: <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> Message-ID: <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> I was thinking along the lines of backing up that entire directory into an encrypted 7z file and then just having to remember the password to that archive. I know there are other options maybe even some that use biometrics to decrypt the database. On 5/24/2020 10:23 AM, Peter Lebbing wrote: > On 24/05/2020 19:11, Mark wrote: >> I think if all the important files are stored in an encrypted >> container, they should be pretty secure. > Just watch out for the catch-22 of "I lost my hard drive, let me restore > from that encrypted container. Hmmm, my only backup of my private key is > inside a container encrypted to that private key..." > > HTH, > > Peter. > From rjh at sixdemonbag.org Sun May 24 21:57:17 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 24 May 2020 15:57:17 -0400 Subject: Backup of Keys In-Reply-To: <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> Message-ID: <74453cd3-7b92-d3c0-35a5-0bfc7b0456ef@sixdemonbag.org> > I was thinking along the lines of backing up that entire directory into > an encrypted 7z file and then just having to remember the password to > that archive. I know there are other options maybe even some that use > biometrics to decrypt the database. Don't. GnuPG puts things in that directory that are specific to your particular machine. Most of these are harmless (lockfiles, etc.) but some are potentially harmful to share between installations. For instance, there's one file, "random_seed". Werner says it's not a major concern, but I and many others have a flaming heebie-jeebies reaction to the idea of sharing a random number generator's seed file between two machines -- copying RNG state information is how *many, many, many* cryptosystems in history have been broken. Don't just back up the directory. Only copy the files that are strictly necessary for operation. Sherpa can help you with this. From azbigdogs at gmx.com Sun May 24 23:56:56 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 24 May 2020 14:56:56 -0700 Subject: Backup of Keys In-Reply-To: <74453cd3-7b92-d3c0-35a5-0bfc7b0456ef@sixdemonbag.org> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> <74453cd3-7b92-d3c0-35a5-0bfc7b0456ef@sixdemonbag.org> Message-ID: <98bd0ab5-47c5-2222-5b0b-fa40d23d0c97@gmx.com> Sorry misspoke.. I should've said put those files you listed in an encrypted archive. I will grab Sherpa later and see how it works. Thanks On 5/24/2020 12:57 PM, Robert J. Hansen wrote: >> I was thinking along the lines of backing up that entire directory into >> an encrypted 7z file and then just having to remember the password to >> that archive. I know there are other options maybe even some that use >> biometrics to decrypt the database. > Don't. GnuPG puts things in that directory that are specific to your > particular machine. Most of these are harmless (lockfiles, etc.) but > some are potentially harmful to share between installations. > > For instance, there's one file, "random_seed". Werner says it's not a > major concern, but I and many others have a flaming heebie-jeebies > reaction to the idea of sharing a random number generator's seed file > between two machines -- copying RNG state information is how *many, > many, many* cryptosystems in history have been broken. > > Don't just back up the directory. Only copy the files that are strictly > necessary for operation. Sherpa can help you with this. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From azbigdogs at gmx.com Mon May 25 00:56:42 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 24 May 2020 15:56:42 -0700 Subject: Backup of Keys In-Reply-To: <74453cd3-7b92-d3c0-35a5-0bfc7b0456ef@sixdemonbag.org> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> <74453cd3-7b92-d3c0-35a5-0bfc7b0456ef@sixdemonbag.org> Message-ID: <2ee77340-783e-895d-a9fa-3013f8ff0b2d@gmx.com> I forgot to mention there are 2 files in that gnupg directory that I'm not sure the purpose of. I know private keys are stored in a directory called private-keys-v1.d and public keys are stored in pubring.kbx. I do have a file called PAPubring.gpg and PAsecring.gpg. They are only 111 and 113 bytes each so can't be holding much of anything. Thanks On 5/24/2020 12:57 PM, Robert J. Hansen wrote: >> I was thinking along the lines of backing up that entire directory into >> an encrypted 7z file and then just having to remember the password to >> that archive. I know there are other options maybe even some that use >> biometrics to decrypt the database. > Don't. GnuPG puts things in that directory that are specific to your > particular machine. Most of these are harmless (lockfiles, etc.) but > some are potentially harmful to share between installations. > > For instance, there's one file, "random_seed". Werner says it's not a > major concern, but I and many others have a flaming heebie-jeebies > reaction to the idea of sharing a random number generator's seed file > between two machines -- copying RNG state information is how *many, > many, many* cryptosystems in history have been broken. > > Don't just back up the directory. Only copy the files that are strictly > necessary for operation. Sherpa can help you with this. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From angel at pgp.16bits.net Mon May 25 04:56:01 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 25 May 2020 04:56:01 +0200 Subject: "just invent something..." In-Reply-To: References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> <1590288962.1660.31.camel@16bits.net> Message-ID: <1590375361.1538.64.camel@16bits.net> On 2020-05-24 at 00:14 -0400, Robert J. Hansen wrote: > > I see a big hole in the validation part. The steps providex are > > validating the offline identity but not matching it to the certificate > > uid. > > Correct, and that's by design. > > There is no -- *NO* -- generally understood meaning for user IDs beyond > "the name here is a meaningful term of address for an individual or > individuals who control this email address". > > Many years ago I was in Germany and tried to persuade a friend of mine > to do the hard right thing as opposed to the easy wrong thing. She > rolled her eyes at me and declared "du bist Rob, der Ritter". ("You're > Rob, the knight.") She was attempting to be sarcastic. Bystanders > misheard her as "du bist ein Raubritter" and a new nickname for me was > born.[1] > > So let's say I give you my ID and you're one of these people who knows > me as Raubritter. Would you sign raubritter at sixdemonbag.org? Probably. > Should you? Sure, why not? You know there's a specific person, me, > who answers that email address and you know exactly who I am in the eyes > of the law, thanks to seeing my ID. > > So why shouldn't you sign a pseudonym, if you know the pseudonym maps to > an individual person? And if you're going to sign a pseudonym, why not > sign donald_trump at sixdemonbag.org if you happen to know there's a person > or persons at that domain which answer to that name? > > > > [1] This was thirty years ago. Words tend to change their cultural and > slang meanings over the years. I don't know what the current > implications of "Raubritter" are, and for that reason I don't use it or > advertise it to others... but yeah, there are people who have known me > for thirty years who still call me that. I tried to cover that with > unless it is the name he goes by in certain circles The point is, if I met you as Raubritter, a government-issued id showing a different name is unlikely to help. Similarly, I remember a blog post written by Skud during the Nym wars, where it was mentioned that being presented in conferences under the legal name ?Kirrily Robert? tended to cause confusion. [1] Of course, this leads to question if it would ever help to see such id. I do think it can be helpful. There are cases where the other party is known to use their legal name. Seeing an official id, and assuming it is a legit one (would you correctly detect a fake id? even from a foreign country?), doesn't stop that an impostor could appear with a valid id on that name (just like dealing with stripe doesn't mean it's the company you really mean to [2], or you could live on many Bostons), but it should restrict the odds somehow, by filtering the possibilities. Remember, if we know the legal name beforehand (e.g. when verifying a university email address, a tenured professor is unlikely _not_ to be using their legal name, although publishing means that naming in academia isn't straightforward either [3]) For online identities, a TOFU approach would probably work better. You would want to link the identity with its good or bad interactions to the cryptographic identity, regardless if who makes them is named Rob or Dogbert. For people you personally know -whatever the name-, you are probably comfortable signing whatever name they used on their key, that's likely how you know them and you may remember them. However, that doesn't help much if you wanted t benefit from the WoT, as the naming gets messy adding intermediate nodes between people. Also, there are too many meanings given to a key signature. I would like to have a standard set of notations with common meanings, so (in some subset) we could all agree on what was meant. Now, this is all quite complex to properly explain in a small FAQ entry, focused to new users, and still be understood, I'm afraid. Best regards PS: I am no German speaker, so I have no idea what Raubritters are. Or what would that term be used for 30 years ago, fwiw. 1- That site has fallen out of the internet and took a while to dig it out, but I finally found it at https://web.archive.org/web/20111115190646/http://infotrope.net/bio/my-name/ for the background on the why for that page see https://web.archive.org/web/20121213001724/http://infotrope.net/2011/07/22/ive-been-suspended-from-google-plus/ 2- https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/ 3- https://academia.stackexchange.com/questions/tagged/personal-name From azbigdogs at gmx.com Mon May 25 06:51:20 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 24 May 2020 21:51:20 -0700 Subject: Public Keyring Security Message-ID: <2f5ee05d-31ca-6f01-752d-5648df42448b@gmx.com> With the posts of backing up files and anonymous private keys it got me thinking. Is there a mechanism in place that protects (encrypts) a public keyring? They can be thought of as sort of an address book or contact list and with some mail providers encrypting contacts I wondered if such a thing existed with pgp keys?? Obviously I know you can install it an encrypted volume (depending on your OS) but was curious if the program or even the "pgp standard" took that into consideration or am I just too bored and that it's a stupid idea? From rjh at sixdemonbag.org Mon May 25 09:06:09 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 25 May 2020 03:06:09 -0400 Subject: Public Keyring Security In-Reply-To: <2f5ee05d-31ca-6f01-752d-5648df42448b@gmx.com> References: <2f5ee05d-31ca-6f01-752d-5648df42448b@gmx.com> Message-ID: <9048e2ef-e47e-a5fb-a4f1-c0020cfdacaf@sixdemonbag.org> > Obviously I know you can install it an encrypted volume (depending on > your OS) but was curious if the program or even the "pgp standard" took > that into consideration or am I just too bored and that it's a stupid idea? The OpenPGP standard dates back to the mid-1990s, when PGP 3 was first being considered. (It was never released: the next version of PGP was actually PGP 5.) Our understanding of the risks of metadata have evolved significantly since then: it's possible that if OpenPGP were being designed fresh today on a clean sheet of paper there would be some mechanism in place to obscure or conceal metadata. Which is, of course, another way of saying that at present OpenPGP is completely silent on this subject. If you want your public keyring to be a confidential secret, the way to do that is to store it on an encrypted file system. From rjh at sixdemonbag.org Mon May 25 09:13:28 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 25 May 2020 03:13:28 -0400 Subject: "just invent something..." In-Reply-To: <1590375361.1538.64.camel@16bits.net> References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> <1590288962.1660.31.camel@16bits.net> <1590375361.1538.64.camel@16bits.net> Message-ID: <06f993c2-eb5e-c929-92fc-ad5c3fc67888@sixdemonbag.org> > The point is, if I met you as Raubritter, a government-issued id showing > a different name is unlikely to help. I refer you back to the part of the FAQ which says the certificate signing process is controversial because every Tom, Dick, and Harry has their own idea on how to do it. If you can convince the list that the FAQ needs updating, I'll update it. But otherwise, I'm going to consider this yet another opinion on what the right thing to do is, and although I certainly think it's on topic for the list, I'm not going to consider changing the FAQ until and unless there's buy-in from others. :) > PS: I am no German speaker, so I have no idea what Raubritters are. Or > what would that term be used for 30 years ago, fwiw. Nabokov once said that translations were like women: the beautiful ones weren't faithful, and the faithful ones weren't beautiful. Literally, "raubritter" means "robber-knight" and historically refers to minor nobility in the medieval period who extorted money out of anyone they could. In English literature, these figures are normally called "black knights". Use whichever meaning you want. :) From rjh at sixdemonbag.org Mon May 25 09:17:02 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 25 May 2020 03:17:02 -0400 Subject: "just invent something..." In-Reply-To: References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> Message-ID: > Would that be okay? > > Would that be worthwhile? By all means, go for it! And if you can get the community to say "yeah, that's a good idea" I'll happily merge 'em in. I know I keep on saying "if the community wants it...". That's the hard and fast rule for the FAQ: it represents the consensus of the community. I'm the FAQ custodian more than I am the FAQ author. From peter at digitalbrains.com Mon May 25 09:36:17 2020 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 25 May 2020 09:36:17 +0200 Subject: Backup of Keys In-Reply-To: <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> Message-ID: <97481854-0403-5df5-204c-7699a1722ba2@digitalbrains.com> On 24/05/2020 21:39, Mark wrote: > I know there are other options maybe even some that use > biometrics to decrypt the database. I am very wary of biometrics for authentication purposes. There are so many examples where the vendor assured us it was working really well, and researchers easily cracked the system by using a photo, or photocopied fingerprints they lifted off a glass or even more funny from the fingerprint reader itself. That's for authentication, where only non-reproducability is vital. For encryption, it's much worse, because you need a lot of entropy for that to ward off offline attacks. And biometrics just doesn't have that much entropy. And both share that there is no recovery from compromise. If somebody learns your passphrase, you change it, tracking down all backups and changing them as well. That might be a little painful. If somebody manages to copy your biometrics, you can't change them. You could erase your fingerprints by taking a job processing pineapples on a daily basis. And you could get plastic surgery for your face, but that really puts the painful in "it's so painful to change your passphrase everywhere"... HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From mgorny at gentoo.org Mon May 25 09:47:14 2020 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Mon, 25 May 2020 09:47:14 +0200 Subject: Backup of Keys In-Reply-To: <97481854-0403-5df5-204c-7699a1722ba2@digitalbrains.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> <97481854-0403-5df5-204c-7699a1722ba2@digitalbrains.com> Message-ID: <9539de2fe29a4340de34a762b6db84ed6637df82.camel@gentoo.org> On Mon, 2020-05-25 at 09:36 +0200, Peter Lebbing wrote: > On 24/05/2020 21:39, Mark wrote: > > I know there are other options maybe even some that use > > biometrics to decrypt the database. > > I am very wary of biometrics for authentication purposes. There are so > many examples where the vendor assured us it was working really well, > and researchers easily cracked the system by using a photo, or > photocopied fingerprints they lifted off a glass or even more funny from > the fingerprint reader itself. ...and that's really a good thing they can do that instead of choosing a more painful way of getting your fingerprints. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From peter at digitalbrains.com Mon May 25 10:01:44 2020 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 25 May 2020 10:01:44 +0200 Subject: Biometrics In-Reply-To: <9539de2fe29a4340de34a762b6db84ed6637df82.camel@gentoo.org> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> <97481854-0403-5df5-204c-7699a1722ba2@digitalbrains.com> <9539de2fe29a4340de34a762b6db84ed6637df82.camel@gentoo.org> Message-ID: <479e27da-75cb-da50-5820-7ff72346c6c7@digitalbrains.com> On 25/05/2020 09:47, Micha? G?rny wrote: > ...and that's really a good thing they can do that instead of choosing > a more painful way of getting your fingerprints. How is that an advantage compared to passphrases? As soon as someone threatens to go all XKCD 538 on you[1], just give them your passphrase. No need to lend them your finger, either with or without you still attached. If this is your threat model, you need more than encryption or biometrics. ... unless your whole comment was as serious as my comment about plastic surgery of course :-) ... More seriously, biometrics might be a nice deterrant to the casual opportunistic curious peeker. It's quick, a finger swipe takes less time and effort than a good passphrase. But it's not proper security in my book. Peter. [1] https://xkcd.com/538/ -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From mgorny at gentoo.org Mon May 25 10:24:08 2020 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Mon, 25 May 2020 10:24:08 +0200 Subject: Biometrics In-Reply-To: <479e27da-75cb-da50-5820-7ff72346c6c7@digitalbrains.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> <97481854-0403-5df5-204c-7699a1722ba2@digitalbrains.com> <9539de2fe29a4340de34a762b6db84ed6637df82.camel@gentoo.org> <479e27da-75cb-da50-5820-7ff72346c6c7@digitalbrains.com> Message-ID: <1ff45b2e5417fc3374a33e5bd4d7ea7384277abe.camel@gentoo.org> On Mon, 2020-05-25 at 10:01 +0200, Peter Lebbing wrote: > On 25/05/2020 09:47, Micha? G?rny wrote: > > ...and that's really a good thing they can do that instead of choosing > > a more painful way of getting your fingerprints. > > How is that an advantage compared to passphrases? As soon as someone > threatens to go all XKCD 538 on you[1], just give them your passphrase. > No need to lend them your finger, either with or without you still > attached. > > If this is your threat model, you need more than encryption or > biometrics. > > ... unless your whole comment was as serious as my comment about plastic > surgery of course :-) ... It was. > More seriously, biometrics might be a nice deterrant to the casual > opportunistic curious peeker. It's quick, a finger swipe takes less time > and effort than a good passphrase. But it's not proper security in my > book. > I wholeheartedly agree with you. -- Best regards, Micha? G?rny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 618 bytes Desc: This is a digitally signed message part URL: From jscott at posteo.net Mon May 25 19:31:11 2020 From: jscott at posteo.net (John Scott) Date: Mon, 25 May 2020 13:31:11 -0400 Subject: Backup of Keys In-Reply-To: <9926d6b5-18a7-937d-6ed3-6168e18b866c@sixdemonbag.org> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <9926d6b5-18a7-937d-6ed3-6168e18b866c@sixdemonbag.org> Message-ID: <17676879.rTY5D8fIXH@t450> On Sunday, May 24, 2020 12:18:51 PM EDT Robert J. Hansen wrote: > > But using Sherpa is probably a good bet. > > Good Lord, it's been a while since I wrote that. The Windows MSI > installer should still work, though. If there's interest in other > formats, I'll see about updating it. Having only heard of it just now, I was surprised it's not included in Debian, until I saw the word of caution and lack of commit history. Whether in Sherpa or GnuPG directly I would be grateful for a more semantic way to make a backup. In fact I think this is a regular unmet need with software, especially to distinguish machine-specific configuration info from user preferences. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From sac at 300baud.de Mon May 25 20:21:06 2020 From: sac at 300baud.de (Stefan Claas) Date: Mon, 25 May 2020 20:21:06 +0200 Subject: Backup of Keys In-Reply-To: <17676879.rTY5D8fIXH@t450> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <9926d6b5-18a7-937d-6ed3-6168e18b866c@sixdemonbag.org> <17676879.rTY5D8fIXH@t450> Message-ID: <20200525202106.00006eb5.sac@300baud.de> John Scott via Gnupg-users wrote: > On Sunday, May 24, 2020 12:18:51 PM EDT Robert J. Hansen wrote: > > > But using Sherpa is probably a good bet. > > > > Good Lord, it's been a while since I wrote that. The Windows MSI > > installer should still work, though. If there's interest in other > > formats, I'll see about updating it. > > Having only heard of it just now, I was surprised it's not included > in Debian, until I saw the word of caution and lack of commit history. > > Whether in Sherpa or GnuPG directly I would be grateful for a more > semantic way to make a backup. In fact I think this is a regular > unmet need with software, especially to distinguish machine-specific > configuration info from user preferences. Maybe people should also consider to use a back-up on paper ... Regards Stefan -- https://keybase.io/stefan_claas From rjh at sixdemonbag.org Mon May 25 23:49:47 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 25 May 2020 17:49:47 -0400 Subject: Backup of Keys In-Reply-To: <17676879.rTY5D8fIXH@t450> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <9926d6b5-18a7-937d-6ed3-6168e18b866c@sixdemonbag.org> <17676879.rTY5D8fIXH@t450> Message-ID: <0f9e3ebc-db54-94ec-0de3-d0fa759bc415@sixdemonbag.org> > Having only heard of it just now, I was surprised it's not included in Debian, > until I saw the word of caution and lack of commit history. The word of caution is because I'm not actively maintaining it: the lack of commit history is because it's literally a project I threw together over a single long evening fueled by two beers and a Red Bull. The code isn't bad. However, in the four years since I wrote it QMake has changed its .pro files just barely enough that they need to be updated. If there's interest, I'll take a look at updating this for the most recent version of Qt. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From azbigdogs at gmx.com Mon May 25 23:56:27 2020 From: azbigdogs at gmx.com (Mark) Date: Mon, 25 May 2020 14:56:27 -0700 Subject: Backup of Keys In-Reply-To: <0f9e3ebc-db54-94ec-0de3-d0fa759bc415@sixdemonbag.org> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <9926d6b5-18a7-937d-6ed3-6168e18b866c@sixdemonbag.org> <17676879.rTY5D8fIXH@t450> <0f9e3ebc-db54-94ec-0de3-d0fa759bc415@sixdemonbag.org> Message-ID: I'd like to see it updated. I think it would be useful utility to have. On 5/25/2020 2:49 PM, Robert J. Hansen wrote: >> Having only heard of it just now, I was surprised it's not included in Debian, >> until I saw the word of caution and lack of commit history. > The word of caution is because I'm not actively maintaining it: the lack > of commit history is because it's literally a project I threw together > over a single long evening fueled by two beers and a Red Bull. > > The code isn't bad. However, in the four years since I wrote it QMake > has changed its .pro files just barely enough that they need to be updated. > > If there's interest, I'll take a look at updating this for the most > recent version of Qt. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From azbigdogs at gmx.com Tue May 26 00:14:25 2020 From: azbigdogs at gmx.com (Mark) Date: Mon, 25 May 2020 15:14:25 -0700 Subject: Backup of Keys In-Reply-To: <97481854-0403-5df5-204c-7699a1722ba2@digitalbrains.com> References: <07284d87-1bdb-f459-5e2e-1da92802ae46@gmx.com> <20200524125221.hjcy5aszmvi43mb6@dynein.local.incenp.org> <20200524140539.GC2584@crowfix.com> <40e7ee37-dabd-5183-eeeb-a5bd32227cdd@gmx.com> <82f2d573-575c-3e1b-58fc-b9819aeab537@digitalbrains.com> <0e490e1a-214a-110c-58db-7a0b09e501c4@gmx.com> <97481854-0403-5df5-204c-7699a1722ba2@digitalbrains.com> Message-ID: <406c9eac-e2f3-252f-36c0-9258e49db8f9@gmx.com> If someone does not want to remember a passphrase then it goes to something they have. Either some sort of key digital or "analog" or biometric.?? Granted changing that is more limited but some get creative, 10 fingers and 10 toes to choose from. I don't think there is any perfect system.? Passwords are easy to change but also easy to forget. Biometrics are hard to "lose" but also hard to change. On 5/25/2020 12:36 AM, Peter Lebbing wrote: > On 24/05/2020 21:39, Mark wrote: >> I know there are other options maybe even some that use >> biometrics to decrypt the database. > I am very wary of biometrics for authentication purposes. There are so > many examples where the vendor assured us it was working really well, > and researchers easily cracked the system by using a photo, or > photocopied fingerprints they lifted off a glass or even more funny from > the fingerprint reader itself. > > That's for authentication, where only non-reproducability is vital. For > encryption, it's much worse, because you need a lot of entropy for that > to ward off offline attacks. And biometrics just doesn't have that much > entropy. > > And both share that there is no recovery from compromise. If somebody > learns your passphrase, you change it, tracking down all backups and > changing them as well. That might be a little painful. > > If somebody manages to copy your biometrics, you can't change them. You > could erase your fingerprints by taking a job processing pineapples on a > daily basis. And you could get plastic surgery for your face, but that > really puts the painful in "it's so painful to change your passphrase > everywhere"... > > HTH, > > Peter. > From azbigdogs at gmx.com Tue May 26 00:23:25 2020 From: azbigdogs at gmx.com (Mark) Date: Mon, 25 May 2020 15:23:25 -0700 Subject: Public Keyring Security In-Reply-To: <9048e2ef-e47e-a5fb-a4f1-c0020cfdacaf@sixdemonbag.org> References: <2f5ee05d-31ca-6f01-752d-5648df42448b@gmx.com> <9048e2ef-e47e-a5fb-a4f1-c0020cfdacaf@sixdemonbag.org> Message-ID: That is what I had figured.? Like I said I was just bored and the though popped in my head if that was something ever discussed. On 5/25/2020 12:06 AM, Robert J. Hansen wrote: >> Obviously I know you can install it an encrypted volume (depending on >> your OS) but was curious if the program or even the "pgp standard" took >> that into consideration or am I just too bored and that it's a stupid idea? > The OpenPGP standard dates back to the mid-1990s, when PGP 3 was first > being considered. (It was never released: the next version of PGP was > actually PGP 5.) Our understanding of the risks of metadata have > evolved significantly since then: it's possible that if OpenPGP were > being designed fresh today on a clean sheet of paper there would be some > mechanism in place to obscure or conceal metadata. > > Which is, of course, another way of saying that at present OpenPGP is > completely silent on this subject. If you want your public keyring to > be a confidential secret, the way to do that is to store it on an > encrypted file system. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From azbigdogs at gmx.com Tue May 26 00:33:30 2020 From: azbigdogs at gmx.com (Mark) Date: Mon, 25 May 2020 15:33:30 -0700 Subject: Unknown Files Message-ID: <0bb414e7-52bb-b945-93b0-70524697c07e@gmx.com> There are 2 files in that gnupg directory that I'm not sure the purpose of. I know private keys are stored in a directory called private-keys-v1.d and public keys are stored in pubring.kbx. I have a file called PAPubring.gpg (111 bytes) and PAsecring.gpg (113 bytes) I'm guessing they are too small to be holding anything but just curious to what they are. Thanks From angel at pgp.16bits.net Tue May 26 01:54:02 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Tue, 26 May 2020 01:54:02 +0200 Subject: "just invent something..." In-Reply-To: <06f993c2-eb5e-c929-92fc-ad5c3fc67888@sixdemonbag.org> References: <1973874.izRjBTkQyM@breq> <2ad806e7-bf76-8b9c-80d3-b452094163d4@mail.ru> <7c0c9f23-c498-3cf7-cc1f-3ba2823b2c5f@sixdemonbag.org> <1590288962.1660.31.camel@16bits.net> <1590375361.1538.64.camel@16bits.net> <06f993c2-eb5e-c929-92fc-ad5c3fc67888@sixdemonbag.org> Message-ID: <1590450842.1077.15.camel@16bits.net> On 2020-05-25 at 03:13 -0400, Robert J. Hansen wrote: > If you can convince the list that the FAQ needs updating, I'll update > it. But otherwise, I'm going to consider this yet another opinion on > what the right thing to do is, and although I certainly think it's on > topic for the list, I'm not going to consider changing the FAQ until and > unless there's buy-in from others. :) I do think the FAQ could benefit from an update. However, I do not claim to know which would the right words to put there. There are some ideas on my previous mails. I hoped that could spark some discussion, but they are not near a proposal. That's a tougher task :) Maybe by giving it enough time I might come up with something to work with, far from perfect, but some draft to built upon. > Nabokov once said that translations were like women: the beautiful ones > weren't faithful, and the faithful ones weren't beautiful. > > Literally, "raubritter" means "robber-knight" and historically refers to > minor nobility in the medieval period who extorted money out of anyone > they could. In English literature, these figures are normally called > "black knights". Thanks for the insight! Best ?ngel From jcross at gmail.com Tue May 26 02:26:38 2020 From: jcross at gmail.com (Jonathan Cross) Date: Tue, 26 May 2020 02:26:38 +0200 Subject: MacOSX help - beginner installation, first time In-Reply-To: References: Message-ID: Hi Cyrus, 1. This is the SHA256 checksum I get for GnuPG-2.2.20.dmg: 39970099819616d4b66a4e471ce26db97384948d0f375e02aae9d9de1d69baa5 2. The signature (GnuPG-2.2.20.dmg.sig) checked out for me: gpg: Signature made Sat Mar 21 12:42:46 2020 CET gpg: using RSA key 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B gpg: Good signature from "Patrick Brunschwig " [full] gpg: aka "Patrick Brunschwig " [full] gpg: aka "[jpeg image of size 13251]" [full] Primary key fingerprint: 4F9F 89F5 505A C1D1 A260 631C DB11 87B9 DD5F 693B Furthermore... 1. I have met Patrick Brunschwig in person, checked his government ID. He also checked mine. 2. We both cross-signed each other's keys. 3. You can verify this by getting our pubkeys from pgpkeys.urown.net 4. You can check the OpenPGP signature on this email to verify my key is: 9386 A2FB 2DA9 D0D3 1FAF 0818 C0C0 7613 2FFA 7695 Now, of course you don't know me, but you now have a bit more info to go on. Maybe there's someone in this list below that you know / trust to check ID and / or verify key fingerprints? My key: https://pgpkeys.urown.net/pks/lookup?op=vindex&search=0xC0C076132FFA7695 Meeting people in person and verifying key fingerprints is of course best, but not always a realistic option for every piece of software :-) Good luck! Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From steffen at sdaoden.eu Tue May 26 15:35:48 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 26 May 2020 15:35:48 +0200 Subject: libgcrypt: random source via library on Linux? Message-ID: <20200526133548.V9X00%steffen@sdaoden.eu> Hello. This is maybe the wrong list, but only here i am subscribed and to me this is one project in the end, but i apologise for that. Yesterday i installed an OpenBSD 6.7 VM here, and was not able to start it with my default config (-device virtio-rng-pci) because libgcrypt failed with Fatal: no entropy gathering module detected (Was quite a journey to find the source of this message...) Long story short: i finally realized that if i run qemu without -chroot everything is fine even with virtio-rng, as a workaround i have created a minimal /dev/ in this chroot so libgcrypt can access ?random devices. But i wondered why the fd is not kept open, you see quite some server related problems if you search the above. But further more, is there usage of the system call or the C library backend on the road? Shall i even open a bug tracker thing? Thanks in advance, Ciao! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From wk at gnupg.org Tue May 26 22:09:23 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 May 2020 22:09:23 +0200 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <1888339675.20200522150827@mail.riseup.net> (MFPA via Gnupg-users's message of "Fri, 22 May 2020 15:08:27 +0100") References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> <1589682794.1744.76.camel@16bits.net> <875zct92gk.fsf@wheatstone.g10code.de> <1337448496.20200520180632@mail.riseup.net> <875zco4ai4.fsf@wheatstone.g10code.de> <1888339675.20200522150827@mail.riseup.net> Message-ID: <87imgi1mrw.fsf@wheatstone.g10code.de> On Fri, 22 May 2020 15:08, MFPA said: > How would it be used only with ECC keys? The MUA doesn't know the > flavour of key/subkey. For sure the MUA knows your own key. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From karel-v_g at tutanota.com Tue May 26 12:27:44 2020 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Tue, 26 May 2020 12:27:44 +0200 (CEST) Subject: Certified OpenPGP-encryption after release of Thunderbird 78 Message-ID: Hello! I am required to use certified encryption for mails by my supervising authorities and good practise. Because of this I have been using a combination of Thunderbird, Enigmail and Gpg4Win, as the latter one is certified by German BSI. With the approaching release of Thunderbird 78 Gpg4Win and Enigmail won't be available any longer and the new OpenPGP-implementation of Thunderbird won't be certified to the best of my knowledge. I am aware this might be slightly OT for this list, but are there any suggestions what can be done to keep up a certified encrypted mail communication? I am afraid Outlook which should work easily with Gpg4Win is not an option. Thanks for suggestions and help! Karel From sac at 300baud.de Tue May 26 23:34:28 2020 From: sac at 300baud.de (Stefan Claas) Date: Tue, 26 May 2020 23:34:28 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: Message-ID: <20200526233428.00002de1.sac@300baud.de> karel-v_g--- via Gnupg-users wrote: > Hello! > I am required to use certified encryption for mails by my supervising > authorities and good practise. Because of this I have been using a > combination of Thunderbird, Enigmail and Gpg4Win, as the latter one > is certified by German BSI. With the approaching release of > Thunderbird 78 Gpg4Win and Enigmail won't be available any longer and > the new OpenPGP-implementation of Thunderbird won't be certified to > the best of my knowledge. Hi, I would ask my supervising authorities if they can contact gnupg.com and see if GnuPG Desktop fits for your companies purposes. At least I strongly assume that they are aware of the Thunderbird situation and are able to offer custom solutions or proper advise. https://gnupg.com/gnupg-desktop.de.html Regards Stefan From abbot at monksofcool.net Wed May 27 01:15:38 2020 From: abbot at monksofcool.net (Ralph Seichter) Date: Wed, 27 May 2020 01:15:38 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: Message-ID: <87367mp9t1.fsf@wedjat.horus-it.com> * karel-v: > With the approaching release of Thunderbird 78 Gpg4Win and Enigmail > won't be available any longer and the new OpenPGP-implementation of > Thunderbird won't be certified to the best of my knowledge. I just checked the BSI's list of certified products[1]. Gpg4Win and Gpg4KDE are currently listed until 2022-06-30, and you can continue using them. Thunderbird and Enigmail are not included in that list, so you are apparently using your own software mix anyway. Enigmail will no longer be available for Thunderbird 78, but you can copy message bodies between Thunderbird and GPG using the clipboard. Of course, this is a major inconvenience, but currently it seems that it's either this method or sticking with the current Thunderbird version and Enigmail. -Ralph From abbot at monksofcool.net Wed May 27 01:22:15 2020 From: abbot at monksofcool.net (Ralph Seichter) Date: Wed, 27 May 2020 01:22:15 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <87367mp9t1.fsf@wedjat.horus-it.com> References: <87367mp9t1.fsf@wedjat.horus-it.com> Message-ID: <87ftbm46zc.fsf@wedjat.horus-it.com> > I just checked the BSI's list of certified products[1]. Sorry, I forgot to include the URL: [1] https://www.bsi.bund.de/DE/Themen/Sicherheitsberatung/ZugelasseneProdukte/Liste_Produkte/Liste_Produkte_node.html From karel-v_g at tutanota.com Wed May 27 12:48:09 2020 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Wed, 27 May 2020 12:48:09 +0200 (CEST) Subject: Certified OpenPGP-encryption after release of Thunderbird 78 Message-ID: Hello! >I just checked the BSI's list of certified products. Gpg4Win andGpg4KDE are currently listed until >2022-06-30, and you can continueusing them. Thunderbird and Enigmail are not included in that list,so >you are apparently using your own software mix anyway. Indeed, the only certified component of my mix is GPG4Win, while Enigmail and Thunderbird aren't. But I had checked that before I implemented that combination: the authorities said that only the part of the software that handles the encryption process needs to be certified while the used mail-client and plugins only need to meet general security requirements (TLS-Connections, latest patch-level, ...). Aside from advising to use BSI-certified products the authorities are not of any help unfortunately... So, to be a bit more precise: is there any mailclient working directly with GPG4win or other certified OpenPGP-solution aside from Outlook or copy and paste with Thunderbird 78ff? Thanks! Karel From sac at 300baud.de Wed May 27 23:41:29 2020 From: sac at 300baud.de (Stefan Claas) Date: Wed, 27 May 2020 23:41:29 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: Message-ID: <20200527234129.00006492.sac@300baud.de> karel-v_g--- via Gnupg-users wrote: > Hello! [...] > Aside from advising to use BSI-certified products the authorities are > not of any help unfortunately... In your previous post you spoke about *supervising* authorities. https://en.wikipedia.org/wiki/Supervisor Regards Stefan From me at halfdog.net Wed May 27 22:42:45 2020 From: me at halfdog.net (halfdog) Date: Wed, 27 May 2020 20:42:45 +0000 Subject: gpgsplit/pgpdump replacement Message-ID: <1693-1590612165.340197@3ITC.Y54c.x06N> Hello list, I just noticed that gpgv2 packaged for Debian does not include the "gpgsplit" and "pgpdump" tools any more. Is there any replacement available for them, e.g. by option to main "gpg" binary? hd From sac at 300baud.de Thu May 28 00:07:25 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 28 May 2020 00:07:25 +0200 Subject: gpgsplit/pgpdump replacement In-Reply-To: <1693-1590612165.340197@3ITC.Y54c.x06N> References: <1693-1590612165.340197@3ITC.Y54c.x06N> Message-ID: <20200528000725.000030ad.sac@300baud.de> halfdog wrote: > Hello list, > > I just noticed that gpgv2 packaged for Debian does not include > the "gpgsplit" and "pgpdump" tools any more. > > Is there any replacement available for them, e.g. by option to > main "gpg" binary? As an alternative you may check out the original pgpdump utility and sequoia pgp for splitting packets. http://www.mew.org/~kazu/proj/pgpdump/en/ https://docs.sequoia-pgp.org/sq/index.html Regards Stefan From me at halfdog.net Thu May 28 06:20:28 2020 From: me at halfdog.net (halfdog) Date: Thu, 28 May 2020 04:20:28 +0000 Subject: gpgsplit/pgpdump replacement In-Reply-To: <20200528000725.000030ad.sac@300baud.de> References: <1693-1590612165.340197@3ITC.Y54c.x06N> <20200528000725.000030ad.sac@300baud.de> Message-ID: <2597-1590639628.854864@hB4A.Txf1.Sxb0> Hello Stefan, Thanks for your helpful reply! Stefan Claas writes: > halfdog wrote: > >> Hello list, >> >> I just noticed that gpgv2 packaged for Debian does not include >> the "gpgsplit" and "pgpdump" tools any more. >> >> Is there any replacement available for them, e.g. by option >> to main "gpg" binary? > > As an alternative you may check out the original pgpdump utility > and sequoia pgp for splitting packets. > > http://www.mew.org/~kazu/proj/pgpdump/en/ Oh, interesting. This might have been an inconsistency in my standard procedures as "pgpdump" still seems to be available as a package on Debian Bullseye, but was not installed by the install automation system on the target device in question. I updated the configuration to have it installed during initial setup. > https://docs.sequoia-pgp.org/sq/index.html Oh, seems very nice, but Debian Bullseye is packaging only the verifier at the moment. Packaging is quite useful when wanting it preinstalled and updated automatically on multiple devices. Do you know if there are plans to get it into Debian Bullseye or at least run it via own deb repositories? As you seem to know about both gnupg and Sequoia, may I ask your opinion if it is possible to implement following use case with one of both? There are multiple devices in the field, which cannot efficiently be protected against physical access. These devices contain a number of quite large (MBs to GBs) encrypted files with historic data, which are usually not needed during normal operation. Therefore the decryption key is not available on the device. When something fails, this data might need to be reprocessed. Due to the expensive/slow mobile link it would be painful to transfer the encrypted file to the centralized server to decrypt them here and send back the decrypted data over the slow link. On the other side agent forwarding would keep your private key available to a low-security remote device for a long time until all the files are decrypted and does not give you any realistic control, what is done with your private key when operating on a larger batch of files (some thousand key operations which would be error prone/slow to review and acknowledge all one by one). The old procedure therefore was: 1) Use pgpsplit remotely to split the first KB of each encrypted file to get the encryption header packet. 2) Transfer all those packets over the slow link. 3) Perform some packet check with pgpdump and then extract the session keys from all those packets locally. 4) Send back a text file with all session keys. 5) Slowly decrypt/decompress/process all files remotely using the session keys. 6) Destroy the session keys on the remote tmpfs by overwriting the memory pages. As you can see the procedure did not require any additional software on local/remote while the functions were still available with gpg and allows you to make sure, that you only decrypted exactly the number of session keys you expected from the remote side. It prevented misuse of you key for signing. With remote device compromised it did not protect against decrypting other data from that device (e.g. historic files already deleted and being reinjected by an attacker) or files from another device sharing the same public key for encryption. Later could be easily prevented by using a per-device encryption key. As the two remote attack scenarios were deemed very unlikely and low-impact, there is no protection in place. @PGP-RFC-Devs: Could it be a nice feature for future of PGP (if cryptographically unproblematic) to have some kind of manipulation proof "tag" in the encrypted session-key packet, that can be set, e.g. via --tag-encrypted-data "mytag-$(echo "some-salt $(hostname -f)" | sha256)" to identify encrypted data source and avoid decrypting injected session key packets. Using a signing key per source seems to be impractical here too as it would also require to transfer the whole file beforehand for signature verification. hd From jscott at posteo.net Thu May 28 06:33:16 2020 From: jscott at posteo.net (John Scott) Date: Thu, 28 May 2020 00:33:16 -0400 Subject: Help setting gpgsm to do LDAP lookup In-Reply-To: <87y2pp7myk.fsf@wheatstone.g10code.de> References: <1981097.e7OUTunqB3@t450> <87y2pp7myk.fsf@wheatstone.g10code.de> Message-ID: <3566383.FlKYNf58MP@t450> On Monday, May 18, 2020 2:53:55 AM EDT Werner Koch wrote: > On Sat, 16 May 2020 23:24, John Scott said: >> Looking up recipients with both dirmngr-client and >> gpgsm --verbose --list-external-keys [recipient] >> are fruitless whether I drop the ads\ from my username or not. I've bumped >> the ldaptimeout to 25. Still both commands finish instantaneously > I just did a quick test using using > > ldap.pca.dfn.de::::o=DFN-Verein,c=DE:ldap > > which works as expected. It has no username and password, though. > To better debug this you should add > > --8<---------------cut here---------------start------------->8--- > verbose > log-file socket:// > debug ipc,lookup,extprog > no-use-tor > --8<---------------cut here---------------end--------------->8--- > [...] > Look at the log file while running these commands; hopefully you see an > error message. Thank you. The extra logging and options didn't reveal anything insightful to me (attached). I've also adjusted the credentials after getting help in my organization. I notice that if I use a non-SSL port like 389 or 3268?which I'm not sure they support the use of, I think they might require non-opportunistic TLS?I get an 'S PROGRESS TICK ? 0 0" message and Dirmngr takes its time before calling it quits. On the other hand using 636 or 3269 Dirmngr seems to not try and gets the log. The URI says only ldap://, can/could/should I specify TLS? -------------- next part -------------- 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: chan_6 <- lookup foobar 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: cmd_lookup: trying ads.foo.com:636 base=ou=Accounts,dc=ads,dc=foo,dc=com 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: ldap wrapper 348782 started (0x00007fae80005e10, /usr/lib/gnupg/dirmngr_ldap) 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: reader_callback: fp[0] stream=0x00007fae800024d0 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=2000) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae80005d90 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae80005d90 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348782]: processing url 'ldap:///ou%3DAccounts,dc%3Dads,dc%3Dfoo,dc%3Dcom?userCertificate,caCertificate,x509caCert?sub?(%7C(sn%3D*foobar*)(%7C(cn%3D*foobar*)(mail%3D*foobar*)))' 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348782]: user 'jscott at foo.com' 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=1996) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae80005d90 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae80005d90 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348782]: pass '*****' 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348782]: host 'ads.foo.com' 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348782]: port 636 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348782]: DN 'ou=Accounts,dc=ads,dc=foo,dc=com' 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=1996) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae80005d90 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae80005d90 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=1996) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae80005d90 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae80005d90 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=1940) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae80005d90 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: reader_callback: fp[0] stream=0x00007fae800024d0 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: releasing ldap worker c=0x00007fae800055f0 pid=348782/348782 rdr=0x00007fae80005e10 ctrl=0x00007fae80000ba0/1 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: cmd_lookup: no data 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: cmd_lookup: trying ads.foo.com:636 base=ou=Accounts,dc=ads,dc=foo,dc=com 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: ldap wrapper 348783 started (0x00007fae80006350, /usr/lib/gnupg/dirmngr_ldap) 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: reader_callback: fp[0] stream=0x00007fae800024d0 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae80005d90 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348782]: filter '(|(sn=*foobar 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: ldap wrapper 348782 ready: exitcode=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap worker stati: 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: c=0x00007fae80005e10 pid=348783/348783 rdr=0x00007fae80006350 logfp=0x00007fae800062d0 ctrl=0x00007fae80000ba0/1 la=1590627929 rdy=0 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: c=0x00007fae800055f0 pid=-1/348782 rdr=0x0000000000000000 logfp=0x0000000000000000 ctrl=0x0000000000000000/0 la=1590627929 rdy=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=1939) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348783]: processing url 'ldap:///ou%3DAccounts,dc%3Dads,dc%3Dfoo,dc%3Dcom?userCertificate,caCertificate,x509caCert?sub?(%7C(sn%3D*foobar*)(%7C(cn%3D*foobar*)(mail%3D*foobar*)))' 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348783]: user 'jscott at foo.com' 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=1935) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348783]: pass '*****' 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348783]: host 'ads.foo.com' 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348783]: port 636 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348783]: DN 'ou=Accounts,dc=ads,dc=foo,dc=com' 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=1935) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=1935) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=1889) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: next run (count=1 size=1, timeout=1889) 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 want=1 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: reader_callback: fp[0] stream=0x00007fae800024d0 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: releasing ldap worker c=0x00007fae80005e10 pid=348783/348783 rdr=0x00007fae80006350 ctrl=0x00007fae80000ba0/1 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: cmd_lookup: no data 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: command 'LOOKUP' failed: No data 4 - 2020-05-27 21:05:29 dirmngr[348691.6]: DBG: chan_6 -> ERR 167772218 No data 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap-reaper: fp[0] stream=0x00007fae800062d0 r=1 r------ 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: dirmngr_ldap[348783]: filter '(|(sn=*fooba 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: ldap wrapper 348783 ready: exitcode=1 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: ldap worker stati: 4 - 2020-05-27 21:05:29 dirmngr[348691.0]: DBG: c=0x00007fae80005e10 pid=-1/348783 rdr=0x0000000000000000 logfp=0x0000000000000000 ctrl=0x0000000000000000/0 la=1590627929 rdy=1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Thu May 28 10:26:48 2020 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 28 May 2020 10:26:48 +0200 Subject: gpgsplit/pgpdump replacement In-Reply-To: <2597-1590639628.854864@hB4A.Txf1.Sxb0> References: <1693-1590612165.340197@3ITC.Y54c.x06N> <20200528000725.000030ad.sac@300baud.de> <2597-1590639628.854864@hB4A.Txf1.Sxb0> Message-ID: <014891f0-bd4a-3c6c-0987-c42757a63a2b@digitalbrains.com> Hi, On 28/05/2020 06:20, halfdog wrote: > Using a signing key per source seems to be impractical here too as it > would also require to transfer the whole file beforehand for signature > verification. What about solving your entire use-case with an explicit two-step process: There's an encrypted, signed OpenPGP file with just a cryptographically secure random number. It is signed by a per-source signing key and encrypted to the secure machine. There's another file with symmetrically encrypted data using the tool of preference (could be GnuPG with --symmetric encryption) which actually contains the bulk of the data. The "passphrase" or encryption key is the cryptographically secure random number from the OpenPGP file. So every time you would now create a public-key encrypted file with the historic data, you explicitly generate a fresh "session key". You encrypt the data symmetrically with that key, and also public-key encrypt and sign that "session key". When you need to recover the historic data, the device sends only all the public-key encrypted "session keys" to the secure machine. That checks all these are signed by the device in the field, and if so, returns all "session keys". It's basically a duplication of the OpenPGP session key, and indeed, internally you are using a session key to encrypt a "session key". So it needs twice the randomness, which might be a problem on embedded systems. But it prevents needing packet surgery and inspection, instead just using default mechanisms. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Thu May 28 11:27:00 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 28 May 2020 11:27:00 +0200 Subject: gpgsplit/pgpdump replacement In-Reply-To: <2597-1590639628.854864@hB4A.Txf1.Sxb0> References: <1693-1590612165.340197@3ITC.Y54c.x06N> <20200528000725.000030ad.sac@300baud.de> <2597-1590639628.854864@hB4A.Txf1.Sxb0> Message-ID: <20200528112700.000047f0.sac@300baud.de> halfdog wrote: > Hello Stefan, > > Thanks for your helpful reply! Hi halfdog, you're welcome! [...] > As you seem to know about both gnupg and Sequoia, may I ask your > opinion if it is possible to implement following use case with > one of both? I only started to use sequoia pgp as a replacement for GnuPG recently, due to performance issues on my old offline Notebook and wanted to mention that the packet split functionality is there included too. [...] > The old procedure therefore was: > > 1) Use pgpsplit remotely to split the first KB of each encrypted > file to get the encryption header packet. > > 2) Transfer all those packets over the slow link. > > 3) Perform some packet check with pgpdump and then extract the > session keys from all those packets locally. > > 4) Send back a text file with all session keys. > > 5) Slowly decrypt/decompress/process all files remotely using > the session keys. > > 6) Destroy the session keys on the remote tmpfs by overwriting > the memory pages. I would say if you use sequoia pgp as a replacement for pgpsplit it should work the same. At least it's worth a try, in case you find no alternative and chances would be low that in the future such split functionality would not be included in future versions of GnuPG. Regards Stefan From wk at gnupg.org Thu May 28 13:08:10 2020 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 May 2020 13:08:10 +0200 Subject: libgcrypt: random source via library on Linux? In-Reply-To: <20200526133548.V9X00%steffen@sdaoden.eu> (Steffen Nurpmeso's message of "Tue, 26 May 2020 15:35:48 +0200") References: <20200526133548.V9X00%steffen@sdaoden.eu> Message-ID: <875zcgtizp.fsf@wheatstone.g10code.de> On Tue, 26 May 2020 15:35, Steffen Nurpmeso said: > Fatal: no entropy gathering module detected Which version of libgcrypt is that and what build options were used? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From steffen at sdaoden.eu Thu May 28 14:43:01 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 28 May 2020 14:43:01 +0200 Subject: libgcrypt: random source via library on Linux? In-Reply-To: <875zcgtizp.fsf@wheatstone.g10code.de> References: <20200526133548.V9X00%steffen@sdaoden.eu> <875zcgtizp.fsf@wheatstone.g10code.de> Message-ID: <20200528124301.mbcVa%steffen@sdaoden.eu> Hello! Werner Koch via Gnupg-users wrote in <875zcgtizp.fsf at wheatstone.g10code.de>: |On Tue, 26 May 2020 15:35, Steffen Nurpmeso said: |> Fatal: no entropy gathering module detected | |Which version of libgcrypt is that and what build options were used? Oh, sorry. That is on CRUX-Linux 3.5 #?0|kent:$ prt-get info libgcrypt Name: libgcrypt Path: /usr/ports/opt Version: 1.8.5 Release: 1 Description: A general purpose cryptographic library based on GnuPG URL: http://www.gnupg.org Maintainer: Thomas Penteker, tek at serverop dot de Dependencies: libgpg-error #?0|kent:$ cat /usr/ports/opt/libgcrypt/Pkgfile # Description: A general purpose cryptographic library based on GnuPG # URL: http://www.gnupg.org # Maintainer: Thomas Penteker, tek at serverop dot de # Depends on: libgpg-error name=libgcrypt version=1.8.5 release=1 source=(ftp://ftp.gnupg.org/gcrypt/libgcrypt/$name-$version.tar.bz2) build() { cd $name-$version ./configure \ --prefix=/usr \ --disable-padlock-support \ --enable-static=yes make make DESTDIR=$PKG install rm -r $PKG/usr/share/info } Our C library is #?0|kent:$ prt-get info glibc Name: glibc Path: /usr/ports/core Version: 2.28 Release: 2 Description: The C library used in the GNU system URL: http://www.gnu.org/software/libc/ Maintainer: CRUX System Team, core-ports at crux dot nu Files: post-install and it is configured in essence via --with-headers=$PKG/usr/include \ --enable-kernel=4.9 \ --enable-add-ons \ --enable-static-nss \ --enable-stack-protector=strong \ --enable-obsolete-rpc \ --enable-obsolete-nsl \ --disable-profile \ --disable-werror \ --without-gd \ --enable-multi-arch He is a busy Siemens security guy i think, but the ArchLinux libgcrypt comes on over with the same recipe? Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From karel-v_g at tutanota.com Thu May 28 16:10:31 2020 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Thu, 28 May 2020 16:10:31 +0200 (CEST) Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <20200527234129.00006492.sac@300baud.de> References: <20200527234129.00006492.sac@300baud.de> Message-ID: Hello! The German translation should be "Aufsichtsbeh?rde" (or even better "Rechtsf?hige Anstalt des ?ffentlichen Rechts"). In fact I don't know the exact translation and didn't find any appropriate in Google-Translate or deepl. So "supervising authorities" was my best guess without being a native speaker... Does this change the meaning or anything else? Karel 27. Mai 2020, 23:41 von sac at 300baud.de: > karel-v_g--- via Gnupg-users wrote: > > >> Hello! >> > > [...] > >> Aside from advising to use BSI-certified products the authorities are >> not of any help unfortunately... >> > > In your previous post you spoke about *supervising* authorities. > > https://en.wikipedia.org/wiki/Supervisor > > > Regards > Stefan > From sac at 300baud.de Thu May 28 23:21:12 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 28 May 2020 23:21:12 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> Message-ID: <20200528232112.00007649.sac@300baud.de> karel-v_g--- via Gnupg-users wrote: > Hello! > The German translation should be "Aufsichtsbeh?rde" (or even better > "Rechtsf?hige Anstalt des ?ffentlichen Rechts"). In fact I don't know > the exact translation and didn't find any appropriate in > Google-Translate or deepl. So "supervising authorities" was my best > guess without being a native speaker... Does this change the meaning > or anything else? Karel Hi, while it is not my business, I do not understand why you have to take care about the Thunderbird issue, as a users and not the Aufsichtsbeh?rde ... If for example you have a job at the Aufsichtsbeh?rde then ok, like I said, I would contact gnupg.com and ask them if GnuPG Desktop (A Windows app) fits for your working environment and in case not what they would suggest, because the Aufsichtsbeh?rde should have IMHO funds to issue a professional licensed working solution for their employees. In case you only have to deal as a gpg4win user with the Aufsichtsbeh?rde via email, then I don't understand how would they detect if you would not comply by using later the new Thunderbird, without BSI approval. P.S. please don't take it personal! Regards Stefan From me at halfdog.net Thu May 28 23:39:50 2020 From: me at halfdog.net (halfdog) Date: Thu, 28 May 2020 21:39:50 +0000 Subject: gpgsplit/pgpdump replacement In-Reply-To: <014891f0-bd4a-3c6c-0987-c42757a63a2b@digitalbrains.com> References: <1693-1590612165.340197@3ITC.Y54c.x06N> <20200528000725.000030ad.sac@300baud.de> <2597-1590639628.854864@hB4A.Txf1.Sxb0> <014891f0-bd4a-3c6c-0987-c42757a63a2b@digitalbrains.com> Message-ID: <2213-1590701990.744619@L7LC.CFRP.zz_I> Peter Lebbing writes: > On 28/05/2020 06:20, halfdog wrote: >> Using a signing key per source seems to be impractical here >> too as it would also require to transfer the whole file beforehand >> for signature verification. > > What about solving your entire use-case with an explicit two-step > process: > > There's an encrypted, signed OpenPGP file with just a > cryptographically secure random number. It is signed by a per-source > signing key and encrypted to the secure machine. > > There's another file with symmetrically encrypted data using > the tool of preference (could be GnuPG with --symmetric encryption) > which actually contains the bulk of the data. The "passphrase" > or encryption key is the cryptographically secure random number > from the OpenPGP file. > > So every time you would now create a public-key encrypted file > with the historic data, you explicitly generate a fresh "session > key". You encrypt the data symmetrically with that key, and > also public-key encrypt and sign that "session key". > > When you need to recover the historic data, the device sends > only all the public-key encrypted "session keys" to the secure > machine. That checks all these are signed by the device in > the field, and if so, returns all "session keys". > > It's basically a duplication of the OpenPGP session key, and > indeed, internally you are using a session key to encrypt a > "session key". So it needs twice the randomness, which might > be a problem on embedded systems. But it prevents needing packet > surgery and inspection, instead just using default mechanisms. > ... You are right. The reason for the gpgsplit/transfer/decrypt scheme was mainly because increase of data volume made the initial design with full data transfer problematic. I should have moved to intermediate key design back then already. I think I will change the encryption of new data according to your suggestings and keep some old gpgv1 instance while there is still some old data around using the old encryption scheme. It would be even possible to "upgrade" the old data by extracting the session keys and reencrypting them but I do not think this would be worth it. Thanks, hd PS: good point thinking about the randomness needed. That should be considered in general but in this specific use case (due to the IO activity for the data to be encrypted) the software RNG should gather sufficient entropy between invocations once per day. From dkg at fifthhorseman.net Thu May 28 21:35:49 2020 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 28 May 2020 15:35:49 -0400 Subject: gpgsplit/pgpdump replacement In-Reply-To: <1693-1590612165.340197@3ITC.Y54c.x06N> References: <1693-1590612165.340197@3ITC.Y54c.x06N> Message-ID: <87mu5rq2cq.fsf@fifthhorseman.net> On Wed 2020-05-27 20:42:45 +0000, halfdog wrote: > I just noticed that gpgv2 packaged for Debian does not include > the "gpgsplit" and "pgpdump" tools any more. pgpdump was never part of GnuPG, it ships in its own package. The gnupg-utils package contains /usr/bin/gpgsplit. For more detailed examination of OpenPGP-related objects, in addition to the other free software projects mentioned on this thread, you might also be interested in python3-pgpy (if you are comfortable with python). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lists at binarus.de Fri May 29 08:48:05 2020 From: lists at binarus.de (Binarus) Date: Fri, 29 May 2020 08:48:05 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <20200528232112.00007649.sac@300baud.de> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> Message-ID: <172840c2-e12a-55af-9ae1-fb368e19a5ac@binarus.de> On 28.05.2020 23:21, Stefan Claas wrote: > > while it is not my business, I do not understand why you have to take > care about the Thunderbird issue, as a users and not the > Aufsichtsbeh?rde ... If for example you have a job at the > Aufsichtsbeh?rde then ok, like I said, I would contact gnupg.com and > ask them if GnuPG Desktop (A Windows app) fits for your working > environment and in case not what they would suggest, because the > Aufsichtsbeh?rde should have IMHO funds to issue a professional > licensed working solution for their employees. > > In case you only have to deal as a gpg4win user with the > Aufsichtsbeh?rde via email, then I don't understand how would they > detect if you would not comply by using later the new Thunderbird, > without BSI approval. This is not my field, but I believe that (besides authorities) there are companies or other institutions which *must* use certified encryption solutions. Some ideas: - The OP might be employed at a city administration of a small village where the full set of regulations is relevant, but where there is no money (as in many small villages) to buy support. - The OP might be employed at a company like a hospital, a nuclear plant, a company which develops or sells military goods, a law office, a tax office, a (medical) insurance, a bank, and so on - you get the idea :-) While I actually don't know in detail which sort of company is bound by which regulation, I am sure that there are dozens of company types and hundreds, if not thousands of companies which are legally restricted to use only BSI-certified encryption software, especially companies which handle sensitive personal data or which compromise public safety if they let leak data. Even more, since the arrival of the GPDR, each company -even the smallest one- has to put significant effort into protecting personal data, and has to document in detail their respective policies and methods. When implementing the respective concepts and explaining / documenting why they are safe and how they protect personal data, it is of great help when the BSI has certified as many parts of the software as possible. Furthermore, to me, the OP sounds if he is not only employed at a company as a normal user, but as a part-time admin who has been asked to implement the email infrastructure for his colleagues besides his normal work (because the management as usual does not understand the importance and value of such work and the expertise and time which is needed). Regards, Binarus From wk at gnupg.org Fri May 29 12:22:58 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 May 2020 12:22:58 +0200 Subject: libgcrypt: random source via library on Linux? In-Reply-To: <20200528124301.mbcVa%steffen@sdaoden.eu> (Steffen Nurpmeso's message of "Thu, 28 May 2020 14:43:01 +0200") References: <20200526133548.V9X00%steffen@sdaoden.eu> <875zcgtizp.fsf@wheatstone.g10code.de> <20200528124301.mbcVa%steffen@sdaoden.eu> Message-ID: <87sgfjrqf1.fsf@wheatstone.g10code.de> On Thu, 28 May 2020 14:43, Steffen Nurpmeso said: > ./configure \ > --prefix=/usr \ > --disable-padlock-support \ > --enable-static=yes > make > make DESTDIR=$PKG install That is pretty standard except for the --disable-padlock-support - why do you use this? Padlock is only used on VIA CPUs and has an auditable design in contrast to RDRAND (which is used by Libgcrypt be default). Are you running in FIPS mode? Can you run the Libgcrypt test suite? In particular $ libgcrypt/tests/version $ libgcrypt/tests/random --verbose --debug Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Fri May 29 12:29:48 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 29 May 2020 12:29:48 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <172840c2-e12a-55af-9ae1-fb368e19a5ac@binarus.de> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <172840c2-e12a-55af-9ae1-fb368e19a5ac@binarus.de> Message-ID: <20200529122948.00006dc7.sac@300baud.de> Binarus wrote: > > > On 28.05.2020 23:21, Stefan Claas wrote: > > > > while it is not my business, I do not understand why you have to > > take care about the Thunderbird issue, as a users and not the > > Aufsichtsbeh?rde ... If for example you have a job at the > > Aufsichtsbeh?rde then ok, like I said, I would contact gnupg.com and > > ask them if GnuPG Desktop (A Windows app) fits for your working > > environment and in case not what they would suggest, because the > > Aufsichtsbeh?rde should have IMHO funds to issue a professional > > licensed working solution for their employees. > > > > In case you only have to deal as a gpg4win user with the > > Aufsichtsbeh?rde via email, then I don't understand how would they > > detect if you would not comply by using later the new Thunderbird, > > without BSI approval. > > This is not my field, but I believe that (besides authorities) there > are companies or other institutions which *must* use certified > encryption solutions. Some ideas: [...] Yes, understand. But then if those institutions have no funds or are not willing to invested in their IT security infrastructure then they may ask the BSI how to proceed. Maybe the BSI has funds to let gnupg.com develope a custom Windows solution for them. The other option would be that the OP and others continue using their current Thunderbird/Enigmail/gpg4win setup. Regards Stefan From wk at gnupg.org Fri May 29 12:36:42 2020 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 May 2020 12:36:42 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: (karel-v's message of "Tue, 26 May 2020 12:27:44 +0200 (CEST)") References: Message-ID: <87o8q7rps5.fsf@wheatstone.g10code.de> On Tue, 26 May 2020 12:27, karel-v_g--- said: > Because of this I have been using a combination of Thunderbird, > Enigmail and Gpg4Win, as the latter one is certified by German BSI. Well, it is not certified but approved to handle data at the EU RESTRICTED level (BSI-VSA-10400 and 10412). There a lot of side condition you have to meet to use that which are detailed in the SecOPs. TB has not been approved to handle restricted data because it does not clearly show whether important conditions are met. GpgOL and KMail are able to meet these requirements for email; Kleopatra for file encryption. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From vesely at tana.it Fri May 29 12:52:03 2020 From: vesely at tana.it (Alessandro Vesely) Date: Fri, 29 May 2020 12:52:03 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <20200529122948.00006dc7.sac@300baud.de> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <172840c2-e12a-55af-9ae1-fb368e19a5ac@binarus.de> <20200529122948.00006dc7.sac@300baud.de> Message-ID: On Fri 29/May/2020 12:29:48 +0200 Stefan Claas wrote: > Binarus wrote: >> On 28.05.2020 23:21, Stefan Claas wrote: >>> >>> while it is not my business, I do not understand why you have to >>> take care about the Thunderbird issue, as a users and not the >>> Aufsichtsbeh?rde ... If for example you have a job at the >>> Aufsichtsbeh?rde then ok, like I said, I would contact gnupg.com and >>> ask them if GnuPG Desktop (A Windows app) fits for your working >>> environment and in case not what they would suggest, because the >>> Aufsichtsbeh?rde should have IMHO funds to issue a professional >>> licensed working solution for their employees. >>> >>> In case you only have to deal as a gpg4win user with the >>> Aufsichtsbeh?rde via email, then I don't understand how would they >>> detect if you would not comply by using later the new Thunderbird, >>> without BSI approval. >> >> This is not my field, but I believe that (besides authorities) there >> are companies or other institutions which *must* use certified >> encryption solutions. Some ideas: > > [...] > > Yes, understand. But then if those institutions have no funds or > are not willing to invested in their IT security infrastructure > then they may ask the BSI how to proceed. Maybe the BSI has funds > to let gnupg.com develope a custom Windows solution for them. > > The other option would be that the OP and others continue using > their current Thunderbird/Enigmail/gpg4win setup. Any chance that the BSI will approve the RNP library that Thunderbird is going to use? Best Ale -- From accounts-gnupg at holbrook.no Fri May 29 14:55:19 2020 From: accounts-gnupg at holbrook.no (Louis Holbrook) Date: Fri, 29 May 2020 14:55:19 +0200 Subject: Signature mismatch for secp256k1 Message-ID: <20200529125519.GA25944@holbrook.no> I'm trying to use gpg-agent to sign for cryptocurrency purposes, using the secp256k1 curve. I've tried a few hashes, but one of them gets a different resulting signature than other implementations. I've compared against libsecp256k1 and nodejs elliptic library. I won't post the code here, but I also put up a question o stackexchange on the same topic which lists my attempt: https://unix.stackexchange.com/questions/589730/gnupg-secp256k1-signature-does-not-match-other-implementations Any pointers would be appreciated. I'm guessing it's some silly oversight of mine, but I can't spot it. Thanks. From listofactor at mail.ru Fri May 29 17:39:50 2020 From: listofactor at mail.ru (LisToFacTor) Date: Fri, 29 May 2020 15:39:50 +0000 Subject: gpgAnon, draft 20150 Message-ID: <081d4993-3e43-251a-494b-e840919ce909@mail.ru> The setup described in this "how-to" was originally put together and used (and possibly still is) quite a while ago, using Disastry's PGP 2.6.3ia-multi06 as the crypto back end. This guide has been composed from bits and pieces of the original user documentation, scissoring out the content that it refers to vaguely as "group policies". Other than that, the only substantial change is the replacement of pgp 2.6.3ia-multi06 with gpg 1.4.10 (or later). Technical testing of the described setup with the new crypto back end is underway. Any comments and criticism, of whatever kind, is welcome, if it implies the permission to incorporate it into the final version of the document. Available to first one hundred downloads at: https://send.firefox.com/download/d49d3f511202f943/#ITQHMkZexDePZ1JMwziuqg From steffen at sdaoden.eu Fri May 29 17:54:11 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 29 May 2020 17:54:11 +0200 Subject: libgcrypt: random source via library on Linux? In-Reply-To: <87sgfjrqf1.fsf@wheatstone.g10code.de> References: <20200526133548.V9X00%steffen@sdaoden.eu> <875zcgtizp.fsf@wheatstone.g10code.de> <20200528124301.mbcVa%steffen@sdaoden.eu> <87sgfjrqf1.fsf@wheatstone.g10code.de> Message-ID: <20200529155411.TgyU1%steffen@sdaoden.eu> Hello. Werner Koch wrote in <87sgfjrqf1.fsf at wheatstone.g10code.de>: |On Thu, 28 May 2020 14:43, Steffen Nurpmeso said: |> ./configure \ |> --prefix=/usr \ |> --disable-padlock-support \ |> --enable-static=yes |> make |> make DESTDIR=$PKG install | |That is pretty standard except for the --disable-padlock-support - why |do you use this? Padlock is only used on VIA CPUs and has an auditable |design in contrast to RDRAND (which is used by Libgcrypt be default). I am overasked why this is done. I have not looked for how RDRAND bugs are handled by libgcrypt either, Werner. Wait. Sigh. Looking at the source it seems libgcrypt knows about the Linux getrandom systemcall. Yet it does not seem to know about glibc's getrandom library function. Hm, so why does random/random-csprng.c:getfnc_gather_random() look out for NAME_OF_DEV_*RANDOM at all .. hmm .. i must admit random/rndlinux.c:_gcry_rndlinux_gather_random() seems strange to me. :) Two possible calls to getpid, could be "((apid = XPID) != my_pid || !add)"; ah i see the FDs could become cached (until fork), .. and then the getrandom syscall is tried even though FDs have been opened despite its presence. This, excuse me ;), i would change quite a bit. I would not do any FD related thing at all if getrandom is available, and i, for the MUA i maintain, simply look for getrandom, library or syscall (the latter came first; users can explicitly specify via VAL_RANDOM what they want, though). Looking at the development version now it finally seems to me that the library call is supported. I still would not do it like that, because if software cannot rely on what has been detected at configuration time all bets are off. I must admit i do the NOSYS check myself for this thing, but only for it, not for anything else. Also not for "system calls" which change behaviour dependent on library symbol version (realpath(2/3) comes to mind, exclusively). Anyhow, unless i am mistaken from this five minute looking, that random/random-csprng.c:getfnc_gather_random() #if USE_RNDLINUX if ( !access (NAME_OF_DEV_RANDOM, R_OK) && !access (NAME_OF_DEV_URANDOM, R_OK)) { fnc = _gcry_rndlinux_gather_random; return fnc; } #endif i would change, maybe with a new call-in to rndlinux.c which should be made responsible for Linux-only environmental detections imho. Like that it could solely depend on getrandom, and make all the FDs optional, maybe by testing for NOSYS with a one byte read or what at first, or by later aborting if collecting random fails if that is possible. (For my MUA i use this for seeding only anyhow.) |Are you running in FIPS mode? | |Can you run the Libgcrypt test suite? In particular | |$ libgcrypt/tests/version |$ libgcrypt/tests/random --verbose --debug Well i could. Is this still of interest? Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From sac at 300baud.de Fri May 29 18:51:00 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 29 May 2020 18:51:00 +0200 Subject: gpgAnon, draft 20150 In-Reply-To: <081d4993-3e43-251a-494b-e840919ce909@mail.ru> References: <081d4993-3e43-251a-494b-e840919ce909@mail.ru> Message-ID: <20200529185100.00007cef.sac@300baud.de> LisToFacTor via Gnupg-users wrote: > The setup described in this "how-to" was originally put together > and used (and possibly still is) quite a while ago, using > Disastry's PGP 2.6.3ia-multi06 as the crypto back end. > > This guide has been composed from bits and pieces of the original > user documentation, scissoring out the content that it refers to > vaguely as "group policies". Other than that, the only substantial > change is the replacement of pgp 2.6.3ia-multi06 with gpg 1.4.10 > (or later). > > Technical testing of the described setup with the new crypto back > end is underway. > > Any comments and criticism, of whatever kind, is welcome, if it > implies the permission to incorporate it into the final version > of the document. > > Available to first one hundred downloads at: > https://send.firefox.com/download/d49d3f511202f943/#ITQHMkZexDePZ1JMwziuqg Hi, how does Alice protects her Live-CD and USB stick, when she leaves home and Mallory gains access to them, so that for example the Live-CD can be exchanged? Does Alice use the USB-stick also with other mediums and if so how does she detect bad USB? Regards Stefan -- my 'hidden' service gopherhole: gopher://iria2xobffovwr6h.onion From listofactor at mail.ru Fri May 29 20:12:47 2020 From: listofactor at mail.ru (LisToFacTor) Date: Fri, 29 May 2020 18:12:47 +0000 Subject: gpgAnon, draft 20150 In-Reply-To: <20200529185100.00007cef.sac@300baud.de> References: <081d4993-3e43-251a-494b-e840919ce909@mail.ru> <20200529185100.00007cef.sac@300baud.de> Message-ID: On 5/29/20 4:51 PM, Stefan Claas - sac at 300baud.de wrote: > how does Alice protects her Live-CD and USB stick, when she leaves home > and Mallory gains access to them, so that for example the Live-CD can > be exchanged? Live-CD is a "public resource", available from multiple locations on the 'net and off, simply discarded when not practical to protect. Anybody can download, burn and give her a copy. On first use, checked with: sudo cat /dev/cdrom | shasum - While noting on the CD is a secret, it is quite unlikely an adversary can modify it without being detected. > Does Alice use the USB-stick also with other mediums and if so how does > she detect bad USB? USB hygiene is always a problem. Small devices and frequent hardware cycling on the trusted device with two USB ports is helpful: dd if=/dev/sdb of=/dev/sdc bs=10M (with subsequent cat ... | shasum - thrown in for good measure) From sac at 300baud.de Fri May 29 21:09:10 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 29 May 2020 21:09:10 +0200 Subject: gpgAnon, draft 20150 In-Reply-To: References: <081d4993-3e43-251a-494b-e840919ce909@mail.ru> <20200529185100.00007cef.sac@300baud.de> Message-ID: <20200529210910.00001e14.sac@300baud.de> LisToFacTor via Gnupg-users wrote: > On 5/29/20 4:51 PM, Stefan Claas - sac at 300baud.de wrote: > > how does Alice protects her Live-CD and USB stick, when she leaves > > home and Mallory gains access to them, so that for example the > > Live-CD can be exchanged? > Live-CD is a "public resource", available from multiple locations on > the 'net and off, simply discarded when not practical to protect. > Anybody can download, burn and give her a copy. On first use, checked > with: > > sudo cat /dev/cdrom | shasum - > > While noting on the CD is a secret, it is quite unlikely an adversary > can modify it without being detected. > > > Does Alice use the USB-stick also with other mediums and if so how > > does she detect bad USB? > USB hygiene is always a problem. Small devices and frequent hardware > cycling on the trusted device with two USB ports is helpful: > dd if=/dev/sdb of=/dev/sdc bs=10M > (with subsequent cat ... | shasum - thrown in for good measure) Maybe you could add these two tips to the document, because Alice might not know. BTW. A while ago my Linux online Notebook was hacked and now I use also a (Windows) offline Notebook for encryption and I have also purchased a Kanguru Defender 3000 USB stick, wich allows to use a virtual keyboard (under Windows) to type in the passphrase for the encrypted USB stick and it has also a write-protect switch, when using on an online computer. And it is bad USB safe. Maybe interesting for someone?! Regards Stefan -- my 'hidden' service gopherhole: gopher://iria2xobffovwr6h.onion From karel-v_g at tutanota.com Fri May 29 14:43:28 2020 From: karel-v_g at tutanota.com (karel-v_g at tutanota.com) Date: Fri, 29 May 2020 14:43:28 +0200 (CEST) Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <20200528232112.00007649.sac@300baud.de> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> Message-ID: Hello! No, I don't work for an Aufsichtsbeh?rde and (fortunately) I don't have to deal with them directly most time. But the Aufsichtsbeh?rde defines how my work has to be done and they have the right to inspect it. And one of the things they require is use recommended (e.g. BSI) software for mailencryption. Of course there is no way knowing for them whether I comply or not without intercepting my mail or visiting my office. But as always it might cause problems when not complying. So I think I will continue use Thunderbird as MTA and use GPG4Win with copy and paste for the encryption part. But it's a pity that Thunderbird developed its own solution because of licensing issues while we have a proven working solution with GnuPG... But why should I take the discussion personal?? :-) Karel 28. Mai 2020, 23:21 von sac at 300baud.de: > karel-v_g--- via Gnupg-users wrote: > > >> Hello! >> The German translation should be "Aufsichtsbeh?rde" (or even better >> "Rechtsf?hige Anstalt des ?ffentlichen Rechts"). In fact I don't know >> the exact translation and didn't find any appropriate in >> Google-Translate or deepl. So "supervising authorities" was my best >> guess without being a native speaker... Does this change the meaning >> or anything else? Karel >> > > Hi, > > while it is not my business, I do not understand why you have to take > care about the Thunderbird issue, as a users and not the > Aufsichtsbeh?rde ... If for example you have a job at the > Aufsichtsbeh?rde then ok, like I said, I would contact gnupg.com and > ask them if GnuPG Desktop (A Windows app) fits for your working > environment and in case not what they would suggest, because the > Aufsichtsbeh?rde should have IMHO funds to issue a professional > licensed working solution for their employees. > > In case you only have to deal as a gpg4win user with the > Aufsichtsbeh?rde via email, then I don't understand how would they > detect if you would not comply by using later the new Thunderbird, > without BSI approval. > > P.S. please don't take it personal! > > Regards > Stefan > From sac at 300baud.de Fri May 29 21:57:36 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 29 May 2020 21:57:36 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> Message-ID: <20200529215736.00007768.sac@300baud.de> karel-v_g--- via Gnupg-users wrote: Hi, > But it's a pity that > Thunderbird developed its own solution because of licensing issues > while we have a proven working solution with GnuPG... We never know, maybe in the future someone writes again a fully working solution for Thunderbird/GnuPG users. > But why should > I take the discussion personal?? :-) Karel Well, because sometimes people may not like what I write. :-) Regards Stefan -- my 'hidden' service gopherhole: gopher://iria2xobffovwr6h.onion From steffen at sdaoden.eu Fri May 29 22:21:34 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 29 May 2020 22:21:34 +0200 Subject: libgcrypt: random source via library on Linux? In-Reply-To: <20200529155411.TgyU1%steffen@sdaoden.eu> References: <20200526133548.V9X00%steffen@sdaoden.eu> <875zcgtizp.fsf@wheatstone.g10code.de> <20200528124301.mbcVa%steffen@sdaoden.eu> <87sgfjrqf1.fsf@wheatstone.g10code.de> <20200529155411.TgyU1%steffen@sdaoden.eu> Message-ID: <20200529202134.6LZBJ%steffen@sdaoden.eu> Hello Werner, all. Steffen Nurpmeso wrote in <20200529155411.TgyU1%steffen at sdaoden.eu>: |Werner Koch wrote in |<87sgfjrqf1.fsf at wheatstone.g10code.de>: ||On Thu, 28 May 2020 14:43, Steffen Nurpmeso said: ... |out for NAME_OF_DEV_*RANDOM at all .. hmm .. i must admit |random/rndlinux.c:_gcry_rndlinux_gather_random() seems strange to |me. :) Two possible calls to getpid, could be "((apid = XPID) != ... |I still would not do it like that, because if software cannot rely ... |Anyhow, unless i am mistaken from this five minute looking, that |random/random-csprng.c:getfnc_gather_random() | | #if USE_RNDLINUX | if ( !access (NAME_OF_DEV_RANDOM, R_OK) | && !access (NAME_OF_DEV_URANDOM, R_OK)) | { | fnc = _gcry_rndlinux_gather_random; | return fnc; |} | #endif | |i would change, maybe with a new call-in to rndlinux.c which |should be made responsible for Linux-only environmental detections |imho. Like that it could solely depend on getrandom, and make all |the FDs optional, maybe by testing for NOSYS with a one byte read |or what at first, or by later aborting if collecting random fails |if that is possible. (For my MUA i use this for seeding only |anyhow.) | ||Are you running in FIPS mode? || ||Can you run the Libgcrypt test suite? In particular || ||$ libgcrypt/tests/version ||$ libgcrypt/tests/random --verbose --debug So with the attached patch libgcrypt solely relies upon getentropy if available, no FD handling is done no more if at all possible. The test suite passes, a short review makes me think it is alright. - The setup could block when the OS cannot serve 1 byte of strong entropy. This is different to before, access(2) does not. (On the other hand neither on OpenBSD nor on newer Linux (5.4 or 5.6 i think) this should matter. And it is likely it does not elsewhere, either people seem to have used things like my entropy-saver or even hammers like haveged which reveal how strange entropy counting was, imho.) - Some tests aka code places directly reach into _gcry_rndlinux_gather_random() and thus only give errors in open_device() not the warning that initiated this ML thread. This i did not get at first, the tests suite passed nonetheless. - P.S.: even if this patch is not used, i would suggest an audit of this file. - RANDOM_CONF_ONLY_URANDOM lost its meaning in the past, and this patch does not reinstantiate that. It cannot be done portably, except for OSs which provide getrandom(2). - I shortly thought about using "extern", but i think doing so in an isolated fashion is surely wrong. Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -------------- next part -------------- A non-text attachment was scrubbed... Name: gcrypt-linux.diff Type: text/x-diff Size: 11006 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri May 29 22:32:34 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 29 May 2020 16:32:34 -0400 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <20200529215736.00007768.sac@300baud.de> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> Message-ID: >> But it's a pity that >> Thunderbird developed its own solution because of licensing issues >> while we have a proven working solution with GnuPG... > > We never know, maybe in the future someone writes again a fully working > solution for Thunderbird/GnuPG users. Over the last fifteen years of providing email support to Enigmail users, I can say 95% of the Enigmail problems were caused by needing to call out to GnuPG. The pipeline was (still is) fragile and the source of many errors. Distributing GnuPG separately from Enigmail was also a headache and a half. You may think Enigmail is a proven working solution because it works for you and the people you know. I'm very happy it works so well for you! But from my perspective, with literally almost two thousand emails over the last fifteen years from people asking for help, I'm reluctant to call it that. It works well for many people and I'm really glad it exists. But there's still an unfortunate amount of work involved in getting it set up and working. From sac at 300baud.de Fri May 29 23:12:24 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 29 May 2020 23:12:24 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> Message-ID: <20200529231224.0000775a.sac@300baud.de> Robert J. Hansen wrote: > >> But it's a pity that > >> Thunderbird developed its own solution because of licensing issues > >> while we have a proven working solution with GnuPG... > > > > We never know, maybe in the future someone writes again a fully > > working solution for Thunderbird/GnuPG users. > > Over the last fifteen years of providing email support to Enigmail > users, I can say 95% of the Enigmail problems were caused by needing > to call out to GnuPG. The pipeline was (still is) fragile and the > source of many errors. Distributing GnuPG separately from Enigmail > was also a headache and a half. > > You may think Enigmail is a proven working solution because it works > for you and the people you know. I'm very happy it works so well for > you! But from my perspective, with literally almost two thousand > emails over the last fifteen years from people asking for help, I'm > reluctant to call it that. > > It works well for many people and I'm really glad it exists. But > there's still an unfortunate amount of work involved in getting it set > up and working. I can only say from my side, when using Enigmail many moons ago, with a Mac, it was ok. Since you mention that you did support for Enigmail, do you have also infos about the current status of Thunderbird development, i.e. beta testing etc., regarding OpenPGP support, so that you may can tell us what people can expect? Regards Stefan -- my 'hidden' service gopherhole: gopher://iria2xobffovwr6h.onion From rjh at sixdemonbag.org Fri May 29 23:34:52 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 29 May 2020 17:34:52 -0400 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <20200529231224.0000775a.sac@300baud.de> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> Message-ID: <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> > Since you mention that you did support for Enigmail, do you have also > infos about the current status of Thunderbird development, i.e. > beta testing etc., regarding OpenPGP support, so that you may can tell > us what people can expect? Enigmail development has ended. The upcoming 2.2 is the final release and introduces no new features. It exists only to help people migrate to TB78's OpenPGP support. TB68 is being EOLed this fall. We've promised to continue to support users for six months after that, including giving emergency security fixes to Enigmail if they become necessary: but at six months and one day we're going to mop the floor, tally up the cash register, shut off the lights, and lock up as we leave. (The only exception is a commercial email company that has a signed support contract with Patrick -- their contract will be fulfilled.) From azbigdogs at gmx.com Fri May 29 23:35:13 2020 From: azbigdogs at gmx.com (Mark) Date: Fri, 29 May 2020 14:35:13 -0700 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> Message-ID: <2f0a4bf4-8786-e41a-af3d-e42e63ec038f@gmx.com> One of the potential problems I can see is multiple key rings. which I have just recently discovered in my own setup. I have the "standard" key rings that GPG4Win/Enigmail use and then I discovered 2 unknown files in my gnupg directory. PAPubring.gpg and PAsecring.gpg. I eventually deduced they came from an archiving program I use that has PGP built in called Power Archiver.? Granted I am a newbie with PGP but the thought of having to make sure multiple key rings are all synced sounds like a hassle. On 5/29/2020 1:32 PM, Robert J. Hansen wrote: >>> But it's a pity that >>> Thunderbird developed its own solution because of licensing issues >>> while we have a proven working solution with GnuPG... >> We never know, maybe in the future someone writes again a fully working >> solution for Thunderbird/GnuPG users. > Over the last fifteen years of providing email support to Enigmail > users, I can say 95% of the Enigmail problems were caused by needing to > call out to GnuPG. The pipeline was (still is) fragile and the source > of many errors. Distributing GnuPG separately from Enigmail was also a > headache and a half. > > You may think Enigmail is a proven working solution because it works for > you and the people you know. I'm very happy it works so well for you! > But from my perspective, with literally almost two thousand emails over > the last fifteen years from people asking for help, I'm reluctant to > call it that. > > It works well for many people and I'm really glad it exists. But > there's still an unfortunate amount of work involved in getting it set > up and working. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From sac at 300baud.de Fri May 29 23:46:47 2020 From: sac at 300baud.de (Stefan Claas) Date: Fri, 29 May 2020 23:46:47 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> Message-ID: <20200529234647.000025d2.sac@300baud.de> Robert J. Hansen wrote: > > Since you mention that you did support for Enigmail, do you have > > also infos about the current status of Thunderbird development, i.e. > > beta testing etc., regarding OpenPGP support, so that you may can > > tell us what people can expect? > > Enigmail development has ended. The upcoming 2.2 is the final release > and introduces no new features. It exists only to help people migrate > to TB78's OpenPGP support. > > TB68 is being EOLed this fall. We've promised to continue to support > users for six months after that, including giving emergency security > fixes to Enigmail if they become necessary: but at six months and one > day we're going to mop the floor, tally up the cash register, shut off > the lights, and lock up as we leave. > > (The only exception is a commercial email company that has a signed > support contract with Patrick -- their contract will be fulfilled.) Thanks for the info, much appreciated. Regards Stefan -- my 'hidden' service gopherhole: gopher://iria2xobffovwr6h.onion From bnsmith001 at gmail.com Sat May 30 00:29:16 2020 From: bnsmith001 at gmail.com (Barry Smith) Date: Fri, 29 May 2020 18:29:16 -0400 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> Message-ID: Robert. I am a long-time version of many different versions of Thunderbird, enigmail, and multiple packages of gpg. If TB 78 is going to have native support of openGPG encryption, then the original person in the thread should be able to export all of the keys in their key rings, and import all of those keys into TB 78, or am I missing one of the gotchas with TV 78 and it's openGPG encryption support. On Fri, May 29, 2020, 17:35 Robert J. Hansen wrote: > > Since you mention that you did support for Enigmail, do you have also > > infos about the current status of Thunderbird development, i.e. > > beta testing etc., regarding OpenPGP support, so that you may can tell > > us what people can expect? > > Enigmail development has ended. The upcoming 2.2 is the final release > and introduces no new features. It exists only to help people migrate > to TB78's OpenPGP support. > > TB68 is being EOLed this fall. We've promised to continue to support > users for six months after that, including giving emergency security > fixes to Enigmail if they become necessary: but at six months and one > day we're going to mop the floor, tally up the cash register, shut off > the lights, and lock up as we leave. > > (The only exception is a commercial email company that has a signed > support contract with Patrick -- their contract will be fulfilled.) > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sat May 30 01:07:03 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 29 May 2020 19:07:03 -0400 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> Message-ID: > If TB 78 is going to have native support of openGPG encryption, then the > original person in the thread should be able to export all of the keys > in their key rings, and import all of those keys into TB 78, or am I > missing one of the gotchas with > TV 78 and it's openGPG encryption support. You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot even import a key*." I'm not kidding. It is so far from complete that Kai Englert, who leads the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in TB until version 78.2, or about a three-month delay. At present, as of -Beta3, TB78's OpenPGP support is badly broken. From gk at leniwiec.biz Sat May 30 01:18:17 2020 From: gk at leniwiec.biz (Grzegorz Kulewski) Date: Sat, 30 May 2020 01:18:17 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> Message-ID: <08097758-f4be-470a-e231-c290f0b9b864@leniwiec.biz> W dniu 30.05.2020 o?01:07, Robert J. Hansen pisze: >> If TB 78 is going to have native support of openGPG encryption, then the >> original person in the thread should be able to export all of the keys >> in their key rings, and import all of those keys into TB 78, or am I >> missing one of the gotchas with >> TV 78 and it's openGPG encryption support. > > You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot > even import a key*." > > I'm not kidding. It is so far from complete that Kai Englert, who leads > the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in > TB until version 78.2, or about a three-month delay. > > At present, as of -Beta3, TB78's OpenPGP support is badly broken. Nice. Since you seem to be following OpenPGP-in-TB78 development: 1. Will key management and crypto happen in the same process as IMAP/POP/SMTP, GUI, JavaScript and everything else? If so - do you believe it's acceptable? 2. Is there any real plan to have working smartcard support in the near future? -- Grzegorz Kulewski From rjh at sixdemonbag.org Sat May 30 01:26:02 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 29 May 2020 19:26:02 -0400 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <08097758-f4be-470a-e231-c290f0b9b864@leniwiec.biz> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <08097758-f4be-470a-e231-c290f0b9b864@leniwiec.biz> Message-ID: > 1. Will key management and crypto happen in the same process as > IMAP/POP/SMTP, GUI, JavaScript and everything else? If so - do you > believe it's acceptable? It should be an easy learning curve for Enigmail users. That isn't the same as finding it acceptable, though. Back in the mid-'90s PGP came out with a GUI for PGP 5, and it's universally agreed at user interface was horrific. (See "Why Johnny Can't Encrypt" for a detailed teardown.) The problem was that this horrific user interface became the standard user interface, and most OpenPGP key managers ever since have adopted it. Those that haven't adopted it, nobody uses, because their UI is so different than everything else. > 2. Is there any real plan to have working smartcard support in the > near future? No. There's some talk about supporting it, but as far as I know there's no plan to do it. It's still at the "you know, it'd be kind of nice if..." stage, not the "we really should do this" stage. From gk at leniwiec.biz Sat May 30 01:39:06 2020 From: gk at leniwiec.biz (Grzegorz Kulewski) Date: Sat, 30 May 2020 01:39:06 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <08097758-f4be-470a-e231-c290f0b9b864@leniwiec.biz> Message-ID: <8a530359-e8b1-e099-4ea2-a4d1802ad9d1@leniwiec.biz> W dniu 30.05.2020 o?01:26, Robert J. Hansen pisze: >> 1. Will key management and crypto happen in the same process as >> IMAP/POP/SMTP, GUI, JavaScript and everything else? If so - do you >> believe it's acceptable? > > It should be an easy learning curve for Enigmail users. That isn't the > same as finding it acceptable, though. > > Back in the mid-'90s PGP came out with a GUI for PGP 5, and it's > universally agreed at user interface was horrific. (See "Why Johnny > Can't Encrypt" for a detailed teardown.) The problem was that this > horrific user interface became the standard user interface, and most > OpenPGP key managers ever since have adopted it. Those that haven't > adopted it, nobody uses, because their UI is so different than > everything else. I wasn't asking if GUI is acceptable. I was asking if crypto and GUI happen in the same process (the main TB process). Since they seem to be using a library for PGP it's quite probable. And if so - is that acceptable in your opinion? >> 2. Is there any real plan to have working smartcard support in the >> near future? > > No. There's some talk about supporting it, but as far as I know there's > no plan to do it. It's still at the "you know, it'd be kind of nice > if..." stage, not the "we really should do this" stage. Double nice. Time to check Claws I think. -- Grzegorz Kulewski gk at leniwiec.biz +48 663 92 88 95 From rjh at sixdemonbag.org Sat May 30 01:51:17 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 29 May 2020 19:51:17 -0400 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <8a530359-e8b1-e099-4ea2-a4d1802ad9d1@leniwiec.biz> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <08097758-f4be-470a-e231-c290f0b9b864@leniwiec.biz> <8a530359-e8b1-e099-4ea2-a4d1802ad9d1@leniwiec.biz> Message-ID: <758d7dee-37b6-0b9d-7a00-8c438d481aa0@sixdemonbag.org> > I wasn't asking if GUI is acceptable. I was asking if crypto and GUI > happen in the same process (the main TB process). Since they seem to > be using a library for PGP it's quite probable. And if so - is that > acceptable in your opinion? Oh! When you said "process", I read that as "workflow". My apologies. Yes, it's all part of the main family of processes. There's no spawning off of a GnuPG instance and setting up a communications channel to it. From cderr at simons-rock.edu Sat May 30 01:54:11 2020 From: cderr at simons-rock.edu (charlie derr) Date: Fri, 29 May 2020 19:54:11 -0400 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <8a530359-e8b1-e099-4ea2-a4d1802ad9d1@leniwiec.biz> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <08097758-f4be-470a-e231-c290f0b9b864@leniwiec.biz> <8a530359-e8b1-e099-4ea2-a4d1802ad9d1@leniwiec.biz> Message-ID: <084600fd-c463-2bfc-6463-dd7f8debc2f5@simons-rock.edu> On 5/29/20 7:39 PM, Grzegorz Kulewski wrote: > Time to check Claws I think. i've found that claws, evolution, sylpheed and kmail all integrate seamlessly with gpg2 (using standard debian packages for everything) ~c -- Charlie Derr Director, Instructional Technology 413-528-7344 https://www.simons-rock.edu Bard College at Simon's Rock Encryption key: http://hope.simons-rock.edu/~cderr/ Personal writing: https://medium.com/@cderr pronouns: either he/him or they/them is acceptable Home landline: 860-435-1427 From chriechers at aim.com Sat May 30 11:23:54 2020 From: chriechers at aim.com (Christian Riechers) Date: Sat, 30 May 2020 11:23:54 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <08097758-f4be-470a-e231-c290f0b9b864@leniwiec.biz> Message-ID: <25f44a4d-ffd1-0702-7996-99a08de65ae5@aim.com> On 5/30/20 1:26 AM, Robert J. Hansen wrote: >> 2. Is there any real plan to have working smartcard support in the >> near future? > > No. There's some talk about supporting it, but as far as I know there's > no plan to do it. It's still at the "you know, it'd be kind of nice > if..." stage, not the "we really should do this" stage. Smart card support is on the ToDo list. https://wiki.mozilla.org/index.php?title=Thunderbird:OpenPGP:Status From steffen at sdaoden.eu Sat May 30 16:52:10 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 30 May 2020 16:52:10 +0200 Subject: libgcrypt: random source via library on Linux? In-Reply-To: <20200529202134.6LZBJ%steffen@sdaoden.eu> References: <20200526133548.V9X00%steffen@sdaoden.eu> <875zcgtizp.fsf@wheatstone.g10code.de> <20200528124301.mbcVa%steffen@sdaoden.eu> <87sgfjrqf1.fsf@wheatstone.g10code.de> <20200529155411.TgyU1%steffen@sdaoden.eu> <20200529202134.6LZBJ%steffen@sdaoden.eu> Message-ID: <20200530145210.EwnnE%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20200529202134.6LZBJ%steffen at sdaoden.eu>: |Steffen Nurpmeso wrote in |<20200529155411.TgyU1%steffen at sdaoden.eu>: ||Werner Koch wrote in ||<87sgfjrqf1.fsf at wheatstone.g10code.de>: |||On Thu, 28 May 2020 14:43, Steffen Nurpmeso said: ... |So with the attached patch libgcrypt solely relies upon getentropy |if available, no FD handling is done no more if at all possible. |The test suite passes, a short review makes me think it is alright. Maybe, but it was not. Please find attached a second one to be applied on top, it fixes some preprocessor problems. Please just feel free to take those, and commit under your name or any way you like it. Joining them into one would be nice... Thank you, and Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -------------- next part -------------- A non-text attachment was scrubbed... Name: gcrypt-linux-2.diff Type: text/x-diff Size: 3340 bytes Desc: not available URL: From patrick at enigmail.net Sat May 30 18:20:31 2020 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 30 May 2020 18:20:31 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <08097758-f4be-470a-e231-c290f0b9b864@leniwiec.biz> Message-ID: <3033a0b7-debb-96fb-c173-6aabac3c42b3@enigmail.net> Robert J. Hansen wrote on 30.05.2020 01:26: >> 1. Will key management and crypto happen in the same process as >> IMAP/POP/SMTP, GUI, JavaScript and everything else? If so - do you >> believe it's acceptable? > > It should be an easy learning curve for Enigmail users. That isn't the > same as finding it acceptable, though. > > Back in the mid-'90s PGP came out with a GUI for PGP 5, and it's > universally agreed at user interface was horrific. (See "Why Johnny > Can't Encrypt" for a detailed teardown.) The problem was that this > horrific user interface became the standard user interface, and most > OpenPGP key managers ever since have adopted it. Those that haven't > adopted it, nobody uses, because their UI is so different than > everything else. > >> 2. Is there any real plan to have working smartcard support in the >> near future? > > No. There's some talk about supporting it, but as far as I know there's > no plan to do it. It's still at the "you know, it'd be kind of nice > if..." stage, not the "we really should do this" stage. The plan is to support smartcards (by using GnuPG for private key operations). This is already working partially, and is foreseen to be available in TB 78. -Patrick From patrick at enigmail.net Sat May 30 18:17:23 2020 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 30 May 2020 18:17:23 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> Message-ID: Robert J. Hansen wrote on 30.05.2020 01:07: >> If TB 78 is going to have native support of openGPG encryption, then the >> original person in the thread should be able to export all of the keys >> in their key rings, and import all of those keys into TB 78, or am I >> missing one of the gotchas with >> TV 78 and it's openGPG encryption support. > > You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot > even import a key*." I'm sorry, but that is simply not true. There is a known bug in the library used by Thunderbird (RNP) that leads to crashes when importing _certain_ keys. But I succeeded in importing all of my keys without any problems (more than 1.000), except for 5 V3-keys. I can definitely say that it's not just broken, and it can import keys. > I'm not kidding. It is so far from complete that Kai Englert, who leads > the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in > TB until version 78.2, or about a three-month delay. Again, that's oversimplified. OpenPGP will not be enabled _by_ _default_ but users may still enable it manually. > At present, as of -Beta3, TB78's OpenPGP support is badly broken. No, it's incomplete - work in progress. That's not quite the same. -Patrick From azbigdogs at gmx.com Sat May 30 20:54:35 2020 From: azbigdogs at gmx.com (Mark) Date: Sat, 30 May 2020 11:54:35 -0700 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> Message-ID: <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> So then do you have multiple pairs of key rings? One pair for TB78 and its built in PGP and another pair as part of GNUPG? If so how do you keep them synchronized? On 5/30/2020 9:17 AM, Patrick Brunschwig wrote: > Robert J. Hansen wrote on 30.05.2020 01:07: >>> If TB 78 is going to have native support of openGPG encryption, then the >>> original person in the thread should be able to export all of the keys >>> in their key rings, and import all of those keys into TB 78, or am I >>> missing one of the gotchas with >>> TV 78 and it's openGPG encryption support. >> You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot >> even import a key*." > I'm sorry, but that is simply not true. There is a known bug in the > library used by Thunderbird (RNP) that leads to crashes when importing > _certain_ keys. But I succeeded in importing all of my keys without any > problems (more than 1.000), except for 5 V3-keys. I can definitely say > that it's not just broken, and it can import keys. > >> I'm not kidding. It is so far from complete that Kai Englert, who leads >> the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in >> TB until version 78.2, or about a three-month delay. > Again, that's oversimplified. OpenPGP will not be enabled _by_ _default_ > but users may still enable it manually. > >> At present, as of -Beta3, TB78's OpenPGP support is badly broken. > No, it's incomplete - work in progress. That's not quite the same. > > -Patrick > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From patrick at enigmail.net Sat May 30 21:57:16 2020 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 30 May 2020 21:57:16 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> Message-ID: <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> Mark wrote on 30.05.2020 20:54: > So then do you have multiple pairs of key rings? One pair for TB78 and > its built in PGP and another pair as part of GNUPG? No exactly. You have your secret keys with GnuPG, and your public keys with Thunderbird. No synchronization required. -Patrick > > If so how do you keep them synchronized? > > On 5/30/2020 9:17 AM, Patrick Brunschwig wrote: >> Robert J. Hansen wrote on 30.05.2020 01:07: >>>> If TB 78 is going to have native support of openGPG encryption, then the >>>> original person in the thread should be able to export all of the keys >>>> in their key rings, and import all of those keys into TB 78, or am I >>>> missing one of the gotchas with >>>> TV 78 and it's openGPG encryption support. >>> You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot >>> even import a key*." >> I'm sorry, but that is simply not true. There is a known bug in the >> library used by Thunderbird (RNP) that leads to crashes when importing >> _certain_ keys. But I succeeded in importing all of my keys without any >> problems (more than 1.000), except for 5 V3-keys. I can definitely say >> that it's not just broken, and it can import keys. >> >>> I'm not kidding. It is so far from complete that Kai Englert, who leads >>> the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in >>> TB until version 78.2, or about a three-month delay. >> Again, that's oversimplified. OpenPGP will not be enabled _by_ _default_ >> but users may still enable it manually. >> >>> At present, as of -Beta3, TB78's OpenPGP support is badly broken. >> No, it's incomplete - work in progress. That's not quite the same. >> >> -Patrick >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Sun May 31 00:05:38 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 30 May 2020 18:05:38 -0400 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> Message-ID: <2bb02807-04bc-112e-1d93-e5e6191fe886@sixdemonbag.org> > I'm sorry, but that is simply not true. There is a known bug in the > library used by Thunderbird (RNP) that leads to crashes when importing > _certain_ keys. But I succeeded in importing all of my keys without any > problems (more than 1.000), except for 5 V3-keys. I can definitely say > that it's not just broken, and it can import keys. I have yet to talk to anyone who's been able to import their keyring, which is the absolute minimum use case. When it fails it does so silently. If the minimum use case of "average users should be able to import their keyrings" leads to RNP crashing, no keys being imported, and no error message being generated, I have no problem calling key importation broken. > Again, that's oversimplified. OpenPGP will not be enabled _by_ _default_ > but users may still enable it manually. According to Kai's post on one of the TB mailing lists, he wants the version in 78 to be a technology preview, hidden from the user, and only accessible to power users. I don't consider that to be shipping it for 78. From azbigdogs at gmx.com Sun May 31 01:28:59 2020 From: azbigdogs at gmx.com (Mark) Date: Sat, 30 May 2020 16:28:59 -0700 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> Message-ID: Doesn't TB also need your secret keys to decrypt messages??? Also what if you need your public keys outside of TB such as encrypting a file? The reason I'm asking is that awhile ago I posted about unknown files in my GNUPG directory. PAPubring.gpg and PAsecring.gpg. I eventually found out those are key rings used by a program I have called Power Archiver. I'm not sure why it has it own set of keys, still awaiting an explanation from support. If every app is not using the same pair of key rings (and there is no synchronization between them) could that not lead to problems? Thanks On 5/30/2020 12:57 PM, Patrick Brunschwig wrote: > Mark wrote on 30.05.2020 20:54: >> So then do you have multiple pairs of key rings? One pair for TB78 and >> its built in PGP and another pair as part of GNUPG? > No exactly. You have your secret keys with GnuPG, and your public keys > with Thunderbird. No synchronization required. > > -Patrick >> If so how do you keep them synchronized? >> >> On 5/30/2020 9:17 AM, Patrick Brunschwig wrote: >>> Robert J. Hansen wrote on 30.05.2020 01:07: >>>>> If TB 78 is going to have native support of openGPG encryption, then the >>>>> original person in the thread should be able to export all of the keys >>>>> in their key rings, and import all of those keys into TB 78, or am I >>>>> missing one of the gotchas with >>>>> TV 78 and it's openGPG encryption support. >>>> You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot >>>> even import a key*." >>> I'm sorry, but that is simply not true. There is a known bug in the >>> library used by Thunderbird (RNP) that leads to crashes when importing >>> _certain_ keys. But I succeeded in importing all of my keys without any >>> problems (more than 1.000), except for 5 V3-keys. I can definitely say >>> that it's not just broken, and it can import keys. >>> >>>> I'm not kidding. It is so far from complete that Kai Englert, who leads >>>> the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in >>>> TB until version 78.2, or about a three-month delay. >>> Again, that's oversimplified. OpenPGP will not be enabled _by_ _default_ >>> but users may still enable it manually. >>> >>>> At present, as of -Beta3, TB78's OpenPGP support is badly broken. >>> No, it's incomplete - work in progress. That's not quite the same. >>> >>> -Patrick >>> >>> _______________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users From patrick at enigmail.net Sun May 31 10:01:34 2020 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 31 May 2020 10:01:34 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> Message-ID: <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> Mark wrote on 31.05.2020 01:28: > Doesn't TB also need your secret keys to decrypt messages?? With smartcard support via GnuPG, all secret key operations are handled by GnuPG, and all public key operations are handled by TB (Note: the standard case, without smartcard support, will be that all keys are in Thunderbird). The use-cases are clearly distinct: - encryption: you only need public keys - decryption: you only need secret keys - signing: you only need secret keys - verification: you only need public keys > Also what if you need your public keys outside of TB such as encrypting > a file? That's not supported by Thunderbird. The idea of OpenPGP in Thunderbird is that you use it for email. > The reason I'm asking is that awhile ago I posted about unknown files in > my GNUPG directory. PAPubring.gpg and PAsecring.gpg. I eventually found > out those are key rings used by a program I have called Power Archiver. > I'm not sure why it has it own set of keys, still awaiting an > explanation from support. If every app is not using the same pair of key > rings (and there is no synchronization between them) could that not lead > to problems? The only "problem" might be that you have different keys on different key rings. But this is not necessarily a problem - you use different keys for different purposes and you can import and export the keys between the tools if needed. -Patrick > On 5/30/2020 12:57 PM, Patrick Brunschwig wrote: >> Mark wrote on 30.05.2020 20:54: >>> So then do you have multiple pairs of key rings? One pair for TB78 and >>> its built in PGP and another pair as part of GNUPG? >> No exactly. You have your secret keys with GnuPG, and your public keys >> with Thunderbird. No synchronization required. >> >> -Patrick >>> If so how do you keep them synchronized? >>> >>> On 5/30/2020 9:17 AM, Patrick Brunschwig wrote: >>>> Robert J. Hansen wrote on 30.05.2020 01:07: >>>>>> If TB 78 is going to have native support of openGPG encryption, then the >>>>>> original person in the thread should be able to export all of the keys >>>>>> in their key rings, and import all of those keys into TB 78, or am I >>>>>> missing one of the gotchas with >>>>>> TV 78 and it's openGPG encryption support. >>>>> You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot >>>>> even import a key*." >>>> I'm sorry, but that is simply not true. There is a known bug in the >>>> library used by Thunderbird (RNP) that leads to crashes when importing >>>> _certain_ keys. But I succeeded in importing all of my keys without any >>>> problems (more than 1.000), except for 5 V3-keys. I can definitely say >>>> that it's not just broken, and it can import keys. >>>> >>>>> I'm not kidding. It is so far from complete that Kai Englert, who leads >>>>> the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in >>>>> TB until version 78.2, or about a three-month delay. >>>> Again, that's oversimplified. OpenPGP will not be enabled _by_ _default_ >>>> but users may still enable it manually. >>>> >>>>> At present, as of -Beta3, TB78's OpenPGP support is badly broken. >>>> No, it's incomplete - work in progress. That's not quite the same. >>>> >>>> -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 802 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sun May 31 11:07:53 2020 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 31 May 2020 11:07:53 +0200 Subject: Exchange between muiltiple OpenPGP implementations In-Reply-To: <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> Message-ID: <0ff9271f-57b8-e1b7-75f0-16062ec05c19@digitalbrains.com> Hi, On 31/05/2020 10:01, Patrick Brunschwig wrote: > The only "problem" might be that you have different keys on different > key rings. But this is not necessarily a problem - you use different > keys for different purposes and you can import and export the keys > between the tools if needed. Does the new TB implementation support TOFU? If so, you lose your TOFU historical data and identity assertions when you would export/import to a different OpenPGP implementation. That'd be a shame. Maybe there's a need for a standardised interchange format for that. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From computer at boehlk.com Sun May 31 11:09:58 2020 From: computer at boehlk.com (Andreas Boehlk Computer-Service) Date: Sun, 31 May 2020 11:09:58 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> Message-ID: Hello Patrick, Am 31.05.2020 um 10:01 schrieb Patrick Brunschwig: > Mark wrote on 31.05.2020 01:28: >> Doesn't TB also need your secret keys to decrypt messages?? > > With smartcard support via GnuPG, all secret key operations are handled > by GnuPG, and all public key operations are handled by TB (Note: the > standard case, without smartcard support, will be that all keys are in > Thunderbird). > > The use-cases are clearly distinct: > - encryption: you only need public keys > - decryption: you only need secret keys > - signing: you only need secret keys > - verification: you only need public keys > The standard user will not be able to work with that "solution". Compared to the "enigmail-solution" this is the hell and bound to fail. >> Also what if you need your public keys outside of TB such as encrypting >> a file? > > That's not supported by Thunderbird. The idea of OpenPGP in Thunderbird > is that you use it for email. > That is correct, but nevertheless it is mandatory to have and use a single key-store. >> The reason I'm asking is that awhile ago I posted about unknown files in >> my GNUPG directory. PAPubring.gpg and PAsecring.gpg. I eventually found >> out those are key rings used by a program I have called Power Archiver. >> I'm not sure why it has it own set of keys, still awaiting an >> explanation from support. If every app is not using the same pair of key >> rings (and there is no synchronization between them) could that not lead >> to problems? > > The only "problem" might be that you have different keys on different > key rings. But this is not necessarily a problem - you use different > keys for different purposes and you can import and export the keys > between the tools if needed. > As I stated before: This is a real problem. Multiple keys-stores are not manageable and this planned solution is much more complicated than the current with enigmail. Therefore it is bound to be a non-starter. > -Patrick > >> On 5/30/2020 12:57 PM, Patrick Brunschwig wrote: >>> Mark wrote on 30.05.2020 20:54: >>>> So then do you have multiple pairs of key rings? One pair for TB78 and >>>> its built in PGP and another pair as part of GNUPG? >>> No exactly. You have your secret keys with GnuPG, and your public keys >>> with Thunderbird. No synchronization required. >>> >>> -Patrick >>>> If so how do you keep them synchronized? >>>> >>>> On 5/30/2020 9:17 AM, Patrick Brunschwig wrote: >>>>> Robert J. Hansen wrote on 30.05.2020 01:07: >>>>>>> If TB 78 is going to have native support of openGPG encryption, then the >>>>>>> original person in the thread should be able to export all of the keys >>>>>>> in their key rings, and import all of those keys into TB 78, or am I >>>>>>> missing one of the gotchas with >>>>>>> TV 78 and it's openGPG encryption support. >>>>>> You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot >>>>>> even import a key*." >>>>> I'm sorry, but that is simply not true. There is a known bug in the >>>>> library used by Thunderbird (RNP) that leads to crashes when importing >>>>> _certain_ keys. But I succeeded in importing all of my keys without any >>>>> problems (more than 1.000), except for 5 V3-keys. I can definitely say >>>>> that it's not just broken, and it can import keys. >>>>> >>>>>> I'm not kidding. It is so far from complete that Kai Englert, who leads >>>>>> the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in >>>>>> TB until version 78.2, or about a three-month delay. >>>>> Again, that's oversimplified. OpenPGP will not be enabled _by_ _default_ >>>>> but users may still enable it manually. >>>>> >>>>>> At present, as of -Beta3, TB78's OpenPGP support is badly broken. >>>>> No, it's incomplete - work in progress. That's not quite the same. >>>>> >>>>> -Patrick > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From computer at boehlk.com Sun May 31 10:28:43 2020 From: computer at boehlk.com (Andreas Boehlk Computer-Service) Date: Sun, 31 May 2020 10:28:43 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> Message-ID: Hello Mark, I totally agree. It is not possible to have more than one key store. Synchronization always fails some time and the standard user cannot handle it. So the only solution for TB will be to use GNUPG, because it has the only key store for all platforms and has proved to work for years. That results in the only possible solution for TB to integrate the enigmail functionality into the code directly or live with the enigmail plug-in. All other solutions are defective by design from start. Andreas Am 31.05.2020 um 01:28 schrieb Mark: > Doesn't TB also need your secret keys to decrypt messages??? > > Also what if you need your public keys outside of TB such as encrypting > a file? > > The reason I'm asking is that awhile ago I posted about unknown files in > my GNUPG directory. PAPubring.gpg and PAsecring.gpg. I eventually found > out those are key rings used by a program I have called Power Archiver. > I'm not sure why it has it own set of keys, still awaiting an > explanation from support. If every app is not using the same pair of key > rings (and there is no synchronization between them) could that not lead > to problems? > > Thanks > > On 5/30/2020 12:57 PM, Patrick Brunschwig wrote: >> Mark wrote on 30.05.2020 20:54: >>> So then do you have multiple pairs of key rings? One pair for TB78 and >>> its built in PGP and another pair as part of GNUPG? >> No exactly. You have your secret keys with GnuPG, and your public keys >> with Thunderbird. No synchronization required. >> >> -Patrick >>> If so how do you keep them synchronized? >>> >>> On 5/30/2020 9:17 AM, Patrick Brunschwig wrote: >>>> Robert J. Hansen wrote on 30.05.2020 01:07: >>>>>> If TB 78 is going to have native support of openGPG encryption, then the >>>>>> original person in the thread should be able to export all of the keys >>>>>> in their key rings, and import all of those keys into TB 78, or am I >>>>>> missing one of the gotchas with >>>>>> TV 78 and it's openGPG encryption support. >>>>> You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot >>>>> even import a key*." >>>> I'm sorry, but that is simply not true. There is a known bug in the >>>> library used by Thunderbird (RNP) that leads to crashes when importing >>>> _certain_ keys. But I succeeded in importing all of my keys without any >>>> problems (more than 1.000), except for 5 V3-keys. I can definitely say >>>> that it's not just broken, and it can import keys. >>>> >>>>> I'm not kidding. It is so far from complete that Kai Englert, who leads >>>>> the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in >>>>> TB until version 78.2, or about a three-month delay. >>>> Again, that's oversimplified. OpenPGP will not be enabled _by_ _default_ >>>> but users may still enable it manually. >>>> >>>>> At present, as of -Beta3, TB78's OpenPGP support is badly broken. >>>> No, it's incomplete - work in progress. That's not quite the same. >>>> >>>> -Patrick >>>> >>>> _______________________________________________ >>>> Gnupg-users mailing list >>>> Gnupg-users at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From chad.williams at dxc.com Sat May 30 16:51:49 2020 From: chad.williams at dxc.com (Williams, Chad L) Date: Sat, 30 May 2020 14:51:49 +0000 Subject: gpg generate key is not finishing Message-ID: Attempting to generate a key on Solaris 10 server using the below command gpg --full-generate-key --pinentry-mode=loopback Everything seem to be working but the key generation never completes. Its been setting at this point for 10 hours. I tried to produce more entropy by running suggested command on other console and the agent is running root 8249 28754 0 21:48:19 pts/12 0:02 gpg --full-generate-key --pinentry-mode=loopback root 17222 1 0 19:55:32 ? 0:08 gpg-agent --homedir /root/.gnupg --use-standard-socket --daemon GnuPG needs to construct a user ID to identify your key. Real name: root1 Email address: root at localhost Comment: You selected this USER-ID: "root1 " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. afffffkkdkdkdkdkdkkdkdkdkdkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --. -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at enigmail.net Sun May 31 12:17:06 2020 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 31 May 2020 12:17:06 +0200 Subject: Exchange between muiltiple OpenPGP implementations In-Reply-To: <0ff9271f-57b8-e1b7-75f0-16062ec05c19@digitalbrains.com> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> <0ff9271f-57b8-e1b7-75f0-16062ec05c19@digitalbrains.com> Message-ID: <8abcc5f8-8cac-0773-ea0c-f9edf551cbed@enigmail.net> Peter Lebbing wrote on 31.05.2020 11:07: > Hi, > > On 31/05/2020 10:01, Patrick Brunschwig wrote: >> The only "problem" might be that you have different keys on different >> key rings. But this is not necessarily a problem - you use different >> keys for different purposes and you can import and export the keys >> between the tools if needed. > > Does the new TB implementation support TOFU? If so, you lose your TOFU > historical data and identity assertions when you would export/import to > a different OpenPGP implementation. That'd be a shame. Maybe there's a > need for a standardised interchange format for that. TB chose (unfortunately in my eyes) to currently only support explicit trust using their own trust handling. I hope that future versions will support other methods. -Patrick From patrick at enigmail.net Sun May 31 12:35:00 2020 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 31 May 2020 12:35:00 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> Message-ID: <6b33aedb-65f8-723e-bb37-0a7b97917de1@enigmail.net> Andreas Boehlk Computer-Service wrote on 31.05.2020 11:09: > Hello Patrick, > > > Am 31.05.2020 um 10:01 schrieb Patrick Brunschwig: >> Mark wrote on 31.05.2020 01:28: >>> Doesn't TB also need your secret keys to decrypt messages?? >> >> With smartcard support via GnuPG, all secret key operations are handled >> by GnuPG, and all public key operations are handled by TB (Note: the >> standard case, without smartcard support, will be that all keys are in >> Thunderbird). >> >> The use-cases are clearly distinct: >> - encryption: you only need public keys >> - decryption: you only need secret keys >> - signing: you only need secret keys >> - verification: you only need public keys >> > The standard user will not be able to work with that "solution". > Compared to the "enigmail-solution" this is the hell and bound to fail. Let's first define Standard users. The majority of users who use smartcards that *I* know are expert or power users. They can handle this. The "Standard users" I have in mind don't use GnuPG for anything else than encrypting mails, and they don't use smartcards either. They won't have this issue in any way. >>> Also what if you need your public keys outside of TB such as encrypting >>> a file? >> >> That's not supported by Thunderbird. The idea of OpenPGP in Thunderbird >> is that you use it for email. >> > That is correct, but nevertheless it is mandatory to have and use a > single key-store. For which use-case precisely? If you only use OpenPGP for emails (and given the users I know who had support cases in the past, this is true for the majority of the Enigmail users), then this is irrelevant. To be quite clear: Thunderbird will not support GnuPG for scenarios other than handling secret keys. And that's only because the OpenPGP library they use can't handle smartcards yet. Once the library will support smartcards, I expect that GnuPG support will be removed entirely. Note: I'm not a Thunderbird developer and I don't drive Thunderbird decisions -- this is simply my expectation of what will happen. -Patrick From lists at theflorys.org Sun May 31 19:10:43 2020 From: lists at theflorys.org (David Flory) Date: Sun, 31 May 2020 11:10:43 -0600 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> Message-ID: <7c37900f-89ad-e163-62de-cc5086e51f58@theflorys.org> On 5/30/2020 10:17 AM, Patrick Brunschwig wrote: [snip] > I'm sorry, but that is simply not true. There is a known bug in the > library used by Thunderbird (RNP) that leads to crashes when importing > _certain_ keys. But I succeeded in importing all of my keys without any > problems (more than 1.000), except for 5 V3-keys. I can definitely say > that it's not just broken, and it can import keys. [snip] How does one identify a v3 key? David -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xE334A5C93AE58BA6.asc Type: application/pgp-keys Size: 4290 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From azbigdogs at gmx.com Sun May 31 20:23:01 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 31 May 2020 11:23:01 -0700 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> Message-ID: <2f1eac70-cdc8-dd01-6632-5ffbba8fae70@gmx.com> That is what I see happening too. When you start having multiple key stores, which one contains the "correct" keys?? I saw that happening in just my very limited usage where another program has its own key rings...? On 5/31/2020 1:28 AM, Andreas Boehlk Computer-Service wrote: > Hello Mark, > > I totally agree. It is not possible to have more than one key store. > Synchronization always fails some time and the standard user cannot > handle it. So the only solution for TB will be to use GNUPG, because it > has the only key store for all platforms and has proved to work for > years. That results in the only possible solution for TB to integrate > the enigmail functionality into the code directly or live with the > enigmail plug-in. All other solutions are defective by design from start. > > Andreas > > ://lists.gnupg.org/mailman/listinfo/gnupg-users From azbigdogs at gmx.com Sun May 31 20:25:10 2020 From: azbigdogs at gmx.com (Mark) Date: Sun, 31 May 2020 11:25:10 -0700 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> Message-ID: So for all of us that don't use a smart card to store our keys, they are stored in TB?? What if we also have need for that key outside of email such as signing or decrypting files? We still need that key in GNUPG as well. If we change the key at all then we have to make sure it has been updated in both areas??? I could see a similar situation could develop with the public keys where the ones stored in TB are not in sync with the ones stored in GNUPG.? What happens with keys that are obtained from websites for places like Apple, Microsoft, etc that are not being directly imported from an email? Maybe I am overthinking it or just missing something but I see potential problems with this. If they are not using the same data (key rings) or in constant synchronization, the "wrong key" could be used.?? Hopefully they have a way to address this. On 5/31/2020 1:01 AM, Patrick Brunschwig wrote: > Mark wrote on 31.05.2020 01:28: >> Doesn't TB also need your secret keys to decrypt messages?? > With smartcard support via GnuPG, all secret key operations are handled > by GnuPG, and all public key operations are handled by TB (Note: the > standard case, without smartcard support, will be that all keys are in > Thunderbird). > > The use-cases are clearly distinct: > - encryption: you only need public keys > - decryption: you only need secret keys > - signing: you only need secret keys > - verification: you only need public keys > >> Also what if you need your public keys outside of TB such as encrypting >> a file? > That's not supported by Thunderbird. The idea of OpenPGP in Thunderbird > is that you use it for email. > >> The reason I'm asking is that awhile ago I posted about unknown files in >> my GNUPG directory. PAPubring.gpg and PAsecring.gpg. I eventually found >> out those are key rings used by a program I have called Power Archiver. >> I'm not sure why it has it own set of keys, still awaiting an >> explanation from support. If every app is not using the same pair of key >> rings (and there is no synchronization between them) could that not lead >> to problems? > The only "problem" might be that you have different keys on different > key rings. But this is not necessarily a problem - you use different > keys for different purposes and you can import and export the keys > between the tools if needed. > > -Patrick > >> On 5/30/2020 12:57 PM, Patrick Brunschwig wrote: >>> Mark wrote on 30.05.2020 20:54: >>>> So then do you have multiple pairs of key rings? One pair for TB78 and >>>> its built in PGP and another pair as part of GNUPG? >>> No exactly. You have your secret keys with GnuPG, and your public keys >>> with Thunderbird. No synchronization required. >>> >>> -Patrick >>>> If so how do you keep them synchronized? >>>> >>>> On 5/30/2020 9:17 AM, Patrick Brunschwig wrote: >>>>> Robert J. Hansen wrote on 30.05.2020 01:07: >>>>>>> If TB 78 is going to have native support of openGPG encryption, then the >>>>>>> original person in the thread should be able to export all of the keys >>>>>>> in their key rings, and import all of those keys into TB 78, or am I >>>>>>> missing one of the gotchas with >>>>>>> TV 78 and it's openGPG encryption support. >>>>>> You're missing the gotcha of "as of -Beta3, the new Thunderbird *cannot >>>>>> even import a key*." >>>>> I'm sorry, but that is simply not true. There is a known bug in the >>>>> library used by Thunderbird (RNP) that leads to crashes when importing >>>>> _certain_ keys. But I succeeded in importing all of my keys without any >>>>> problems (more than 1.000), except for 5 V3-keys. I can definitely say >>>>> that it's not just broken, and it can import keys. >>>>> >>>>>> I'm not kidding. It is so far from complete that Kai Englert, who leads >>>>>> the TB78 OpenPGP effort, recently proposed postponing OpenPGP support in >>>>>> TB until version 78.2, or about a three-month delay. >>>>> Again, that's oversimplified. OpenPGP will not be enabled _by_ _default_ >>>>> but users may still enable it manually. >>>>> >>>>>> At present, as of -Beta3, TB78's OpenPGP support is badly broken. >>>>> No, it's incomplete - work in progress. That's not quite the same. >>>>> >>>>> -Patrick >