Re: SKS Keyserver Network Under Attack
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
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)
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)
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?
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?
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
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?
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
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?
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)
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
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
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?
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
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
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
