From david at gbenet.com Thu Aug 1 09:49:05 2019 From: david at gbenet.com (David) Date: Thu, 1 Aug 2019 08:49:05 +0100 Subject: Enigmail In-Reply-To: References: <74076eb0-5089-349d-7c05-311a06620856@gbenet.com> <20190730162314.000021d8.sac@300baud.de> <20190730194044.00003ebe.sac@300baud.de> <23C0C61C-8EDC-40F3-A824-0B8B4071F473@andrewg.com> <46eaf032-da4c-227f-3ae3-b7a7e9e5cf0e@gbenet.com> <117d1127-8d10-88c7-8648-7b4404ec231e__10128.4245656402$1564556265$gmane$org@gbenet.com> <02b9d27b-fd8e-711b-8fac-562b68597615@enigmail.net> Message-ID: <09413db8-7850-085f-89cf-beac7d804c6b@gbenet.com> Andrew Gallagher: > On 31/07/2019 13:36, David wrote: >> Enigmail always defaults to the first set of keys one created > > Enigmail will default to the first set of keys in your keyring that > matches the selection criteria. Do you have more than one ID on each > key? Do you have more than one key for each ID? This could be causing > some confusion. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Andrew, I have one key pair associated with one email address Those keys do not have other ids attached to them. Each key pair is only for a single (not multiple) email account. Regards David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com From gnupgmlusers.fwnsp at xoxy.net Thu Aug 1 03:50:08 2019 From: gnupgmlusers.fwnsp at xoxy.net (Friedhelm Waitzmann) Date: Thu, 1 Aug 2019 03:50:08 +0200 Subject: --lsign --add-me or the invisible WoT In-Reply-To: <20190731162537.00005c16.sac@300baud.de> References: <20190720115720.000020da.sac@300baud.de> <87zhkubf6j.fsf@wheatstone.g10code.de> <20190731155857.00000125.sac@300baud.de> <20190731162537.00005c16.sac@300baud.de> Message-ID: <20190801014939.GB6013@kugelfisch> Stefan Claas: >I lsign Bob's key so third parties do not know (normally) that I did >this. But how could my friend Alice trust Bob's key she has without >my non-exportable lsign sig? >What I tried to propose is an additional parameter, like --add-me >which would write a 'blob' to a second file.db where I can export >then Bob's blob (non-compatible to SKS etc.) with my --lsign sig, >and give it to my friend Alice. I think, this can be done with GnuPG as it is: In the following GnuPG invocations $TEMP_KEYRING stands for a temporary key ring: (1) export Bob's key from your default key ring, minimize it, and import it into the temporary one. $ gpg --export-options=export-minimal \ --export =user_id_of_Bob | \ gpg --no-default-keyring --keyring=$TEMP_KEYRING --import Now you have Bob's public key minimized in the temporary key ring. (2) lsign a user id of Bob: $ gpg --no-default-keyring --keyring=$TEMP_KEYRING \ --lsign =user_id_of_Bob (3) export this version of Bob's public key into a public key block Bob.pubkey, that you can give to Alice: $ gpg --no-default-keyring --keyring=$TEMP_KEYRING \ --export-options=export-local-sigs \ --output Bob.pubkey \ --export (4) import your local signature into your default key ring: $ gpg --import-options=import-local-sigs --import Bob.pubkey >Later If Alice knows Bob better >or personally knows him she can --lsign --add-me Bob's key ('blob') >too and give it to her friend Mary. Alice would do the same: Import Bob's keyblock Bob.pubkey into a temporary key ring using --import-options=import-local-sigs, lsign it there, export it using --export-options=export-local-sigs into Bob.pubkey, give Bob.pubkey to Mary and import Bob.pubkey using --import-options=import-local-sigs in her default key ring. Regards Friedhelm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-keys Size: 13051 bytes Desc: PGP Key 0xD0B55F3592C00CED. URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Digital signature URL: From wk at gnupg.org Thu Aug 1 13:37:26 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Aug 2019 13:37:26 +0200 Subject: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information In-Reply-To: <87pnltt0px.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via Gnupg-users's message of "Mon, 29 Jul 2019 09:43:54 -0400") References: <501932509.20190728141245@my_localhost_LG> <87pnltt0px.fsf@fifthhorseman.net> Message-ID: <87ftmlqfpl.fsf@wheatstone.g10code.de> On Mon, 29 Jul 2019 09:43, gnupg-users at gnupg.org said: > it that way", i think. Perhaps Werner can provide more background on > why GnuPG is generally resistant to holding OpenPGP certificates that > have no User ID at all in its local keyring. The user ID is important because the accompanying self-signature conveys important information about the keyblock. For example expiration date and preferences. It is true that this can also be conveyed with direct-key-signatures (a self-signature directly on a key which was mainly introduced for dedicated revocations). However, this is a not so well tested feature of gpg and my educated guess is that many other OpenPGP implementations do not handle direct-key signatures in a way compatible to pgp or gpg - if at all. Thus by relying on them we would sail into uncharted waters. > Doing such a merge would be super helpful, particularly for receiving > things like subkey updates and revocation information from I agree that we can add a code path to import a primary key plus revocation certificate but without user-ids. PGP however, does not support this and is the reason why we extended the revocation certifciate with a minmal primary key. Update of subkeys is a different issue and I see no solid use case for allowing that without user-id (cf. expiration date of the primary key). 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 Aug 1 15:16:02 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 1 Aug 2019 15:16:02 +0200 Subject: --lsign --add-me or the invisible WoT In-Reply-To: <20190801014939.GB6013@kugelfisch> References: <20190720115720.000020da.sac@300baud.de> <87zhkubf6j.fsf@wheatstone.g10code.de> <20190731155857.00000125.sac@300baud.de> <20190731162537.00005c16.sac@300baud.de> <20190801014939.GB6013@kugelfisch> Message-ID: <20190801151602.00001a3a.sac@300baud.de> Friedhelm Waitzmann wrote: > Stefan Claas: > > >I lsign Bob's key so third parties do not know (normally) that I did > >this. But how could my friend Alice trust Bob's key she has without > >my non-exportable lsign sig? > > >What I tried to propose is an additional parameter, like --add-me > >which would write a 'blob' to a second file.db where I can export > >then Bob's blob (non-compatible to SKS etc.) with my --lsign sig, > >and give it to my friend Alice. > > I think, this can be done with GnuPG as it is: [snip] Thank you very much Friedhelm! Best regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From dkg at fifthhorseman.net Thu Aug 1 15:27:45 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 Aug 2019 09:27:45 -0400 Subject: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information In-Reply-To: <87ftmlqfpl.fsf@wheatstone.g10code.de> References: <501932509.20190728141245@my_localhost_LG> <87pnltt0px.fsf@fifthhorseman.net> <87ftmlqfpl.fsf@wheatstone.g10code.de> Message-ID: <87sgqlqalq.fsf@fifthhorseman.net> On Thu 2019-08-01 13:37:26 +0200, Werner Koch wrote: > The user ID is important because the accompanying self-signature conveys > important information about the keyblock. For example expiration date > and preferences. It is true that this can also be conveyed with > direct-key-signatures (a self-signature directly on a key which was > mainly introduced for dedicated revocations). However, this is a not so > well tested feature of gpg and my educated guess is that many other > OpenPGP implementations do not handle direct-key signatures in a way > compatible to pgp or gpg - if at all. Thus by relying on them we would > sail into uncharted waters. We're already in uncharted waters with the inevitable abuse of SKS, we need to figure out how to stabilize the ecosystem. >> Doing such a merge would be super helpful, particularly for receiving >> things like subkey updates and revocation information from > > I agree that we can add a code path to import a primary key plus > revocation certificate but without user-ids. PGP however, does not > support this and is the reason why we extended the revocation > certifciate with a minmal primary key. If the PGP implementation of OpenPGP has bugs or doesn't behave well in the context of a minimized/stripped certificate, let's ask them to fix those bugs. The bugs in how that implementation interprets data are irrelevant to data that > Update of subkeys is a different issue and I see no solid use case for > allowing that without user-id (cf. expiration date of the primary key). Here's one use case (i've got others if you want): * You have my OpenPGP certificate (with userid with e-mail address), but it is not published in full publicly because i do not want people to be able to find anything related to my e-mail address online. * It has an encryption-capable subkey "X" that expires in 1 year, which i use to be able to have deletable messages. I will destroy the secret component when X expires. * As the year draws to a close, i create a new subkey "Y" and i attach it to my OpenPGP certificate, and i push the updated certificate to an abuse-resistant keystore (like keys.openpgp.org), again declining to allow it to publish my e-mail address. * After the expiration of "X", you want to send me an encrypted mail (as is your habit when mailing me). You follow best practices and refresh your keyring (fetching certificate updates by primary key fingerprint) from a public, abuse-resistant keystore. Does your OpenPGP implementation learn about "Y" when it pulls in the update? It should. If it does not, you will end up sending me cleartext e-mail, pointlessly, because your local client had the opportunity to know (for certain -- with cryptographically-verifiable evidence!) that a non-expired encryption-capable subkey was available, associated with the given primary key. Regards, --dkg -------------- 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 Aug 1 17:46:39 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Aug 2019 17:46:39 +0200 Subject: Commands supported by extra socket In-Reply-To: <20190726102719.GC24622@chikyu> (Vijai Kumar K. via Gnupg-users's message of "Fri, 26 Jul 2019 15:57:19 +0530") References: <20190726102719.GC24622@chikyu> Message-ID: <87blx8riqo.fsf@wheatstone.g10code.de> On Fri, 26 Jul 2019 15:57, gnupg-users at gnupg.org said: > Where can I find information on what commands are supported by > S.gpg-agent and S.gpg-agent.extra socket? I am looking for some > information which clearly differentiates these two sockets. Here is an overview on the allowed commands for the S.gpg-agent.extra and S.gpg-agent.browser. Only the commands required for perform a signature creation or a decryption are possible via these sockets. It is for example not possible to list all known keys or to create a key. | Command | Allowed | Comment | |-------------------+---------+---------| | GETEVENTCOUNTER | no | | | ISTRUSTED | yes | | | HAVEKEY | yes | | | KEYINFO | no | | | SIGKEY | yes | | | SETKEY | yes | | | SETKEYDESC | yes | | | SETHASH | yes | | | PKSIGN | yes | | | PKDECRYPT | yes | | | GENKEY | no | | | READKEY | no | | | GET_PASSPHRASE | no | | | PRESET_PASSPHRASE | no | | | CLEAR_PASSPHRASE | no | | | GET_CONFIRMATION | no | | | LISTTRUSTED | no | | | MARKTRUSTED | no | | | LEARN | no | | | PASSWD | no | | | SCD | no | | | KEYWRAP_KEY | no | | | IMPORT_KEY | no | | | EXPORT_KEY | no | | | DELETE_KEY | no | | | GET_SECRET | no | | | PUT_SECRET | no | | | GETVAL | no | | | PUTVAL | no | | | UPDATESTARTUPTTY | no | | | KILLAGENT | no | | | RELOADAGENT | no | | | KEYTOCARD | no | | | GETINFO | no | see 1 | | OPTION | no | see 2 | |-------------------+---------+---------| 1) except for the sub-commands: "version", "cmd_has_option", "s2k_count", "restricted". 2) except for the option: "agent-awareness" 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 tlikonen at iki.fi Thu Aug 1 19:18:23 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 01 Aug 2019 20:18:23 +0300 Subject: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information In-Reply-To: <87sgqlqalq.fsf@fifthhorseman.net> References: <501932509.20190728141245@my_localhost_LG> <87pnltt0px.fsf@fifthhorseman.net> <87ftmlqfpl.fsf@wheatstone.g10code.de> <87sgqlqalq.fsf@fifthhorseman.net> Message-ID: <87blx8ztwg.fsf@iki.fi> Daniel Kahn Gillmor via Gnupg-users [2019-08-01T09:27:45-04] wrote: > Here's one use case (i've got others if you want): > > * You have my OpenPGP certificate (with userid with e-mail address), > but it is not published in full publicly because i do not want people > to be able to find anything related to my e-mail address online. > > * It has an encryption-capable subkey "X" that expires in 1 year, which > i use to be able to have deletable messages. I will destroy the > secret component when X expires. > > * As the year draws to a close, i create a new subkey "Y" and i attach > it to my OpenPGP certificate, and i push the updated certificate to > an abuse-resistant keystore (like keys.openpgp.org), again declining > to allow it to publish my e-mail address. > > * After the expiration of "X", you want to send me an encrypted mail > (as is your habit when mailing me). You follow best practices and > refresh your keyring (fetching certificate updates by primary key > fingerprint) from a public, abuse-resistant keystore. Does your > OpenPGP implementation learn about "Y" when it pulls in the update? > It should. To me this sounds very relevant use case and adds one more feature to the general OpenPGP system. I hope future implementations support exporting and importing (merging) also partial key block data. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tlikonen at iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 694 bytes Desc: not available URL: From david at gbenet.com Thu Aug 1 21:46:19 2019 From: david at gbenet.com (David) Date: Thu, 1 Aug 2019 20:46:19 +0100 Subject: skipped packet 12 Message-ID: Hello, Do you have any ideas why am getting multiple lines of: gpg: skipped packet of type 12 in keybox Thanks David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com From playfair at riseup.net Thu Aug 1 20:16:34 2019 From: playfair at riseup.net (Playfair) Date: Thu, 1 Aug 2019 14:16:34 -0400 Subject: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information In-Reply-To: <87ftmlqfpl.fsf@wheatstone.g10code.de> References: <501932509.20190728141245@my_localhost_LG> <87pnltt0px.fsf@fifthhorseman.net> <87ftmlqfpl.fsf@wheatstone.g10code.de> Message-ID: On 8/1/19 7:37 AM, Werner Koch via Gnupg-users wrote: > On Mon, 29 Jul 2019 09:43, gnupg-users at gnupg.org said: >> it that way", i think. Perhaps Werner can provide more background on >> why GnuPG is generally resistant to holding OpenPGP certificates that >> have no User ID at all in its local keyring. > > The user ID is important because the accompanying self-signature conveys > important information about the keyblock. For example expiration date > and preferences. It is true that this can also be conveyed with > direct-key-signatures (a self-signature directly on a key which was > mainly introduced for dedicated revocations). However, this is a not so > well tested feature of gpg and my educated guess is that many other > OpenPGP implementations do not handle direct-key signatures in a way > compatible to pgp or gpg - if at all. Thus by relying on them we would > sail into uncharted waters. > >> Doing such a merge would be super helpful, particularly for receiving >> things like subkey updates and revocation information from > > I agree that we can add a code path to import a primary key plus > revocation certificate but without user-ids. PGP however, does not > support this and is the reason why we extended the revocation > certifciate with a minmal primary key. > > Update of subkeys is a different issue and I see no solid use case for > allowing that without user-id (cf. expiration date of the primary key). Couldn't this issue be dealt with by the key server instead of by OpenPGP implementations? GnuPG can create and import keys having non-email-address user IDs. A string of more than 4 characters is acceptable. Anything remotely resembling an email address, e.g. x at y.xyz, is okay. If keys.openpgp.org won't publish a user ID other than a verified email address, is its only recourse to remove the user ID? Could it instead substitute the hex key ID, fingerprint or a dummy string like "User ID not verified"? If it can't, is there any benefit in publishing a mutilated key people can't use? Just reject it. Chuck -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Aug 1 21:58:56 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Aug 2019 21:58:56 +0200 Subject: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information In-Reply-To: <87sgqlqalq.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via Gnupg-users's message of "Thu, 01 Aug 2019 09:27:45 -0400") References: <501932509.20190728141245@my_localhost_LG> <87pnltt0px.fsf@fifthhorseman.net> <87ftmlqfpl.fsf@wheatstone.g10code.de> <87sgqlqalq.fsf@fifthhorseman.net> Message-ID: <87r264pshr.fsf@wheatstone.g10code.de> On Thu, 1 Aug 2019 09:27, gnupg-users at gnupg.org said: > We're already in uncharted waters with the inevitable abuse of SKS, we > need to figure out how to stabilize the ecosystem. Most businesses do not use public keyservers at all but use their internal PKI. > If the PGP implementation of OpenPGP has bugs or doesn't behave well in > the context of a minimized/stripped certificate, let's ask them to fix > those bugs. The bugs in how that implementation interprets data are Good luck. PGP is in maintenance mode and there won't be any updates. We even had layer-8 problems back in the times when Hal was still alive/unfrozen to get new OpenPGP features into PGP. In particular companies will hesitate to update their once purchased PGP. 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 david at gbenet.com Thu Aug 1 22:13:31 2019 From: david at gbenet.com (David) Date: Thu, 1 Aug 2019 21:13:31 +0100 Subject: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information In-Reply-To: References: <501932509.20190728141245@my_localhost_LG> <87pnltt0px.fsf@fifthhorseman.net> <87ftmlqfpl.fsf@wheatstone.g10code.de> Message-ID: <1449617d-da8a-c045-ce37-d38a11f642e7@gbenet.com> Playfair via Gnupg-users: > On 8/1/19 7:37 AM, Werner Koch via Gnupg-users wrote: >> On Mon, 29 Jul 2019 09:43, gnupg-users at gnupg.org said: >>> it that way", i think. Perhaps Werner can provide more background on >>> why GnuPG is generally resistant to holding OpenPGP certificates that >>> have no User ID at all in its local keyring. >> >> The user ID is important because the accompanying self-signature conveys >> important information about the keyblock. For example expiration date >> and preferences. It is true that this can also be conveyed with >> direct-key-signatures (a self-signature directly on a key which was >> mainly introduced for dedicated revocations). However, this is a not so >> well tested feature of gpg and my educated guess is that many other >> OpenPGP implementations do not handle direct-key signatures in a way >> compatible to pgp or gpg - if at all. Thus by relying on them we would >> sail into uncharted waters. >> >>> Doing such a merge would be super helpful, particularly for receiving >>> things like subkey updates and revocation information from >> >> I agree that we can add a code path to import a primary key plus >> revocation certificate but without user-ids. PGP however, does not >> support this and is the reason why we extended the revocation >> certifciate with a minmal primary key. >> >> Update of subkeys is a different issue and I see no solid use case for >> allowing that without user-id (cf. expiration date of the primary key). > > Couldn't this issue be dealt with by the key server instead of by > OpenPGP implementations? GnuPG can create and import keys having > non-email-address user IDs. A string of more than 4 characters is > acceptable. Anything remotely resembling an email address, e.g. > x at y.xyz, is okay. > > If keys.openpgp.org won't publish a user ID other than a verified email > address, is its only recourse to remove the user ID? Could it instead > substitute the hex key ID, fingerprint or a dummy string like "User ID > not verified"? If it can't, is there any benefit in publishing a > mutilated key people can't use? Just reject it. > > Chuck > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Why upload a key to a keyserver with no email address? What's the point of doing that? You cant send an encrypted email to it - unless your given the email first -will it work to encrypt to a publlic key with no email? I got 180 public keys - some are very weird (I should delete them) some keys are for signing some sub keys are for encrypting and some sub keys decryption - why not make a key that does it all with a oad of sub keys? Keyservers should have strict rules on public keys - all to have a valid email a validation email sent back - then confirmed and that public key is then available. No identity available - simple - reject the key. Users of gpg that want to create weird and wonderful keys need to keep them on their own laptop or desktop - keyservers should be able to purge off these keys then keyservers would be back to what was intended. David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com From vijaikumar.kanagarajan at gmail.com Fri Aug 2 03:29:51 2019 From: vijaikumar.kanagarajan at gmail.com (vijai kumar) Date: Fri, 2 Aug 2019 06:59:51 +0530 Subject: Commands supported by extra socket In-Reply-To: <87blx8riqo.fsf@wheatstone.g10code.de> References: <20190726102719.GC24622@chikyu> <87blx8riqo.fsf@wheatstone.g10code.de> Message-ID: On Thu 1 Aug, 2019, 9:20 PM Werner Koch, wrote: > On Fri, 26 Jul 2019 15:57, gnupg-users at gnupg.org said: > > > Where can I find information on what commands are supported by > > S.gpg-agent and S.gpg-agent.extra socket? I am looking for some > > information which clearly differentiates these two sockets. > > Here is an overview on the allowed commands for the S.gpg-agent.extra > and S.gpg-agent.browser. Only the commands required for perform a > signature creation or a decryption are possible via these sockets. It is > for example not possible to list all known keys or to create a key. > > | Command | Allowed | Comment | > |-------------------+---------+---------| > | GETEVENTCOUNTER | no | | > | ISTRUSTED | yes | | > | HAVEKEY | yes | | > | KEYINFO | no | | > | SIGKEY | yes | | > | SETKEY | yes | | > | SETKEYDESC | yes | | > | SETHASH | yes | | > | PKSIGN | yes | | > | PKDECRYPT | yes | | > | GENKEY | no | | > | READKEY | no | | > | GET_PASSPHRASE | no | | > | PRESET_PASSPHRASE | no | | > | CLEAR_PASSPHRASE | no | | > | GET_CONFIRMATION | no | | > | LISTTRUSTED | no | | > | MARKTRUSTED | no | | > | LEARN | no | | > | PASSWD | no | | > | SCD | no | | > | KEYWRAP_KEY | no | | > | IMPORT_KEY | no | | > | EXPORT_KEY | no | | > | DELETE_KEY | no | | > | GET_SECRET | no | | > | PUT_SECRET | no | | > | GETVAL | no | | > | PUTVAL | no | | > | UPDATESTARTUPTTY | no | | > | KILLAGENT | no | | > | RELOADAGENT | no | | > | KEYTOCARD | no | | > | GETINFO | no | see 1 | > | OPTION | no | see 2 | > |-------------------+---------+---------| > > 1) except for the sub-commands: > "version", "cmd_has_option", "s2k_count", "restricted". > 2) except for the option: > "agent-awareness" > > > Thank you Werner!! Best, Vijai Kumar K > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Aug 2 09:47:24 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Aug 2019 09:47:24 +0200 Subject: skipped packet 12 In-Reply-To: (David's message of "Thu, 1 Aug 2019 20:46:19 +0100") References: Message-ID: <87k1bwovoz.fsf@wheatstone.g10code.de> On Thu, 1 Aug 2019 20:46, david at gbenet.com said: > Do you have any ideas why am getting multiple lines of: > gpg: skipped packet of type 12 in keybox You gpg version is older than 2.1.20 but you used a newer version on that keybox too. 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 playfair at riseup.net Fri Aug 2 13:50:15 2019 From: playfair at riseup.net (Playfair) Date: Fri, 2 Aug 2019 07:50:15 -0400 Subject: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information In-Reply-To: <1449617d-da8a-c045-ce37-d38a11f642e7@gbenet.com> References: <501932509.20190728141245@my_localhost_LG> <87pnltt0px.fsf@fifthhorseman.net> <87ftmlqfpl.fsf@wheatstone.g10code.de> <1449617d-da8a-c045-ce37-d38a11f642e7@gbenet.com> Message-ID: <82c0f777-7112-8af7-6fa7-01b43a2ba45f@riseup.net> On 8/1/19 4:13 PM, David wrote: > Playfair via Gnupg-users: >> If keys.openpgp.org won't publish a user ID other than a verified email >> address, is its only recourse to remove the user ID? Could it instead >> substitute the hex key ID, fingerprint or a dummy string like "User ID >> not verified"? If it can't, is there any benefit in publishing a >> mutilated key people can't use? Just reject it. > > Why upload a key to a keyserver with no email address? What's the point > of doing that? The point of doing that is to permit people who obtain my key through other channels, say directly from me, to periodically refresh it. When I revoke my key or change the expiration date, the fact will be communicated to holders of my public key, at least to those who refresh their key rings. > You cant send an encrypted email to it - unless your > given the email first -will it work to encrypt to a publlic key with no > email? Of course it works. A correspondent has only to select my public key when sending me email. Easier still is for her to create an Enigmail PRR associating my key with my email address or addresses. That makes key selection automatic. > Keyservers should have strict rules on public keys - all to have a valid > email a validation email sent back - then confirmed and that public key > is then available. No identity available - simple - reject the key. Sounds to me like you expect a key server to double as a CA. Chuck -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Fri Aug 2 16:17:04 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Fri, 2 Aug 2019 15:17:04 +0100 Subject: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information In-Reply-To: <82c0f777-7112-8af7-6fa7-01b43a2ba45f@riseup.net> References: <501932509.20190728141245@my_localhost_LG> <87pnltt0px.fsf@fifthhorseman.net> <87ftmlqfpl.fsf@wheatstone.g10code.de> <1449617d-da8a-c045-ce37-d38a11f642e7@gbenet.com> <82c0f777-7112-8af7-6fa7-01b43a2ba45f@riseup.net> Message-ID: <4122122.20190802151704@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 2 August 2019 at 12:50:15 PM, in , Playfair via Gnupg-users wrote:- > Easier still is for her to > create an Enigmail > PRR associating my key with my email address Or a group line in gpg.conf. - -- Best regards MFPA A nod is as good as a wink to a blind bat! -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXURF4F8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +sMaAP9i+ePlpJTH1ZN+I7sBkknt+pZrl9ZqP3l6jaENs4/AiAD+IP2p6/o6DifW wP2SjElIVEcjifQw8qVNGNXKpZ/5swaJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXURF4F8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/xwSD/4trT0wv4p99bTCqqhf0QkOIkfG xFgAAgoKcPvO89L8sX22qPqfLDYAYNZWiNl+DSY2WbuAclZfScokMzZbboIFpUgl agZxicgZHJm/VbwmzPF2NHMNoj5Pzo54VU0SRBBuLSVFMS2h3+AB+rtUlby7wDEl prz0R9PoL1TnXHzqQeQ5DmrWFB+yeA+4wbfl1R50C4y0eZExqijA1jl/g1c7jODh J2v4MDxatiV4b8qaRKSA+rZWk63RnVLaIIl1BMPxHtCEl/y7qWGRQBQhWM5Yawrz 9wKLDYsJfym1HzwOWYPJWIHm4ypn5b8a5lQ4vH6cide4RziNLZgxb/FxwrPF8M69 g6wdvuTfnpBoObnjJiGwyJr7+9VfeYKcGwHPLJ9q7WErQe8buROf063Te6tgIdnC 0XU2AA5ZOflYGX1BsmcadX7aSCXtG0IB10V56MPz3s1vyAaSHc1jdx6SftMwi9kb bkmsUyccqhAKJsn/wtIM0QYCs8vQ3mdZAKcs8j3LbdTBhWvcodonNUew6CNdkbmZ zA92mgqnoO/OCYNqDET0US1UmD2/aG1TdBZfYlAcZ+5AG6VZOhTSR4FnLUKTyLZK dHjd6qaKU8ghBwsOqo4r0TLtwN6ZWeBr2HIDBOyjmW3vxtx8aaLkDSgeZXMaSfra fsLIJyO25XyE0dScuQ== =M0TI -----END PGP SIGNATURE----- From wk at gnupg.org Sun Aug 4 11:43:31 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 04 Aug 2019 11:43:31 +0200 Subject: About support of RFC 2437, 4056 and 6979 In-Reply-To: (Persmule's message of "Sat, 20 Jul 2019 10:07:41 +0000") References: Message-ID: <87r261nu4c.fsf@wheatstone.g10code.de> On Sat, 20 Jul 2019 10:07, persmule at hardenedlinux.org said: > Does GnuPG support OAEP for RSA (PKCS#1 v2 and RFC 2437), RSA-PSS (RFC gpg does not support this because OpenPGP requires pkcs-1.5. There are no plans to change this because there is not real world issue with pcsc-15. when using in the way OpenPGP uses it. > 4056?), or deterministic usage of (EC)DSA (RFC 6979)? That is an implementation detail: gpg uses rfc-6979 since version 2.0.23 when it requires the use of Libgcrypt 1.6 implements this feature. > And if GnuPG does support RFC 6979, would it also work with (EC)DSA > private keys stored on OpenPGP cards which support (EC)DSA algorithms? Yes for on-disk keys. For cards it depends on the specific card. Note that we suggest the use of EdDSA with Curve25519 instead of ECDSA. 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 Sun Aug 4 18:19:25 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 4 Aug 2019 18:19:25 +0200 Subject: Zero Knowledge Proofs to detect possible MITM attacks Message-ID: <20190804181925.00001b98.sac@300baud.de> Hi all, I recently read about ZKPs and was wondering if some of you have used them in the past. I ask because I think (once met in person) it would be a good method when using ZKPs addionally (maybe for the paranoid among us) with encrypted communications, where the involved parties may not be sure if their online computer is already compromised. The good think about ZKPs, as I have tested with one example code, is that they can be carried out on (scentific) poket calculators. Any thoughts or tips and tricks would be very welcome! Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From 76nemo76 at gmx.ch Sun Aug 4 20:15:08 2019 From: 76nemo76 at gmx.ch (Pierre Dupond) Date: Sun, 4 Aug 2019 20:15:08 +0200 Subject: Two tests fail in libgcrypt Message-ID: <6bd7eac7-9aa4-f105-4f6c-f95de28c902e@gmx.ch> Hi All, ?????????? As you can see in the attached log, two tests fail on my machine after I have compiled without error (and without optimisation) "libgcrypt". The test of gpg (with this library) seems to succeed. But I would know what are these tests and if their failure is a big problem. Thanks for your help, best regards, --------------------------------------------------------------Partial log of the check--------------------------------------------- root at oche:/var/tmp/gpg/libgcrypt-1.8.4 # gmake check Making check in compat gmake[1]: Entering directory '/var/tmp/gpg/libgcrypt-1.8.4/compat' gmake[1]: Nothing to be done for 'check'. gmake[1]: Leaving directory '/var/tmp/gpg/libgcrypt-1.8.4/compat' Making check in mpi gmake[1]: Entering directory '/var/tmp/gpg/libgcrypt-1.8.4/mpi' gmake[1]: Nothing to be done for 'check'. gmake[1]: Leaving directory '/var/tmp/gpg/libgcrypt-1.8.4/mpi' Making check in cipher gmake[1]: Entering directory '/var/tmp/gpg/libgcrypt-1.8.4/cipher' gmake[1]: Nothing to be done for 'check'. gmake[1]: Leaving directory '/var/tmp/gpg/libgcrypt-1.8.4/cipher' Making check in random gmake[1]: Entering directory '/var/tmp/gpg/libgcrypt-1.8.4/random' gmake[1]: Nothing to be done for 'check'. gmake[1]: Leaving directory '/var/tmp/gpg/libgcrypt-1.8.4/random' Making check in src gmake[1]: Entering directory '/var/tmp/gpg/libgcrypt-1.8.4/src' gmake[1]: Nothing to be done for 'check'. gmake[1]: Leaving directory '/var/tmp/gpg/libgcrypt-1.8.4/src' Making check in doc gmake[1]: Entering directory '/var/tmp/gpg/libgcrypt-1.8.4/doc' gmake? check-am gmake[2]: Entering directory '/var/tmp/gpg/libgcrypt-1.8.4/doc' gmake[2]: Nothing to be done for 'check-am'. gmake[2]: Leaving directory '/var/tmp/gpg/libgcrypt-1.8.4/doc' gmake[1]: Leaving directory '/var/tmp/gpg/libgcrypt-1.8.4/doc' Making check in tests gmake[1]: Entering directory '/var/tmp/gpg/libgcrypt-1.8.4/tests' gmake? check-TESTS gmake[2]: Entering directory '/var/tmp/gpg/libgcrypt-1.8.4/tests' version:1.8.4:10804:1.36:12400: cc:90100:gcc:9.1.0: ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2: rnd-mod:linux: cpu-arch:x86: mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S: hwflist:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-avx:intel-rdtsc: fips-mode:n:n: rng-type:standard:1:2010000:1: PASS: version t-secmem: line 176: gcry_control (GCRYCTL_INIT_SECMEM, pool_size, 0) failed: Erreur g?n?rale FAIL: t-secmem PASS: mpitests t-sexp: line 1174: gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0) failed: Erreur g?n?rale FAIL: t-sexp PASS: t-convert PASS: t-mpi-bit PASS: t-mpi-point PASS: curves PASS: t-lock PASS: prime PASS: basic PASS: keygen PASS: pubkey PASS: hmac PASS: hashtest PASS: t-kdf PASS: keygrip PASS: fips186-dsa PASS: aeswrap PASS: pkcs1v2 PASS: random PASS: dsa-rfc6979 ????? 256 of 1026 tests done ????? 512 of 1026 tests done ????? 768 of 1026 tests done ????? 1024 of 1026 tests done ????? 1026 tests done PASS: t-ed25519 ????? 18 tests done PASS: t-cv25519 ????? now running 'basic' test with all hardware features disabled. PASS: basic-disable-all-hwf ?????????? . ?????????? . ?????????? . PASS: bench-slope SKIP: hashtest-256g ====================================== 2 of 27 tests failed (1 test was not run) Please report to http://bugs.gnupg.org ====================================== gmake[2]: *** [Makefile:864: check-TESTS] Error 1 gmake[2]: Leaving directory '/var/tmp/gpg/libgcrypt-1.8.4/tests' gmake[1]: *** [Makefile:987: check-am] Error 2 gmake[1]: Leaving directory '/var/tmp/gpg/libgcrypt-1.8.4/tests' gmake: *** [Makefile:488: check-recursive] Error 1 r From sac at 300baud.de Thu Aug 8 17:22:47 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 8 Aug 2019 17:22:47 +0200 Subject: BSI withdraws approval of GnuPG for confidential documents Message-ID: <20190808172247.00001665.sac@300baud.de> Hi, maybe interesting for some community members, living in Germany. (Article is in German language.) Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From contact at sciss.de Thu Aug 8 16:44:19 2019 From: contact at sciss.de (Hanns Holger Rutz) Date: Thu, 8 Aug 2019 16:44:19 +0200 Subject: Cannot upload updated public keys - "Server indicated a failure" Message-ID: <76e65057-5aa8-2590-0a75-48ff8ffaf374@sciss.de> hello, disclaimer: gpg is a periphery piece of software in my life. please don't assume that i'm going to unwind my computer because of this. i sign emails and software with a gpg key. i had to extent its expiry now. i cannot upload the updated keys: $ gpg --send-keys 7437FCBA03E4CB85 gpg: sending key 7437FCBA03E4CB85 to hkp://keys.gnupg.net gpg: keyserver send failed: Server indicated a failure gpg: keyserver send failed: Server indicated a failure i tried various other URLs known to me, same effect. i'm on debian stretch with gpg 2.1.18. i cannot update my distribution at this moment. i need to publish my updated key with reasonable effort. enigmail also won't upload the keys. thanks for you help! best, .h.h. -------------- 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 Thu Aug 8 20:26:33 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Aug 2019 20:26:33 +0200 Subject: BSI withdraws approval of GnuPG for confidential documents In-Reply-To: <20190808172247.00001665.sac@300baud.de> (Stefan Claas via Gnupg-users's message of "Thu, 8 Aug 2019 17:22:47 +0200") References: <20190808172247.00001665.sac@300baud.de> Message-ID: <87lfw3h5t2.fsf@wheatstone.g10code.de> On Thu, 8 Aug 2019 17:22, gnupg-users at gnupg.org said: > maybe interesting for some community members, living in Germany. We learned about that last week and are trying to figure out what is going on. It is likely an internal coordination or content admin problem at the BSI. We do not know about any technical problems. 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 jhs at berklix.com Fri Aug 9 00:18:08 2019 From: jhs at berklix.com (Julian H. Stacey) Date: Fri, 09 Aug 2019 00:18:08 +0200 Subject: BSI withdraws approval of GnuPG for confidential documents In-Reply-To: Your message "Thu, 08 Aug 2019 17:22:47 +0200." <20190808172247.00001665.sac@300baud.de> Message-ID: <201908082218.x78MI8AK002064@fire.js.berklix.net> Stefan Claas via Gnupg-users wrote: > Hi, > > maybe interesting for some community members, living in Germany. > (Article is in German language.) > > https://translate.google.com/translate?hl=&sl=de&tl=en&u=https%3A%2F%2Fwww.heise.de%2Fnewsticker%2Fmeldung%2FBSI-zieht-Zulassung-von-GnuPG-fuer-vertrauliche-Dokumente-zurueck-4489547.html "BSI withdraws authorization from GnuPG for confidential documents The Federal Office for Information Security has tacitly withdrawn the approval of Gpg4win for confidential documents. ...." Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent 700,000 Brexit votes stolen from British in EU; 2.4 M UK young had no vote; 1.6 M died; Lies paid & fined. Treason to threaten parliament to prorogue it. http://stolenvotes.uk From contact at sciss.de Fri Aug 9 06:09:50 2019 From: contact at sciss.de (Hanns Holger Rutz) Date: Fri, 9 Aug 2019 06:09:50 +0200 Subject: Cannot upload updated public keys - "Server indicated a failure" In-Reply-To: <76e65057-5aa8-2590-0a75-48ff8ffaf374@sciss.de> References: <76e65057-5aa8-2590-0a75-48ff8ffaf374@sciss.de> Message-ID: <9bb4fa87-a5ac-b3a3-5830-eaf28c7dfa45@sciss.de> updating to gpg 2.2.12 fixed this On 08/08/2019 16:44, Hanns Holger Rutz wrote: > hello, > > disclaimer: gpg is a periphery piece of software in my life. please > don't assume that i'm going to unwind my computer because of this. > > i sign emails and software with a gpg key. i had to extent its expiry > now. i cannot upload the updated keys: > > $ gpg --send-keys 7437FCBA03E4CB85 > gpg: sending key 7437FCBA03E4CB85 to hkp://keys.gnupg.net > gpg: keyserver send failed: Server indicated a failure > gpg: keyserver send failed: Server indicated a failure > > i tried various other URLs known to me, same effect. i'm on debian > stretch with gpg 2.1.18. i cannot update my distribution at this moment. > i need to publish my updated key with reasonable effort. > > enigmail also won't upload the keys. > > thanks for you help! > > best, .h.h. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mixmaster at remailer.privacy.at Sun Aug 11 23:47:47 2019 From: mixmaster at remailer.privacy.at (Anonymous Remailer (austria)) Date: Sun, 11 Aug 2019 23:47:47 +0200 (CEST) Subject: PGP Key Poisoner Message-ID: https://github.com/skeeto/pgp-poisoner From juergen at bruckner.tk Mon Aug 12 13:25:37 2019 From: juergen at bruckner.tk (Juergen Bruckner) Date: Mon, 12 Aug 2019 13:25:37 +0200 Subject: PGP Key Poisoner In-Reply-To: References: Message-ID: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> Thats pretty interesting, but the author also says he did this as showcase. Nontheless, its not really good to have such a tool "in the wild", and even on a plattform like GitHub regards Juergen Am 11.08.19 um 23:47 schrieb Anonymous Remailer (austria): > > https://github.com/skeeto/pgp-poisoner > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From playfair at riseup.net Mon Aug 12 13:54:00 2019 From: playfair at riseup.net (Playfair) Date: Mon, 12 Aug 2019 11:54:00 +0000 Subject: PGP Key Poisoner In-Reply-To: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> Message-ID: Juergen Bruckner via Gnupg-users wrote: > Thats pretty interesting, but the author also says he did this as showcase. > Nontheless, its not really good to have such a tool "in the wild", and > even on a plattform like GitHub A tool like this has been in the wild for several weeks. As skeeto says "Further, this attack has been known for years, and in 2019 it's been used against real keys on keyservers. This tool is nothing new and does not create any new capabilities. It's merely proof that such attacks are very easy to pull off. It doesn't take a nation-state actor to break the PGP ecosystem, just one person and couple evenings studying RFC 4880. This system is not robust." One wonders why an attack that's been known for years is only being addressed now that it has been used. > Am 11.08.19 um 23:47 schrieb Anonymous Remailer (austria): >> >> https://github.com/skeeto/pgp-poisoner >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From david at gbenet.com Mon Aug 12 14:09:59 2019 From: david at gbenet.com (David) Date: Mon, 12 Aug 2019 13:09:59 +0100 Subject: PGP Key Poisoner In-Reply-To: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> Message-ID: <837da0a8-e8a6-8415-3961-95a0e2a4c805@gbenet.com> On 12/08/2019 12:25, Juergen Bruckner via Gnupg-users wrote: > Thats pretty interesting, but the author also says he did this as showcase. > Nontheless, its not really good to have such a tool "in the wild", and > even on a plattform like GitHub > > regards > Juergen > > Am 11.08.19 um 23:47 schrieb Anonymous Remailer (austria): >> >> https://github.com/skeeto/pgp-poisoner >> >> _______________________________________________ >> 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 > To be frank - putting this code on Github whist demonstrating a point - was foolish - it put's the code out into the wild - and some silly smart arse is going to play. It also begs the question - who did the attacks on SKS keyservers? "I have katana and I just wanted to demonstrate cutting people's head's of because I can." But am not going to accept the responsibility and be accountable for my actions. Such a position is untenable in Law and in ethics. There are hundreds of thousands of people globally who are employed paid by their respective intelligence agencies to write malicious code. They hide behind the fact that they are paid - it's just a day-time 9 to 5 job - and have no sense of responsibility or accountability working in contravention of their own countries laws. Now you have put the code into the public domain - to prove a point? The justification and points hardly support an ethical just standpoint. To say that this was in practice and common knowledge for years - it's new to me and many thousands of pgp users. Many thousands of people got infected - and had no thought to back up their king rings and have to start all over again. Just because one can develop a nuclear bomb - it proves real stupidity to drop it on an unsuspecting public. Be Happy! David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From look at my.amazin.horse Mon Aug 12 14:35:11 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Mon, 12 Aug 2019 14:35:11 +0200 Subject: PGP Key Poisoner In-Reply-To: <837da0a8-e8a6-8415-3961-95a0e2a4c805@gbenet.com> References: <837da0a8-e8a6-8415-3961-95a0e2a4c805@gbenet.com> <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> Message-ID: <38GRSKLYUS7YY.2TWXXDP249LN0@my.amazin.horse> > To be frank - putting this code on Github whist demonstrating a point - > was foolish No it's not. It is the basis of cryptograhpy. See also: https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle > Now you have put the code into the public domain - to prove a point? Yes. And that point is that some of our security was built on obscurity. See also: https://en.wikipedia.org/wiki/Shooting_the_messenger - V From schinzel at fh-muenster.de Mon Aug 12 12:59:08 2019 From: schinzel at fh-muenster.de (Sebastian Schinzel) Date: Mon, 12 Aug 2019 12:59:08 +0200 Subject: Repo with test cases for covert content attacks Message-ID: Dear all, Jens M?ller just gave a talk at DEFCON about Covert Content Attacks against S/MIME and OpenPGP encryption and digital signatures in the email context. He just published the PoC emails that he used in the talk and they might be useful for further testing. https://github.com/RUB-NDS/Covert-Content-Attacks This is the paper describing the attacks from April 2019: https://arxiv.org/abs/1904.07550 Best, Sebastian From raubvogel at gmail.com Mon Aug 12 14:37:39 2019 From: raubvogel at gmail.com (Mauricio Tavares) Date: Mon, 12 Aug 2019 08:37:39 -0400 Subject: PGP Key Poisoner In-Reply-To: <837da0a8-e8a6-8415-3961-95a0e2a4c805@gbenet.com> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <837da0a8-e8a6-8415-3961-95a0e2a4c805@gbenet.com> Message-ID: On Mon, Aug 12, 2019 at 8:10 AM David wrote: > > On 12/08/2019 12:25, Juergen Bruckner via Gnupg-users wrote: > > Thats pretty interesting, but the author also says he did this as showcase. > > Nontheless, its not really good to have such a tool "in the wild", and > > even on a plattform like GitHub > > > > regards > > Juergen > > > > Am 11.08.19 um 23:47 schrieb Anonymous Remailer (austria): > >> > >> https://github.com/skeeto/pgp-poisoner > >> > >> _______________________________________________ > >> 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 > > > To be frank - putting this code on Github whist demonstrating a point - > was foolish - it put's the code out into the wild - and some silly smart > arse is going to play. > > It also begs the question - who did the attacks on SKS keyservers? "I > have katana and I just wanted to demonstrate cutting people's head's of > because I can." But am not going to accept the responsibility and be > accountable for my actions. Such a position is untenable in Law and in > ethics. > > There are hundreds of thousands of people globally who are employed paid > by their respective intelligence agencies to write malicious code. They > hide behind the fact that they are paid - it's just a day-time 9 to 5 > job - and have no sense of responsibility or accountability working in > contravention of their own countries laws. > > Now you have put the code into the public domain - to prove a point? The > justification and points hardly support an ethical just standpoint. To > say that this was in practice and common knowledge for years - it's new > to me and many thousands of pgp users. Many thousands of people got > infected - and had no thought to back up their king rings and have to > start all over again. > I take you are against CVE lists. > Just because one can develop a nuclear bomb - it proves real stupidity > to drop it on an unsuspecting public. > > Be Happy! > > David > > -- > People Should Not Be Afraid Of Their Government - Their Government > Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION > Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" > https://gbenet.com > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From abbot at monksofcool.net Mon Aug 12 16:47:03 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Mon, 12 Aug 2019 16:47:03 +0200 Subject: PGP Key Poisoner In-Reply-To: <837da0a8-e8a6-8415-3961-95a0e2a4c805@gbenet.com> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <837da0a8-e8a6-8415-3961-95a0e2a4c805@gbenet.com> Message-ID: <87sgq6l9ug.fsf@ra.horus-it.com> * david at gbenet.com: > putting this code on Github whist demonstrating a point - was foolish No, it was not. Foolish would be to pretend the conceptual flaw does not exist, cover your ears with your hands and go "la la la". > To say that this was in practice and common knowledge for years - it's > new to me and many thousands of pgp users. Are you suggesting that people "in the know" should let people with a potentially harmful lack of knowledge stay blissfully unaware? What good would that do? > People Should Not Be Afraid Of Their Government - Their Government > Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION > Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" I think that, in light of your message, is quite a ridiculous signature. https://gbenet.com advertises itself as a "Capitalist Free Website For Free Thinkers!" stating "I have no ''beliefs'' no secret agenda's [sic] - other than to bring you knowledge which you may not be aware of". Well, some knowledge was brought to you via GitHub, so enjoy. :-) -Ralph From sac at 300baud.de Mon Aug 12 16:54:34 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 12 Aug 2019 16:54:34 +0200 Subject: PGP Key Poisoner In-Reply-To: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> Message-ID: <20190812165434.00006251.sac@300baud.de> Juergen Bruckner via Gnupg-users wrote: > Thats pretty interesting, but the author also says he did this as showcase. > Nontheless, its not really good to have such a tool "in the wild", and > even on a plattform like GitHub AFAIK it is common pratice to publish PoCs to help program authors to improve or quickly fix their open source security software. Otherwise long standing issues may have been never fixed. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From ryan at digicana.com Mon Aug 12 17:44:28 2019 From: ryan at digicana.com (Ryan McGinnis) Date: Mon, 12 Aug 2019 15:44:28 +0000 Subject: PGP Key Poisoner In-Reply-To: <20190812165434.00006251.sac@300baud.de> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publicKey - ryan at digicana.com - 5c738727ee58786a777c4f1db5aa3fa3486ed7ad.as= c" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tClZlcnNpb246IFBt Y3J5cHRvIEdvbGFuZyAwLjAuMSAoZGRhY2ViZTApCkNvbW1lbnQ6IGh0dHBzOi8v cHJvdG9ubWFpbC5jb20KCnhzRk5CRm95d3BvQkVBQ0dsQ0x6dUl4UHR1VDYwQld3 K1luQ0V3NS9HbFhJeDVYNmwzTkpnRGlUL1FydjZtM0MKWDROSkVIY21VT3J1SWhS L2JJMFdrdnVXVjRSZnh2MEJLUWpwN0puTVdSRE9ZNU54SWNrdk1KR3BsTFRoY3lS agpLcUF2aXhTcnVrc3h0M3YzQTViNzdLeXcxZXlCMytlQzNZbzBnMjh5aGhmbG4x Z2V4enNVc3V6U1crRml4eGd6ClMyS2RKMjZhWjhTYjNnanZmSEx2L01LaFhsdVN3 WWdYSURLTWlVT2liMGlEVmRXUGZGWENwVmJIM28xOFZueFQKZEMzVUkzdlZtbEph clI0TzV4SXA2RndkbVFWdGo3M1pNSGRnWW5RY2VHWWN3b2I4dGFPMGRLZlUrMzEv Ymp1dQpNYU9qeTJ1S25DeDlsZWVLNEgxM0pjYkl5R1NLN2pyQWVRUk53RTU4VXpC SlpVQnMxSURjZFlZN1l2MW9iOWlNClljZmtaaHF6enREaksxUVAzSWJlM0FHMDJY K3JVWExjdmxoOEVjY0RiL1c1MElBK2VqRHk3eUZRYjZTSys0U3AKSXJaSEdQamYx eUQ0eGtraHpORlBKMm1ZR040aENDcm5XckRnL2hDM3J4U3dDcEkzUEV4bFo4T0Y5 ank5alR0cQpJUngvelhTUUtnSmNBRHM0dHNOSGZ6UHJuRXk0MWJzbWNkSTBOcm5j UGNmMjVqRnZhUFR3QkhBQ3lIbG1GWDJ6Ci9HdUNoZW9wYXhtaVZKRnVWbGVxcnR4 ZVRCTjR2NzlMaHhCR3RDVWRZSDlHcmVuRnZ6QTl2OFZNQTZyOWQ3YVcKQ2I3bDBK SEw4d3pEQk9sRENiSk1adlQ3dER4eWwyTUl2MTFMUWVJSW5SbEk2SkJ4TENGWnVo WVB6d0FSQVFBQgp6U1Z5ZVdGdVFHUnBaMmxqWVc1aExtTnZiU0E4Y25saGJrQmth V2RwWTJGdVlTNWpiMjArd3NGMUJCQUJDQUFwCkJRSmFNc0tnQmdzSkJ3Z0RBZ2tR dGFvL28waHUxNjBFRlFnS0FnTVdBZ0VDR1FFQ0d3TUNIZ0VBQUp5TEQvMFQKZUdG YmJ1TnlQZmxUb3NkbW1LQUM2Wnl1RHdKeExqdkwzWW5IQVVQa1RPL2E2eFR0RVoy QjQxL21PeDJPVGN5aApKaGh3dEIwL2xzU043cjVyWEh6VVc0VmU2R1NTOFBFSTNq MUl5TS93ZWN2MytnYjM4ZmZkRkVKQTFiVW45K2YvCnV5aFFJRmFMd0ZwcThVUUd4 RFJKOTFRWGNYRnJQemFsc3Y5S0tOY3QxdFJDbGZWblFSNzdCemtoZklKczJnUWkK eVQxbCtWRnF6WEFoVmlpdXpSZGxKTWFUTGIyMzZVa2VPeC9leU5WRWNpdlZZb3V5 MkJ6TC9kVzI4V0RQUHRkVgpIT2NWbVY0S2ZhWUpwSDRtQkhCL0tQK0pOUXk1c3BW Zk1MTWZDMDhyNWEwRUZFM0J5ZWJsdDNPTlBtKzJ5bXpDClJvdEl0ejhUN3Njd3U0 eFRtSXc1V1dSY0lpM21iRFcvbWVmbzd3aGJYM283TmlkUEJDK1pxSnNxTG9Obm8v YUQKUFlYbnBUekFiczRVVFNxcDZQNDlNSFZXTkY0L24vYVhVM1ZoQnZaeDBoMU5O TmJPMVB6Ui84U3I3ZmVkRDlVQwpuaUpOSmdmYUtodDFpMTlQYytCRjUrc2duYlJa ZUlmU3hIV2ZYRCtrcklXR1ptUkJhQnBHelIzSnIzQUF3Q2NECnVKVmVDWHhJZTE3 WlRIeXdxVlpsb1hGWEVSSkJUZm1KK0FEbjIrc0ZNanBkV0Jhd3NsNXhYLzlmZmlP WWY4aTAKbEdoNnZraWtCbkdaem5YSVp4Y3YvSVZpSHVnYlY3M3FwdktUaVpiME5o WDlhd3kybGJqcWRxZzR4UHhuMlJJbwpwaEY5VTNpYmxhcDRqSnJZMFo2NmdNUEhB b2VVWlVJa1crWjYzT1BJbE03QlRRUmFNc0thQVJBQWlSblptNHVjClBLc0ZEUG5N SjVWcUVkeE9LcVRhbGsxRDM3NzEyemovWjcwNjlaRkV6QnY5UkVUcU9qdmFCQ1ZU dExrWmpVS3UKQXQ5QVF3S0prcUhNbXpHVGdsVGt5cThEM0Z3cDExeVVoQm12M3lP ciswVjVNZUU2OUhNdXFpdHBPNWdYbW9NMQoyQ1VBUERzcWV0OEY4THN0RUpNYlJo cHh2T3NnbU1SV2dGbTVMNzRjeXFPVDQ0K01vOCt1THdldlBIMXBDN2JFCi9rTEVQ ZXdjQUUvNjBwUTBZZ1ZQMkxlNngyaHQ4Q3pEWjdwOGNTSGtYbEJhOXlIa1haUkV0 VStMMFdJSU0rM28KRjBycnhMeENpcmJjU2hOM1pFeHgra0xuTTJ6YjN4bUVRd1k2 YndsVXRIa25ub1ZwSmtaWFBjM21OSlFLYzA4NAorWEdnSWNQYXEwNTN2cElaa093 ZlFib292azZ4cG9sWkdmU254c1FTVnNCTFQ3WFlKR2UydjRTdExuS1UzRzFXCk1J aHk4TitzK1ArUHRPYytZRU9sNS82cmhiZUk2UkFsS21wcisvMGhFWG9lK0Z4USt0 Njc5TS9kR2ptRmM1YlIKVFl0b1k2YlpuaGpHYnZ0dWY0K3pmUFNudmFMOFFtd2Rj bjZYSFExVndCQmFVWXlqYUxJTCtOam1LSjdSWGhrawoyeUs0SU1iZDVYMFl1TDVm dVpnTXE5OUJTbkVtZ1B0QUhwQW9rci9sWXV0VW82NmhIUEQ5OWlBSUwxYUI5aU5l CmpqU0FjdWI1QThQMENaYWJNTWVsdmw5QnRXRGVHZ0d6K3lFQmlJN09MOHdaOUxn NjM0RTZRNjVIUmZBcUFiU2cKc0pyRmRHc0tKM3NuUXRhbGJ6UzJBaldVUnZWOW5T aHpuV3NBRVFFQUFjTEJYd1FZQVFnQUV3VUNXakxDb3drUQp0YW8vbzBodTE2MENH d3dBQU5qSkQvNDFRTmpkSkQ3VzNZR0RkRjd6SXlOMW5FME9WTElsaGh5WHZ4Mk5C UzlFCjhPMzM4V1dpbnMzekxJZTdCenFyNkhTSmdQZUxyRElJWi8rQ29aSW9aZm52 cEI2bllsbWdQME8zdUZuSnNQYysKTjVnc1E0cDEzZEF4QldWMVNBSmJtMDdyZ3VT RVMzNzlpdHdPTWFuSU9KTVNQTnhETHI4YUxLY2pKV0tqNWRnTgpvMEx1eWFYSjdI OU02MWMrMytUV25ZdWNBakZDQ2s3STcrRldtWHZ2OEgzVHBBeEF6K3FPYllKRDRS UDFaL3RSCjdtYVJyQU5NalVZY0lneVR2RzlsNDF2ZG1jR01lZDN4bTc3VS9Yek96 ZlVDbEVEbWFLMzlibU9HNEF1YzVSOHkKNjIrMkhJSS94cmE5V2VlaUlPZXNxTUVN NTB5NkFjUUVSVnAydDQyZjFucld5aU1KMkR6cVMyUlZwMHZiNWNsRApIK25XUUlM bGxuN1VBd09ONHJvaXpQZm5zeTRBOGdiTS9KcXlMazA1Vnl4WlEzWUNUZUJJcVJm anUyUndIM0l2CjRuZFBhaXBIUkY3R3dOZEdKWDJFYmJ4L1hyMHBLbUx3K0tKa211 ZEVuU0VqYUJTeFYwcml1N3dHUHZ6UVFhL3AKWTIrNmlzWDgxeVNibFlqakVwVCsz eDUvdmFzMDcxL3dNdlFaWmJrc29RT3dvZGxZSHFHellGOTlXbFoyMHJySgpnL1F4 R2VQS2xRU01jQWlYalhXUzI4bkYxY2xVZHRlUlNXM0JDbHJsbGcyNFlNNWRZL1ZC RDhzZWp5aERNVUI4CnA3NUNCa1JDTzZ4UlozcnJ5QXBqQTM0QnJlNnd0NlJOT1A5 V1VTYzFnbmhPaUk5K3E1a3oxc0JHWm9VRXRNTmsKZ1E9PQo9SXZXYQotLS0tLUVO RCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0t -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 839 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Mon Aug 12 17:47:44 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 12 Aug 2019 17:47:44 +0200 Subject: Repo with test cases for covert content attacks In-Reply-To: References: Message-ID: <20190812174744.000017c0.sac@300baud.de> Sebastian Schinzel wrote: > Dear all, > > Jens M?ller just gave a talk at DEFCON about Covert Content Attacks > against S/MIME and OpenPGP encryption and digital signatures in the > email context. He just published the PoC emails that he used in the talk > and they might be useful for further testing. > > https://github.com/RUB-NDS/Covert-Content-Attacks > > This is the paper describing the attacks from April 2019: > > https://arxiv.org/abs/1904.07550 Thanks for the info. I do no longer use a GPG plug-in MUA combination, but are these 'Johnny you are fired' issues already been resolved? I must admit I am a bit out of the loop. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From sac at 300baud.de Mon Aug 12 18:13:09 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 12 Aug 2019 18:13:09 +0200 Subject: PGP Key Poisoner In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> Message-ID: <20190812181309.0000784e.sac@300baud.de> Ryan McGinnis via Gnupg-users wrote: [snip] Not to be off-topic but I wonder why your message, when reading it in my MUA, displays this in the message body: Never seen this before on the ML. c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publicKey - ryan at digicana.com - 5c738727ee58786a777c4f1db5aa3fa3486ed7ad.as= c" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tClZlcnNpb246IFBt Y3J5cHRvIEdvbGFuZyAwLjAuMSAoZGRhY2ViZTApCkNvbW1lbnQ6IGh0dHBzOi8v cHJvdG9ubWFpbC5jb20KCnhzRk5CRm95d3BvQkVBQ0dsQ0x6dUl4UHR1VDYwQld3 K1luQ0V3NS9HbFhJeDVYNmwzTkpnRGlUL1FydjZtM0MKWDROSkVIY21VT3J1SWhS L2JJMFdrdnVXVjRSZnh2MEJLUWpwN0puTVdSRE9ZNU54SWNrdk1KR3BsTFRoY3lS agpLcUF2aXhTcnVrc3h0M3YzQTViNzdLeXcxZXlCMytlQzNZbzBnMjh5aGhmbG4x Z2V4enNVc3V6U1crRml4eGd6ClMyS2RKMjZhWjhTYjNnanZmSEx2L01LaFhsdVN3 WWdYSURLTWlVT2liMGlEVmRXUGZGWENwVmJIM28xOFZueFQKZEMzVUkzdlZtbEph clI0TzV4SXA2RndkbVFWdGo3M1pNSGRnWW5RY2VHWWN3b2I4dGFPMGRLZlUrMzEv Ymp1dQpNYU9qeTJ1S25DeDlsZWVLNEgxM0pjYkl5R1NLN2pyQWVRUk53RTU4VXpC SlpVQnMxSURjZFlZN1l2MW9iOWlNClljZmtaaHF6enREaksxUVAzSWJlM0FHMDJY K3JVWExjdmxoOEVjY0RiL1c1MElBK2VqRHk3eUZRYjZTSys0U3AKSXJaSEdQamYx eUQ0eGtraHpORlBKMm1ZR040aENDcm5XckRnL2hDM3J4U3dDcEkzUEV4bFo4T0Y5 ank5alR0cQpJUngvelhTUUtnSmNBRHM0dHNOSGZ6UHJuRXk0MWJzbWNkSTBOcm5j UGNmMjVqRnZhUFR3QkhBQ3lIbG1GWDJ6Ci9HdUNoZW9wYXhtaVZKRnVWbGVxcnR4 ZVRCTjR2NzlMaHhCR3RDVWRZSDlHcmVuRnZ6QTl2OFZNQTZyOWQ3YVcKQ2I3bDBK SEw4d3pEQk9sRENiSk1adlQ3dER4eWwyTUl2MTFMUWVJSW5SbEk2SkJ4TENGWnVo WVB6d0FSQVFBQgp6U1Z5ZVdGdVFHUnBaMmxqWVc1aExtTnZiU0E4Y25saGJrQmth V2RwWTJGdVlTNWpiMjArd3NGMUJCQUJDQUFwCkJRSmFNc0tnQmdzSkJ3Z0RBZ2tR dGFvL28waHUxNjBFRlFnS0FnTVdBZ0VDR1FFQ0d3TUNIZ0VBQUp5TEQvMFQKZUdG YmJ1TnlQZmxUb3NkbW1LQUM2Wnl1RHdKeExqdkwzWW5IQVVQa1RPL2E2eFR0RVoy QjQxL21PeDJPVGN5aApKaGh3dEIwL2xzU043cjVyWEh6VVc0VmU2R1NTOFBFSTNq MUl5TS93ZWN2MytnYjM4ZmZkRkVKQTFiVW45K2YvCnV5aFFJRmFMd0ZwcThVUUd4 RFJKOTFRWGNYRnJQemFsc3Y5S0tOY3QxdFJDbGZWblFSNzdCemtoZklKczJnUWkK eVQxbCtWRnF6WEFoVmlpdXpSZGxKTWFUTGIyMzZVa2VPeC9leU5WRWNpdlZZb3V5 MkJ6TC9kVzI4V0RQUHRkVgpIT2NWbVY0S2ZhWUpwSDRtQkhCL0tQK0pOUXk1c3BW Zk1MTWZDMDhyNWEwRUZFM0J5ZWJsdDNPTlBtKzJ5bXpDClJvdEl0ejhUN3Njd3U0 eFRtSXc1V1dSY0lpM21iRFcvbWVmbzd3aGJYM283TmlkUEJDK1pxSnNxTG9Obm8v YUQKUFlYbnBUekFiczRVVFNxcDZQNDlNSFZXTkY0L24vYVhVM1ZoQnZaeDBoMU5O TmJPMVB6Ui84U3I3ZmVkRDlVQwpuaUpOSmdmYUtodDFpMTlQYytCRjUrc2duYlJa ZUlmU3hIV2ZYRCtrcklXR1ptUkJhQnBHelIzSnIzQUF3Q2NECnVKVmVDWHhJZTE3 WlRIeXdxVlpsb1hGWEVSSkJUZm1KK0FEbjIrc0ZNanBkV0Jhd3NsNXhYLzlmZmlP WWY4aTAKbEdoNnZraWtCbkdaem5YSVp4Y3YvSVZpSHVnYlY3M3FwdktUaVpiME5o WDlhd3kybGJqcWRxZzR4UHhuMlJJbwpwaEY5VTNpYmxhcDRqSnJZMFo2NmdNUEhB b2VVWlVJa1crWjYzT1BJbE03QlRRUmFNc0thQVJBQWlSblptNHVjClBLc0ZEUG5N SjVWcUVkeE9LcVRhbGsxRDM3NzEyemovWjcwNjlaRkV6QnY5UkVUcU9qdmFCQ1ZU dExrWmpVS3UKQXQ5QVF3S0prcUhNbXpHVGdsVGt5cThEM0Z3cDExeVVoQm12M3lP ciswVjVNZUU2OUhNdXFpdHBPNWdYbW9NMQoyQ1VBUERzcWV0OEY4THN0RUpNYlJo cHh2T3NnbU1SV2dGbTVMNzRjeXFPVDQ0K01vOCt1THdldlBIMXBDN2JFCi9rTEVQ ZXdjQUUvNjBwUTBZZ1ZQMkxlNngyaHQ4Q3pEWjdwOGNTSGtYbEJhOXlIa1haUkV0 VStMMFdJSU0rM28KRjBycnhMeENpcmJjU2hOM1pFeHgra0xuTTJ6YjN4bUVRd1k2 YndsVXRIa25ub1ZwSmtaWFBjM21OSlFLYzA4NAorWEdnSWNQYXEwNTN2cElaa093 ZlFib292azZ4cG9sWkdmU254c1FTVnNCTFQ3WFlKR2UydjRTdExuS1UzRzFXCk1J aHk4TitzK1ArUHRPYytZRU9sNS82cmhiZUk2UkFsS21wcisvMGhFWG9lK0Z4USt0 Njc5TS9kR2ptRmM1YlIKVFl0b1k2YlpuaGpHYnZ0dWY0K3pmUFNudmFMOFFtd2Rj bjZYSFExVndCQmFVWXlqYUxJTCtOam1LSjdSWGhrawoyeUs0SU1iZDVYMFl1TDVm dVpnTXE5OUJTbkVtZ1B0QUhwQW9rci9sWXV0VW82NmhIUEQ5OWlBSUwxYUI5aU5l CmpqU0FjdWI1QThQMENaYWJNTWVsdmw5QnRXRGVHZ0d6K3lFQmlJN09MOHdaOUxn NjM0RTZRNjVIUmZBcUFiU2cKc0pyRmRHc0tKM3NuUXRhbGJ6UzJBaldVUnZWOW5T aHpuV3NBRVFFQUFjTEJYd1FZQVFnQUV3VUNXakxDb3drUQp0YW8vbzBodTE2MENH d3dBQU5qSkQvNDFRTmpkSkQ3VzNZR0RkRjd6SXlOMW5FME9WTElsaGh5WHZ4Mk5C UzlFCjhPMzM4V1dpbnMzekxJZTdCenFyNkhTSmdQZUxyRElJWi8rQ29aSW9aZm52 cEI2bllsbWdQME8zdUZuSnNQYysKTjVnc1E0cDEzZEF4QldWMVNBSmJtMDdyZ3VT RVMzNzlpdHdPTWFuSU9KTVNQTnhETHI4YUxLY2pKV0tqNWRnTgpvMEx1eWFYSjdI OU02MWMrMytUV25ZdWNBakZDQ2s3STcrRldtWHZ2OEgzVHBBeEF6K3FPYllKRDRS UDFaL3RSCjdtYVJyQU5NalVZY0lneVR2RzlsNDF2ZG1jR01lZDN4bTc3VS9Yek96 ZlVDbEVEbWFLMzlibU9HNEF1YzVSOHkKNjIrMkhJSS94cmE5V2VlaUlPZXNxTUVN NTB5NkFjUUVSVnAydDQyZjFucld5aU1KMkR6cVMyUlZwMHZiNWNsRApIK25XUUlM bGxuN1VBd09ONHJvaXpQZm5zeTRBOGdiTS9KcXlMazA1Vnl4WlEzWUNUZUJJcVJm anUyUndIM0l2CjRuZFBhaXBIUkY3R3dOZEdKWDJFYmJ4L1hyMHBLbUx3K0tKa211 ZEVuU0VqYUJTeFYwcml1N3dHUHZ6UVFhL3AKWTIrNmlzWDgxeVNibFlqakVwVCsz eDUvdmFzMDcxL3dNdlFaWmJrc29RT3dvZGxZSHFHellGOTlXbFoyMHJySgpnL1F4 R2VQS2xRU01jQWlYalhXUzI4bkYxY2xVZHRlUlNXM0JDbHJsbGcyNFlNNWRZL1ZC RDhzZWp5aERNVUI4CnA3NUNCa1JDTzZ4UlozcnJ5QXBqQTM0QnJlNnd0NlJOT1A5 V1VTYzFnbmhPaUk5K3E1a3oxc0JHWm9VRXRNTmsKZ1E9PQo9SXZXYQotLS0tLUVO RCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0t [signature.asc application/pgp-signature (839 Bytes)] Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From sac at 300baud.de Mon Aug 12 18:39:38 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 12 Aug 2019 18:39:38 +0200 Subject: PGP Key Poisoner In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> Message-ID: <20190812183938.00003bdc.sac@300baud.de> Ryan McGinnis via Gnupg-users wrote: > Yes, ironically, this proof of concept is the responsible way to demonstrate > the issue (after a sufficient waiting period following a private?disclosure > to the developers), rather than, say, demonstrating the issue by spitefully > poisoning the keys of a few prominent people in the GPG community. ? The ?if > nobody talks about it and it remains obscure then it is not an issue? is > something you would expect from a Mickey Mouse outfit that has no real > understanding of security, not from a software development community that is > essentially creating platforms focused on gold-standard security applications > that underpin a lot of development infrastructure. ? > > Just my two cents *ploink ploink* I don't want to warm-up this topic again, but... didn't Robert said in his github gist that the issue was known for more than a decade? Why was is then not fixed a decade ago, like it was done with 2.2.17? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From vedaal at nym.hush.com Mon Aug 12 19:09:27 2019 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Mon, 12 Aug 2019 13:09:27 -0400 Subject: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key" In-Reply-To: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> Message-ID: <20190812170927.CAC3420129@smtp.hushmail.com> On 8/12/2019 at 7:28 AM, "Juergen Bruckner via Gnupg-users" wrote: >Am 11.08.19 um 23:47 schrieb Anonymous Remailer (austria): >> >> https://github.com/skeeto/pgp-poisoner ===== Here is a quote from the above site: =====[ begin quoted material ]===== As far as keyserver weaknesses go, key poisoning attacks are really just scratching the surface. For example, did you know other people can bind your subkeys to their primary key? =====[ end quoted material ]===== Can this really be done? (Does not matter so much to me personally, as I grew up with v3 keys, and even when using a V4 key, I don't generate a subkey, but allow all the functions (sign, encrypt. certify) to be done with the master key). Does matter a lot if I can't trust the subkey of someone whom I want to encrypt to. How real is this threat, and is it any threat at all, if simply binding the subkey to a different master key, won't allow for anyone else other than the 'real' owner, to decrypt messages encrypted to that subkey? TIA vedaal From peter at digitalbrains.com Mon Aug 12 19:27:49 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 12 Aug 2019 19:27:49 +0200 Subject: PGP Key Poisoner In-Reply-To: <20190812183938.00003bdc.sac@300baud.de> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> Message-ID: On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote: > Why was is then not fixed a decade ago, like it was done with 2.2.17? There is no fix for the SKS keyserver network, which explains why it wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over the last several years. DANE, WKD, Autocrypt, work on keys.openpgp.org... I thought this (there is no fix) was pretty solidly established by now on this mailing list and elsewhere? 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 ullbeking at andrewnesbit.org Mon Aug 12 18:31:54 2019 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Mon, 12 Aug 2019 17:31:54 +0100 Subject: PGP Key Poisoner In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> Message-ID: <3809260b-e2bc-49c0-cb41-850ba7b72dc5@andrewnesbit.org> On 12/08/2019 16:44, Ryan McGinnis via Gnupg-users wrote: > Yes, ironically, this proof of concept is the responsible way to > demonstrate the issue (after a sufficient waiting period following a > private?disclosure to the developers) I don't understand how this is irony. I must have missed something. Are you suggesting that because the entire community have known about this for a long time and did nothing, then the problem has effectively been disclosed already? Therefore something should have been done long ago and because it wasn't exploiting the defect like this should not be something to complain about? Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From johnz at pleasantnightmare.com Mon Aug 12 18:56:35 2019 From: johnz at pleasantnightmare.com (John Z.) Date: Mon, 12 Aug 2019 13:56:35 -0300 Subject: PGP Key Poisoner In-Reply-To: <20190812183938.00003bdc.sac@300baud.de> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> Message-ID: <20190812165635.GH772@johnslap.localdomain> > I don't want to warm-up this topic again, but... didn't Robert said in his > github gist that the issue was known for more than a decade? > > Why was is then not fixed a decade ago, like it was done with 2.2.17? The link in the github document, points to another link which explains that the code is difficult to work with, and -iirc- is written in OCaml as a Ph.D. thesis. I stand corrected, if I'm wrong. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- "That gum you like is going to come back in style." From sac at 300baud.de Mon Aug 12 21:13:48 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 12 Aug 2019 21:13:48 +0200 Subject: PGP Key Poisoner In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> Message-ID: <20190812211348.00003611.sac@300baud.de> Peter Lebbing wrote: > On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote: > > Why was is then not fixed a decade ago, like it was done with 2.2.17? > > There is no fix for the SKS keyserver network, which explains why it > wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over > the last several years. DANE, WKD, Autocrypt, work on > keys.openpgp.org... > > I thought this (there is no fix) was pretty solidly established by now > on this mailing list and elsewhere? > > Peter. Yes, but still I don't understand the attitude of the SKS operators. People know there that there are issues for a decade with the software running on their servers and they don't understand the codebase to fix issues. And when things later happen, like recently, they still run their servers. I wonder why those SKS key servers are so important to be still in service as of today since we have WKD, Hagrid, keybase, Mailvelope Key Server and Facebook? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From schinzel at fh-muenster.de Mon Aug 12 22:08:31 2019 From: schinzel at fh-muenster.de (Sebastian Schinzel) Date: Mon, 12 Aug 2019 22:08:31 +0200 Subject: Repo with test cases for covert content attacks In-Reply-To: <20190812174744.000017c0.sac@300baud.de> References: <20190812174744.000017c0.sac@300baud.de> Message-ID: Am 12.08.19 um 17:47 schrieb Stefan Claas via Gnupg-users: > Sebastian Schinzel wrote: > >> Dear all, >> >> Jens M?ller just gave a talk at DEFCON about Covert Content Attacks >> against S/MIME and OpenPGP encryption and digital signatures in the >> email context. He just published the PoC emails that he used in the talk >> and they might be useful for further testing. >> >> https://github.com/RUB-NDS/Covert-Content-Attacks >> >> This is the paper describing the attacks from April 2019: >> >> https://arxiv.org/abs/1904.07550 > > Thanks for the info. I do no longer use a GPG plug-in MUA > combination, but are these 'Johnny you are fired' issues > already been resolved? I must admit I am a bit out of the > loop. Those are two different papers. 1. The 'Jonny, you are fired' paper solely dealt with signature spoofing and the repo is here: https://github.com/RUB-NDS/Johnny-You-Are-Fired 2. The paper mentioned in the thread above is 'Re: What's Up Johnny? -- Covert Content Attacks on Email End-to-End Encryption' and it contains some leftover attack cases that didn't make it into the Efail paper. It aims at exfiltrating the plaintext of encrypted mails, but with some degree of user interaction, e.g. replying to a malicious email. Lots of test cases and I am not aware of any current list of what MUA fixed which issue (correctly or incorrectly). Best, Sebastian From ullbeking at andrewnesbit.org Mon Aug 12 22:09:02 2019 From: ullbeking at andrewnesbit.org (U'll Be King Of The Stars) Date: Mon, 12 Aug 2019 21:09:02 +0100 Subject: PGP Key Poisoner In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> Message-ID: <26219709-C1D0-421B-B835-BA8406354C2A@andrewnesbit.org> On 12 August 2019 18:27:49 BST, Peter Lebbing wrote: >On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote: >> Why was is then not fixed a decade ago, like it was done with 2.2.17? > >There is no fix for the SKS keyserver network, which explains why it >wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over >the last several years. DANE, WKD, Autocrypt, work on >keys.openpgp.org... I still contend that a large subset of the most harmful factors in all of this are those awful GnuPG beginners tutorials that encourage the inexperienced new user to upload their new keys to keyservers. I would love to fix this problem from this perspective. Before too long I would like to determine if I can schedule time to work on it. It's an important thing for an important project that I just happen to be particularly interested in. >I thought this (there is no fix) was pretty solidly established by now >on this mailing list and elsewhere? The things I missed are: - how to check and clean a user's local keyring - how to update the user's local configuration in ~/.gnupg Andrew From sac at 300baud.de Mon Aug 12 22:28:09 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 12 Aug 2019 22:28:09 +0200 Subject: Repo with test cases for covert content attacks In-Reply-To: References: <20190812174744.000017c0.sac@300baud.de> Message-ID: <20190812222809.00004328.sac@300baud.de> Sebastian Schinzel wrote: > Those are two different papers. > > 1. The 'Jonny, you are fired' paper solely dealt with signature spoofing > and the repo is here: > > https://github.com/RUB-NDS/Johnny-You-Are-Fired > > 2. The paper mentioned in the thread above is 'Re: What's Up Johnny? -- > Covert Content Attacks on Email End-to-End Encryption' and it contains > some leftover attack cases that didn't make it into the Efail paper. It > aims at exfiltrating the plaintext of encrypted mails, but with some > degree of user interaction, e.g. replying to a malicious email. > > Lots of test cases and I am not aware of any current list of what MUA > fixed which issue (correctly or incorrectly). Thanks for pointing that out! Even if I no longer use online computers for encryption/decryption I may take the time and study the examples, once time permits. Best regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From rjh at sixdemonbag.org Tue Aug 13 05:35:15 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 12 Aug 2019 23:35:15 -0400 Subject: PGP Key Poisoner In-Reply-To: <20190812183938.00003bdc.sac@300baud.de> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> Message-ID: <2d920f69-4b54-1869-4071-6658b7d181d0@sixdemonbag.org> > I don't want to warm-up this topic again, but... didn't Robert said in his > github gist that the issue was known for more than a decade? I did. Much closer to two decades than one. I remember talking about it with Randy Harmon of PGP Security in 2000. > Why was is then not fixed a decade ago, like it was done with 2.2.17? Re-read my Gist, please. It's all in there. From vesely at tana.it Tue Aug 13 09:54:01 2019 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 13 Aug 2019 09:54:01 +0200 Subject: PGP Key Poisoner In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> Message-ID: <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> On Mon 12/Aug/2019 19:27:49 +0200 Peter Lebbing wrote: > On 12/08/2019 18:39, Stefan Claas via Gnupg-users wrote: >> Why was is then not fixed a decade ago, like it was done with 2.2.17? > > There is no fix for the SKS keyserver network, which explains why it > wasn't fixed in 2.2.17 either. In fact, fixes have been deployed over > the last several years. DANE, WKD, Autocrypt, work on > keys.openpgp.org... This and John Z mentioning OCaml seem to point a finger in the wrong direction. The key poisoner shows that 200000 signatures can be handled in a few seconds (I didn't try, I trust the author). More than a reasonable number of signatures makes no sense in practice, so I agree lists should somehow be "fixed" so as not to accept an unreasonable number of signatures (reasonable == 2??) The bug, however, is in the program that chokes on poisoned keys! Was that fixed, yet? Best Ale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From david at gbenet.com Tue Aug 13 11:15:09 2019 From: david at gbenet.com (David) Date: Tue, 13 Aug 2019 10:15:09 +0100 Subject: PGP Key Poisoner In-Reply-To: <87sgq6l9ug.fsf@ra.horus-it.com> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <837da0a8-e8a6-8415-3961-95a0e2a4c805@gbenet.com> <87sgq6l9ug.fsf@ra.horus-it.com> Message-ID: <03152f46-0358-f3c8-5ac1-3c0bfdd774c8@gbenet.com> On 12/08/2019 15:47, Ralph Seichter wrote: > * david at gbenet.com: > >> putting this code on Github whist demonstrating a point - was foolish > > No, it was not. Foolish would be to pretend the conceptual flaw does not > exist, cover your ears with your hands and go "la la la". > >> To say that this was in practice and common knowledge for years - it's >> new to me and many thousands of pgp users. > > Are you suggesting that people "in the know" should let people with a > potentially harmful lack of knowledge stay blissfully unaware? What good > would that do? > >> People Should Not Be Afraid Of Their Government - Their Government >> Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION >> Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" > > I think that, in light of your message, is quite a ridiculous signature. > https://gbenet.com advertises itself as a "Capitalist Free Website For > Free Thinkers!" stating "I have no ''beliefs'' no secret agenda's [sic] - > other than to bring you knowledge which you may not be aware of". Well, > some knowledge was brought to you via GitHub, so enjoy. :-) > > -Ralph > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Thank you Ralf, David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Aug 13 12:08:31 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Aug 2019 12:08:31 +0200 Subject: PGP Key Poisoner In-Reply-To: <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> (Alessandro Vesely via Gnupg-users's message of "Tue, 13 Aug 2019 09:54:01 +0200") References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> Message-ID: <875zn1e5sw.fsf@wheatstone.g10code.de> On Tue, 13 Aug 2019 09:54, gnupg-users at gnupg.org said: > The bug, however, is in the program that chokes on poisoned keys! Nope. This is a long standing DoS protection by limiting the total length of a keyblock. The diagnostics were a bit misleading, though. The time it took to process all these signatures during importing is due to a fix and out of order keyblock functions which has been enabled by default in 2.1. It should be obvious that checking several thousands of signatures and finding the matching user-id takes its time. Anyway, given that these keys are real the approach with 2.2.17 is to auto-retry an import with import-clean etc. if the keyblock size hits the size limit. For keyserver imports import-clean is also the 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 peter at digitalbrains.com Tue Aug 13 13:07:07 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 13 Aug 2019 13:07:07 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> Message-ID: On 13/08/2019 09:54, Alessandro Vesely via Gnupg-users wrote: > More than a reasonable number of signatures makes no sense in > practice, so I agree lists should somehow be "fixed" so as not to > accept an unreasonable number of signatures (reasonable == 2??) Others tell us: the synchronization protocol as it is cannot be fixed. You reply: I agree it should - somehow - be fixed? The sort and unhelpful answer of course is: read the first sentence again, or disprove it mathematically just like the algorithm was mathematically proven to work in the first place. But I'll try to sketch it. I don't know the synchronization protocol. What I do know: the design goals included resistance to oppressive regimes interested in deleting anything from the network, so it was to be designed so it was technically impossible to delete anything. Furthermore, this is from memory, but when I read basic information about the SKS reconciliation algorithm, I see the terms "monotonicity requirement for progress" or something alike. I don't know if this is how it works, but this is how it could work: Somebody has worked years on an algorithm for their PhD thesis which fulfills an important task, and through those years a lot of mathematical proofs have been spent on proving that it does what was asked of it. One of these demands was that it could provably never delete data that had been available earlier. In order to make this algorithm, the PhD student discovered that they needed to have some properties hold at *every* single step: otherwise they could not prove that the algorithm was correct. So let's see a single step in the reconciliation process as the reconciliation of a single piece of data that has been added to the network. The PhD student found they needed a requirement they called the monotonicity requirement. I don't know what it means precisely in this case, but I can take a guess: if two hosts are reconciling, the monotonicity requirement could mean that the data at either one of these hosts - gets data added and everything that was there stays - the data it has stays exactly the same Those are the only two cases that satisfy the monotonicity requirement. Furthermore, the end goal is for all hosts to have the same dataset, so let's define progress as that the hosts become more and more alike: when the number of differences between the hosts has reduced, we have made progress. Once completed, it has progressed to the point where the number of differences is zero. As an aside, it has to be proven that we eventually progress to that point where they are the same, otherwise there could be a dataset that just keeps spinning, running the algorithm endlessly. In fact, it's well possible that this is where the monotonicity requirement plays a role. Let's do this with your max 2. Somebody uses SKS keyserver network host A to add two signatures, call them A1 and A2 to the key in question, which did not have any signatures yet. Host A accepts them, they fall within the limits. Either this same person or someone else adds two signatures on SKS server B on the same key, call them B1 and B2. Hosts A and B haven't reconciled yet, so B sees no signatures on the key and accepts. Now they reconcile. They compare their datasets. They are not the same: we still need to have progress to get to completion. Let's reconcile signature A1. Server A offers server B signature A1. Wait a minute, the key already has signatures B1 and B2. Server B cannot accept signature A1, it would break the contract that there are ever only 2 signatures on the key. Now we have a deadlock. There is no following step that would fulfill the monotonicity requirement as well as make any progress. The only way to fulfill the monotonicity requirement is when server A keeps the signatures A1 and A2, and server B keeps B1 and B2. But the progression has halted and the process never finishes. Ah, you say, why don't you /swap/ B1 for A1? Well, there is no such thing as swapping. Swapping is simply the deleting of B1 followed by the addition of A1. And monotonicity says we can't delete anything. Besides, any limit on the number of signatures is a Denial-of-Service. In your case, if Alice, Bob and Carol all sign eachother's keys, there's no more room for other signatures. And if Mallory creates two bogus keys and signs all the keys of Alice, Bob and Carol, the three can't add any real signatures anymore. The algorithm is designed to withstand very well funded actors, oppressive regimes were what the designers were thinking of. Obviously, the algorithm does this regardless of who is trying to do something otherwise, no matter whether it is a repressive regime or the legitimate operators and designers of the system. > The bug, however, is in the program that chokes on poisoned keys! It seems to me there is (almost?) always a denial of service. Offline systems have more trouble with this than online systems, and even websites (online systems) have really expensive world-spanning networks to mitigate (rather than truly deal with) DoS-attacks. Asymmetric crypto has a very unfavourable runtime <-> data size ratio. With just a few bytes, you need a hell of a lot of mathematical processing to interpret those bytes correctly. It's a really unfortunate amplification factor: when an attacker hands you a very small payload, you need a lot of runtime to decide if it was actually something you wanted. There are better and worse ways to design the data for this aspect, but it's always going to be on the computation-intensive side of things. So GnuPG gets a key with a lot of third-party signatures. It can keep wading through all the crap looking for the real signatures the user does want between all the crap added by attackers, and this takes a lot of runtime. Or it can decide: this is taking to long, I bail out. In neither case will the user get that signature that they actually want, and which according to Murphy is actually near the end of where GnuPG will be looking. So the user is denied the signatures it was looking for in either case. > Was that fixed, yet? How? You keep looking through the piles of crap, or you stop looking. In either case, you don't find what you are looking for in a desirable length of time. I think the solution needs to be sought in a direction where GnuPG doesn't have to look for valid data amidst a lot of invalid crap. Because evaluating the invalid crap can always be made expensive, so there should be other means to say "I'm not going to parse this, find another way to get me the proper data where it's not buried in crap". 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 kristian.fiskerstrand at sumptuouscapital.com Tue Aug 13 13:56:25 2019 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 13 Aug 2019 13:56:25 +0200 Subject: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key" In-Reply-To: <20190812170927.CAC3420129@smtp.hushmail.com> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812170927.CAC3420129@smtp.hushmail.com> Message-ID: On 12.08.2019 19:09, vedaal via Gnupg-users wrote: > Can this really be done? > > (Does not matter so much to me personally, as I grew up with v3 > keys, and even when using a V4 key, I don't generate a subkey, but > allow all the functions (sign, encrypt. certify) to be done with the > master key). > > Does matter a lot if I can't trust the subkey of someone whom I want > to encrypt to. > How real is this threat, and is it any threat at all, if simply > binding the subkey to a different master key, won't allow for anyone > else other than the 'real' owner, to decrypt messages encrypted to > that subkey? As you correctly point out its really not that relevant for encryption subkeys. It does have security implementations for signing subkeys; see [cross-certification section] for some details on that. References: [cross-certification section] https://gnupg.org/faq/subkey-cross-certify.html -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws -------------- 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 Tue Aug 13 14:09:53 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 13 Aug 2019 14:09:53 +0200 Subject: PGP Key Poisoner In-Reply-To: <20190812211348.00003611.sac@300baud.de> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <20190812211348.00003611.sac@300baud.de> Message-ID: <197a932e-f04d-93fb-9bee-6da8b4cee88b@digitalbrains.com> I suspect we haven't seen this issue being done in the real world before because it is not a useful attack in many scenarios. It's just a nasty DoS that can be avoided by not using the SKS keyserver network. I'm completely speculating, but I think that the people who really want to learn something about their victim will use and have used completely different attacks. This DoS isn't effective at what they want. I don't know if that is the case, but I think it's a possibility. This doesn't mean that this attack was harmless; far from it. I think it has the potential to do a lot of harm to a lot of people. It just possibly doesn't really accomplish the goals that, for instance, oppressive regimes or black hats penetrating networks have. And since no serious attacker used this weakness, by that virtue it might not be a big problem. The good sides of the SKS keyserver network might outway its flaws when the flaws are not the flaws that attackers will exploit in practice. Until little boys with matches come round and play at being responsible security researchers without understanding how that actually works. > People know there that there are issues for a decade with the software > running on their servers and they don't understand the codebase to fix > issues. I don't think the bit about the OCaml code complexity was a good argument in Rob's gist post. I think the proper fix is to design an alternative to the SKS keyserver network. The design choices in the reconciliation protocol don't work out anymore, we shouldn't change the protocol but replace it. Several alternatives for key distribution have actually been developed for many years now. You can't say people are not actively working on this problem, it's just not true. That they are actually looking in a different solution space than what you want to see is their right. > And when things later happen, like recently, they still run their > servers. Perhaps because there are still users who need it. GnuPG 2.2.17 already led to a report[1] on the mailing list that they needed third-party signatures from keyservers. I don't know if they need the SKS network, but in general, there are users out there who can still use it. But I obviously can't speak for anyone else. > I wonder why those SKS key servers are so important to be still in > service as of today since we have WKD, Hagrid, keybase, Mailvelope Key > Server and Facebook? Only people using the SKS keyserver network are affected by this issue. You say you don't see a reason to use them. So don't. Tell your correspondants to use different methods when they exchange keys with you, and you'll never have to interact with the SKS keyserver network again. Problem solved; for you. Others will take care of their own. Also.... Facebook? A lot of the alternatives to the SKS network have some issues regarding either a form of trusted third party, or of anonymity. Every service has its own trade-offs. And some stand out like a sore thumb. Again... Facebook?! :-) Cheers, Peter. [1] -- 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 Tue Aug 13 14:16:43 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 13 Aug 2019 14:16:43 +0200 Subject: PGP Key Poisoner In-Reply-To: <26219709-C1D0-421B-B835-BA8406354C2A@andrewnesbit.org> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <26219709-C1D0-421B-B835-BA8406354C2A@andrewnesbit.org> Message-ID: On 12/08/2019 22:09, U'll Be King Of The Stars wrote: > The things I missed are: > > - how to check and clean a user's local keyring > > - how to update the user's local configuration in ~/.gnupg I generally felt there was a lack of concise, complete instructions for users, after the event. I was missing several pieces of the puzzle myself. Still, I suppose I could have tried to do this, so it's a bit odd to be pointing out that this area was lacking when I could have solved it partially myself. But here we are: I never saw a good concise complete set of instructions and guidance, and I was a bit surprised no one wrote it. 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 Tue Aug 13 14:25:01 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 13 Aug 2019 14:25:01 +0200 Subject: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key" In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812170927.CAC3420129@smtp.hushmail.com> Message-ID: On 13/08/2019 13:56, Kristian Fiskerstrand wrote: > As you correctly point out its really not that relevant for encryption > subkeys. It does have security implementations for signing subkeys; see > [cross-certification section] for some details on that. But this issue has been fixed for so long that any CD's documenting the fix will have since bit-rotted! It's ancient Information Technology history! To be exact, this has been a non-issue since GnuPG 1.4.8, released 2007-12-20, which defaulted to --require-cross-certification after the cross certifications had percolated through the ecosystem in the years leading up to that new default. 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 Tue Aug 13 14:32:31 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 13 Aug 2019 14:32:31 +0200 Subject: PGP Key Poisoner In-Reply-To: <197a932e-f04d-93fb-9bee-6da8b4cee88b@digitalbrains.com> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <20190812211348.00003611.sac@300baud.de> <197a932e-f04d-93fb-9bee-6da8b4cee88b@digitalbrains.com> Message-ID: <20190813143231.000015b2.sac@300baud.de> Peter Lebbing wrote: > > I wonder why those SKS key servers are so important to be still in > > service as of today since we have WKD, Hagrid, keybase, Mailvelope Key > > Server and Facebook? > > Only people using the SKS keyserver network are affected by this issue. > You say you don't see a reason to use them. So don't. Tell your > correspondants to use different methods when they exchange keys with > you, and you'll never have to interact with the SKS keyserver network > again. Problem solved; for you. Others will take care of their own. > > Also.... Facebook? > > A lot of the alternatives to the SKS network have some issues regarding > either a form of trusted third party, or of anonymity. Every service has > its own trade-offs. And some stand out like a sore thumb. Again... > Facebook?! :-) True, I will let them know. Regarding Facebook, yes, I see at as some form of a key server too because it allows FB users to upload their pub key to their profile. :-) Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From sac at 300baud.de Tue Aug 13 14:56:47 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 13 Aug 2019 14:56:47 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> Message-ID: <20190813145647.00007861.sac@300baud.de> Peter Lebbing wrote: [snip] > Furthermore, the end goal is for all hosts to have the same dataset, so > let's define progress as that the hosts become more and more alike: when > the number of differences between the hosts has reduced, we have made > progress. Once completed, it has progressed to the point where the > number of differences is zero. As an aside, it has to be proven that we > eventually progress to that point where they are the same, otherwise > there could be a dataset that just keeps spinning, running the algorithm > endlessly. In fact, it's well possible that this is where the > monotonicity requirement plays a role. [snip] Good write-up. Now I have a question, in hope that SKS operators are reading this too. I have learned from Robert's gist that the max. is 150.000 sigs per key the servers can handle, if I am not mistaken. How do they handle the following: Bob uploads his key from a key signing party with 100 sigs to server A. Mallory and Eve attended the key signing party too and signed Bob's key. Mallory uploads Bob's key with an additional 100k sigs on server B and Eve does the same with server C. Lets assume that server B and C syncs before A. What does server B accepts then from C and vice versa, because of the 150k sig limit? Will at the end server A, B and C have different key sets from Bob, because of the 150k limit? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From rjh at sixdemonbag.org Tue Aug 13 16:54:24 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 13 Aug 2019 10:54:24 -0400 Subject: Difficulty of fixing reconciliation In-Reply-To: <20190813145647.00007861.sac@300baud.de> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <20190813145647.00007861.sac@300baud.de> Message-ID: > Good write-up. Now I have a question, in hope that SKS operators are > reading this too. I have learned from Robert's gist that the max. is > 150.000 sigs per key the servers can handle, if I am not mistaken. I didn't say this. I said they handle up to about that, *because we've seen keys with that many*. So clearly, obviously, they handle that many. A great many people have assumed I intended to say "and it won't handle more than 150,000". Which I didn't say and don't intend. It very well could handle more. From rjh at sixdemonbag.org Tue Aug 13 17:11:36 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 13 Aug 2019 11:11:36 -0400 Subject: PGP Key Poisoner In-Reply-To: <197a932e-f04d-93fb-9bee-6da8b4cee88b@digitalbrains.com> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <20190812211348.00003611.sac@300baud.de> <197a932e-f04d-93fb-9bee-6da8b4cee88b@digitalbrains.com> Message-ID: <5bc20d0a-b246-0753-a4c2-55a7b0c44e30@sixdemonbag.org> > I don't think the bit about the OCaml code complexity was a good > argument in Rob's gist post. In my defense, I wrote that front-to-back in under an hour. My goal was to quickly release a useful pr?cis, not to slowly write a definitive reference on the problem. :) That said, this particular thing I stand behind. The number of people in the SKS community who grok OCaml is pretty close to zero. > I think the proper fix is to design an alternative to the SKS keyserver > network. The design choices in the reconciliation protocol don't work > out anymore, we shouldn't change the protocol but replace it. I agree. From peter at digitalbrains.com Tue Aug 13 17:22:07 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 13 Aug 2019 17:22:07 +0200 Subject: PGP Key Poisoner In-Reply-To: <5bc20d0a-b246-0753-a4c2-55a7b0c44e30@sixdemonbag.org> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <20190812211348.00003611.sac@300baud.de> <197a932e-f04d-93fb-9bee-6da8b4cee88b@digitalbrains.com> <5bc20d0a-b246-0753-a4c2-55a7b0c44e30@sixdemonbag.org> Message-ID: <04d27f5b-430c-475c-95f3-582fc9539cf0@digitalbrains.com> On 13/08/2019 17:11, Robert J. Hansen wrote: >> I think the proper fix is to design an alternative to the SKS keyserver >> network. The design choices in the reconciliation protocol don't work >> out anymore, we shouldn't change the protocol but replace it. > > I agree. Ah, then the discussion about OCaml is a moot point by now and can be disregarded until the moment someone proposes to write the replacement in OCaml :-D Cheers, 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 Tue Aug 13 17:26:36 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 13 Aug 2019 17:26:36 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <20190813145647.00007861.sac@300baud.de> Message-ID: <20190813172636.0000246c.sac@300baud.de> Robert J. Hansen wrote: > > Good write-up. Now I have a question, in hope that SKS operators are > > reading this too. I have learned from Robert's gist that the max. is > > 150.000 sigs per key the servers can handle, if I am not mistaken. > > I didn't say this. > > I said they handle up to about that, *because we've seen keys with that > many*. So clearly, obviously, they handle that many. > > A great many people have assumed I intended to say "and it won't handle > more than 150,000". Which I didn't say and don't intend. It very well > could handle more. Ah, o.k. sorry, my misunderstanding! Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD) From vedaal at nym.hush.com Tue Aug 13 20:26:49 2019 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 13 Aug 2019 14:26:49 -0400 Subject: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key" In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812170927.CAC3420129@smtp.hushmail.com> Message-ID: <20190813182650.0D6E120120@smtp.hushmail.com> On 8/13/2019 at 7:59 AM, "Kristian Fiskerstrand" wrote: >As you correctly point out its really not that relevant for >encryption >subkeys. It does have security implementations for signing >subkeys; see >[cross-certification section] for some details on that. > >References: >[cross-certification section] >https://gnupg.org/faq/subkey-cross-certify.html GnuPG has been requiring cross-certification for a very long time, which would mean that an attacker who attaches a person's listed subkey to a different masterkey, would still not be able to do anything with it, because the attacker can't make it cross-certify. Being simplistically naive here, How difficult would it be to get keyservers to agree that only the key owners can submit new signatures to their own keys? (i.e., The owner's detached signature of the public keyblock having the new signature, required together with any submitted key with a new signature.) A Denial-of Service attack will still always be possible against a keyserver, since it is easy for an attacker to generate a large volume of legitimate keys, with only a self-signature, and upload them to the keyserver, but at least then, no individual key by a real user, could be attacked. vedaal From vesely at tana.it Wed Aug 14 11:38:39 2019 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 14 Aug 2019 11:38:39 +0200 Subject: PGP Key Poisoner In-Reply-To: <875zn1e5sw.fsf@wheatstone.g10code.de> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <875zn1e5sw.fsf@wheatstone.g10code.de> Message-ID: <6e51bc3e-5a05-e361-75fb-5c89eeb0b7e0@tana.it> On Tue 13/Aug/2019 12:08:31 +0200 Werner Koch Via Gnupg-users wrote: > On Tue, 13 Aug 2019 09:54, gnupg-users at gnupg.org said: > >> The bug, however, is in the program that chokes on poisoned keys! > > Nope. This is a long standing DoS protection by limiting the total > length of a keyblock. The diagnostics were a bit misleading, though. > > The time it took to process all these signatures during importing is due > to a fix and out of order keyblock functions which has been enabled by > default in 2.1. It should be obvious that checking several thousands of > signatures and finding the matching user-id takes its time. > > Anyway, given that these keys are real the approach with 2.2.17 is to > auto-retry an import with import-clean etc. if the keyblock size hits > the size limit. For keyserver imports import-clean is also the default. Why wasn't that check in place from version 0.0.0? Perhaps GnuPG was coded at times when DoS was an operating system? Of course, anonymous key poisoning is a kind of gratuitous vandalism. Yet, crypto is supposed to work in a hostile environment. Best Ale -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From vesely at tana.it Wed Aug 14 11:39:56 2019 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 14 Aug 2019 11:39:56 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> Message-ID: <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> On Tue 13/Aug/2019 13:07:07 +0200 Peter Lebbing wrote: > On 13/08/2019 09:54, Alessandro Vesely via Gnupg-users wrote: >> More than a reasonable number of signatures makes no sense in >> practice, so I agree lists should somehow be "fixed" so as not to >> accept an unreasonable number of signatures (reasonable == 2??) > > [...] > > Furthermore, this is from memory, but when I read basic information > about the SKS reconciliation algorithm, I see the terms "monotonicity > requirement for progress" or something alike. Absolute monotonicity is wrong. It must be possible to delete errors. > [...skip algorithm for their PhD thesis...] > > Let's do this with your max 2. > > Somebody uses SKS keyserver network host A to add two signatures, call > them A1 and A2 to the key in question, which did not have any signatures > yet. Host A accepts them, they fall within the limits. > > Either this same person or someone else adds two signatures on SKS > server B on the same key, call them B1 and B2. Hosts A and B haven't > reconciled yet, so B sees no signatures on the key and accepts. > > Now they reconcile. > > They compare their datasets. They are not the same: we still need to > have progress to get to completion. Let's reconcile signature A1. Server > A offers server B signature A1. Wait a minute, the key already has > signatures B1 and B2. Server B cannot accept signature A1, it would > break the contract that there are ever only 2 signatures on the key. > > Now we have a deadlock. There is no following step that would fulfill > the monotonicity requirement as well as make any progress. The only way > to fulfill the monotonicity requirement is when server A keeps the > signatures A1 and A2, and server B keeps B1 and B2. But the progression > has halted and the process never finishes. The illegal sig shall be deleted from both servers. (2 is a bit Procrustean, a reasonable number would be enforceable.) > Besides, any limit on the number of signatures is a Denial-of-Service. > In your case, if Alice, Bob and Carol all sign eachother's keys, there's > no more room for other signatures. And if Mallory creates two bogus keys > and signs all the keys of Alice, Bob and Carol, the three can't add any > real signatures anymore. I'm no expert, but it seems to me that 3rd party signatures should not be allowed. All signing party recipes provide for /exchanging/ sigs, but then rely on the fact that Alice can sign Bob's sig before Bob has signed Alice's and without Bob's authorization. That is, the semantics is good, but it's not algorithmically enforced. > The algorithm is designed to withstand very well funded actors, > oppressive regimes were what the designers were thinking of. Obviously, > the algorithm does this regardless of who is trying to do something > otherwise, no matter whether it is a repressive regime or the legitimate > operators and designers of the system. Hm... if your sig is signed by a suspect, you become suspect too? In fact, SKS servers with lots of countersigned sigs is manna from heaven for police. I recall someone in the sixties recommending "Comrades, no phone-books! Burn them, learn numbers by memory and burn them." So, would that be a reason to allow 3rd party signatures? I sign your sig, but then I also sign a few dozens other random sigs so as to conceal the link between you and me. Sounds like a poor trick to me. >> The bug, however, is in the program that chokes on poisoned keys! > > [...skip very unfavourable runtime <-> data size ratio...] > > So GnuPG gets a key with a lot of third-party signatures. It can keep > wading through all the crap looking for the real signatures the user > does want between all the crap added by attackers, and this takes a lot > of runtime. > > Or it can decide: this is taking to long, I bail out. Exactly! That signature is poisoned, delete it. There might be utilities that attempt to recover it ?much like AV utilities to recover infected files. >> Was that fixed, yet? > > How? You keep looking through the piles of crap, or you stop looking. In > either case, you don't find what you are looking for in a desirable > length of time. The defense would try and avoid poisoning. When a signature is poisoned, the defense has failed. > I think the solution needs to be sought in a direction where GnuPG > doesn't have to look for valid data amidst a lot of invalid crap. > Because evaluating the invalid crap can always be made expensive, so > there should be other means to say "I'm not going to parse this, find > another way to get me the proper data where it's not buried in crap". Agreed. Best Ale -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Wed Aug 14 12:09:17 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 14 Aug 2019 11:09:17 +0100 Subject: Difficulty of fixing reconciliation In-Reply-To: <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> Message-ID: On 14/08/2019 10:39, Alessandro Vesely via Gnupg-users wrote: > Absolute monotonicity is wrong. It must be possible to delete errors. Indeed, but that condition is fundamentally incompatible with decentralised reconciliation - because deletion without permissions management is an open door, and permissions have to be enforced by an authority. >> Now we have a deadlock. There is no following step that would >> fulfill the monotonicity requirement as well as make any progress. >> The only way to fulfill the monotonicity requirement is when server >> A keeps the signatures A1 and A2, and server B keeps B1 and B2. But >> the progression has halted and the process never finishes. > The illegal sig shall be deleted from both servers. There are three signatures. Which one is illegal? You can't base your decision on the contents of any of the signatures, because they're third-party and therefore untrustworthy. Timestamps can be backdated, for example. > I'm no expert, but it seems to me that 3rd party signatures should not > be allowed. All signing party recipes provide for /exchanging/ sigs, > but then rely on the fact that Alice can sign Bob's sig before Bob has > signed Alice's and without Bob's authorization. That is, the > semantics is good, but it's not algorithmically enforced. There's nothing intrinsically wrong with third-party signatures. The problem is caused by keyservers allowing a global search on the target id to include all the third party signatures on it, whether the target consents or not. Unless you use a maximum trust path length of 1, you must have some way of searching for intermediates. > Hm... if your sig is signed by a suspect, you become suspect too? In > fact, SKS servers with lots of countersigned sigs is manna from heaven > for police. A third-party signature is just a statement by someone saying "I know this person". Sure, that may make you a suspect by association, but so does mentioning your name in public, or sending you an unsolicited postcard. -- 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 david at gbenet.com Wed Aug 14 12:09:44 2019 From: david at gbenet.com (David) Date: Wed, 14 Aug 2019 11:09:44 +0100 Subject: Difficulty of fixing reconciliation In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <20190813145647.00007861.sac@300baud.de> Message-ID: <6a8b8772-0ffd-9589-126b-01088b80b6a6@gbenet.com> On 13/08/2019 15:54, Robert J. Hansen wrote: >> Good write-up. Now I have a question, in hope that SKS operators are >> reading this too. I have learned from Robert's gist that the max. is >> 150.000 sigs per key the servers can handle, if I am not mistaken. > > I didn't say this. > > I said they handle up to about that, *because we've seen keys with that > many*. So clearly, obviously, they handle that many. > > A great many people have assumed I intended to say "and it won't handle > more than 150,000". Which I didn't say and don't intend. It very well > could handle more. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Robert, Can you give me a valid reason why anyone would want their key signed by 150,000 people or more?? How can you meet 150,000 people? Your going to spend your entire waking hours getting your key signed by as many people as possible before you die? The mind boggles! David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From look at my.amazin.horse Wed Aug 14 12:29:59 2019 From: look at my.amazin.horse (Vincent Breitmoser) Date: Wed, 14 Aug 2019 12:29:59 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> Message-ID: <2N118T7JN0X42.267FY60IAIF22@my.amazin.horse> > The algorithm is designed to withstand very well funded actors, > oppressive regimes were what the designers were thinking of. We are talking about a sand castle here that was kicked down by a kid. It's a bit bizarre to claim that it was built to withstand rockets. Given that the recon algorithm was designed as a PhD thesis, it seems like a safe bet that it was designed to solve the academic problem of set reconciliation between distributed systems with optimal message complexity. Funny story how it ended up becoming infrastructure for a security ecosystem. - V From peter at digitalbrains.com Wed Aug 14 12:37:38 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 14 Aug 2019 12:37:38 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: <6a8b8772-0ffd-9589-126b-01088b80b6a6@gbenet.com> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <20190813145647.00007861.sac@300baud.de> <6a8b8772-0ffd-9589-126b-01088b80b6a6@gbenet.com> Message-ID: <0871775a-9e8e-cfc6-d20f-e48e19c80dd1@digitalbrains.com> Hello David, > Can you give me a valid reason why anyone would want their key signed by > 150,000 people or more?? I don't see anybody claiming that this is a valid use case. There are several issues preventing actually limiting this in the current keyserver network, but this has already been explained. 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 Wed Aug 14 12:51:09 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 14 Aug 2019 12:51:09 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> Message-ID: <31b3f34e-4ac4-45bf-c91e-da9a8a32703e@digitalbrains.com> On 14/08/2019 11:39, Alessandro Vesely via Gnupg-users wrote: > Absolute monotonicity is wrong. It must be possible to delete errors. In that case we need a different algorithm. Which I had already been advocating, so you are preaching to the choir. You can keep reiterating that you do not like the current algorithm, but I already got that and I agree. > Exactly! That signature is poisoned, delete it. Which is a denial of service, which I point out in the next paragraph of the mail you replied to. I'll copy-paste it here with a double indentation: >> In neither case will the user get that signature that they actually >> want, and which according to Murphy is actually near the end of where >> GnuPG will be looking. > The defense would try and avoid poisoning. When a signature is > poisoned, the defense has failed. And that's again my very next paragraph: >> I think the solution needs to be sought in a direction where GnuPG >> doesn't have to look for valid data amidst a lot of invalid crap. >> Because evaluating the invalid crap can always be made expensive, so >> there should be other means to say "I'm not going to parse this, find >> another way to get me the proper data where it's not buried in crap". Cheers, 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 Wed Aug 14 13:06:55 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 14 Aug 2019 13:06:55 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> Message-ID: <6ad4cac6-8030-0c1f-9fb5-4b501d43e483@digitalbrains.com> On 14/08/2019 12:09, Andrew Gallagher wrote: > Indeed, but that condition is fundamentally incompatible with > decentralised reconciliation - because deletion without permissions > management is an open door, and permissions have to be enforced by an > authority. Hmmmm.... the authority could just be the primary key that the third-party signatures are over. I'm not talking about the current SKS keyserver network, but some still-to-be-created federated synchronizing service. That authority could also authorize no longer sharing a particular third party signature, I think. It might still circulate in the federated network, but any time it rears its head again it could get ignored by the revoked authorization (or more: authorization to revoke). "Ignoring" might just mean not offering it to clients even though it's still part of the federation for technical purposes. There's a lot of chance for misunderstandings here. I started writing something less ambiguous and stopped due to the amount of work :-). Cheers, 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 Wed Aug 14 13:19:02 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 14 Aug 2019 13:19:02 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: <2N118T7JN0X42.267FY60IAIF22@my.amazin.horse> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <2N118T7JN0X42.267FY60IAIF22@my.amazin.horse> Message-ID: <7f34fac7-766c-39fd-c698-7a79ebd6fa26@digitalbrains.com> On 14/08/2019 12:29, Vincent Breitmoser wrote: >> The algorithm is designed to withstand very well funded actors, >> oppressive regimes were what the designers were thinking of. > > We are talking about a sand castle here that was kicked down by a kid. It's > a bit bizarre to claim that it was built to withstand rockets. I meant that statement purely and only with regard to deleting data that had already been in the network, nothing more. It seems to me that the impossibility of deletion was at the core of the design of the reconciliation algorithm. To say that we should change the algorithm to no longer do that seems like claiming we should build rockets out of sand castles ;-). > Given that the recon algorithm was designed as a PhD thesis, it seems like > a safe bet that it was designed to solve the academic problem of set > reconciliation between distributed systems with optimal message complexity. > Funny story how it ended up becoming infrastructure for a security ecosystem. These same statements apply to a *lot* of critical infrastructure in the Information Technology domain. It's a wonder it usually works well (or at least gives that appearance when you don't look too hard). 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 cderr at simons-rock.edu Wed Aug 14 17:30:49 2019 From: cderr at simons-rock.edu (charlie derr) Date: Wed, 14 Aug 2019 11:30:49 -0400 Subject: looking for assistance tracking down why i don't have the ability to run gpg from the command line Message-ID: <4aeaaa70-a800-ba0a-6500-e86af0048aeb@simons-rock.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm running debian 10 buster (upgraded recently from stretch if that matters) and i use KDE. I haven't yet tried to logout of my desktop environment completely (and just use a native console), but I thought I would see if any of you had any ideas. Here's the problem: ni at quark:~/.ssh$ gpg --list-keys gpg: checking the trustdb gpg: waiting for lock (held by 22009) ... gpg: waiting for lock (held by 22009) ... gpg: waiting for lock (held by 22009) ... ^C gpg: signal Interrupt caught ... exiting ni at quark:~/.ssh$ ps aux | grep 22009 ni 7740 0.0 0.0 6076 892 pts/6 S+ 11:21 0:00 grep 22009 ni 22009 2.0 0.2 89404 78536 ? RL 02:51 10:30 gpg - --batch --no-sk-comments --status-fd 104 --no-tty --charset utf8 - --enable-progress-filter --exit-on-status-write-error --display :0 - --logger-fd 108 --with-colons --list-keys -- 4E2247974AA5A23A5C92BB4DBB8B3D7331A9367F ni at quark:~/.ssh$ kill 22009 ni at quark:~/.ssh$ gpg --list-keys gpg: checking the trustdb gpg: waiting for lock (held by 28999) ... gpg: waiting for lock (held by 28999) ... gpg: waiting for lock (held by 28999) ... as you can see, killing the offending process doesn't work (as it respawns immediately) The reason this is important to me right now is because I have a new laptop and I'm trying to transfer my keys to it. I have an email from this list sent by Robert J. Hansen on 9/14/2016 that has excellent instructions (which I've used in the past for this purpose) but the 1st command in those instructions: gpg --armor --export dumps a lot of output to the command line but never "finishes" (and my guess is that it's the same lock that's preventing that command from completing). thanks so very much in advance for your time, ~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: he or they -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEETiJHl0qlojpckrtNu4s9czGpNn8FAl1UKR4ACgkQu4s9czGp Nn93/w/+MX6xS0bMETgq/dWUaIt8vzubE1z9HypapZDyxqFyObsoWJS0AEwLMmwx VqEAxFgbGrWT18CP04dLP1L6KPqAI5FsPm9ge0uXYVYF8M5xluIy8NALGWSbwhTm NZlAuPwnzMmNaR4jD2iVF5PuIzzQF8Cx446vZTdR6vrCFWL+0hTn7Orp8l1Rk/ym LLGPUU4iSkRpmYXcQyIwvrxpvROSFr521NFoyr8YcwX7w208FV3spqmfvBSO+Jqm aQMXowggR9O61YPmrmDT6eXFLnULhTUzbaB3GYT55rh4bkqZZrw9I/Poi2j8DxaI 6wfTQasm4Hi2onyF1AgSpv7/uu4KnrR+FrYQfdkU0peCG1AYEcB8VUREfEOdHsUp ncVZtZsaFk7NXWPYt0ibdBZbI4uJM4NRAPvQGY4mAgKszZpBJPO7lYvaJIpJJ87C U9CQ4pIXC2ivgQ2jv5/Ti1vvBfbCwuD+9fUBy8yNZqi13E8El+Jo6WG5KhKCqhet kkgHOBM8EKPKMpWQIBSv1/mc+HE6NAVz6YPiy41emKSmU8cKwimfF/Zsm8eMsgGx aL7xEL4WRsgMGJaccRlCcTjk1ETROjMOgaGxBaacxq9QPIN0wKZvmti8HhsZdGsR 8FTQzY7fCmxB2m4S7tSdnIJ88W2glzJmWeHDGCgfcBDU80B1sbY= =u8iV -----END PGP SIGNATURE----- From brian at minton.name Wed Aug 14 20:30:31 2019 From: brian at minton.name (Brian Minton) Date: Wed, 14 Aug 2019 14:30:31 -0400 Subject: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key" In-Reply-To: <20190813182650.0D6E120120@smtp.hushmail.com> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812170927.CAC3420129@smtp.hushmail.com> <20190813182650.0D6E120120@smtp.hushmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I've often wondered why the sks software didn't require cross-certification. It seems like that would solve the key poisoning issue. It would mean that when signing someone's key, you'd have to have a way to exchange the signatures first, before submitting them to the keyserver network. However, I think that most keysigning parties do that anyway, not to mention software like caff. -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTu0BWAE9wubW4AHqQ3uVB6z/IBbgUCXVRTFwAKCRA3uVB6z/IB bqAKAQC4mzwJSUj52Wls65QJqOdZNFvEx8yozIeCDtb/+XWdtAD7BALPm3Z9/5oI ZAjPE5b9EX1sddZpdj2+DuvbKZKoDQeIdQQBEQgAHRYhBPnEu3YOeD8N7BCmimuO s6Blz7qpBQJdVFMvAAoJEGuOs6Blz7qpCMgA/35Ni8l2Cb/EdHP3AhmkbHJAVGHo 7AeDnRHGcgre6M1CAPwO8IoTd8l69z2Rn0YzXwakHfNQlp9+OPg6U+mUj9eImw== =v1zo -----END PGP SIGNATURE----- From johanw at vulcan.xs4all.nl Wed Aug 14 20:16:59 2019 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 14 Aug 2019 20:16:59 +0200 Subject: PGP Key Poisoner In-Reply-To: <6e51bc3e-5a05-e361-75fb-5c89eeb0b7e0@tana.it> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <875zn1e5sw.fsf@wheatstone.g10code.de> <6e51bc3e-5a05-e361-75fb-5c89eeb0b7e0@tana.it> Message-ID: <5D54501B.2070305@vulcan.xs4all.nl> On 14-08-2019 11:38, Alessandro Vesely via Gnupg-users wrote: > Of course, anonymous key poisoning is a kind of gratuitous vandalism. > Yet, crypto is supposed to work in a hostile environment. But this is only an extreme form of what an old keyserver already did: it issued (I believe every 6 months) a new signature. Arguments about DoS attacks were already given then. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Wed Aug 14 21:45:19 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 14 Aug 2019 15:45:19 -0400 Subject: Difficulty of fixing reconciliation In-Reply-To: <6a8b8772-0ffd-9589-126b-01088b80b6a6@gbenet.com> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <20190813145647.00007861.sac@300baud.de> <6a8b8772-0ffd-9589-126b-01088b80b6a6@gbenet.com> Message-ID: <7ef2cfa3-78a2-e4f5-e06f-2c7f9d650904@sixdemonbag.org> > Can you give me a valid reason why anyone would want their key signed by > 150,000 people or more?? How can you meet 150,000 people? Sure, if you can give me a valid reason why I *should* give you a valid reason. Seriously. I'm not a GnuPG developer. I don't run an SKS keyserver. I know a good bit about the internals of both, but I wasn't involved in the decisions and I'm getting really annoyed at people who expect me to be an apologist just because they mistakenly think I'm more involved than I am. Now that I've got that out of the way, welcome to the Zero-One-N rule. It's a rule of thumb in software engineering that says to either allow none of something, only one of something, or an arbitrary number of somethings. Either support no third-party signatures, one third-party signature, or arbitrary numbers of them. When the OpenPGP spec was developed *more than twenty years ago* it was decided to support arbitrary numbers of third-party signatures. GnuPG faithfully implements this spec, even though this policy has turned out to not be a good idea. If you want to be *productive*, get over on the IETF Working Group mailing list and start asking how the next draft of the spec is going to resolve this problem. That's where the problem began. That's where you need to solve it. From rjh at sixdemonbag.org Wed Aug 14 21:49:31 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 14 Aug 2019 15:49:31 -0400 Subject: was Re: PGP Key Poisoner // now "Binding one person's subkey to another person's primary key" In-Reply-To: References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812170927.CAC3420129@smtp.hushmail.com> <20190813182650.0D6E120120@smtp.hushmail.com> Message-ID: <065f33bb-d912-28bb-5696-95e62ec7b496@sixdemonbag.org> > I've often wondered why the sks software didn't require > cross-certification. It seems like that would solve the key poisoning > issue. Not enough OCaml programmers, mostly. Strange but true: SKS has no crypto code in it anywhere. So the moment you say "I wonder why SKS doesn't do this thing that involves crypto," well, that's the answer: because it involves crypto and nobody has ever added that capability to SKS. From wk at gnupg.org Wed Aug 14 22:12:19 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Aug 2019 22:12:19 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: <7ef2cfa3-78a2-e4f5-e06f-2c7f9d650904@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 14 Aug 2019 15:45:19 -0400") References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <20190813145647.00007861.sac@300baud.de> <6a8b8772-0ffd-9589-126b-01088b80b6a6@gbenet.com> <7ef2cfa3-78a2-e4f5-e06f-2c7f9d650904@sixdemonbag.org> Message-ID: <87a7cbbj6k.fsf@wheatstone.g10code.de> On Wed, 14 Aug 2019 15:45, rjh at sixdemonbag.org said: > developed *more than twenty years ago* it was decided to support > arbitrary numbers of third-party signatures. GnuPG faithfully At least OpenPGP has this: 5.2.3.17. Key Server Preferences (N octets of flags) This is a list of one-bit flags that indicate preferences that the key holder has about how the key is handled on a key server. All undefined flags MUST be zero. First octet: 0x80 = No-modify the key holder requests that this key only be modified or updated by the key holder or an administrator of the key server. GnuPG has always set this flag in anticipation that the keyservers will eventually come up with an authenticated upload method. As we all know the keyserver developers didn't considered that as a priority thing and thus we are at the state we are know. At the first and only keyserver conference in 2000 this topic had been on the agenda. Due to the burst of the dotcom bubble we never got together again and most thought that SKS was the way to go. Recall that it solved the problem with OpenPGP (HKP supported only 1 primary plus one subkey) and the performance problem. Since December 2013 it was pretty clear that the WoT and the keyservers will have scaling problems. 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 2017-r3sgs86x8e-lists-groups at riseup.net Thu Aug 15 00:32:20 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Wed, 14 Aug 2019 23:32:20 +0100 Subject: Difficulty of fixing reconciliation In-Reply-To: <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> Message-ID: <1945102635.20190814233220@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 14 August 2019 at 10:39:56 AM, in , Alessandro Vesely via Gnupg-users wrote:- > I'm no expert, but it seems to me that 3rd party > signatures should not > be allowed. Perhaps a "keyserver no-third-party-signatures" option would resolve this. Unlike "keyserver no-modify", honouring it would not require a keyserver to undertake any cryptographic checking. - -- Best regards MFPA However beautiful the strategy, you should occasionally look at the results. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXVSMAV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +oVAAP9lSV1dK1iQWIkm2edvSzRwSPSY0tDflMtQmNQ65gYRNgEAzVtumEK+Ju9k jHPNSTkkVQRm7s20GHOZOn1ZLgPASwCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXVSMAV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/28RD/4wRqb6Pt+We48Ahvk+L5191X5M DrjPHAq3hLombNaUTmXpRAb8Eg8cBebyPKMxUd2vjFWPKMBFGzhJY6YvpFoOa7aP huLsdyVMVn1TWJKGO15Q8yV6fc5nS6DLhfNjAytGad2jh9NjksHUh7j4xEyfBlFU C9BkhudbBLWwk+CqS/rw3LioT2g9JiYshq2U/HIh6NOzRtdelIfJCXI9S8vKmiYJ cvrL1TcBolntx3afmK5UdnUY+oLc64/Gh1pyuYixuCY829fhsE4mwPdgOzqhf/Ua k/o+RmUHE4xxCVrqJFNNknKAklgUjr5lWSPHvFfRrTJ+QKAxvdAeuNExSvub9Kg4 YUv4Khv4s4otrRFSRqhahnqciEehbK98x4L02/6sU2Agiork8ScyESaAI4RTy1GR QuHDPbdqYaI27ocek5VIgadjO3cjtOh8frlR94xOujcJTZk9DRLPGeBiKdlcHUFe zjCoM/ttbJWjGkoxm80/2ENiFvOeOqi7Bcdm0h+9ftpdMh2n2g89OOoXuOgljkKy 4NddgVAF2UBOZ3/fBu0tawhZdrnTcTcAsWCjPQ0hK7xb8wu8Xo640O5uRJZ+BEWn Cyi0JHc/FF4qIiI3GSV2WWbOEWxW7QDj/Fb2NgtwKyZbA1FOt59EzNFYMFxaFznC gHi1vm0nVDGGPqjvcA== =ChAv -----END PGP SIGNATURE----- From dan at savevsgeek.com Thu Aug 15 00:38:09 2019 From: dan at savevsgeek.com (Daniel Clery) Date: Wed, 14 Aug 2019 18:38:09 -0400 Subject: Key poisoning Message-ID: If the keyserver implemented a signer blacklist, (which would scrub the blacklisted signature from any current or incoming public keys), what consequences am I missing? In essence, shadowbanning a signing key. Keyservers without blacklist support would still pass around the toxic keys, but only until they get updated with the blacklist. The notion of nothing getting deleted is a feature (as nice as it would be to be able to nuke my keys from the 90s that never really got used to begin with). Masking out signatures from bad actors seems like a valid solution. It doesn't address all of the problems were seeing now (core infrastructure not in a maintainable state for the project, using effectively voodoo to do its job) But could be a start. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at gbenet.com Thu Aug 15 04:42:55 2019 From: david at gbenet.com (David) Date: Thu, 15 Aug 2019 03:42:55 +0100 Subject: looking for assistance tracking down why i don't have the ability to run gpg from the command line In-Reply-To: <4aeaaa70-a800-ba0a-6500-e86af0048aeb@simons-rock.edu> References: <4aeaaa70-a800-ba0a-6500-e86af0048aeb@simons-rock.edu> Message-ID: <6dbc3989-c781-f14e-e73b-3f44cc244b1e@gbenet.com> On 14/08/2019 16:30, charlie derr wrote: > I'm running debian 10 buster (upgraded recently from stretch if that > matters) and i use KDE. I haven't yet tried to logout of my desktop > environment completely (and just use a native console), but I thought > I would see if any of you had any ideas. Here's the problem: > > ni at quark:~/.ssh$ gpg --list-keys > gpg: checking the trustdb > gpg: waiting for lock (held by 22009) ... > gpg: waiting for lock (held by 22009) ... > gpg: waiting for lock (held by 22009) ... > ^C > gpg: signal Interrupt caught ... exiting > > ni at quark:~/.ssh$ ps aux | grep 22009 > ni 7740 0.0 0.0 6076 892 pts/6 S+ 11:21 0:00 grep > 22009 > ni 22009 2.0 0.2 89404 78536 ? RL 02:51 10:30 gpg > --batch --no-sk-comments --status-fd 104 --no-tty --charset utf8 > --enable-progress-filter --exit-on-status-write-error --display :0 > --logger-fd 108 --with-colons --list-keys -- > 4E2247974AA5A23A5C92BB4DBB8B3D7331A9367F > ni at quark:~/.ssh$ kill 22009 > ni at quark:~/.ssh$ gpg --list-keys > gpg: checking the trustdb > gpg: waiting for lock (held by 28999) ... > gpg: waiting for lock (held by 28999) ... > gpg: waiting for lock (held by 28999) ... > > as you can see, killing the offending process doesn't work (as it > respawns immediately) > > The reason this is important to me right now is because I have a new > laptop and I'm trying to transfer my keys to it. I have an email from > this list sent by Robert J. Hansen on 9/14/2016 that has excellent > instructions (which I've used in the past for this purpose) but the > 1st command in those instructions: > > gpg --armor --export > > dumps a lot of output to the command line but never "finishes" (and my > guess is that it's the same lock that's preventing that command from > completing). > > thanks so very much in advance for your time, > ~c > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Hello Charlie, On Debian 10 busty - which I have now - you have "root" I simply log into root open the home folder go to user name folder list hidden files - then select the .gpg folder and copy that to a USB. You can do a weekly backup to USB. Then you can add it to whatever you want - but be in root to change the ownership to whatever the users called. when I do a --list-users t lists all my 186 keys :) David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From jharris at widomaker.com Thu Aug 15 06:02:41 2019 From: jharris at widomaker.com (Jason Harris) Date: Thu, 15 Aug 2019 00:02:41 -0400 Subject: Difficulty of fixing reconciliation In-Reply-To: <1945102635.20190814233220@my_localhost_LG> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> <1945102635.20190814233220@my_localhost_LG> Message-ID: > On Aug 14, 2019, at 6:32 PM, MFPA via Gnupg-users wrote: > On Wednesday 14 August 2019 at 10:39:56 AM, in > , Alessandro Vesely > via Gnupg-users wrote:- > >> I'm no expert, but it seems to me that 3rd party >> signatures should not >> be allowed. > > Perhaps a "keyserver no-third-party-signatures" option would resolve > this. Unlike "keyserver no-modify", honouring it would not require a > keyserver to undertake any cryptographic checking. No, then the ?attack? just changes to making the issuing keyid = the keyid being attacked, so everything looks like a selfsig... But at least then we will want to add cryptography to see which selfsigs are truly legitimate, right? Sent from my iPad From andrewg at andrewg.com Thu Aug 15 08:07:34 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 15 Aug 2019 07:07:34 +0100 Subject: Key poisoning In-Reply-To: References: Message-ID: <9B2C2E8C-669E-4E0B-95F2-063AE03396A7@andrewg.com> > On 14 Aug 2019, at 23:38, Daniel Clery wrote: > > If the keyserver implemented a signer blacklist, (which would scrub the blacklisted signature from any current or incoming public keys), what consequences am I missing? This is known as ?enumerating badness? and it doesn?t scale. You would only be able to identify a bad actor after its actions are noticed - by a human being. Also, if thousands of separate keys have signed another key, making it unusable, how do we decide which of those thousands of keys are legit and which the bad actors? Generating lots of keys on modern hardware is not difficult. A From rjh at sixdemonbag.org Thu Aug 15 08:50:14 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 15 Aug 2019 02:50:14 -0400 Subject: Key poisoning In-Reply-To: References: Message-ID: > If the keyserver implemented a signer blacklist, (which would scrub the > blacklisted signature from any current or incoming public keys), what > consequences am I missing? Someone already chimed in about how this is "enumerating badness", which runs counter to best practices in security. Additionally, the bad guys can create new malicious certificates faster than the keyserver network can blacklist. From peter at digitalbrains.com Thu Aug 15 11:26:31 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 15 Aug 2019 11:26:31 +0200 Subject: Key poisoning In-Reply-To: References: Message-ID: On 15/08/2019 08:50, Robert J. Hansen wrote: > Additionally, the bad guys can create new malicious certificates faster > than the keyserver network can blacklist. Plus, the attacker could just create a signature that looks likely to be real (self-sig or existing third-party sig seems a good candidate). Only when actually doing the cryptographic verification will it turn out to be fake anyway. By that time the amount of processing GnuPG has done is already enough for the denial of service. I think the attacker only used cryptographically valid signatures because it was easier to use existing tooling. There is no reason for the poison to be cryptographically valid. It just has to be slightly expensive to verify. GnuPG doesn't even get to the bit where the signature is validated, since the signing key isn't on the keyring, and still, we have this DoS. 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 Thu Aug 15 11:48:37 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 15 Aug 2019 11:48:37 +0200 Subject: My mails to rjh bounce In-Reply-To: References: Message-ID: <742e0f5d-a45f-d94c-f23b-a3009d9b6c15@digitalbrains.com> By the way, I keep intending to put this as a PS on a proper mail, but I always forget. All my mails to Rob keep bouncing. The first bounce was June 30th. I'm not including the bounce message here on the off chance that there is something non-public about Robs mail infrastructure :-). So Rob can find it encrypted to him at [1]. All those bounced mails were also addressed to the mailing list, so he got a chance to read them anyway... Cheers, Peter. [1] -- 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 Thu Aug 15 12:43:42 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 15 Aug 2019 12:43:42 +0200 Subject: looking for assistance tracking down why i don't have the ability to run gpg from the command line In-Reply-To: <4aeaaa70-a800-ba0a-6500-e86af0048aeb@simons-rock.edu> References: <4aeaaa70-a800-ba0a-6500-e86af0048aeb@simons-rock.edu> Message-ID: <93c29802-2f9f-13db-26cd-b22e4a736240@digitalbrains.com> Hello, > ni at quark:~/.ssh$ ps aux | grep 22009 > ni 7740 0.0 0.0 6076 892 pts/6 S+ 11:21 0:00 grep > 22009 > ni 22009 2.0 0.2 89404 78536 ? RL 02:51 10:30 gpg > --batch --no-sk-comments --status-fd 104 --no-tty --charset utf8 > --enable-progress-filter --exit-on-status-write-error --display :0 > --logger-fd 108 --with-colons --list-keys -- > 4E2247974AA5A23A5C92BB4DBB8B3D7331A9367F That doesn't show which process is starting that gpg. I would start by doing $ ps fax | less and then from within less type for instance /22009 which will search for the line containing that PID. Then you can see its ancestry (the f option makes a -f-orest of parent/child relations). There are more ways to investigate, but this seems a good start. 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 wk at gnupg.org Thu Aug 15 21:33:40 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Aug 2019 21:33:40 +0200 Subject: Difficulty of fixing reconciliation In-Reply-To: (Jason Harris via Gnupg-users's message of "Thu, 15 Aug 2019 00:02:41 -0400") References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> <1945102635.20190814233220@my_localhost_LG> Message-ID: <87muga9qaz.fsf@wheatstone.g10code.de> On Thu, 15 Aug 2019 00:02, gnupg-users at gnupg.org said: > But at least then we will want to add cryptography to see which > selfsigs are truly legitimate, right? That would be the first and most important step to get the keyservers back for the WoT 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 Thu Aug 15 21:48:50 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Thu, 15 Aug 2019 20:48:50 +0100 Subject: Key poisoning In-Reply-To: References: Message-ID: <138482902.20190815204850@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 15 August 2019 at 10:26:31 AM, in , Peter Lebbing wrote:- > Plus, the attacker could just create a signature that > looks likely to be > real (self-sig or existing third-party sig seems a > good candidate). Would the attack work by just concatenating lots of identical signature packets onto a copy of the target key and sending the result to the keyserver? - -- Best regards MFPA An obstinate man does not hold opinions. They hold him. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXVW3MV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +ncpAQDhG3HrT17ZNRCddaPh4Mz+PDmDzoYA8g5TgSsrP2UecQEAswc8FBOdRJku sPjNfiQaWyQSPHLnWNDkccPTywm+vgCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXVW3MV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/1tfD/sFEf1QzMMnhDOZMt+RAhHMp3Va TcM3O8g9453Hb1eFkkIa+7lZCox4S4uDAVa4eKwhmqnhv9HTDlRFrxYR1d+rXWn7 7XcwdgsBdMlJxZ0YIDSXdEXuNzcokQlIvLhcf4qhx9jY3v/+3hd1luNjzb/sYWr4 j5nErWrFywQD5BWh9kFa6hMisrfVNTSo0Tb2R3HwUej97iwcuwVdu/6dIW3uSUFt MACQDmYNvWJqw/Rvjb+YKt7L5E/yY+47tO++Izm+cYvSYUM/DqDFLayvOVLtT/Wl JGGwpxbdaBmk41t4wnpp8c0bpoZuAVgylAzk39Yal67yIOzcEipcyupqNlPupcVd 79h+1j48KweDrvHdHw2smaHsbSJOSPWpZBwpzeveMHKqiavmoFpY3BVzEwZYU7wq dTTG55z3dnFkcUiWzNzzr/6HRPRMkgYSX+1YDdCeSdDrtTguOyDmK9nUJDoDyvvZ r70sgftCF54j4jK2Xq/B2mj0bHbQvkPi9kEwXUU+VaPWyWtlki8V5vL4HFypTdrh eWVrwdbvDSaaxnIrjlyrxMOpjvAQ/2tYFSJgOA2jjAFqDYDBtFqJwCLWMc0Ksohq 5S2KNxhOcxRfR32QgYDHj9k1AtYjDDCfz9MMemr8B13zgALLFSJYTVpOUf2cSo3X cIlFh2czPTfUlsL3Nw== =GjEU -----END PGP SIGNATURE----- From 2017-r3sgs86x8e-lists-groups at riseup.net Thu Aug 15 21:50:37 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Thu, 15 Aug 2019 20:50:37 +0100 Subject: Key poisoning In-Reply-To: <9B2C2E8C-669E-4E0B-95F2-063AE03396A7@andrewg.com> References: <9B2C2E8C-669E-4E0B-95F2-063AE03396A7@andrewg.com> Message-ID: <146617262.20190815205037@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 15 August 2019 at 7:07:34 AM, in , Andrew Gallagher wrote:- > Also, if thousands of > separate keys have > signed another key, making it unusable, how do we > decide which of > those thousands of keys are legit and which the bad > actors? > Generating lots of keys on modern hardware is not > difficult. Does the attacker even keep the same signing keys to use again? Each key could be dumped after adding its signature to the target key. The suggested blacklist could soon grow to be a crippling overhead for the keyserver. - -- Best regards MFPA Beware the deadly donkey falling slowly from the sky -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXVW3jV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +p0hAP41O5yaJ515MrR96zg9Q9I10Cuy54lSrIk+ZHZkvROcRwEAwO+sl8WbImDE MWOPszYYgh55/IKsyL4CMCyVIPP44QaJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXVW3jV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/xtjD/9CrOG0mu655f6EWK69mRlRcclj J4dXznJ1HFy7WC3pV9/mEhBjgVIvsHGv/IMQzx7oQSm8Q6e+iY7OvK4gp1sRZ5Gt q8GUVW2L3uzXaGO2XDWOP3JnMwg1VPGLfF6XbV9Kzr02Rg/kcAaeffefYWfSUSJr P9oBfFut5BeBbEAJE6AZdgBnccRJWOOtd19haHEBnhS4wb2pCUA4J6h1760Tg2Nv 1IrjICnz2w20gLxbUKJkwZGpA5fg5rRVOAjPWGtBqzVCgW11/KhoNg9/5EOjdmau bOo2PpXj5evSzF7HB715Ivf/Yp7AnJIe8QNvkFa7gHylt1R2WRZ4bmhehHE0UWFD zs7ga3ynxquYWFe+IM4eOXmwVjdAU/IuxigztPSsyvdB9zg+oL/ADO4TzPd8+aDY xURX8tTMPVuI8ETfxQFcrVyk5gGcPvqUaE/t/AfnbjbCqacqmUNxdRC9jF7ArNP3 +F6RNorFKaDQj/30pG4nqSX7uHfoq2rOZifSmhIXmHToIVUcKxXKamWeJ3V3xgLg PVD0Igan1TbuU6L74fUYZAQq1diz3Ab4VaD2QjVfkVKW4Co02tbJDtTEPY5QMuPK XD3e++TNJVXBsteEI7Vg0M/G3ZM4OSC4PvS953PrnngkQ4LOrHY3D6HiavD+tlbf c9VUzHfbfULsmlVqpA== =Gz3/ -----END PGP SIGNATURE----- From jharris at widomaker.com Fri Aug 16 00:44:53 2019 From: jharris at widomaker.com (Jason Harris) Date: Thu, 15 Aug 2019 18:44:53 -0400 Subject: Difficulty of fixing reconciliation In-Reply-To: <87muga9qaz.fsf@wheatstone.g10code.de> References: <5c994780-22b8-5cd0-d858-214b9598c469@bruckner.tk> <20190812165434.00006251.sac@300baud.de> <20190812183938.00003bdc.sac@300baud.de> <4dfa11c7-ac5a-2d4d-360f-fb451794b89b@tana.it> <33b6296c-8619-dab1-d83d-d67b9d5cba2f@tana.it> <1945102635.20190814233220@my_localhost_LG> <87muga9qaz.fsf@wheatstone.g10code.de> Message-ID: <7C333193-61DE-4AA0-87FF-5AEB5510F6E9@widomaker.com> > On Aug 15, 2019, at 3:33 PM, Werner Koch wrote: > > On Thu, 15 Aug 2019 00:02, gnupg-users at gnupg.org said: > >> But at least then we will want to add cryptography to see which >> selfsigs are truly legitimate, right? > > That would be the first and most important step to get the keyservers > back for the WoT Actually, I think hockeypuck might be validating selfsigs already: https://github.com/hockeypuck/openpgp/blob/v1/pubkey.go when it calls CheckSig(). (It isn?t that hard to install and loads most of the SKS keydump keys, but you do need PostgreSQL and then to sync with SKS to get the remaining (malformed) keys that apparently didn?t get imported from the dump.) Sent from my iPad -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at gbenet.com Fri Aug 16 10:53:14 2019 From: david at gbenet.com (David) Date: Fri, 16 Aug 2019 09:53:14 +0100 Subject: "There's always light..........." Message-ID: <0f193271-d7a7-dd34-5f6a-e6b867705208@gbenet.com> Hi All, Many moons ago I added the line "there's always light at the end of the tunnel" in my postmaster key pair. But when crating my new keys - I'd completely forgotten how to do this. I read the GPG Manual and could find no reference to this. Am wondering now that I've created the keys - can I add a comment? If so what is the command?? Cheers David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From johndoe65534 at mail.com Fri Aug 16 11:38:53 2019 From: johndoe65534 at mail.com (john doe) Date: Fri, 16 Aug 2019 11:38:53 +0200 Subject: "There's always light..........." In-Reply-To: <0f193271-d7a7-dd34-5f6a-e6b867705208@gbenet.com> References: <0f193271-d7a7-dd34-5f6a-e6b867705208@gbenet.com> Message-ID: <4bd53f48-b0fa-e164-cd29-3b179919bd20@mail.com> On 8/16/2019 10:53 AM, David wrote: > Hi All, > > Many moons ago I added the line "there's always light at the end of the > tunnel" in my postmaster key pair. > > But when crating my new keys - I'd completely forgotten how to do this. > I read the GPG Manual and could find no reference to this. > > Am wondering now that I've created the keys - can I add a comment? If so > what is the command?? > Have a look here: https://security.stackexchange.com/questions/67796/adding-a-comment-to-pgp-mail-signature-files A better comment would be the URL where to download your public key. If you are talking about the comment in your UID, you would need to creat a new UID to do that but you are better off without the one that you want to use or without a comment altogether. -- John Doe From peter at digitalbrains.com Fri Aug 16 12:16:17 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 16 Aug 2019 12:16:17 +0200 Subject: Key poisoning In-Reply-To: <138482902.20190815204850@my_localhost_LG> References: <138482902.20190815204850@my_localhost_LG> Message-ID: <8f0152a6-b395-71da-e188-d07306f0811d@digitalbrains.com> Hi MFPA, > Would the attack work by just concatenating lots of identical > signature packets onto a copy of the target key and sending the result > to the keyserver? I have no knowledge of the workings of the keyservers. But my guess is that they would all be coalesced into the single signature that they are (similarly to when a single new signature was uploaded to two different SKS keyservers and these are coalesced on reconciliation). It might be possible if you just change some bytes. I dunno. 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 wiktor at metacode.biz Fri Aug 16 12:53:06 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Fri, 16 Aug 2019 12:53:06 +0200 Subject: "There's always light..........." In-Reply-To: <4bd53f48-b0fa-e164-cd29-3b179919bd20@mail.com> References: <0f193271-d7a7-dd34-5f6a-e6b867705208@gbenet.com> <4bd53f48-b0fa-e164-cd29-3b179919bd20@mail.com> Message-ID: On 16.08.2019 11:38, john doe wrote: > A better comment would be the URL where to download your public key. Even better would be using "--sig-keyserver-url" to embed the URL in an appropriate packet. Details here: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html Note that unless "honor-keyserver-url" is set in the config explicitly this is not used by default by GnuPG (see comments about "auto-key-retrieve" here: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html ). And, if the key is available via WKD using "--sender $EMAIL" as GnuPG can fetch the missing key over WKD (using only --auto-key-retrieve). Kind regards, Wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From david at gbenet.com Fri Aug 16 14:30:44 2019 From: david at gbenet.com (David) Date: Fri, 16 Aug 2019 13:30:44 +0100 Subject: "There's always light..........." In-Reply-To: References: <0f193271-d7a7-dd34-5f6a-e6b867705208@gbenet.com> <4bd53f48-b0fa-e164-cd29-3b179919bd20@mail.com> Message-ID: <94aa7e14-b49c-f1ad-b8a9-40d02cff618e@gbenet.com> On 16/08/2019 11:53, Wiktor Kwapisiewicz via Gnupg-users wrote: > On 16.08.2019 11:38, john doe wrote: >> A better comment would be the URL where to download your public key. > > Even better would be using "--sig-keyserver-url" to embed the URL in an > appropriate packet. > > Details here: > https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html > > Note that unless "honor-keyserver-url" is set in the config explicitly > this is not used by default by GnuPG (see comments about > "auto-key-retrieve" here: > https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html > ). > > And, if the key is available via WKD using "--sender $EMAIL" as GnuPG > can fetch the missing key over WKD (using only --auto-key-retrieve). > > Kind regards, > Wiktor > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Thank you Wiktor, There's no examples how to use the --comment command - I've tried various options - aall confuse gpg/gpg2 :) All I want to do is add a comment in site-admin "The captain's (B)log" open and closed brackets (B)Log confuse gpg/2 even more. Being a bit "eccentric" david at gbenet.com "One Flew Over the Cookoo's Nest" would be good :) Would the --comment command add it to the private and public key?? There's very little info on the usage of the command or what it actually does. Regards David -- People Should Not Be Afraid Of Their Government - Their Government Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og" https://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x459E3AE3EA13E1A3.asc Type: application/pgp-keys Size: 3057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Fri Aug 16 19:41:11 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Fri, 16 Aug 2019 18:41:11 +0100 Subject: "There's always light..........." In-Reply-To: <94aa7e14-b49c-f1ad-b8a9-40d02cff618e@gbenet.com> References: <0f193271-d7a7-dd34-5f6a-e6b867705208@gbenet.com> <4bd53f48-b0fa-e164-cd29-3b179919bd20@mail.com> <94aa7e14-b49c-f1ad-b8a9-40d02cff618e@gbenet.com> Message-ID: <1313297525.20190816184111@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 16 August 2019 at 1:30:44 PM, in , David wrote:- > Would the --comment command add it to the private and > public key?? I think it would maybe add it at the top of an ascii armoured keyblock, after the "-----BEGIN PGP PUBLIC KEY BLOCK-----" line. > There's very little info on the usage of the command > or what it actually > does. Try - -- Best regards MFPA If you save the world too often, it begins to expect it -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXVbqzV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +gciAP9SBUVYCFwnLKNux/Fn+sEcHrpJi/vvhui41NPLBuOj8QD/e8PDHQxMBiW5 R5cPSTrujbsdcvQGFoPyfkMg9seA6AKJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXVbqzV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/01lD/9+SChFZ1RMtp2J4EmEwOm1kDSt bvLyNn2XaEcay9ldP93ONtreiA1CExuyXa3YHX5x5WXBLjGcOogEshviihgywFmP Mdxceu/+ZEUuWXHXCqT4mDRLIrKo1maSCw0yKAIIqGs5yh8nI/dwI7RHDm3pD/83 2Uk4fCC3/uGj4tXz5PcoanMOkmuecg6DJPSICTaJXe6i9F1UtDXZBCRDkievM7DW LvxyIvGAUGMlqZ/PvS8O/0LDaXuyIWJ2xlU2UVHYDFzc1DmPd2AXyYx0A/jzOZlY MIyrBvyeSKAFP2urR5ddQN5EHPzSznmHDFybVEZqdHY2cwJP9cLEIBlJmODACtYb Xg3Ms1xFeCjbOTazK9N8ZWAI/hjti3HSuDXiTXfbntkV7/UbJnLSfL8BzabxSR/1 gFl9qmCEg3zLaKKRQmhJYriQXAK1ItQbgt9MgN2vxTKOpTLnNX+4wRaMuZTadzQ0 Ok5yDoUA+je9mRNNoJ2rM1HgUwDlnsrYzSMtq0HCdMkYAJBo8hX1tBW3cxq/BOJB Q8uA/jzCK7reZaeRJhtD1HPx+PwKvOBr/wAuuQxSbuAXAmbL3mRWwaFBvnN0Vsqc XdwiB2IAuo71MCSjhVLs9PaRz9/X3Phh7nGIRxJDM/hhQ/urPopw8X5I/XCoXD+y 4UA0i1yHpq3SpJo4Uw== =HcKA -----END PGP SIGNATURE----- From tomasz at debian.org Sat Aug 17 18:45:24 2019 From: tomasz at debian.org (Tomasz Buchert) Date: Sat, 17 Aug 2019 18:45:24 +0200 Subject: Storing custom signed data in the key Message-ID: <20190817164524.GA5617@noether> Hey Gnupg users, what would be the most "canonical" way to store arbitrary, signed data along the gpg key? And then: what is the programmatic way of extracting said data? My specific usecase is putting a signify [1] public key inside my GPG key, so that I can leverage key distribution to push my signify key. After some digging, I was able to add a "notation" to one of my UIDs, using "edit-key" + "notation", and now I have a signed notation inside a self-sig. See: $ gpg --no-options --list-options show-notation --check-sigs KEYID | grep pub at signify Signature notation: pub at signify=SIGNIFYKEY This extraction process seems dangerous to me, however, since an attacker could add a dummy signature on my key with the same notation. I can improve the above by interpreting the input more thoroughly, since the notation follows the signature info: sig!3 N KEYID 2019-08-17 User Example Signature notation: pub at signify=SIGNIFYKEY By checking the signature verification status ("sig!") and KEYID I can ensure that the notation is valid. Does it make sense? Is it a good idea? What would be a better way? Cheers, Tomasz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wiktor at metacode.biz Sat Aug 17 22:19:43 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Sat, 17 Aug 2019 22:19:43 +0200 Subject: Storing custom signed data in the key In-Reply-To: <20190817164524.GA5617@noether> References: <20190817164524.GA5617@noether> Message-ID: Hi Tomasz, > what would be the most "canonical" way to store arbitrary, signed data > along the gpg key? And then: what is the programmatic way of extracting > said data? > (...) > sig!3 N KEYID 2019-08-17 User Example > Signature notation: pub at signify=SIGNIFYKEY > > > Does it make sense? Is it a good idea? What would be a better way? Yep, that definitely makes sense and notations are a good way to store additional data. The only problem here is how to get the notation values programmatically in a way that you know the self-signature is valid. Sadly "gpg --list-options show-notations --with-colons --list-keys $KEY" does not print the notation output. I did use OpenPGP.js to verify signature and extract notations for a small project of mine (https://metacode.biz/openpgp/proofs example here: https://metacode.biz/@wiktor ) but I understand you want to keep the dependencies to the minimum. Maybe you could use GpgME, the docs look promising: > The signature notations on a key signature are only available if the key was retrieved via a listing operation with the GPGME_KEYLIST_MODE_SIG_NOTATIONS mode enabled, because it can be expensive to retrieve all signature notations. Source: https://www.gnupg.org/(es)/documentation/manuals/gpgme/Key-objects.html#Key-objects One minor thing, you may want to adjust the notation name (key). RFC 4880 advises e-mail-like key where the domain is a name you control. So for example "pub-signify at debian.org" if you control "debian.org". Additionally it would be nice to have the e-mail redirect to a human in case someone sends the message there. Kind regards, Wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dan at savevsgeek.com Sun Aug 18 00:05:31 2019 From: dan at savevsgeek.com (Daniel Clery) Date: Sat, 17 Aug 2019 18:05:31 -0400 Subject: Key poisoning Message-ID: Thanks - I knew I was being naive. Is it correct that the thesis that describes the fundamentals of the current reconciliation algorithm is 'Spreading Rumors Cheaply, Quickly, and Reliably'? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionic at ionic.de Sun Aug 18 08:24:02 2019 From: ionic at ionic.de (Mihai Moldovan) Date: Sun, 18 Aug 2019 08:24:02 +0200 Subject: Generating bitwise identical keyrings with GnuPG 1 + 2 Message-ID: <0889c2f9-b8ac-eb76-f65c-2d1666ad21e4@ionic.de> Hi I am working on a software package alike to Debian's debian-archive-keyring. Within that, public keys are stored in a jetring-compatible format. At build time, these keys are essentially read/imported and concatenated in a non-kbx-keyring. Maintainers, for sanity, are supposed to build the keyrings locally and sign them. The signature (only) is then included in the package. At build time, the keyrings are generated on-the-fly using jetring and the signature checked. Obviously, for this to work correctly, the generated keyrings must be bitwise identical. Now the fun part: gpg 1.4 (which is used by older distro versions... and even if it weren't, I'd only have gpg 2.0 as an alternative which likewise doesn't include the changes from 2.1) and 2.2 generate different data and I'm trying to find a way to get 2.2 to generate identical data to what 1.4 would spit out. All of this is best illustrated by an example, emulating what jetring-build would do (for sake of simplicity, I'll use file sizes here, even if that is not a replacement for secure hash functions, of course): rm -f keyringfile-gpg2.2.gpg* # It took me quite a while to figure out that this is CRUCIAL. If the target # keyring does not exist, gpg 2.1+ will create new keybox files by default. # If it exists, however, they will just append data to the (empty) keyring when # importing keys, which more or less corresponds to the old keyring format. touch keyringfile-gpg2.2.gpg # The tail ... pipe just reads in ASCII-armored public key data. for i in active-keys/add-{d,n,g,X}*; do gpg2 --command-fd 0 --no-auto-check-trustdb --options /dev/null --no-default-keyring --batch --yes --keyring ./keyringfile-gpg2.2.gpg --secret-keyring ./seckeyring.gpg --import <(tail -n +5 $i | sed -e 's/^ \+//g'); done; rm -f keyringfile-gpg2.2.gpg~ wc -c keyringfile-gpg2.2.gpg Output: gpg: key E1F958385BFE2B6E: public key "X2go Debian/Ubuntu Packaging " imported gpg: Total number processed: 1 gpg: imported: 1 gpg: key C509840B96F89133: public key "Oleksandr Shneyder " imported gpg: Total number processed: 1 gpg: imported: 1 gpg: key F4A7678C9C6B0B2B: public key "X2go Git Administrator " imported gpg: Total number processed: 1 gpg: imported: 1 gpg: key 817F33270D65FBF2: public key "X2Go Packages Automatic Signing Key " imported gpg: Total number processed: 1 gpg: imported: 1 5521 keyringfile-gpg2.2.gpg Okay, good. That's about the same thing jetring-build would have done, with minor difference that we don't care about. For instance, jetring-build would run each import command in a new, empty, temporary GNUPGHOME environment and also put seckeyring.gpg in there. It doesn't matter here because we'll not be using anything within GNUPGHOME anyway and have no secret keys. Now, gnupg 2.1.14 introduced a new filter functionality that can be used to sanitize keyrings and remove "bad" data. Let's use that: gpg2 --no-options --no-default-keyring --no-auto-check-trustdb --trustdb-name ./trustdb.gpg --no-keyring --import-options import-export --import < ./keyringfile-gpg2.2.gpg > ./keyringfile-gpg2.2.gpg.san wc -c keyringfile-gpg2.2.gpg.san Output: gpg: Total number processed: 4 5345 ./keyringfile-gpg2.2.gpg.san This is the final keyring I care for, generated with gpg 2.2 and sets our baseline. 5345 bytes in size. Let's do the same thing with gpg 1.4: rm -f keyringfile-gpg1.4.gpg* # Not actually needed for 1.4, but better safe than sorry. touch keyringfile-gpg1.4.gpg for i in active-keys/add-{d,n,g,X}*; do gpg1 --command-fd 0 --no-auto-check-trustdb --options /dev/null --no-default-keyring --batch --yes --keyring ./keyringfile-gpg1.4.gpg --secret-keyring ./seckeyring.gpg --import <(tail -n +5 $i | sed -e 's/^ \+//g'); done; rm -f keyringfile-gpg1.4.gpg~ wc -c keyringfile-gpg1.4.gpg Output (I'll drop gnupg's output since that is not interesting): 5377 keyringfile-gpg1.4.gpg Crap, that doesn't match the previous 5521 bytes as generated by gpg 2.2. Sanitizing the keyring is also difficult, because 1.4 naturally doesn't have the import-export import functionality/filter, but just for the sake of it, we'll try to emulate it: gpg1 --no-options --no-default-keyring --no-auto-check-trustdb --trustdb-name ./trustdb.gpg --keyring ./keyringfile-gpg1.4.gpg --export | gpg1 --no-options --no-default-keyring --no-auto-check-trustdb --trustdb-name ./trustdb.gpg --keyring ./keyringfile-gpg1.4.gpg.san --import; rm -f keyringfile-gpg1.4.gpg.san~ wc -c keyringfile-gpg1.4.gpg.san Output: 5377 keyringfile-gpg1.4.gpg.san Crap2, this seems to essentially have been a no-op, and it's confirmed by checksums: c0943200ee62d1b2cac320e53d19a8d07f3d66c7f0f3d36d95a0b96dcb982024 *keyringfile-gpg1.4.gpg c0943200ee62d1b2cac320e53d19a8d07f3d66c7f0f3d36d95a0b96dcb982024 *keyringfile-gpg1.4.gpg.san Also note that the keyring generated by gpg1 doesn't match neither the first keyring generated by gpg 2.2 nor the sanitized one. I wonder what would happen if we'd just take the sanitized version generated by 2.2 and read it through gpg 1.4... gpg1 --no-options --no-default-keyring --no-auto-check-trustdb --trustdb-name ./trustdb.gpg --keyring ./keyringfile-gpg2.2.gpg.san --export | gpg1 --no-options --no-default-keyring --no-auto-check-trustdb --trustdb-name ./trustdb.gpg --keyring ./keyringfile-gpg1.4.from2.2san.gpg --import; rm -f keyringfile-gpg1.4.from2.2san.gpg~ wc -c keyringfile-gpg1.4.from2.2san.gpg Output: 5377 keyringfile-gpg1.4.from2.2san.gpg Oh, interesting. Same size as all the other keyring files generated through gpg 1.4. Does the checksum match as well? c0943200ee62d1b2cac320e53d19a8d07f3d66c7f0f3d36d95a0b96dcb982024 *keyringfile-gpg1.4.gpg c0943200ee62d1b2cac320e53d19a8d07f3d66c7f0f3d36d95a0b96dcb982024 *keyringfile-gpg1.4.from2.2san.gpg So, to summarize, if I process a keyring file generated by gpg 2.2 with a 1.4 binary, i.e., read-in the former, export all keys and import it again, gpg 1.4 generates exactly the same file as it would when importing the keys directly. I'm looking for a way to generate exactly the same file through gpg 2.2, though. Is that possible? Not having to force maintainers to install gpg 1.4 would be great. Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From ilf at zeromail.org Sun Aug 18 18:06:13 2019 From: ilf at zeromail.org (ilf) Date: Sun, 18 Aug 2019 18:06:13 +0200 Subject: how to recover secret key passphrase? Message-ID: <20190818160613.GH6070@zeromail.org> Over the years, I have used quite a number of keypairs. Unfortunately, I have forgotten the passphrase for some of them. But I do know potential parts of the passphrase. What's the current recommended way to recover the passphrase of OpenPGP private keys? The classic John the Ripper includes a tool "gpg2john" to convert ASCII-armored exported private keys to a format that john can work with: http://blog.atucom.net/2015/08/cracking-gpg-key-passwords-using-john.html However, to export a private key from the current private-keys-v1.d/ gpg-agent key store, I need my passphrase. Which I can't remember. I would welcome any hints on how to achieve this. According to Kerckhoffs's principle, this can be public knowledge, in contrast to "security through obscurity". But if you feel like this is sensible, feel free to answer me directly instead of the list. Thanks! -- ilf If you upload your address book to "the cloud", I don't want to be in it. From ml at mareichelt.com Tue Aug 20 18:25:52 2019 From: ml at mareichelt.com (Markus Reichelt) Date: Tue, 20 Aug 2019 18:25:52 +0200 Subject: how to recover secret key passphrase? In-Reply-To: <20190818160613.GH6070@zeromail.org> References: <20190818160613.GH6070@zeromail.org> Message-ID: <20190820162552.GA25098@pc21.mareichelt.com> * ilf wrote: > Over the years, I have used quite a number of keypairs. Unfortunately, I > have forgotten the passphrase for some of them. But I do know potential > parts of the passphrase. This is ancient, but may help you https://www.vanheusden.com/nasty/ -- left blank, right bald From ilf at zeromail.org Tue Aug 20 18:53:52 2019 From: ilf at zeromail.org (ilf) Date: Tue, 20 Aug 2019 18:53:52 +0200 Subject: how to recover secret key passphrase? In-Reply-To: <20190820162552.GA25098@pc21.mareichelt.com> References: <20190818160613.GH6070@zeromail.org> <20190820162552.GA25098@pc21.mareichelt.com> Message-ID: <20190820165352.GQ6070@zeromail.org> Markus Reichelt: >> Over the years, I have used quite a number of keypairs. Unfortunately, I >> have forgotten the passphrase for some of them. But I do know potential >> parts of the passphrase. > This is ancient, but may help you https://www.vanheusden.com/nasty/ Thanks. But my problem is not the actual brute-forcing part, john is perfect for that. My problem is getting a usable input for john from the current the current private-keys-v1.d/ gpg-agent private key key store format. -- ilf If you upload your address book to "the cloud", I don't want to be in it. From vedaal at nym.hush.com Tue Aug 20 19:46:44 2019 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 20 Aug 2019 13:46:44 -0400 Subject: how to recover secret key passphrase? In-Reply-To: <20190820165352.GQ6070@zeromail.org> References: <20190818160613.GH6070@zeromail.org> <20190820162552.GA25098@pc21.mareichelt.com> <20190820165352.GQ6070@zeromail.org> Message-ID: <20190820174644.51730E0796@smtp.hushmail.com> On 8/20/2019 at 12:57 PM, "ilf" wrote: > My problem is getting a usable input for john >from the current the current private-keys-v1.d/ gpg-agent private key key >store format. ===== Try This: [1] Open a new terminal command prompt window [2] Type gpg -a --export-secret-key keyname The private key block should then appear in your terminal window. No passphrase is necessary unless you want to 'edit' the key. This works in both GnuPG 1.x and 2.x assuming that your keyrings are in your home directory. Don't use gpg-agent for this. vedaal From peter at digitalbrains.com Wed Aug 21 12:03:40 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 21 Aug 2019 12:03:40 +0200 Subject: how to recover secret key passphrase? In-Reply-To: <20190820174644.51730E0796@smtp.hushmail.com> References: <20190818160613.GH6070@zeromail.org> <20190820162552.GA25098@pc21.mareichelt.com> <20190820165352.GQ6070@zeromail.org> <20190820174644.51730E0796@smtp.hushmail.com> Message-ID: <69586a1a-2fc6-ca86-13cb-0df1d569d4af@digitalbrains.com> On 20/08/2019 19:46, vedaal via Gnupg-users wrote: > Try This: > > [1] Open a new terminal command prompt window > [2] Type gpg -a --export-secret-key keyname I think ilf is quite correct that you need to enter your passphrase to do an export from the agent-managed store in private-keys-v1.d. The encryption in the private key store is not the same as the encryption of a transferable OpenPGP private key anymore, so it needs to be decrypted and re-encrypted, which is why you're asked for your passphrase. > This works in both GnuPG 1.x and 2.x I think it would have worked in 1.x and 2.0. But for 2.1+, it no longer works, and > Don't use gpg-agent for this. you actually really need the agent to access the private keys from GnuPG 2.1+. So what ilf probably needs is something that can read the private keybox format. That's where my advice falls short: I can't help with that. 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 wk at gnupg.org Wed Aug 21 12:24:14 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Aug 2019 12:24:14 +0200 Subject: how to recover secret key passphrase? In-Reply-To: <69586a1a-2fc6-ca86-13cb-0df1d569d4af@digitalbrains.com> (Peter Lebbing's message of "Wed, 21 Aug 2019 12:03:40 +0200") References: <20190818160613.GH6070@zeromail.org> <20190820162552.GA25098@pc21.mareichelt.com> <20190820165352.GQ6070@zeromail.org> <20190820174644.51730E0796@smtp.hushmail.com> <69586a1a-2fc6-ca86-13cb-0df1d569d4af@digitalbrains.com> Message-ID: <87lfvmbyup.fsf@wheatstone.g10code.de> On Wed, 21 Aug 2019 12:03, peter at digitalbrains.com said: > So what ilf probably needs is something that can read the private keybox > format. That's where my advice falls short: I can't help with that. That is right. You need a new tool for John to do that. The format is descriped in gnupg/agent/keyformat.txt. I do not have the time to write such a tool anytime soon. Sorry. 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 Wed Aug 21 21:28:17 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 21 Aug 2019 21:28:17 +0200 Subject: BSI withdraws approval of GnuPG for confidential documents In-Reply-To: <87lfw3h5t2.fsf@wheatstone.g10code.de> References: <20190808172247.00001665.sac@300baud.de> <87lfw3h5t2.fsf@wheatstone.g10code.de> Message-ID: <20190821212817.00004c12.sac@300baud.de> Werner Koch via Gnupg-users wrote: > On Thu, 8 Aug 2019 17:22, gnupg-users at gnupg.org said: > > > maybe interesting for some community members, living in Germany. > > We learned about that last week and are trying to figure out what is > going on. It is likely an internal coordination or content admin > problem at the BSI. We do not know about any technical problems. > > > Salam-Shalom, > > Werner > Did you get any informations yet, because I saw this today: Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 Autocrypt pub key avail. on Hagrid - offline pub key avail. via WKD From sac at 300baud.de Wed Aug 21 22:05:52 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 21 Aug 2019 22:05:52 +0200 Subject: BSI withdraws approval of GnuPG for confidential documents In-Reply-To: <851C9E1C-4D5E-49F1-AA93-B6CCB942E050@webweaving.org> References: <20190808172247.00001665.sac@300baud.de> <87lfw3h5t2.fsf@wheatstone.g10code.de> <20190821212817.00004c12.sac@300baud.de> <851C9E1C-4D5E-49F1-AA93-B6CCB942E050@webweaving.org> Message-ID: <20190821220552.00007c86.sac@300baud.de> Dirk-Willem van Gulik wrote: > FWIIW - in the past I've found the BSI a highly professional & responsible > organisation - with key staff answering (every very detailed technical > questions) very quickly, comprehensively and in great technical detail. > > So I would just ask. Thanks for pointing that out. In case you mean me asking the BSI I think it is much better that Werner, as author of GnuPG, asks them. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 Autocrypt pub key avail. on Hagrid - offline pub key avail. via WKD From dirkx at webweaving.org Wed Aug 21 21:43:58 2019 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 21 Aug 2019 21:43:58 +0200 Subject: BSI withdraws approval of GnuPG for confidential documents In-Reply-To: <20190821212817.00004c12.sac@300baud.de> References: <20190808172247.00001665.sac@300baud.de> <87lfw3h5t2.fsf@wheatstone.g10code.de> <20190821212817.00004c12.sac@300baud.de> Message-ID: <851C9E1C-4D5E-49F1-AA93-B6CCB942E050@webweaving.org> > On 21 Aug 2019, at 21:28, Stefan Claas via Gnupg-users wrote: > > Werner Koch via Gnupg-users wrote: > >> On Thu, 8 Aug 2019 17:22, gnupg-users at gnupg.org said: >> >>> maybe interesting for some community members, living in Germany. >> >> We learned about that last week and are trying to figure out what is >> going on. It is likely an internal coordination or content admin >> problem at the BSI. We do not know about any technical problems. >> >> >> Salam-Shalom, >> >> Werner >> > > Did you get any informations yet, because I saw this today: > > > > FWIIW - in the past I've found the BSI a highly professional & responsible organisation - with key staff answering (every very detailed technical questions) very quickly, comprehensively and in great technical detail. So I would just ask. Dw -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Thu Aug 22 00:04:55 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 22 Aug 2019 00:04:55 +0200 Subject: BSI withdraws approval of GnuPG for confidential documents In-Reply-To: <20190821220552.00007c86.sac@300baud.de> References: <20190808172247.00001665.sac@300baud.de> <87lfw3h5t2.fsf@wheatstone.g10code.de> <20190821212817.00004c12.sac@300baud.de> <851C9E1C-4D5E-49F1-AA93-B6CCB942E050@webweaving.org> <20190821220552.00007c86.sac@300baud.de> Message-ID: On 21/08/2019 22:05, Stefan Claas via Gnupg-users wrote: > Thanks for pointing that out. In case you mean me asking the BSI I think > it is much better that Werner, as author of GnuPG, asks them. If I were you, I'd just ask, and note that you will post the answer to "gnupg-users, the official GnuPG mailing list for general discussion and help" or something on that order. In that case they will understand this is for public dissemination among the GnuPG-using populace. This gives it due weight as well. And relieves Werner of the work, making time free for stuff only he (or few people at least) can do well. (And in general, announcing you will publish what someone is writing to you is the nice thing to do and might even be required) And heck, it might lend urgency to the topic should Werner subsequently also ask them. 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 Aug 22 00:43:47 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 22 Aug 2019 00:43:47 +0200 Subject: BSI withdraws approval of GnuPG for confidential documents In-Reply-To: References: <20190808172247.00001665.sac@300baud.de> <87lfw3h5t2.fsf@wheatstone.g10code.de> <20190821212817.00004c12.sac@300baud.de> <851C9E1C-4D5E-49F1-AA93-B6CCB942E050@webweaving.org> <20190821220552.00007c86.sac@300baud.de> Message-ID: <20190822004347.000044a9.sac@300baud.de> Peter Lebbing wrote: > On 21/08/2019 22:05, Stefan Claas via Gnupg-users wrote: > > Thanks for pointing that out. In case you mean me asking the BSI I think > > it is much better that Werner, as author of GnuPG, asks them. > > If I were you, I'd just ask, and note that you will post the answer to > "gnupg-users, the official GnuPG mailing list for general discussion and > help" or something on that order. In that case they will understand this > is for public dissemination among the GnuPG-using populace. This gives > it due weight as well. And relieves Werner of the work, making time free > for stuff only he (or few people at least) can do well. > > (And in general, announcing you will publish what someone is writing to > you is the nice thing to do and might even be required) > > And heck, it might lend urgency to the topic should Werner subsequently > also ask them. Well, normally citizens in Germany can contact the BSI via an email address they specifically have for citizens. However, in this case the linked article's contact address is for the press only, which I overlooked, sorry! Werner should have the proper contact channels. Otherwise, if the contact address in this article would be for non-press people I could mail them. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 Autocrypt pub key avail. on Hagrid - offline pub key avail. via WKD From wk at gnupg.org Thu Aug 22 10:16:34 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Aug 2019 10:16:34 +0200 Subject: BSI withdraws approval of GnuPG for confidential documents In-Reply-To: (Peter Lebbing's message of "Thu, 22 Aug 2019 00:04:55 +0200") References: <20190808172247.00001665.sac@300baud.de> <87lfw3h5t2.fsf@wheatstone.g10code.de> <20190821212817.00004c12.sac@300baud.de> <851C9E1C-4D5E-49F1-AA93-B6CCB942E050@webweaving.org> <20190821220552.00007c86.sac@300baud.de> Message-ID: <87pnkxaa3h.fsf@wheatstone.g10code.de> On Thu, 22 Aug 2019 00:04, peter at digitalbrains.com said: > And heck, it might lend urgency to the topic should Werner subsequently > also ask them. We are in contact with them and have regular meetings. It does not help the case if I would disclose details. The problems around the OpenPGP part of GnuPG is not a technical problem. 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 Sun Aug 25 20:40:54 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 25 Aug 2019 20:40:54 +0200 Subject: Slightly OT - mobile OpenPGP usage Message-ID: <20190825204054.00000b9e.sac@300baud.de> Hi all, I am curious what apps you are using when not at home, to send OpenPGP compatible email messages? Do you carry a Notebook with GnuPG or do you use an OpenPGP smartphone app? Because I do not have a smartphone and I do not want to carry a Notebook with me I came up with the following solution for me. Due to some tests I found Mailvelope an OpenPGP extension for Firefox and Chrome and installed it on my Kanguru Defender 3000 USB stick. Besides the new Mailvelope keyserver I added also Hagrid. Key management is quite comfortable and messages sending is also very easy. A lot of free mail providers support Mailvelope. This set-up allows me to use OpenPGP not only in an Internet Caf? etc. but also at work where I can't install a MUA like Thunderbird or even install GnuPG. https://www.mailvelope.com/en https://keys.mailvelope.com/ P.S. my posting should not bee seen as an advertisement for Mailvelope but this is currently a mobile solution I have found for me and maybe it could be useful for others as well. I am all ears what other mobile solutions are available and which one you use. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From hello at ezaquarii.com Sun Aug 25 21:22:03 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Sun, 25 Aug 2019 20:22:03 +0100 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <20190825204054.00000b9e.sac@300baud.de> References: <20190825204054.00000b9e.sac@300baud.de> Message-ID: On 25/08/2019 19:40, Stefan Claas via Gnupg-users wrote: > Hi all, > > I am curious what apps you are using when not at home, to send > OpenPGP compatible email messages? Do you carry a Notebook with > GnuPG or do you use an OpenPGP smartphone app? Shortly, I know only one combination that provides reasonable use experience on mobile. Android + K-9 Mail + OpenKeychain + YubiKey with NFC. Cheers, Chris Narkiewicz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From stefanclaas at riseup.net Sun Aug 25 22:48:04 2019 From: stefanclaas at riseup.net (Stefan Claas) Date: Sun, 25 Aug 2019 13:48:04 -0700 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: References: <20190825204054.00000b9e.sac@300baud.de> Message-ID: <62ebfbe23dbdc15b81217a8c4cf52e9c@riseup.net> On 2019-08-25 21:22, Chris Narkiewicz via Gnupg-users wrote: > On 25/08/2019 19:40, Stefan Claas via Gnupg-users wrote: >> Hi all, >> >> I am curious what apps you are using when not at home, to send >> OpenPGP compatible email messages? Do you carry a Notebook with >> GnuPG or do you use an OpenPGP smartphone app? > Shortly, I know only one combination that provides reasonable > use experience on mobile. > > Android + K-9 Mail + OpenKeychain + YubiKey with NFC. Thanks for the info, much appreciated. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From farhan at farhan.codes Mon Aug 26 01:26:00 2019 From: farhan at farhan.codes (Farhan Khan) Date: Sun, 25 Aug 2019 23:26:00 +0000 Subject: Constantly restarting gpg-agent Message-ID: <1d970504a3b1499f8e77987ae2f1579e@farhan.codes> Hi all, I use gnupg to sign my git commits, but after a few hours of use I have to restart gpg-agent. Before doing so, what I presume is gpg-agent asks me to re-enter my password on a random terminal (but it seems to drop characters and never works). As a result, the git commit fails. I have to kill gpg-agent and restart it as "gpg-agent --daemon", which then works. I would like to: A. The calling terminal should be where I have to re-enter my password, not seemingly a random terminal. B. Enter my password only once. This is a headless remote system I ssh into running FreeBSD 12.0. Please find my configuration below. -----BEGIN TERMINAL MESSAGE----- [farhan at dev ~]$ cat ~/.gnupg/gpg.conf # File re-created by pEp # See backup in '/home/farhan/.gnupg/gpg.conf.0.pep.bkp' personal-digest-preferences SHA512 cert-digest-algo SHA512 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed keyserver hkp://keys.gnupg.net no-emit-version no-comments personal-cipher-preferences AES AES256 AES192 CAST5 ignore-time-conflict allow-freeform-uid no-secmem-warning [farhan at dev ~]$ cat ~/.gnupg/gpg-agent.conf # File re-created by pEp # See backup in '/home/farhan/.gnupg/gpg-agent.conf.0.pep.bkp' enable-ssh-support default-cache-ttl 300 max-cache-ttl 1200 -----END TERMINAL MESSAGE----- Thanks, --- Farhan Khan PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE From mkesper at schokokeks.org Mon Aug 26 11:01:17 2019 From: mkesper at schokokeks.org (Michael Kesper) Date: Mon, 26 Aug 2019 11:01:17 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: References: <20190825204054.00000b9e.sac@300baud.de> Message-ID: Hi Chris, On 25.08.19 21:22, Chris Narkiewicz via Gnupg-users wrote: > Shortly, I know only one combination that provides reasonable > use experience on mobile. > > Android + K-9 Mail + OpenKeychain + YubiKey with NFC. Do you know a good guide for setting this up? Best wishes Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From dan at savevsgeek.com Mon Aug 26 19:17:03 2019 From: dan at savevsgeek.com (Daniel Clery) Date: Mon, 26 Aug 2019 13:17:03 -0400 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: References: <20190825204054.00000b9e.sac@300baud.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tangentially related - I've seen docs recommending having your portable keychain have a subkey for signing, and that keychain to lack the master secret key entirely ( and putting that one in an undisclosed secure location), with a different passphrase, etc. What are gnupg-users thoughts on that sort of setup? -----BEGIN PGP SIGNATURE----- Version: Mailvelope v4.1.0 Comment: https://www.mailvelope.com wsFcBAEBCAAGBQJdZBQBAAoJEMpMWCzKN2JrCHgQAI2nG2X64v6fcqt8/ftE JrFtNDr24ItU36dCp8xDxIBu6Is01nwqxyTJVo1idxuivA9goLsNguIdc/gp zOzCnFuKA3dbiRxUJ8RXcogPHDBToAN19F9l2ehk3C64M4/uHdWcDHXoCz1i OV7RDlqtODX0CPsxTfCMq5Nb4ZUVGM/jxzrVBmHYLb+1TmALzHHlnB2HdFWb 5CXq3T0RbX38RqHlrGmTi4KPwbgMWt9a4dxVK393rh8BPSyFZd5dbz4yyPlA NxthZ4+dpJh0yNyqudafELf3mVLWDun9z/yFP/sdKLwB/ovS2wuQ+Bp2EPlj QKe/PwfYTdYA34JlrzMhCFlHpoR0XGhNRt/Ns9d41/OvAo9lvlD75my33u2t Iy2xH/dhAvBVCE0YYWXb2iT8gM9YbYDePkF1FgEjadTdg/TD04NOVONgoZdS n+uSzFxl3X7oIdPYrRYeqryBSHYo9sZAIjFAW4/+BrA720Ju0cWpQolN7rdW YKZKz4OeV/MILVGVYa+lv01MB+lrTs7eH8NVCoPxcqpscnTSYHafC93/Z+ga mIuYDMWE9fpQ/MR4EtBdq5yrcrC4HSbm7CfsOirYv635jZ+2MXZeQYLuifIz IlqoRDXTB+YBKXLnw2kvPxojZxCZliboNmAIWut47s3/Ard3zZCB6q05egeG ekWf =ZDVi -----END PGP SIGNATURE----- On Mon, Aug 26, 2019 at 5:25 AM Michael Kesper wrote: > Hi Chris, > > On 25.08.19 21:22, Chris Narkiewicz via Gnupg-users wrote: > > Shortly, I know only one combination that provides reasonable > > use experience on mobile. > > > > Android + K-9 Mail + OpenKeychain + YubiKey with NFC. > > Do you know a good guide for setting this up? > > Best wishes > Michael > > _______________________________________________ > 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 andrewg at andrewg.com Mon Aug 26 19:37:46 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 26 Aug 2019 18:37:46 +0100 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: References: <20190825204054.00000b9e.sac@300baud.de> Message-ID: <3AF3DF9A-64C4-46D9-9264-21A02B29C4E8@andrewg.com> > On 26 Aug 2019, at 18:17, Daniel Clery wrote: > > Tangentially related - I've seen docs recommending having your portable keychain have a subkey for signing, and that keychain to lack the master secret key entirely ( and putting that one in an undisclosed secure location), with a different passphrase, etc. What are gnupg-users thoughts on that sort of setup? It?s a nice idea in principle, but it?s a technical violation (sorry, nonstandard extension) of the standard to allow bare private subkeys, so many mobile clients (e.g. ipgmail) don?t support it. I used to do this on my laptops with gnupg (which does support it) but have since migrated to smartcards. With the advent of NFC and lightning hardware tokens, it will make more sense to use them for all devices, removing the need for nonstandard extensions entirely. There is a non-negligible cost for the hardware, but it is *much* more convenient and secure to plug a card or dongle into a new device than it is to transfer subkey bundles (which are still sensitive data, even without the primary key). A From wiktor at metacode.biz Mon Aug 26 20:47:40 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 26 Aug 2019 20:47:40 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <3AF3DF9A-64C4-46D9-9264-21A02B29C4E8@andrewg.com> References: <20190825204054.00000b9e.sac@300baud.de> <3AF3DF9A-64C4-46D9-9264-21A02B29C4E8@andrewg.com> Message-ID: On 26.08.2019 19:37, Andrew Gallagher wrote: >> Tangentially related - I've seen docs recommending having your portable keychain have a subkey for signing, and that keychain to lack the master secret key entirely ( and putting that one in an undisclosed secure location), with a different passphrase, etc. What are gnupg-users thoughts on that sort of setup? > With the advent of NFC and lightning hardware tokens, it will make more sense to use them for all devices, removing the need for nonstandard extensions entirely. There is a non-negligible cost for the hardware, but it is *much* more convenient and secure to plug a card or dongle into a new device than it is to transfer subkey bundles (which are still sensitive data, even without the primary key). I agree. I'm using this kind of setup (offline master key and hardware tokens for subkeys) and it works very well. If one sets URL field on the token then just plugging the token when OpenKeychain is opened is enough to get the key ready-to-use. Having multiple subkeys for multiple devices can be problematic in practice (e.g. GnuPG does not encrypt to all encryption subkeys or Autocrypt clients only export one signing subkey etc.) W.r.t. NFC there is this minor detail: https://lists.gnupg.org/pipermail/gnupg-users/2018-December/061375.html But from the UX point of view it's very convenient. Kind regards, Wiktor From sac at 300baud.de Mon Aug 26 21:14:59 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 26 Aug 2019 21:14:59 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: References: <20190825204054.00000b9e.sac@300baud.de> <3AF3DF9A-64C4-46D9-9264-21A02B29C4E8@andrewg.com> Message-ID: <20190826211459.00001ec4.sac@300baud.de> Wiktor Kwapisiewicz via Gnupg-users wrote: > W.r.t. NFC there is this minor detail: > https://lists.gnupg.org/pipermail/gnupg-users/2018-December/061375.html Interesting. Well, for important and very short messages one could additionally use the modern ElsieFour handcypher, by Prof. Kaminsky., in combination with mobile devices. :-) https://eprint.iacr.org/2017/339.pdf Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From muredanta at protonmail.com Tue Aug 27 02:18:46 2019 From: muredanta at protonmail.com (muredanta) Date: Tue, 27 Aug 2019 00:18:46 +0000 Subject: Questions on code signing Message-ID: <6dUOzuDVx71UGldPpqUE6ealHJNetRMyIQtkTOZTP28HWTb6jhW5Dr6O5VBVM6z3pnEXa8hDFnHDMNf2_t6xKu-Fp2XBKajDLBD_Ynxcd1M=@protonmail.com> I've been working on a scheme for signing binary images that we ship out to various remote systems. The remote system expects the file to be both encrypted and signed, but there seem to be some corner cases: (1) If a file is signed but the signature is incorrect, 'gpg2 -d' returns a non-zero status code, so the remote script knows not to trust the file, but if the file carries no signature at all, then decryption succeeds and there is no indication to a script that there was not a valid signature.This opens a window for an attacker to send a fine that is properly encrypted but not signed at all, and it looks like gpg2 will not catch that case. Is there an option I can give in addition to -d that REQUIRES the file to be signed? I realize you can verify a detached signature as a secondary step but I was hoping there would be a way to combine everything into one command. (2) If a file is signed and the remote script has the signer's public key, then a --verify operation will succeed. The trouble is, what if the file is signed by some signature in the remote script's keyring other than the expected code signing key? Is there an option that can be given to --verify (or along with -d, if there's a solution to (1)) that can specify the exact signing key (or keys) required? I tried using -u with --verify, and although no error was generated, the parameter was ignored. (3) If a file is both encrypted and signed, is there a way to merely verify the signature other than to include a detached signature? Right now, using --verify on a single file that was encrypted/signed with -es just gives "gpg: verify signatures failed: Unexpected error." Is there a way around that, so I don't need to use a detached signature? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Aug 27 11:30:06 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Aug 2019 11:30:06 +0200 Subject: Questions on code signing In-Reply-To: <6dUOzuDVx71UGldPpqUE6ealHJNetRMyIQtkTOZTP28HWTb6jhW5Dr6O5VBVM6z3pnEXa8hDFnHDMNf2_t6xKu-Fp2XBKajDLBD_Ynxcd1M=@protonmail.com> (muredanta via Gnupg-users's message of "Tue, 27 Aug 2019 00:18:46 +0000") References: <6dUOzuDVx71UGldPpqUE6ealHJNetRMyIQtkTOZTP28HWTb6jhW5Dr6O5VBVM6z3pnEXa8hDFnHDMNf2_t6xKu-Fp2XBKajDLBD_Ynxcd1M=@protonmail.com> Message-ID: <87zhjv3qht.fsf@wheatstone.g10code.de> On Tue, 27 Aug 2019 00:18, gnupg-users at gnupg.org said: > (1) If a file is signed but the signature is incorrect, 'gpg2 -d' > returns a non-zero status code, so the remote script knows not to Right but as stated somewhere in the docs, you should never ever rely on the status code fomr the binary. Well, except for the gpgv tool which we developed just for the purpose to verify signatures. You can't use it however with encrypted+signed data. > like gpg2 will not catch that case. Is there an option I can give in > addition to -d that REQUIRES the file to be signed? I realize you can No, you need to check that there is a valid signature by checking the --status-fd messages. It is a bit tricky to get this right because there is a variety of things which can be found in the input to gpg. Using detached signatures makes things much easier because you really known what has been signed. You still need to check the status-fd messages. You may also use the GPGME library (or the gpgme-json wrapper) to make things easier. GPGME takes care of also nitty-gritty you would need to do. > (2) If a file is signed and the remote script has the signer's public > key, then a --verify operation will succeed. The trouble is, what if > the file is signed by some signature in the remote script's keyring > other than the expected code signing key? Is there an option that can > be given to --verify (or along with -d, if there's a solution to (1)) > that can specify the exact signing key (or keys) required? I tried Your script or progrtam should check which key was used for signing. Or you make sure that your local keyring only has that very key. Watch out for this --status-fd token: VALIDSIG The args are: - - - - - - - - - - [ ] This status indicates that the signature is cryptographically valid. This is similar to GOODSIG, EXPSIG, EXPKEYSIG, or REVKEYSIG (depending on the date and the state of the signature and signing key) but has the fingerprint as the argument. Multiple status lines (VALIDSIG and the other appropriate *SIG status) are emitted for a valid signature. All arguments here are on one long line. sig-timestamp is the signature creation time in seconds after the epoch. expire-timestamp is the signature expiration time in seconds after the epoch (zero means "does not expire"). sig-version, pubkey-algo, hash-algo, and sig-class (a 2-byte hex value) are all straight from the signature packet. PRIMARY-KEY-FPR is the fingerprint of the primary key or identical to the first argument. This is useful to get back to the primary key without running gpg again for this purpose. The primary-key-fpr parameter is used for OpenPGP and not available for CMS signatures. The sig-version as well as the sig class is not defined for CMS and currently set to 0 and 00. Note, that *-TIMESTAMP may either be a number of seconds since Epoch or an ISO 8601 string which can be detected by the presence of the letter 'T'. This can be easily parsed with awk(1) or other tools. > (3) If a file is both encrypted and signed, is there a way to merely > verify the signature other than to include a detached signature? Right > now, using --verify on a single file that was encrypted/signed with > -es just gives "gpg: verify signatures failed: Unexpected error." Is > there a way around that, so I don't need to use a detached signature? You can extra the signature from the encrypted+signed data: gpg --unwrap -d -o SIG From hello at ezaquarii.com Tue Aug 27 17:52:27 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Tue, 27 Aug 2019 16:52:27 +0100 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: References: <20190825204054.00000b9e.sac@300baud.de> <3AF3DF9A-64C4-46D9-9264-21A02B29C4E8@andrewg.com> Message-ID: <95108729-b556-fd2e-5bc6-af11d7441292@ezaquarii.com> On 26/08/2019 19:47, Wiktor Kwapisiewicz via Gnupg-users wrote: > If one sets URL field on the > token then just plugging the token when OpenKeychain is opened is enough > to get the key ready-to-use. Can you explain what kind of workflow do you mean here? -------------- 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 Tue Aug 27 18:01:13 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 27 Aug 2019 18:01:13 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <20190825204054.00000b9e.sac@300baud.de> References: <20190825204054.00000b9e.sac@300baud.de> Message-ID: <20190827180113.000022a1.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Due to some tests I found Mailvelope an OpenPGP extension for > Firefox and Chrome and installed it on my Kanguru Defender 3000 > USB stick. Besides the new Mailvelope keyserver I added also Hagrid. > Key management is quite comfortable and messages sending is also > very easy. A lot of free mail providers support Mailvelope. > > This set-up allows me to use OpenPGP not only in an Internet Caf? etc. > but also at work where I can't install a MUA like Thunderbird or even > install GnuPG. I have also a question for the experts regarding keyloggers in public places. Would you consider these both methods secure enough for entering passphrases in Mailvelope, like outlined in article [1] while using Oxynger KeyShield [2]? [1] [2] Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From andrewg at andrewg.com Tue Aug 27 18:07:34 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 27 Aug 2019 17:07:34 +0100 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <20190827180113.000022a1.sac@300baud.de> References: <20190825204054.00000b9e.sac@300baud.de> <20190827180113.000022a1.sac@300baud.de> Message-ID: On 27/08/2019 17:01, Stefan Claas via Gnupg-users wrote: > Would you consider these both methods secure enough for entering passphrases in > Mailvelope, like outlined in article [1] while using Oxynger KeyShield [2]? If you think there's a keylogger on your machine, then don't type in a password at all, ever. And if there's a keylogger then there's just as likely to be a screen scraper, or all sorts of other nasty things. -- 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 wiktor at metacode.biz Tue Aug 27 18:55:13 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Tue, 27 Aug 2019 18:55:13 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <95108729-b556-fd2e-5bc6-af11d7441292@ezaquarii.com> References: <20190825204054.00000b9e.sac@300baud.de> <3AF3DF9A-64C4-46D9-9264-21A02B29C4E8@andrewg.com> <95108729-b556-fd2e-5bc6-af11d7441292@ezaquarii.com> Message-ID: <94ef8f32-1ae4-d61b-87f4-1ec55feb543c@metacode.biz> Hi Chris, On 27.08.2019 17:52, Chris Narkiewicz via Gnupg-users wrote: > On 26/08/2019 19:47, Wiktor Kwapisiewicz via Gnupg-users wrote: >> If one sets URL field on the >> token then just plugging the token when OpenKeychain is opened is enough >> to get the key ready-to-use. > > Can you explain what kind of workflow do you mean here? I mean you start OpenKeychain, touch the NFC token and get the import key screen (see attachment). This is very straightforward, no need to mess with passwords and secret key files. OpenPGP software requires public keys but tokens don't store them so own public keys need to be transmitted somehow. Fortunately OpenPGP Card spec has a "URL of public key" field. You can see/set the value this way: $ gpg --card-edit Reader ...........: ... Application ID ...: ... Version ..........: 2.1 Manufacturer .....: Yubico ... URL of public key : https://metacode.biz/@wiktor/openpgp/key Login data .......: wiktor This is in turn used by OpenKeychain (but also by gpg --card-edit and "fetch" subcommand) to download public parts. Kind regards, Wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: okc-import-token.jpg Type: image/jpeg Size: 28307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Tue Aug 27 21:50:42 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 27 Aug 2019 21:50:42 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: References: <20190825204054.00000b9e.sac@300baud.de> <20190827180113.000022a1.sac@300baud.de> Message-ID: <20190827215042.000029aa.sac@300baud.de> Andrew Gallagher wrote: > On 27/08/2019 17:01, Stefan Claas via Gnupg-users wrote: > > Would you consider these both methods secure enough for entering > > passphrases in Mailvelope, like outlined in article [1] while using Oxynger > > KeyShield [2]? > > If you think there's a keylogger on your machine, then don't type in a > password at all, ever. And if there's a keylogger then there's just as > likely to be a screen scraper, or all sorts of other nasty things. But what would be, when using computers at work or public places, then the best strategy for using OpenPGP, without carrying a Notebook or smartphone? There should be good solution available IMHO. :-) At least Firefox portable exists for Windows users and I believe portable apps were invented for USB stick usage, right? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From peter at digitalbrains.com Tue Aug 27 23:41:39 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 27 Aug 2019 23:41:39 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <20190827215042.000029aa.sac@300baud.de> References: <20190825204054.00000b9e.sac@300baud.de> <20190827180113.000022a1.sac@300baud.de> <20190827215042.000029aa.sac@300baud.de> Message-ID: <4389dd40-097d-215e-44df-0f471c18b207@digitalbrains.com> On 27/08/2019 21:50, Stefan Claas via Gnupg-users wrote: > But what would be, when using computers at work or public places, then > the best strategy for using OpenPGP, without carrying a Notebook or > smartphone? If a computer is compromised, this is game over for cryptography. Full stop. > There should be good solution available IMHO. :-) BYOD :-) 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 hello at ezaquarii.com Wed Aug 28 00:41:21 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Tue, 27 Aug 2019 23:41:21 +0100 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <4389dd40-097d-215e-44df-0f471c18b207@digitalbrains.com> References: <20190825204054.00000b9e.sac@300baud.de> <20190827180113.000022a1.sac@300baud.de> <20190827215042.000029aa.sac@300baud.de> <4389dd40-097d-215e-44df-0f471c18b207@digitalbrains.com> Message-ID: On 27/08/2019 22:41, Peter Lebbing wrote: > If a computer is compromised, this is game over for cryptography. Full > stop. This is not true. Many crypto systems are designed to perform damage control and recovery in such cases. If the compromise is game over for the user - it depends on threat profile. Cheers, Chris Narkiewicz From hello at ezaquarii.com Wed Aug 28 00:44:35 2019 From: hello at ezaquarii.com (Chris Narkiewicz) Date: Tue, 27 Aug 2019 23:44:35 +0100 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <20190827215042.000029aa.sac@300baud.de> References: <20190825204054.00000b9e.sac@300baud.de> <20190827180113.000022a1.sac@300baud.de> <20190827215042.000029aa.sac@300baud.de> Message-ID: <4e9bf503-c8dd-4a5b-6adf-5b40fedea3f2@ezaquarii.com> On 27/08/2019 20:50, Stefan Claas via Gnupg-users wrote: > But what would be, when using computers at work or public places, then > the best strategy for using OpenPGP, without carrying a Notebook or > smartphone? The strategy I advice would be to not use GnuPG and look for alternatives. I wouldn't look for some golden practice because I believe there is none. Bluntly speaking, GnuPG is not fit for purpose of securing everyday communication and shall not be advertised as such. Generally your keys should never leave secure environment. Secure environment can be either dedicated machine that you control or (better) SmartCard/HSM. If your keys cannot be contained in secure environment, your comms channel should be re-keyed after use. Modern communicators perform re-keying after every message. GnuPG makes re-keying very cumbersome. > There should be good solution available IMHO. :-) Sadly, GnuPG never delivered friendly user experience. It found it's niche in some specialized use-cases, such as infrastructure - package signing, backup encryption, commands by e-mail, etc - but it never gained significant adoption among wider population. If you expected more - I' m sorry that you will be disappointed. Cheers, Chris Narkiewicz From dkg at fifthhorseman.net Wed Aug 28 01:17:13 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Aug 2019 19:17:13 -0400 Subject: Storing custom signed data in the key In-Reply-To: <20190817164524.GA5617@noether> References: <20190817164524.GA5617@noether> Message-ID: <87woey9p1i.fsf@fifthhorseman.net> Hi Tomasz-- On Sat 2019-08-17 18:45:24 +0200, Tomasz Buchert wrote: > what would be the most "canonical" way to store arbitrary, signed data > along the gpg key? And then: what is the programmatic way of extracting > said data? > > My specific usecase is putting a signify [1] public key inside my GPG > key, so that I can leverage key distribution to push my signify key. As i understand it, signify uses ed25519 public keys. For this specific use case, i'd recommend attaching your signify public key as a signing-capable subkey directly to your OpenPGP certificate. Or, if you don't want it to look like it's signing-capable for the purposes of OpenPGP signing, you could attach it as a subkey with an empty key flags subpacket. If you want to include a notation that indicates that this key is for use with signify specifically, you could then include a notation in the subkey binding signature. This seems like the most prinicipled way to include the key in your OpenPGP certificate, and the best way to avoid having people get confused about third-party certification claims, since third-parties can't attach subkeys. Doing this specifically would require some conversion capability between the signify format and the OpenPGP format for Ed25519 keys. I haven't tried to do that, but if it's something that you're interested in, i'd be happy to look at it with you. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From muredanta at protonmail.com Wed Aug 28 02:33:52 2019 From: muredanta at protonmail.com (muredanta) Date: Wed, 28 Aug 2019 00:33:52 +0000 Subject: Questions on code signing In-Reply-To: <87zhjv3qht.fsf@wheatstone.g10code.de> References: <6dUOzuDVx71UGldPpqUE6ealHJNetRMyIQtkTOZTP28HWTb6jhW5Dr6O5VBVM6z3pnEXa8hDFnHDMNf2_t6xKu-Fp2XBKajDLBD_Ynxcd1M=@protonmail.com> <87zhjv3qht.fsf@wheatstone.g10code.de> Message-ID: <5KmOO0Uo-N6qndJSbXpaE3oWXOjzuwkdQANcf0zFSVv-bp5IESzqpZlxQq3gBmB78puGW1T3O7HirZu0wvp3nT5GvAEuouw5M7ZtIB5MsdA=@protonmail.com> Wow. Thanks very much for such a detailed reply. GPG can be counter-intuitive at times, but it seems there is always a way. Shalom! Sent with ProtonMail Secure Email. ??????? Original Message ??????? On Tuesday, August 27, 2019 6:30 PM, Werner Koch wrote: > On Tue, 27 Aug 2019 00:18, gnupg-users at gnupg.org said: > > > (1) If a file is signed but the signature is incorrect, 'gpg2 -d' > > returns a non-zero status code, so the remote script knows not to > > Right but as stated somewhere in the docs, you should never ever rely on > the status code fomr the binary. Well, except for the gpgv tool which > we developed just for the purpose to verify signatures. You can't use > it however with encrypted+signed data. > > > like gpg2 will not catch that case. Is there an option I can give in > > addition to -d that REQUIRES the file to be signed? I realize you can > > No, you need to check that there is a valid signature by checking the > --status-fd messages. It is a bit tricky to get this right because > there is a variety of things which can be found in the input to gpg. > Using detached signatures makes things much easier because you really > known what has been signed. You still need to check the status-fd > messages. > > You may also use the GPGME library (or the gpgme-json wrapper) to make > things easier. GPGME takes care of also nitty-gritty you would need to > do. > > > (2) If a file is signed and the remote script has the signer's public > > key, then a --verify operation will succeed. The trouble is, what if > > the file is signed by some signature in the remote script's keyring > > other than the expected code signing key? Is there an option that can > > be given to --verify (or along with -d, if there's a solution to (1)) > > that can specify the exact signing key (or keys) required? I tried > > Your script or progrtam should check which key was used for signing. Or > you make sure that your local keyring only has that very key. Watch out > for this --status-fd token: > > VALIDSIG > > The args are: > > - > > - > > - > > - > > - > > - > > - > > - > > - > > - [ ] > > > This status indicates that the signature is cryptographically > valid. This is similar to GOODSIG, EXPSIG, EXPKEYSIG, or REVKEYSIG > (depending on the date and the state of the signature and signing > key) but has the fingerprint as the argument. Multiple status > lines (VALIDSIG and the other appropriate *SIG status) are emitted > for a valid signature. All arguments here are on one long line. > sig-timestamp is the signature creation time in seconds after the > epoch. expire-timestamp is the signature expiration time in > seconds after the epoch (zero means "does not > expire"). sig-version, pubkey-algo, hash-algo, and sig-class (a > 2-byte hex value) are all straight from the signature packet. > PRIMARY-KEY-FPR is the fingerprint of the primary key or identical > to the first argument. This is useful to get back to the primary > key without running gpg again for this purpose. > > The primary-key-fpr parameter is used for OpenPGP and not > available for CMS signatures. The sig-version as well as the sig > class is not defined for CMS and currently set to 0 and 00. > > Note, that *-TIMESTAMP may either be a number of seconds since > Epoch or an ISO 8601 string which can be detected by the presence > of the letter 'T'. > > This can be easily parsed with awk(1) or other tools. > > > (3) If a file is both encrypted and signed, is there a way to merely > > verify the signature other than to include a detached signature? Right > > now, using --verify on a single file that was encrypted/signed with > > -es just gives "gpg: verify signatures failed: Unexpected error." Is > > there a way around that, so I don't need to use a detached signature? > > You can extra the signature from the encrypted+signed data: > > gpg --unwrap -d -o SIG > and then run > > gpgv -o SIGNEDFILE SIG && echo verified! > > --unwrap is not documented and has the minor problem that it also keeps the > compression layer. However, gpgv groks that compression layer and works > as with a standard signature. The signature is on SIGNEDFILE which gpgv > outputs for you. > > Shalom-Salam, > > Werner > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From stefanclaas at riseup.net Wed Aug 28 11:07:30 2019 From: stefanclaas at riseup.net (Stefan Claas) Date: Wed, 28 Aug 2019 02:07:30 -0700 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <4e9bf503-c8dd-4a5b-6adf-5b40fedea3f2@ezaquarii.com> References: <20190825204054.00000b9e.sac@300baud.de> <20190827180113.000022a1.sac@300baud.de> <20190827215042.000029aa.sac@300baud.de> <4e9bf503-c8dd-4a5b-6adf-5b40fedea3f2@ezaquarii.com> Message-ID: <5e39ea59124b0bcb66549bfeca786c9a@riseup.net> On 2019-08-28 00:44, Chris Narkiewicz via Gnupg-users wrote: > On 27/08/2019 20:50, Stefan Claas via Gnupg-users wrote: >> But what would be, when using computers at work or public places, then >> the best strategy for using OpenPGP, without carrying a Notebook or >> smartphone? > The strategy I advice would be to not use GnuPG and look for alternatives. Well, not GnuPG but I thought more about other OpenPGP apps, because the OpenPGP protocol besides S/MIME is still widely used. > I wouldn't look for some golden practice because I believe there > is none. Bluntly speaking, GnuPG is not fit for purpose of > securing everyday communication and shall not be advertised > as such. > > Generally your keys should never leave secure environment. Secure > environment can be either dedicated machine that you control > or (better) SmartCard/HSM. Here is an idea ... I recently read about Prof. Kaminsky's Enigma2000 which is a JavaScrpit encryption app running on an offline Raspberry Pi with a touchscreen. https://www.cs.rit.edu/~ark/parallelcrypto/enigma2000/ If someone would write a JavaScript OpenPGP app which works like Enigma2000 one could attach an USB stick to store an amored message, unplug and set the write protect switch and insert the USB stick to a public computer. We would have a secure OpenPGP messaging device, not requiring an expensive smartphone nor a laptop to carry around. It could be done as a kickstarter project (Raspi+Touchscreen as one device + JavaScript code. Well, just a thought and hopefully a talented coder and hardware tinkerer could make this happen. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From peter at digitalbrains.com Wed Aug 28 12:07:05 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 28 Aug 2019 12:07:05 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: References: <20190825204054.00000b9e.sac@300baud.de> <20190827180113.000022a1.sac@300baud.de> <20190827215042.000029aa.sac@300baud.de> <4389dd40-097d-215e-44df-0f471c18b207@digitalbrains.com> Message-ID: <3b7af7d4-9b2d-e776-508b-373616a8afd9@digitalbrains.com> On 28/08/2019 00:41, Chris Narkiewicz via Gnupg-users wrote: > This is not true. Many crypto systems are designed to perform damage > control and recovery in such cases. Damage control in the case of GnuPG would be using a smartcard: while you are using the smartcard, so can the attacker, but once you pull the smartcard and no longer use the compromised system, the attacker no longer has access to the key. In this scenario it makes sense to have an offline primary key: while the attacker can issue data signatures and decrypt your files, they cannot change your key, e.g., add another signing subkey to be used later when the smartcard is no longer available to the attacker. Recovery... well, damage control already implied there was damage, and recovery even more so. Stefan asked for a "best strategy for using OpenPGP [...]". I did not interpret that as asking for how to limit damage, but rather to avoid it. Whether a compromise is game over depends on your scenario. However, what is quite often asked for here is some way to use a compromised system without compromising confidentiality of encryption or without enabling an attacker to issue data signatures. These things cannot be done on a system where the attacker has control over the whole computer (root access, in *nix parlance, or hypervisor access). If you can show me an example where the attacker has full access to a computer and a user can still do decryption and issue signatures *on that computer* while maintaining confidentiality and signature integrity, I'd love to hear about it. However, I've heard many wrong solutions, so in actuality I don't think I would love to hear about it, because it sounds like a waste of time. Here are two obviously wrong ones. "Provide explicit confirmation of each signature issued by a smartcard with an external button". Attacker's solution: pretend something went wrong, and make the user do the actions again. Nothing actually went wrong, the user issued two signatures. Social engineering to the rescue. Or, demise. When they're sending an e-mail, simply make it look like the mail client crashed just after they confirmed the signature, for instance. The confirmation button doesn't ensure signature integrity, it is damage control. "Provide explicit confirmation of decryption with smartcard". Whenever user decrypts something, store the decryption key in a database. When the user decrypts the same file twice, use the stored decryption key and decrypt that interesting file the attacker wants to read instead. 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 Wed Aug 28 12:38:42 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 28 Aug 2019 12:38:42 +0200 Subject: Constantly restarting gpg-agent In-Reply-To: <1d970504a3b1499f8e77987ae2f1579e@farhan.codes> References: <1d970504a3b1499f8e77987ae2f1579e@farhan.codes> Message-ID: <8cd09836-3502-8eda-1e63-3dc6d81998c7@digitalbrains.com> On 26/08/2019 01:26, Farhan Khan via Gnupg-users wrote: > I use gnupg to sign my git commits, but after a few hours of use I > have to restart gpg-agent. Before doing so, what I presume is > gpg-agent asks me to re-enter my password on a random terminal (but it > seems to drop characters and never works). Ah yes, when I use the agent for SSH authentication and it picks the wrong terminal, if on that terminal bash is active, they seem to race for stdin. Some of the characters typed go to the pinentry, and some go to bash. The characters for bash are echoed to the screen. It's a great way to get part of your passphrase in .bash_history! :-D But for gpg, this should not happen. gpg will pass the terminal and/or the X display to the agent, which enables the agent to prompt on the correct terminal. You could try debugging the agent. If I add the following to my .gnupg/gpg-agent.conf: --8<---------------cut here---------------start------------->8--- debug ipc log-file agent.log --8<---------------cut here---------------end--------------->8--- and then issue "gpgconf --kill gpg-agent", the agent that will be subsequently started will log inter-process communication to the file agent.log in my homedir ($HOME, not $GNUPGHOME). There I can see a git commit signing passing the needed information: --8<---------------cut here---------------start------------->8--- 2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 <- OPTION ttytype=screen.xterm-256color 2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 -> OK 2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 <- OPTION display=:0.0 2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 -> OK 2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 <- OPTION xauthority=/home/peter/.Xauthority 2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 -> OK 2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 <- OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus 2019-08-28 12:17:46 gpg-agent[21792] DBG: chan_9 -> OK --8<---------------cut here---------------end--------------->8--- Is it perhaps possible that you run something which unsets environment variables crucial to passing the TTY information to the agent? Have a look at the debug log the moment you encounter the issue again, and compare the conversation with an earlier one that did work. > As a result, the git commit fails. I have to kill > gpg-agent and restart it as "gpg-agent --daemon", which then works. Killing the agent is fine. You shouldn't need to restart it; it is autostarted and in fact it might interfere with the proper functioning if you explicitly start it but with different options set than the autostart would 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 peter at digitalbrains.com Wed Aug 28 12:47:13 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 28 Aug 2019 12:47:13 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <3b7af7d4-9b2d-e776-508b-373616a8afd9@digitalbrains.com> References: <20190825204054.00000b9e.sac@300baud.de> <20190827180113.000022a1.sac@300baud.de> <20190827215042.000029aa.sac@300baud.de> <4389dd40-097d-215e-44df-0f471c18b207@digitalbrains.com> <3b7af7d4-9b2d-e776-508b-373616a8afd9@digitalbrains.com> Message-ID: <56f1a71d-8742-5c78-5d2c-f95d0cea2691@digitalbrains.com> On 28/08/2019 12:07, Peter Lebbing wrote: > Whether a compromise is game over depends on your scenario. Sorry, I meant, it depends on your definition of "game over", definitely *not* on the scenario. I think it is perfectly acceptable to say "compromise = game over", the only way I see that could be wrong is if you have a different idea of what game over means. 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 wk at gnupg.org Thu Aug 29 15:33:51 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 29 Aug 2019 15:33:51 +0200 Subject: [Announce] Libgcrypt 1.8.5 released Message-ID: <87zhjsyu2o.fsf@wheatstone.g10code.de> Hi! The GnuPG Project is pleased to announce the availability of Libgcrypt version 1.8.5. This release fixes an ECDSA side-channel attack. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.8.5 =================================== * Bug fixes: - Add mitigation against an ECDSA timing attack. [T4626,CVE-2019-13627] - Improve ECDSA unblinding. * Other features: - Provide a pkg-config file for libgcrypt. Release-info: https://dev.gnupg.org/T4683 Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.5.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.5.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.5.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.5.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at . In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.8.5.tar.bz2 you would use this command: gpg --verify libgcrypt-1.8.5.tar.bz2.sig libgcrypt-1.8.5.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. - If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file libgcrypt-1.8.5.tar.bz2, you run the command like this: sha1sum libgcrypt-1.8.5.tar.bz2 and check that the output matches the first line from the this list: 2d8781e92f88706707a1e76fb628b499ad538a30 libgcrypt-1.8.5.tar.bz2 c4852a14b57744b2d0e97d9e8e3e60c95ef7e6bb libgcrypt-1.8.5.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= In case of build problems specific to this release please first check https://dev.gnupg.org/T4683 for updated information. For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs two full-time developer and two contractors. They all work exclusively on GnuPG and closely related software like Libgcrypt, GPGME, and GPA. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Thanks to Tomas Mraz for pointing out several smaller flaws. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- 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: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From brian at minton.systems Fri Aug 30 01:02:56 2019 From: brian at minton.systems (Brian Minton) Date: Thu, 29 Aug 2019 18:02:56 -0500 Subject: What is the practical strength of DSA1024/Elgamal2048 (former GnuPG default)? In-Reply-To: References: <201904250920.56038.bernhard@intevation.de> Message-ID: <20190829230256.GA30272@lab.bjmgeek.science> On Thu, Apr 25, 2019 at 11:19:15AM +0200, Kristian Fiskerstrand wrote: > On 4/25/19 9:20 AM, Bernhard Reiter wrote: > > Wikipedia points out a strong sensitivity of the algorithm to the quality of > > random number generators and that implementations could deliberately leak > > information in the signature [3]. This alone probably is a reason to switch > > keys. > > This isn't really a major point given rfc6979 ( > https://tools.ietf.org/html/rfc6979 ): Deterministic Usage of the > Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature > Algorithm (ECDSA) > Does GnuPG use deterministic DSA / ECDSA? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Aug 30 14:12:54 2019 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 30 Aug 2019 14:12:54 +0200 Subject: What is the practical strength of DSA1024/Elgamal2048 (former GnuPG default)? In-Reply-To: <20190829230256.GA30272@lab.bjmgeek.science> References: <201904250920.56038.bernhard@intevation.de> <20190829230256.GA30272@lab.bjmgeek.science> Message-ID: <93a2bb4c-0c3f-6b95-f82e-6676f3495c89@sumptuouscapital.com> On 30.08.2019 01:02, Brian Minton wrote: > On Thu, Apr 25, 2019 at 11:19:15AM +0200, Kristian Fiskerstrand wrote: >> On 4/25/19 9:20 AM, Bernhard Reiter wrote: >>> Wikipedia points out a strong sensitivity of the algorithm to the quality of >>> random number generators and that implementations could deliberately leak >>> information in the signature [3]. This alone probably is a reason to switch >>> keys. >> This isn't really a major point given rfc6979 ( >> https://tools.ietf.org/html/rfc6979 ): Deterministic Usage of the >> Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature >> Algorithm (ECDSA) >> > Does GnuPG use deterministic DSA / ECDSA? > Yes (at least for modern versions, iirc it was introduced in libgcrypt 1.6.0, but it has been used for 6 or so years) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From brian at minton.systems Fri Aug 30 18:41:48 2019 From: brian at minton.systems (Brian Minton) Date: Fri, 30 Aug 2019 11:41:48 -0500 Subject: gpg tells me a signature from my own key is a forgery. Message-ID: <20190830164148.GA666@lab.bjmgeek.science> I am testing signing with multiple keys. However, gpg tells me that my own key is a forgery. I know it is not a forgery because I didn't forge it. Is there a way to tell gpg that my own key is good? I'm using trust model tofu+pgp, and both of my keys are cross-signed and set to ultimate trust. Here's an example: $ echo this message is signed|gpg --local-user 37B9507ACFF2016E! --local-user 6B8EB3A065CFBAA9! --local-user 04D3ED26E707AD0643EBA7EC44F35EDB355D526A --clearsign|gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... this message is signed gpg: Signature made Fri 30 Aug 2019 11:36:33 AM CDT gpg: using EDDSA key EED0158013DC2E6D6E001EA437B9507ACFF2016E gpg: issuer "brian at minton.systems" gpg: Good signature from "Brian Minton " [ultimate] gpg: aka "keybase.io/bjmgeek " [ultimate] gpg: aka "Brian Minton " [ultimate] gpg: aka "Brian Minton " [ultimate] gpg: aka "Brian Minton " [ultimate] gpg: aka "Brian Minton " [ultimate] gpg: aka "[jpeg image of size 5202]" [never] gpg: WARNING: We do NOT trust this key! gpg: The signature is probably a FORGERY. gpg: Signature made Fri 30 Aug 2019 11:36:33 AM CDT gpg: using DSA key F9C4BB760E783F0DEC10A68A6B8EB3A065CFBAA9 gpg: issuer "brian at minton.systems" gpg: Good signature from "Brian Minton " [ultimate] gpg: aka "keybase.io/bjmgeek " [ultimate] gpg: aka "Brian Minton " [ultimate] gpg: aka "Brian Minton " [ultimate] gpg: aka "Brian Minton " [ultimate] gpg: aka "Brian Minton " [ultimate] gpg: aka "[jpeg image of size 5202]" [never] gpg: WARNING: We do NOT trust this key! gpg: The signature is probably a FORGERY. gpg: Signature made Fri 30 Aug 2019 11:36:33 AM CDT gpg: using EDDSA key 04D3ED26E707AD0643EBA7EC44F35EDB355D526A gpg: issuer "brian at minton.systems" gpg: Good signature from "Brian Minton " [ultimate] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: not available URL: From brian at minton.name Fri Aug 30 19:02:25 2019 From: brian at minton.name (Brian Minton) Date: Fri, 30 Aug 2019 13:02:25 -0400 Subject: gpg tells me a signature from my own key is a forgery. In-Reply-To: <20190830164148.GA666@lab.bjmgeek.science> References: <20190830164148.GA666@lab.bjmgeek.science> Message-ID: <145ba81b-75b7-9d81-1ece-4d5d7127ce78@minton.name> On 8/30/19 12:41 PM, Brian Minton wrote: > I am testing signing with multiple keys. However, gpg tells me that my > own key is a forgery. I know it is not a forgery because I didn't forge > it. Is there a way to tell gpg that my own key is good? I'm using > trust model tofu+pgp, and both of my keys are cross-signed and set to > ultimate trust. oh, I found the problem I had "sender brian at minton.systems" in my gpg config file.? When I commented that line out, it worked fine. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 456 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Sat Aug 31 12:45:51 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 31 Aug 2019 12:45:51 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: References: <20190825204054.00000b9e.sac@300baud.de> Message-ID: <20190831124551.0000600b.sac@300baud.de> Daniel Clery wrote: Hi, > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 [snip] > -----BEGIN PGP SIGNATURE----- > Version: Mailvelope v4.1.0 > Comment: https://www.mailvelope.com I just noticed that you use Mailvelope on your site, awesome! Can you please tell me what web mailer you have installed in order to run Mailvelope on an own domain? I recently started to use Mailvelope, with several email providers, and find it pretty awesome. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From andrewg at andrewg.com Sat Aug 31 13:44:09 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 31 Aug 2019 12:44:09 +0100 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <20190831124551.0000600b.sac@300baud.de> References: <20190825204054.00000b9e.sac@300baud.de> <20190831124551.0000600b.sac@300baud.de> Message-ID: <61DD45A4-ABF0-4043-B90F-FE7AF032E5BD@andrewg.com> > On 31 Aug 2019, at 11:45, Stefan Claas via Gnupg-users wrote: > > Can you please tell me what web mailer you have installed in > order to run Mailvelope on an own domain? I recently migrated from squirrelmail to roundcube on my own domain and I would recommend it. Mailvelope will support any roundcube installation if you add the appropriate domain to its whitelist. I have found though that while Mailvelope works well with manually imported or generated private keys, its integration with gnupg for e.g. smart card support is very sketchy due to lack of gpgme-json packaging in the major distributions. DKG has been trying to push it in debian but afaict there isn?t a package available yet. A From sac at 300baud.de Sat Aug 31 14:11:19 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 31 Aug 2019 14:11:19 +0200 Subject: Slightly OT - mobile OpenPGP usage In-Reply-To: <61DD45A4-ABF0-4043-B90F-FE7AF032E5BD@andrewg.com> References: <20190825204054.00000b9e.sac@300baud.de> <20190831124551.0000600b.sac@300baud.de> <61DD45A4-ABF0-4043-B90F-FE7AF032E5BD@andrewg.com> Message-ID: <20190831141119.00000854.sac@300baud.de> Andrew Gallagher wrote: > > > On 31 Aug 2019, at 11:45, Stefan Claas via Gnupg-users > > wrote: > > > > Can you please tell me what web mailer you have installed in > > order to run Mailvelope on an own domain? > > I recently migrated from squirrelmail to roundcube on my own domain and I > would recommend it. Mailvelope will support any roundcube installation if you > add the appropriate domain to its whitelist. Awesome!!! Thanks a lot! Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas