Re: Application deadlock when using GnuPG, gpgsm, and Scute

[Damien Goutte-Gattat via Gnupg-users]

On Sunday, 9 April 2023 20:13:46 BST John Scott via Gnupg-users wrote:
> You're a genius!

Hardly. :D


> I actually had a hard time getting Scute 1.7.0 to compile, so I built it from 
> Git instead

If you have some time to spare I’d be interested to know which problem(s) you 
ran into when trying to compile Scute 1.7.0.

Building from a release tarball is supposed to be easier than building from a 
Git checkout after all!


> and everything worked flawlessly! I was even able to sign a PDF :)

Glad to read that!

Best,

- Damien

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

Re: Application deadlock when using GnuPG, gpgsm, and Scute

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Sunday, 9 April 2023 03:35:18 BST John Scott via Gnupg-users wrote:
> Note that GnuPG 2.3 is not available in Debian, not even in Debian 
> experimental yet, but as soon as the packagers provide it I will give it a 
> try. Perhaps I'll install GnuPG 2.3 myself in /usr/local

Note also that according to packages.debian.org [1], the latest version of 
Scute available in Debian, even in Sid, is still 1.5.0. That version is six 
years old. If you don’t mind compiling and installing GnuPG ≥ 2.3 yourself you 
should also try installing Scute 1.7.0.

- Damien

[1] https://packages.debian.org/source/sid/scute


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

Re: Safest Way to get GPG

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Friday, 18 November 2022 02:35:24 GMT Michaela Tilson via Gnupg-users wrote:
> I'm looking forward to updated advice from security experts on this. What is 
> the safest/most reliable way to get GnuPG as a command line application on 
> macOS?

Not pretending to be any kind of security expert, but on my professional Mac, I 
use MacPorts, with a custom copy of the ports repository where I upgraded 
gnupg2 to the latest release from the 2.3 branch.


> GPG Tools is most often recommended, but this may be due to GUI integration. 
> Its drawback is that it offers the LTS instead of the stable version.

I _also_ use GPG Tools, but _solely_ for the Apple Mail plugin. The plugin uses 
the MacPorts-installed GnuPG binaries and daemons instead of those from GPG 
Tools, so I can benefit from the 2.3 branch.


> But I've read that even popular package managers are prone to supply chain 
> attacks if they don't ship with the OS itself.

As mentioned above, I have a local clone of the ports repository and I install 
my ports from there. I did that for GnuPG primarily so that I could bump the 
version from 2.2.x to 2.3.x, but even if you don’t change anything to the ports 
tree, having it locally on your machine allows you to manually inspect any 
Portfile – in particular, you can check the hashes for the source tarballs, and 
compare them with the hashes from the GnuPG website and/or from the latest 
announcement e-mail.

(And if you already have access to a working GnuPG installation somewhere – on 
another machine maybe? –, you can then download the GnuPG tarballs from 
gnupg.org along with the corresponding signatures, check the signatures, and 
compute the hashes yourself on the now verified tarballs. Then compare with the 
hashes in the Portfiles.)

Hope that helps!

- Damien

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

Re: Read random bytes from Gnuk potentially frequently without destroying the card

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Sunday, 20 November 2022 04:59:32 GMT John Scott via Gnupg-users wrote:
> I'd like to try writing a program for my libreCMC router that feeds the
> Linux entropy pool with data from the token's true RNG.

FYI, I wrote a similar program a few years ago: scdrand [1]. It uses
Scdaemon’s RANDOM command to extract random bytes from any Scdaemon-supported
token (be it a Gnuk token, an actual smartcard, a Yubikey, etc.) and feed them
to the kernel’s entropy pool.

I am not really using it anymore because I found that I had no longer any need
for it with recent Linux kernels, but it should still work.

Of course, this should not dissuade you from writing your own program. :)


> I also notice that OpenSC has the feature to get an arbitrary number of
> random bytes from the card with its OpenPGP module […] does this
> probably use the same mechanism under-the-hood

Yes. Both Scdaemon’s RANDOM and pkcs11-tool’s --generate-random work by
sending the token a ISO7816 "GET CHALLENGE" command, which instructs the token
to send back random bytes.

Whether “excessive use” of that command end up damaging the token, and what is
“excessive use”, ultimately depends on how that command is implemented
token-side.

In the specific case of the Gnuk token, the GET CHALLENGE command is
implemented using the same logic as the one used in NeuG [2]. I have not
looked in details how NeuG works, but given that it is specifically intended
as a random number generator, I’d say it’s safe to assume than using it as
intended cannot ”destroy the token”. :)

Hope that helps.

- Damien

[1] https://git.incenp.org/damien/scdtools
[2] https://www.gniibe.org/memo/development/gnuk/rng/neug.html



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

Re: gpg-agent not working properly

[Damien Goutte-Gattat via Gnupg-users]

Hi

On Friday, 23 September 2022 12:01:18 BST Tsilimigkras Athanasios wrote: 
> MY QUESTION: is there any way of changing the settings on GPGv2.2.4 to allow
> this environment variable to be set and therefore allow passwords to be
> cached as in earlier versions?

No. But if you are using other programs that depend on that variable being
present (such as SVN), you can easily set that variable yourself:

export GPG_AGENT_INFO=$(gpgconf --list-dirs agent-socket)::

Which version of SVN are you using, though? Because recent versions seem to
have been updated to look for GnuPG Agent’s socket at the correct places in
the absence of the GPG_AGENT_INFO variable.

- Damien

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

Re: Status of original PGP?

[Damien Goutte-Gattat via Gnupg-users]

On Wednesday, 7 September 2022 23:09:54 BST Robert J. Hansen via Gnupg-users 
wrote:
> Does anyone know what happened to PGP?

It is *supposedly* still available from Broadcom, under the name “Symantec
Desktop Email Protection” [1].

How you can *actually* get it is another question. My understanding is that
you first need to buy a licence from one of Broadcom’s partners, then get
your licence number [2], and then finally download the software [3].


> My interest in this is purely historical.

I had a somewhat similar interest a while ago. I was trying to find some
technical details about the current version of PGP – e.g., which algorithms
does it support? Did they implement ECC keys? If so, which curves? etc.

I was never able to find this kind of information…

- Damien


[1] https://www.broadcom.com/products/advanced-threat-protection/encryption
[2] https://knowledge.broadcom.com/external/article/206503
[3] https://knowledge.broadcom.com/external/article/193931

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

Re: SSH_AUTH_SOCK - to set or not to set?

[Damien Goutte-Gattat via Gnupg-users]

On Wednesday, 22 June 2022 17:34:45 BST theaetetos--- via Gnupg-users wrote:
> unset SSH_AGENT_PID
> if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
> export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
> fi
> 
> I don't understand the condition being checked, but I gather the whole
> thing is simply a more robust version of my ~/.profile two-liner.

Yes. `gnupg_SSH_AUTH_SOCK_by` is set by the agent at the same time as 
`SSH_AUTH_SOCK`. By checking that variable instead of `SSH_AUTH_SOCK` 
directly, you avoid the case where `SSH_AUTH_SOCK` has already (incorrectly) 
been set by something else (for example by an earlier profile script).

The `gpgconf` thing is to make sure `SSH_AUTH_SOCK` is always set to the 
correct path, because you should not assume the socket will always be in 
GnuPG’s home directory. With modern GnuPG versions it is normally somewhere 
under [/var]/run.


> Meanwhile, the first sentence of the gpg-agent(1) man page for the
> --enable-ssh-support option,which I set in my gpg-agent.conf, tells
> us: The OpenSSH Agent protocol is always enabled, but gpg-agent will
> only set the SSH_AUTH_SOCK variable if this flag is given.
> 
> So should 'SSH_AUTH_SOCK' be set by the user or can gpg-agent indeed
> take care of that?

In most cases you should set `SSH_AUTH_SOCK` yourself in your profile script.

There are two cases where the sentence you are referring to in gpg-agent(1) is 
relevant:

1) You use gpg-agent to spawn a new program (e.g. a shell):

  $ gpg-agent --enable-ssh-support --daemon /bin/sh

In that case, the agent will take care of exporting `SSH_AUTH_SOCK` before 
spawning the shell, so it does not need to be done in the shell’s profile 
script.


2) You invoke gpg-agent in a profile script like this:

  eval $(gpg-agent --sh --enable-ssh-support daemon)

In this case, the agent will print to stdout the appropriate `export 
SSH_AUTH_SOCK` stanza, which will then be evaluated by the `eval` command, 
resulting in the variable being exported in the shell’s environment.

This used to be a pretty standard way of both starting the agent *and* making 
sure the environment variables SSH_AUTH_SOCK and GPG_AGENT_INFO were set, back 
in the times before the start-on-demand mechanism was devised.

Nowadays, with the start-on-demand mechanism (which made GPG_AGENT_INFO 
obsolete), I don’t think there’s any compelling reason to still use that 
method, but it’s still there.

Hope that helps,

- Damien

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

Re: Questions re auto-key-locate

[Damien Goutte-Gattat via Gnupg-users]

On Tuesday, 15 February 2022 20:32:50 GMT Dan Mahoney (Gushi) via Gnupg-users 
wrote:
> Worse still, if you know a key exists via something like DANE (dayjob
> makes DNS software, we like the idea of it being available via DANE),
> there's no way to do gpg --search via DANE, only via a keyserver.
> 
> Thus, using that as a prefetch method to grab the current version of our
> codesign@ key into our keyring is not helpful either, unless we "faked it"
> by attempting to encrypt a message to that address, then discarded it.
> 
> Is there another way forward?  The normal things for auto-key-locate don't
> seem to help here.  I'm open to ideas.

Unless I misunderstood what you’re trying to achieve, I think the `--locate-
external-keys` command should be what you’re looking for?

This is basically the equivalent of `--search-keys`, except that the search is 
not limited to keyservers but instead use the mechanisms configured via the 
`--auto-key-locate` option (which can include DNS lookups, either using the 
“historical“ method of RFC-4398, or the modern method of RFC-7929).

- Damien


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

Re: Using gpgsm+scute with p11tool

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Mon, Nov 08, 2021 at 02:45:53PM +1000, Stuart Longland via Gnupg-users wrote:

The HTTP request I need to perform is this one:
https://www.vaultproject.io/docs/auth/cert#via-the-api

I tried using Firefox, it can see the certificate presented by `scute`,
but it seems Vault isn't designed to authenticate clients that way as
best I can tell.


As long as the server allows certificate-based client authentication, it 
shouldn’t matter to the server that you are using Scute (or any other 
way to store your certificate) at your end.


However, usage of Scute + Firefox seems broken with TLS 1.3. In my case, 
it works perfectly fine if I force Firefox to use TLS 1.2 
(security.tls.version.max = 3 in about:config), but systematically fails 
when TLS 1.3 is enabled.


I am not sure about the root cause of the failure with TLS 1.3, or even 
if the root cause is in Scute itself or in Firefox.


Could you try temporarily disable TLS 1.3 and try again? If it works 
with TLS 1.2 only, this would suggest you are running into the same 
problem as me.




If I try doing the same with `scute`, I get nothing:

$ p11tool --provider=/usr/lib64/pkcs11/scute.so --list-tokens

Consequently, I have no idea what hardware token URI to supply to
`curl` when authenticating.

Is there some trick needed to get `scute` to tell me what tokens are
present or how to find out what the URL of my private key is?


I would need to look at how is p11tool generating its output, but I 
suspect it may be using some PKCS#11 functions that Scute does not 
currently implement.


- Damien



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

Re: What are the file in ~/.gnupg ?

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Fri, Oct 29, 2021 at 04:04:11PM +0200, Romain LT via Gnupg-users wrote:

dirmngr.conf :
configuration for dirmngr (keyserver access)


Dirmngr is also used for fetching the Certificate Revocation Lists 
(CRLs), if you’re using GpgSM (the X.509/SMIME part of GnuPG).




crls.d/DIR.txt



This is where dirmngr stores the aforementioned CRLs. The DIR.txt file 
acts as a kind of index for the CRLs that are cached in that folder. It 
is normal for that folder to be empty (save for the DIR.txt file) if you 
don’t use GpgSM.




openpgp-revocs.d/
folder to store revocs certificates (for my own keys ?)


Yes. This is where Gpg writes out the revocation certificate it 
automatically generates upon creating a new key.



should I store certificates in this waiting for the moment my keys are 
compromised ?)


That is ultimately dependent on your threat model. Keep in mind that, 
contrary to your private key, the revocation certificate is *not* 
passphrase-protected (whoever manages to grab it can use it to revoke 
your key without needing anything else). That may be reason enough to 
want to move it offline, elsewhere than on your computer, instead of 
leaving it in the openpgp-revocs.d folder.




private-keys-v1.d/
folder with private keys files, named afte key or subkey keygrip
Is there only the private key part of my own keys in this ? or
is there a way to obtain public+private key from one of those
files ?


Private key only. I believe the purely “mathematical” components of the 
public key can be derived from it (though I may be wrong here), but that 
does not include the User IDs and associated signatures, that are 
necessary to make a ”full” public key – those components are in 
pubring.kbx.




tofu.db
is an sqlite database and mean Trust On First Use. But what does
it means and what does it contains ?


TOFU is a new (or not so new anymore, it has been introduced in 2015 or 
so) trust model, that can either replace the web of trust or be used in 
combination with the web of trust.


The TOFU database is what allows GnuPG to keep track of which email 
address a given key is associated with, so that it can detect any future 
mismatch (which could be a sign that a MITM attack is under way).




trustdb.gpg
the "trust database" which seem to be usefull for web of trust.
The doc says to not backup this file. Why, and why did it
contains, and what is it for ?


This is indeed the database for the web of trust. It contains the 
ownertrust value you assigned to the public keys of you keyring. (The 
“onwertrust value” is when you state how much you trust the owner of a 
key to sign other people’s keys.) In the web-of-trust model, GnuPG uses 
the ownertrust values combined with key signatures to decide whether a 
public key in your keyring is valid.


Those values should be backed up (unless you don’t mind manually 
re-assigning ownertrust values for all the keys you trust if you come to 
lose the trustdb.gpg file). The current manual page says:


  There is no need to backup this file; it is better to backup the 
  ownertrust values (see option --export-ownertrust).


This is not intended to mean the trustdb.gpg file is worthless, merely 
that its contents should be backed up using the --export-ownertrust 
command instead of simply doing a file-level backup:


  gpg --export-ownertrust > ownertrust.backup
  # to restore
  gpg --import-ownertrust < ownertrust.backup


Hope that helps,

- Damien


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

Re: gpg and TPM

[Damien Goutte-Gattat via Gnupg-users]

On Tue, May 11, 2021 at 02:03:21PM +, mailinglis...@posteo.de wrote:

I´m not that familiar with the TPM in general


Me neither.


is the TPM owner (and SRK) password safe against brute force attacks? 
Or do you need a complex password for the TPM?


My understanding is that the TPM offers the *possibility* to protect 
against brute force attacks (through the “dictionary attack lockout 
reset” mechanism), but I am not sure whether that protection is enabled 
by default or if the tpm2daemon (the new component within GnuPG in 
charge of using the TPM) makes use of it.


Until I know more, I use with my TPM stronger PINs than what I normally 
use with my OpenPGP tokens, just in case. :)


- Damien


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

Re: gpg and TPM

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Sun, May 09, 2021 at 10:00:25AM +, mailinglisten--- via Gnupg-users 
wrote:

I wasn´t aware the TPM has that much space, does the TPM hold really a
complete key? Does it make sense to use ECC keys to save space on the TPM?


Keys are actually not stored *in* the TPM. When you use the `keytotpm` 
command, the key is encrypted in such a way that it can only be 
decrypted and used by the TPM, but the key is still stored, in this 
encrypted form, as a file under the $GNUPGHOME/private-keys-v1.d 
directory.


So there's no need to switch to ECC keys just to “save space on the 
TPM”. You can protect as many RSA keys as you want with the TPM without 
being constrained by space.


- Damien


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

Re: GnuPG 2.3.0: AEAD - no GCM-Mode?

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Sun, Apr 11, 2021 at 10:07:08PM +0200, karel-v_g--- via Gnupg-users wrote:

Another question: why donˋt you use GCM as a possible mode for AEAD?


This kind of questions should rather go to the IETF OpenPGP mailing list 
[1], where the OpenPGP format iself (not its implementations) is 
discussed.


The option of using GCM in particular *has* been discussed, but there 
was no consensus for it. If anything, there was almost a consensus 
*against* GCM [2,3].




It seems to be the most common nowadays


My understanding (from following the discussion in the WG at the time) 
was that people have been using GCM mostly because they could not or did 
not want to use OCB.  Now that OCB is no longer encumbered by patents, 
there may not be an interest in GCM anymore.


- Damien


[1] https://www.ietf.org/mailman/listinfo/openpgp
[2] 
https://mailarchive.ietf.org/arch/msg/openpgp/V4ND7Dcx8MG6oNnYbUntaX8cbzM/
[3] 
https://mailarchive.ietf.org/arch/msg/openpgp/fsxXaDD3SkZuktQ7yl22jHioDKw/


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

[Announce] Pinentry 1.1.1 released

[Damien Goutte-Gattat via Gnupg-users]

Hi,

The GnuPG project is pleased to announce the availability of the latest 
release of the collection of PIN or passphrase entry dialogs for GnuPG, 
Pinentry 1.1.1.



Noteworthy changes in version 1.1.1 (2021-01-21)
===

* A Pinentry for the Enlightenment environment is available.

* In the GTK, QT, TQt, and curses pinentries, echoing can be disabled by 
pressing the backspace key prior to any other input.


* The TTY pinentry now supports line editing.

* The GTK pinentry now requires GTK+ 2.12.0 or a later version.


Download


Source code is hosted at the GnuPG FTP server and its mirrors as listed 
on <https://gnupg.org/download/mirrors.html>.  On the primary server the 
source tarball and its signature are:


  ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-1.1.1.tar.bz2
  ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-1.1.1.tar.bz2.sig

The same files are also available via HTTP:

  https://gnupg.org/ftp/gcrypt/pinentry/pinentry-1.1.1.tar.bz2
  https://gnupg.org/ftp/gcrypt/pinentry/pinentry-1.1.1.tar.bz2.sig


Signing keys


The tarball is signed by the following keys:

pub  rsa4096 2014-03-14 [SC]
 Key fingerprint = 4FA2 0823 62FE 73AD 03B8 8830 A8DC 7067 E25F BABB
uid  Damien Goutte-Gattat 

pub  ed25519 3030-08-24 [SC] [expires: 2030-06-30]
 Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA
uid  Werner Koch (dist signing key 2020)

The first of those keys is available via a WKD lookup:

  $ gpg --locate-key dgouttegat...@incenp.org

The second is available in https://gnupg.org/signature_key.html and in 
any recently released GnuPG tarball in the file g10/distsigkey.gpg.



Copying
===

Pinentry is copyright by g10 Code GmbH and licensed under the GNU 
General Public License version 2 or later (GPL-2.0+). The full text of 
the license is included in the COPYING file of the source distribution.



Support
===

The Pinentry manual is included in the source distribution in TeXinfo 
format. For community support, you may ask on the gnupg-users mailing 
list <https://lists.gnupg.org/mailman/listinfo/gnupg-users>.


If you need commercial support, check out 
<https://gnupg.org/service.html>.


Maintenance and development of Pinentry and of GnuPG as a whole is 
mostly financed by donations. Please consider donating via 
<https://gnupg.org/donate/>.


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

Re: WKD proper behavior on fetch error

[Damien Goutte-Gattat via Gnupg-users]

On Sun, Jan 17, 2021 at 06:53:29PM +0100, Erich Eckner via Gnupg-users wrote:
And I assume, it's non-trivial or even impossible to start proper DNS 
queries (for a SRV record) from within JS?


Apparently not, at least that what folks on the IETF openpgp mailing 
lists said when the issue had been debated [1].


That’s why the WKD protocol (which *used* to rely on SRV records to 
provide a level of indirection between the domain name and the WKD 
server, which was The Right Thing™ do to) had to drop the SRV records in 
favor of a fixed subdomain, at the demand of Javascript developers.




Because it seems to me, the root for this debate is in gnupg's "ab"use 
of a subdomain for something which should actually be a SRV record. 


Given that this “abuse” was almost forced upon GnuPG developers by JS 
developers who basically said “please change your protocol otherwise 
there’s no way I can implement it”, and that Werner was on the record 
reluctant to the change [2], I find it quite disheartening that the 
blame should be put at GnuPG’s feet. :(


Oh well, all problems in the OpenPGP world are GnuPG’s fault anyway. It 
is known.



- Damien

[1] 
https://mailarchive.ietf.org/arch/msg/openpgp/f6V8W9wKY6dt2wAq4FBOWk8wtos/


[2] 
https://mailarchive.ietf.org/arch/msg/openpgp/SH1dzlERTgJsaCoKvxQGsnckq-w/


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

Re: WKD for GitHub pages

[Damien Goutte-Gattat via Gnupg-users]

On Tue, Jan 12, 2021 at 09:25:15AM +0100, Stefan Claas via Gnupg-users 
wrote:

It would be nice to know why the advanced method was added.


To give more flexibility for people setting up a WKD for more than one 
domain.


Let’s say that I manage example.org and example.net, and I want to serve 
keys for addresses in both domains. With the “direct” method, I need to 
set up two distinct WKD servers, one for each domain. With the 
“advanced” method, I can set up a single server and make 
openpgpkey.example.org and openpgpkey.example.net point to that single 
server.


(SRV records would be the modern and proper way to provide such a level 
of indirection, instead of a subdomain. And indeed, previous versions of 
the WKD draft relied on SRV records. Unfortunately, resolving SRV 
records was problematic for some implementers using some limited 
languages with limited DNS capabilities, so they were scrapped in favor 
of the subdomain approach.)




the direct method would not be sufficent or would have security issues
I would think that than one replaces the direct method with advanced
one and then we only need only one method, in order that this works.


If you have only one domain to manage and don’t need the indirection 
provided by the advanced method, the direct method is still perfectly 
fine, why replace it?



And if we must have two methods, why is the order not, like one would
think: check direct first and if this does not work check advanced?


I don’t know, it feels more logical to me to look for an indirection 
*first*, and only if there’s no indirection you then look at the target 
domain itself.



- Damien


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

Re: WKD question

[Damien Goutte-Gattat via Gnupg-users]

On Mon, Jul 27, 2020 at 10:00:07PM +0200, Stefan Claas wrote:

For testing my new Nitrokey I have just install Enigmail for
Thunderbird on a fresh Ubuntu system and when clicking on
a signed message from a friend, which has properly set-up
WKD Thunderbird/Enigmail can not fetch the pub key. :-(


Unless I missed something, I believe Enigmail will only attempt to 
automatically fetch a key from a Web Key Directory when *composing* a 
message (if there’s no key for the recipient in the local keyring), and 
*not* when checking a signature on a received message.


See that excerpt from Enigmail 2.0 changelog [1]:

Support for Web Key Directory (WKD) is implemented. Enigmail will try 
to download unavailable keys during message composition from WKD.



You can force GnuPG to try to fetch a missing key when verifying a 
signature by enabling the --auto-key-retrieve option (please read the 
note about the “web bug” in gpg’s man page before doing so—that option 
is disabled by default for a reason.)



Regards,

- Damien


[1] https://enigmail.net/index.php/en/download/changelog


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

Re: Backup of Keys

[Damien Goutte-Gattat via Gnupg-users]

On Sat, May 23, 2020 at 09:35:54PM -0700, Mark wrote:

I'm sure this is a pretty stupid question


No, it’s not.


I'm trying to figure out which files I need to backup to safeguard my 
keys.


I’m assuming you are using GnuPG 2.2 on Windows here (based on your 
User-Agent).


Everything that needs to be saved is in GnuPG’s home directory, which on 
Windows should be `C:\Documents and Settings\\Application 
Data\gnupg`. In that folder you should save:


* the private keys (in the `private-keys-v1.d` subfolder;
* the public keys (the `pubring.kbx` file);
* the trust data (the `trustdb.gpg` file, plus the `tofu.db` file of you 
are using the TOFU trust model);

* any configuration file (`*.conf`);
* if you are using GpgSM, the `policies.txt` and `trustlist.txt` files.

For the private and public keys however, instead of saving the files 
directly I’d recommend exporting them from GnuPG:


% gpg -o private-keys.gpg --export-secret-keys
% gpg -o public-keys.gpg  --export

The rationale for doing so is that the exported files are in the 
standard OpenPGP format, from which you can re-import them without 
worrying about changes from one GnuPG version to another. To restore:


% gpg --import private-keys.gpg
% gpg --import public-keys.gpg

(You can also do that with a graphical interface, of course.)

Of note, there is also a much simpler option which could replace 
everything above: use the Sherpa tool [1], which does exactly what you 
need. It backs up a complete GnuPG profile into an archive and later 
allows you to restore it. Do mind the warning about Sherpa not being 
“ready for regular users”, though. For what it’s worth, I’ve used it a 
few times and never had any issues with it.


Hope that helps,

- Damien


[1] https://github.com/rjhansen/sherpa


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

Re: keys require a user-id

[Damien Goutte-Gattat via Gnupg-users]

On Sat, May 16, 2020 at 04:28:58PM -0400, Robert J. Hansen wrote:
With judicious use of the various -clean options, the key spamming bug 
is effectively dead...


I’d like to point out that the options you are referring to are actually 
enabled by default nowadays (since 2.2.17). So from an user’s point of 
view, the judicious thing to do is simply to use the latest GnuPG 
version available.


I am pointing that out because people could interpret your comment as 
meaning that GnuPG requires some tinkering of its options in order to be 
safely usable with regard to the SKS spamming issue. That’s not the 
case; the default configuration is fine.


- Damien


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

Re: Comparison of RSA vs elliptical keys

[Damien Goutte-Gattat via Gnupg-users]

On Wed, May 13, 2020 at 10:02:14AM +0200, Sylvain Besençon via Gnupg-users 
wrote:
RJH's answer sounds like a good piece of advice, but still, at the end, 
we HAVE to to choose which algorithm to use when creating new key 
pairs.


No you don’t.

You can simply use `gpg --gen-key` and let GnuPG create a keypair with 
the default algorithm (which is currently RSA 2048). Only if you call 
GnuPG with the `--full-gen-key` command will you be asked to explicitly 
choose which type of key of want.



I am not sure to fully grasp the consequences of this... Does that mean 
that, if I use Curve 25519, some people won't be able to use my public 
key to encrypt stuff?


If their software does not support Curve 25519, yes.


Or does that mean that some people won't be able to read or verify 
stuff that I encrypt and signs?


You encrypt messages to your correspondants with *their* public keys, so 
the type of *your* key does not matter for that purpose. But they won’t 
be able to verify your signatures.



Would it be because they use older versions or because some software 
programs don't implement Curve 25519?


Yes. That being said, most modern implementations do seem to support 
curve 25519. As far as I know, it is supported at the very least by


* GnuPG (≥ 2.1)
* OpenPGP.js
* Sequoia-PGP
* RNP

… which should already cover most of the OpenPGP user base. Of note, it 
is *not* supported by Symantec PGP, though [1].




I guess that Curve 25519 is mentioned in the IETF standard, isn't it?


Not yet. Officially, only the NIST P-256, P-384, and P-521 curves are 
part of the standard (since RFC 6637). The first mention of Curve 25519 
for OpenPGP was in a draft by Werner in 2014 [2]. The draft never made 
it to a RFC but the 25519 curve is now part of the draft for RFC4880bis, 
the next revision of the OpenPGP standard [3].



- Damien

[1] 
https://knowledge.broadcom.com/external/article/175932/encryption-desktop-cannot-import-ecc-pgp.html


[2] https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-00

[3] https://gitlab.com/openpgp-wg/rfc4880bis


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

Re: Performance of Yubikey fw >= 5.2.3 and Curve25519 in OpenPGP

[Damien Goutte-Gattat via Gnupg-users]

On Fri, May 08, 2020 at 12:49:03PM +0200, Grzegorz Kulewski wrote:
Does anybody here have Curve25519 enabled Yubikey and did/could do such 
benchmarks?


I have the following tokens:

* a Yubikey NEO with a RSA-2048 key;
* a Yubikey 5 with a Ed25519 key;
* a FST-01G/Gnuk token with a Ed25519 key.

I have not done any proper benchmark, but from my usage, my feeling is 
that the Yubikey 5 and the FST-01G have similar performances, and that 
they both outperform the Yubikey NEO with the RSA-2048 key.


A quick decryption test seems to confirm that impression:

* Yubikey NEO, RSA-2048: 0.795s ± 0.011s
* Yubikey 5, Ed25519:0.096s ± 0.005s
* FST-01G, Ed25519:  0.075s ± 0.006s

Note that the comparison between the RSA-2048 key on the Yubibey NEO and 
the Ed25519 key on the Yubikey 5 probably tells a lot more about the 
difference between the two generations of Yubikeys that it does about 
the difference between RSA and Ed25519. With the Yubikey NEO, even 
listing the card’s contents (with `gpg --card-status`) already takes 
~0.7s, compared to ~0.05s with the Yubikey 5.



- Damien


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

Re: Revoking a Lost Key

[Damien Goutte-Gattat via Gnupg-users]

On Wed, Feb 05, 2020 at 03:59:01PM -0700, Mark wrote:

Is there anyway to revoke an OLD LOST PGP key? I no longer have either
the public or private keys but can find the KeyID. I'm guessing not but
figured I'd ask just in case.


The revocation certificate needs to be signed by the private key, so 
without the private key it is indeed not possible.


It is possible to ask a third party to revoke your key in your stead, 
but only if you have previously made said third party a "designated 
revoker" (something that needs to be done in advance, when you still 
have the private key).


Since you cannot revoke, the only thing you may try is asking some of 
the people who certified your lost key (if any) to revoke their 
certification of your key.


Cheers,

- Damien


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

Re: private data objects on smartcard

[Damien Goutte-Gattat via Gnupg-users]

On Fri, Jan 31, 2020 at 12:55:05AM +0100, mailing list wrote:

I hoped these objects may have been (read) protected by the PIN, but
they´re world readable if you have the card, a bit sad...


Only Private DOs #1 and #2 are readable without any PIN. Reading the 
private DO #3 requires the user PIN, and reading the private DO #4 
requires the admin PIN.


If no PIN has been verified, the --card-status command will only ever 
print out the contents of private DOs #1 and #2.


While we are at it, *writing* to the private DOs #1 and #3 requires the 
user PIN, and writing to the private DOs #2 and #4 requires the admin 
PIN.


You can find the details about those DOs and all the other features of 
the OpenPGP smart card in the specifications for the different versions, 
which are all available on GnuPG's site [1].



Cheers,

- Damien


[1] https://gnupg.org/ftp/specs/


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

Re: private data objects on smartcard

[Damien Goutte-Gattat via Gnupg-users]

On Fri, Jan 31, 2020 at 12:39:11AM +0100, mailing list wrote:

By the way, is mcl3 the length of the key currently living on the
smartcard or the maximum key length supported by this card?


Neither of those. It's the maximum length of the "Cardholder certificate 
DO". This is another data object available on a OpenPGP smart card, 
intended to store a X.509 certificate.


You can write to that DO using the (undocumented) writecert command. For 
example, assumimg the cert.der file contains a DER-encoded X.509 
certificate:


 $ gpg --card-edit
 gpg/card> writecert 3 < cert.der

GnuPG allows to write into that DO but does not actually use it. As far 
as I know the only component that makes use of the Cardholder 
certificate DO is Scute [1], for TLS client authentication (and even for 
that the DO is actually dispensable: if Scute does not find the desired 
certificate in that DO, it will obtain it from GpgSM.)




I just play with a card version 1.1 and mcl3 is 0 there.


The Cardholder certificate DO was added in version 2.0 of the 
specification, so nothing surprising here.



Cheers,

- Damien


[1] http://scute.org/


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

Re: private data objects on smartcard

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Thu, Jan 30, 2020 at 11:24:54PM +0100, mailing list via Gnupg-users wrote:
How do you write to these objects? Can GnuPG do this? I didn´t found 
any way with --card-edit or --card-status.


You can use the (undocumented) command "privatedo" from GnuPG's 
--card-edit menu. For example, to write into the private DO #1:


 $ gpg --card-edit
 gpg/card> privatedo 1
 Private DO data: [enter whatever value you want to store into the DO]

Or, to write the contents of a file into the private DO #2:

 $ gpg --card-edit
 gpg/card> privatedo 2 < [filename]



And can GnuPG read these objects?


Yes. If a private DO contains a value, it will be listed in the output 
from the --card-status command.



I read somewhere, the size of these objects is 2048 bytes each. How 
many of these objects do exist on a smartcard?


First, note that private DOs are an optional feature of the OpenPGP 
smart card; not all implementations support them.


You can use the following command to check if an OpenPGP smart card 
supports private DOs:


 $ gpg-connect-agent 'SCD LEARN --force' /bye | grep EXTCAP
 S EXTCAP gc=1+ki=1+fc=1+pd=1+mcl3=2048+aac=1+sm=0+si=5+dec=0+bt=1+kdf=1

Here, "pd=1" means the card does have private DOs. "pd=0" would indicate 
that private DOs are not supported.


When private DOs are supported, there are four of them. For cards 
compatible with versions 1.x or 2.x of the specification, they have a 
size of 254 bytes. For 3.x cards, the size of the private DOs is defined 
by the implementation (the OpenPGP smart card from FLOSS Shop [1] has 
indeed 2048-bytes private DOs).


Cheers,

- Damien


[1] 
https://www.floss-shop.de/en/security-privacy/smartcards/13/openpgp-smart-card-v3.3?c=40


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

Re: Changes in GnuPG

[Damien Goutte-Gattat via Gnupg-users]

On Mon, Jan 06, 2020 at 04:42:40PM +0100, azbigd...@gmx.com wrote:

I'm still a bit confused on the changes in secring. How does it come up
with the names for those "new" keys as it doesn't seem to corrolate
with anything I can see on the keys.


Files under the $GNUPGHOME/private-keys-v1.d directory are named after 
the *keygrips* of the keys.


A keygrip is similar in principle to an OpenPGP fingerprint, but is 
computed on a data structure that is independent of any protocol 
(contrary to an OpenPGP fingerprint, which is computed over an OpenPGP 
packet).


GnuPG, which since its version 2.0 implements both OpenPGP and S/MIME, 
uses keygrips internally to refer to a key independently of the protocol 
with which the key is to be used.


You can use the --with-keygrip option when listing keys to have GnuPG 
display the keygrips, and check that they match the filenames you see in 
the $GNUPGHOME/private-keys-v1.d directory.




For them to go away from the OpenPGP standard it obviously had to make
sense to them


The OpenPGP standard dictates how compliant implementations 
interoperate. It says nothing about what the implementations shall do 
internally.


Keygrips are strictly an internal implementation detail of GnuPG. When 
it interacts with the outside world (e.g. when exporting a key), GnuPG 
still follows the OpenPGP standard.



Cheers,

- Damien


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

Re: Usability of OpenSSL vs GNUPG

[Damien Goutte-Gattat via Gnupg-users]

On Sat, Dec 14, 2019 at 08:05:04PM -0500, Dave via Gnupg-users wrote:

I can’t recall encountering any similar complaints about OpenSSL.  I
find this somewhat curious, and am wondering if there are OpenSSL
detractors out there that I simply haven’t come across


OpenSSL definitely has its detractors. They were for example very vocal 
back in 2014 in the aftermath of the Heartbleed bug.




OpenSSL command structure isn’t as complicated as it seems to me.


For what I have seen, most of the criticisms against OpenSSL are 
directed at the code and/or the API rather than at the command line 
tools. This may reflect the fact that OpenSSL is probably more often 
used as a programming library than as a set of command line tools. That 
being said I have seen complaints about the command line OpenSSL tools 
as well.


(I’ve heard a crypto-nerd once telling me that the only way to correctly 
generate a certificate signing request using OpenSSL’s req command was 
to type the command while sitting in a demonic circle after having 
sacrificed at least a dozen of chickens—or two dozens if the CSR is for 
a ECC certificate.)




I suppose that OpenSSL is geared toward a very technical and
security-aware user base, who aren’t likely to complain about usability
issues


I am not sure I’d buy that. All the criticisms I have seen against 
either GnuPG or OpenSSL came from very technical-minded people.


By contrast, in my experience non-technical people showing up at 
cryptoparties are very much willing to use the software as it is, 
learning what they need to learn instead of complaining that the 
software should be simple enough that they shouldn’t have to learn 
anything.


(Of course those are the people motivated enough to attend a 
cryptoparty. They may not reflect the larger group of users.)



Cheers,

- Damien


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

Re: Modern gnupg.conf setup

[Damien Goutte-Gattat via Gnupg-users]

On Sat, Dec 14, 2019 at 11:18:32PM +0100, Defiant wrote:

Hey, I recall back in the days there were lots of online tutorials about
how to strengthen your GnuPG configuration.


I don’t know which tutorials exactly you’re referring to, but I have 
seen several of them myself, and I have always had the feeling that they 
were written by people who couldn’t be bothered to check what GnuPG’s 
default configuration actually is before deciding it needed to be 
”strengthened”…




no-emit-version
no-comments


Not needed, those are the defaults.



export-options export-minimal


That’s up to you. Note, this does not actually “strengthen” anything.



keyid-format 0xlong
with-fingerprint


For information, the default is not to display any key ID (either short 
or long) but to display the full fingerprint instead (which makes 
displaying the key ID quite irrelevant).


Setting keyid-format to either “short” or “long” however has the effect 
of forcing GnuPG to display the key ID of *subkeys*, so if that’s 
something you need, you may keep that line.




list-options show-uid-validity
verify-options show-uid-validity


Already enabled by default.



personal-cipher-preferences AES256


The default is AES256, AES192, AES128, 3DES. Note that you cannot remove 
3DES which is mandatory as per the RFC 4880 (that’s the only algorithm 
which is guaranteed to be supported by any compliant OpenPGP 
implementation): even if you do not include it, GnuPG will silently add 
it back.


By removing AES192 and AES128, you’re actually increasing the risk that 
GnuPG will have to fallback to 3DES if AES256 is not supported by the 
other party. I don’t think this is what you want.




personal-digest-preferences SHA512


The default is SHA256, SHA384, SHA512, SHA-224, SHA1, with SHA1 being 
mandatory. Same problem as above: by limiting GnuPG’s options, you are 
increasing the risk of having to fallback to SHA1.




default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
TWOFISH ZLIB BZIP2 ZIP Uncompressed


This is almost exactly the default list, except that the default list 
does not include TWOFISH.




cipher-algo AES256
digest-algo SHA512
cert-digest-algo SHA512
compress-algo ZLIB


You are basically bypassing the whole preference-based mechanism used to 
select algorithms compatible with your recipients’ implementation.  
Almost certainly a bad idea unless you are operating in a context where 
you know you don’t need to care about interoperability (e.g. if you are 
only encrypting files for yourself).




disable-cipher-algo 3DES IDEA CAST5 Blowfish
weak-digest SHA1


3DES and SHA1 are mandatory as said above. The other algorithms are 
already not used by default.




s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-mode 3
s2k-count 65011712


The default S2K mode is already 3 (iter+salt). As for the S2K count, for 
information the default is a value automatically determined by GPG Agent 
so that, on your computer, running the S2K algorithm will take ~100ms.



Overall I’d say most of your configuration is either uneeded or even 
counterproductive. I’ll quote GnuPG’s FAQ [1]:



Does GnuPG need to be ‘tuned’ before use?
No. GnuPG has sensible defaults right out of the box.



Cheers,

- Damien


[1] https://gnupg.org/faq/gnupg-faq.html#tuning


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

Re: Partial/fragmented decryption keys

[Damien Goutte-Gattat via Gnupg-users]

On Sun, Dec 08, 2019 at 10:48:47AM -0700, Joseph Bruni via Gnupg-users wrote:
I recall from the early days of PGP that there was a way to create a 
corporate key, fragmented into a certain number of potions, which would 
require some quorum to be able to perform decryption. [...] Is this 
still possible in OpenPGP and therefore in GnuPG?


The OpenPGP RFC [1] seems to acknowledge this possibility by defining a 
flag that can be set on a public key to indicate that the corresponding 
private key “may have been split by a secret-sharing mechanism” (§ 
5.2.3.1). But it does not provide any details about how that feature 
should be implemented, leaving that entirely to the implementations 
(which makes sense, I guess, since what an implementation does with a 
private key is not supposed to have an impact on interoperability, and 
so does not need to be specified).


I don’t know about early (or even more recent) PGP versions, but GnuPG 
does not have such a feature. If you are interested the topic has been 
discussed a few years ago on the -devel mailing list [2].


Cheers,

- Damien


[1] https://tools.ietf.org/html/rfc4880#section-5.2.3.21

[2] 
https://lists.gnupg.org/pipermail/gnupg-devel/2016-January/030681.html


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

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Sun, Oct 27, 2019 at 08:25:10PM +0100, Stefan Claas via Gnupg-users wrote:
Can you please, or somebody else, explain in laymen terms why this is 
so?


Simply put, gpg and openssl enc don’t use the same file formats.  
Different formats may encode the same data differently, so you can’t 
expect the two outputs to be similar or to be of a similar size.


In GnuPG’s case, the format is the one defined by the RFC 4880 standard 
[1]. I don’t know what is the format used by OpenSSL, but some of the 
differences with GnuPG’s format include:


* GnuPG adds a “Modification Detection Code” to the encrypted data;

* GnuPG also adds some metadata, including the name of the original 
 file.


Those differences alone already explain easily why the file generated by 
GnuPG is bigger.


Cheers,

- Damien


[1] https://tools.ietf.org/html/rfc4880


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

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Tue, Oct 15, 2019 at 03:17:58PM -0400, Robert J. Hansen wrote:

... Those were the high-priority changes that needed to be made.  If
anyone has other suggestions, speak up: I'm listening.  :)


A while ago (I can’t find the e-mail anymore) I suggested a few changes 
that somehow didn’t find their way to the FAQ and then I forgot about 
them. Allow me to submit them again.


Those changes are all related to the fact that modern (≥ 2.1) GnuPG 
automatically creates a revocation certificate whenever it creates a new 
key pair, and stores it in $GNUPGHOME/openpgp-revocs.d.


In section 7,17 (What’s a ‘revocation certificate’?), it’s no longer 
recommended to create a revocation certificate immediately after 
generating a new GnuPG certificate. Instead, this section may state that 
GnuPG already creates one when creating a GnuPG certificate, and that it 
can be found in $GNUPGHOME/openpgp-revocs.d.


Similarly, section 8.5 (“What should I do after making my certificate”) 
should no longer say to generate a revocation certificate, but again may 
indicate where to find the one automatically generated by GnuPG, and 
advise to store it in a safe place.


In the same section, the subsection “How do I generate a revocation 
certificate” could be moved elsewhere, as it is no longer something you 
“should do after making [your] certificate”.


In section 10 (“What are some common bast practices?”), the advice 
“Generate a revocation certificate and keep it safe” should be removed 
and optionally replaced by “Keep your (automatically generated) 
revocation certificate safe”.


Cheers,

- Damien


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

[Damien Goutte-Gattat via Gnupg-users]

On Sat, Oct 12, 2019 at 08:07:58AM -0400, Mark H. Wood wrote:

Humph, I was already grumpy about Mozilla products' insistence on
having their own insular X.509 store, meaning that I have to install
certificates twice (once for Firefox, again for *everything else*.)


Slightly off-topic for this list, but on unix-like systems, you can 
force Firefox to use the system store of X.509 certificates (in 
/etc/ssl/certs) by replacing Firefox’s libnssckbi.so library by the 
libp11-kit.so library from the p11-kit project [1,2].


This also works with Thunderbird and with LibreOffice.

- Damien


[1] https://p11-glue.github.io/p11-glue/p11-kit.html
[2] 
https://askubuntu.com/questions/244582/add-certificate-authorities-system-wide-on-firefox/1036637#1036637


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?

[Damien Goutte-Gattat via Gnupg-users]

On Tue, Sep 17, 2019 at 06:59:34PM +0200, Stefan Claas via Gnupg-users wrote:

I assume that in order to decrypt a message the secret key data must be
unlocked and loaded for a very short time into the computers RAM, in order
to perform the decryption


No. The secret key data remains on the smartcard and is *not* sent to 
the host computer. The host computer sends the data to be decrypted to 
the smartcard, the smartcard does the decryption itself then sends the 
decrypted data back to the host.


(Actually the "data" sent to the card is not an entire OpenPGP message, 
just the asymetrically encrypted session key which the hosts then uses 
to decrypt the bulk of the message. But this is a detail which does not 
change the fact that the host never sees the secret private key.)


- Damien


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?

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Mon, Sep 16, 2019 at 11:29:19AM +0200, Daniel Bossert wrote:

I need recommendations:
- Which version of software shall I install?


The latest version available for your system, which should in any case 
be a version from the 2.2 branch. (If your system is Windows, that would 
be Gpg4Win 3.1.10, which provides GnuPG 2.2.17.)


You should *not* use GnuPG 1.4.x unless you have some very specific 
needs (such as working on a "exotic" system or having to interoperate 
with PGP versions from the mid-1990s), and you should *not* use any 
version from the 2.0 or 2.1 branch which are not supported anymore.




- Create key via cli-commands or is Windows-Version ok?


This doesn't matter, really. You may use gnupg directly on the command 
line if you're familiar with it, but you don't have to.



- Which keys shall I take (there was an article not to encrypt/sign 
with El-Gamal)?


The usual recommandation is to stick to the default setting proposed by 
GnuPG (which currently and if I remember correctly is to generate a 
RSA-3072 master key for certifying and signing and a RSA-3072 encryption 
subkey).


Note that modern versions of GnuPG do not ask you anymore to specify the 
type and/or size of key you want unless you explicitly request it.



- Damien


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

Scute 1.6.0 released

[Damien Goutte-Gattat via Gnupg-users]

Hi,

The GnuPG Project is pleased to announce the availability of Scute 
1.6.0.


Scute is a PKCS#11 module built around the GnuPG Agent and the GnuPG 
Smart Card Daemon. It allows you to use an OpenPGP or a PIV smart card 
for TLS client authentication and S/MIME mail and document signing.



Noteworthy changes in version 1.6.0 (2019-09-10)
===

* PIV cards are now supported in addition to OpenPGP cards.

* Key selection is delegated to GpgSM, resulting in faster operations.

* The license has been changed to the GNU Lesser General Public License, 
version 2.1 or later.


* Scute now requires at a minimum the current stable version of GnuPG 
(2.2.0); advanced PIV card support needs the current GnuPG development 
version.


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


Download


Source code is hosted at the GnuPG FTP server and its mirror as listed 
as <https://gnupg.org/download/mirrors.html>.  On the primary server the 
source tarball and its signature are:


 ftp://ftp.gnupg.org/gcrypt/scute/scute-1.6.0.tar.bz2
 ftp://ftp.gnupg.org/gcrypt/scute/scute-1.6.0.tar.bz2.sig

The same files are also available via HTTP:

 https://gnupg.org/ftp/gcrypt/scute/scute-1.6.0.tar.bz2
 https://gnupg.org/ftp/gcrypt/scute/scute-1.6.0.tar.bz2.sig


Signing key
===

The tarball is signed by the maintainer's key:

 rsa4096 2014-03-14
 Key fingerprint = 4FA2 0823 62FE 73AD 03B8  8830 A8DC 7067 E25F BABB
 Damien Goutte-Gattat 

That key is available via a WKD lookup:

 $ gpg --locate-key dgouttegat...@incenp.org


Copying
===

Scute is copyright by g10 Code GmbH and licensed under the GNU Lesser 
General Public License version 2.1 or later (LGPLv2.1+). The full text 
of the license is included in the COPYING.LESSER file of the source 
distribution.


Note that this is a change compared to previous releases of Scute, which 
were licensed under the GNU General Public License version 2 or later 
with an additional exception.



Support
===

The Scute manual is included in the source distribution and is also 
available online at <http://scute.org/scute.html/index.html>. For 
community support, you may ask on the gnupg-users mailing list 
<https://lists.gnupg.org/mailman/listinfo/gnupg-users>.


If you need commercial support, check out 
<https://gnupg.org/service.html>.


Maintenance and development of Scute and of GnuPG as a whole is mostly 
financed by donations. Please consider donating via 
<https://gnupg.org/donate/>.


Happy hacking!


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?

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Fri, Jun 14, 2019 at 10:12:51AM +0200, Oscar Carlsson via Gnupg-users wrote:
I'm generally curious on your opinions on the latest new keyserver, 
this time running a new software than the normal keyservers.


For what it's worth, my main concern is that it is a centralized 
service.


This puts whoever is running keys.openpgp.org in a uniquely good 
position to do Bad Things™. Of course I don't expect they would, but the 
point is, they could (or they could be forced to).


That being said, I have nothing better to propose and overall I welcome 
any attempt, however imperfect, to make OpenPGP slightly easier and/or 
more comfortable to use. (And I do note that Hagrid developers "plan to 
explore options for a distributed service in the future" [1].)


Regards,

- Damien

[1] https://keys.openpgp.org/about/faq


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

Re: Encryption Algorithm for GnuPG?

[Damien Goutte-Gattat via Gnupg-users]

On Sun, May 26, 2019 at 11:30:18PM -0700, Procopius via Gnupg-users wrote:

What is the encryption engine for the current GnuPG.


There’s no single symmetric encryption algorithm. OpenPGP allows a set 
of algorithms: 3DES, IDEA, CAST5, AES, Blowfish, Twofish, and Camellia 
[1,2]. GnuPG supports all of them.




I know IDEA is proprietary so that can’t be used, is this correct?


All patents on IDEA have now expired and IDEA is supported by GnuPG.


If it’s NIST AES that is under the US Government? Wouldn’t that be in 
danger of a US back door in the algorithm?


Rijndael was actually designed by a team of Belgian cryptologists. NIST 
evaluated it amongst the other candidate ciphers of the AES competition 
and eventually selected it as the winner, but was not involved in its 
design. [3]



- Damien

[1] https://tools.ietf.org/html/rfc4880#section-9.2

[2] 
https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml#pgp-parameters-13


[3] 
https://www.nist.gov/news-events/news/2000/10/commerce-department-announces-winner-global-information-security


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

Re: Several GnuPG instances, with their corresponding agents

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Sun, Mar 10, 2019 at 01:25:41AM -0500, Konstantin Boyandin wrote:
> Question: how do I keep several GnuPG versions installed, every
> version with its own gpg-agent?

A Gpg-agent is tied to a specific home directory (as specified in the
GNUPGHOME environment variable or through the --homedir option of gpg),
so all you have to is to make sure you use a separate home directory for
each version you want to use.

For example, assuming you have installed version X of GnuPG under
$HOME/myprogs/gnupg-X, create a directory to use as the home directory
for that version (say, $HOME/gnupg-homes/X), then you can start using
that version by running the following:

  PATH=$HOME/myprogs/gnupg-X/bin:$PATH
  export GNUPGHOME=$HOME/gnupg-homes/X
  $SHELL -i

You'll start a new shell in which all GnuPG invocations will use the
binaries from the X version and the keyrings and other associated files
from the indicated home directory. Simply exit that shell to use again
your system-provided GnuPG in the normal home directory.

Hope that helps,

- Damien


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

Re: gpg > addphoto

[Damien Goutte-Gattat via Gnupg-users]

On Wed, Jan 09, 2019 at 11:29:06PM +0100, dirk1980ac via Gnupg-users wrote:
> > I only wanted to know why such a large image size in the first
> > place was chosen, when GnuPG suggest a much much smaller
> > size. :-)
> 
> I think the 16M are from times, where RAM was nbot measured in GB.

Not quite. If you look at the code’s history, you’ll find that the 16MB
limit is actually from 2014 [1]. There was no limitation on the size of
user attribute packets before that.

It is wise to be careful when you abruptly introduce a limitation that
did not exist before; 16MB was chosen because it is big enough to avoid
breaking any existing key with a legitimate user attribute packet, while
still preventing DoS attempts with deliberately oversized packets.

Of note, the OpenPGP RFC does allow arbitrary large attribute packets,
which means that strictly speaking, GnuPG is already "wrong" to reject a
packet larger than 16MB.


- Damien


[1] https://dev.gnupg.org/rGbab9cdd971f35ff47e153c00034c95e7ffeaa09a


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

Re: NIST 800-57 compatible unattended encryption?

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Wed, Jan 02, 2019 at 04:02:03PM +1100, gn...@raf.org wrote:
> For some dumb reason I think I was hoping that the RSA
> algorithm wasn't really used to encrypt all the data. I
> thought it was probably used to encrypt a per-file
> randomly-generated symmetric key which was then used to
> encrypt the file (and was encrypted along with the
> file) because it could be faster. But I think I'm
> confusing it with network protocols like TLS.
> 
> Is that what happens with RSA in gpg? [Probably not]

Actually yes, that’s exactly what happens. The data (in your
case, the contents of your file) is symmetrically encrypted using
a randomly generated “session key”, and *that* key is
asymmetrically encrypted using the RSA public key.

Cheers,

- Damien


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

Re: gpg - difference --encrypt-to and --recipient

[Damien Goutte-Gattat via Gnupg-users]

On Mon, Dec 31, 2018 at 07:17:21AM +0100, Dirk Gottschalk via Gnupg-users wrote:
> Yes, that's correct. Anyways, I prefer using the --hidden-recipient for
> this purpose. That prevents the disclosure of the communication paths
> with pure GPG-Packet analysis.

You do realize that, in the case of e-mail, the communication paths are
already disclosed by the SMTP protocol (command "RCPT TO") and the mail
headers ("From", "To", and the like), which both are outside the scope
of OpenPGP protection?

Using --hidden-recipient only protects against an hypothetic attacker
who is somehow only able to obtain the email body (the OpenPGP message
itself) without the surrounding metadata.


- Damien


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

Re: Garbled data in keyservers

[Damien Goutte-Gattat via Gnupg-users]

On Mon, Dec 10, 2018 at 02:25:08PM +0100, Wiktor Kwapisiewicz via Gnupg-users 
wrote:
> On 09.12.2018 20:48, Stefan Claas wrote:
> > Mind you in the 90's PGP key servers accepted also email and Usenet
> > submissions, if i remember correctly. The keyword was then simple
> > the word "add" in the subject line of an email.
>
> [...]
>
> I didn't manage to get it running though ("gpg: keyserver send failed: No
> keyserver available"), probably it depends on some package that I don't have
> locally.

As far as I know, most keyservers nowadays no longer accepts key
submission by e-mail. Those that still support the e-mail
interface only do so to allow *querying* the keyserver, not
*adding* any key; that is, they only support the INDEX and the GET
commands, not the ADD command.


- Damien


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

Update FAQ about revocation certificates?

[Damien Goutte-Gattat via Gnupg-users]

Hi GnuPG folks,

The current version of the FAQ recommends creating a revocation
certificate at several places.


§ 7.17

  "We recommend you create a revocation certificate immediately
   after generating a new GnuPG certificate."


§ 8.5

  "What should I do after making my certificate?
   Generate a revocation certificate"


§ 10

  "What are some common best practices?
   [...] Generate a revocation certificate"


However, since GnuPG 2.1 a revocation certificate is now
automatically generated by GnuPG at the same time a new key pair
is created, and stored in $GNUPGHOME/openpgp-revocs.d.

Therefore the above recommendations should either be removed or at
the very least amended to explain that they are only necessary
with GnuPG < 2.1.

FWIW, I believe they should be removed completely. Rationale: It
has already been decided three years ago not to mention GnuPG 1.4
in the FAQ [1]. Since then, GnuPG 2.0 has been end-of-lifed and so
in my opinion should not be mentioned either.  Thus the FAQ should
only focus on "modern" GnuPG (>= 2.1). And with modern GnuPG there
is no need to recommend to generate a revocation certificate.

On the same topic, the answer to the question "How do I generate a
revocation certificate?" (§ 8.5) should be amended to explain that
such a revocation certificate may already have been generated.
("May", because it is possible the user asking this question has
generated his or her key a long time ago, using an older version
of GnuPG.)

Comments are welcome.

Cheers,

Damien


[1] https://lists.gnupg.org/pipermail/gnupg-users/2015-August/054172.html


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

Re: Most secure GPG combination for Mac OS X

[Damien Goutte-Gattat via Gnupg-users]

Hi,

First, a warning: I am by no means a "security expert" and I have
very little experience with Mac OS X, which I only use at my
workplace (and only because my employer didn't let me use a
GNU/Linux workstation...).

However and for what it's worth:

On Tue, Nov 06, 2018 at 06:48:07AM -0500, Nicholas Papadonis wrote:
> I noticed that there are two OSX packages for GPG:
> 
>   Mac GPG Installer from the gpgtools project
>   GnuPG for OS X Installer for GnuPG

There's a third possibility, which is the one I use: install the GnuPG
provided by the MacPorts project [1].

Install MacPorts and then simply run:

  $ port install gnupg2

MacPorts packagers seem keen to provide the latest versions and to
update their ports quickly when upstream publishes a new release.
For example, Libgcrypt was updated to version 1.8.4 the day after
that version was released.


> I'm considering using the Mac Mail.app

I tried to build the Mail.app plugin from the gpgtools project,
but failed. I don't remember what the problem was, just that I
gave up.

I am currently using alternatively Neomutt (also installed through
MacPorts), which natively supports GnuPG, and Thunderbird with
Enigmail. Everything is working fine, including smartcard support.
Whether this is a "better integrated" solution than using Mail.app
I cannot tell.

Hope that helps a bit.

Damien

[1] https://www.macports.org/


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

Re: OpenPGP key verification + legal framework

[Damien Goutte-Gattat via Gnupg-users]

On Mon, Nov 05, 2018 at 09:30:48PM +0200, Viktor wrote:
> Because of Google or because of "only one user ID" ?

Both, even though the requirement of using only one user ID would
be more acceptable if the address did not have to be associated
with a Google account.

Damien


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

Re: OpenPGP key verification + legal framework

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On Mon, Nov 05, 2018 at 05:13:41PM +0100, Juergen Bruckner wrote:
> I just tried to register with a key who has several user-ID's
> (e-mail-adresses) and I always got the error that the user-ID is not the
> same as in log-in/registered e-mail.

From what they say on the home page [1] this is expected: your key is
supposed to have only one user ID whose email component must match
the email address of your Google account...

... which, by the way, is a big "no" for me. :/


Damien


[1] https://cryptonomica.net/#!/

> To become member of Cryptonomica:
> [...]
> Public PGP Key should have one user ID with first name, last
> name and user e-mail. E-mail in the key should be the same as in
> Google account, that you use to login to Cryptonomica server.


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

Re: gpg not able to find my secret key

[Damien Goutte-Gattat via Gnupg-users]

On 08/24/2018 07:47 AM, Martin T wrote:
> One more small question- in the output of "gpg --list-keys" or "gpg
> --list-secret-keys" I see two keys, but in the output of
> "gpg-connect-agent 'keyinfo --list' /bye" or "ls
> ~/.gnupg/private-keys-v1.d/" I see four keys with different hashes.
> Why is that so?

When you say that you have two keys, do you mean two *primary* keys? If
so, each primary key probably has an encryption *subkey* (automatically
generated by GnuPG, that has been the default behavior of GnuPG for a
very long time), so you end up with four private keys.

As for the fact that you see "different hashes", that's because `gpg
--list-keys` prints out the *fingerprints*, whereas gpg-agent's keyinfo
command prints out the *keygrips*.

A fingerprint and a keygrip are both hashes of a public key, but they
are computed differently and don't serve the same purpose. Fingerprints
are specified by the OpenPGP format and uniquely identify an OpenPGP
key. Keygrips are used internally by gpg-agent to uniquely identify a
key independently of any protocol.


Damien



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

gpg not able to find my secret key

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On 08/23/2018 10:54 AM, Martin T wrote:
> When I start the "gpg --list-secret-keys" with "strace -e open",
> then ~/.gnupg/secring.gpg file is not searched.

GnuPG >= 2.1 does not use ~/.gnupg/secring.gpg anymore. Secret keys are
now stored in the ~/.gnupg/private-keys-v1.d folder (one file per key).

When you say you "moved ~/.gnupg directory from old machine to new one",
did you make sure to include the private-keys-v1.d folder?

Related question: Do you have a file named "gpg-v21-migrated" in your
.gnupg directory?

Waiting for your answers, I suspect the following happened:

* You were using GnuPG < 2.1 before (1.4 or 2.0), with your private keys
in the secring.gpg file.

* At some point you upgraded to GnuPG 2.1; GnuPG automatically migrated
your keys from the secring.gpg file to the private-keys-v1.d folder
(leaving the gpg-v21-migrated file as a marker that the migration occured).

* When you moved your .gnupg folder, the private-keys-v1.d folder was
somehow left behind (maybe because you didn't know about it). So
gpg-agent cannot find your private keys.

* Even though you still have a copy of your private keys in the
secring.gpg file, GnuPG will not even look at this file, since the
gpg-v21-migrated file tells it that the private keys were already migrated.

If that's what happened, then simply removing the gpg-v21-migrated file
should be enough to trigger a new migration and allow you to get your
private keys where the agent expects to find them.

I am, however, a little bit concerned by the following:

> When I list the secret keys(gpg --list-secret-keys), then the output 
> is empty.  gpg-agent is not running.

gpg-agent should be started automatically by gpg as soon as it is needed
(such as when you ask for a listing of the secret keys). The fact that
the agent is *not* running could indicate a problem in your GnuPG
installation, independently of the presence or absence of the
private-keys-v1.d folder.


Damien



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

Public vs Private Fingerprint

[Damien Goutte-Gattat via Gnupg-users]

On 08/14/2018 12:05 PM, Ralph Corderoy wrote:
> That was my conclusion after having searched a bit this morning,
> but I didn't notice it explicitly documented?

Maybe not in GnuPG's manual, but it is explicitly documented in the
specification of the OpenPGP format (RFC 4880, §12.2 [1]):

> A [V4] fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
> followed by the two-octet packet length, followed by the entire
> *Public-Key packet* starting with the version field.


Damien

[1] https://tools.ietf.org/html/rfc4880#section-12.2



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

Re: Public vs Private Fingerprint

[Damien Goutte-Gattat via Gnupg-users]

On 08/14/2018 05:20 AM, Damian Rivas wrote:
> Is there a reason why the fingerprints for my public and private keys are
> exactly the same?

Actually there's no such thing as a private key fingerprint.
Fingerprints are only calculated on public keys.

(Theoretically you *could* compute a fingerprint on a private key, but
as far as I know that's never used in OpenPGP.)

Even when GnuPG is displaying a private key (e.g. with the
--list-secret-keys command), the fingerprint is the fingerprint of the
corresponding public key.


Damien



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

Expire a single UID

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On 06/11/2018 09:30 AM, Max-Julian Pogner wrote:
> *) should i revoke the uid on the old key? => However, as far as i 
> know, the secret key is not / was never compromised.

This is probably the best option in my opinion, since you will no longer
use that key with this email address.

Revoking a UID is not the same as revoking a key, and does not imply
that the associated secret key has been compromised (if a key has
been compromised you should revoke the key itself, not the UID). Most
often it simply means "I no longer use that UID". Note that when
revoking the UID you will have the option of specifying a reason for the
revocation.


> *) Also, other persons have signed the UID 
> max-julian.pog...@openresearch.com at key 0x2D40BDB44401A8AA without 
> expiration date. What should they do?

With regard to your old key, they don't have anything to do. Your
revocation of the UID takes precedence over their signatures.

With regard to your new key, you might want to ask them if they could
sign it. One way to do that is to send them an email signed by both the
old key and the new key, so that they know you control both keys.


> Thanks for any hints!

Here's another possibility: Have you considered using an OpenPGP card?
This would allow you to keep your private keys under your control, even
when you use them on your employer-provided system.


Hope that helps,

Damien



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

Re: STM32F103 flash ROM read-out service

[Damien Goutte-Gattat via Gnupg-users]

On 06/06/2018 08:50 PM, Philipp Klaus Krause wrote:
> See https://www.aisec.fraunhofer.de/en/FirmwareProtection.html for 
> some research on breaking STM32 readout protection published in 
> January.

For what it's worth, STMicroelectronics claims that the attack described
in this paper "affects only the STM32F0 and is not successful in all
other series" [1].

Whether you believe them or not is up to you. Of note, the authors of
that paper themselves do not claim the attack works on anything else
than the STM32F0.

(But of course, just because *this* attack (presumably) does not work on
the STM32F103, it does not mean that nobody can ever come up with a
successful attack on that chip...)


Damien


[1]
https://community.st.com/thread/46432-hacking-readout-protection-on-stm32#comment-181542



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

Relocating pubring.kbx in gpg.conf

[Damien Goutte-Gattat via Gnupg-users]

On 05/22/2018 07:58 AM, Konstantin Boyandin via Gnupg-users wrote:
> primary-keyring ~/mounted/gnupg/pubring.gpg
> secret-keyring ~/mounted/gnupg/secring.gpg
> trustdb-name ~/mounted/gnupg/trustdb.gpg 
> keyring ~/mounted/gnupg/pubring.gpg
> but I see no obvious directives to relocate pubring.kbx

You can use the keyring option as well, which works both for the old
keyring format (.gpg) and the new keybox format (.kbx). You might want
to combine that with the 'no-default-keyring' option, to prevent GnuPG
from systematically create the default $GNUPGHOME/pubring.kbx.

Note, however, that with GnuPG ≥ 2.1 the 'secret-keyring' option no
longer has any effect. Modern GnuPG no longer uses a secret keyring
file, private keys are handled by the Agent which always store them in
$GNUPGHOME/private-keys-v1.d.


> - my only option, so it seems, remains relocating the entire
> configuration directory.

Given that in your current configuration your private keys are *not*
stored where you think they are (because 'secret-keyring' is ignored as
stated above), this is indeed as far as I know your only option.


Damien



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

A postmortem on Efail

[Damien Goutte-Gattat via Gnupg-users]

On 05/21/2018 04:07 AM, Mark Rousell wrote:
> I think you mean that support for 2.0.y has been dropped, surely?

No, I do mean that support for all PGP 2-related stuff has been dropped
from the current stable branch. Modern GnuPG (≥ 2.1) can neither read
nor write anything that has been generated by PGP 2.x. Compatibility
starts with PGP 5, which dates back to 1997.


> When I wrote "2.x.y" above I meant that users should be able 
> to continue decrypting legacy-encrypted data (albeit with a change of
> commands/options compared to the present) with whatever the
> currently-supported version of 2.something is at any point in the
> future.

Well, that's already not the case. If you have pre-1997 data, you need
to use GnuPG 1.4, which again *is* still supported precisely for this
use case. (You could also, in theory, use GnuPG 2.0.x, but *that* branch
is explicitly no longer supported.)


Damien



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

Breaking changes

[Damien Goutte-Gattat via Gnupg-users]

On 05/21/2018 06:20 AM, Robert J. Hansen wrote:
> 2.  End-of-life 2.0.

That one at least is already done. The 2.0 branch reached EOL with the
2.0.31 release on December 29, 2017. I believe Werner stated clearly
enough that there will be *no* further point release on that branch, not
even for critical security fixes. If a distro is currently shipping a
2.0.x version, backporting any such security fix will be left to the
packagers/maintainers for that distro.

The last release of the 2.0.x branch is not even listed anymore on
gnupg.org's download page.


Damien



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

A postmortem on Efail

[Damien Goutte-Gattat via Gnupg-users]

On 05/20/2018 08:45 PM, Mark Rousell wrote:

I presume that one day the 1.x.y code will reach end of life.


There's no plan to terminate the 1.x branch. It will not gain any new 
features, but as stated by Werner Koch a few months ago, it "will be 
kept alive for use with PGP 2 encrypted and signed data" [1].




I think it is important that they can still do this with a maintained (2.x.y) 
code base.


Support for PGP 2 has already been dropped from the current stable 
branch, I don't think it will ever be brought back. But the 1.4.x branch 
*is* maintained, even if only for critical bugfixes.



Damien


[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-January/059815.html



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

A postmortem on Efail

[Damien Goutte-Gattat via Gnupg-users]

On 05/20/2018 02:51 PM, Dirk Gottschalk via Gnupg-users wrote:

It would be possible to implement something like --legacy to
re-enable the old functionality.


For information, for the problem at hand, two things have been done in 
that direction:


In GnuPG itself: GnuPG will now error out when attempting to decrypt 
*any* message that is not integrity-protected, *unless* the 
--ignore-mdc-error flag has been set. This has only been done in the 
master branch of GnuPG (to be released as GnuPG 2.3 at some point), 
*not* in the current stable 2.2 branch.


In GpgME: GpgME will return a failure when attempting to decrypt *any* 
message that is not integrity-protected, inconditionnally and even if 
GnuPG itself only emits a warning.


What this all means is that all clients using GpgME will lose the 
ability to decrypt old, unprotected message upon the next GpgME release 
(i.e., those clients will be completely immune to Efail even if they 
currently ignore the no-MDC warning). Users will still be able to 
decrypt such unprotected messages by calling gpg directly (with the 
--ignore-mdc-error flag, if needed).


Clients that spawn gpg themselves without using GpgME will still be able 
to decrypt unprotected messages (and therefore, be potentially 
vulnerable to Efail if they don't pay attention to GnuPG warnings) until 
GnuPG 2.3 is released.



And more generally on the backward compatibility problem: to decrypt all 
kind of "legacy" messages there will always be the option of using GnuPG 
1.4.x, which is still maintained especially for compatibility with 
1990-era PGP (it notably retains support for things like PGP 2.6 keys or 
the MD5 hash algorithm).



Damien



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

Where to send a "patch" to scute.

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On 05/10/2018 11:42 PM, Dirk Gottschalk via Gnupg-users wrote:

Where shoult I send this a suggested feature?


Patches should be sent to gnupg-de...@gnupg.org, prefixing the subject 
with a "[PATCH scute]" tag. Same for feature requests.


Alternatively, you may also create a Task in the GnuPG project's bug 
tracking system at https://dev.gnupg.org/.




Is somebody interested in this out there?


As the maintainer of Scute, I am. :)



PS: The changes were made in some kind of dirty way, because I was in a
hurry to get this working.


I just had a cursory look at the patch. Although I kind of like the 
idea, my main concern with it is the duplication of the entire 
src/slots.c file. I will not merge anything like that.




If somebody has suggestions to make this in a cleaner way, feel free to comment.


Right now, my first idea would be to avoid duplicating src/slots.c and 
instead use info.grip1 or info.grip3 depending on the value of the 
ENABLE_SIGKEY flag. But I have to give it a little bit more thoughts.


In the meantime, you might want to bring the topic to the gnupg-devel 
list, which is more appropriate for development-related discussions.



Damien



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

Re: Backup .gnupg using git

[Damien Goutte-Gattat via Gnupg-users]

On 04/21/2018 05:32 PM, Wink Saville wrote:

Comments on the security of what I'm doing?


Can't really tell anything without knowing your adversary (is it Mossad 
or not-Mossad? [1]), but here are a few remarks.


You do not say which version of GnuPG you are using. Assuming you are 
using the latest available version on your system (which you should), 
most of the options you put in your gpg.conf and dirmngr.conf are 
useless, as they are already in the default settings (something many 
authors of those "create a perfect keypair" howtos seem to ignore).


Also, your gpg.conf contains the following:

  # Avoid information leaked
  [...]
  export-options export-minimal

If the goal here is to avoid revealing who signed your key (this option 
tells GnuPG to remove all third-party signatures on your key), then this 
is completely defeated by the fact that you upload your entire public 
keyring to a world-readable Github repository!


Combined with the trust database that you *also* upload, this is a 
pretty serious information leak IMO, as anyone can learn not only who 
signed your key, but also which keys you collected over time, which keys 
you signed (even if you only signed them locally), and how much you 
trust the owners of all those keys. Are you fine with that, or didn't 
you realize the implications of uploading those files?


Finally and as a general rule, if you are not sure of what you are 
doing, I am strongly of favour of following only those two advices:


* Use the latest GnuPG version available on your system. In particular, 
if you invoke `gpg`, make sure this is GnuPG >= 2.1 and *not* GnuPG 1.x.

* Use the default settings.


Damien


[1] https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058046.html



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

Re: Semantics of WOT and Subkeys

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On 04/19/2018 03:12 AM, Evan Klitzke wrote:
Later Alice learns about subkeys, so she creates a new signing subkey 
for signing her mail/git commits/whatever. How does this work when Bob 
sees the new subkey?


For most purposes, the use of subkeys is "transparent" from the user's 
point of view. Users only need to be concerned about their 
correspondants' master (or primary) key.


In particular :


Does Bob/GPG treat the signing subkey to be just as trusted as Alice's master 
key?


Yes [1].


From Bob's point of view, is there a difference which key 
(the master key or the subkey) Alice used when signing Carol's key?


Unless Alice played with GnuPG's source code, she can only use her 
master key to sign Carol's key.


Signing a key ("certify", to use the proper term), in OpenPGP, is a 
special form of signing which requires a key with the "Certify" 
capability instead of the "Signing" capability. Only the master key has 
that capability. As far as I know it is not possible to generate a 
certification-capable subkey.


Hope that helps,

Damien


[1] Assuming the subkey is correctly bound (with correct signatures) to 
Alice's master key. But this is something that not even Alice should 
have to care about, this is all taken care of by GnuPG when she 
generates her new subkey.




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

Re: Again: Writing DER certificates to ZeitControl Cards

[Damien Goutte-Gattat via Gnupg-users]

On 04/02/2018 01:10 AM, NIIBE Yutaka wrote:

Most likely, the length of certificate matters.  If you can minimize
your certificate, please try.  I don't know the limitation for the card.


I don't know for the v3.3 card, but v2.1 cards allow for a 2048 bytes 
certificate (at least mine does, but maybe this has changed between 
different production runs?).


One way of finding the max allowed size is the following command (here 
tested with a Yubikey NEO):


$ gpg-connect-agent 'SCD LEARN --force' /bye | grep '^S EXTCAP'
S EXTCAP gc=1+ki=1+fc=1+pd=0+mcl3=1216+aac=0+sm=2+si=0+dec=0+bt=0

The value you are interested in is "mcl3". In this example, it says that 
the Yubikey NEO allows for a 1216-bytes certificate.



Damien



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

Re: enigmail with pgp 2.2.4

[Damien Goutte-Gattat]

Hi,

On 02/22/2018 02:21 PM, Dmitry Gudkov wrote:

sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local
[...]
*and all works fine in terminal*

however after installing Enigmail I get this error


You installed GnuPG 2.2.4 in /usr/local, but you still have an older 
version in /usr.


Everything works fine in the terminal because your shell finds the newer 
/usr/local/bin/gpg, but Enigmail is still using /usr/bin/gpg2 (as you 
can see in the error message, which includes the exact command used to 
invoke gpg).


You must configure Enigmail to use /usr/local/bin/gpg (in the 
"Preferences" dialog, "Basic" tab, override the default setting).




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

Re: is there a preferred order to building dependencies for gnupg2

[Damien Goutte-Gattat]

On 01/10/2018 09:25 AM, Henry wrote:

There are five libraries required to build gnupg2: libgpg-error,
libgcrypt, libassuan, libksba and npth.

Is there a preferred order in which they should be built?


Libgpg-error should be built first as it is required by all other 
libraries except npth.


Apart from that, there is no dependencies between the other libraries 
and they can be built in any order.


For example, when I compile GnuPG for Slackware, I do this (on a fresh 
VM with a "vanilla" Slackware):


1) Build libgpg-error and npth (in any order).
2) Install libgpg-error.
3) Build libgcrypt, libassuan, and libksba (in any order).
4) Install npth, libgcrypt, libassuan, and libksba.
5) Build gnupg.

(This should be suitable for any GNU/Linux system beyond Slackware. 
However, I don't know about building GnuPG on/for other systems.)


Damien



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

Re: trouble listing keys in my private-keys-v1.d directory

[Damien Goutte-Gattat]

Hi,

On 01/02/2018 01:43 PM, Maarten Nieber via Gnupg-users wrote:

My hypothesis is that somehow, by creating a few extra keys today, my previous 
openpgp key is not visible anymore. Can somebody explain why that might be the 
case, and help me to repair this?


My first guess would be that pass was using gpg2, while you started 
using gpg which on your system is probably gpg 1.4.


The location of both the public and private keys has changed in the 
history of GnuPG (basically: public keys were stored in pubring.gpg in 
GnuPG <= 2.0, and in pubring.kbx from GnuPG 2.1, while private keys were 
stored in secring.gpg in GnuPG 1.x, and in private-keys-v1.d from GnuPG 
2.0+). If gpg is gpg 1.x on your system, this could explain why you 
don't see your pass private key when you call gpg --list-keys.


Can you check precisely which version(s) of GnuPG are available on your 
system?


  $ gpg --version
  $ gpg2 --version

As for pass complaining about the "unusable public key", that could be 
the result of the trustdb having been updated by gpg 1.4 (which did not 
know that the private key for 89F615FB was available, and therefore has 
marked the corresponding public key as untrusted instead of having 
ultimate trust).


If that's the case, the best option would probably be to stop using the 
old gpg 1.4 and use only gpg2.


Damien



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

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

[Damien Goutte-Gattat]

On 10/29/2017 07:18 PM, Shannon C wrote:

Assuming that the secret key was generated outside of an Infineon
chip, but that subsequently subkeys were generated by a chip with the
ROCA vulnerability, does that compromise the main private key, or
only the subkey?


There is no mathematical link between a primary (or master) key and a 
subkey. A subkey is linked to a primary key only through a "subkey 
binding signature".


If a subkey is compromised (meaning an attacker somehow managed to know 
the private key, be it through the ROCA vulnerability or any other 
method), this has *no impact* on the primary key. The attacker won't be 
able to infer any information about the primary key.


This is also true the other way around: knowing the primary private key 
does not allow to deduce the private subkey(s).


Damien



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

Re: Is there some writeable memory on the OpenPGP-card

[Damien Goutte-Gattat]

On 10/10/2017 01:38 PM, Matthias Apitz wrote:

it would be nice transfer some small files together with the
USB OpenPGP-card. Is there some memory for read/write on them, maybe
with some commands of the card daemon?


The OpenPGP Card specification defines "Private Use Data Objects" that 
you may use to store arbitrary data.


You can write to those DO using the "privatedo" command of the GnuPG's 
card editor. For example, to send the contents of the test1.txt file to 
the private DO #1:


  $ gpg --card-edit

  gpg/card> privatedo 1 < test1.txt

Caveats to be aware of:

* In versions 2.0 and 2.1 of the OpenPGP Card specification, private DOs 
are limited in size to 254 bytes each. (In version 3, there is no upper 
limit fixed in the specification.)


* Private DOs are optional and not all implementations support them. 
(Yubico's Yubikey NEO does not, for example).


Damien



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

Re: Extending expiration date and SSH

[Damien Goutte-Gattat]

Hi,

On 09/18/2017 12:38 PM, Marko Božiković wrote:

Will that change the SSH public key (as it is exported using ssh-add -L for
adding to .ssh/authorized_keys)?


No. The expiration date of the subkey is not part of the key material 
itself, it is stored in the subkey binding signature. A modification of 
the expiration date has no effect on the public key as seen by SSH.



Damien



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

Re: [Feature Request] Multiple level subkey

[Damien Goutte-Gattat]

On 09/10/2017 11:32 PM, lesto fante wrote:

just to be sure I don't misunderstand, the level 2 key cannot revoke
the level 1 key, right?


No it cannot.

And to be more precise, in the situation where the level-2 key is 
compromised, you actually do not revoke the level-2 key itself (using 
the corresponding level-2 private key), you revoke the trust signature 
on the level-2 key (using the level-1 private key). The level-2 will 
then cease to be valid in the eyes of your correspondents.




My goal is to bring good privacy at the housewife, while making the
process even more easier (as it will be as easy as using a wallet).


So you want to bring privacy to the housewife while at the same time 
make her rely on someone else (the "son/trust person" you mentioned) to 
manage her privacy? But is it still privacy then?


If I had to trust someone else with my privacy, I think I would rather 
trust the faceless algorithms running in a Google datacenter than a 
person close to me and who keep telling me "don't worry, I'm taking care 
of everything, just relax."


(If you think that your son or your "trust person" cannot betray you, 
well, by definition you can be betrayed *only* by someone you trust.)


GnuPG (and free software in general) should empower users to take 
privacy in their own hands, not incite then to rely on a "trust person".


That's only my opinion, of course.

Damien



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

Re: [Feature Request] Multiple level subkey

[Damien Goutte-Gattat]

On 09/10/2017 09:17 PM, lesto fante wrote:

If your level-3 key is compromised, you revoke it, generate a new one and sign 
it with the level-2 key. The new level-3 key will be automatically valid for 
your correspondents.


what if i lose the level-2 key too? imagine level-2 and level-3 key
are both on my phone, with NO other copy of the level-2 and level-3
private key.
Can i revoke all of them?


You revoke the level-2 key, that will be enough to invalidate the 
signature on the level-3 key.




If my device is in the hand of a bad person, will he be able to
compromise my level-1 key


Assuming the level-1 key is not on that device, then no.



Also i understand the key-level truthiness, but here i want to
AUTOMATE, make this thing MORE EASY to use than a common password
approach.


I merely pointed out what is already feasible with the current state of 
the OpenPGP specification and the GnuPG implementation.




This approach MUST be "housewife proof"; her son/truth person will set
up the sign key for her and then just tell her to keep the smartcard
in a safe place. Then to choose a safe password for the SIGN key. That
is the only password out housewife need, unless she will loose or get
a compromised phone; at this point, she will call the trust person
that will take care revoke, and then issuing a new SIGN key on her new
phone. No need to go and reset ALL of her account and such; all the
key she had has been already replaced :)


I do not really care for this "user is an idiot, we cannot trust him/her 
to do the right thing so we should do it for him/her" approach.


Damien



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

Re: [Feature Request] Multiple level subkey

[Damien Goutte-Gattat]

On 09/10/2017 08:30 PM, lesto fante wrote:

If your level-1 key is compromised, you revoke it, generate a new one and sign 
it with the level-2 key. The new level-1 key will be automatically valid for 
your correspondents.

If your level-2 key is compromised, you revoke it, generate a new one, tsign it 
with the level-1 key


this is exactly what i DON'T want. The level 2 key (or level 1, it
seems you mixed them up)


Sorry, I did mix level-1 and level-3 keys in the first sentence you're 
quoting. What I meant was:


If your level-3 key is compromised, you revoke it, generate a new one 
and sign it with the level-2 key. The new level-3 key will be 
automatically valid for your correspondents.




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

Re: [Feature Request] Multiple level subkey

[Damien Goutte-Gattat]

Hello,

On 09/09/2017 12:50 AM, lesto fante wrote:

Tho achieve that, I think about a multilevel subkey system.


The OpenPGP specification already has some support for a hierarchical 
system, in the form of "trust signatures".


(Hereafter, I will use "trust-sign" as a verb to refer to the act of 
emitting a trust signature.)


For a 3-levels hierarchy as you describe, you could do the following:

a) You sign your level-3 key(s) with your level-2 key;

b) You trust-sign your level-2 key with your level-1 key, with a trust 
depth of 1.


c) Your correspondents trust-sign your level-1 key, with a trust depth of 2.

If your level-1 key is compromised, you revoke it, generate a new one 
and sign it with the level-2 key. The new level-1 key will be 
automatically valid for your correspondents.


If your level-2 key is compromised, you revoke it, generate a new one, 
tsign it with the level-1 key, and use it to re-sign your level-1 key 
(although if the level-2 key is compromised, you may want to assume that 
the level-1 key is compromised as well, and generate a new one). Again, 
the new level-2 key will be valid and trusted by your correspondents, 
since it bears a trust signature from the level-1 key.


The problem you may have with this method is that it depends on your 
correspondents *trust-signing* your level-1 key. If they use a normal 
signature instead (or a trust signature with a trust depth < 2), no 
ownertrust will be assigned to the level-2 key and therefore the level-3 
key will not be considered valid. So you have to tell your 
correspondents to *trust-sign* your level-1 key, but you cannot force 
them to do so.


This is kind of a design feature of OpenPGP, by the way: the user is 
always free to choose whom he wants to trust, and to what extent. This 
is by contrast with the X.509 world, where the fact that a certificate 
can only be signed by *one* authority gave rise to an ecosystem of CAs 
that are "too-big-to-fail" (or "too-big-to-choose-not-to-trust").




Now the nice thing: i guess most of the people will use their phone
to keep the level 2 key, but we know those are not the most secure
stuff, especially when get old or wit some producer allergic to
patch.


Slightly off-topic, but using a NFC-enabled token might be an easier way 
to deal with that particular concern. I know of at least two such 
tokens: the Yubikey NEO [1] and the Fidesmo Privacy Card [2].



Damien

[1] https://www.yubico.com/products/yubikey-hardware/yubikey-neo/

[2] http://shop.fidesmo.com/product/fidesmo-privacy



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

Re: Documentation of trust model

[Damien Goutte-Gattat]

Hello,

On 09/05/2017 12:58 AM, Mario Castelán Castro wrote:
Are the trust models “classical” and “pgp” as implemented in GNU PG 
documented anywhere?


As far as I know, not really. Certainly not in the OpenPGP RFCs. RFC4880 
and its predecessors never defined any trust model, they only defined 
some “tools” that can be used by a trust model (such as the different 
certification types or the trust signature packet). But the trust models 
themselves are left to the implementors.


I seem to remember that someone on the IETF OpenPGP mailing-list evoked 
the idea of writing a complementary, informational RFC to describe 
routinely used trust models, but I don’t think it has ever been done.


As for the “classic” and “pgp” trust models as used by GnuPG, very  briefly:

In the “classic” trust model, GnuPG determines whether a given 
non-expired, non-revoked OpenPGP public key is valid by looking at the 
signatures (“certifications”) carried by that key. The key is fully 
valid, marginally valid, or of unknown validity depending on the number 
of certifications emitted by trusted keys in the user’s keyring.


The key aspect of the “classic” trust model is that it only determines 
the *validity* of a key. *Ownertrust* (the value associated with a key 
and which indicates if certifications emitted by that key are taken into 
account) is always manually set by the user. (This is something that is 
frequently misunderstood.) A “classic” signature only means something 
like “I certify that this key belongs to its stated owner”.


By contrast, in the “pgp” trust model, users can emit “trust 
signatures”, which carry both validity and ownertrust information. A 
trust signature means “I certify that this key belongs to its stated 
owner *and* I regard its owner as trustworthy.”


To illustrate the difference, let’s consider the following (from the 
point of view of Alice):


a) Alice signs Bob’s key and fully trusts Bob;
b) Bob signs Carol’s key and fully trusts Carol;
c) Carol signs David’s key.

In the “classic” trust model, only Bob’s and Carol’s key are valid 
(Bob’s key because it is signed by Alice’s own key, and Carol’s key 
because it is signed by Bob’s key, which Alice fully trusts). But 
David’s key is of unknown validity because Alice never assigned an 
ownertrust value to Carol’s key. The fact that Bob fully trusts Carol is 
irrelevant; actually, Alice does not even know that Bob fully trusts Carol.


In the “pgp” trust model, and assuming that Alice and Bob emitted trust 
signatures instead of simple signatures (I ignore, for simplicity’s 
sake, the notion of trust depth and the possibility to assign marginal 
ownertrust), Carol’s key has full ownertrust in the eyes of Alice even 
though Alice never explicity assigned an ownertrust value to it. 
Consequently, David’s key is valid.


Obviously there would be much more to describe, but I hope the above 
helps a little bit.


For what it’s worth, I wrote a document attempting to describe more 
thoroughly the various trust models used by GnuPG (including the new 
TOFU models) [1]. Unfortunately, it’s in French. :( I wanted to write an 
English version but never found the time nor the motivation…


Damien

[1] https://incenp.org/dvlpt/docs/confiance-openpgp.html



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

Re: Newbie Question: Creating a Key Server using GNUPG tools

[Damien Goutte-Gattat]

Hi,

On 08/27/2017 11:40 AM, arznix via Gnupg-users wrote:

Can anyone clarify whether it is possible to create a local Key Server using the
GNUPG tools?


Not with GnuPG itself. The GnuPG project does not provide a keyserver 
software.


Most keyservers out there are powered by a software called SKS 
(Synchronizing Key Server) [1,2].


For a local network, a LDAP-based keyserver may also be considered. The 
GnuPG wiki has a page on how to setup such a server [3].


Finally, with GnuPG modern (>= 2.1) you may choose to setup a Web Key 
Directory. This is a recently introduced approach to key distribution, 
for which GnuPG provides some tools and documentation [4,5].


Hope that helps,

Damien

[1] https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home
[2] https://keyserver.mattrude.com/guides/building-server/
[3] https://wiki.gnupg.org/LDAPKeyserver
[4] https://gnupg.org/blog/20160830-web-key-service.html
[5] https://gnupg.org/blog/20161027-hosting-a-web-key-directory.html



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

Re: export secret subkeys

[Damien Goutte-Gattat]

On 08/17/2017 03:39 PM, Dirk-Willem van Gulik wrote:

This had me believe that export-secret-subkeys would just export a
subkey.

Instead the output of --list-packets (and the file size) suggests
that both the master and the subkey are exported.


Seemingly, yes. But actually, when using --export-secret-subkeys, the 
master private key is not really exported. The command does produce a 
"secret key packet" corresponding to the master key, but this packet 
does not actually contain the private key material.


Look for the "gnu-dummy S2K" line in the details of the secret key packet:


:secret key packet:
version 4, algo 1, created 1502976628, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
gnu-dummy S2K, algo: 0, simple checksum, hash: 0


It's the clue indicating that this packet is actually unusable. And 
that's what the man page means when it says:


"The second form of the command has the special property to render the 
secret part of the primary key useless."


The purpose of this command is to create a situation where only the 
private subkeys are available on the machine, while the master private 
key is stored offline.


Damien



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

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

[Damien Goutte-Gattat]

On 07/31/2017 05:49 PM, Dirk-Willem van Gulik wrote:

For what it is worth - the various best practices at `riseup.net’[1] seem to 
strike a good middle ground.


For what it is worth, I disagree.

The main problem I have with that document is that it implies the user 
should care about a lot of details that he actually should not have to 
care about, especially with a decently recent GnuPG version.


Specifically:

* Starting from GnuPG 2.1.16, the user has nothing to do to use the SKS 
keyserver pool, that's already the default. There's no need to manually 
download the CA certificate for the pool, either, because it is now 
included directly in GnuPG.


* There is no need to "ensure that all keys are refreshed through the 
keyserver you have selected"--the honor-keyserver-url option is already 
disabled by default.


* There is no need to generate a revocation certificate. GnuPG already 
does that when you create a new keypair. You need to do it yourself only 
if you generated your key some years ago, before automatic generation of 
revocation certificates was implemented (i.e. before GnuPG 2.1).


* There is no nothing to do to "have a separate subkey for encryption". 
When creating a new keypair, GnuPG automatically creates a primary key 
for signing and certifying, *and* a subkey for encryption. (I do not 
remember when GnuPG started to do that, but I am pretty sure this is not 
new at all.)


* Unless you generated your key a long time ago, you absolutely do not 
have to "make sure your key is OpenPGPv4". No recent or even 
not-so-recent version of GnuPG will ever generate a v3 key.


* Likewise, there is no need to check that self-signatures do not use 
MD5, unless your keys are *very old*.


* Likewise for SHA-1. I think GnuPG stopped using SHA-1 as the default 
hash algorithm sometimes in 2009.


So all of those advices could be replaced by a single one: "Use a recent 
GnuPG version. Ideally, use the most recent version available. At the 
very least, do not use a decade-old version."


The problem with recommanding unnecessary steps is that they will 
confuse the beginner and make him think that GnuPG is more difficult to 
use than it already is.


Damien



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

[Announce] Scute 1.5.0 released

[Damien Goutte-Gattat]

Hi,

The GnuPG Project is pleased to announce the availability of Scute
1.5.0.

Scute is a PKCS#11 module built around the GnuPG Agent and the GnuPG
Smart Card Daemon. It allows you to use your OpenPGP smart card for TLS
client authentication and S/MIME mail and document signing.


Noteworthy changes in version 1.5.0 (2017-07-14)
===

* Support for TLS 1.2.

* Support for S/MIME signing. This has been tested with Thunderbird (to
  sign e-mails) and with LibreOffice (to sign OpenDocument and PDF
  files).

* Support for 4096 bit RSA keys.

* Better support for GnuPG 2.1:

  - A communication bug between GnuPG Agent and Scute, leading to failed
signatures, has been fixed.

  - Scute now relies on gpg-connect-agent to be able to always find the
socket for GnuPG Agent, no matter where that socket is actually
located.

* C_GenerateRandom function is implemented. This allows Firefox to seed
  its entropy pool using the OpenPGP smart card's random number
  generator.


Download


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

 ftp://ftp.gnupg.org/gcrypt/scute/scute-1.5.0.tar.bz2 (968k)
 ftp://ftp.gnupg.org/gcrypt/scute/scute-1.5.0.tar.bz2.sig

The same files are also available via HTTP:

 https://gnupg.org/ftp/gcrypt/scute/scute-1.5.0.tar.bz2
 https://gnupg.org/ftp/gcrypt/scute/scute-1.5.0.tar.bz2.sig


Copying
===

Scute is copyrighted by g10 Code GmbH ans licensed under the GNU General
Public License version 2 or later (GPLv2+) with the following exception:

  In addition, as a special exception, g10 Code GmbH gives permission
  to link this library: with the Mozilla Foundation's code for
  Mozilla (or with modified versions of it that use the same license
  as the "Mozilla" code), and distribute the linked executables.  You
  must obey the GNU General Public License in all respects for all of
  the code used other than "Mozilla".  If you modify the software, you
  may extend this exception to your version of the software, but you
  are not obligated to do so.  If you do not wish to do so, delete this
  exception statement from your version and from all source files.


Support
===

The Scute manual is included in the source distribution and is also
available online at . For
community support, you may ask on the gnupg-users mailing list
.

If you need commercial support, check out
.

Maintenance and development of Scute and of GnuPG as a whole is mostly
financed by donations. Please consider donating via
.



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

Re: using GnuPG card for Firefox master password

[Damien Goutte-Gattat]

Hi,

On 07/02/2017 08:51 PM, Matthias Apitz wrote:

I have a bunch of saved logins in Firefox, protected by some so called
master password. Is there a way for using the GnuPG card as the master
password, maybe some plug-in for FF?


As far as I know, not as the master password protecting Firefox's own 
password store. But what you can do is make Firefox use *another* 
password store, one that relies on GnuPG.


pass [1] is a password manager which encrypts passwords with the user's 
GnuPG key. Several plug-ins are available to instruct Firefox to use 
pass instead of its own password storage system, such as PassFF [2] or 
BrowserPass [3]. (Disclaimer: I tried none of them.)


So, when Firefox will need a password it will ask pass, which will call 
gpg, which will in turn "call" your smartcard.


An obvious drawback of this method is that you need to migrate all your 
passwords from Firefox's own storage to pass. There is at least one 
script available for that [4], but again I did not try it.


Hope that helps,

Damien

[1] https://www.passwordstore.org/
[2] https://addons.mozilla.org/en-US/firefox/addon/passff/
[3] https://github.com/dannyvankooten/browserpass
[4] https://github.com/Unode/firefox_decrypt



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

Re: How to join pubring.kbx and pubring.gpg?

[Damien Goutte-Gattat]

Hi,

On 06/16/2017 10:27 AM, Binarus wrote:

Unfortunately, I didn't find any hint on how to extract that key. It is
in the certificate for sure, and I think I will eventually be able to
dump it after playing some time with OpenSSL, but then I eventually
won't know how to integrate it into Enigmail / gpg4win.


Well, there is the Monkeysphere's pem2openpgp tool [1], but AFAIK it 
only works with *private* keys, not public keys.




Furthermore, I am still not sure if this is just a matter of
transforming the key or if the whole software / data exchange protocol
depends on the sort of key. In other words, even if I would manage to
extract the key and to integrate it into the Enigmail / gpg4win world,
would the communication partner be able to decrypt the respective messages?


No. You would generate an OpenPGP-encrypted message that your partner 
won't be able to decrypt using their S/MIME software. They would need an 
OpenPGP implementation (be it GnuPG or any other one).





The bottom line seems to be that I can't use Enigmail / gpg4win to
exchange email with communication partners which provide their keys in
form of certificates. This does not make much sense since there is a
strong trend among the big companies to provide only PGP certificates
instead of PGP keys.


You seem to be confused between OpenPGP certificates and X.509 
certificates, and I think this is the root of your problem.


Let me try to explain.

There are two completely independent standard for e-mail encryption and 
signing: OpenPGP and S/MIME.


Each standard uses its own formats. OpenPGP uses OpenPGP certificates 
(which are called "public key" out of habit, but they really are 
certificates), and S/MIME uses X.509 certificates.


Both partners in a conversation have to use the same standard, either 
OpenPGP or S/MIME (of course they can use *any* software implementing 
the same standard, because that's what standards are all about).


Now what you got from your partner is a X.509 certificate, which means 
that said partner is using S/MIME, not OpenPGP.


There's no many options here: you and your partner must agree on the 
standard you use for your communications. Either you convince your 
partner to switch to OpenPGP when he is communicating with you, or you 
switch yourself to S/MIME when you're communicating with him.




Slightly off-topic: Does anybody eventually know if and when Enigmail /
gpg4win will support certificates?


Thunderbird already supports S/MIME and X.509 certificates natively, you 
do not need Enigmail for that.



Damien

[1] http://web.monkeysphere.info/



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

Re: changing the passphrase of the secret key stored in the GnuPG card

[Damien Goutte-Gattat]

I forgot an important detail:

On 06/12/2017 01:28 PM, Damien Goutte-Gattat wrote:

First, remove the private key stubs:

   $ rm ~/.gnupg/private-keys-v1.d/*.key


This command will delete *all* your private keys. You should use it "as 
is" only if *all* your private keys are stored on a smartcard.


If you have other private keys in your keyring that are not stored on a 
smartcard, do *not* delete all files in ~/.gnupg/private-keys-v1.d! 
Instead, get the keygrip of each of your card keys


  $ gpg2 --with-keygrip --list-secret-keys

and delete only the corresponding files under ~/.gnupg/private-keys-v1.d.

Damien



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

Re: changing the passphrase of the secret key stored in the GnuPG card

[Damien Goutte-Gattat]

On 06/12/2017 07:31 AM, Matthias Apitz wrote:

Now we are on track with my question. The background is/was: what
exactly I have todo with this backup key, for example in case the GnuPG
card gets lost or stolen?


You would have to import your backup key into your private keyring using 
gpg's --import command.


First, remove the private key stubs:

  $ rm ~/.gnupg/private-keys-v1.d/*.key

Then, import your backup:

  $ gpg2 --import backup.gpg

You will then be prompted for the passphrase you choose when the backup 
was created.


At this point, it's as if you had never used a smartcard.

Once you have a new smartcard to replace your lost one, you may move the 
restored keys to the new smartcard using the keytocard command.


(Note that depending on what happened to your original card, you may 
prefer to *revoke* those keys and generate new keys.)




How can I simulate this and check if the passphrase works correctly.


Copy your current .gnupg directory to a temporary GNUPGHOME:

  $ cp -r .gnupg ~/testbackup
  $ export GNUPGHOME=~/testbackup

Then you can test the above procedure:

- Remove the key stubs:

  $ rm ~/testbackup/private-keys-v1.d/*.key

- Import your backup:

  $ gpg2 --import backup.gpg

At this point, you will know if the passphrase works correctly.

And if you want to change the passphrase of your backup:

  $ gpg2 --edit-key Matthias passwd
  $ gpg2 -o backup-with-new-password.gpg --export-secret-keys

Once you are satisfied, you can wipe the testbackup directory out.

Hope that helps,

Damien



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

Re: scute / firefox: cannot connect to GPG agent

[Damien Goutte-Gattat]

> I'll try to find a way to erase the certificate from the Yubikey.

You may also try the patch below. It should allow Scute to ignore the
data read from the token if it does not look like a proper DER-encoded
certificate. It's not a fool-proof check, but it should already catch
a lot of cases (including yours).

-- >8 --
Subject: Add safety check against bad card certificate.

* src/agent.c (scute_agent_get_cert): Reject card certificate if
it does not start with an ASN.1 sequence tag.

Signed-off-by: Damien Goutte-Gattat <dgouttegat...@incenp.org>
---
 src/agent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/agent.c b/src/agent.c
index 75d4933..d6615af 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -1284,7 +1284,7 @@ scute_agent_get_cert (int no, struct cert *cert)
   err = assuan_transact (agent_ctx, cmd, get_cert_data_cb, _s,
 NULL, NULL, NULL, NULL);
   /* Just to be safe... */
-  if (!err && cert_s.cert_der_len <= 16)
+  if (!err && (cert_s.cert_der_len <= 16 || cert_s.cert_der[0] != 0x30))
 {
   DEBUG (DBG_INFO, "bad card certificate rejected");
   err = gpg_error (GPG_ERR_BAD_CERT);
-- 
2.9.0


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

Re: scute / firefox: cannot connect to GPG agent

[Damien Goutte-Gattat]

On 06/05/2017 07:54 PM, Fabian Peter Hammerle wrote:

Ah, I didn't know I had to write the certificate onto the Yubikey.


You do not *have* to; Scute can fetch the certificate both from the 
token itself, or from the gpgsm store. But it will try first to fetch it 
from the token.


Storing the certificate on the token itself instead on relying on the 
gpgsm store allows you to use your token on a machine that is not your 
usual machine.




Could you extract the certificate from the smartcard and have a look at it?
   $ gpg --card-edit
   gpg/card> readcert 3 > file.der
   gpg/card> quit


$ od -x file.der

000 217f 0082      
020        
*
400  00ff
403


I don't pretend to be a X.509 or ASN1 expert (far from it!), but this 
does not look like a X.509 certificate at all.




gpg: error writing certificate to card: Provided object is too large

Do I have to choose a smaller key size?


Check the maximal size supported by the Yubikey:

  $ gpg-connect-agent 'SCD GETATTR EXTCAP' /bye

The output should be a line like the following:

  S EXTCAP gc=1+ki=1+fc=1+pd=1+mcl3=2048+aac=1+sm=0+si=5+dec=0+bt=0

The maximal size for the certificate to be stored on the token is 
indicated by the "mcl3" value (so, 2048 bytes in this example). Your 
DER-encoded certificate should not be bigger than that.


But if it happens that your Yubikey does not support 4096-bit 
certificates, and you still want such a certificate, then you could 
simply erase the (corrupted) certificate on the Yubikey. As I said 
above, Scute will fetch the certificate from the gpgsm store if it 
cannot find it on the token.


As far as I know there is no command in the gpg card editor to erase the 
certificate, but I *think* using the writecert command with /dev/null as 
input should do the trick (I have not tested).




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

Re: scute / firefox: cannot connect to GPG agent

[Damien Goutte-Gattat]

On 06/05/2017 07:04 PM, Fabian Peter Hammerle wrote:

scute: scute_agent_get_cert: got certificate from card with length 259
OK, this is weird. 259 bytes seems too short for a X.509 certificate, 
especially one based on 4096-bit public key (for comparison, my own 
2048-bit certificate is 1587 bytes).


Maybe an error occured when the certificate was stored on the Yubikey, 
and the certificate there is actually truncated?


Could you extract the certificate from the smartcard and have a look at 
it? Run gpg in card-edit mode, and at the prompt, use the (undocumented) 
readcert command to save the certificate to a file


  $ gpg --card-edit

  gpg/card> readcert 3 > file.der
  gpg/card> quit

Then inspect the contents of file.der, using e.g. openssl:

  $ openssl x509 -inform DER -in file.der -text



Due to scute 'rejecting certificate' I just removed my current
certificate for the auth subkey from gpgsm and created / imported a new
self-signed certificate:

> [...]

Anyway, Scute still logs the same error message:


Did you import your new certificate onto the Yubikey? Because 
independently of what your gpgsm store may contain, Scute will always 
try to fetch the certificate from the token itself.




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

Re: scute / firefox: cannot connect to GPG agent

[Damien Goutte-Gattat]

On 06/05/2017 10:20 AM, Fabian Peter Hammerle wrote:

Does anyone know what might cause the 'sharing violation' error?


I am not sure. Can you check that after starting Firefox, you still have 
only one GPG-Agent and one Scdaemon running?


If you run the following command:

  $ gpg-connect-agent "SCD GETINFO pid" /bye

(which returns the PID of the running Scdaemon), do you get the same PID 
than the one displayed in your error messages?



Damien



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

Re: scute / firefox: cannot connect to GPG agent

[Damien Goutte-Gattat]

Hi,

On 06/03/2017 12:48 AM, Fabian Peter Hammerle wrote:

As far as I understand gpg-agent is running.


Can you please check whether it is really the case? E.g., check that the 
socket indicated by "gpgconf --list-dir agent-socket" does exist?



After reading http://scute.org/scute.html/Troubleshooting.html
I noticed that $GPG_AGENT_INFO was not set.


Yes, GnuPG 2.1 does not use (nor set) that variable anymore. But Scute 
still needs it in order to locate the socket, especially now that the 
socket is no longer always located in $GNUPGHOME.


If I remember correctly, the problem goes like this:

1) Scute looks for GPG_AGENT_INFO
2) The variable does not exist, so Scute looks for the socket in $GNUPGHOME
3) The socket is not there (because it is now somewhere under 
[/var]/run), so Scute assume there's no running agent
4) Scute spawns a new agent with the --use-standard-socket option (which 
used to instruct the agent to create its listening socket in $GNUPGHOME, 
but which has no effect with GnuPG 2.1)
5) Scute still does not find the socket in $GNUPGHOME, and thus fails 
with "Cannot connect to GPG Agent"


To avoid this, you need both to set the GPG_AGENT_INFO variable and make 
sure that the agent is running before you start Firefox (simply calling 
"gpg-connect-agent /bye" is enough).




However, setting the path manually did not solve the problem:
$ gpgconf --list-dir agent-socket

/run/user/1000/gnupg/S.gpg-agent

$ GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent firefox


The GPG_AGENT_INFO variable must have the following form: 
"PATH_TO_SOCKET:PID:VERSION", where PID is the running agent's process 
ID and VERSION is the version of the agent protocol (which must be 1). 
Otherwise Scute will ignore the variable.


So try instead:

GPG_AGENT_INFO=$(gpgconf --list-dir agent-socket):0:1 firefox

(The PID can be set to zero because as far as I know Scute does not 
actually use that information.)


Hope that helps,

Damien



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

Re: Obtaining sig2 and sig3 signatures

[Damien Goutte-Gattat]

Hi,

On 05/30/2017 09:25 PM, Stefan Claas wrote:

The classical procedure would be to sign a key with a sig3 after seeing
the persons id-card in a real meeting. But who guarantees that the
id-card is not fake (if the person is a complete stranger)?


Well, no one. You rely on the ability of the signer to distinguish 
between a real ID-card and a fake ID-card. Of course, not everyone can 
spot a well-crafted fake ID (I certainly cannot).


That's one reason why some people actually object to key-signing parties 
where participants are required to show an ID-card. Another reason is 
that requiring an ID-card is equivalent to trusting the government 
emitting those cards, and not everyone is OK with that (after all one of 
the goals of the web-of-trust is to avoid the need for centralized 
authorities).




Please note, i don't want to ask people here to sign my pub key, i just
want to know what your thoughts are. :-)


I think that, for most users, certification levels are actually useless 
due to the fact that the different certification levels don't have an 
universally recognized meaning.


The OpenPGP standard (RFC 4880) says nothing about the meaning of 
certification levels 2 and 3. It is up to the signing user to decide 
what is a "casual certification" (level 2) and what is a "positive 
certification" (level 3).


With the meaning of a sig2 or a sig3 depending on the certification 
policy of the signer, the whole feature is quite pointless in my opinion.


(Maybe certification levels can still be useful when OpenPGP is used in 
a closed, controlled setup--e.g. within an organization which can define 
its own rules, to be followed by all its members. Maybe.)


Incidentally, I also think that many users will be much happier with the 
TOFU trust model, where they won't have to care about all this "key 
signing stuff" (unless they want to). Discussing about certification 
levels will likely be irrelevant when TOFU will become the default trust 
model.




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

Re: Using a GnuPG CCID card in another computer (follow-up)

[Damien Goutte-Gattat]

On 05/16/2017 07:55 AM, Matthias Apitz wrote:

The question remains: Why I do have to move the files below .gnupg/ to
the other workstation?


The card only contains the private keys. GnuPG also needs some 
informations that are only contained in the public parts, such as the 
User IDs associated with the key and the bindings between a primary key 
and its subkeys.


So while you no not have to move *all* the files below .gnupg, you at 
least need to import your *public* key onto your other workstation.


(That's why the card editor of GnuPG has a "fetch" command. The idea is 
that you put your public key in a publicly-accessible location, and make 
the "URL" field of your card point to that location. With that, upon 
arriving onto a new computer--with an empty or inexisting .gnupg--, you 
can get a working setup just by inserting your card, firing up the card 
editor, and using the "fetch" command".)




And, what are the files below .gnupg/private-keys-v1.d are exactly?


They normally contain the private key themselves. When the private keys 
are stored on a smartcard, they are "stubs", whose purpose is to inform 
GnuPG that the keys are on a smartcard (notably, they contain the serial 
number of said smartcard).


GnuPG should normally re-create those stubs automatically if they do not 
exist when you run the --card-status command, so you should not have to 
copy them over manually.


What is troubling in your experience is that you said there was "no key 
in the card" when you first run "gpg2 --card-status" on the new 
workstation. I have no explanation for that.


Damien



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

Re: help

[Damien Goutte-Gattat]

Hi,

On 02/27/2017 04:07 PM, r...@riseup.net wrote:

I'll use my master key offline. Following this guidelines:
https://incenp.org/notes/2015/using-an-offline-gnupg-master-key.html

I also implemented the Appelbaum's config.(Riseup Best Practices) Will
it work properly if the Master Key isn't on my machine?


It should.

Note, however, that Riseup's Best Practices [1] and proposed 
configuration file [2] are partially obsolete, *especially* if you are 
using GnuPG 2.1. Many of the proposed options and advices are not needed 
anymore, as GnuPG already does The Right Thing.




And the following faults are coming:
 gpg: keyserver option 'ca-cert-file' is obsolete; please use
'hkp-cacert' in dirmngr.conf


If you're using the sks-keyservers.net pool you no longer need to 
provide GnuPG with the CA certificate file, as it is now bundled with 
GnuPG (>= 2.1.11) and automatically used when needed. (And with GnuPG >= 
2.1.16 you will no longer even need to explicity set the keyserver 
option, as hkps.pool.sks-keyservers.net is already the default.)




gpg: keyserver option 'no-try-dns-srv' is unknown


This option no longer exists, but I *think* that if you really want to, 
you can disable SRV lookups by explicitly specifying a port number when 
setting the keyserver, as in:


  keyserver hkps.pool.sks-keyservers.net:443


Damien

--
[1] https://riseup.net/en/security/message-security/openpgp/best-practices
[2] 
https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf




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

Re: GPG, subkeys smartcard and computer

[Damien Goutte-Gattat]

On 02/19/2017 03:11 PM, Peter Lebbing wrote:

However, maybe someone has come across a reason to do it where it would
be worth the hassle. There certainly are people using multiple S subkeys.


Some time ago, I did some experiments with a RSA master key with two 
sets of subkeys: RSA subkeys and ECC-based subkeys (ECDSA for the 
signing subkey, ECDH for the encryption subkey).


The idea was to test whether such a setup could be used by someone 
wanting to use elliptic-curve cryptography, but at the same time not 
wanting to cut herself from people still using GnuPG 2.0.x (which has no 
support for ECC).


Let's say Alice and Bob both use GnuPG 2.1, but Charlie uses GnuPG 2.0. 
And Alice uses the setup described above, where the ECC-based subkeys 
were created *after* the RSA-based subkeys.


For encryption: When Bob wants to encrypt a message to Alice, his gpg 
program automatically selects the latest encryption subkey it can use, 
that is, the ECDH subkey. On the other hand, when Charlie wants to 
encrypt a message to Alice, his gpg program skips the unsupported ECDH 
subkey and automatically selects the remaining RSA subkey. So everything 
work, Alice and Bob can benefit from ECC support in GnuPG 2.1 while 
still allowing Charlie to use RSA.


For signing: Alice signs her messages with *both* her RSA subkey and her 
ECDSA subkey (using multiple --local-user options), allowing both Bob 
and Charlie to verify her messages even though Charlie is stuck with 
GnuPG 2.0 and RSA.


(Eventually, Charlie will upgrade to GnuPG 2.1, and Alice will then 
revoke her RSA subkeys.)


Disclaimer: I am not advocating such a setup, that I don't even actually 
use. I did those tests mostly out of curiosity (I stick to RSA keys even 
with GnuPG 2.1, so I have no need to worry about backward 
compatibility). But I guess it's a possible reason for wanting more than 
one set of subkeys.




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

Re: content of private-keys-v1.d

[Damien Goutte-Gattat]

On 02/08/2017 06:25 PM, Werner Koch wrote:

The format of the private key files is documented in

gnupg/agent/keyformat.txt


Obviously I had completely overlooked this file, my bad.

Sorry for the disinformation. It's good to know that the documentation 
is there.



Damien



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

Re: content of private-keys-v1.d

[Damien Goutte-Gattat]

On 02/08/2017 12:13 PM, Marko Bauhardt wrote:

You mean that this “stub” contains no information which can be use to
sign/decrypt/authenticate?


Yes. The stub contains only the serial number of the smartcard on which
the private key is stored.



Or in other words in case someone steal this key, he/she can nothing
do with that particular key, only in case the GPG key is located on
a smartcard?


The stub is completely useless without the corresponding smartcard, yes.



But if the key is not on the smart card this corresponding key can
be use to sign/enc/auth?


If the key is not on a smartcard, then the file contains the whole
private key. Note, however, that the key is stored in an encrypted form,
which means that stealing the file is not enough: your attacker would
also need to know your passphrase to make any use of the key.



I can not really find some detailed documentation of the
`private-keys-v1.d` folder. Do you have some docu?


I don't think it has really been documented. I guess the source code 
*is* the documentation.



Damien



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

Re: content of private-keys-v1.d

[Damien Goutte-Gattat]

Hi,

On 02/08/2017 08:23 AM, Marko Bauhardt wrote:

My question is. What is this for a key and for what is that key used
for? The folder name `private-keys-v1.d` sounds like to store keys
from GPG version 1.x. But i’m using 2.0.x. Any comments about his
folder?


This folder holds all the private keys. It was initially used only by 
gpgsm (for S/MIME keys), but since GnuPG 2.1 it is also used by gpg (for 
OpenPGP keys). The "v1" part in the name has nothing to do with the 
version of GnuPG.




As i said before, i want to not save any key on my machine. And for
now i’m not sure if i reach this goal because this new key sounds
like it is a private key.


Even when your private keys are stored on a smartcard, you would still 
have a corresponding file in the private-keys-v1.d directory. But this 
file is only a "stub", that is, it only tells GnuPG that the actual key 
material is stored on a smartcard.



Damien



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

Re: sha1 pgp fingerprint

[Damien Goutte-Gattat]

On 01/26/2017 12:47 AM, sivmu wrote:

The question I have not yet found any clear answer for, is why is nobody
talking about this and should pgp keys be identified by a stronger hash
alogrithm in the future?


People *do* talk about this. But a change of the hash algorithm used for 
fingerprinting keys cannot be decided unilateraly by GnuPG developers. 
All OpenPGP implementations have to agree on such a change, that's why 
the discussions occur on the IETF OpenPGP mailing list.


See for example those threads:

https://www.ietf.org/mail-archive/web/openpgp/current/msg08265.html

https://www.ietf.org/mail-archive/web/openpgp/current/msg08693.html



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

Re: gnupg website

[Damien Goutte-Gattat]

On 01/25/2017 02:41 PM, Robert J. Hansen wrote:

For that matter, I'm still in the dark as to what the big problem with
three-key 3DES is.  The best attack against it requires more RAM than
exists in the entire world and only reduces it to 112 bits.


The main problem would be its 64-bit block size. Apparently there's a 
"practical" attack against 64-bit ciphers as used in TLS [1].


That's probably reason enough to avoid 3DES whenever possible (when a 
128-bit cipher is available).


[1] https://eprint.iacr.org/2016/798





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

Re: Trust signature domain

[Damien Goutte-Gattat]

Hi,

On 01/18/2017 03:51 PM, John Lane wrote:

I think things look ok up to step 9 and point (a) and (b) appear to work
as I expect but (c) doesn't. I'd really appreciate some feedback about
what is happening in:
step 10 (trust level 1 restricted to example.org)
step 14 (trust level 2 restricted to example.org)
step 16 (trust level 2 restricted to example.es)

It would appear that any domain restriction disables trust completely!


I believe there's a bug in the handling of the regular expression 
associated with a trust signature. I've just submitted a patch to fix it 
[1]. With that patch applied, I get the expected result for step 10 
(Blake's key is fully valid, not the others') and step 14 (Blake's key 
is fully valid, and so are Chloe's and David's keys).


For step 16, none of the keys are valid, but I think that's the expected 
behavior: you signed Introducer with a level 2 trust signature 
restricted to example.es, so the signature of Blake's key (which as an 
example.org UID) is rightly ignored. Blake's key is thus of unknown 
validity and his signatures on Chloe's and David's keys are ignored as well.


(Side note: you can use the '%transient-key' directive when 
batch-generating keys for testing purposes. This instructs GnuPG to use 
a less secure but faster random number generator, thus speeding up the 
generation process.)


Damien

[1] https://lists.gnupg.org/pipermail/gnupg-devel/2017-January/032472.html



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

Re: gpg-agent has to be restarted after GnuPG SmartCard pulled from reader

[Damien Goutte-Gattat]

On 01/06/2017 10:06 AM, gnupg-users.d...@o.banes.ch wrote:

I was under the impression the OmniKey 3121 is a real reader since it is
on the how to [1].


For what is worth, I have two such readers, which are working flawlessly 
with the ccid driver [1] and with 2048-bit keys. I have not tried them 
with the internal driver.




What would be a good alternative bevore I buy another bad one.


I also have a SCM 3500 reader from SCM Microsystems (now Identiv), again 
working flawlessly with the ccid driver.




p.s. in the meantime a made a script which tails the scdaemon.log and
waits for "Removal of a card:"
and then kills the gpg-agent. Not a proper solution - but working so far.


Instead of watching the log, you could use a feature of Scdaemon: if the 
file $GNUPGHOME/scd-event exists and is executable, it will be called on 
every card reader status change.


For example, to act upon card removal, you could have the following:

  #!/bin/sh

  case "$8" in
  NOCARD)
  # do something
  ;;
  esac

See doc/examples/scd-event in GnuPG's source for more details of what 
this script can do.



Damien


[1] http://pcsclite.alioth.debian.org/ccid.html



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

Re: Unable to import Private Key

[Damien Goutte-Gattat]

On 12/31/2016 11:22 AM, Guy Wyers wrote:

The command used to build this export was the following (executed with the
-vv option to get all the info):

  $ gpg2 -vv -ao secret-key.asc --export-secret-keys 

gpg: writing to 'secret-key.asc'
gpg: key 69F91A22: asking agent for the secret parts
gpg: key 69F91A22: error receiving key from agent: End of file - skipped
gpg: key 69F91A22/9D2311A4: asking agent for the secret parts


So gpg asks the agent for your secret primary key (69F91A22) but the 
agent cannot provide it. Then it asks for the secret subkey and gets it.


Next questions:

* What exact version of GnuPG are you using? It looks like you are using 
a version from the 2.1 branch, not 2.0. Please give the output of `gpg2 
--version`.


* Can you *use* your secret primary key? Try performing any action 
requiring the secret primary key (such as signing a message, assuming 
you do not have a signing subkey).


* If you can reproduce the issue at will, can you try exporting the 
private keys again, but with logging of debug informations?


Add the following lines to your ~/.gnupg/gpg-agent.conf file (create 
that file if it does not already exist):


  log-file /wherever/you/want.log
  debug 1024

Reload the agent (gpgconf --reload gpg-agent) and try exporting again.



Any ideas?


It's starting to look like a communication problem between gpg and the 
agent. What problem exactly, I have no clue.




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

Re: Unable to import Private Key

[Damien Goutte-Gattat]

On 12/27/2016 11:16 AM, MFPA wrote:

The --export-secret-subkeys command will do what it says on the tin.


That option would still generate a secret key packet for the primary 
key, it's just that this packet would not actually contain any key material.


Here, what has been generated is a file containing only a secret subkey 
packet (and the associated binding signature). That's not the result of 
using --export-secret-subkeys.




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

Re: Unable to import Private Key

[Damien Goutte-Gattat]

On 12/26/2016 06:52 PM, Guy Wyers wrote:

- Can I somehow recover from this? I guess that, at least theoretically,
the public should be "derivable" from the private key?


The problem here is not that you are missing the public key (the public 
key *is* derivable from the private key, and GnuPG would automatically 
extract the public key upon importing the private key).


The problem is that you are missing the secret *primary* key to which 
this secret subkey should be attached.


If you do not have a backup of that primary key, I am not sure you will 
be able to recover.


At least with GnuPG 2.1, it should be possible to re-attach the subkey 
to a new primary key (because GnuPG 2.1 allows to "create" a key from a 
pre-existing key if you know its keygrip), *but* the newly re-attached 
key would still have a different key creation time and thus a different 
key ID... meaning that it could not be used to decrypt messages 
encrypted to the original key.




- How did I end up with this truncated export? As far as I remember -even
if it was long long time ago- I followed the standard instructions for
"storing my private key in a safe place".M


As far as I know, the only way to export a subkey only is to explicitly 
specify that subkey by its key ID with an appended '!', as in the 
following example:


   $ gpg2 --output backup.gpg --export-secret-keys '0xDECAFBAD!'

Otherwise, GnuPG will always export the primary key and all its subkeys.

What are those "standard instructions" you are referring to? If you were 
instructed to backup only your secret subkey instead of your entire 
private keyring, I am afraid you have been badly misled.




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

Re: Unable to import Private Key

[Damien Goutte-Gattat]

On 12/26/2016 10:34 AM, Guy Wyers wrote:

Here is the output I get with the -vv option:


Your file seems to contain only a private *sub* key. I don't think GnuPG 
can import such a file (I've just tested with a similar file on my 
system with GnuPG 2.1.17, I got a similar result).




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