Re: SKS Keyserver Network Under Attack

2019-06-30 Thread Guilhem Moulin
On Sun, 30 Jun 2019 at 22:23:11 +, Alyssa Ross wrote:
>> Third-party signatures from locally unknown certificates are arguably
>> not so useful, so how about using ?--keyserver-options import-clean??
>> (Or even making it the default behavior?)  Of course it's not perfect as
>> it still clutters network traffic and gpg(1) needs to clean up the mess
>> client-side (which is slow and CPU expensive), but at least it mitigates
>> the DoS attack: it doesn't prevent keyring updates, and limits the bloat
>> on disk.
> 
> Alas, this doesn't fully mitigate the issue, because it's not exactly
> difficult to get a key into somebody's keyring, especially with the
> existence of the auto-key-retrieve option.

Ah yeah, good point.  At least this vastly limits the scope of the
attack: instead of affecting every keyring upon refresh/import, the
attacker needs to somewhat target which keyring they want to poison.

-- 
Guilhem.


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


Re: SKS Keyserver Network Under Attack

2019-06-30 Thread Guilhem Moulin
On Sun, 30 Jun 2019 at 00:36:19 -0700, Mirimir via Gnupg-users wrote:
> | High-risk users should stop using the keyserver network immediately.
> 
> So OK, I can purge requests to SKS keyservers from my machines. But what
> about upstream impacts? As I understand it, GnuPG authentication is
> pervasive. And I suspect that getting missing keys from SKS is common.
> As an error trap, if nothing else.

Third-party signatures from locally unknown certificates are arguably
not so useful, so how about using ‘--keyserver-options import-clean’?
(Or even making it the default behavior?)  Of course it's not perfect as
it still clutters network traffic and gpg(1) needs to clean up the mess
client-side (which is slow and CPU expensive), but at least it mitigates
the DoS attack: it doesn't prevent keyring updates, and limits the bloat
on disk.

Compare

~$ export GNUPGHOME="$(mktemp --tmpdir=/dev/shm --directory)"
~$ alias time="command time -f '%E (%U user, %S sys)  %P CPU  %Mk maxres'"
~$ gpg --import /usr/share/keyrings/*.gpg
~$ gpg --with-colons --list-sigs | grep -c ^pub:
1187
~$ gpg --with-colons --list-sigs | grep -c ^sig:
56001
~$ stat -c %s "$GNUPGHOME/pubring.kbx"
34041308
~$ time gpg --recv-keys \
C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 \
CC11BE7CBBED77B120F37B011DCBDC01B44427C7
gpg: key 1DCBDC01B44427C7: 149109 signatures not checked due to missing keys
gpg: error writing keyring '…/pubring.kbx': Provided object is too large
gpg: key F20691179038E5C6: 54608 signatures not checked due to missing keys
gpg: error writing keyring '…/pubring.kbx': Provided object is too large
[…]
Command exited with non-zero status 2
10:53.44 (269.47 user, 362.81 sys)  96% CPU  330976k maxres

(which fails the keyring update operation) with

[…]
~$ time gpg --keyserver-options import-clean --recv-keys \
C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 \
CC11BE7CBBED77B120F37B011DCBDC01B44427C7
gpg: key 1DCBDC01B44427C7: 1 duplicate signature removed
gpg: key 1DCBDC01B44427C7: 1 signature reordered
gpg: key 1DCBDC01B44427C7: public key "Robert J. Hansen 
" imported
gpg: key F20691179038E5C6: 2 duplicate signatures removed
gpg: key F20691179038E5C6: 2 signatures reordered
gpg: key F20691179038E5C6: "Daniel Kahn Gillmor " 
not changed
gpg: no ultimately trusted keys found
gpg: Total number processed: 2
gpg:   imported: 1
gpg:  unchanged: 1
49:48.80 (1668.47 user, 1305.03 sys)  99% CPU  190840k maxres

(The initial import of /usr/share/keyrings/*.gpg is merely there to
start with a non-trivial keyring.  In particular, a keyring containing
certificates that issued third-party signatures on 1DCBDC01B44427C7 and
F20691179038E5C6.  The keyring even contains a non-poisoned version of
dkg's key, as on my system the glob matches 
‘/usr/share/keyrings/debian-keyring.gpg’.)

I suppose validating keyservers are the way to go, but it seems like
there is currently no good solution for third-party signatures.  For
workflow relying on these (at least for locally known signers), or which
for some other reason need to stick to SKS, a possible mitigation is to
pass `--keyserver-options import-clean`.  As seen above refreshing the
keyring might take a veeery long time (possibly room for improvement,
from an algorithmic perspective I don't get why filtering signature
packets from unknown signers is so slow), but at least succeeds in
getting updates from SKS. 

-- 
Guilhem.


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


Re: Utilizing facts of homedir organization (was: Exact definition of token S/N field for --with-colons)

2018-11-09 Thread Guilhem Moulin
Hi,

On Fri, 09 Nov 2018 at 16:12:19 +0100, Peter Lebbing wrote:
> On 07/10/2018 03:01, Daniel Kahn Gillmor wrote:
>> Does this make sense?  you just need to make sure you tie the version of
>> gpg and the keyring into the same initramfs build time.
> 
> The problem is that the gpg invocation is not at the time of building
> the initramfs.

It wasn't, but the hook file is a mere shell script where we can do
pretty much everything (as long as it's nullipotent from the main
system's perspective — besides creating the initramfs image of course).
In fact I implemented dkg's suggestion:

gpg --homedir="$DESTDIR/cryptroot/gnupghome" … --import <"$PUBRING"

is called by the hook file when the initramfs image is generated, using
the very same gpg(1) binary that's copied to the initramfs.  Hence we're
not relying on its homedir's internals, and we're safe as long as gpg(1)
is able to make use of the homedir content it generates (which is
definitely a reasonable assumption), even if the ‘gnupg’ package is
later is upgraded to a version with a different keyring format or file
name, and diverges from the version included in the initramfs image.
(In fact the ‘gnupg’ package can even be deleted on systems where one is
certain that the initramfs image won't be updated anymore.)

> I have an idea about elegantly handling the fact that the smartcard stub
> is not known during boot, since there doesn't seem to be a stable
> interface to transferring these stubs, and invoking gpg at initramfs
> build time will leave a running gpg-agent, which is rather avoided. I'll
> work this out when I have the time.

I look forward to see that! :-)  FWIW it's not the `gpg` invocation
during initramfs generation that's a blocker, but the fact that listing
secret key material spawns a gpg-agent(1) process hence breaks
nullpotency.  We could make make the hook nullpotent, but at the expense
of a brittle and racy logic I'm reluctant to write or merge in to
‘cryptsetup-initramfs’.

Cheers,
-- 
Guilhem.


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


Re: Utilizing facts of homedir organization (was: Exact definition of token S/N field for --with-colons)

2018-09-24 Thread Guilhem Moulin
Hi there,

On Sun, 23 Sep 2018 at 16:19:22 -0400, Daniel Kahn Gillmor wrote:
> But the real question is: why do you need this, and what do you intend
> to do with it?

I believe it was a follow up to https://bugs.debian.org/903163, messages
≥160 in particular.  TL;DR: for smartcard usage (decryption in our case)
at initramfs stage we need a public keyring containing the relevant
public key(s), and copy it into the initramfs image.

Cheers,
-- 
Guilhem.


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


Re: "best" ed25519/curve25519 setup?

2018-01-23 Thread Guilhem Moulin
On Tue, 23 Jan 2018 at 09:01:25 +0100, Simon Josefsson wrote:
> Guilhem Moulin <guil...@fripost.org> writes:
>> On Mon, 01 Jan 2018 at 14:28:34 +0100, Simon Josefsson wrote:
>>> I want to use ed25519/curve25519, but right now I have an offline
>>> master RSA key with three subkeys.  Does it work well to add new
>>> subkeys for Ed25519/Curve25519?  What is the user experience in
>>> various applications?  I'm thinking MUAs, SSH, git, gpg itself, and
>>> also more exotic approaches like K9Mail.
>>
>> AFAICT multiple Ed25519/Curve25519 subkeys work fine, with the following
>> caveats:
>>
>> * You'll want to sign with both your Ed25519 and non-ECC (sub-)keys,
>>   otherwise non-ECC capable OpenPGP implementations won't be able to
>>   verify your data signatures.  You can do this by adding
>>
>>   local-user $FINGERPRINT!
>>   
>>   for each (sub)key to sign with (note the trailing exclamation mark
>>   to specify the subkey).
> 
> Have you noticed any problem with this approach?  I could imagine some
> software might be equally confused by two signatures, or become confused
> that GnuPG "under the hood" adds another signature.

There are non RFC-compliant implementations for sure, but FWIW RFC 4880
allows multiple signatures on the same data.  That's the last octet of
One-Pass Signature Packets, cf. RFC 4880 Sec. 5.4:

“A one-octet number holding a flag showing whether the signature is
 nested.  A zero value indicates that the next packet is another
 One-Pass Signature packet that describes another signature to be
 applied to the same message data.”
— https://tools.ietf.org/html/rfc4880#section-5.4

That's often used in OpenPGP key transition statements, for instance.

That being said I didn't add a signing-capable Ed25519 subkey along with
my RSA one, and the only OpenPGP implementation I use is GnuPG, so I
don't know how well other implementations support nested signatures.
 
> I wonder if I should re-use the RSA subkeys from my current key into the
> new one...  I suppose for SSH it would be useful, but for anything
> OpenPGP-related it should be based on the master key id, right?

I see no reason to do that for signing and decryption, indeed.

-- 
Guilhem.


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


Re: "best" ed25519/curve25519 setup?

2018-01-01 Thread Guilhem Moulin
Hi Simon,

On Mon, 01 Jan 2018 at 14:28:34 +0100, Simon Josefsson wrote:
> I want to use ed25519/curve25519, but right now I have an offline
> master RSA key with three subkeys.  Does it work well to add new
> subkeys for Ed25519/Curve25519?  What is the user experience in
> various applications?  I'm thinking MUAs, SSH, git, gpg itself, and
> also more exotic approaches like K9Mail.

AFAICT multiple Ed25519/Curve25519 subkeys work fine, with the following
caveats:

  * You'll want to sign with both your Ed25519 and non-ECC (sub-)keys,
otherwise non-ECC capable OpenPGP implementations won't be able to
verify your data signatures.  You can do this by adding

local-user $FINGERPRINT!

for each (sub)key to sign with (note the trailing exclamation mark
to specify the subkey).

  * You'll want to create your Curve25519 encryption subkey *after* the
non-ECC one, as `gpg --encrypt --recipient $KEYID` only uses the
most recent valid encryption-capable subkey, I think.  So if you
have an older non-ECC encryption subkey, older gpg(1) will encrypt
to it while ≥2.1 will use the Curve25519 encryption subkey.

  * You can use multiple authentication subkeys with gpg-agent's SSH
agent emulation, but `gpg --export-ssh-key $KEYID` currently only
exports the most recent authentication (sub)key, so you'll need to
generate the relevant authorized_keys(5) for OpenSSH as follows:

   gpg --with-colons --list-key $FINGERPRINT \
   | sed -nr 
's/^[ps]ub:[^deir:]*(:[^:]*){2}:([0-9a-fA-F]+)(:[^:]*){7}a.*/\2/p' \
   | xargs -I{} gpg --export-ssh-key {}\!

(note the trailing exclamation mark to specify the subkey).  Recent
OpenSSH's PubkeyAcceptedKeyTypes default value contain “ssh-ed25519,
ssh-rsa” in that order so the Ed25519 (sub)key will be tried first.
Older OpenSSH — that don't support Ed25519 — will fallback to the
RSA (sub)key.

> The alternative for me of course is to create a brand new key, with an
> offline Ed25519 master key, plus some subkeys.  Has anyone done this,
> and can share their experience?

IMHO it's too early to use an Ed25519 master key in production, because
there are still a lot of legacy systems out there and that will make the
whole key unusable for encryption and verification.  It's fine to start
bring such key to KSPs to improve its reputation and have a less painful
key rollover later, though :-)

Cheers,
-- 
Guilhem.


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


Re: Houston, we have a problem

2017-09-22 Thread Guilhem Moulin
On Fri, 22 Sep 2017 at 22:32:37 +0200, Kristian Fiskerstrand wrote:
> And what happens if you do gpg --import-options import-clean --recv-key
> ? is the bad MPI value sigs removed or still there in that case?

Should be `gpg --keyserver-options import-clean --recv-key $keyid`; or
alternatively, `gpg --edit-key $keyid clean save` if you want to do it
offline.  Both commands removes these “Bad MPI value” sigs here (2.2.1),
and `--check-sigs` reports that all remaining signatures are indeed
valid.

-- 
Guilhem.


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


Re: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?

2017-06-30 Thread Guilhem Moulin
On Fri, 30 Jun 2017 at 18:29:41 +0200, Peter Lebbing wrote:
> It would be really good if the SSH agent protocol would be extended to
> communicate on which tty a request comes in. Without updates to the SSH
> protocol, there is simply no way to know where it comes from.

I also hope some day this will happen :-)
 
> However, I think many people work around this problem by a) using a
> graphical pinentry and b) using a single graphical session. As long as
> one also refrains from SSH'ing from a remote terminal, with the
> combination, you've circumvented the problem by just using the
> effectively singleton graphical session :-).

Another other (somewhat ugly) hack is to define a ProxyCommand in your
ssh_config(5) file.

ProxyCommand sh -c 'gpg-connect-agent updatestartuptty /bye >/dev/null && 
nc "$0" "$1"' %h %p

That one is particularly ugly as children are kept alive during the whole
time of the SSH session (and file descriptors are wasted for the pipe
and the socket):

ssh example.net
  └─sh -c gpg-connect-agent updatestartuptty /bye >/dev/null && nc "$0" 
"$1" example.net 22
  └─nc odin.guilhem.org 22

With recent OpenSSH and OpenBSD's implementation of nc(1)
(netcat-openbsd package on Debian) it's possible to have the
ProxyCommand pass the connected socket back to ssh and exit, so there is
no wasted ressource during the session:

ProxyCommand sh -c 'gpg-connect-agent updatestartuptty /bye >/dev/null && 
nc -F "$0" "$1"' %h %p
ProxyUseFDpass yes

Still, it's unfortunate to have to fork a shell just for that.  I wrote
a little C wrapper (to call the Assuan command, connect to the remote
host, pass the descriptor, and exit) some time ago, but clearly the
proper fix is to extend the SSH agent protocol.

-- 
Guilhem.


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


Re: Key corruption: duplicate signatures and usage flags

2017-06-21 Thread Guilhem Moulin
Hi Martin,

On Wed, 21 Jun 2017 at 11:03:40 +0200, martin f krafft wrote:
> And then check this out:
> 
> % gpg --edit-key 0x55C9882D999BBCC4
> […]
> 
> key 55C9882D999BBCC4:
> 24 duplicate signatures removed
> 
> That's a bit weird. Where do these come from?

The OpenPGP packets were not ordered properly, and gpg tried to clean
that up.  (Typically the signatures were placed under a subkey or the
wrong UID, then reordered to be placed under the proper component;
duplicate sigs currently arise when the key is refreshed.)  See issue
2236 for details and background: https://dev.gnupg.org/T2236

Cheers,
-- 
Guilhem.


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


Re: Signatures on a subkey?

2017-01-14 Thread Guilhem Moulin
Hi,

On Sat, 14 Jan 2017 at 12:17:01 +, MFPA wrote:
> In fact, nearly a hundred signatures seem to be on the subkey
> 0x73CC004C3EE4249E rather than on any of the UIDs.
> […]
> Can anybody explain?

Using GnuPG ≥2.1.13, running `gpg --edit-key $keyID check save` should
fix it locally, cf. https://bugs.gnupg.org/gnupg/issue2236 .  (But the
packets will remain badly ordered on the server.)

-- 
Guilhem.


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


Re: With colons: Where is my curve? (rsa+ecc mixed key)

2016-06-15 Thread Guilhem Moulin
On Tue, 14 Jun 2016 at 23:17:59 +0200, Werner Koch wrote:
> On Tue, 14 Jun 2016 14:11, manto...@vollbio.de said:
>> This key has been created as a more or less default 3k RSA key, and I added 
>> an
>> ECC encryption subkey with curve25519 after creation.
>> What I am missing is the curve field filled for the subkey.
> 
> Ooops.  Here is the fix I just pushed to the repo:

FWIW, the exact same fix I proposed on February 2nd in
<1454434791-31608-1-git-send-email-guil...@fripost.org> was overlooked
:-(  Good that it now landed to master, though.

-- 
Guilhem.


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


Alternative to ‘--keyserver-options auto-key-retrieve’ under 2.1.x

2016-02-12 Thread Guilhem Moulin
Hi there,

With 1.4.x and 2.0.x ‘--keyserver-options auto-key-retrieve’ provided a
convenient way to automatically download a missing key, when verifying a
message signature in the MUA for instance.

However it seems to be a noop with 2.1.11, unless the deprecated option
‘--keyserver’ is also given.  From the manpage it looks like only some
not all keyserver options are deprecated, and ‘auto-key-retrieve’ in not
among them.  Is there a way around to tell gpg to retrieve the key via
dirmngr?

Thanks,
cheers,
-- 
Guilhem.


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


Re: Alternative to ‘--keyserver-options auto-key-retrieve’ under 2.1.x

2016-02-12 Thread Guilhem Moulin
On Fri, 12 Feb 2016 at 20:57:18 +0100, Werner Koch wrote:
> On Fri, 12 Feb 2016 13:51, guil...@fripost.org said:
>> However it seems to be a noop with 2.1.11, unless the deprecated option
>> ‘--keyserver’ is also given.  From the manpage it looks like only some
>> not all keyserver options are deprecated, and ‘auto-key-retrieve’ in not
>> among them.  Is there a way around to tell gpg to retrieve the key via
>> dirmngr?
> 
> It works for me using a fresh GNUPGHOME with 
> keyserver hkp://keys.mayfirst.org
> set in dirmngr.conf and no gpg.conf:

Oops right, in fact I'm no longer able to reproduce that either.  I
guess there was something on the line somehow…  Sorry for the noise.

-- 
Guilhem.


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


Re: Why gpg 2.1.9 cannot export secret key without passphrase?

2015-11-27 Thread Guilhem Moulin
On Fri, 27 Nov 2015 at 12:39:30 +0300, Dmitrii Tcvetkov wrote:
> In this case passphrase is needed to decrypt private key from keyring.
> Becuase of passphrase is not provided gpg-agent can't give gpg the
> private key. 

Or perhaps Andrey tries to export an *unprotected* private key using
GnuPG 2.1.  In that case this seems to be a known issue [0].

> Private key exports in cleartext.

I think this is incorrect.  gpg --export's output is always in the
OpenPGP format (possibly armored), while as of 2.1 private material is
stored in another format (in ~/.gnupg/private-keys-v1.d/$KEYGRIP.key).
Thus the agent asks for the passphrase to decrypt the private key, and
gpg reencrypts it on the fly (using the same passphrase).  gpg2(1) also
says:

  --export-secret-keys

  GnuPG may ask you to enter the passphrase for the key.  This is
  required because the internal protection method of the secret key is
  different from the one specified by the OpenPGP protocol.

Indeed ‘gpg2 --export-secret-keys $KEYID | gpg --list-only --list-packets’
tells me that the secret material is protected.

-- 
Guilhem.

[0] https://bugs.gnupg.org/gnupg/issue2070


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


Re: [HowTo] use gpg2.1 with an onion service

2015-09-19 Thread Guilhem Moulin
On Thu, 17 Sep 2015 at 13:56:51 +0200, Werner Koch wrote:
> To add this flag I need to find documentation on how to route DNS
> requests via tor.  A simple  record lookup is not sufficient.

Unfortunately this doesn't seem to be possible currently, since at the
end of the circuit creation the exit node replies with a single IP and
TTL [0].  (Tor is TCP-only, hence not suitable to route DNS packets; DNS
resolution is left to SOCKSv5 server [the tor client], which in turns
delegates it to the exit node.)

There is a proposed amendment to the Tor protocol [1] to support full
DNS (and DNSSEC) resolution, but the proposal is still sketchy and has
never been implemented.

-- 
Guilhem.

[0] https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt section 6.2
[1] 
https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.txt


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


Re: 31C3, keysigning party

2014-12-11 Thread Guilhem Moulin
On Thu, 11 Dec 2014 at 13:22:28 +0100, Peter Lebbing wrote:
 On 11/12/14 11:39, Werner Koch wrote:
 I will be at the 31C3 at Hamburg from the 28th (late afternoon) to the
 30th.  You may find me at the FSFE Assembly or ask there for my local
 communication parameters.
 
 I intend to organise a keysigning party if no one else does.

There is one advertized already:

  https://events.ccc.de/congress/2014/wiki/Session:Keysigning_Party

 Now I'm considering a mixed-mode party, basing on Sassaman-Efficient,
 but falling back to slips of paper as produced by e.g. gpg-key2ps for
 people who brought those from home and don't have access to a printer
 while at the congress. Oh, and there's this 2D barcode keysigning
 thing as well, should look it up.

You'll find an alternative to gpg-key2ps(1) in the latest signing-party
package: gpg-key2latex(1).  It produces a nicer output IMHO, including
UAT (photo) and QR code, at the expense of heavier dependencies (such as
texlive).  Disclaimer: I'm the author of that script :-P

-- 
Guilhem.


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