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


If you need commercial support, check out 
.


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


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


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