Re: Adding new uid to causes bad signature

[Andrew Gallagher via Gnupg-users]

On 1 May 2024, at 10:08, Rens Rikkerink via Gnupg-users  
wrote:
> 
> Lately I've been trying to add a new uid to my public key, I have
> however so far been unsuccessful in doing so. Every time I try to do
> so, I then immediately get "1 bad signature" which wasn't present
> beforehand. It's probably worth noting that my private key is stored
> on a Yubikey 5 NFC (smartcard).

FYI it’s not just gnupg that complains about the bad signature, so does 
hockeypuck. So I’d assume that the card didn’t create the signature properly. 
Does this happen consistently?

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: x488 vs all other : keyid flip

[Andrew Gallagher via Gnupg-users]

On 17 Apr 2024, at 15:43, Christian Sommer  wrote:
> 
> You are right Andrew!
> 
> I indeed choose to preset the "with-fingerprint" option in my
> gpg.conf. By removing it, listing my keys give back the full 64
> character long fingerprint of my X448 key.

Good to hear!

I think the best solution is for gnupg to ignore the `with-fingerprint` 
configuration option. Modern versions display primary key fingerprints by 
default anyway, so the alternative display format is both redundant and 
potentially confusing.

I would be particularly concerned that people with different settings in their 
gpg.conf would see a mismatch between the 50-character fingerprint on one 
machine and the 64-character fingerprint on another, and incorrectly infer that 
something shady was going on. Differences in whitespace formatting are broadly 
expected (ref: credit card numbers) but truncation is not.

And to pick up on an earlier point, short key IDs should never be displayed or 
processed under any circumstances. Evil32 was a whole decade ago.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: x488 vs all other : keyid flip

[Andrew Gallagher via Gnupg-users]

On 28 Mar 2024, at 12:54, Christian Sommer via Gnupg-users 
 wrote:
> 
> when explicitly telling GnuPG to display x448 fingerprints (gpg
> --fingerprint) it just spits out the "abbreviated hex format" by takes
> the first 50 bytes and sweeping the rest under the rug! Not very nice.

Hi, Christian.

This seems to depend on whether you have “with-fingerprint” enabled in your 
gpg.conf file. I commented out this line from my own gpg.conf, and I was able 
to reproduce Werner’s full 64-character v5 fingerprint output. With this 
configuration line enabled I could only see your 50-character fingerprint 
output.

Hope this helps,
Andrew.



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: x488 vs all other : keyid flip

[Andrew Gallagher via Gnupg-users]

On 3 Apr 2024, at 10:32, Werner Koch  wrote:
> 
> On Tue,  2 Apr 2024 18:53, Andrew Gallagher said:
> 
>> technical challenge since no modern software supports them, and gnupg1
>> doesn’t implement --list-packets :-) But I have to admit they do
> 
> Sure it has the --list-packets command.  This command dates back to the
> very first release.

Please ignore my above remark; PEBKAC :facepalm:

> Given that Ubuntu's Hockeypuck is the default keyserver for GnuPG for
> most people (i.e. on Windows) it would be good if it continues to
> support at least the default keys.  Whether X448 or the forthcominng
> Kyber subkeys are relevant for keyservers is a different questions.

I don’t see why a new algorithm would be fundamentally different from existing 
ones from a keyserver point of view. I would hope that they could be supported 
seamlessly.

> FWIW, I have severe doubts on the usefulness of public keyservers given
> the DoS problems for users and the wrong - but real - assumption of
> users that keys from a keyserver are trustworthy.  Sending keys with an
> initial mail is a better way; keyserver should be used only to provide
> subkey updates and revocations - no search by user id.

I agree that keyservers are not ideal for userid search - unfortunately we 
haven’t collectively settled on an alternative yet. Sending initial keys with 
every email may not be the best solution for large key material such as Kyber, 
although one could imagine a two-step process such as looking up the signing 
key of a signed mail via a keyserver. And trust calculations would still be an 
issue of course; TOFU protects against a passive eavesdropper but doesn’t do 
much against an active MITM… there’s a lot of work still to be done to improve 
the UX of mutual verification.

> I don't care about the IETF OpenPGP WG^Committee anymore.

Like it or not, we have to find some way to tolerate each other’s existence. 
And petty name-calling doesn’t help.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: x488 vs all other : keyid flip

[Andrew Gallagher via Gnupg-users]

On 2 Apr 2024, at 15:24, Werner Koch  wrote:
> 
> On Tue,  2 Apr 2024 12:39, Andrew Gallagher said:
> 
>> Are you saying that this is *not* a novel failure mode? Because we’ve
> 
> No.  We had v2, v3 and v4 keyes in all kind of combinations in the past
> (even as part of subkeys) and back then the two OpenPGP implementations
> had no problems with that.  The whole point of packet version numbers is
> to be able to ignore such packets.

This intrigued me, so I went back through the SKS dataset and found exactly 
four (4) v4 primary keys with v3 subkeys. This was quite a technical challenge 
since no modern software supports them, and gnupg1 doesn’t implement 
--list-packets :-) But I have to admit they do exist… and rfc4880 technically 
doesn’t forbid them. Still, I’m sure most people would find their existence as 
surprising as that of v3 sbinds over v4 subkeys (which are several orders of 
magnitude more common).

>> different version number (since v3 did not support subkeys). Have you
>> interop-tested this with other implementations? Besides RNP? What were
> 
> If there are new implementaions they should check interop with the
> de-facto standards which are PGP, GnuPG and later RNP.  There is also
> the widely used BouncyCastle library and we have not seen problems with
> it except when ppl ignore features of these library.

BouncyCastle is quite low level, and AFAICT does not enforce much in the way of 
packet grammar etc., so may not be the best comparison. And surely the entire 
point of a written specification is to avoid "de-facto standard” reference 
implementations?

> But let me remark for the records that GnuPG has been the entity which
> always used the term /OpenPGP/ instead of /PGP/ or - as many Linux
> people did - the term /GPG/ keys.  Thus we, and in particular me,
> stressed that this is the OpenPGP standard which GnuPG implements,
> popularized, took care, and pride of.  Sure it does no "belong" to us or
> anyone - it is term without having a trademark.

This is fair, and thank you. Not everyone is so careful.

> OTOH, tehre is a
> respoisbility here to keep the repudiation of that standard high - this
> is what the /current OpenPGP WG participants/ don't a do anymore since
> fall 2021.

Reputation is a matter of publicly expressed opinion, and by far the greatest 
amount of text declaring that OpenPGP no longer has a good reputation has been 
written by you. So this is a circular argument.

>>> how should an implementation behave if it wants to support both the
>>> librepgp and crypto-refresh specs?
> 
> That is up to those implementaions who want to destroy a solid standard.
> Why should I help them?

Let us be clear here: you appear to be saying that if I want to update 
hockeypuck to support both librepgp and crypto-refresh artifacts, I am helping 
to destroy a solid standard? Or have I misunderstood your position?

> This is a GnuPG mailing list and you are
> welcome to discuss technical details of stuff relevant to GnuPG and
> OpenPGP (up to fall 2021).  Everything else is better addressed to the
> crypto-refresh commitee.

I will bring this to the WG, with your comments.

Thanks,
A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: x488 vs all other : keyid flip

[Andrew Gallagher via Gnupg-users]

On 2 Apr 2024, at 11:58, Werner Koch  wrote:
> 
> On Fri, 29 Mar 2024 13:00, Andrew Gallagher said:
> 
>> V5 subkeys of v4 primary keys would appear to introduce a novel
>> failure mode. It should be noted that in crypto-refresh, adding a
> 
> Nope.

Are you saying that this is *not* a novel failure mode? Because we’ve never 
before had a key of one version number with a subkey of a different version 
number (since v3 did not support subkeys). Have you interop-tested this with 
other implementations? Besides RNP? What were the results?

> A v5 key has nothing to do a v4 signature and having different
> algorithm on the primary key and the subkeys is really common and
> allowed us once to slowly introduce RSA and ECC without any major
> problems.  This is why we will do the same for PQC encryption.

Yes, but a subkey of a different *algorithm* is anticipated by the spec and 
should work (in principle). A subkey of a different *version* is a different 
matter. Or is it specified somewhere that I have overlooked?

> All in all a really minor changes and not worth a long debate.

It may be a minor change, but if it breaks interop it is still worth debating 
the consequences.

> The crypto-refresh has a lot of things which breaks OpenPGP and that
> draft, or soon to be RFC, does not care about backward compatibility.
> They should not have used the term OpenPGP for this.

You keep repeating these talking points, but they are simply not true.

1. crypto-refresh defines a *different* set of extensions to OpenPGP than GnuPG 
supports, but these do not “break” OpenPGP.
2. crypto-refresh has bumped all of its packet version numbers specifically to 
avoid compatibility issues. Just because the WG have a different opinion does 
not mean that they don’t care.
3. The term “OpenPGP” does not belong to GnuPG.

And I notice that you have not addressed the most important point in my last 
email:

> how should an implementation behave if it wants to support both the librepgp 
> and crypto-refresh specs?

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: x488 vs all other : keyid flip

[Andrew Gallagher via Gnupg-users]

On 28 Mar 2024, at 09:47, Werner Koch via Gnupg-users  
wrote:
> 
> x448 keys are created as version 5 keys and version 5 keys come with a
> 32 byte fingerprint (v4 has 20 bytes).
...
> Here is an example:
> 
> pub   ed25519 2016-02-02 [SC]
>  FD8FEC4F8595AB1B6F60D43FC2CED0800E50ACF1
> uid   [ unknown] chicago 
> sub   cv25519 2016-02-02 [E]
>  532D5C7677B4D806B50B0E0F11E7BF9EE1034B1C
> sub   cv448 2024-03-27 [E]
>  FB6A3BC5EB92C8AA9F3807A9B4C79C38F16E9AA4CF9384B07485923574773DCF
> 
> where a v5 subkey has been added.

V5 subkeys of v4 primary keys would appear to introduce a novel failure mode. 
It should be noted that in crypto-refresh, adding a non-v4 subkey to a v4 
primary key is explicitly forbidden:

> Every subkey for a v4 primary key MUST be a v4 subkey.

https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-13#section-10.1.3

I notice in the LibrePGP draft that there is no specification of this hybrid 
v4/v5 construction. The corresponding section of the spec doesn’t even mention 
v5 TPKs at all, just v3 and v4:

https://datatracker.ietf.org/doc/html/draft-koch-librepgp#name-key-structures

This appears to be a verbatim copy of the corresponding section from RFC4880 
that has not (yet) been updated to take account of v5:

https://datatracker.ietf.org/doc/html/rfc4880#section-12.1

So a few questions arise: is this a deliberate design decision, and if so what 
considerations were taken into account in that design, and how should an 
implementation behave if it wants to support both the librepgp and 
crypto-refresh specs?

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Finding all files encrypted with a certain key

[Andrew Gallagher via Gnupg-users]

Apologies to the `file` authors, it’s a BSD utility, not GNU.

A

On 24 Oct 2023, at 10:11, Andrew Gallagher via Gnupg-users 
 wrote:
> 
> Signed PGP part
> On 24 Oct 2023, at 04:38, Felix E. Klee  wrote:
>> 
>> For the purpose of re-encryption with a new key, I’d like to find all
>> files that are encrypted with my key BEF6EFD38FE8DCA0. All encrypted
>> files, independent of key, have the extension `.gpg`.
>> 
>> How do I do that for a massive directory tree?
> 
> Hi, Felix.
> 
> GNU `file` will print the encryption key ID:
> 
> ```
> andrewg@fum:~$ file hidden_service/private_key.gpg
> hidden_service/private_key.gpg: PGP RSA encrypted session key - keyid: 
> 6B090693 14549D4B RSA (Encrypt or Sign) 4096b .
> ```
> 
> That keyid is the encryption subkey, so you can grep file’s batch output for 
> its short ID, e.g.:
> 
> ```
> file *.gpg | grep $SHORT_ENC_SUBKEY_ID
> ```
> 
> Note that due to file’s use of whitespace, you can’t grep for the long ID 
> unless you mangle it accordingly.
> 
> If you don’t have GNU file, you can try `gpg —list-packets` instead, but this 
> will be slower as gpg will parse the entire file. Also, it only parses one 
> file at a time, and the encryption key ID is output on STDERR. You can invoke 
> it in a bash loop like this:
> 
> ```
> find . -name '*.gpg' -print0 | while read -r -d '' file; do
>echo -n "$file: "
>gpg --list-packets "$file" 2>&1 >/dev/null
> done | grep $SHORT_ENC_SUBKEY_ID
> ```
> 
> A
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Finding all files encrypted with a certain key

[Andrew Gallagher via Gnupg-users]

On 24 Oct 2023, at 04:38, Felix E. Klee  wrote:
> 
> For the purpose of re-encryption with a new key, I’d like to find all
> files that are encrypted with my key BEF6EFD38FE8DCA0. All encrypted
> files, independent of key, have the extension `.gpg`.
> 
> How do I do that for a massive directory tree?

Hi, Felix.

GNU `file` will print the encryption key ID:

```
andrewg@fum:~$ file hidden_service/private_key.gpg
hidden_service/private_key.gpg: PGP RSA encrypted session key - keyid: 6B090693 
14549D4B RSA (Encrypt or Sign) 4096b .
```

That keyid is the encryption subkey, so you can grep file’s batch output for 
its short ID, e.g.:

```
file *.gpg | grep $SHORT_ENC_SUBKEY_ID
```

Note that due to file’s use of whitespace, you can’t grep for the long ID 
unless you mangle it accordingly.

If you don’t have GNU file, you can try `gpg —list-packets` instead, but this 
will be slower as gpg will parse the entire file. Also, it only parses one file 
at a time, and the encryption key ID is output on STDERR. You can invoke it in 
a bash loop like this:

```
find . -name '*.gpg' -print0 | while read -r -d '' file; do
echo -n "$file: "
gpg --list-packets "$file" 2>&1 >/dev/null
done | grep $SHORT_ENC_SUBKEY_ID
```

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Sirs:

[Andrew Gallagher via Gnupg-users]

On 25 Aug 2023, at 18:23, xyz938 via Gnupg-users  wrote:
> 
> How do I hide the fact that the key is 32764 on the keyserver?

You can’t. That’s like trying to publish a book written in Chinese without 
letting anyone know that it is written in Chinese.

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Sirs:

[Andrew Gallagher via Gnupg-users]

On 25 Aug 2023, at 19:09, Andrew Gallagher  wrote:
> 
> On 25 Aug 2023, at 18:23, xyz938 via Gnupg-users  
> wrote:
>> 
>> How do I hide the fact that the key is 32764 on the keyserver?
> 
> You can’t. That’s like trying to publish a book written in Chinese without 
> letting anyone know that it is written in Chinese.

BTW, hockeypuck probably won’t accept a public key that large anyway, as the 
self-sig will most likely not validate (I have not tested this though).

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: "gpg --card-edit" with multiple card readers (Yubikey)

[Andrew Gallagher via Gnupg-users]

On 17 Jul 2023, at 18:36, Michael Richardson  wrote:
> 
> Andrew Gallagher  wrote:
>>> Juanjo via Gnupg-users  wrote:
>>> 
>>> "Keys stored on YubiKey are non-exportable (as opposed to file-based
>>> keys that are stored on disk) and are convenient for everyday use. "
>>> 
>>> In my case, I want the same key on multiple devices, which 3 to 5 core
>>> members of an open source project will hold.  (I am also considering
>>> if we want a higher security key which would be secret split across
>>> those keys, but we aren't building a CA here, but..)
>>> 
>>> Is that possible with these devices?
>>> 
>>> In some cases keys can be transfered in an encrypted form for another
>>> device, but not recovered by outsiders.
> 
>> This is not possible with a Yubikey. If you want the same (sub)keys on
>> multiple devices you must generate them on your laptop and copy them to
>> each device in turn, remembering not to delete until you’re done.
> 
> okay, so in this case we are using the Yubikey only as a storage, equivalent
> essentially to a USB storage?  Or does it still do crypto on the device?

The yubikey performs cryptography on the device, but does have a small amount 
of flash memory to store the private key material. The yubikey does not provide 
any method to copy the private key material back off that storage, it can only 
be overwritten or used by the yubikey’s own processor.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: "gpg --card-edit" with multiple card readers (Yubikey)

[Andrew Gallagher via Gnupg-users]

On 15 Jul 2023, at 20:36, Michael Richardson  wrote:
> 
> Juanjo via Gnupg-users  wrote:
> 
>> This may be a good starting point:
>> https://github.com/drduh/YubiKey-Guide
> 
> "Keys stored on YubiKey are non-exportable (as opposed to file-based keys
> that are stored on disk) and are convenient for everyday use. "
> 
> In my case, I want the same key on multiple devices, which 3 to 5 core
> members of an open source project will hold.
> (I am also considering if we want a higher security key which would be secret
> split across those keys, but we aren't building a CA here, but..)
> 
> Is that possible with these devices?
> 
> In some cases keys can be transfered in an encrypted form for another device,
> but not recovered by outsiders.

This is not possible with a Yubikey. If you want the same (sub)keys on multiple 
devices you must generate them on your laptop and copy them to each device in 
turn, remembering not to delete until you’re done.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Looking for keyserver software without any validation or fancy features

[Andrew Gallagher via Gnupg-users]

(resending because the previous mail went out HTML-only, apologies)

Hi, Bernd.

> hagrid and huckeypuck are total overkill,

(Disclaimer: I’m one of the hockeypuck contributors)

If you have docker-compose installed, it’s *very* easy to spin up a test 
instance of hockeypuck, see the README at 
https://github.com/hockeypuck/hockeypuck

You will need a non-empty keydump to start with, but you can export a single 
key to a file with the suffix “.gpg” and it should suffice.

> and at least hagrid is not
> even /intended/ to be "self hosted".

I’m pretty sure you can self-host hagrid, although I haven’t tested it.

> I have seen https://github.com/SKS-Keyserver/sks-keyserver but still
> have to check it out if it really suites my needs.

SKS-keyserver is very similar to hockeypuck (hockeypuck was first developed as 
an SKS-keyserver replacement). It does have the ability for a quick-build that 
serves static files directly without ingesting them into a database in advance, 
however you will still probably have to build the ptree (at least in its 
default configuration). It also has an unofficial docker image at 
https://registry.hub.docker.com/r/zhusj/sks 

> Are there any other options?

https://github.com/PennockTech/openpgpkey-control comes to mind.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Looking for keyserver software without any validation or fancy features

[Andrew Gallagher via Gnupg-users]

Hi, Bernd. hagrid and huckeypuck are total overkill,(Disclaimer: I’m one of the hockeypuck contributors)If you have docker-compose installed, it’s *very* easy to spin up a test instance of hockeypuck, see the README at https://github.com/hockeypuck/hockeypuckYou will need a non-empty keydump to start with, but you can export a single key to a file with the suffix “.gpg” and it should suffice. and at least hagrid is noteven /intended/ to be "self hosted".I’m pretty sure you can self-host hagrid, although I haven’t tested it.I have seen https://github.com/SKS-Keyserver/sks-keyserver but stillhave to check it out if it really suites my needs.SKS-keyserver is very similar to hockeypuck (hockeypuck was first developed as an SKS-keyserver replacement). It does have the ability for a quick-build that serves static files directly without ingesting them into a database in advance, however you will still probably have to build the ptree (at least in its default configuration). It also has an unofficial docker image at https://registry.hub.docker.com/r/zhusj/sksAre there any other options?https://github.com/PennockTech/openpgpkey-control comes to mind.A___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: get OpenPGP pubkeys authenticated using German personal ID

[Andrew Gallagher via Gnupg-users]

On 3 Jun 2023, at 01:56, Jacob Bachmeyer  wrote:
> 
> Alexander Leidinger via Gnupg-users wrote:
>> [...]
>> 
>> I don't remember if there was a challenge/response or not. As I still have 
>> the email with the signed key, I can tell that the signature can arrive via 
>> a TLS encrypted SMTP channel directly from governicus (and they have a SPF 
>> setup but not DKIM):
>> ---snip---
>> 
>> Received: from smtp.governikus.de (smtp.governikus.de [194.31.70.126])
>> (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
>>  key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
>>  client-signature RSA-PSS (4096 bits) client-digest SHA256)
>> (Client CN "VPR-BOS004.dmz.bosnetz.de", Issuer "VPR-BOS004.dmz.bosnetz.de" 
>> (not verified))
>> 
>> ---snip---
>> 
> 
> Am I misreading that header or does Governikus' outgoing SMTP have a 
> self-signed client certificate for 'VPR-BOS004.dmz.bosnetz.de'?  That does 
> not inspire confidence…


I wouldn’t read too much into this. The client cert here is probably used for 
internal purposes, and their MXes may be configured to offer their client certs 
by default - external sites won’t check it anyway, so no harm done.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: get OpenPGP pubkeys authenticated using German personal ID

[Andrew Gallagher via Gnupg-users]

On 1 Jun 2023, at 15:50, Johan Wevers via Gnupg-users  
wrote:
> 
> On 2023-05-31 16:55, Bernhard Reiter wrote:
> 
>> Governikus provides the online service for authenticating your OpenPGP key on
>> behalf of the German Federal Office for Information Security (BSI). This
>> online service compares the name read from your ID card, your electronic
>> residence permit or eID card for citizens of the European Union with the name
>> specified in your OpenPGP key. If the names match, your public key is
>> electronically signed by Governikus, confirming the match.
> 
> Considering the persistent attempts of the EU to scan all encrypted
> communication, would you think it is wise to prove to one of the
> governments pushing this which key is yours? GnuPG encrypted mail can be
> analyzed to see what the receiver's keyID is so using such a key with
> another mail address would inform any snooper that it is yours.

If you want to maintain two separate online identities, and keep that linkage 
secret from your government, using the same encryption key for both is pretty 
high up the list of very bad ideas.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: get OpenPGP pubkeys authenticated using German personal ID

[Andrew Gallagher via Gnupg-users]

On 1 Jun 2023, at 12:23, Alexander Leidinger via Gnupg-users 
 wrote:
> 
> Quoting Bernhard Reiter  > (from Wed, 31 May 2023 16:55:05 +0200):
> 
>> Obviously they cannot authenticate the email address
>> so once I have a common name, we get collisions?
> 
> The signature is send to the email listed in the key. In case you share a 
> name with someone which has a PGP key and you sign this key, the person(s) 
> with access to that email account will get the signature.

This is not best practice. Normally when email verification is being performed, 
the gated action (such as certification, account creation etc.) is not done 
until after a (time-bound!) challenge/response succeeds. This places too much 
emphasis on verification of the (non-unique) “real name” component of the 
UserID, and not enough on the machine-readable email address.

This opens up more fundamental questions about the meaning of signatures over 
RFC822 UserIDs - do they validate the “real name”, the email address, or some 
combination of the two? For example, an email-validating CA may only check the 
email address part, treating the “real name” as little more than a comment; 
while Governikus appear to be doing it the other way around. It is of course up 
to the receiver to decide how to interpret signatures, but it only compounds 
the problem when not only is the signer’s trustworthiness in question, but also 
their intent. How do you interpret the validity of a claim when it’s not even 
clear what the claim is?

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: "gpg: no valid OpenPGP data found" error when importing public key from sks

[Andrew Gallagher via Gnupg-users]

Hi, Guillermo.

You don’t say what sort of keys these are. V4? V5? Elliptic curve? Some recent 
kinds of keys may not be compatible with SKS. Have you compared with hockeypuck 
to see if it serves them any differently?

Thanks,
Andrew.

> On 12 May 2023, at 21:08, Guillermo Montoya Naranjo via Gnupg-users 
>  wrote:
> 
> Good afternoon, I have an sks server installed, which synchronizes with 
> kleopatra, I create a pair of openPGPG keys, which I then publish to the sks 
> server and it does it successfully, but when I execute the search option, it 
> throws me the following error, as shown in the image
> 
> gpg: no valid OpenPGP data found
> gpg: Total amount processed: 0
> I have installed Gpg4win 4.1.0 and a sks 1.1.6 server
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: out-of-key UIDs [was: ADK's]

[Andrew Gallagher via Gnupg-users]

On 5 May 2023, at 17:55, Ineiev  wrote:
> 
> On Thu, May 04, 2023 at 11:01:36AM +0100, Andrew Gallagher wrote:
>>> I tried something like this with my MUA, I believe that doesn't work:
>>> it first looks for appropriate keys, probably using --list-keys;
>>> in fact, it insists on choosing a single key when multiple ones
>>> are available.
>> 
>> Which MUA is this?
> 
> Mutt.

Ah, I see this has been raised before as a missing feature in [neo]mutt:

https://github.com/neomutt/neomutt/issues/404

A


signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: out-of-key UIDs [was: ADK's]

[Andrew Gallagher via Gnupg-users]

On 4 May 2023, at 10:43, Ineiev  wrote:
> 
> On Thu, May 04, 2023 at 09:52:54AM +0100, Andrew Gallagher wrote:
>> 
>> andrewg@serenity % gpg --group 
>> fn...@test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A -r fn...@test.eu -e < 
>> /etc/shells > shells.gpg
>> gpg: 0x40F9B9601900E974: There is no assurance this key belongs to the named 
>> user
> 
> I tried something like this with my MUA, I believe that doesn't work:
> it first looks for appropriate keys, probably using --list-keys;
> in fact, it insists on choosing a single key when multiple ones
> are available.

Which MUA is this? I know that Thunderbird doesn’t support gnupg’s groups any 
more, but it has an equivalent inbuilt feature that you can configure 
separately.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: out-of-key UIDs [was: ADK's]

[Andrew Gallagher via Gnupg-users]

On 4 May 2023, at 06:46, Ineiev  wrote:
> 
> On Mon, May 01, 2023 at 03:16:12PM +0100, Andrew Gallagher wrote:
>> On 1 May 2023, at 12:40, Ineiev via Gnupg-users  
>> wrote:
>>> now, I generate a key
>>> for y...@guan.edu locally and add 0123456789ABCDEF as an ADK (BTW,
>>> will GnuPG complain if the only encryption-capable subkey is ADK?
>> 
>> Or you could just use an alias…?
> 
> I don't think I fully understand what you mean.
> 
> $ gpg --group fn...@test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A 
> --list-keys fn...@test.eu
> gpg: error reading key: No public key
> $ gpg --list-keys BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A | head -n1
> pub   rsa2048 2014-10-21 [SC] [expires: 2024-10-17]
> $ gpg --version | head -n2
> gpg (GnuPG) 2.2.41
> libgcrypt 1.8.10



—list-keys doesn’t expand groups. Try this instead:


andrewg@serenity % gpg --group 
fn...@test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A -r fn...@test.eu -e < 
/etc/shells > shells.gpg
gpg: 0x40F9B9601900E974: There is no assurance this key belongs to the named 
user

sub  rsa2048/0x40F9B9601900E974 2014-10-21 Ineiev (fencepost) 
 Primary key fingerprint: BD9D 4DEE 7B2F F1CB EF2E  E0C4 E0AC D3E0 CBE7 874A
  Subkey fingerprint: F495 D912 C380 C534 23CD  6B7C 40F9 B960 1900 E974

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y
andrewg@serenity % gpg --list-packets shells.gpg
gpg: encrypted with rsa2048 key, ID 0x40F9B9601900E974, created 2014-10-21
  "Ineiev (fencepost) "
gpg: problem with fast path key listing: IPC parameter error - ignored
gpg: public key decryption failed: No secret key
gpg: decryption failed: No secret key
# off=0 ctb=85 tag=1 hlen=3 plen=268
:pubkey enc packet: version 3, algo 1, keyid 40F9B9601900E974
data: [2047 bits]
# off=271 ctb=d2 tag=18 hlen=2 plen=187 new-ctb
:encrypted data packet:
length: 187
mdc_method: 2
andrewg@serenity %

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ADK's

[Andrew Gallagher via Gnupg-users]

On 2 May 2023, at 02:18, Michael Richardson  wrote:
> 
> It's the initial investigation of an irregularity where there could be a 
> problem.

These examples are becoming increasingly contrived. If you are investigating 
fraud by someone who can read all your company emails, don’t discuss it over 
company email. This is really basic stuff.

> There is also an issue with 2FA and password reset emails: it's something
> that may be a vulnerability to archive. Okay, few are encrypted today, but
> we can hope.

Password reset emails are supposed to be immune to replay attacks.

> Many companies with forced proxis are starting to realize that
> they become liable when they store banking login cookies.

The only way that a company would end up archiving a password reset email 
encrypted to an ADK would be if an employee was using their work email address 
for password resets. If using their work email for this purpose is inadvisable, 
then it is inadvisable regardless of ADKs. 

> Anyway, I think senders need to be made mildly aware that it's occuring, and
> I think they should be allowed to pick a specific ADK or suppress them all in
> certain circumstances best decided by them.

If I add an ADK notation to my key for legitimate reasons that I do not discuss 
with all my correspondents, on what basis do they decide to second guess it? 
How is this any different from where I store my private key, whether it is 
escrowed, whether it has a password etc, which are invisible to the sender and 
generally none of their business? If you don’t trust how I manage my key, the 
only reasonable recourse is to avoid using it.

ADK introduces no new considerations that are not also an issue for key escrow, 
which happens anyway, and has several advantages over escrow, particularly 
transparency. If however it became common for people to disable encrypting to 
the ADK, it would simply encourage companies to stop using it and keep using 
escrow, which doesn’t prevent any of the proposed abuses. 

If you don’t trust your correspondent’s employer, then the only effective 
course of action is to not use their employer’s email address. Technical 
measures cannot protect you from opsec problems.

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ADK's

[Andrew Gallagher via Gnupg-users]

On 1 May 2023, at 12:40, Ineiev via Gnupg-users  wrote:
> now, I generate a key
> for y...@guan.edu locally and add 0123456789ABCDEF as an ADK (BTW,
> will GnuPG complain if the only encryption-capable subkey is ADK?

Or you could just use an alias…?

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ADK's

[Andrew Gallagher via Gnupg-users]

On 30 Apr 2023, at 14:42, Johan Wevers via Gnupg-users  
wrote:
> 
> On 2023-04-30 14:58, Andrew Gallagher via Gnupg-users wrote:
>> Whether this is done voluntarily or under duress from their employer is an 
>> opsec issue, not a comsec one.
> 
> If it is an ex-employer that might be more compicated.

Indeed. If this is in your threat model then don’t use work email addresses for 
personal communication, because encryption cannot protect you.

>> The danger of an “ignore ADK” option is that it gives a false sense of 
>> security. It is already possible for an employer to require escrow of the 
>> decryption subkeys of their employees - ADK actually makes this process more 
>> transparent.
> 
> That might be, but it is nowhere certain that this escrow will happen,
> especially if they roll out adk's.

You’re inverting the burden of proof here. The important consideration is that 
E2E can’t prove that a key *wasn’t* escrowed - so it’s much better for the 
software to make no claims about it than potentially misleading ones. 

A



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ADK's

[Andrew Gallagher via Gnupg-users]

On 30 Apr 2023, at 13:45, Johan Wevers via Gnupg-users  
wrote:
> 
> On 2023-04-30 14:10, Werner Koch via Gnupg-users wrote:
> 
>> It does not make any sense so have such an option.  If a user wants to
>> allow colleagues or an archive system to decrypt her mails that is her
>> decision.
> 
> What I've had in practice in one company: you got a company key with a
> personal key and an adk added. Nothing to want from my part there. If I
> want to mail someone at such a company I may just want to ignore the adk.

E2E encryption can’t protect you from your correspondent disclosing your 
communication at the other end. Whether this is done voluntarily or under 
duress from their employer is an opsec issue, not a comsec one. If you don’t 
want your correspondent’s employer reading your emails, don’t send messages to 
their work email address.

The danger of an “ignore ADK” option is that it gives a false sense of 
security. It is already possible for an employer to require escrow of the 
decryption subkeys of their employees - ADK actually makes this process more 
transparent. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ADK's (was: [Announce] GnuPG 2.4.1 released)

[Andrew Gallagher via Gnupg-users]

On 30 Apr 2023, at 11:30, Johan Wevers via Gnupg-users  
wrote:
> 
> On 2023-04-30 1:15, ckeader via Gnupg-users wrote:
> 
>> Can't call it that as long as it's under user control (every long option of 
>> the software has an equivalent config file option. You don't add such a key 
>> via config or command line, no adsk will happen as it's not configured).
> 
> On my key, yes, I can choose to add an adk or not of course. But suppose
> I want to encrypt to a key that has an adk added, but I only want to
> encrypt to that key and not to the added adk? How do I do that?

Just curious, what’s the threat scenario here? If you suspect that your 
correspondent’s key preferences have been tampered with by a third party then 
surely the entire key is supect and shouldn’t be used at all? If on the other 
hand you believe that it has not been tampered with, but your correspondent has 
been negligent in configuring it, then maybe you shouldn’t trust your 
correspondent?

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Flooding attack against synchronising keyservers

[Andrew Gallagher via Gnupg-users]

Hi, all.

pgpkeys.eu is fully operational, is accepting key submissions and is syncing 
with two similarly recovered peers. The number of keys in the dataset is back 
to pre-flooding levels, and site reliability has been significantly improved.

If you are an operator and need assistance recovering your system, please get 
in touch.

Thanks,
A

> On 27 Mar 2023, at 18:47, Andrew Gallagher via Gnupg-users 
>  wrote:
> 
> Signed PGP part
> Hi, everyone.
> 
> The synchronising keyserver network has been under an intermittent flooding 
> attack for the past five days, resulting in the addition of approximately 3 
> million obviously-fake OpenPGP keys to the SKS dataset. The fake keys are 
> currently being submitted multiple times per second via a large number of Tor 
> exit relays, making them difficult to block using normal abuse mitigations. 
> If unaddressed, this will eventually fill up the disk of all public 
> synchronising servers.
> 
> Effective immediately, pgpkeys.eu has been temporarily disconnected from all 
> its peers, and is blocking all key submissions. It will remain available for 
> key lookups but will not allow key updates while the flooding attack 
> continues.
> 
> I strongly recommend that other keyserver operators take similar measures, 
> until a more permanent solution can be deployed.
> 
> A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Flooding attack against synchronising keyservers

[Andrew Gallagher via Gnupg-users]

Hi, everyone.

The synchronising keyserver network has been under an intermittent flooding 
attack for the past five days, resulting in the addition of approximately 3 
million obviously-fake OpenPGP keys to the SKS dataset. The fake keys are 
currently being submitted multiple times per second via a large number of Tor 
exit relays, making them difficult to block using normal abuse mitigations. If 
unaddressed, this will eventually fill up the disk of all public synchronising 
servers.

Effective immediately, pgpkeys.eu has been temporarily disconnected from all 
its peers, and is blocking all key submissions. It will remain available for 
key lookups but will not allow key updates while the flooding attack continues.

I strongly recommend that other keyserver operators take similar measures, 
until a more permanent solution can be deployed.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Optimal workflow with GPG signatures from multiple parties

[Andrew Gallagher via Gnupg-users]

On 04/03/2023 17:18, Ave Milia via Gnupg-users wrote:

What are some available solutions? How would you suggest to organize the keys? 
Maybe, there should be some signing server in-place, that the developers sends 
an artifact to?


I built something similar for $WORK. You lock down the signing server 
and use your preferred form of authentication to allow only your 
developers (and the build server) to submit an artifact for signature. 
This could be done using a simple REST API.


Once you have this in place, it would be easy to extend it with a second 
signing key for development purposes only, and make sure that only the 
production public key is distributed with your production artifacts. 
That way all your developers can get their dev builds signed, but only 
your build server and maybe your release manager have the credentials to 
sign with the production key. This could be done by linking the signing 
key to the user credentials, or by having two signing servers.


A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Unable to sign public key

[Andrew Gallagher via Gnupg-users]

On 31 Jan 2023, at 19:52, Joel via Gnupg-users  wrote:
> 
> Hello!
> 
> I am trying to sign a public key, but I get an error saying, `gpg: signing 
> failed: No secret key`. However, a normal signing on a file works perfectly 
> fine. I suspect it could be something because I have a yubikey and it might 
> not work as I initially expected. Have anyone had similar problems and know 
> how to fix it when you use a yubikey?

Yes, this is expected behaviour with a yubikey. The confusion arises with an 
unfortunate clash of terminology. When you “sign” someone else’s public key, 
you are technically “certifying” it - even though signing and certification use 
the same cryptographic operation (also called “signing”, hence the confusion), 
they are two different modes of operation and PGP treats them as entirely 
separate things.

The normal structure of a key is to have a primary key which is allowed to 
certify and sign, and an encryption subkey that is only allowed to (de)crypt. 
When using a yubikey, standard practice is to also create a signing subkey and 
store that and the encryption subkey (and optionally an authentication subkey) 
on the yubikey, but leave the primary on disk. The advantage is that if your 
yubikey is stolen, you can generate new subkeys and revoke the old ones, 
without having to revoke the primary. The disadvantage is that certification 
subkeys are not supported by the standard, so yubikeys (and other forms of 
smartcard) cannot normally certify other people’s keys.

You may be able to get around this by ensuring that your primary key is 
signing-capable (it is by default) and storing it instead of a signing subkey 
in the signing slot of your yubikey (caveat: I have not tested this!). But then 
you lose the main advantage of a yubikey (sacrificial subkeys). Otherwise, you 
can only certify other keys using the original computer that has your primary 
key on disk.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Ecrypt group email addresses

[Andrew Gallagher via Gnupg-users]

On 26 Jan 2023, at 22:40, Alex  wrote:
> 
> Clients that have their own OpenPGP implementation, like Mozilla
> Thunderbird, likely don't support groups.

Thunderbird does support encryption to groups, but you have to manually edit a 
JSON configuration file:

https://support.mozilla.org/en-US/kb/openpgp-recipient-alias-configuration

A


signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Subkeys renewing/expiring strategy

[Andrew Gallagher via Gnupg-users]

On 5 Jan 2023, at 13:42, Ingo Klöcker  wrote:
> 
> GitLab keeps the verification state if a
> key is removed, but I added the updated key including the expired subkey. That
> was a bad idea because GitLab invalidated all commits signed with the expired
> subkey.

It is disappointing to see that major projects still have trouble implementing 
signature verification correctly. The rules are not trivial, but they are 
important to accurately convey the intent of the signer.

Is there an implementers guide anywhere for how to calculate sig validity? 
There are plenty for users but none for developers that I can see. The details 
are distributed across various parts of the RFCs (expiry, revocation, etc.), so 
perhaps a wiki page to consolidate them (and other relevant arcane knowledge) 
would be helpful, so that we could point implementers at it and tap the sign.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Reminder: use plaintext mails only on ML

[Andrew Gallagher via Gnupg-users]

On 06/01/2023 13:42, Bernhard Reiter wrote:

Friends of GnuPG,
a happy new year to all of you!


Happy New Year!


Now I am taking Andrew (hi) as an example


Oh dear...!


to send a reminder
why using text/plain format only mails is a good idea
on this (and other mailing lists).

Am Samstag 17 Dezember 2022 19:54:39 schrieb Andrew Gallagher via Gnupg-users:

I’ve been


Argh, that will teach me not to reply to list emails from my phone. 
Sorry, everyone. :-(


A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Expiration date of subkeys (retroactive)

[Andrew Gallagher via Gnupg-users]

On 1 Jan 2023, at 03:49, gnupg-us...@aschoettler.com wrote:
> 
> I have several GnuPG keys which I edited with KGpg.
> https://apps.kde.org/de/kgpg/
> 
> Unfortunately, the subkeys were not taken into account when setting the 
> expiry date.
> How can I retroactively edit my expired keys and expire the subkeys?

If your primary key is already expired, there’s not much advantage to be gained 
by explicitly expiring the subkeys. It’s conceptually tidier, but a subkey of 
an expired primary key is just as (in)valid either way. The expiry date of a 
subkey is meant to expire the subkey earlier that its primary; the inverse case 
(subkey expiring later than its primary) is meaningless - once the primary is 
expired the entire key should be considered expired, subkeys and all. The only 
exception might be if you are interacting with client software that doesn’t 
calculate validity correctly, and needs the extra hint.

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Card-Reader

[Andrew Gallagher via Gnupg-users]

I’ve been using this ACS reader for years with no problems. It appears to be no longer available but there is a successor model that may suit your purposes ACR38T-D1cardomatic.deAndrew GallagherOn 17 Dec 2022, at 18:36, Klaus Ethgen  wrote:Hi,I destroyed my card reader from gemalto and need a new one. (The card,luckily survived.)Is there any way to order them anymore? I found many ways to download areader but no shop where to buy them. Preferred in Switzerland.They should be able to read SIM card size GnuPG-Cards and been optimalrobust tu carry them in the pocket.Gruß   Klaus-- Klaus Ethgen   http://www.ethgen.ch/pub  4096R/4E20AF1C 2011-05-16    Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C___Gnupg-users mailing listGnupg-users@gnupg.orghttps://lists.gnupg.org/mailman/listinfo/gnupg-users___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Mastodon account, good server?

[Andrew Gallagher via Gnupg-users]

On 1 Dec 2022, at 16:42, Bernhard Reiter  wrote:
> 
> Hi friends of GnuPG,
> 
> seems to be a good time to start an official Mastodon account
> for GnuPG and related topics like Gpg4win and OpenPGP.
> 
> At least for announcements and some interaction as the interest
> is growing for this decentral platform.
> 
> Is there an interest here?  Should be do this?

I would say so, yes.

> If we do this, a server needs to be select.
> I'd probably go and suggest one my initial rough requirements:
> * located in Europe
> * can be volunteeringly paid for
> * some volume / track record to expect a good administration
> * a moderation and contents policy that allows for respectful
>   exchange, but is liberal in that commercial Free Software
>   topics (and broad other topics) are allowed as well.
> * (optional) Free Software and privacy friendly organisation
> 
> Any suggestions matching these?


infosec.exchange is hosted in the EU (via Hetzner) and has a focus on security, 
encryption etc. without being prescriptive. I haven’t seen any abuse on it 
personally, and they have fediblocked a significant list of known hate sites. 
It’s run by Jerry Bell, who’s pretty respectable (CISO of IBMCloud), and a 
significant fraction of the security/encryption people I follow(ed) on Twitter 
use it. You can support it financially via liberapay.com

(other security/foss themed mastodon sites are available. YMMV etc etc)

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: macos IKEv2 auth with yubikey

[Andrew Gallagher via Gnupg-users]

On 28/11/2022 06:29, Martin Brook via Gnupg-users wrote:
2. I've achieved IKEv2 vpn auth with yubikey on windows. It seems 
windows can interact with Yubikey perfectly but not on macos.


Hi, Martin.

How did you get this to work on Windows? Which IKE software are you 
using on each platform?


A


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Question about redundant smartcard setup

[Andrew Gallagher via Gnupg-users]

On 19 Aug 2022, at 17:17, kho  wrote:
> 
> Thanks for this fast, complete and clear answer.
> 
> I am going to see if I can still pick up somewhere or just remove all I
> did and start all over by following your steps.

Just a note of caution: since it is quite an involved process I would recommend 
keeping it as simple as possible at first, and trying it out with a test key 
before doing it in production. So long as you have a (tested!) offline backup 
you should be safe.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Question about redundant smartcard setup

[Andrew Gallagher via Gnupg-users]

On 19 Aug 2022, at 13:48, kho via Gnupg-users  wrote:
> 
> 5. What is at the end the best way to setup 2 smartcards that can be
> used in encryption, signing and decryption? And additionally both
> smartscard should work, I have 2 smartcards for redundancy.

If you want the two smartcards to be redundant copies of each other, then they 
MUST contain exactly the same key material. It is possible to generate multiple 
signing/authentication subkeys that will be treated the same for practical 
purposes, since most software will try each valid sig/auth-capable (sub)key in 
turn during verification. There is no equivalent ability for encryption 
subkeys, as clients will encrypt to only the most recent valid encryption 
subkey. If you lose/break the smartcard with the only copy of an encryption 
subkey then there is no way to recover.

You can save the same key material to multiple smartcards using the gnupg 
command line interface:

1. Run gnupg and follow the usual process for generating (sub)keys, but “save” 
to save and exit before transferring subkeys to the smartcard. This ensures 
that you have a copy on disk before continuing.

2. Run gnupg again and copy the subkey(s) to the card, but afterwards you 
should say “quit” to exit *without* saving (not “save”). That way the subkeys 
will not be deleted from disk and you can use them again.

3. Repeat step 2 for the second (third, fourth,…) smartcard. Only choose “save” 
to save-and-exit after copying to the last smartcard, however be aware that 
“last” in this context really means “last”. No take-backs.

If you have to generate a new subkey for whatever reason (say you had to revoke 
the previous one) you must follow a similar save/quit sequence, remembering the 
order “run, generate, save, run, copy, quit, run, copy, quit, … run, copy, save"

To keep open the possibility of provisioning extra cards in the future, you 
could back up your entire .gnupg directory to a secure offline storage medium 
(such as an encrypted thumb drive) after generating the keys but before 
transferring to smartcard(s). Or you could perform the whole process of 
generating and managing your keys using a secure live system such as Tails with 
an encrypted persistent partition (remembering to “quit” after copying even the 
last time so that there is always a copy on disk). If you do either of these 
you only need one smartcard, so long as you don’t mind waiting for a 
replacement smartcard to arrive in the post if your original breaks.

On any given machine, gnupg will only ask for one smartcard. You should 
therefore consider one smartcard your working copy and one your emergency 
backup (if you have multiple machines, you could assign different primary cards 
to each machine). To force gnupg to ask for the other smartcard, you can delete 
the stub `.key` files under ~/.gnupg/private-keys-v1.d (on Linux/Mac, I forget 
the Windows equivalent). To work out which files to delete, incant `gpg -K 
--with-keygrip` and note the “Keygrip” lines under the three subkeys. Delete 
the corresponding `.key` files only, then plug in the replacement smartcard and 
incant `killall gpg-agent; gpg --card-status` (again Linux/Mac only). gnupg 
should now recognise the replacement card as the primary, and will ask 
consistently for that one until you repeat the process.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: OT: Re: Does the PGP public key at https://www.washingtonpost.com/anonymous-news-tips/

[Andrew Gallagher via Gnupg-users]

> On 7 Aug 2022, at 19:31, john doe via Gnupg-users  
> wrote:
> 
> Why did you published the key to the sks key servers?
> 
> I guess my question is about the reasoning behind using sks key server
> instead of WKD or Hagrid.

WKD publication can only be done by (or with the cooperation of) the domain 
owner. Publication to keys.openpgp.org should ideally be done by the key owner 
because they will have to reply to a verification email in order for it to be 
searchable by email address. If I submitted it there without their knowledge it 
would only be searchable by fingerprint, which is suboptimal. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Does the PGP public key at https://www.washingtonpost.com/anonymous-news-tips/

[Andrew Gallagher via Gnupg-users]

> On 7 Aug 2022, at 17:28, Jay Sulzberger via Gnupg-users 
>  wrote:
> 
> Andrew, do the sks keyservers work today?
> 
> I was able to find the key by going to
> 
> https://keyserver.ubuntu.com/
> 
> and putting
> 
> EC6C2905F0F93C0373946CA10642427A5FF780BE
> 
> into the search box.

Do you mean SKS the software (i.e. github.com/sks-keyserver) or SKS the 
protocol/network? The answer in both cases is “yes”, but for different values 
of “yes”. 邏

What doesn’t work any more is the sks-keyservers.net pool, which had become a 
nightmare to manage. This has been taken by many to mean that the SKS network 
itself is down, but this is absolutely not the case.

sks-keyserver still works, but is IMO not suitable for use in production unless 
you are an expert willing to roll your own load balancing pool and recompile 
the code to update blacklists (there are still a few such brave souls left). 
This may change in the future — the software is maintained but hasn’t had a 
significant feature bump in some time.

The SKS network also still works, and depending on your choice of metric is 
probably more stable today than it has ever been. The reasons are twofold: many 
operators have migrated from sks-keyserver to hockeypuck, and most of the rest 
have shut down. This means that although there are fewer keyservers now than 
five years ago, the ones that do exist (including keyserver.ubuntu.com) are 
generally much more reliable.

Information about the SKS network can be found at https://spider.pgpkeys.eu

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Does the PGP public key at https://www.washingtonpost.com/anonymous-news-tips/

[Andrew Gallagher via Gnupg-users]

On 06/08/2022 13:49, Jay Sulzberger via Gnupg-users wrote:

I think the Washington Post has not placed their recent key on the PGP
public keyservers.  Below is quoted from a different machine:

   Welcome to the Emacs shell

   ~ $ gpg --recv-keys 'EC6C2905F0F93C0373946CA10642427A5FF780BE'
   gpg: keyserver receive failed: No data
   ~ $


As this key's availability is in the public interest, and does not 
contain any personal information, I have taken the liberty of submitting 
it to the SKS network.


A


OpenPGP_0xFB73E21AF1163937_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Does the PGP public key at https://www.washingtonpost.com/anonymous-news-tips/

[Andrew Gallagher via Gnupg-users]

On 06/08/2022 13:49, Jay Sulzberger via Gnupg-users wrote:

I think the Washington Post has not placed their recent key on the PGP
public keyservers.  Below is quoted from a different machine:

   Welcome to the Emacs shell

   ~ $ gpg --recv-keys 'EC6C2905F0F93C0373946CA10642427A5FF780BE'
   gpg: keyserver receive failed: No data
   ~ $


As this key's availability is in the public interest, and does not 
contain any personal information, I have taken the liberty of submitting 
it to the SKS network.


A


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPG 2.2.36 released

[Andrew Gallagher via Gnupg-users]

> On 7 Jul 2022, at 04:47, Ralph Seichter via Gnupg-users 
>  wrote:
> 
> 1.) Starting today, disk images (*.dmg) are signed with a new ed25519
> key (EAB0FE4FF793D9E7028EC8E2FD56297D9833FF7F). This key has been
> uploaded to pgp.mit.edu today, but the site is once again very sluggish
> and it might take a while to sync the key to other pool members. For
> this reason, I'll include the public key here:

As of 2130Z today this key still had not reached pgpkeys.eu, so I have just 
uploaded it there by hand; most other syncing servers should have it within the 
hour. I can see it is also available on keys.openpgp.org. 

Sadly, I would recommend against the use of pgp.mit.edu, as it is one of the 
most consistently unreliable keyservers. The graphs at 
https://spider.pgpkeys.eu/graphs now show a crude “N nines” reliability 
estimate for each available keyserver - this is based on an hourly poll and is 
only capable of resolving up to three nines, but it should give you a rough 
guide to which keyservers have a track record of responsiveness. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg auto-locate-key selects expired/revoked key

[Andrew Gallagher via Gnupg-users]

On 09/06/2022 12:20, Jan Eden wrote:
> I had configured hkp://keys.gnupg.net in gpg.conf (no separate
> dirmngr.conf). Switching to keys.openpgp.org had the desired effect:

keys.gnupg.net has not existed for a few years now, but for backwards
compatibility gnupg silently maps it to the hardcoded default server. So
setting keys.gnupg.net in your config effectively does nothing...

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg auto-locate-key selects expired/revoked key

[Andrew Gallagher via Gnupg-users]

On 09/06/2022 11:50, Jan Eden wrote:
> jan ~ % gpg --refresh-key 0xFB73E21AF1163937
> gpg: refreshing 1 key from hkp://pgp.surf.nl
> gpg: key FB73E21AF1163937: "Andrew Gallagher " not 
> changed
> gpg: Total number processed: 1
> gpg:  unchanged: 1

You're using the pgp.surf.nl keyserver, but it has been broken for some
time (it's currently lagging by about 360 thousand keys). pgp.surf.nl
was configured by default in some previous releases of gnupg but has
since been replaced.

You should edit dirmngr.conf and change your default keyserver to e.g.
keys.openpgp.org or keyserver.ubuntu.com (other keyservers are
available, see https://spider.pgpkeys.eu).

Example:

```
% more ~/.gnupg/dirmngr.conf
keyserver hkps://pgpkeys.eu
```

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg auto-locate-key selects expired/revoked key

[Andrew Gallagher via Gnupg-users]

On 09/06/2022 07:11, Jan Eden wrote:
> PS. The key used to sign your message seems to be expired.

That could be because you already had my key in your keyring and it
wasn't recently (i.e. in the last 18 months) refreshed. What does it say
if you incant the following?

```
gpg --refresh-key 0xFB73E21AF1163937
```

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg auto-locate-key selects expired/revoked key

[Andrew Gallagher via Gnupg-users]

On 8 Jun 2022, at 07:46, Jan Eden via Gnupg-users  wrote:
> 
> - Which WKD server hosts my expired/revoked key such that it takes precedence
>  over my own WKD server at domain.com ?
> - Why does gpg select an expired/revoked key over a valid key?

I suspect the issue is that your WKD is serving both keys (as you can see from 
the output of the metacode checker) but GnuPG expects just one key to be 
served, and so is consuming the first (which is the expired one) and ignoring 
the second. Try replacing the file on the WKD server with one that contains 
just the current key?

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: TB weirdness

[Andrew Gallagher via Gnupg-users]

On 24/02/2022 16:59, Robert J. Hansen via Gnupg-users wrote:

Sounds like a defect to me, do you have a problem report ticket with
Thunderbird or a forum entry which described the problem in more detail
(like which version is affected).


It turns out the actual behavior is a little different than I originally 
described.  If you have a valid certificate with a given email address, 
and a revoked certificate (or certificates) with that same email 
address, it will silently add the revoked certificates, as well as the 
valid one, to your email.  This is still a bad idea.


I can confirm this happened to me when I specifically ticked "Attach my 
public key" in TB's composer - it also attached the revocation cert for 
an ancient key that I still have in my keyring but never used for anything.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions re auto-key-locate

[Andrew Gallagher via Gnupg-users]

On 15/02/2022 23:37, Dan Mahoney wrote:

That's a decision I leave up to the people who *make*  the key (and the 
software that it's signing).


Sorry, from your previous message it sounded like you were publishing 
your own software.



(and it's no longer the case that you can publish just anyone's key)


This is not true, you can still publish any key you want. In the 
specific case that you publish to keys.openpgp.org it will not be 
searchable by userid until the key owner verifies it, but your use case 
only requires lookup by fingerprint, so that doesn't arise.



Right now, the decision is that our key (signed with our prior-year key) is on 
our website and FTP (also via https) site, and we do not assert that it's 
available on the keyservers.


OK, but again I'm curious about the reasoning...

--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: How to solve this garbled code?

[Andrew Gallagher via Gnupg-users]

On 15/02/2022 11:32, Gao Xiaohui via Gnupg-users wrote:
Hello, why do such garbled characters appear on the display page of 
gnupg(inside the red box),The Chinese characters will be displayed 
abnormally too, similar to this garbled character. what should I do and 
how to avoid it?

Thank you very much.


I suspect this is because you're using a non-Unicode codepage in the 
windows command terminal. What happens if you type:


chcp 65001

and try again?

--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions re auto-key-locate

[Andrew Gallagher via Gnupg-users]


> On 15 Feb 2022, at 21:46, Dan Mahoney (Gushi) via Gnupg-users 
>  wrote:
> 
> Since the debacle a few years ago with the SKS keyserver denial-of-service 
> attack, the keyservers are kind of a non-starter.

Why so? Keyservers are still around, and the ones that survived the apocalypse 
are generally the ones that are better maintained. The only glitch from a user 
POV is that you have to publish to both a synchronising server and 
keys.openpgp.org to make sure everyone sees your updates…

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: lost id on keyserver

[Andrew Gallagher via Gnupg-users]

On 10/02/2022 13:23, Raja Saha wrote:


I created the subkey, output it to a file and imported it to gpg on
working dir. Then I sent the key to the keyserver, gpg --send-keys
*. After that when I searched the keyserver by my email it, there
was no key. When I searched by my key
F01D54EDAEB1700EBEDE6FC6C0A9DE3BFEFD07E2 (now revoked) it was there.
When I imported it, it didn't have a mail id.


What OS are you using? The default keyserver depends on your linux 
distro, and the default in Debian-based distros (keys.openpgp.org) 
doesn't serve userIDs by default. If you published your key there and 
then imported it into a different keyring, it wouldn't have come with 
the userID unless you went through their email verification procedure first.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: "Are You Now or Have You Ever Been..."

[Andrew Gallagher via Gnupg-users]

On 31/01/2022 22:29, jonkomer wrote:

Confirming it, possibly many years after it has been dissolved.
Future is the key-word here.

In that context, then-current response of a key-server query on
"" could be much more deleterious to John
than the evidence given to the tribunal by Jane Doe that she
exchanged e-mails with john@example.org way back in 2022.


If this is your concern, then email probably isn't the appropriate tool 
for your use case. The mere existence of a particular email address is 
not a secret; by design email does not (cannot!) protect envelope 
information.


If the members of example.com need to keep their membership secret, then 
at the very minimum example.com should give them random usernames. But 
you should also consider whether a plausible-deniability system like OTR 
is a better fit for your opsec, and even then plausible deniability is 
only really useful against adversaries who believe in due process...


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preventing public key upload to key-servers

[Andrew Gallagher via Gnupg-users]

> On 31 Jan 2022, at 21:39, jonkomer  wrote:
> 
> There is significant difference between a one-time
> "third-party" correspondent misusing his knowledge of
> the relationship after it has been dissolved, from
> that same knowledge being published in perpetuity via
> a simple, automated Internet query.

Are you worried about people discovering this relationship, or confirming a 
suspected relationship?

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: First Amendment and Marines?

[Andrew Gallagher via Gnupg-users]

I go away for the weekend, and my mailbox catches fire... ;-)

On 29/01/2022 16:38, jonkomer via Gnupg-users wrote:
> (a) Unfortunately, OpenPG email encryption is incompatible
> with GDPR and should not be used by those that either want
> or need to be GDPR compliant.

This is not so; the use of email encryption *improves* GDPR compliance.

> (b) GDPR appears to be a topic that, for some strange reason,
> elicits emotional reactions by the OpenPG creators and
> maintainers.

GDPR elicits interesting reactions in general! ;-)

> (c) GPG and OpenPG appear to be very much US-centric
> endevours. That fact ought to be taken into account by the
> new users.

On the contrary, Europe is (in my experience) over-represented in the
OpenPGP development community, and there has been extensive discussion
of its implications for PGP both in this group and elsewhere.

> If the ultimate goal of OpenPG is the wider adaption of
> encrypted e-mail, finding technical means to make it usable
> by those that *wish to be GDPR compliant* - without forcing
> such MO on everyone - appears to be a worthwhile effort.

Agreed in general, however I'm not sure what you mean by "forcing such
MO on everyone".

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preventing public key upload to key-servers

[Andrew Gallagher via Gnupg-users]

On 28/01/2022 20:02, jonkomer via Gnupg-users wrote:
>> A. G. via :
>> The short answer is "no", or at best "not yet"...
> 
> Thank you very much for the response and comprehensive
> comments.
> 
> In this case, the mail domain owner is actually the one
> that needs this level of control: he insists on the ability
> to positively respond to individual e-mail users' GDPR
> "forget me" requests.
...
> Domain owner intends to operate a "members only" public key
> dissemination and fingerprint verification mechanism. When
> the user is removed from the "membership", (either by the
> domain owner action or by his or her own request), the mail
> address (and any/all other personal data) is  deleted and
> promptly removed from the publicly exposed Internet domain
> presence.

This sounds like a perfect use case for WKD. It is under the full
control of the domain owner (the data controller), and RTBF does not
arise. Publication of the key is necessary to provide the service, and
the data controller deletes personal data immediately on cessation of
that service.
> After the user removal the domain owner is ipso facto
> GDPR compliant. However, he would prefer that a naive user
> (rightly or not) does not consider him unresponsive, and both
> sides

Both sides?

> have some interest in preventing any Internet server
> from keeping an active and publicly exposed user's name
> and (now defunct) e-mail-address, thus indiscriminately
> advertising forever the fact that John Doe was at some point
> in time a member of Example.org.

This is not an OpenPGP-specific concern - anyone with John Doe's name
and email in their address book can potentially "leak" the fact that JD
was once associated with example.com, even if he never creates a public
key. These are presumably the same people that he is corresponding with
using OpenPGP.

GDPR actively helps you here, by ensuring that if you are corresponding
with a company that does business in the EU, they must have internal
processes to minimise such leaks.

Otherwise, you are at the mercy of your correspondents, GDPR or not.
What is to stop them posting JD's contact details on Twitter, for
example? Or synchronising their address books with a badly-run cloud
service?

> How do individual key-server owner/operators react to
> formal GDPR "forget me" requests; either by e-mail users, or
> by mail domain owners? Any known legal precedents?

The mail domain owner cannot make an RTBF request on behalf of a user;
GDPR applies to personal data, and the domain owner is not the data owner.

Hockeypuck server operators can add the fingerprint of the offending key
to their block list. SKS operators have to recompile, but in theory can
also comply.

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preventing public key upload to key-servers

[Andrew Gallagher via Gnupg-users]

On 29/01/2022 01:55, Johan Wevers via Gnupg-users wrote:
> There are known technical issues: the HKP keyserver does not allow keys
> to be removed, GDPR or not. When the keyserer operator operates outside
> of the EU I don't think that is a legal problem.

This is incorrect. All three of the commonly-used HKP servers can remove
keys; this has been done for years to remove poison (i.e. oversized)
keys that cause DoS. However doing so comes with costs.

SKS does not properly support removing keys, however it is often patched
to include a list of known poison keys that should be ignored. This
obviously does not scale. Other keyservers (Hockeypuck and Hagrid) have
proper support for removing keys.

The longer-term cost is that keyserver sync (in SKS and Hockeypuck)
degrades as the list of blocked keys grows. Hockeypuck caches sync
failures and so (in theory) degrades more gracefully than SKS, which
does not.

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preventing public key upload to key-servers

[Andrew Gallagher via Gnupg-users]

On 29/01/2022 03:51, Shawn K. Quinn via Gnupg-users wrote:
> If the server is physically in the US, administered by someone residing
> in the US, is the EU really expecting US courts to enforce EU
> laws/directives like the GDPR on a US citizen?

The short answer is no, of course not.

The practical consequence of the GDPR's "universality" is that if you
want to do business in the EU, you have to comply across your worldwide
operations. For mom and pop stores, this will therefore never be an
issue. But for multinational companies (Google, Facebook, etc.), this
has real teeth. In particular, it means that they can't hide behind "yes
we broke your rules but we laundered it through another jurisdiction so
you can't touch us".

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: First Amendment and Marines?

[Andrew Gallagher via Gnupg-users]

On 30/01/2022 10:12, Klaus Ethgen wrote:
> 
> When it comes to keyservers, with the same argument you could state that
> bitcoin is illegal. (No information in the key chain can be removed. And
> there is even child porn inside that key chain that could never ever
> again be removed!)
> 
> There are more technologies out there where informations, once in, could
> never removed again.

Yes, and this is both morally and legally terrifying. The fact that
nobody has yet been taken to court over this particular issue merely
makes the legality of it "untested".

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Preventing public key upload to key-servers

[Andrew Gallagher via Gnupg-users]

On 26/01/2022 22:03, jonkomer via Gnupg-users wrote:
> Is there anything that a public key owner can do, to actually
> *ensure* that, if some careless or malicious correspondent
> ignores the comment ("Please do not upload...") and attempts
> to upload his or her (otherwise fully functional) public key
> to the key-server(s), the key upload is rejected?

The short answer is "no", or at best "not yet".

There is a "keyserver preferences/no-modify" flag defined in rfc4880:

```
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.

```

But this is technically fraught. Most keyservers just ignore this flag,
while keys.openpgp.org effectively assumes that it is always set, but
even then doesn't behave exactly as the spec implies.

keys.openpgp.org will not publish the userID of a key until the key's
purported owner performs an email-based verification, and won't serve
third-party sigs at all. It will however serve the non-userID components
(by fingerprint search) no matter who uploaded it.

Synchronising keyservers don't perform the verification step, due to
conceptual incompatibilities between the (universal) sync model and
(subjective) verification, and so the full key material will be made
available regardless of who uploads them.

There was a proposal in the old rfc4880bis draft that the "no-modify"
flag should specifically prevent distribution of non-attested
third-party sigs, but this would still not affect distribution of the
userIDs and self-sigs, and has not been replicated in the new
crypto-refresh draft. It is also quite likely that once sig attestations
become commonplace, keyservers will stop distributing non-attested
third-party sigs regardless of whether a key owner sets this flag.

Note also that a domain administrator can publish the key of any email
address in the domain via WKD, and this is effectively equivalent to
publishing it on a keyserver.

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPG - signed Telefax communication

[Andrew Gallagher via Gnupg-users]

On 14/01/2022 18:22, Стефан Васильев wrote:
>> Good question. My thought was that Telefax is still used, among
> lawyers, doctors, business folks etc., and brand-new Fax machines
> can be bought on Amazon etc. 

+1 for obsolescence! Beware of course that fax machines are VERY noisy,
and analogue lines are increasingly routed over VOIP, so if you're using
this as some kind of off-grid technique you're not going to get very far.

> Yes, do you know of any QR-code software (open source) which could
> do that task automatically, i.e. split a large (encoded) message into
> several  QR-codes and reassemble later?

I don't know about QR codes, but splitting a single file into multiple
parts of a given size and reassembling them again can be done with the
venerable unix utilities `split` and `cat`.

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPG - signed Telefax communication

[Andrew Gallagher via Gnupg-users]

On 14/01/2022 17:54, Стефан Васильев wrote:
> 
> The idea is to use a Telefax machine for endpoint security, with
> an offline usage PC, which for example gpg4win is ideal for.

Would it not be simpler to use a modem?

> I thought about that too, but in case the document would be several
> pages long and would not fit into a QR-code. Ok, one can split the
> large document and insert then several QR-codes into one Fax page.

The largest standard QR code can hold just under 3kB of data in a single
image. If you need more than that you would probably have to split
across multiple sheets no matter what encoding system you choose.

A



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPG - signed Telefax communication

[Andrew Gallagher via Gnupg-users]

On Fri, 2022-01-14 at 16:42 +, Стефан Васильев via Gnupg-users
wrote:
> The --begin etc. markers should be used to detect where
> the OCR scanned document begins and ends to have later
> a good signature.

If you are relying on OCR to reconstitute a bitwise-perfect message
(because that's the only way a signature will validate) then you're
asking for trouble, unless you're using a very restricted character set
with at most one whitespace codepoint.

> the receiver then OCR scans the document and decodes the QR-code

If QR is an option, why not encode the entire message in QR?

A


signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Gnupg-users Digest, Vol 220, Issue 11

[Andrew Gallagher via Gnupg-users]

> On 10 Jan 2022, at 20:33, Chris Taylor  
> wrote:
> 
> Hello,
> 
> Please unsubscribe me from this list.

Please follow the instructions that you quoted in the email you just sent:

>> To subscribe or unsubscribe via the World Wide Web, visit
>>http://lists.gnupg.org/mailman/listinfo/gnupg-users
>> or, via email, send a message with subject or body 'help' to
>>gnupg-users-requ...@gnupg.org

A


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: one ecc key-pair for both encryption and signature?

[Andrew Gallagher via Gnupg-users]

On 07/01/2022 16:55, Bernhard Reiter wrote:

> Then RSA should be limited in the same way.
(Because there it is possible, so I guess that there is another reason.)


I agree, although IIRC such usage is supported for backwards 
compatibility reasons.



| The curve is birationally equivalent to a twisted Edwards curve
| used in the Ed25519 signature scheme.

There is anequivalence given (two functions) in the Ed25519 wikipedia page,
but I don't know if this allows the same curve used in both algorithms.


"Birationally equivalent" means that there is a 1:1 mapping between the 
points of each curve that preserves their mathematical structure. This 
means that you could in principle convert a key from one curve to the 
other, but it would be a more complex function than just copying the raw 
bit string.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: one ecc key-pair for both encryption and signature?

[Andrew Gallagher via Gnupg-users]

On 07/01/2022 14:06, Bernhard Reiter wrote:

With 2.2.33 is is not possible to create a single ecc key-pair
that can do "sign" and "encrypt".


There are circumstances (legal, contractual, operational) where you may 
need to disclose or share an encryption key, so it is best practice to 
keep the encryption-capable subkey distinct. And if you present people 
with the option to do a suboptimal thing, a significant fraction of them 
will choose that option by accident - so usually best not to offer it in 
the first place.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Gpg4win LetsEncrypt issue

[Andrew Gallagher via Gnupg-users]

> On 4 Jan 2022, at 12:15, Alex Nadtoka  wrote:
> 
> yes thanks, tried disabling it but error was still there. So I deleted  DST 
> Root CA X3 . At the mooment I see error from dirmngr 2.3.4: no CA certificate 
> found 
> And 
>  error searching keyserver: "No inquire callback in IPC"
> 
> Not sure if it is still because of root certificate. Will try to google now

You probably don’t have the new root certificate installed then. You should be 
able to download it from letsencrypt.org

A___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Gpg4win LetsEncrypt issue

[Andrew Gallagher via Gnupg-users]

On Fri, 2021-12-31 at 23:23 +0200, Alex Nadtoka wrote:
> Ok, thanks. Where on the client end i can remove it?

This blog appears to do it correctly (to the best of my knowledge) and
as its worked example uses the very same CA certificate that we have
just been discussing:  

https://www.thesslstore.com/blog/how-to-remove-certificates-from-windows-10/

A


signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Announce] A New Future for GnuPG

[Andrew Gallagher via Gnupg-users]

On Mon, 2022-01-03 at 11:31 -0500, Robert J. Hansen via Gnupg-users
wrote:
> Werner, this is amazing news.  Thank you for sharing it!

Indeed, many congratulations!

> I did spend about six months doing a clean-room implementation of 
> RFC2440 in PHP3.  It was a vile experience and one I don't recommend.

I am simultaneously shocked, impressed, and disgusted. ;-)

A



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Gpg4win LetsEncrypt issue

[Andrew Gallagher via Gnupg-users]

> On 30 Dec 2021, at 16:27, Alex Nadtoka  wrote:
> 
> Even if I remove root certificate from the server it will be added again on 
> renewal.

It is the client that needs the ca certificate to be removed, not the server. 
The root cause is that there is more than one verification path possible and 
unpatched openssl versions pick the wrong (expired) option. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Gpg4win LetsEncrypt issue

[Andrew Gallagher via Gnupg-users]

> On 29 Dec 2021, at 21:12, Alex Nadtoka  wrote:
> 
> We have our internal GPG server( I want people in company to be able to 
> connect to it from windows as well... 

OK, so you definitely need to solve the root certificate issue. 

Do sites using letsencrypt work from an Edge browser on that machine, or is it 
just dirmngr?

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Gpg4win LetsEncrypt issue

[Andrew Gallagher via Gnupg-users]

> On 29 Dec 2021, at 20:15, Alex Nadtoka  wrote:
> 
> yes it works with  keyserver-01.2ndquadrant.com 

Is this server sufficient for your purposes or do you also need to support an 
internal keyserver?

A

> ср, 29 груд. 2021 р. о 17:06 Andrew Gallagher via Gnupg-users 
>  пише:
>> On Wed, 2021-12-29 at 14:33 +0200, Alex Nadtoka via Gnupg-users wrote:
>> > I cannot connect to any keyserver. The error is certificate expired.
>> > I am on latest (I think) Windows 10 . Tried reinstalling it or
>> > installing on new Windows machine but no luck . dirmngr keeps telling
>> > me that certificate is expired. 
>> 
>> Have you tried configuring an hkps keyserver that does not use
>> LetsEncrypt, e.g. keyserver-01.2ndquadrant.com ?
>> 
>> A
>> ___
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Gpg4win LetsEncrypt issue

[Andrew Gallagher via Gnupg-users]

On Wed, 2021-12-29 at 14:33 +0200, Alex Nadtoka via Gnupg-users wrote:
> I cannot connect to any keyserver. The error is certificate expired.
> I am on latest (I think) Windows 10 . Tried reinstalling it or
> installing on new Windows machine but no luck . dirmngr keeps telling
> me that certificate is expired. 

Have you tried configuring an hkps keyserver that does not use
LetsEncrypt, e.g. keyserver-01.2ndquadrant.com ?

A


signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: issue with gpg4win

[Andrew Gallagher via Gnupg-users]

> On 25 Dec 2021, at 11:24, Alex Nadtoka  wrote:
> 
> 
> Hi Andrew, yes I have changed the real name of my mailbox and the server) 
> Thanks for the reply. 
> My Client Machine is Windows . If you can tell me how to do that I would 
> appreciate it. Thanks again for the update) 
> Finally got some help. 

I haven’t had to do this myself on windows, so I’m not an expert; if you have 
windows update enabled it should get fixed automatically. If for whatever 
reason you aren’t getting updates you could try something like this:

https://www.stephenwagner.com/2021/09/30/sophos-dst-root-ca-x3-expiration-problems-fix/

> Sorry for all these troubles and Merry Christmas 

Merry Christmas!

A___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: issue with gpg4win

[Andrew Gallagher via Gnupg-users]

> 2021-12-23 11:27:30 gpg[12864] DBG: connection to the dirmngr established
> 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x025c -> GETINFO version
> 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x025c <- D 2.3.4
> 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x025c <- OK
> 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x025c -> KEYSERVER --clear 
> hkps://gpg.example.com/
> 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x025c <- OK
> 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x025c -> KS_SEARCH -- 
> oleksa...@example.com
> 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x025c <- ERR 167772261 
> Certificate expired 
> 2021-12-23 11:27:30 gpg[12864] error searching keyserver: Certificate expired
> 2021-12-23 11:27:30 gpg[12864] keyserver search failed: Certificate expired
> 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x025c -> BYE

OK, so I can see from the image that you’re not actually using example.com, 
fair enough :-) I do notice that your chosen keyserver is using a 
recently-issued letsencrypt certificate. There is a known issue with 
Letsencrypt certificates due to the replacement of their upstream CA and a 
known bug in openssl. Are you able to upgrade openssl and the ca-certificates 
bundle on your client machine?

A___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: issue with gpg4win

[Andrew Gallagher via Gnupg-users]

On Thu, 2021-12-23 at 12:37 +0200, Alex Nadtoka via Gnupg-users wrote:
> 2021-12-23 11:27:30 gpg[12864] DBG: chan_0x025c -> KEYSERVER --
> clear hkps://gpg.example.com/

This doesn't look like a real keyserver. Did you redact this, or is
this really what is currently configured in dirmngr.conf?

If you currently have "pool.sks-keyservers.net" configured in
dirmngr.conf, please note that it has been deprecated for some time.
Try a known working keyserver such as keyserver.ubuntu.com or
pgpkeys.eu instead, and see if it works better.

A


signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: fingerprint associated public key does not match displayed public key

[Andrew Gallagher via Gnupg-users]

> On 18 Dec 2021, at 02:25, Robert J. Hansen via Gnupg-users 
>  wrote:
> 
> As the FAQ says, "The good news is the internet is a treasure trove of 
> information. The bad news is that the internet is a festering sewer of 
> misinformation, conspiracy theories, and half-informed speculations all 
> masquerading as informed commentary."

Indeed. The internet is also full of articles that haven’t been updated since 
before the iPhone was invented, and thus are *at best* so technologically 
outdated they might as well be written in hieroglyphics…

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why are 64-bit libraries not included in GnuPG but Gpg4win?

[Andrew Gallagher via Gnupg-users]

> On 4 Dec 2021, at 04:14, Sven Richter via Gnupg-users  
> wrote:
> 
> Thunderbird expects to be able to manage all public keys regardless. Even 
> with this setup of mine, it only pulls the private keys from GnuPG.

You may be interested in the Sequoia Octopus, which is a drop in replacement 
for Thunderbird’s RNP library and enables public keyring sync between TB and 
GnuPG:

https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp#building-installing

A___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: User id's without person's name, only email

[Andrew Gallagher via Gnupg-users]

On 17/11/2021 18:15, Robert J. Hansen wrote:

Mapping a "Real Name" to an email address is a conceptually different
thing from mapping an email address to a public key.


Except that should we be mapping keys to email addresses in the first 
place?

>
When we sign a certificate we make an assertion that this cryptographic 
material is controlled by this entity.  I control the cryptographic 
material associated with certificate 0x1DCBDC01B44427C7. 
r...@sixdemonbag.org controls nothing -- it's just one of several places 
I pick up mail.


A cryptographic signature does not attest that anything belongs to you, 
the meatspace person - it merely attests a relationship between some 
cryptographic material and a particular identifier. The interpretation 
of the identifier is context-dependent and highly subjective.


If I want to send an email to you, I have to identify you to my MUA. If 
I want to encrypt it, I have to ask the MUA to associate the identifier 
I just gave it with a key. I either select your name from an address 
book (in which case the unique ID is your email address) or I type in 
your email address by hand. It doesn't matter how many other identifiers 
(emails, post boxes, passport numbers) you have - from my POV, and that 
of my MUA, they are irrelevant because they don't let me identify you 
any more precisely than I already can with just one.


The cryptographic binding is always between key material and a 
machine-readable identifier. This identifier may or may not be globally 
unique, but it should be unique in the context of the system within 
which it is used (e.g. my MUA). The mapping of contextual identifiers 
onto meatspace is a philosophical question that is beyond the reasoning 
capability of a computer, and the ability of natural persons to assume 
and discard identifiers is a feature, not a bug.


I have long considered mapping keys to email addresses to be a 
fundamental flaw.  It obscures exactly what it is we're trying to 
assert: that cryptographic material is controlled by *people*.
Some cryptographic material is created, used and destroyed without any 
human interaction whatsoever, e.g. TLS session keys. The session key is 
signed by the server key to state "this session key is controlled by me" 
(i.e. the server). The server may be controlled by an organisation, and 
the organisation by people (or the people by the organisation, depending 
on your point of view!).


The point being that there are many layers of abstraction between the 
cryptographic material and a natural person. Software can only make and 
test claims about some of those layers at best, and some of those layers 
may not even be meaningful to the end user, depending on the context.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: User id's without person's name, only email

[Andrew Gallagher via Gnupg-users]

On 17/11/2021 14:40, Teemu Likonen wrote:

  2. Second "address book" is my OpenPGP keyring. It groups persons'
 names, their email and other key data. If many keys don't have name
 in their user id it could be inconvenience. Computer programs can
 find keys but often we need also manual "gpg -k" etc. Real names
 help there.


It may sound like a nerdy quibble, but it's a fundamental weakness. 
Mapping a "Real Name" to an email address is a conceptually different 
thing from mapping an email address to a public key. Conflating the two 
introduces confusion about what exactly is being verified by the 
cryptographic toolchain. If an MUA's address book is not sufficiently 
user-friendly, then that's a user interface shortcoming that can't be 
fixed by introducing RFC-822 "Real Names", which were highly 
questionable long before email encryption was invented...


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: User id's without person's name, only email

[Andrew Gallagher via Gnupg-users]

On Tue, 2021-11-16 at 18:20 +0200, Teemu Likonen wrote:
> Am I seeing a starting trend here? Do some people think that it is
> better practice to have only have email address as user id? What
> might be their reason? Or maybe it's not a trend and doesn't mean
> anything. I got curious anyway. Add your speculation. :-)

When selecting a key for either encryption or verification purposes,
only the email address part is meaningful. "John Smith
" and "John David Smith (work email)
" are functionally equivalent. The "Real Name" and
"Comment" portions of the userID are mere conventions and, if you have
an address book, entirely redundant.

It is reasonable therefore to take the view that the non-email portion
of a userID is cruft at best (and an unnecessary leakage of personal
information at worst).

A


signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: OpenPGP card and gpg-agent TTL

[Andrew Gallagher via Gnupg-users]

On 04/11/2021 08:40, Matthias Apitz wrote:

I bought the OpenPGP card from
Purism for USD 15, I don't know if the small format exist here in
Germany.


Not Germany, but Cryptoshop in Vienna sells them:

https://en.cryptoshop.com/products/smartcards/open-pgp-smartcard-v2-id-000.html

--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD, wildcard DNS resolution (Re: Error when trying to locate key via WKD)

[Andrew Gallagher via Gnupg-users]

On 28/10/2021 12:25, Bernhard Reiter wrote:

Am Donnerstag 28 Oktober 2021 12:07:52 schrieb Andrew Gallagher via
Gnupg-users:

The megathread from hell starts here :-)
https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064567.html


That is not gnupg-_devel_ (where I was searching). :)


To be fair to Ingo, he did say "here OR on gnupg-devel" :-)


Interesting to me is:
https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064584.html
Ingo explaning that it is considered a security drawback if a domain
for the advanced method is there but does not allow a connection
with a valid TLS certificate.

The understanding of the current draft therefore is
   If the subdomain for the advanced method resolves via DNS,
   the direct method MUST NOT be used.


As Werner pointed out on the other thread, the mail provider can disable 
the advanced method by creating a TXT record for openpgpkey.mail.de - 
the existence of the TXT record will prevent the wildcard from matching 
the advanced method's A lookup, and gnupg should fail back to the old 
method.


The ball belongs in mail.de's court IMO, however the confusion is 
understandable.



On the other hand, if I trust my email domain webserver, the DNS provider can
create the advanced method DNS entry and attack me. However this DNS provider
could also just change the entry to my email domain webserver.


Indeed, if you don't trust your DNS provider, you have worse problems... ;-)

--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Error when trying to locate key via WKD

[Andrew Gallagher via Gnupg-users]

On 28/10/2021 10:44, Bernhard Reiter wrote:

Am Mittwoch 27 Oktober 2021 22:54:48 schrieb Ingo Klöcker:

The problem with wildcard sub-domains and WKD has been discussed here or on
gnupg-devel recently.


Ingo,
can you provide me a pointer to the gnupg-devel thread?
(Did a few minutes of searching, I probably missed something.)



The megathread from hell starts here :-)

https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064567.html

But the most concise summary is probably this:

https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064575.html

--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD docs on the wiki, restructuring. Feedback on forUsers page

[Andrew Gallagher via Gnupg-users]

On 30/09/2021 13:17, ಚಿರಾಗ್ ನಟರಾಜ್ via Gnupg-users wrote:

Hmm, this is odd. I setup WKD as detailed on 
thehttps://wiki.gnupg.org/WKDHosting  (using the openpgpkey subdomain), 
currently only for one address on my domain (s...@chiraag.me). Opening the file 
directly in a web browser does work, so the file is at the correct path with 
the correct (I presume) permissions. However, running the test given here 
does_not_  work and fails with the debugging output I've attached.


What URL are you expecting it to be found at? Did you hash the full 
email address or just the bit before the @?


A


OpenPGP_0xFB73E21AF1163937.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Andrew Gallagher via Gnupg-users]

On 29/07/2021 17:52, Rainer Fiebig wrote:


~> openssl x509 -text 

So the file exists, and appears to have the correct contents (the 
difference in checksum is probably whitespace or commentary, I wouldn't 
worry about it).


I'm going to refer back to my earlier statement: "It looks like dirmngr 
isn't using the same set of CAs that curl is using".


If you built gnupg from its default configuration, it does not 
automatically look in /etc/ssl/certs for CA certificates. You may want 
to add a soft link from /etc/gnupg/trusted-certs to /etc/ssl/certs so 
that dirmngr looks in the Mozilla certificate library.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Andrew Gallagher via Gnupg-users]

On 29/07/2021 17:33, Rainer Fiebig wrote:

Thanks. File exists but has a different checksum:

/etc/ssl/certs> sha256sum DST_Root_CA_X3.pem
4b3ecda4db3f417f23f5dfa84eb4d59d6cc2959446ebaf89c7df5866d31e9980
DST_Root_CA_X3.pem


Ah, I wonder is the expiry date different. Can you incant the following 
please?


```
openssl x509 -text 

OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Andrew Gallagher via Gnupg-users]

On 29/07/2021 08:41, Rainer Fiebig via Gnupg-users wrote:

Am 28.07.21 um 21:38 schrieb Ingo Klöcker:
On Mittwoch, 28. Juli 2021 18:38:07 CEST Rainer Fiebig via Gnupg-users 

wrote:
>>

Does 'gpg --keyserver hkps://pgpkeys.eu --search-keys ...' work for you?


No, same output as reported initially.


The common problem is the LetsEncrypt R3 certificate.


* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=keys.openpgp.org
*  start date: Jul 26 04:32:08 2021 GMT
*  expire date: Oct 24 04:32:06 2021 GMT
*  subjectAltName: host "keys.openpgp.org" matched cert's "keys.openpgp.org"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.

...

Looks OK to me. The Let's Encrypt certificate is recognized and
verified. Or what do you think?


I think it looks like dirmngr isn't using the same set of CAs that curl 
is using.


The missing root certificate is:

2021-07-28 16:06:50 dirmngr[4135.6] issuer certificate: #/CN=DST Root 

CA

X3,O=Digital Signature Trust Co.
Can you confirm that /etc/ssl/certs/DST_Root_CA_X3.pem exists on your 
machine and has the following checksum?


```
andrewg@whippet:~$ sha256sum /etc/ssl/certs/DST_Root_CA_X3.pem
139a5e4a4e0fa505378c72c5f700934ce8333f4e6b1b508886c4b0eb14f4be99 
/etc/ssl/certs/DST_Root_CA_X3.pem

```

Also, is your system clock correct? (long shot, but always worth asking 
when debugging TLS cert issues)


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --search-keys: "gpg: error searching keyserver: No inquire callback in IPC"

[Andrew Gallagher via Gnupg-users]

On 28/07/2021 15:19, Rainer Fiebig via Gnupg-users wrote:

2021-07-28 16:06:50 dirmngr[4135.6] Fehler beim Verbinden mit
'https://keys.openpgp.org:443': Fehlendes Herausgeberzertifikat in der Kette
2021-07-28 16:06:50 dirmngr[4135.6] command 'KS_SEARCH' failed:
Fehlendes Herausgeberzertifikat in der Kette
2021-07-28 16:06:50 dirmngr[4135.6] Handhabungsroutine für den fd 6 beendet


"Fehlendes Herausgeberzertifikat in der Kette" translates as "Missing 
publisher certificate in the chain", is that correct?


keys.openpgp.org uses LetsEncrypt as their TLS CA. Can you connect to 
other keyservers that also use LetsEncrypt? For example, pgpkeys.eu uses 
the same intermediate certificate (LetsEncrypt R3) as keys.openpgp.org.


What OS are you using? Do you have the latest version of ca-certificates 
(or equivalent) installed?


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Multiple Yubikeys/Smartcards and Thunderbird email client

[Andrew Gallagher via Gnupg-users]

> On 15 Jul 2021, at 12:54, john doe via Gnupg-users  
> wrote:
> 
> Is this still relevent with the built-in gpg stuff of TB?

Very much so. Thunderbird’s native Open PGP support is quite basic, and 
anything to do with smartcards still has to be delegated to an external gnupg 
process. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Call me crazy, but ...

[Andrew Gallagher via Gnupg-users]

> On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 
>  wrote:
> 
> It would tell me as 3rd party that for WoT puposes, if this is still used,
> Alice and her good friend Bob were able to sign their pub keys remotely,
> based on a free of charge verification method.

That’s what ordinary third-party sigs do. Adding medical data to a public key 
does not add anything to the process.

You should also beware that medical information is treated as sensitive 
personal data under GDPR, and this subject to stricter rules. Keyserver 
operators already have enough legal issues handling ordinary personal data 
(email addresses etc) without adding vaccination certificates to the dataset.

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Call me crazy, but ...

[Andrew Gallagher via Gnupg-users]

> On 14 Jul 2021, at 19:49, Стефан Васильев  wrote:
> 
> Andrew Gallagher wrote:
>>>> On 14 Jul 2021, at 18:34, Стефан Васильев via Gnupg-users 
>>>>  wrote:
>>> Viktor wrote:
>>>> It's the same as putting any other public information in public key
>>>> certificate. You can put first and last name, email address and even
>>>> photo of another person.
>>> But this information can be digitally verified and is issued EU wide by
>>> Governemnt trusted sources in this field.
>> But this puts logical causality the wrong way around. Just because the
>> thing *being signed* is genuine, does not prove that the thing *doing
>> the signing* is genuine.
>> IMO this proposal is abuse of the public key infrastructure. If you
>> want to sign an ID document, just sign an ID document and distribute
>> it through other channels. Attaching it as a signed packet to a key
>> adds zero value, at nonzero cost.
> 
> What abuse do you see here, if I may ask? I see it as an non-public option
> among virtual GnuPG friends to include in a duplicate certified data, which
> is not meant to been distributed on keyservers etc. or made public to
> the world and acts for two pub keys comparison.

As currently configured, there is nothing to stop this sort of information 
being uploaded to a keyserver. So while keyserver operators cannot yet forbid 
it, we should certainly not encourage it. And in any case, we should always ask 
what value is being added by a particular proposal, weighed against what 
(potential) costs are being incurred. Remembering that costs are not always 
borne by those enjoying the benefits. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Call me crazy, but ...

[Andrew Gallagher via Gnupg-users]

> On 14 Jul 2021, at 18:34, Стефан Васильев via Gnupg-users 
>  wrote:
> 
> Viktor wrote:
> 
>> It's the same as putting any other public information in public key
>> certificate. You can put first and last name, email address and even
>> photo of another person.
> 
> But this information can be digitally verified and is issued EU wide by
> Governemnt trusted sources in this field.

But this puts logical causality the wrong way around. Just because the thing 
*being signed* is genuine, does not prove that the thing *doing the signing* is 
genuine.

IMO this proposal is abuse of the public key infrastructure. If you want to 
sign an ID document, just sign an ID document and distribute it through other 
channels. Attaching it as a signed packet to a key adds zero value, at nonzero 
cost. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: recommendation for key servers

[Andrew Gallagher via Gnupg-users]

On 06/07/2021 20:59, Daniel Kahn Gillmor wrote:

On Mon 2021-06-28 18:42:02 +0100, Andrew Gallagher via Gnupg-users wrote:

It’s not clear, but it may be due to a lack of canonical ordering of
packets.


There are no published specifications for how to canonically order
OpenPGP packets, but i sketched a proposal here:

 https://dev.gnupg.org/T3389

Adoption of such a canonical ordering would reduce the amount of
computation for synchronizing keyservers, once they all adopted the same
one.


That's an interesting idea, and it has merit in itself, but from a 
keyserver point of view I think a more general solution is to explode 
TPKs into atomic components, sync them separately, and reconstruct the 
TPK on demand at query time. This addresses not just reordering of 
packets, but also differential filtering, simultaneous updates, etc.


See https://github.com/hockeypuck/hockeypuck/issues/137

--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: recommendation for key servers

[Andrew Gallagher via Gnupg-users]

> On 28 Jun 2021, at 18:02, Стефан Васильев via Gnupg-users 
>  wrote:
> 
> When looking at the stats, why are there IMHO such high numbers
> (daily) on updated pub keys, compared to submitted ones?

It’s not clear, but it may be due to a lack of canonical ordering of packets. 
Say Alice and Bob have both signed my key, but keyserver A and keyserver B have 
different copies of my key with Alice and Bob’s signatures in opposite order 
from each other. These keys will have different checksums, even though they 
contain the same functional information. If the sync process doesn’t result in 
A and B reordering the sigs in the same way, then they will keep syncing 
(successfully!) forever, incrementing the number of changes each time. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Content Protection

[Andrew Gallagher via Gnupg-users]

> On 26 Jun 2021, at 08:26, LisToFacTor via Gnupg-users  
> wrote:
> 
> Once a message reaches
> the recipient's operational environment, it should be decrypted,
> and its further protection is best addressed as part and parcel
> of the protection of that complete environment.

But this is not the way many people use email now. It is quite common to use 
multiple “operational environments” to access a common user mailbox, and that 
mailbox may not be under the user’s sole control. Any security model must take 
into account how people lready behave in practice… otherwise they will use 
insecure workarounds. 

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net

[Andrew Gallagher via Gnupg-users]

On 24/06/2021 22:39, Brandon Anderson via Gnupg-users wrote:



$ host pool.sks-keyservers.net <http://pool.sks-keyservers.net>

Host pool.sks-keyservers.net <http://pool.sks-keyservers.net> not 
found: 3(NXDOMAIN)


Did these names get permanently deleted? Any workarounds or 
suggestions would be appreciated.


Hey Alex,

From what I can tell a lot of the keyservers are being shutdown. Take a 


look at the message on the SKS site (the SSL cert is expired) 
https://sks-keyservers.net/.


The keyserver *pools* at sks-keyservers.net are no longer maintained for 
legal reasons. sks-keyservers.net was receiving GDPR requests, e.g. for 
RTBF, that it could not satisfy because the pools had no formal 
structure that could compel individual operators to comply with legal 
requests. While sks-keyservers.net did not host personal data, it was 
providing a DNS round-robin service for keyservers that did, and the 
distinction was poorly understood.


Most of the individual keyservers that used to be in the pools are still 
working, however. There is a service at https://sks-status.gwolf.org/ 
that monitors the known keyservers. Scroll to the bottom and click on 
the latest "Success" link to see a graph of keyservers that are 
currently responsive.


What to do next depends on your use case. If your CI is searching for a 
key that is under your own control, then you have more freedom of 
choice. If it is searching for someone else's key then you may need to 
use whatever keyserver they use.


keys.openpgp.org is the default keyserver for most new installs, and 
many long-time users have also switched to it. If you don't have a 
particular reason to choose one, this is probably the safest bet. The 
main caveat is that it does not serve third-party sigs, and so you won't 
be able to verify a downloaded key by its signatures.


keyserver.ubuntu.com is reliable, but is not widely used outside the 
Ubuntu developer community. It doesn't get key updates particularly 
often, so you may find yourself with a stale copy of your 
correspondent's key.


If you need continuity of dataset with the sks-keyservers pool, then you 
may prefer to use a Hockeypuck server that was formerly part of the 
pool, such as pgpkeys.eu, keyserver.trifence.ch or keys.andreas-puls.de 
(other keyservers are available, see https://sks-status.gwolf.org/). 
Note that Hockeypuck is generally more reliable than SKS due to 
limitations in SKS's design.


Due to the fragmented nature of the keyserver ecosystem at the moment, 
you may want to try all of the above. And as mentioned in an earlier 
reply, you should probably also search WKD.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Long Term Key Management With Hardware Tokens

[Andrew Gallagher via Gnupg-users]

On 22/06/2021 17:53, Brandon Anderson via Gnupg-users wrote:
Many tutorials, examples, and articles that are talking about using 
Yubikeys and smartcards currently suggest making paper backups of the 
encryption key so you can add it to new devices if needed. But this, at 


least to me, feels like it's significantly reducing the value of using 
secure hardware like smartcards in the first place. Having the keys only 
ever exist on secure hardware, including the backups, would make this 
unnecessary.


The disadvantage of only ever storing secret key material on a finite 
number of secure hardware devices is that all such devices have a 
lifetime, and once they're all dead your information is gone. You'll 
still find yourself re-encrypting all your data to a new encryption 
(sub)key when you get down to your last working hardware device.


Having a non-secure offline backup does not negate all the advantages of 
secure hardware. It depends on the threat model of course, but *most* 
people are much more likely to have their laptop compromised remotely 
than have their safe cracked and the paper backup stolen.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users