Re: GnuPG and SSH_AUTH_SOCK value

[Werner Koch via Gnupg-users]

On Fri, 21 Jun 2019 11:20, g...@unixarea.de said:

> What I do not understand is, why this value without the KDE5 environment
> is
>
> $ gpgconf --list-dirs agent-ssh-socket
> /home/guru/.gnupg-ccid/S.gpg-agent.ssh

That is because you have a
GNUPGHOME=/home/guru/.gnupg-ccid
and  /var/run/users/1001  does not exist.

> and after start of Xorg and KDE5 it is:
>
> $ gpgconf --list-dirs agent-ssh-socket
> /var/run/user/1001/gnupg/d.m4rfaasqebhjmgto9ddm6m7y/S.gpg-agent.ssh

/var/run/users/1001 has been created (systemd mess?) and thus GnuPG
expects ist sockets below /var/run/user/.  The token is the hash of
the homedir's name so that we don't get a too long path.

 $ echo -n /home/guru/.gnupg-ccid | sha1sum | cut -d ' ' -f1 | undump |zb32
 m4rfaasqebhjmgto9ddm6m7yfhgj8yc8

undump does the obvious and zb32 is like base64 but encodes using 
Zooko's Base32 encoding.


Shalom-Salam,

   Werner


ps:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=wk-misc.git;a=blob;f=zb32.c
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=wk-misc.git;a=blob;f=undump.c

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: New keyserver at keys.openpgp.org - what's your take?

[Werner Koch via Gnupg-users]

On Fri, 21 Jun 2019 12:03, gnupg-users@gnupg.org said:

> here is a article (only in german) from Heise:

By the very same guy who showed in the past that he has no clue about
keyservers and their goals and ignored all comments gathered about this
before writing an article [1].

That new thing now is the n-th repetition of the same game: Replacing
PGP by a centralized approach, or well many centralized approaches, in
an attempt to repeat the story of S/MIME.  PGP has its strengths in the
idea of not having the one-and-only-distributor-of-all-keys and thus a
SPoFailure/Denial/Surveillance.  If we want that it is easier to go with
S/MIME.

An in-house keyserver is sometimes a good idea but a global validating
keyserver is a failed idea.  Being under the AGPL may also be
problematic because the code can't be used for in-house deployments and
the AGPL often smells a little bit like a trigger for an Open Core
business model.


Salam-Shalom,

   Werner


[1] https://werner.eifzilla.de/20150224-re-die-schlssel-falle.html

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: GPG/YubiKey/CentOS7

[Werner Koch via Gnupg-users]

On Fri, 21 Jun 2019 18:42, gnupg-users@gnupg.org said:

> Even though I have had GPG and YubiKey running a few times on CentOS7

Which GnuPG version does it come with: "gpg --version".  Does it install
gpg under the name gpg2 and provides the legacy GnuPG 1.4 under the name
gpg ?

> [p42547@cswks20~] > ssh-add -l
> error fetching identities for protocol 1: agent refused operation
> 2048 SHA256:dj02A/DHL0RKuJuMLBX14CaQ6RriT0uqY0sXqTNPoW4
> cardno:000609042340 (RSA)

To see what the problem is you neeed to add these lines to
~/.gnupg/gpg-agent.conf

--8<---cut here---start->8---
log-file /tmp/p42547-agent.log
verbose
debug ipc
--8<---cut here---end--->8---

restart gpg-agent and run ssh-add-l again.

> [p42547@cswks20~] > gpg --export-secret-keys $KEYID | openpgp2ssh $KEYID
> We cannot handle encrypted secret keys.  Skipping!

I don't know this openpgp2ssh thingie.  To export an OpenPGP key as an
openpgp _public_ key in ssh format use

  gpg -a --export-ssh-key FINGERPRINT

You may need to append a '!' to the fingerprint to export a specific
subkey.

> gpg --export-secret-keys C5778901 gives me an asci file that then

You need to add the option -a to get in in ASCII format.

> complains about not being openpgp it also is missing the cardno in the

The cardno is has no important information; it is merely there so that
the agent can prompt you to insert the expected card.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: GnuPG and SSH_AUTH_SOCK value

[Werner Koch via Gnupg-users]

On Fri, 21 Jun 2019 16:39, g...@unixarea.de said:

> Thanks for the explanation. But why GNUPGHOME is not also used for the
> place where the sockets should be created when X11/KDE is up?

That seems to be deep in the innards of KDE's X startup or Wayland or
Systemd configuration.  I try to avoid all this and use the old
fashioned but easy to debug ~/.xsession


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: New keyserver at keys.openpgp.org - what's your take?

[Werner Koch via Gnupg-users]

On Tue, 25 Jun 2019 17:54, gnupg-users@gnupg.org said:

>> Theres simply one point: "If you do not want your email to be public, don't
>> upload your key to a server."
>
> What if I upload your key to a server though? Keep in mind this is not just
> a "nice to have", it is a legal requirement.

For whom, the holder of the mail address, the uploader, or the
responsible person for thge keyserver?

Please cite the section from the GDPR and the, say, German
implementation along with relevant commentary to show why this is a
legal requirement.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: New keyserver at keys.openpgp.org - what's your take?

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 14:55, andr...@andrewg.com said:

> Yes, which is why we've informally had "let the owner choose whether to
> publish her incoming certifications" as best practice for a long time.

Actually gpg has always set the /Key Server Preferences/ to 

   First octet: 0x80 = No-modify
   the key holder requests that this key only be modified or updated
   by the key holder or an administrator of the key server.

assuming that at some point in the near future we would come up with a
scheme to actually allow to implement such a verification.  The problem
here is that PGP-5 and thus OpenPGP continued to use the PGP-2 model and
didn't defined key-signature as, for example, embedded signatures or
something similar.  We had no other chance here because the WoT was
heavily used for real and for ranking games.

Given that all public keyservers (there used to be others) didn't
verified any signatures it was not possible to implement an upload
scheme which guaranteed that key-signatures had been confirmed by the
key holder.  It has already been mentioned that this would have gone
against the design of the keyserver network to be a perpetual storage
system.  I recall that we discussed all these issues at the keyserver
admins conference in Utrecht back in 2000 and planned to do something
about it.  However, PGP Inc. was soon sold and interest in doing
something with the decentralized keyservers network diminished.  The new
SKS thing then made keyservers working for OpenPGP (the original HKP was
severely limited in accepting OpenPGP keys) but we all knew that if we
ever get really successful with OpenPGP the keyserver would not be able
to solve the key distribution task.  In fact we are here too similar to
X.509 and their CRL and OCSP problems.

> Cross-signing would enforce this, but the client-side tooling is lacking.

Cross-signing is not an easy solution because it can create a catch-22:
You can only import a key which has been cross-signed but for
cross-signing it needs to be imported.

An approval of a key signature by a self-signature would be the right
way - but a straightforward scheme would break the existing WoT and,
worse for some, the ranking.

The other and more important question is whether the WoT and thus
classical key signatures solve a real world problem for the _masses_.  I
doubt that and I can live without public (exportable) key-signatures.
Local key signatures are still a good idea as an annotation of imported
keys.


Salam-Shalom,

   Werner



p.s.
As stop-gap solution the next gpg release sports a
--keyserver-options self-sigs-only to allow importing of spammed keys.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: distributing pubkeys: autocrypt, hagrid, WKD (Re: Your Thoughts)

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 15:13, gnupg-users@gnupg.org said:

> distribution keys in Gentoo.  However, the main problem with WKD right
> now is that AFAIK GnuPG doesn't support refreshing existing keys via WKD

Actually gpg updates expired keys via WKD.  However, to not break things
and not to go out and do a query on the mail domain, this is only done
if the key has originally been fetched via WKD.

That turned out to be a too conservative approach and thus I consider to
change this so that gpg always tries to update an expired key via the
WKD.

Regarding a manual refresh there is indeed only a clumsy set of options
and commands but if we can agree to stop using --search-keys with
keyservers, this command can be used as a forceful update via WKD.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: distributing pubkeys: autocrypt, hagrid, WKD

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 10:27, konstan...@linuxfoundation.org said:

> - subkey changes

An expired key triggers a reload of the key via WKD or DANE.  Modulo the
problems I mentioned in the former mail.  For new subkeys we have a
problem unless we do a regular refresh similar to what should be done
for revocations.

> - UID additions/revocations

A new UID will automatically be fetched, so this is not a problem.  For
revocations the same as above is true.

> - expiration date extensions

What do you mean by this?  gpg --quick-set-expire and how this relates
to the Web Key Directory?




Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Your Thoughts

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 22:58, h...@alyssa.is said:

> For example, why isn't ask-cert-level a default? I'm guessing it's just
> because at some point it didn't exist, and the developers didn't want to

Because we have good defaults and options to chnage them in the config.
We do not want to expose all options to standard users and annoy them
with useless questions.  Some lobbied for such an interactive option
anyway and thus we added it 1.3.6:

* New --ask-cert-level/--no-ask-cert-level option to turn on and
  off the prompt for signature level when signing a key.  Defaults
  to off.

The interactive prompts are designed in a way that new prompts can be
added without breaking anything.  We have introduced new prompts a lot
without much fear about compatibility problems.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Your Thoughts

[Werner Koch via Gnupg-users]

On Mon,  1 Jul 2019 23:47, r...@sixdemonbag.org said:

> for development.  My donation capped at $500.  For several of those
> years, I was one of the largest individual contributors to GnuPG.

Right, your donation encouraged me to keep on working on this set of
tool which is used at many more places than people expect.  Thank you
and also all the other folks who continue to help financing us.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 10:23, gnupg-users@gnupg.org said:

> Why not make "import-clean" and "import-minimal" strip key signatures
> before importing a key? That would make "import-minimal" behave like

Because that contradicts what import-clean is supposed to do:

  After import, compact (remove all signatures except the
  self-signature) any user IDs from the new key that are not usable.
  Then, remove any signatures from the new key _that are not usable_.
  This includes signatures that were issued by keys that are not present
  on the keyring.

To do this gpg needs to check whether the corresponding key exists and
the verify the signature using that key.  In contrast self-sigs-only
removes all signature which are not self-signature right away by just
comparing a 64 bit integer.

> My opinion: make "keyserver-options import-clean" the default and make
> it internally never import any unknown signatures.

Sorry, this is a catch-22.  We need the key to verify the signature.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: SKS Keyserver Network Under Attack

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 10:01, gnupg-users@gnupg.org said:

> No such issues on keys.openpgp.org, gpg --send-key and the new updated
> key is immediately available with no time outs or delays.

Unless you are on Windows where the server can't be accessed because it
uses a pretty limited set of TLS cipher suites.  Thus the majority of
GnuPG encryption users are out of luck.

On Windows we use the ntbtls library which has not yet support for the
GCM mode and we hesitate to add this to 2.2 because GCM has not been
approved for the use of GnuPG in restricted communication (VS-NfD).  It
is not a technical problem but a policy one which we first need to sort
out.  Even with the fear of padding oracles on CBC and old as well as a
forthcoming attack, the restriction of the server to use only GCM based
cipher modes is not helpful.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: SKS Keyserver Network Under Attack

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 13:47, look@my.amazin.horse said:

> Huh, that's interesting. I was not aware of this issue, and wish you had 
> reached
> out to me, or to supp...@keys.openpgp.org, or filed an issue on Hagrid.

I assumed that newly launched server software with the goal to take over
all existing keyservers has been properly tested on the major desktop
platform.

We track the case as https://dev.gnupg.org/T4597

> This BSI requirement was not known to me. While it would be preferable
> to stick

It is not a requirement but it is what has been evaluated.  Changing
anything crypto related requires discussion on whether this will affect
the approval.  It won't be a problem for GnuPG 2.3 because a lot of
things will change there anyway and a re-evaluation will be required.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Some thoughts on the future of OpenPGP and GnuPG

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 16:03, gnupg-users@gnupg.org said:

> With "big boys" I meaned the German Government, German BSI and Facebook.

I, or well my company g10 Code GmbH, has currently no contracts with the
German government or the BSI.  We had projects with the BSI but no
funding whatsoever.  These projects are the usual invitation for bid, a
bid by us (together with Intevation GmbH), and with luck the bid was
then accepted.  The last such project ended about 2 years ago.

Right now we are talking to companies and also institutions like the BSI
with the goal to sell support contracts (under the gnupg.com label);
that is a new effort Andre and me started this year.

Facebook and Stripe both donate 50k USD per year to support GnuPG
because they use it internally and with their customers and users.  They
are obviously interested to keep the software well maintained.

We also have recurring donations from individuals which are really
helpful and encouraging.  Thanks.

> I assume that 99.9 % of GnuPG /gpg4win users have not seen this before.

This is an old (2014) video showing the answer to a parliamentarian
question by MdB Christian Ströbele on why support for German crypto
[GnuPG] is such low.  The answer has some numbers on money spent via BSI
and BMWI for these purposes.  We tried to figure out how they get to
these numbers and it seems they lumped together different efforts over a
long period of time.

Anyway, it might have helped that new invitations for bids were sent out
by the BSI and Intevation and g10 Code where lucky enough to get
acceptance for our bids on 3 projects (Gpg4all, EasyGpg and Gpg4vs-nfd).
They worked quite well and for the first time we actually made some
profit form these projects.  See [1] for short article on g10 Code's
profits in 2016 and [2] for the balance sheet of 2017.

Unfortunately I have had not found the time to write about the year
2017, or even 2018, on how we are doing.  This lack of time of mine is
partly caused by the departure of 3 of our employers to move on to pEp
and hack on their projects over there.  Anyway, we are currently without
financial problems and are more troubled to find good developers who
have a professional working habit and, best, have some experience in our
field.


Shalom-Salam,

   Werner


[1] https://gnupg.org/blog/20170904-financial-results-2016.html
[2] https://gnupg.org/blog/data/g10code-bilanz-2017-pub.pdf

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Some thoughts on the future of OpenPGP and GnuPG

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 20:41, an...@pgp.16bits.net said:

> attachments that you need to extract, then open with a special program
> to decrypt.
> (In fact, many people _currently_ use OpenPGP in that stony age way)

From my experience many people use ZIP or PDF encryption here and not
OpenPGP.  But anyway we do not have any real numbers on that and thus we
can't tell for sure.  Agreed, copy and pasting armored gpg messages is
often a very useful thing in particular with chats and fora.

> But then, it needs to work in Microsoft Outlook. Or in Lotus.

We like to hear about problem you experience with Gpg4win and Outlook
with and without Exchange.  A few minor bugs are known but most users
tells us that it works pretty well, be it OpenPGP or S/MIME.  The user
interface of GpgOL (The outlook plugin from Gpg4win) for encryption is
even more advanced than Outlook's internal S/MIME encryption.

> The big deal are email clients. And there you would have all the issues
> that existing implementations have. Plus those they have fixed.

Right, and most faults you have seen in recent years are due to bad
integration of crypto in MUAs.  It used to be better when we started to
integrate encryption into MUAs about 20 years ago but meanwhile nifty
UIs and featurism seems to be more important than solid integration.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 11:00, d...@fifthhorseman.net said:

> It sounds like you are saying that the order of operations --
> import-then-clean vs. clean-then-import is part of the API spec that
> GnuPG is committed to.

No.  What I say is that if we want to clean the keys from bogus
signatures we need to get the key for each signature first.  Obviously
this requires that we do some checking on that key as a weel and this is
why I say it is a catch-22.

However, if you are only talking about self-signature, there is for sure
no problem: We already have the key (it is a self-signature) and thus we
can immediately check the signature.  Anyway, that takes some time, it
is a crypto operation - multiply that by 15.  OTOH, simply removing
non-self-signatures does not costs any measurable time because it is
just comparing two integers.

> But "clean-then-import" is clearly a preferable approach to any of the
> workarounds described so far.

--import-options import-clean does exactly this.  With the latest pacth
we fallback to this option and --self-sigs-only if gpg detects that the
keyblock is too larger afer some basic checks.

> certificate in the keyring.  "clean" means that the certificates already
> stored in the keyring are used to validate incoming signatures.  right?

import-clean does this:

   After import, compact (remove all signatures except the
   self-signature) any user IDs from the new key that are not usable.
   Then, remove any signatures from the new key that are not usable.
   This includes *signatures that were issued by keys that are not*
   *present on the keyring*. This option is the same as running the
   --edit-key command "clean" after import. Defaults to no.

This import-clean works on all signatures, not just self-signatures.
This is what takes time - finding the key in the keyring (slower since
2.1 due to DB correctness improvements).  In contrast import-minimal
does this

   Import the smallest key possible. This removes all signatures except
   the most recent self-signature on each user ID. This option is the
   same as running the --edit-key command "minimize" after import.
   Defaults to no.

But I am sure you know this.  What Am I misreading?


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 12:35, gnupg-users@gnupg.org said:

> problem but I have read RJH's article). It sounds like SKS servers can
> handle these poisoned keys but GPG can't. That suggests that maybe GPG's

I think here is a misunderstanding.  Sure, processing 150k signatures
takes quite some time and makes things very slow.  This is why we call
it a DoS.  We can't do much about it.  Compare it to X.509 CRLs - they
have a very similar problem (cacert.org is a prominent but not the only
example of CRLs making S/MIME processing very slow).

The actual problem in gpg when using the keybox format is that only
after processing the imported keys we hit a 5MiB limit for the keyblock
in the database layer.  Thus the import fails.  Determining the size of
the keyblock as it will be stored requires that we first remove some
(standard) garbage from the keyblock - this takes some time.  With the
currently deployed code gpg will just reject any updates from a key if
that limit was reached.  That is not a good choice and the reason why I
call it a bug.   The fix to this bug is to fallback importing a stripped
down version of the key.  The current state is that we keep only
self-signatures and then then import again with import-clean (which is
then basically identical to import-minimal).

> For example, if the problem is overuse of resources such as memory, could
> the keyring handling code be rewritten to use fewer resources? e.g. treat

Years ago we had the problem that people uploaded keys with large user
ids and such.  Thus we introduced limits to avoid spamming the keyring
with such faked data.  There is also an overall limit of 5 MiB for the
entire keyblock which is sufficient for all real-world keyblocks - even
for those with many key-signatures.

> signatures when importing a key, perhaps there could be a limit to how many
> signatures GPG will verify. Does it really have to verify every single one?

It needs to validate all self-signature because they make up the
integrity of the keyblock.  For key-signature, sure we could introduce a
limit, we actually do that with import-clean because that imports only
those key-signature which we can verify and which are the latest from the
same key (it is possible to sign a key several times to change meta data
associated with the key-signature).


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: distributing pubkeys: autocrypt, hagrid, WKD

[Werner Koch via Gnupg-users]

On Tue,  2 Jul 2019 15:40, konstan...@linuxfoundation.org said:

> When this happens, a maintainer who tries to verify a signed pull
> request will have the operation fail, so they need to have a way to
> force-refresh the developer's key. I would say this is the #1 workflow

Agreed.  A signature carries only the fingerprint of the then unknown
subkey without any information on the primary key.  Thus an automated
lookup is not possible.

But wait, if --sender has been used or due to other reasons the Signer's
UID is included in the keyring, we could do a lookup via tha user-id to
see whether the signature has been made by a new subkey.  The
--auto-key-retrieve code already respective code but we need to chnage
the order from where a key is fetched.

And yes, an easier to remember command to forcefully update a key would
be very useful.   I have

  gpg --serach-key MAILADDRESS

for that in mind.  See https://dev/gnupg.org/T4599


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: SKS and GnuPG related issues and possible workarounds

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 05:06, r...@sixdemonbag.org said:

> As I understand it the current list of targeted keys is myself, dkg,
> Werner, Patrick, and Kristian.  It is clear the attacker's goal is to

I am not yet affected except for these few thousand old xmas fun
signatures.

> Werner will no doubt be updating GpgOL as well.

I am sorting out some other bugs and hope to get a release out next
week.  I tend to make

  --keyserver-options self-sigs-only

the default to avoid importing possible crap from the keyservers.
no-self-sigs-only should allow to revert for those who still want to
receive updates from the anyway overloaded keyservers.  A command to
clean affected keys would also be useful but it might be better to get a
new release out early than to implement a feature which needs quite some
time taking testing. (https://dev/gnupg.org/T4591)

What we can also do is to remove the default keyserver feature we
introduced with 2.2.  This means that anyone who wants to use a
keyserver needs to pick one and not rely on defaults.

The other thing I have in mind to actually add to 2.2 is to re-purpose
--search-keys to update from WKD or DANE instead looking up at the
keyservers. (T4599)


> of OpenPGP is to verify package signatures; for the small fraction that
> use it for email, Enigmail is the most dominant choice, with GpgOL a

Frankly, I doubt that given the many users of Gpg4win compared to those
of Linux desktops.  But this is a different topic.

> The real damage is going to be to people's workflows.  A whole lot of
> people are going to be impacted by these fixes and we can expect to need

Actually not being able to fetch a key from the keyservers can improve
security or at least avoid problems sending mails encrypted to the wrong
key.  (see my comment above on --search-keys).


Shalom-Salam,

   Werner


p.s.
Why can't we have such problems at times when it is cold and rainy and
you can anyway only sit at your desk ;-).

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 10:38, tliko...@iki.fi said:

>> import-clean does this:
>>
>>After import, compact (remove all signatures except the
>>self-signature)
>
> ...here you and the manual say that "first import [to local keyring]
> then clean".
>
> So there are conflicting messages. Which of the two happens?

Right, the man page is a ambigious in use of the term "import".  It
should say that "after the key has been received by gpg, is is compacted
..., and if no error is encountred written to the keyring".

> I think everyone would prefer that import-clean would do all the
> checking and cleaning before importing certificates to the local
> keyring. The same thing with import-minimal.

It does this.  However for 150k signatures it even takes quite some time
to check whether the key does not exist locally so that the signature
won't be imported.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 12:29, pe...@digitalbrains.com said:

> Ah, based on a new message I just read the penny dropped. self-sigs-only
> can be made a default because it only applies to keyservers.
> import-minimal cannot be made a default because it affects all other

Not quite.  When importing from a keyserver you use --keyserver-options
and thus this allows to have a different set of options than when
importing using --import (and its corresponding --import-options
option).  --keyserver-options recognizes all import options in addition
to keyserver specific options.

The main advantage of self-sigs-only is that it is really fast.
Importing dkg's keys from a file takes 0.2s.  Importing without that
option takes 50 seconds.  The latter takes a long time until it runs
into the size limit which then triggers the fallback to self-sigs-only.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Local solutions: SKS Keyserver Network Under Attack

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 12:58, pe...@digitalbrains.com said:

> reached its intended goal: dirmngr said "re-reading config". It just
> didn't have an effect for some odd reason. For people thinking about

Check that you do not have a keyserver entry in your gpg.conf or
Enigmail is calling gpg with that options.  The keyserver specified by
gpg overrides whatever dirmngr has been configured to.

  debug ipc
  log-file /some/file

in dirmngr.conf should shows what is going on.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 13:50, pe...@digitalbrains.com said:

> Is there a good use-case for the former? If the latter also filtered out

Yes, as I wrote: 0.2s compared to 50s.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 15:42, pe...@digitalbrains.com said:

> --keyserver-options self-sigs-only,import-minimal
>
> as I propose, why would it take longer than 0.2 s?

Indeed, we could change the code for import-minimal so that it first
does the same what self-sigs-only does.  Then it should be very similar.

The reason why I added self-sigs-only is to allow ignoring
key-signatures completely.  Regardless of any other cleaning options.
Sometimes it is useful to not clean things so that one can see hcnages
to preferences and such.

And well, self-sigs-only is a less intrusive change than changing
import-minimal.  If it breaks something it can easily be reverted by the
user - a change to the semantics of import-minimal can't be reverted by
the user.

"self-sigs-only" also better expresses what it does.  If you have a
better name, let us know.

> then the self-sigs-only behaviour can be folded into import-minimal,
> avoiding creating yet another option in an already crowded option space.

Removing the keyserver support would even result in more cleanup of that
space ;-)


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keyserver-options: self-sigs-only, import-clean, import-minimal

[Werner Koch via Gnupg-users]

On Wed,  3 Jul 2019 17:08, stef...@sdaoden.eu said:

> I (still user of GPG1, it is only your newer key which this cannot

Just don't use it unless you need to decrypt very old mails.  In
particular not with keyservers or cards.  The next maintenance release
will anyway remove all keyserver and card code.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Release candidate for 2.2.17

[Werner Koch via Gnupg-users]

Hi!

Due to the SKS keyserver problems we are planning a new release for the
next week.  That release will have some changes related to keyserver.
See below for details.

In general we do not provide release candidates because experience
showed that they are more or less ignored.  However, this time I would
like to you to give that version some testing.  Get it from




and in case of problems please report to gnupg-devel.  Here are the
changes:

  * gpg: Ignore all key-signatures received from keyservers.  This
change is required to mitigate a DoS due to keys flooded with
faked key-signatures.  The old behaviour can be achieved by adding
  keyserver-options no-self-sigs-only,no-import-clean
to your gpg.conf.  [#4607]

  * gpg: If an imported keyblocks is too large to be stored in the
keybox (pubring.kbx) do not error out but fallback to an import
using the options "self-sigs-only,import-clean".  [#4591]

  * gpg: New command --locate-external-key which can be used to
refresh keys from the Web Key Directory or via other methods
configured with --auto-key-locate.

  * gpg: New import option "self-sigs-only".

  * gpg: In --auto-key-retrieve prefer WKD over keyservers.  [#4595]

  * dirmngr: Support the "openpgpkey" subdomain feature from
draft-koch-openpgp-webkey-service-07. [#4590].

  * dirmngr: Add an exception for the "openpgpkey" subdomain to the
CSRF protection.  [#4603]

  * dirmngr: Fix endless loop due to http errors 503 and 504.  [#4600]

  * dirmngr: Fix TLS bug during redirection of HKP requests.  [#4566]

  * gpgconf: Fix a race condition when killing components.  [#4577]

  Release-info: https://dev.gnupg.org/T4606



Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Testing WKD setup?

[Werner Koch via Gnupg-users]

On Mon,  8 Jul 2019 16:17, gnupg-users@gnupg.org said:

> false negatives.  It only supports the 'direct' method, where the key
> has to be hosted on `example.org` instead of `openpgpkey.example.org`.

BTW, the openpgpkey subdomain method was accidently not available in
2.2.  This will be fixed with the release of 2.2.17


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Third-Party Confirmation signature?

[Werner Koch via Gnupg-users]

On Mon,  8 Jul 2019 18:45, gnupg-users@gnupg.org said:

> Is there a way to create a "Third-Party Confirmation signature"[1]
> using the gnupg command line interface?

No.  You need to add code for this which also requires that you have a
way to specify another signature packet.

Are you considering to use 0x50 self-signatures to approve key
signatures?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

[Announce] GnuPG 2.2.17 released to mitigate attacks on keyservers

[Werner Koch via Gnupg-users]

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.2.17.  This is maintenance release to mitigate the effects of
the denial-of-service attacks on the keyserver network.  See below for a
list changes.


About GnuPG
===

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.2.17


  * gpg: Ignore all key-signatures received from keyservers.  This
change is required to mitigate a DoS due to keys flooded with
faked key-signatures.  The old behaviour can be achieved by adding
  keyserver-options no-self-sigs-only,no-import-clean
to your gpg.conf.  [#4607]

  * gpg: If an imported keyblocks is too large to be stored in the
keybox (pubring.kbx) do not error out but fallback to an import
using the options "self-sigs-only,import-clean".  [#4591]

  * gpg: New command --locate-external-key which can be used to
refresh keys from the Web Key Directory or via other methods
configured with --auto-key-locate.

  * gpg: New import option "self-sigs-only".

  * gpg: In --auto-key-retrieve prefer WKD over keyservers.  [#4595]

  * dirmngr: Support the "openpgpkey" subdomain feature from
draft-koch-openpgp-webkey-service-07. [#4590].

  * dirmngr: Add an exception for the "openpgpkey" subdomain to the
CSRF protection.  [#4603]

  * dirmngr: Fix endless loop due to http errors 503 and 504.  [#4600]

  * dirmngr: Fix TLS bug during redirection of HKP requests.  [#4566]

  * gpgconf: Fix a race condition when killing components.  [#4577]

  Release-info: https://dev.gnupg.org/T4606


Getting the Software


Please follow the instructions found at  or
read on:

GnuPG 2.2.17 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found at
.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.17.tar.bz2 (6560k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.17.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.17_20190709.exe (4185k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.17_20190709.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.

A new version of Gpg4win incluing this version of GnuPG will be released
in a few days.


Checking the Integrity
==

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.2.17.tar.bz2 you would use this command:

 gpg --verify gnupg-2.2.17.tar.bz2.sig gnupg-2.2.17.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.2.17.tar.bz2, you run the command like this:

 sha1sum gnupg-2.2.17.tar.bz2

   and check that the output matches the next line:

12c1cee8871c03f0315fc8f27876364b75c95b12  gnupg-2.2.17.tar.bz2
533deef5939fcd6506be650731dea4a9d18f9df8  gnupg-w32-2.2.17_20190709.tar.xz
82abfbc79d1a99b27f25ba92fe878cad07a31532  gnupg-w32-2.2.17_20190709.exe


Internationaliza

Re: Third-Party Confirmation signature?

[Werner Koch via Gnupg-users]

On Tue,  9 Jul 2019 10:10, gnupg-users@gnupg.org said:

> However, if gpg doesn't support a way of adding that subpacket, then
> creating easy-to-copy-and-paste commands for users to use to approve
> signatures becomes difficult.

The problem I see is that the keyservers need to check the validity of
the 0x50 signature first.  Only this will allow them to distribute only
key-signatures which have veen approved buy the key owner.

If that has been achieved we can quickly add the required feature to
gpg.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: WKD documentation (Re: Testing WKD setup?)

[Werner Koch via Gnupg-users]

On Tue,  9 Jul 2019 15:50, gnupg-users@gnupg.org said:

> setting it up and the feedback has been overwhelmingly positive. The
> only thing I needed was basically the local-part hash and actually
> that's what I built the checker for, to generate the URL in an easy

I think things are even easier now.  I have not checked whether this has
made it into the wiki.  From gpg-wks-client(1):

Since 2.2.12 we have:

   The command --install-key manually installs a key into a local
   directory (see option -C) reflecting the structure of a WKD.  The
   arguments are a file with the keyblock and the user-id to
   install.  If the first argument resembles a fingerprint the key
   is taken from the current keyring; to force the use of a file,
   prefix the first argument with "./".  If no arguments are given
   the parameters are read from stdin; the expected format are lines
   with the fingerprint and the mailbox separated by a space.  The
   command --remove-key removes a key from that directory, its only
   argument is a user-id.

The idea is that you can prepare a WKD on your local machine and upload
it by whatever you commonly use to for web pages.  And it works on
Windows.

Since we 2.2.15 we also have:

   The command --print-wkd-hash prints the WKD user-id identifiers
   and the corresponding mail-boxes from the user-ids given on the
   command line or via stdin (one user-id per line).

   The command --print-wkd-url prints the URLs used to fetch the key
   for the given user-ids from WKD.  The meanwhile preferred format
   with sub-domains is used here.

It is a bit unfortunate that under Unix we install that tool in
/usr/libexec or /usr/lib/.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: How to delete flooded key

[Werner Koch via Gnupg-users]

On Wed, 10 Jul 2019 10:23, patr...@enigmail.net said:

> Is it sufficient to run "gpg --delete-keys 0x...", and wait for quite a
> while, or does it require other measures?

--edit-key and then use "clean" to remove them.  And well, install
2.2.17 to avoid future trouble.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: WKD: mutt integration status

[Werner Koch via Gnupg-users]

On Wed, 10 Jul 2019 10:53, gnupg-users@gnupg.org said:

> If you convince Mutt community that WKD is a good idea I can prepare
> the patch for you. As far as I remember it's very minimal and I'd be

Actually I started to work on Mutt (not NeoMutt, though) but had to give
up due to time constraints.

> more places that would need attention. For example the code is riddled
> with PKA integration code and from what I can see PKA is considered

That could should not harm but can of course be removed.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: WKD: mutt integration status

[Werner Koch via Gnupg-users]

On Wed, 10 Jul 2019 11:59, andr...@andrewg.com said:

> In this instance, I wonder if the apostrophe hasn't screwed something up
> - are apostrophes valid in the MIME boundary charset?

I use that for ages and believe this is all valid.  But new Emacs
versions sometimes chnage the spooky list and thus it is possible that
the latest list proves me wrong.

--8<---cut here---start->8---
(defun spook-make-boundary (&optional count)
  (save-excursion
(set-buffer (generate-new-buffer " *spook tmp*"))
(setq buffer-disable-undo t)
(spook)
(subst-char-in-region (point-min) (point-max) ?\n ?= t)
(subst-char-in-region (point-min) (point-max) ?   ?_ t)
(subst-char-in-region (point-min) (point-max) ?[  ?. t)
(subst-char-in-region (point-min) (point-max) ?]  ?. t)
(subst-char-in-region (point-min) (point-max) ?$  ?. t)
(prog1
(buffer-substring (point-min) (min 70 (point-max)))
  (kill-buffer (current-buffer)
(setq mml-boundary-function 'spook-make-boundary)
(add-hook 'gnus-group-mode-hook 'gnus-topic-mode)
--8<---cut here---end--->8---



Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: WKD documentation (Re: Testing WKD setup?)

[Werner Koch via Gnupg-users]

On Tue,  9 Jul 2019 23:33, johan...@zarl-zierl.at said:

> Now that I have done it once, I think the setup without /usr/lib/gnupg/gpg-
> wks-client isn't that complicated either:

Please use gpg-wks-tool instead; it is much easier and less error prone.

> b. Manually, using gpg: gpg --homedir "$(mktemp -d)" --locate-keys $KEYID

With 2.2.17 use

  gpg --locate-external-key -v f...@example.org

Granted it imports the key but after all that is what you want.  That
new command does not check the local keyring so it can be used to
refresh from a WKD (or whatever has been configured in your AKL)

You may  use

  gpg-wks-client --with-colons --supported DOMAINS

to get the status of the Web Key Service for the requested domains.
See the man page for details.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: WKD documentation (Re: Testing WKD setup?)

[Werner Koch via Gnupg-users]

On Wed, 10 Jul 2019 21:47, johan...@zarl-zierl.at said:

> ...except it isn't installed by default. Will this be part of gpg-wks-client? 

Ooops.  I meant gpg-wks-client.  There is no gpg-wks-tool.

> won't be installed to libexec), it would still be beneficial to describe the 
> actual file system layout.

You mean, where it gets installed?  When running ./configure without any
options gpg-wks-tool whill be installed under /usr/local/libexec as per
GNU standards.  Debian and other distors don't have this directory and
install it under /usr/lib.  You can of course use

 $(gpgconf --list-dirs libexecdir)/gpg-wks-client



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: WKD: Publishing a key for multiple user IDs

[Werner Koch via Gnupg-users]

On Mon, 15 Jul 2019 18:03, gnupg-users@gnupg.org said:

> So if I have two email addresses/user IDs m...@my.org and m...@my.org
> associated with the same key, I cannot just export the key and publish
> it, right? I have to somehow publish two different ‘stripped’ public

Sight.  GnuPG handles this for you if your frontend uses gpg-wks-cleint
for this.  You can use this tool also to create a local copy of server
data structure and then sysc it up.

> Is there documentation somewhere how to produce the keys for both these
> user IDs with GnuPG? (I don’t think the Python generate scripts do this

I don't known about Python scripts.  Kmail, GpgOL, and Enigmail do the
publishing for you.  You can also do it manuallay, see the Wiki.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: WKD auto-key-retrieve method

[Werner Koch via Gnupg-users]

On Tue, 16 Jul 2019 17:18, gnupgpac...@on.yourweb.de said:

> how to put "--sender email at address" to gpg.conf file if using several
> different email addresses from sender?

You can't it is the task of the MUA (cf. gpgme_set_sender).

> Is it possible to put "--sender" option to public key itself?

No.  But the same effect can be achieved by specifying the sender via a
mail address.  Anywa, I would stuggest to use --sender or better
gpgme_set_sender.  The latter is a 3 liner for most MUAs.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: I deleted 80 % of my keyring, but my keybox file isn't shrinking

[Werner Koch via Gnupg-users]

On Wed, 17 Jul 2019 23:41, i...@zeromail.org said:

> But the keybox file didn't get any smaller:

Good catch.  In gpg we have not implenteted the compression run:

 /* FIXME: Do a compress run if needed and no other
user is currently using the keybox. */

However, in gpgsm this is done.  It does not work immediately but is
run only on gpgsm invocation iff there has been np update operaion in
the last 3 hours.  Thus to force a compression run you can do:

  faketime -f +3 gpgsm -k foo >/dev/null

Note that gpgsm's option --faked-system-time does not work here ( I
pushed a fix, though).

> PS: This could probably be updated:
>
>> Well, OpenPGP keys are not implemented, gpg still used the keyring
>> file pubring.gpg.

Will do.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: --lsign --add-me or the invisible WoT

[Werner Koch via Gnupg-users]

On Sat, 20 Jul 2019 11:57, gnupg-users@gnupg.org said:

> additional paramemter like --add-me for --lsign would make sense, for

   --quick-sign-key fpr [names]
   --quick-lsign-key fpr [names]
   
  Directly sign a key from the passphrase without any
  further user interaction.  The fpr must be the verified
  primary fingerprint of a key in the local keyring. If no
  names are given, all useful user ids are signed; with
  given [names] only useful user ids matching one of theses
  names are signed.  By default, or if a name is prefixed
  with a '*', a case insensitive substring match is used.
  If a name is prefixed with a '=' a case sensitive exact
  match is done.

  The command --quick-lsign-key marks the signatures as
  non-exportable.  If such a non-exportable signature
  already exists the --quick- sign-key turns it into a
  exportable signature.

  This command uses reasonable defaults and thus does not
  provide the full flexibility of the "sign" subcommand from
  --edit-key.  Its intended use is to help unattended key
  signing by utilizing a list of verified fingerprints.


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information

[Werner Koch via Gnupg-users]

On Mon, 29 Jul 2019 09:43, gnupg-users@gnupg.org said:
> it that way", i think.  Perhaps Werner can provide more background on
> why GnuPG is generally resistant to holding OpenPGP certificates that
> have no User ID at all in its local keyring.

The user ID is important because the accompanying self-signature conveys
important information about the keyblock.  For example expiration date
and preferences.  It is true that this can also be conveyed with
direct-key-signatures (a self-signature directly on a key which was
mainly introduced for dedicated revocations).  However, this is a not so
well tested feature of gpg and my educated guess is that many other
OpenPGP implementations do not handle direct-key signatures in a way
compatible to pgp or gpg - if at all.  Thus by relying on them we would
sail into uncharted waters.

> Doing such a merge would be super helpful, particularly for receiving
> things like subkey updates and revocation information from

I agree that we can add a code path to import a primary key plus
revocation certificate but without user-ids.  PGP however, does not
support this and is the reason why we extended the revocation
certifciate with a minmal primary key.

Update of subkeys is a different issue and I see no solid use case for
allowing that without user-id (cf. expiration date of the primary key).


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Commands supported by extra socket

[Werner Koch via Gnupg-users]

On Fri, 26 Jul 2019 15:57, gnupg-users@gnupg.org said:

> Where can I find information on what commands are supported by
> S.gpg-agent and S.gpg-agent.extra socket? I am looking for some
> information which clearly differentiates these two sockets.

Here is an overview on the allowed commands for the S.gpg-agent.extra
and S.gpg-agent.browser.  Only the commands required for perform a
signature creation or a decryption are possible via these sockets.  It is
for example not possible to list all known keys or to create a key.

| Command   | Allowed | Comment |
|---+-+-|
| GETEVENTCOUNTER   | no  | |
| ISTRUSTED | yes | |
| HAVEKEY   | yes | |
| KEYINFO   | no  | |
| SIGKEY| yes | |
| SETKEY| yes | |
| SETKEYDESC| yes | |
| SETHASH   | yes | |
| PKSIGN| yes | |
| PKDECRYPT | yes | |
| GENKEY| no  | |
| READKEY   | no  | |
| GET_PASSPHRASE| no  | |
| PRESET_PASSPHRASE | no  | |
| CLEAR_PASSPHRASE  | no  | |
| GET_CONFIRMATION  | no  | |
| LISTTRUSTED   | no  | |
| MARKTRUSTED   | no  | |
| LEARN | no  | |
| PASSWD| no  | |
| SCD   | no  | |
| KEYWRAP_KEY   | no  | |
| IMPORT_KEY| no  | |
| EXPORT_KEY| no  | |
| DELETE_KEY| no  | |
| GET_SECRET| no  | |
| PUT_SECRET| no  | |
| GETVAL| no  | |
| PUTVAL| no  | |
| UPDATESTARTUPTTY  | no  | |
| KILLAGENT | no  | |
| RELOADAGENT   | no  | |
| KEYTOCARD | no  | |
| GETINFO   | no  | see 1   |
| OPTION| no  | see 2   |
|---+-+-|

1) except for the sub-commands:
   "version", "cmd_has_option", "s2k_count", "restricted".
2) except for the option:
   "agent-awareness"



Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information

[Werner Koch via Gnupg-users]

On Thu,  1 Aug 2019 09:27, gnupg-users@gnupg.org said:

> We're already in uncharted waters with the inevitable abuse of SKS, we
> need to figure out how to stabilize the ecosystem.

Most businesses do not use public keyservers at all but use their
internal PKI.

> If the PGP implementation of OpenPGP has bugs or doesn't behave well in
> the context of a minimized/stripped certificate, let's ask them to fix
> those bugs.  The bugs in how that implementation interprets data are

Good luck.  PGP is in maintenance mode and there won't be any updates.
We even had layer-8 problems back in the times when Hal was still
alive/unfrozen to get new OpenPGP features into PGP.  In particular
companies will hesitate to update their once purchased PGP.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: skipped packet 12

[Werner Koch via Gnupg-users]

On Thu,  1 Aug 2019 20:46, da...@gbenet.com said:

> Do you have any ideas why am getting multiple lines of:
> gpg: skipped packet of type 12 in keybox

You gpg version is older than 2.1.20 but you used a newer version
on that keybox too.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: About support of RFC 2437, 4056 and 6979

[Werner Koch via Gnupg-users]

On Sat, 20 Jul 2019 10:07, persm...@hardenedlinux.org said:

> Does GnuPG support OAEP for RSA (PKCS#1 v2 and RFC 2437), RSA-PSS (RFC

gpg does not support this because OpenPGP requires pkcs-1.5.  There are
no plans to change this because there is not real world issue with
pcsc-15. when using in the way OpenPGP uses it.

> 4056?), or deterministic usage of (EC)DSA (RFC 6979)?

That is an implementation detail: gpg uses rfc-6979 since version 2.0.23
when it requires the use of Libgcrypt 1.6 implements this feature.

> And if GnuPG does support RFC 6979, would it also work with (EC)DSA
> private keys stored on OpenPGP cards which support (EC)DSA algorithms?

Yes for on-disk keys.  For cards it depends on the specific card.  Note
that we suggest the use of EdDSA with Curve25519 instead of ECDSA.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: BSI withdraws approval of GnuPG for confidential documents

[Werner Koch via Gnupg-users]

On Thu,  8 Aug 2019 17:22, gnupg-users@gnupg.org said:

> maybe interesting for some community members, living in Germany.

We learned about that last week and are trying to figure out what is
going on.  It is likely an internal coordination or content admin
problem at the BSI.  We do not know about any technical problems.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: PGP Key Poisoner

[Werner Koch via Gnupg-users]

On Tue, 13 Aug 2019 09:54, gnupg-users@gnupg.org said:

> The bug, however, is in the program that chokes on poisoned keys!

Nope.  This is a long standing DoS protection by limiting the total
length of a keyblock.  The diagnostics were a bit misleading, though.

The time it took to process all these signatures during importing is due
to a fix and out of order keyblock functions which has been enabled by
default in 2.1.  It should be obvious that checking several thousands of
signatures and finding the matching user-id takes its time.

Anyway, given that these keys are real the approach with 2.2.17 is to
auto-retry an import with import-clean etc. if the keyblock size hits
the size limit.  For keyserver imports import-clean is also the default.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Difficulty of fixing reconciliation

[Werner Koch via Gnupg-users]

On Wed, 14 Aug 2019 15:45, r...@sixdemonbag.org said:

> developed *more than twenty years ago* it was decided to support
> arbitrary numbers of third-party signatures.  GnuPG faithfully

At least OpenPGP has this:

  5.2.3.17.  Key Server Preferences

   (N octets of flags)

   This is a list of one-bit flags that indicate preferences that the
   key holder has about how the key is handled on a key server.  All
   undefined flags MUST be zero.

   First octet: 0x80 = No-modify
   the key holder requests that this key only be modified or updated
   by the key holder or an administrator of the key server.

GnuPG has always set this flag in anticipation that the keyservers will
eventually come up with an authenticated upload method.  As we all know
the keyserver developers didn't considered that as a priority thing and
thus we are at the state we are know.

At the first and only keyserver conference in 2000 this topic had been
on the agenda.  Due to the burst of the dotcom bubble we never got
together again and most thought that SKS was the way to go.  Recall that
it solved the problem with OpenPGP (HKP supported only 1 primary plus
one subkey) and the performance problem.

Since December 2013 it was pretty clear that the WoT and the keyservers
will have scaling problems.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Difficulty of fixing reconciliation

[Werner Koch via Gnupg-users]

On Thu, 15 Aug 2019 00:02, gnupg-users@gnupg.org said:

> But at least then we will want to add cryptography to see which
> selfsigs are truly legitimate, right?

That would be the first and most important step to get the keyservers
back for the WoT


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: how to recover secret key passphrase?

[Werner Koch via Gnupg-users]

On Wed, 21 Aug 2019 12:03, pe...@digitalbrains.com said:

> So what ilf probably needs is something that can read the private keybox
> format. That's where my advice falls short: I can't help with that.

That is right.  You need a new tool for John to do that.  The format is
descriped in gnupg/agent/keyformat.txt.  I do not have the time to write
such a tool anytime soon.  Sorry.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: BSI withdraws approval of GnuPG for confidential documents

[Werner Koch via Gnupg-users]

On Thu, 22 Aug 2019 00:04, pe...@digitalbrains.com said:

> And heck, it might lend urgency to the topic should Werner subsequently
> also ask them.

We are in contact with them and have regular meetings.  It does not help
the case if I would disclose details.  The problems around the OpenPGP
part of GnuPG is not a technical problem.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Questions on code signing

[Werner Koch via Gnupg-users]

On Tue, 27 Aug 2019 00:18, gnupg-users@gnupg.org said:

> (1) If a file is signed but the signature is incorrect, 'gpg2 -d'
> returns a non-zero status code, so the remote script knows not to

Right but as stated somewhere in the docs, you should never ever rely on
the status code fomr the binary.  Well, except for the gpgv tool which
we developed just for the purpose to verify signatures.  You can't use
it however with encrypted+signed data.

> like gpg2 will not catch that case. Is there an option I can give in
> addition to -d that REQUIRES the file to be signed? I realize you can

No, you need to check that there is a valid signature by checking the
--status-fd messages.  It is a bit tricky to get this right because
there is a variety of things which can be found in the input to gpg.
Using detached signatures makes things much easier because you really
known what has been signed.  You still need to check the status-fd
messages.

You may also use the GPGME library (or the gpgme-json wrapper) to make
things easier.  GPGME takes care of also nitty-gritty you would need to
do. 

> (2) If a file is signed and the remote script has the signer's public
> key, then a --verify operation will succeed. The trouble is, what if
> the file is signed by some signature in the remote script's keyring
> other than the expected code signing key? Is there an option that can
> be given to --verify (or along with -d, if there's a solution to (1))
> that can specify the exact signing key (or keys) required? I tried

Your script or progrtam should check which key was used for signing.  Or
you make sure that your local keyring only has that very key.  Watch out
for this --status-fd token:

VALIDSIG 

The args are:

- 
- 
- 
- 
- 
- 
- 
- 
- 
- [  ]

This status indicates that the signature is cryptographically
valid. This is similar to GOODSIG, EXPSIG, EXPKEYSIG, or REVKEYSIG
(depending on the date and the state of the signature and signing
key) but has the fingerprint as the argument. Multiple status
lines (VALIDSIG and the other appropriate *SIG status) are emitted
for a valid signature.  All arguments here are on one long line.
sig-timestamp is the signature creation time in seconds after the
epoch. expire-timestamp is the signature expiration time in
seconds after the epoch (zero means "does not
expire"). sig-version, pubkey-algo, hash-algo, and sig-class (a
2-byte hex value) are all straight from the signature packet.
PRIMARY-KEY-FPR is the fingerprint of the primary key or identical
to the first argument.  This is useful to get back to the primary
key without running gpg again for this purpose.

The primary-key-fpr parameter is used for OpenPGP and not
available for CMS signatures.  The sig-version as well as the sig
class is not defined for CMS and currently set to 0 and 00.

Note, that *-TIMESTAMP may either be a number of seconds since
Epoch or an ISO 8601 string which can be detected by the presence
of the letter 'T'.

This can be easily parsed with awk(1) or other tools.

> (3) If a file is both encrypted and signed, is there a way to merely
> verify the signature other than to include a detached signature? Right
> now, using --verify on a single file that was encrypted/signed with
> -es just gives "gpg: verify signatures failed: Unexpected error." Is
> there a way around that, so I don't need to use a detached signature?

You can extra the signature from the encrypted+signed data:

  gpg --unwrap -d -o SIG 

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

[Announce] Libgcrypt 1.8.5 released

[Werner Koch via Gnupg-users]

Hi!

The GnuPG Project is pleased to announce the availability of Libgcrypt
version 1.8.5.  This release fixes an ECDSA side-channel attack.

Libgcrypt is a general purpose library of cryptographic building blocks.
It is originally based on code used by GnuPG.  It does not provide any
implementation of OpenPGP or other protocols.  Thorough understanding of
applied cryptography is required to use Libgcrypt.


Noteworthy changes in version 1.8.5
===

 * Bug fixes:

   - Add mitigation against an ECDSA timing attack.
 [T4626,CVE-2019-13627]

   - Improve ECDSA unblinding.

 * Other features:

   - Provide a pkg-config file for libgcrypt.

 Release-info: https://dev.gnupg.org/T4683


Download


Source code is hosted at the GnuPG FTP server and its mirrors as listed
at .  On the primary server
the source tarball and its digital signature are:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.5.tar.bz2
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.5.tar.bz2.sig

or gzip compressed:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.5.tar.gz
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.5.tar.gz.sig

In order to check that the version of Libgcrypt you downloaded is an
original and unmodified file please follow the instructions found at
.  In short, you may
use one of the following methods:

 - Check the supplied OpenPGP signature.  For example to check the
   signature of the file libgcrypt-1.8.5.tar.bz2 you would use this
   command:

 gpg --verify libgcrypt-1.8.5.tar.bz2.sig libgcrypt-1.8.5.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 - If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file libgcrypt-1.8.5.tar.bz2, you run the command like this:

 sha1sum libgcrypt-1.8.5.tar.bz2

   and check that the output matches the first line from the
   this list:

2d8781e92f88706707a1e76fb628b499ad538a30  libgcrypt-1.8.5.tar.bz2
c4852a14b57744b2d0e97d9e8e3e60c95ef7e6bb  libgcrypt-1.8.5.tar.gz

   You should also verify that the checksums above are authentic by
   matching them with copies of this announcement.  Those copies can be
   found at other mailing lists, web sites, and search engines.
   

Copying
===

Libgcrypt is distributed under the terms of the GNU Lesser General
Public License (LGPLv2.1+).  The helper programs as well as the
documentation are distributed under the terms of the GNU General Public
License (GPLv2+).  The file LICENSES has notices about contributions
that require that these additional notices are distributed.


Support
===

In case of build problems specific to this release please first check
https://dev.gnupg.org/T4683 for updated information.

For help on developing with Libgcrypt you should read the included
manual and optional ask on the gcrypt-devel mailing list [1].  A
listing with commercial support offers for Libgcrypt and related
software is available at the GnuPG web site [2].

If you are a developer and you may need a certain feature for your
project, please do not hesitate to bring it to the gcrypt-devel
mailing list for discussion.


Thanks
==

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project currently employs two full-time developer and two
contractors.  They all work exclusively on GnuPG and closely related
software like Libgcrypt, GPGME, and GPA.

We have to thank all the people who helped the GnuPG project, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.  Thanks to Tomas Mraz for pointing out several smaller flaws.

Many thanks to our numerous financial supporters, both corporate and
individuals.  Without you it would not be possible to keep GnuPG in a
good shape and address all the small and larger requests made by our
users.  Thanks.


Happy hacking,

   Your GnuPG hackers



p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users'at'gnupg.org mailing list.

p.p.s
List of Release Signing Keys:

To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are s

Re: Info for GnuPG users which have a keybase account

[Werner Koch via Gnupg-users]

On Tue, 10 Sep 2019 18:58, gnupg-users@gnupg.org said:

> Well, Werner and other prominent ML members are on keybase, so

I am not.  I once tested it and thus there may still be an account or
whatever.  And I do not know what Stellar or Lumen are in this context.
But no need to explain it.

Anyway, I don't mind to see such pointers on this ML once in a while.
For easier parsing you should have biefly explained the key terms.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Generating bitwise identical keyrings with GnuPG 1 + 2

[Werner Koch via Gnupg-users]

On Fri, 13 Sep 2019 21:28, io...@ionic.de said:

> Either way, my best guess is that GPG 2.2+ drops the trust packets
> because the trust is not explicitly set (i.e., default value) - as an

The trust packets are for internal use of gpg and are never exported.
These packets are one of the reasons why we stated for decades that the
interface is "gpg --export" and that the files in ~/.gnupg are internal
to gnupg.

gnupg/doc/DETAILS tells this about the trust packets:

* Format of the OpenPGP TRUST packet

  According to RFC4880 (5.10), the trust packet (aka ring trust) is
  only used within keyrings and contains data that records the user's
  specifications of which key holds trusted introducers.  The RFC also
  states that the format of this packet is _implementation defined_ and
  SHOULD NOT be emitted to output streams or should be ignored on
  import.  GnuPG uses this packet in several additional ways:

  - 1 octet :: Trust-Value (only used by Subtype SIG)
  - 1 octet :: Signature-Cache (only used by Subtype SIG; value must
   be less than 128)
  - 3 octets :: Fixed value: "gpg"
  - 1 octet  :: Subtype
   - 0 :: Signature cache (SIG)
   - 1 :: Key source on the primary key (KEY)
   - 2 :: Key source on a user id (UID)
  - 1 octet :: Key Source; i.e. the origin of the key:
   - 0 :: Unknown source.
   - 1 :: Public keyserver.
   - 2 :: Preferred keyserver.
   - 3 :: OpenPGP DANE.
   - 4 :: Web Key Directory.
   - 5 :: Import from a trusted URL.
   - 6 :: Import from a trusted file.
   - 7 :: Self generated.
  - 4 octets :: Time of last update.  This is a a four-octet scalar
with the seconds since Epoch.
  - 1 octet  :: Scalar with the length of the following field.
  - N octets :: String with the URL of the source.  This may be a
zero-length string.

  If the packets contains only two octets a Subtype of 0 is assumed;
  this is the only format recognized by GnuPG versions < 2.1.18.
  Trust-Value and Signature-Cache must be zero for all subtypes other
  than SIG.

If you use "--export-options backup" these trust packets are exported
anyway so that they can be imported with "--import-otions restore".

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: 37.191.231.105 (part of keyserver pool) redirects to ... unknown location?

[Werner Koch via Gnupg-users]

On Mon, 16 Sep 2019 10:11, io...@ionic.de said:

> which also means that requests to URLs like http://keys.gnupg.net will 
> sometimes
> redirect a user to that location.

That is not correct.  For quite some time that address is a hardwired to
avoid problems DNS problems (https://dev.gnupg.org/T3755):

  /* We used to have DNS CNAME redirection from the URLs below to
   * sks-keyserver pools.  The idea was to allow for a quick way to
   * switch to a different set of pools.  The problem with that
   * approach is that TLS needs to verify the hostname and - because
   * DNS is not secured - it can only check the user supplied hostname
   * and not a hostname from a CNAME RR.  Thus the final server all
   * need to have certificates with the actual pool name as well as
   * for keys.gnupg.net - that would render the advantage of
   * keys.gnupg.net useless and so we better give up on this.  Because
   * the keys.gnupg.net URL are still in widespread use we do a static
   * mapping here.
   */
  if (!strcmp (uri, "hkps://keys.gnupg.net")
  || !strcmp (uri, "keys.gnupg.net"))
uri = "hkps://hkps.pool.sks-keyservers.net";
  else if (!strcmp (uri, "https://keys.gnupg.net";))
uri = "https://hkps.pool.sks-keyservers.net";;
  else if (!strcmp (uri, "hkp://keys.gnupg.net"))
uri = "hkp://hkps.pool.sks-keyservers.net";
  else if (!strcmp (uri, "http://keys.gnupg.net";))
uri = "http://hkps.pool.sks-keyservers.net";;
  else if (!strcmp (uri, "hkps://http-keys.gnupg.net")
   || !strcmp (uri, "http-keys.gnupg.net"))
uri = "hkps://ha.pool.sks-keyservers.net";
  else if (!strcmp (uri, "https://http-keys.gnupg.net";))
uri = "https://ha.pool.sks-keyservers.net";;
  else if (!strcmp (uri, "hkp://http-keys.gnupg.net"))
uri = "hkp://ha.pool.sks-keyservers.net";
  else if (!strcmp (uri, "http://http-keys.gnupg.net";))
uri = "http://ha.pool.sks-keyservers.net";;


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Generating bitwise identical keyrings with GnuPG 1 + 2

[Werner Koch via Gnupg-users]

On Mon, 16 Sep 2019 15:41, io...@ionic.de said:
> * On 9/15/19 3:56 PM, Werner Koch wrote:
>> The trust packets are for internal use of gpg and are never exported.
>
> But... that's the whole point. gpg 1.4 seems to export them, while gpg
> 2.x does not.

I just checked the code and I can't see how they get exported.  In the
loop over the packets you find:

/* Make sure that ring_trust packets never get exported. */
if (node->pkt->pkttype == PKT_RING_TRUST)
  continue;

which should skip them while exporting.  Can you please provide a test
keyring and tell us the exact gpg 1.4 version you are using?

> unreproducible output for a specific operation is a bit weird. I don't know if
> the format GnuPG generates with the --export command is considered
> stable, though.

Yes it is the interchange format as specified by RFC-4880.

> I basically need to find a way to
>  - either make gpg 1.4 NOT output trust packets

The solution is simple; Do not use gpg 1.4 except for decrypting legacy
data which either does not use MDC or is encrypted with a v3 key.
There is no other use case for gpg 1.4.

> 1.4 seems to generate trust packets *only* after signatures, while 2.2, when
> used with the --export-options backup option, generates trust packets after 
> key,

They are implementation defined and thus do not go into the key
interchange format (transferable public/secret key).  The backup/restore
options are an exception for, well, backup and restore of *GnuPG*'s
internal key data storage.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Which version of GnuPG to use?

[Werner Koch via Gnupg-users]

On Mon, 16 Sep 2019 23:49, gnupg-users@gnupg.org said:

> speak, with a specially crafted software, when using an online computer
> with a SmardCard? I have read that the secret key can not been copied from
> the card, but what about the 'bits and pieces' in memory when decrypting?

Side-channel attacks on smartcards are an pretty old thing dating back
to the late 80ies.  Current smartcards are hardened against most such
attacks.  Unless you have physical access to the card the secrets and
their use on the card/token are well protected against any sniffing by
the host.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Regenerate Openpgp Public Key from Private Key

[Werner Koch via Gnupg-users]

On Tue, 17 Sep 2019 06:51, m...@halfdog.net said:

> Regenerating private keys is mathematically trivial but tool-wise
> a little tricky. It seems that quite some people were troubled

What's wrong with 

  gpg --import backup-of-private-key.gpg

the private key include the entire public key.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keys.openpgp.org not sending confirmation email

[Werner Koch via Gnupg-users]

On Tue, 17 Sep 2019 09:12, li...@binarus.de said:

> I am asking myself why Enigmail doesn't. I am not sure (and can't test
> at the moment) how GnuPG would behave if given a problematic name when
> generating a key; I hope it would give a warning or would add the

gpg generates such a key just fine:

  gpg --quick-gen-key "foo, bar | baz "

results in

  pub   rsa3072 2019-09-17 [SC] [expires: 2021-09-16]
  D5A13F45AD29FAD517FEB157F29010625F3EDDDA
  uid  foo, bar | baz 

and gpg's internal mail-addr extraction function simply looks for the
left angle bracket to find the mail-address and then checks whether that
mail-addr is valid.  The code also allows for a user-id consisting only
of the mail-addr without the angle brackets.  The reason for this is
that this de-facto standard only resembles an rfc-822 address but is not
necessary valid.  For example due to the utf-8 encoding.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Regenerate Openpgp Public Key from Private Key

[Werner Koch via Gnupg-users]

On Tue, 17 Sep 2019 11:09, m...@halfdog.net said:

> Therefore some exports (or copies of old secring.gpg) just do
> no include the public key, otherwise import would be trivial.

Nope.  It is not possible to create an OpenPGP secret keyblok without
the public key parts.

> As the key causing me problems was very old, I do not have the
> software at hand that was used to create it, nor it is clear

We removed v3 key support in 2.1 for security reasons.  You need to use
gpg 1.4 wo work with these keys.

> https://unix.stackexchange.com/questions/267844/gpg-secret-key-not-available-when-sec-pub-key-are-in-keyring

That is about the old 2.0 (or a 1.4) version which is end-of-life and
did not allow to merge secret and public keyblocks.  That might be the
problem at hand.  2.2 fixes this problem by not trying to sync a
secring.gpg and pubring.gpg.  The secring.gpg is actually not anymore
used but the secret parts of the key have been moved to the gpg-agent's
secret key store.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keys.openpgp.org not sending confirmation email

[Werner Koch via Gnupg-users]

On Tue, 17 Sep 2019 14:57, li...@binarus.de said:

> to use only key IDs consisting solely of the actual mail address
> hereafter (with or without the angle brackets - I can live with both

That is actually what I suggest for quite some time.  The extra stuff is
not required and may lead only to confusion if the user id does not
match the mail address as taken from an addressbook, or a received mail.

Further there are mail providers who do only allow keys which only the
mail address.  The Web Key Directory takes this in account and gnupg
will create a new user id for such providers in the publishing process.
 
> I see. Then the problem might be due to standards which are "only"
> de-facto, leading to parsers (on the key servers) which interpret those
> IDs subtly differently from what GnuPG / Enigmail and friends expect.

BTW, for a long time PGP 5 and later had no idea about the charset of
user-ids and happily copied verbatim whatever the OS supplied as a
string.  The result is that all MUAs and gpg's command line implement a
heuristic to detect and convert on display the Latin-1 encoding of
German Umlauts.

> By the way, I did not test yet how keys.openpgp.org would behave when
> given a key ID with a comma in the name, but with the name quoted.

FWIW, tehre are obvious cases which gpg does not catch either.  I added
two test cases to show this:

+++ b/common/t-mbox-util.c
@@ -77,6 +77,12 @@ run_mbox_test (void)
   { " ()", "fo()o...@example.org" },
   { "fo()o...@example.org", NULL},
   { "Mr. Foo ", "f...@example.org"},
+  { "Surname, Forename | company ", "f...@example.org"},
+  /* The next one is for sure not RFC-822 correct but nevertheless
+   * the way gpg does it.  We won't change it because the user-id
+   * is only rfc-822 alike and not compliant (think only of our
+   * utf-8 requirement).  */
+  { "\"\" ", "f...@example.org"},
   { NULL, NULL }
 };

> to have my name or other fancy text in my keys' IDs. I suppose that
> somebody who wants to write me an encrypted message will search for my
> public key at first by email address (and not by other criteria). At

Actually we parse the address out of the user-id and put it into the
Signer's User ID subpacket of a signature if possible.  Mail addresses
have the advantage that they maps to a global directory of identities
which full user-ids won't.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Automatically delete old keys from servers

[Werner Koch via Gnupg-users]

On Tue, 17 Sep 2019 15:12, daniel.boss...@dabo.ch said:

> On the key servers are many old keys lying around which aren't valid anymore.

Old keys are still useful to verify signatures.  This is even true for
expired keys.  The user then needs to decide what to do with the
verification result.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keys.openpgp.org not sending confirmation email

[Werner Koch via Gnupg-users]

On Tue, 17 Sep 2019 15:08, gnupg-users@gnupg.org said:

> See also dkg's thoughts on the matter on the openpgp-wg mailing list, to align
> the specification with reality:

OpenPGP has never defined what goes into the User ID except for the
encoding which should be UTF-8.  Anything else does not belong into the
specs unless the X.509 mess is a desired outcome.  Thus the current
wording is sufficient and has served us well over the last 25 years [1]:

| ## User ID Packet (Tag 13)
| 
| A User ID packet consists of UTF-8 text that is intended to represent
| the name and email address of the key holder.  By convention, it
| includes an RFC 2822 [](#RFC2822) mail name-addr, but there are no
| restrictions on its content.  The packet length in the header specifies
| the length of the User ID.



Salam-Shalom,

   Werner




[1] RFC-1991 is oldest spec I have instantly available; it describes the
1991 data format of PGP2, it differes from OpenPGP only by using ASCII
for the encoding:

|6.7 User ID Packet
|
|   Purpose.  A user ID packet identifies a user and is associated with a
|   public or private key.
|
|   Definition.  A user ID packet is the concatenation of the following
|   fields:
|
|  (a) packet structure field (2 bytes);
|  (b) User ID string.
|
|   The User ID string may be any string of printable ASCII characters.
|   However, since the purpose of this packet is to uniquely identify an
|   individual, the usual practice is for the User ID string to consist
|   of the user's name followed by an e-mail address for that user, the
|   latter enclosed in angle brackets.


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: keys.openpgp.org not sending confirmation email

[Werner Koch via Gnupg-users]

On Tue, 17 Sep 2019 17:35, look@my.amazin.horse said:

> convention or otherwise.  The spec is factually wrong and misleading for
> implementors in this aspect, and should be updated to reflect reality.

The specs are not wrong if you would read them:

| the name and email address of the key holder.  *By convention*, it
| includes an RFC 2822 [](#RFC2822) mail name-addr, but there are no

 Convention \Con*ven"tion\, n. [L. conventio: cf. F. convention.

 5. An agreement or contract less formal than, or preliminary
to, a treaty; an informal compact, as between commanders
of armies in respect to suspension of hostilities, or
between states; also, a formal agreement between
governments or sovereign powers; as, a postal convention
between two governments.
[1913 Webster]

In German "Sitte" oder "Brauch".  In contrast:

 specification \spec`i*fi*ca"tion\

 4. A detailed listing or description of the required
properties of some object proposed to be built or bought;
-- usually used in the plural; as, the building
specifications require that it withstand an earthquake of
magnitude 8; the program specifications require an option
to change the menus.
[PJC]

Instead of finalizing RFC4880bis, which has all its goals already
implemented, some members of the WG kept on raising new items for what
the WG has never been chartered.  The outcome of all that mess is that
implementers will simply ignore the fact that there won't be an RFC and
implement the current I-D.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Need Help with C Compiler Error in AIX 5.3 During GnuPG Build

[Werner Koch via Gnupg-users]

On Mon, 23 Sep 2019 02:36, gnupg-users@gnupg.org said:

> configure:3554: error: C compiler cannot create executables

configure does an early test to see whether your C compiler works.  This
is done to detect crippled compilers delivered on some systems.  Seems
not the case here, though.

> configure:3505: cc $(INCLUDE_FLAGS) -U__STR__ -DAIXRIOS -DNLS_ASIA
> -DORE -D_BSD -DRIOS -qro -O -DAFSTUBS conftest.c >&5
> cc: 1501-228 (W) input file $(INCLUDE_FLAGS) not found

... $(INCLUDE_FLAGS) looks like a make macro and definitely does not
belong here.  Check whether you have set any of CFLAGS, CPPFLAGS,
LDFLAGS set in your environment or whether the envvar CC specifies these
flags.  It is also possible that cc is shell script or other wrapper
which invokes the real CC; check for uncommon things in your PATH.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: ed25519 and sha256

[Werner Koch via Gnupg-users]

On Wed, 25 Sep 2019 16:35, r...@sixdemonbag.org said:

> Wikipedia is not a very good reference for low-level technical details.
>  Ed25519 is shorthand for "EdDSA on a specific curve": it is silent on
> the subject of hash algorithms, although you can specify one as
> "Ed25519-SHA-512" or what-have-you.

Not quite true.  We use ed25519 with SHA-512.  However, what we sign is
a hash value which often commonly happens to be a SHA-256 hash.

The reasons for this is that this model better fits into the OpenPGP
framework and - more important - this indirection allows us to implement
ed25519/sha512 in a smartcard.  Consider the case that you want to sign
a large data blob with a smartcard: With the direct ed25519 method it
would be required to send the entire data to the smartcard which would
take way to long for any practical application.  Smardcards communicate
in the 300 kBit/sec range and even USB tokens or not much faster.
Further they employ small 16 bit CPUs where taking a SHA-512 hash on a
lot of data will take ages.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: unknown modified files in GNUPGHOME

[Werner Koch via Gnupg-users]

On Sun, 29 Sep 2019 10:27, g...@unixarea.de said:
> Hello,
>
> While doing a backup of my $HOME it turned out (what I never saw
> before), that some file were changed in GNUPGHOME:
>
> -rw---  1 guru  wheel157316 21 sept. 10:07 .gnupg-ccid/pubring.kbx
> -rw---  1 guru  wheel155467 21 sept. 10:07 .gnupg-ccid/pubring.kbx~

The usual backup file without the last edit.  gpg writes to a new file,
renames the old file to *~, and then renames the new file to the
original file.

> drwx--  2 guru  wheel  1024 21 sept. 10:08 .gnupg-ccid/crls.d/
> -rw---  1 guru  wheel  3997 21 sept. 10:08 .gnupg-ccid/crls.d/DIR.txt
> -rw--- 1 guru wheel 17715895 21 sept. 10:08
> .gnupg-ccid/crls.d/crl-CDECFDC58640B7262B39CCB59B61E8EEFF2ED4D0.db

Some CRL was updated.  CRLs are downloaded after the have expired,
verified and the content then stored in a constant database (tinycdb)
for index access to the entries.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: We have GOT TO make things simpler

[Werner Koch via Gnupg-users]

On Fri,  4 Oct 2019 21:28, Stefan Claas said:

> Well, I was wrong. It seems that the U.S. ESIGN Act is pretty relaxed
> and does not need such strong requirements like in the EU.

The EU neither.  Even the Qualifizierte Elektronische Signatur,
introduced in Germany ages ago, is not anymore a requirement for the
majority of transactions.  In fact the Einfache Elektronische Signatur
(i.e. your name below a email) is often sufficient.  It is the same as
with handwritten signatures - if it comes to a litigation the court
decides and evaluates the entire circumstances.  Having a government
issued token (e.g. a qualified electronic signature) puts more trust
into the validity of the signature but still allows the signer to
repudiate the signature just by telling that the token was lost and the
PIN was on an attached post-it.

Recall that for VAT purposes (the major revenue source of almost
countries) no signature on digital invoices is required.  A EU decision
once overturned the German requirement for a government issued qualified
signature on invoices and thus was the tombstone for the qualified
electronic signature (modulo that some companies try to keep them alive
as their business model but that, along with their questionable legal
hack, is a different story).

It is a perfectly okay to allow a Fortgeschrittene Elektronische
Signatur (advanced electronic sigature, i.e. S/MIME or OpenPGP) to
replace a handwritten signature if that has been stated in contracts or
constitutional documents or their bylaws.  This prima facie evidence is
nearly always sufficient unless notarial documents are anyway required.

There is a lot of literature on that topic which can easily be found and
studied.  It is is not the topic of this technical mailing list, though.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: We have GOT TO make things simpler

[Werner Koch via Gnupg-users]

On Sat,  5 Oct 2019 12:15, Stefan Claas said:

> installing MUAs and plug-ins, besides of GnuPG) point them to the FAQ as
> learning resource and then show them as modern alternative Mailvelope

And don't forget to point them to all the HOWTOS and RFCs required to to
use and admin a MUA, sendmail, and the net configuration to name just a
few.  The point here is that you falsely compare a system tool with an
end user visible interface.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

How to improve our GUIs (was: We have GOT TO make things simpler)

[Werner Koch via Gnupg-users]

On Mon, 30 Sep 2019 10:58, Roland Siemons said:

> 4/ Here is my proposal:
> 4.1/ Stimulate that people use a GUI like GPA or Kleopatra. Not Enigmail,

Enigmail folks won't like that suggestion.  Users need to install a
second tool which behaves different (because Enigmail implements parts
of GnuPG on its own).

I agree with you and, although I sometimes hack on GPA, I would suggest
Kleopatra.  On Windows Kleopatra and the Explorer plugin do actually do
what you suggest and we LOTS of folks using Gpg4win.  Be it for plain
file encryption or for its Outlook plugin.

> 4.2/ Ensure that, when generating a keypair, GnuPG creates one directory
> "Secretkeys", and one directory "Publickeys". Make GnuPG to store the public
> part and the secret part separately in those directories. If GnuPG needs also
> keypairs in a single file, store that under Secretkeys.

That are all internals of GnuPG (except for the revocations directory)
and should not be touched by most users.  The problem is that there are
so many howtos and tutorials floating around which suggest to modify
this or that or to do that.  In most cases this is not appropriate.
gpg --import and --export are the interfaces which users need to know
about - iff they really want to use the gpg _tool_.  See your first point.

> 4.3/ Get rid of the confusing menu/Exportkeys/ vs. menu/Exportsecretkey. etc.

Exporting public keys is an important operation for everyone and thus it
needs to be prominent.  Exporting secret keys should come with a strong
warning or better be removed and replaced by a sync-with-other-device
feature.

If you have concrete suggestions for Kleopatra, I am sure Andre will
listen to you.  For GPA it is unlikely that we put a lot work into it -
it is these days mostly a test bench for my changes to GPGME.

> 4.5/ Get rid of the options to NOT publish keys on keyservers. Just work the
> opt-in alternative: If you want to publish to keyservers, make that a separate
> action that requires some effort.

No.  Despite the current problems with keyservers, we like keyservers
because they make public key encryption easier.  Deployment of the Web
Key Directory is still rare and some mail providers will never deploy
that.  Thus the second best option is to send initially a signed mail and
the recipient can then reply encrypted - this works by looking up the
signature key on a keyserver and use that for encryption.  We are
currently in the process of tweaking this so that we can eventually
make this again the default behaviour.


Shalom-Salam,

   Werner


p.s. I took the freedom to change the subject to better reflect what
your suggestion is about.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: How to improve our GUIs

[Werner Koch via Gnupg-users]

On Sat,  5 Oct 2019 21:21, vedaal said:

> and then a separate option of
> "Export Secret Keys"

The OP explictly suggested to make the exporting of the secret key not
too easy so that users don't accidently send out their secret keys.  


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: How to improve our GUIs

[Werner Koch via Gnupg-users]

On Mon,  7 Oct 2019 10:15, john doe said:

> In the above link, only the cli version of the 1.4 release is available.
> I got it from (1).

Nope.   That is always the current 2.2.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: We have GOT TO make things simpler

[Werner Koch via Gnupg-users]

On Sat,  5 Oct 2019 12:30, Robert J. Hansen said:

> *absolutely no way* integrated into the email message.  That had to wait
> until the PGP/MIME RFCs -- that was when OpenPGP became an email protocol.

MIME types for PGP inline were used on Unix soon after the introduction
of MIME in 1992 at about the same time PGP started its life.  The
original use cases for MSDOS PGP were BBS (e.g. FidoNet) where it does
not make sense to distinguish between mail and files.

RFC-2015 (PGP/MIME) was published in fall 1996 and predates the OpenPGP
specs.  I recall that Mutt implemented PGP/MIME even before its
publication.

> See above.  Email was used as a way to transfer files.  But there was
> nothing special about using email to transfer files.  You could just as

Everything is a file on Unix (or well, on Plan-9) ;)


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: can not se and run gpg2 command

[Werner Koch via Gnupg-users]

On Wed,  9 Oct 2019 15:42, Fta said:

> I have installed Gnup in me windows 7, but I can not se and run the
> command gpg2

On some systems (mainly older Linux distributions), the current gpg is
still installed under the name gpg2.  On Windows we are using the name
gpg.exe now for many years.  Some HOWTOS tell you to use gpg2.exe but you
can and should use gpg.exe.

> C:\Users\Danuna\AppData\Roaming\gnupg>gpg.exe --version
> gpg (GnuPG) 2.2.17

Good.  You are using the latest version.

BTW, to get information on where GnuPG is installed you can use

  gpgconf.exe --list-dirs


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Future OpenPGP Support in Thunderbird

[Werner Koch via Gnupg-users]

On Fri, 11 Oct 2019 20:18, Philipp Klaus Krause said:

> They don't want users to require to install gpg first. And they don't
> want to ship gpg with Windows installers, since it isn't MPL.

The latter is just plain bullshit.  There are even many proprietary
products which bundle gpg or other GPL code with their proprietary or
MPL licensed code.  Not just small companies but large ones with huge
and conservative legal departments.  The actual requirements for
distribution are easy to fulfill and are actually easier with the GPLv3
than with the v2.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Future OpenPGP Support in Thunderbird

[Werner Koch via Gnupg-users]

On Sat, 12 Oct 2019 02:23, Robert J. Hansen said:

> on Enigmail was very real.  It was created by an ambiguity in how GnuPG
> returns error states: just because GnuPG says "decryption OK" doesn't

Nope.  They did not read the documentation and did not checked error
codes.  We suggest for a reason to use GPGME to make error checking
easy.  You can't just code things down along some specs without thinking
over the implications.

Still, TB is still subject to those attacks because their primary
encryption protocol is S/MIME and the last time I checked S/MIME (well,
CMS for the nitpickers) does not supoport any kind of authenticated
encryption.  In contarst OpenPGP provides this nearly for 2 decades.
Mozilla has not even stepped forward and implemented one of the
meanwhile old proposal to move to AE.  So Microsoft had to take the lead
to do this (rumors are that the next OL version will allow for GCM mode)

After 20 years of strong resistance against implementing OpenPGP [1], they
finally seem to do it.  That is a good move.


Shalom-Salam,

   Werner


[1] Back in ~1999, when Mozilla rewrote the entire mail engine, I
implemented a first version of PGP/MIME code which was rejected due to
their policy of only supporting S/MIME.  For a term paper a German
student later took up on my code, extended and cleaned it up.  Again it
was rejected.  About 2005 we had a meeting with them to propose that we
implement S/MIME again in a way that would comply to the strong policy
requirements here in Germany and also to implement OpenPGP as an
additional protocol.  It was again rejected.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Future OpenPGP Support in Thunderbird

[Werner Koch via Gnupg-users]

On Fri, 11 Oct 2019 21:48, qwrd said:

> Storing private keys on a smartcard is a noteworthy security
> enhancement, and I would like to see smartcard support being available
> in Thunderbird. Either via GnuPG or some other mechanism.

Take a Yubikey or an OpenPGP smartcard, install Scute (pcks#11
provider) and GnuPG and you are done.  Either S/MIME or OpenPGP.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Future OpenPGP Support in Thunderbird

[Werner Koch via Gnupg-users]

On Sat, 12 Oct 2019 12:43, Chris Narkiewicz said:

> Do you know why they resited OpenPGP adoption it so much?

iirc, they said that they want to support only one protocol and settled
for S/MIME.  This still did not explain why they rejected our proposal
to clean up their S/MIME code and implement missing stuff so that TB
could be used for tasks of the German administrative and to be
compatible with a wider range of S/MIME implementations.  The plan was
to do that all within TB and without external dependencies.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Future OpenPGP Support in Thunderbird

[Werner Koch via Gnupg-users]

On Sun, 13 Oct 2019 18:27, Binarus said:

> keys' IDs were formally wrong so that key servers didn't accept the
> keys. The easiest possible solution was to re-generate these keys using

For the records: Not /keyservers/ but one specific keyserver which runs
on a not yet matured enough code base and is thus expected to have bugs.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Future OpenPGP Support in Thunderbird

[Werner Koch via Gnupg-users]

On Mon, 14 Oct 2019 10:54, Phillip Susi said:

>> encryption protocol is S/MIME and the last time I checked S/MIME (well,
>> CMS for the nitpickers) does not supoport any kind of authenticated
>> encryption.  In contarst OpenPGP provides this nearly for 2 decades.
>
> What do you mean?  S/MIME authenticates the user's identity via the CA.

authenticated encryption is different from signed and encrypted mails.
There are relative easy attacks on the encryption layer if standard
encryption modes like CBC (as in S/MIME) are used.  Whether this really
affects users is a different question but they can be used to leverage
implementation flaws in MUAs to full plaintext leaks.  This is known for
20 years and made it last year again to the media under the term EFAIL.

Granted, encrypted+signed mails can to a large extend also mitigate the
threat.  But there are still reasons why signatures can't be used or
need to be verified only at a latter time in the workflow.

OpenPGP had a mitigation against this since 2000 and was widely deployed
by 2003.  However S/MIME never implemented this despite of 10 years old
RFCs describing methods for such a mitigation, called authenticated
encryption (AE or AEAD).


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Future OpenPGP Support in Thunderbird

[Werner Koch via Gnupg-users]

On Mon, 14 Oct 2019 20:43, Kristian Fiskerstrand said:

> was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC.
> Details need to be discussed, but it would be an optional solution, that

Given that TB already has smartcard support it would be easy if the new
code just makes use of that code.  Of course the code then needs to
touch the NSS part of Mozilla and can't just go with RNP.  That would be
a more integrated solution than any other hack.

Right, separate software will be required but that is the usual case
with smartcards.  For example Scute can be used to provide card services
via GnuPG (and also allow for on-disk GnuPG.  Note that GnuPG 2.3 will
be much more flexible in regard to smartcard use and how it can interact
with TB via Scute.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: FAQ October 2019 update

[Werner Koch via Gnupg-users]

On Tue, 15 Oct 2019 15:17, Robert J. Hansen said:

> * Every reference to the SKS keyserver network now points to
> keys.openpgp.org.  Reason: the SKS attacks a few months ago.

I have to object against this change.  The SKS server network is still
useful and definitely more useful than an non-matured and  centralized
keyserver.  I am okay with removing explicit reference to the SKS
network for now but suggesting the use of that specific keyserver is a no-go.

> * All references to 2048-bit crypto are updated to refer to 3072-bit
> crypto.  Reason: GnuPG now defaults to 3072-bit RSA.

Okay.   But this

  +your certificate uses 2048-bit keys we recommend retiring them and
  +migrating to a new keypair of at least 3072 bits length.  You can do

is a no-go because we will have a hard to time to convice people that
this is just a geek suggestion and that for almost all general use of
gpg the existsing keys are still fine.  Actually 2k keys are still
allowed in Germany for restricted communication and there is no need for
an immediate rush to 3k.

I also wonder why you removed this

  -If you need more security than RSA-2048 offers, the way to go would be
  -to switch to elliptical curve cryptography — not to continue using
  -RSA.

GnuPG's future default is already ECC and some hosted mail services
are already creating such keys.  GnuPG will switch to that with 2.3
which is not that far away.

> (Note: I just committed the FAQ changes.  It may take a couple of days
> for the documentation on the website to be regenerated.)

That is a matter of minutes.  I only had a brief look at it but I can't
see that your changes are subject to frequently asked questions here.
The GnuPG FAQ is for all GnuPG users and should not again start reflect
the view of some crypto geeks or give advises which will lead only to
trouble.

I am sorry for having to write these harsh comments: In contrast to
discussions on the mailing list the FAQ reflects the opinion of the
GnuPG project and as such substantial changes need to be discussed
first.  I would suggest to create a branch and revert the changes
in master until an agreement has been reached.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: GPG Agent discarding cache before ttl/max ttl

[Werner Koch via Gnupg-users]

On Tue, 15 Oct 2019 09:14, Chip Senkbeil said:

> Is there some separate setting for GPG agent to discard its cache
> earlier than the ttl/max ttl settings? I've checked the GPG agent

You can follow the cache operations by adding

  log-file /some/log/file
  debug cache

to gpg-agent.conf and reload it (gpgconf --reload gpg-agent).  This will
give you some insights on what is going on.

The stadard way to flush the cache is bei sending a HUP to gpg-agent (or
the above reload command).  If your system has a method to run a script
on suspend or lid closing it may already do just that.  I consider this
a good idea but we can't do that by default in GnuPG because systems
differ to much on how to detect a lid closing event or similar.  Thus
there is also no way to avoid it using a GnuPG option.

> enable-ssh-support

Its the default anyway

> fixed-list-mode

You can remove that too it has no effect anymore.

> # When making an OpenPGP certification, use a stronger digest than
> the default
> # SHA1:
> cert-digest-algo SHA256

It is the default for a long time now.  Only gpg 1.4 still defaults to
SHA-1 but you are not using that.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: A place for discussing WKD spec clarifications?

[Werner Koch via Gnupg-users]

On Tue, 15 Oct 2019 09:06, Bjarni Runar Einarsson said:

> Would the GnuPG issue tracker be a good place to file "bug
> reports" against the spec, to work towards clarifications?

That is okay for bug reports, but often it is more important to get the
opinions from more people than those who triage the bug reports.

I thing gnupg-devel@ gnupg.org would be an appropriate place for
discussing such topics.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Future OpenPGP Support in Thunderbird

[Werner Koch via Gnupg-users]

On Wed, 16 Oct 2019 13:07, Patrick Brunschwig said:

> something on their PC and more. Gpgme may handle some of these issues,
> but the fact remains: an external component makes things a lot more
> complex, especially for support.

Right GPGME handles this all pretty well and I have suggested often
enough that you should move to GPGME so that we can better support
Enigmail.  Your comment about external components is right from a
company POV; however Enigmail is also an external component to TB and
thus TB suffers from very similar problem.  GpgOL and GnuPG both are
maintained by us and thus I know very well this helps to reduce
friction.

The move to integrate OpenPGP in TB is important but also pretty risky
if it won't work for everyone right away from the start.  The big
advantage of TB/Enigmail is that it is cross-platform and often the only
way to have encrypted mail on macOS.  I know several media companies who
badly suffered when GpgTools were not able to get their plugin working
on a new macOS version.  Their journalists were then forced to use TB
and not their, for whatever reason, beloved apple mailer.  Let's hope
that at least of one is always working.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Future OpenPGP Support in Thunderbird

[Werner Koch via Gnupg-users]

On Wed, 16 Oct 2019 10:46, Martijn Brinkers said:

> I actually spend a lot of time investigating the impact of EFAIL on
> S/MIME and it's my opinion that the real impact has been overblown. In
> all my experiments, and I can tell you I have done a lot of them, I have
> not been able to force a mail client to actually forward the decrypted
> content to a remote system.

I recall that you mentioned this in the past and I have not seen any
statement to the contrary.  In fact the whole attack is nearly 20 years
old and even back then it was hard to construct a case where the
non-authenticated encryption could be abused.  When the PGP folks and me
discussed the attack around the year 2000, we knew that and suggested
signed mails as a solid counter-measurement.  The MDC was then
introduced mainly to counter the more or less theoretical attack and to
be on the safe side in case better attacks would be developed.

The media and political coverage (we had working groups and internal
meetings) of the efail paper however required some extra measurements to
take.

> I think the problem with the paper was that they discusses two separate
> issues. The issue with Efail-2 was serious but that was more an mail
> client issue.

I fully agree here.  As usual reports about the MUA failures spread for
months without mentioning that all the major MUAs fixed the bug within a
few days or weeks or even had fixed it at the time the paper was
published.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: are angle brackets around email address allowed for auto-key-locate?

[Werner Koch via Gnupg-users]

On Tue, 15 Oct 2019 22:23, David Hebbeker said:
> The manual [1] says that GnuPG can automatically retrieve keys for
> emails in the "u...@example.com" form. Does this exclude emails wrapped
> by angle brackets like ""?

That is fine.  Find below our test addresses.


Salam-Shalom,

   Werner



ps.
Here is our test data set. The second string is the exepcted result, if
it is NULL we can't extract a mail address from the string:

  { "Werner Koch ", "w...@gnupg.org" },
  { "", "w...@gnupg.org" },
  { "w...@gnupg.org", "w...@gnupg.org" },
  { "w...@gnupg.org ", NULL },
  { " w...@gnupg.org", NULL },
  { "Werner Koch (test) ", "w...@gnupg.org" },
  { "Werner Koch  (test)", "w...@gnupg.org" },
  { "Werner Koch ", NULL },
  { "Werner Koch ", NULL },
  { "", "f...@example.org" },
  { "", "f...@example.org" },
  { "<.f...@example.org>", ".f...@example.org" },
  { "", "fo...@example.org" },
  { "", "foo.@example.org" },
  { "", NULL },
  { "", NULL },
  { "", NULL },
  { "<@example.org>", NULL },
  { "", NULL },
  { "<@f...@example.org>", NULL },
  { " ()", "f...@example.org" },
  { " ()", "fo()o...@example.org" },
  { " ()", "fo()o...@example.org" },
  { "fo()o...@example.org", NULL},
  { "Mr. Foo ", "f...@example.org"},
  { "Surname, Forename | company ", "f...@example.org"},
  /* The next one is for sure not RFC-822 correct but nevertheless
   * the way gpg does it.  We won't change it because the user-id
   * is only rfc-822 alike and not compliant (think only of our
   * utf-8 requirement).  */
  { "\"\" ", "f...@example.org"},

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: libgcrypt license

[Werner Koch via Gnupg-users]

On Tue, 22 Oct 2019 12:27, Fuse Hiroaki said:

> https://github.com/gpg/libgcrypt/commit/915570db198f2cf15db5c034096a444a8a79476e#diff-c55728a8e1162a431e4754734d27a041

I don't known what you found on github, which seems to be an inofficial
mirror of GnuPG (and I do not want to check that specific commit).
However, dumpsexp.c is indeed under the GPLv3.  There is no real reason
for this and we could change the license if that really makes a
difference for you.  You can also distribute without that debug helper.

> This mean that only dumpsexp is GPLv3?

I have not checked but in case you find another GPL tool, please let us
know via a feature request on our bug tracker.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Should gpg try to connect to TCP/993?

[Werner Koch via Gnupg-users]

On Fri, 25 Oct 2019 12:23, Jay Sulzberger said:

> Is the following correct:
>
>   When I use gpg to just encrypt or decrypt a file already on my
>   computer/OS's file system, then gpg does not open any formal
>   channels of communication going outside my computer/OS.

No.  By default gpg may go out for key discovery, CRLs, version checks
etc.  If you do not want this you can use the gpg option
--disable-dirmngr or, to be 100%, do not install dirmngr.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Question about symmetric AES cipher in GnuPG

[Werner Koch via Gnupg-users]

On Wed, 30 Oct 2019 17:19, Brian Minton said:

> My guess is, the gpg one also is doing MDC, so you'd have to add the
> equivalent HMAC code to openssl, but that's just a complete guess.  

The OpenPGP MDC is a SHA-1 hash appended to the plaintext and then
encrypted along with the data.  The usual OpenPGP packet structure is
used; details are in RFC-4880. Further OpenPGP's symmetric encryption
uses a random session key and encrypts that session key using the
passphrase as key.  This allows to have several independent passphrases
or public keys for the same data.

You can't easily implement that with OpenSSL in a script.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: How to decrypt a message while preserving the signature?

[Werner Koch via Gnupg-users]

On Sun,  3 Nov 2019 10:15, Peter Lebbing said:

>> --unwrap is not documented and has the minor problem that it also keeps the
>> compression layer.  However, gpgv groks that compression layer and works

I'll document it for future releases.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: encrypt file in batch mode

[Werner Koch via Gnupg-users]

On Sun,  3 Nov 2019 08:31, Fourhundred Thecat said:

> $ gpg --list-secret-keys
> gpg: can't connect to the agent: No such file or directory
> gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory

Your system is not properly installed.  It is missing the gpg-agent
which is a mandatory part of GnuPG.  Except for some esoteric commands
there is no way to use gpg without gpg-agent.  The gpg-agent is used for
private keys as well as to provide a couple of other information like a
useful iteration count for the S2K mechanism.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: gpg-agent only checks for smartcard not for local keys

[Werner Koch via Gnupg-users]

On Sat,  2 Nov 2019 12:20, Horst Skatmus said:

> I do not understand how the gpg-agent determines where to look for the
> private key (disk or smartcard) and where this is configured. I can switch
> off the scdaemon via --disable-scdaemon but this has no effect.

At the time you use ssh-add (putty has a similar feature iirc) the key
is copied to GnuPG's private key store and added to the file sshcontrol
in GnuPG home directory ("gpgconf --list-dirs" shows this).

You can add the key also manuualy to the file.  An entry there looks
like:

  # Ed25519 key added on: 2016-11-29 10:28:00
  # MD5 Fingerprint:  b5:f9:23:5f:b2:8c:b2:58:7d:b3:1e:f4:7e:26:33:7c
  1934563577D9EDA59D3CC74B0CF9C630EA3F302D 0

The header of the sshcontrol file has comments on the syntax.
In short you put the keygrip (as show in the KEYINFO lines or in
"gpg -k --with-keygrip") followed by the TTL for the cache
(0 for the default).

gpg-agend access the smartcard because the authenticstion key of an
inserted card is implicitly enabled for ssh.  Which key this is depends
on the card and gpg-agent knows how to query this.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: encrypt file in batch mode

[Werner Koch via Gnupg-users]

On Mon,  4 Nov 2019 16:49, Fourhundred Thecat said:

> Yes, that is exactly the problem. Why should simple operations require
> gpg agent ?

The manual has a chapter on the architecture, please read it to
understand the design goals and how it was implemented nearly 20 years
ago.

> Imagine the authors of "cat" or "ls" decided that these utilities no

Separation of duties is an important part of the Unix philosophy.  Thus
we use gpg-agent to handle the operations which require private keys and
also for some minor things which benefit from being implemented in a
daemon.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: BSI withdraws approval of GnuPG (revisited after 3 month)

[Werner Koch via Gnupg-users]

On Mon,  4 Nov 2019 08:58, karel-v_g--- said:

> In a message to this list on August 8th Werner Koch said he is
> permanent contact with BSI and the reason for the withdrawal is in the
> OpenPGP part of GnuPG. Once again no further details were
> provided. [4]

We received a new approval BSI-VS-10400 dated Sep 9.  We have not yet
announced this widely except for a short notice at gnupg.com.  The
reason for this that we are still waiting for the promised
"Freigabeempfehlung" for the OpenPGP part.  That is a kind of approval
which allows to use OpenPGP without a smartcard.  Without such a
Freigabeempfehlung the public might have get the false idea that
the OpenPGP part is not secure.  But now, that you asked I better
explain what I know.

There seem to be different opinions at the BSI on whether a smartcard
should be mandatory for use with VS-NfD.  The whole thing is not a
technical issue but a pure political/organizational thing.  In fact the
current software used for VS-NfD (Chiasmus) does not use any smartcards
but a plain old proprietary 64 bit block length symmetric algorithms.
Users of VS-NfD are eagerly waiting for an easy migration path from that
legacy software to GnuPG (Gpg4win/Gpg4KDE).

> Should we consider our data protected by GnuPG insecure as german
> authorities obviously do?

No they don't.  They even use Gpg4win and GnuPG in house.

> Can or must we take any steps to eliminate or at least mitigate the
> problem in the current modern (2.2.17) and classic 1.4.23) versions of
> GnuPG (e.g. avoid compatibility options like —openpgp)?

Nope.  All is fine and Gpg4win may be used for VS-Nfd if the SecOPs are
followed (e.g a Telesec NetKey 3.0 card is used for the S/MIME keys)

> Is it a problem only with GnuPG or with OpenPGP in general? Are other
> implementations affected as well?

No, there is no bug or issue except for the slow grinding bureaucratic
mills to get an approval for the OpenPGP and S/MIME without a smartcard.



Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: BSI withdraws approval of GnuPG (revisited after 3 month)

[Werner Koch via Gnupg-users]

On Mon,  4 Nov 2019 12:39, Art Silva said:

> What do they approve for securing data of higher security classifications?

There is a public list at:




Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: BSI withdraws approval of GnuPG (revisited after 3 month)

[Werner Koch via Gnupg-users]

On Mon,  4 Nov 2019 11:40, Robert J. Hansen said:

> requirements.  This could be as simple as, "we prohibit the use of 3DES,
> but OpenPGP lists it as a MUST algorithm".

It is even less technical see my other mail.

FWIW, GnuPG knows all allowed algorithms for the VS-NfD use case and can
be switched into a mode where this is enforced (for creating message) or
indicated with a warning (for reading a message).

  $ gpg --compliance=help
  gpg: valid values for option '--compliance':
  gpg:   gnupg
  gpg:   openpgp
  gpg:   rfc4880bis
  gpg:   rfc4880
  gpg:   rfc2440
  gpg:   pgp6
  gpg:   pgp7
  gpg:   pgp8
  gpg:   de-vs
  
Thus when VS-NfD is required the admin will configure gpg and gpgsm with
--compliance=de-vs.  Actually Kleopatra and GpgOL have GUI elements to
enable/show that mode.  One thing which sets us apart from other VS-NfD
products is that the very same software can be used for regular mail and
VS-NfD processing without switching.  The user experience is thus better
aligned to the real world use.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: encrypt file in batch mode

[Werner Koch via Gnupg-users]

On Mon,  4 Nov 2019 18:10, Tony Lane said:

> was made with the unix philosophy in mind. Perhaps it would've been
> better to write the gpg-agent as a shared library to be called by the
> core instead. Well, we're probably too far down down the rabbit hole

The process boundary has security advantages and is one of the reasons
why this is not just a shared library.  Or why gpg is not a shared
library itself.  By splitting GnuPG into an OpenPGP part (gpg) and a
private key handling part (gpg-agent) we have a couple of benefits:

- We reduce the amount of code and of linked other shared libraries which
  come in touch with the sensitive private key material.
- The gpg-agent does not need to care about the complicated OpenPGP
  protocol (or gpgsm not about the more complicated CMS/X.509 protocol).
- No user interface required.
- Exploitable bugs in gpg must not immediately compromise private keys.
- We can can store/cache data in memory and do not need to load and
  process it each time.  A shared library won't allow this.  The cache
  is even encrypted so that we could extend it to store that encryption
  key in some kind of secure element to limit the expose of that key and
  thus the cache.
- Auditing the code and reasoning about the operation it is much easier
  given the well defined interface between the modules.
- Using SELinux or similar systems allows to run the gpg-agent in a mode
  where only gpg-agent may access the files storing the private keys.
- The gpg-agent could be run under a different uid and this way take
  advantage of the even stronger uid separation of most OSes.
- The gpg-agent can be run on an entirely different machine and thus
  work similar to a HSM.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: gpg-agent SSH agent returned incorrect signature type

[Werner Koch via Gnupg-users]

On Tue,  5 Nov 2019 17:49, Sebastian Wiesinger said:

> debug3: sign_and_send_pubkey: signing using rsa-sha2-512

AFAICS that method is not supported.  We support "ssh-rsa" and
"ssh-rsa-cert-...@openssh.com" but not this method.  However, I do not
have the debug out of gpg-agent so I can't tell for sure.  Please put

--8<---cut here---start->8---
log-file /somewhere/gpg-agent.log
verbose
--8<---cut here---end--->8---


into ~/.gnupg/gpg-agent.conf and "gpgconf --kill gpg-agent".  In case
this reveals nothing it may be nessary to add a line "debug crypto" but
that would reveal key material if not only used with the Yubikey.

Anyway, I would suggest to use an EC algorithm; they are much faster.
The Yubikey only supports the NIST curves and thus ecdsa-sha2-nistp256
or ecdsa-sha2-nistp521 would be approriate.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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