Re: sopv-gpgpv: an implementation of the verification-only subset of the Stateless OpenPGP CLI using gpgv as a backend
Werner Koch via Gnupg-users writes: > Hi! > > while talking about gpgv, let me remind you about the new > --assert-signer option which can be used as a replacement for gpgv. > > --assert-signer fpr_or_file > > This option checks whether at least one valid signature on file has > been made with the specified key. The key is either specified as a > fingerprint or a file listing fingerprints. The fingerprint must be > given or listed in compact format (no colons or spaces in between). > This option can be given multiple times and each fingerprint is > checked against the signing key as well as the corresponding > primary key. If fpr_or_file specifies a file, empty lines are > ignored as well as all lines starting with a hash sign. With this > option gpg is guaranteed to return with an exit code of 0 if and > only if a signature has been encountered, is valid, and the key > matches one of the fingerprints given by this option. > > This option is available since 2.4.1. I've been wanting a parameter like that! Does it check key expiration times by default? Is it possible to disable/enable that behaviour? Sometimes (and a safe default behaviour) you want to reject signatures signed by an expired key, although sometimes you want to permit that to confirm that some old signature was created by some expired key. /Simon signature.asc Description: PGP signature ___ 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
vuori writes: > On Tue, Apr 11, 2023 at 10:50:39AM +0200, Simon Josefsson via Gnupg-users > wrote: >> Are there well-maintained debian packages for GnuPG 2.4 anywhere? I >> recently ran into yet another bug that has been fixed in later versions >> that Debian/Trisquel doesn't ship, so wondered this recently as well. >> >> I've seen some work here: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022702#10 >> >> If nobody has done this, is there interest in providing such packages? > > I was wondering about this a while ago. A PPA or similar external repo > would be very convenient if the Debian situation can't be sorted out, > since there are several post-2.2 features I'd like to use. Thanks to the wonders of git packaging and gitlab shared runners, it only took an hour or so to build bullseye packages for 2.2.40 and 2.4.0 via gitlab. See how to test the packages below. This uses upstream gnupg2, libgcrypt, libksba, libgpg-error from salsa with no changes, built using the latest tag that is also in unstable+testing but on bullseye images. For v2.4, only the gnupg2 package was rebuilt on the tmp-ametzler-v2.4 branch suggesting that it works. Of course, this is work in progress... See https://gitlab.com/debdistutils/packages/cicd-config for background. I'm sure we could finalize this into stable URLs and sign the apt repository using a GnuPG key if people find this interesting. I would find packages for Trisquel aramo useful myself, I'm not sure the bullseye packages work directly. /Simon To install version 2.2.40 follow this: ``` podman run -it --rm debian:bullseye apt-get update apt-get dist-upgrade -u -y apt-get install -y ca-certificates echo "deb [trusted=yes] https://gitlab.com/debdistutils/packages/libgpg-error/-/jobs/4092717327/artifacts/raw/aptly bullseye main" > /etc/apt/sources.list.d/libgpg-error.list echo "deb [trusted=yes] https://gitlab.com/debdistutils/packages/gnupg2/-/jobs/4092793555/artifacts/raw/aptly bullseye main" > /etc/apt/sources.list.d/gnupg2.list apt-get update apt-get install -y gnupg2 gpg --version ``` The expected output after all the installation noise should be: ``` gpg (GnuPG) 2.2.40 libgcrypt 1.8.8 Copyright (C) 2022 g10 Code GmbH License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /root/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ``` To install version 2.4.0 follow this: ``` podman run -it --rm debian:bullseye apt-get update apt-get dist-upgrade -u -y apt-get install -y ca-certificates echo "deb [trusted=yes] https://gitlab.com/debdistutils/packages/libgpg-error/-/jobs/4092717327/artifacts/raw/aptly bullseye main" > /etc/apt/sources.list.d/libgpg-error.list echo "deb [trusted=yes] https://gitlab.com/debdistutils/packages/libgcrypt/-/jobs/4093099318/artifacts/raw/aptly bullseye main" > /etc/apt/sources.list.d/libgcrypt.list echo "deb [trusted=yes] https://gitlab.com/debdistutils/packages/libksba/-/jobs/4092985161/artifacts/raw/aptly bullseye main" > /etc/apt/sources.list.d/libksba.list echo "deb [trusted=yes] https://gitlab.com/debdistutils/packages/gnupg2/-/jobs/4093118295/artifacts/raw/aptly bullseye main" > /etc/apt/sources.list.d/gnupg2.list apt-get update apt-get install -y gnupg2 gpg --version ``` The expected output after all the installation noise should be: ``` gpg (GnuPG) 2.4.0 libgcrypt 1.10.1 Copyright (C) 2021 Free Software Foundation, Inc. License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /root/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ``` signature.asc Description: PGP signature ___ 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
Werner Koch via Gnupg-users writes: > I am sorry, for the Debian troubles - we actually had 2.3 in Sid already > 2 years ago. AFAICS the problem is that the Debian maintainer seems to > be in a conflict between being Sequoia contributor and maintainer, > OpenPGP WG Chair and also long time GnuPG maintainer. Are there well-maintained debian packages for GnuPG 2.4 anywhere? I recently ran into yet another bug that has been fixed in later versions that Debian/Trisquel doesn't ship, so wondered this recently as well. I've seen some work here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022702#10 If nobody has done this, is there interest in providing such packages? /Simon signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP card with 25519 key breaks SSH sntrup761x25519-sha...@openssh.com
Never mind -- I realized this was a duplicate of this bug report: https://dev.gnupg.org/T5935 I will try to work on getting a newer GnuPG into Guix as a solution. /Simon signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
OpenPGP card with 25519 key breaks SSH sntrup761x25519-sha...@openssh.com
Hi. When I SSH with gpg-agent's ssh-agent emulation, this happens: jas@kaka ~$ ssh root@192.168.10.186 sign_and_send_pubkey: signing failed for ED25519 "cardno:FFFE 42315277" from agent: agent refused operation root@192.168.10.186: Permission denied (publickey). jas@kaka ~$ Tracking it down, it only occurs when both of these holds: 1) Modern enough SSH versions that prefers sntrup761x25519-sha...@openssh.com over curve25519-sha256. To force it: ssh -oKexAlgorithms=sntrup761x25519-sha...@openssh.com root@192.168.10.186 2) The 25519 key is on an OpenPGP card. I verified that 'ssh-keygen -t ed25519' and using that key works successfully with sntrup761x25519-sha512, so the problem is likely not within the OpenSSH server or client. I have verified the problem with two different OpenPGP cards, Gnuk1.2.20@FST01SZ and YubiKey, so it is likely not a card problem. Isn't this supposed to work? The workaround is to use the old default of curve25519-sha256: jas@kaka ~$ ssh -oKexAlgorithms=curve25519-sha256 root@192.168.10.186 Then it works. I enable debugging and restarting scdaemon as follows: jas@kaka ~$ cat>.gnupg/scdaemon.conf debug-all log-file /tmp/scd.log jas@kaka ~$ gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye OK ERR 67125247 Slut på fil jas@kaka ~$ The relevant output from a failing SSH command: DBG: chan_7 <- SERIALNO DBG: chan_7 -> S SERIALNO D276000124010200FFFE42315277 DBG: chan_7 -> OK DBG: chan_7 <- GETINFO card_list DBG: chan_7 -> S SERIALNO D276000124010200FFFE42315277 DBG: chan_7 -> OK DBG: chan_7 <- SERIALNO --demand=D276000124010200FFFE42315277 DBG: chan_7 -> S SERIALNO D276000124010200FFFE42315277 DBG: chan_7 -> OK DBG: chan_7 <- GETATTR $AUTHKEYID DBG: chan_7 -> S $AUTHKEYID OPENPGP.3 DBG: chan_7 -> OK DBG: chan_7 <- GETATTR SERIALNO DBG: chan_7 -> S SERIALNO D276000124010200FFFE42315277 DBG: chan_7 -> OK DBG: chan_7 <- READKEY OPENPGP.3 DBG: chan_7 -> [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(85 byte(s) skipped) ] DBG: chan_7 -> OK DBG: chan_7 <- GETATTR $DISPSERIALNO DBG: chan_7 -> S $DISPSERIALNO FFFE+42315277 DBG: chan_7 -> OK DBG: chan_7 <- SERIALNO --demand=D276000124010200FFFE42315277 DBG: chan_7 -> S SERIALNO D276000124010200FFFE42315277 DBG: chan_7 -> OK DBG: chan_7 <- SETDATA 3021300906052B0E03021A050004140040FAE895F31F2660B12248ED8BBF26A300125BABD0322CDDF09E9C15D963528F3EE5C65FED25D5F4A06A00C870ECA356EFAC01EC6AF60908B7F792C0B52571FB10320004726F6F74000E7373682D636F6E6E656374696F6E00237075626C69636B65792D686F7374626F756E642D763030406F70656E7373682E636F6D01000B7373682D656432353531390033000B7373682D656432353531390020BCC215C1C7ACACD548F0C36AB64F62A9FCF47E533DAC7070E460460FB80DA8040033000B7373682D6564323535313900209E01C3E55A1A346ED50BA91A9AE6752CED4ACC5B747450EC58B33E558718BC44 DBG: chan_7 -> OK DBG: chan_7 <- PKAUTH 24C58979C8A14326ECBA27CE64C86D0D563D DBG: send apdu: c=00 i=88 p1=00 p2=00 lc=260 le=256 em=0 operation auth result: Invalid value app_auth failed: Invalid value DBG: chan_7 -> ERR 100663351 Invalid value DBG: chan_7 <- RESTART DBG: chan_7 -> OK Releant part when I use -oKexAlgorithms=curve25519-sha256 for a successfull SSH command: 2022-12-30 14:55:37 scdaemon[8885] DBG: chan_7 <- SETDATA 3021300906052B0E03021A0500041400201B17C1E7A476E697A846BFEC82D58277CE29BE5D5E4729707B50817AB58DAEAA320004726F6F74000E7373682D636F6E6E656374696F6E00237075626C69636B65792D686F7374626F756E642D763030406F70656E7373682E636F6D01000B7373682D656432353531390033000B7373682D656432353531390020BCC215C1C7ACACD548F0C36AB64F62A9FCF47E533DAC7070E460460FB80DA8040033000B7373682D6564323535313900209E01C3E55A1A346ED50BA91A9AE6752CED4ACC5B747450EC58B33E558718BC44 2022-12-30 14:55:37 scdaemon[8885] DBG: chan_7 -> OK 2022-12-30 14:55:37 scdaemon[8885] DBG: chan_7 <- PKAUTH 24C58979C8A14326ECBA27CE64C86D0D563D 2022-12-30 14:55:37 scdaemon[8885] DBG: send apdu: c=00 i=88 p1=00 p2=00 lc=228 le=256 em=0 2022-12-30 14:55:37 scdaemon[8885] DBG: PCSC_data: 00 88 00 00 E4 00 00 00 20 1B 17 C1 E7 A4 76 E6 97 A8 46 BF EC 82 D5 82 77 CE 29 BE 5D 5E 47 29 70 7B 50 81 7A B5 8D AE AA 32 00 00 00 04 72 6F 6F 74 00 00 00 0E 73 73 68 2D 63 6F 6E 6E 65 63 74 69 6F 6E 00 00 00 23 70 75 62 6C 69 63 6B 65 79 2D 68 6F 73 74 62 6F 75 6E 64 2D 76 30 30 40 6F 70 65 6E 73 73 68 2E 63 6F 6D 01 00 00 00 0B 73 73 68 2D 65 64 32 35 35 31 39 00 00 00 33 00 00 00 0B 73 73 68 2D 65 64 32 35 35 31 39 00 00 00 20 BC C2 15 C1 C7 AC AC D5 48 F0 C3 6A B6 4F 62 A9 FC F4 7E 53 3D AC 70 70 E4 60 46 0F B8 0D A8 04 00 00 00 33 00 00 00 0B 73 73 68 2D 65 64 32 35 35 31 39 00 00 00 20 9E 01 C3 E5 5A 1A 34 6E D5 0B A9 1A 9A E6 75 2C ED 4A CC 5B 74 74 50 EC 58 B3 3E 55 87 18 BC 44 00 2022-12-30 14:55:37 scdaemon[8885] DBG: response: sw=9000 datalen=64 2022-12-30 14:55:37 scdaemon[8885] DBG: dump: 7E 25 60 36 E3 B5 34 22 74 C0 DD 0C 08 84 70 AE B2 A9 2F A4 75 66 A2 AF 48 C2 BE
Re: "best" ed25519/curve25519 setup?
Guilhem Moulin writes: > 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). 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. > * 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. That is an important aspect, thank you! >> 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 :-) I already have a good RSA-based master key setup: RSA offline master key RSA subkey for signature RSA subkey for decryption RSA subkey for authentication So I'm thinking that my new setup should be 25519-based. Would you want to use separate Curve25519 keys for authentication and signatures? So I guess the "perfect" setup for me would then be to add the following new key: Ed25519 offline master key Ed25519 subkey for signature Curve25519 subkey for authentication Curve25519 subkey for decryption ? I could adopt the middle way and continue to use my current RSA-based key and a new Ed25519-based key, and have both algorithms available as subkeys. RSA offline master key RSA subkey for signature RSA subkey for decryption RSA subkey for authentication Ed25519 subkey for signature Curve25519 subkey for authentication Curve25519 subkey for decryption Ed25519 offline master key RSA subkey for signature RSA subkey for decryption RSA subkey for authentication Ed25519 subkey for signature Curve25519 subkey for authentication Curve25519 subkey for decryption 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? Algorithm migration is really tricky... /Simon signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
"best" ed25519/curve25519 setup?
Hi. 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. 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? Naturally, I want the subkeys to be on hardware (smartcard). Is it possible to have multiple OpenPGP cards for the same master key, but for different subkeys? Does GNUK handle combined RSA+25519 keys? /Simon signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Yubikey, GnuPG 2.1 Modern, and SSH on OS X
> > Why do you add the keygrip to the sshcontrol file? I have never > > needed that step. For me it uses the right key directly. Is it > > because you have another (revoked) A subkey? It sounds somewhat of > > sub-optimal behaviour for gpg-agent's SSH support to use a revoked > > key instead of the non-revoked key. > > I do have a revoked Authentication sub-key on my primary key, but I > no longer use it and that is also not why I added the keygrip entry to > sshcontrol file. I added it at the suggestion of Werner in this post: > > https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html > > And these blog posts: > http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html > http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key > > Is this suggestion outdated? I don't recall ever using it, and I've been using SSH with smartcards through gpg-agent for over 10 years. What happens if you drop that part? For me it has always selected the right subkey automatically. /Simon pgpfOOtgB7R5k.pgp Description: OpenPGP digital signatur ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Yubikey, GnuPG 2.1 Modern, and SSH on OS X
Glenn Rempe writes: > I recently setup my own Mac w/ gnupg 2.1.10, and I am using a Yubikey to > manage my gpg private keys and I am using that key for SSH auth. I have it > all up and running but I ran into some issues as well so I wrote up a blog > post. I'd appreciate any suggestions for improvement and especially for > any ideas for a better fix for the workaround I had to do that I documented > at the end of the post. Maybe this will be of some use to those wanting to > use the latest gpg for SSH auth on a Mac with a Yubikey. > > https://www.rempe.us/blog/yubikey-gnupg-2-1-and-ssh/ Have you tried killing/restarting scdaemon only, not gpg-agent? Try: gpgconf --reload scdaemon or gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye Why do you add the keygrip to the sshcontrol file? I have never needed that step. For me it uses the right key directly. Is it because you have another (revoked) A subkey? It sounds somewhat of sub-optimal behaviour for gpg-agent's SSH support to use a revoked key instead of the non-revoked key. /Simon signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The best practice of master/sub key capabilities
Dongsheng Song writes: > Hi all, > > When I create new master/sub key, in the following 2 choice, I'm > wondering which is better? > > 1) master key have SCEA capabilities > > sec rsa4096/A19676A1 > created: 2015-08-20 expires: never usage: SCEA > trust: ultimate validity: ultimate > ssb rsa4096/27ADD750 > created: 2015-08-20 expires: never usage: SEA > > 2) master key have only Certify capability > > sec rsa4096/1F8AFCAD > created: 2015-08-20 expires: never usage: C > trust: ultimate validity: ultimate > ssb rsa4096/8E1D2A87 > created: 2015-08-20 expires: never usage: SEA I would use a SC master key because I would want to use it to certify other's keys, and would also be able to use it to sign statements in case something bad happened to my sub-keys. I would use three separate sub-keys, one each for the three SEA usages. /Simon signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-agent unable to see yubikey until manually re-running `gpg --card-status`
"Lance R. Vick" writes: > I only ever tried this on 2.0.0 as far as older versions go, and that was > similarly broken. I didn't bother documenting as I saw there were some > smartcard updates in 2.1.4 so I upgraded. > > Just now had another variation (on 2.1.4): > > 1. start gpg-agent > 2. populate SSH_AUTH_SOCK > 3. ssh successfully > 4. remove yubikey > 5. insert yubikey > 6. attempt to ssh -> "Permission Denied (Publickey)" > 7. `gpg --card status` -> "no card present" > 8. `gpg --card status` (again) -> Got usual card output > 9. ssh successfully again What mode is your YubiKey NEO in? If it is in the OTP/CCID combo mode, and you touch it, it will eject the CCID interface, issue an OTP, and then re-insert itself to CCID after a small timeout. Just an idea. Can you always reproduce the above, or is it timing dependent? Does the problem occur if you wait 20 seconds before doing every step? Being able to reproduce this on someone else's system would be a good step towards fixing it. /Simon > > On Thu, Jun 18, 2015 at 1:32 AM, Werner Koch wrote: > >> On Wed, 17 Jun 2015 18:17, si...@josefsson.org said: >> >> > I've seen the error many times, also when I used a g10code smartcard, >> > but lately things have been smooth. I think there have been a couple of >> >> Old versions of GnuPG assumed that there is a card reader which can tell >> you whether a card has been removed or inserted. However USB tokens are >> different in that you insert/remove the entire reader. gniibe fixed >> these problems some time ago. >> >> >> Salam-Shalom, >> >>Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> >> ___ >> Gnupg-users mailing list >> Gnupg-users@gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-agent unable to see yubikey until manually re-running `gpg --card-status`
NIIBE Yutaka writes: > Gpg frontend certainly works well for --sign, --decrypt after you > remove your token and insert it again. Please try: > > (1) Insert token > (2) Run "gpg --card-status" > (3) Remove token > (4) Run "gpg --sign" or "gpg --decrypt" > > SSH authentication also works well after removal/insertion. > > Note that it all works for me with Gnuk Token or OpenPGPcard with a > card reader. Removing/inserting YubiKey NEO works fine for me with GnuPG 2.0.x from Jessie. Could this be a GnuPG 2.1.x issue? Lance, did this work with older GnuPG versions? I've seen the error many times, also when I used a g10code smartcard, but lately things have been smooth. I think there have been a couple of gpg-agent/scdaemon fixes going in to make unplug/insert resume fine. /Simon signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: State-of-the-art way to setup a shared security@ email with hardware-backed keys?
Daniel Kahn Gillmor writes: > Hi Simon-- > > Thanks for the interesting use case. > > On Tue 2015-06-09 09:21:08 -0400, Simon Josefsson wrote: >> My current idea is to generate a secur...@example.com master PGP key and >> keep that offline, and to generate one decryption sub-key, and load that >> onto a couple of OpenPGP Card smartcards. >> >> This would allow authorized people to decrypt emails properly, by using >> the "security team smartcard". To respond to the emails, they would >> need to use their own smartcard which is a nauisance but workable. > > I like this approach for encryption to the team; i think it's definitely > better than the server that does decryption/reencryption. Hi. Thanks for confirmation. I'm going to write this up and implement it in the organization I had in mind. > Another (much weirder) remailer approach that doesn't expose the content > to the remailer itself uses El Gamal keys that have a known relationship > to each other. The remailer can transform the PKESK in such a way that > it is readable to each peer, without being able to recover the > cleartext. Is this implemented? I wan't to use standard stuff, anything experimental is likely to be difficult to deploy. Further, having an online remailer creates an attack surface that is costly to secure. > This still has the awkward key distribution step when new members join > the team -- you have to generate their encryption-capable secret key and > get it to them. I don't think key distribution is a significant problem for me -- I could generate the decryption keys for the members of the security team. > But for revocation for user X in this case, you'd just tell the server > to stop PKESK translation for the corresponding offset for user X -- no > certificate update is necessary, and no redistribution to every > remaining team member. Revocation is possible in my scheme -- just revoke the decryption key, create a new decryption sub-key and distribute it to all members that should have it. Perhaps not scalable to a large team, but quite feasible on my level of scale (<10 people). > I note that you're asking here only about the encryption-capable > subkeys, and not signing subkeys -- it's quite possible that your > correspondents would like to be cryptographically confident that the > reply messages come from the team, and not from an imposter. My plan was that people responding would sign their emails using their personal keys. While a shared signing key is possible, I'm not sure I see what the advantage is? I think I would prefer making communication going direct and end-to-end instead of continuing using the security@ address all the time. > Interestingly, the case for signing-capable subkeys is not symmetric > with the case for encryption-capable subkeys. It should be possible for > each of your members to contribute a distinct signing-capable subkey, > and you'd attach all of them to the primary key. Right, that could be interesting. > There are two approaches to this: > > a) you could have each person generate their own signing capable > subkey, create the binding cross-sig with it to the primary key, and > send the public part + the cross-sig to the team keyring maintainer, > who would bind it as a subkey and publish the updated cert. Sounds like figuring out the work-flow here will take some time. > b) during generation of the per-person encryption-capable subkey, you > could go ahead and generate a separate signing-capable subkey for > that user and pre-install it on the smartcard. Yeah. > the advantages of this individualized signing-subkey scheme (using > either approach above) over a single-shared-signing-subkey are: > > 0) you can do individualized revocation without reissuing new > signing-capable subkeys for everyone else. > > 1) you don't have to keep the signing-capable subkey on hand at the > keyring management site in order to enroll new team members. > > 2) when a message coming from the team is signed, you can identify > which team member made the signature. Is there really any advantage in this scheme compared to all members having two smartcards -- one contains their personal user@ keys and one contains the security@ decryption key? The only point I see with your scheme(s) is that people receiving responses will see that they are signed by secur...@example.com but I don't see what that improves over having see the response being signed by u...@example.com. The latter invites direct end-to-end secure communication, bypassing the security@ alias if needed. I think my use-case is to allow people to REACH us with encrypted emails using a well-established alias like secur...@exampl
State-of-the-art way to setup a shared security@ email with hardware-backed keys?
I want to setup a secur...@example.com contact email address that should accept OpenPGP encrypted emails. The purpose is to notify us of security incidents. The decryption key needs to be shared by several people who are authorized to read and reply to such emails. Naturally I don't want soft keys laying around on everyone's disk. Is anyone doing this for some organization? What is the best way to achieve this? My current idea is to generate a secur...@example.com master PGP key and keep that offline, and to generate one decryption sub-key, and load that onto a couple of OpenPGP Card smartcards. This would allow authorized people to decrypt emails properly, by using the "security team smartcard". To respond to the emails, they would need to use their own smartcard which is a nauisance but workable. Dealing with revocation (if someone quits or loses their smartcard) seems feasible: just revoke the subkey and generate a new one, loading that onto everyone's smartcards. One alternative I can think of is to setup a server that receives the email, decrypts it and encrypts it to all people who should receive it. Then they can use only their personal smartcard and don't need to carry another smartcard around. The disadvantage with this is that the server will become an easy attack target. What we currently use is to publish the individal PGP keys for all security team members, so people can encrypt to all of us and email directly, but that is rather unfriendly to people sending us reports. Thoughts? /Simon signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Notes from the first OpenPGP Summit
"Neal H. Walfield" writes: > Hi Simon, > > We've documented the problem at http://wiki.gnupg.org/GnomeKeyring . Thanks -- another workaround, alas. > The solution is to fix Gnome Keyring :). I've spoken with Stef, the > main developer of GKR, and he confirmed that the only reason GKR MITMs > GPG Agent is so that it can intercept prompts for the password to > supply any cached value. The solution is to enhance pinentry so that > if GKR is available it caches the password with GKR. This requires a > few modifications to GnuPG proper as well as enhancements to pinentry. > I'm working on this and it should be done shortly. The GPG Tools > people also need this functionality in GPG 2.0 so it will also be > backported. We hope to coordinate with Debian to get the fixed > versions of GPG and GKR in the next point release of Jessie. Great, I'm really looking forward to a proper fix to this problem. /Simon signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Notes from the first OpenPGP Summit
Werner Koch writes: > I appreciated the opportunity to meet the GPG Tools developers, who > are very dedicated to make GnuPG working well on OS X. I stressed the > importance to actively participate on the GnuPG mailing list to keep > information in sync. One example may illustrate this: For years the > adaption of GnuPG-2 on GNOME based systems has been hampered by the > fact that the gnome-keyring-manager (GKR) tries to emulate gpg-agent > and thus inhibits proper working of any advanced function of GnuPG > (e.g. smartcards and gpgsm). With Debian’s release of Jessie that > problem will even be worse due to other desktop environments now also > using GKR. Given that the GKR developers are not willing to change > their defaults, Neal, dkg, and me came up with a pragmatic solution > for this problem on Saturday morning. What is this solution? I am working around the bug in Jessie [1], but GKR's bug/design is a real pain if you want to convince others to start to use GnuPG with smartcards. I recently noticed that my fix doesn't even work on Ubuntu, so each OS need their own fix... :-( /Simon [1] http://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/ signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: x509 and openGPG smartcard
Guillaume Lanquepin-Chesnais writes: > Hello, > > I've just bought a Gemalto USB Shell Token V2 and openGPG smartcard. I > successfully get it work on Ubuntu 12.04 (gnupgp 2.0.17) without any > problem. However, I > can't store a x509 certificate on the smartcard. I thought OpenPGP cards didn't support storing X.509 certs? /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: sign and encrypt from batch script
"Roberts, David M [ITSYS]" writes: > I've got a batch script that signs and encrypts files using GnuPG1.2.6 > running on a REHL4 system. We are upgrading the system to RHEL6 which > comes with Gnupg2.0.14 and the scripts no longer run correctly. > > gpg -u "signing-key" -r "receiving_pub-key" -sea -o /output.pgp > --batch --passphrase-fd 0 < /phrase.txt /plaintext.txt > > When I run this command on the new system I get a message like this > > You need a passphrase to unlock the secret key for > user: "signing-key" > 2048-bit RSA key, ID EAA21D37, created 2012-03-26 > can't connect to `/root/.gnupg/S.gpg-agent': No such file or directory GnuPG 2 uses the agent. It may not be entirely relevant, but I managed to run ssh with the gpg-agent unattended on a server: http://blog.josefsson.org/2011/10/11/unattended-ssh-with-smartcard/ I have not tested whether it works with private keys stored encrypted on disk, but I see no fundamental reason why it wouldn't work. You can ignore the SSH aspect of it, which should make it simpler. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Which ExpressCard/54?
Olav Seyfarth writes: > Hi list, > > I use my OpenPGP SmartCard in my laptop (W7+Linux) with a PCMCIA reader. > > I think about buying a new laptop. Unfortunately, new models often only > ExpressCard/54 slot is available today (if at all). > > After having had trouble with built-in SmartCard readers, > I think it's a good idea to use a ExpressCard/54 reader instead. > > It would help to have a hint which ExpressCard reader to buy. > The OpenPGP SmartCard HowTo does not recommend any ExpressCard reader. > > I found two ExpressCard/54 readers: > > * Gemalto PC Express (PCMCIA HWP114310D) > http://www.gemalto.com/products/pc_link_readers/#PC_Express > http://support.gemalto.com/?id=70 > > * SCM Microsystems SCR3340 Express Card Reader > http://www.identive-infrastructure.com/products-solutions/\ > smart-card-readers-a-terminals/smart-card-readers/scr3340 > > Any hands-on experience with them or other suggestions? I have the Gemalto PC Express card and has works excellent with OpenPGP (gnupg, ssh-agent, etc) for many months now. Here is some more info about it: http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x08E60x34EC http://pcsclite.alioth.debian.org/ccid/#106 Initially I bought another device, the OmniKey 4321: http://pcsclite.alioth.debian.org/ccid/#140 However it does not work well with OpenPGP cards, see this blog about the problem: http://ludovicrousseau.blogspot.com/2010/10/gnupg-v2-card-and-extended-apdu.html /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
Aaron Toponce writes:
> I've added it with "my_hdr OpenPGP id=${pgp_sign_as}\;url=...". The only
> question remaining, for me, is whether or not it should be "X-OpenPGP" or
> "OpenPGP" as the header field name. I've heard various positions on this,
> but nothing definitive.
No X-OpenPGP please. It was a broken idea that prevented
standardization of headers that gain popularity. The X- idea was
removed from the latest revision of RFC 822.
/Simon
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Having trouble getting GPG to accept input from a pinpad
Paul Richard Ramer writes: > Hi, > > I am using an OpenPGP v2 card with an SCM SPR-532 smartcard reader, and > I can't get GPG to take a PIN from the pinpad instead of the keyboard. > When I run "gpg --card-edit" followed by any command that requires a PIN > or Admin PIN, I get a password dialog box from pinentry, but I can only > enter the PIN via a keyboard. IIRC the on-device PIN entry is only used for signing operations, not admin stuff -- so try proceeding anyway and then try signing. This kind of harms the point of having a on-device PIN entry, but it is still possible to setup the card on a secure machine and then use it in other environments. I'm using a SPR-532 too with GnuPG on Mac for SSH authentication, and I enter the PIN on the SPR-532 just fine. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Smartcard PIN change via card reader keypad?
Hauke Laging writes: > Am Montag 07 Juni 2010 08:22:07 schrieb Simon Josefsson: > >> I'm using the keyboard on my smartcard reader to enter the PIN and it >> works fine with GnuPG. I'm using a SCM SPR-532. Maybe your reader >> isn't supported? > > I have that reader model, too. The normal card usage works. (Not without > problems but I don't know whether they are software or hardware related.) > > When I use the keys on the card then gpg always asks me to use the reader > keypad. Do you have a special configuration so that it does this for changing > the PIN, too? Oops, sorry I didn't notice your question was only about changing the PIN. I don't recall testing this, so I'm not sure it is using the reader keypad or not. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Smartcard PIN change via card reader keypad?
Hauke Laging writes: > Hello, > > I am surprised that gpg asks for the smartcard PIN via the keyboard > when it is to be changed. Do I misunderstand anything? Can I make gpg > use the card reader keypad for that instead? IMHO an important part of > smartcard security is that the PC does NOT know the passphrase. Is > there any reason why the keypad cannot be used for this? I'm using the keyboard on my smartcard reader to enter the PIN and it works fine with GnuPG. I'm using a SCM SPR-532. Maybe your reader isn't supported? /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Gnupg doesn't recognize card.
Werner Koch writes: > On Fri, 29 Jan 2010 01:22, jcr...@gmail.com said: > >> $ killall -u scdaemon #usually has to be entered 2-3x to >> kill it > > FWIW, > > gpgconf --reload scdaemon > > does the same in a well defined manner. The --reload parameter doesn't appear to be documented. Is it really supported for use in long-term portable scripts? /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG4Win: running gpg-agent with SSH agent support?
Werner Koch writes: > On Fri, 29 Jan 2010 14:03, si...@josefsson.org said: > >> I've installed GPG4Win and it recognizes my OpenPGP smartcards without >> problem (via a gpg-agent process which appears to be auto-started >> somehow?). However, I'd like to enable SSH agent support in gpg-agent > > Yes, we do this on Windows because we have a well known socket name > there. It may actually happen that two agents are started which does > not harm because the the unused agent detects this case and terminates > itself after some time. > >> too, so that Cygwin ssh can make use of it. Is this possible, if so >> how? > > It can't work out of the box because ssh needs to implement our local > socket emulation (see libassuan/src/assuan-socket.c). It would be very > useful if we could get support for this into putty. Why can't gpg-agent implement the same protocol that ssh-agent does under Windows? The ssh-agent under Cygwin appears to work in the same way it does on GNU/Linux, i.e., the ssh process looks for the environment variables that ssh-agent prints when started. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG4Win: running gpg-agent with SSH agent support?
I've installed GPG4Win and it recognizes my OpenPGP smartcards without problem (via a gpg-agent process which appears to be auto-started somehow?). However, I'd like to enable SSH agent support in gpg-agent too, so that Cygwin ssh can make use of it. Is this possible, if so how? /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Web of Trust itself is the problem
Dmitri Minaev writes: > On Thu, Jan 7, 2010 at 9:08 PM, Mario Castelán Castro > wrote: > >> I think the WoT and in general the cryptography is not widely used >> because few people really care about their privacity. > > IMHO, there's another problem, an entry barrier to the WoT. The > practice of key exchange is widespread in very close circles of geeks, > Linux developers and, to a certain degree, scientists. For someone who > does not belong to these categories and does not attend any > conferences, the web of trust is hardly reachable. Unfortunately, I > know no solutions besides commercial CAs. Sites such as http://biglumber.com/x/web can help with this. My perception of it is that it does not exclude non-geeky people. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SSH using OpenPGP card under Windows
Werner Koch writes: > On Mon, 5 Oct 2009 15:54, si...@josefsson.org said: > >> But it requires a PKCS#11 module -- I see on scute.org that >> it is possible to build for Windows, but are there any >> pre-compiled binaries available? > > Scute is part of gpg4win 2.0. Great. I'm trying to use it with PuttySC's 'pprint' and it says: scute-assuan[2756]: can't create socket: Function not implemented scute-assuan[2756]: can't create socket: Function not implemented sc: C_initialize failed Running gpg-agent says it is running and available. Running 'gpg --card-status' works. Any ideas? /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
SSH using OpenPGP card under Windows
Has anyone managed to get this combination working? There is a Putty extension but is appears to be non-free: http://smartcard-auth.de/ssh-en.html There is a free smartcard-enabled Putty: http://www.joebar.ch/puttysc/ But it requires a PKCS#11 module -- I see on scute.org that it is possible to build for Windows, but are there any pre-compiled binaries available? There seems to be some efforts in the OpenSC project to facilitate this, but there is also documentation that suggests smartcard with putty doesn't work perfectly. Thanks, /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: SHA2 in OpenPGP cards?
Werner Koch writes: > On Tue, 29 Sep 2009 09:46, si...@josefsson.org said: >> Hi! Before I spend time testing it, can the OpenPGP card support >> RSA-SHA2 signatures? > > The v2 cards support any hash agorithm as long as they fit into pkcs#1. When I attempt to generate a new key on the card with this in my ~/.gnupg/gpg.conf: personal-digest-preferences SHA256 cert-digest-algo SHA256 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed I get this error: Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o gpg: checking created signature failed: Bad signature gpg: signing failed: Bad signature gpg: make_keysig_packet failed: Bad signature Key generation failed: Bad signature When I comment out the three lines above, it worked fine. Any ideas? GnuPG 2.0.13 from Debian. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keyservers mangle with subkey binding sigs
"Vlad \"SATtva\" Miller" <[EMAIL PROTECTED]> writes: > While I understand that this place isn't the best for PKS bug reports, > I'm still not sure of what's happening (except it's quite weird). My key > 0x8443620A consists of a main certification key and two subkeys: one for > encryption and one for signing. > > Both subkeys have expired in the end of the last year, but I've chosen > not to generate new and to simply extend life of existing subkeys for > another few years, so I've re-signed them with extended expiration date > and updated to keyservers. A few days later one of my correspondents > contacted me saying that my key is expired and unusable. I've looked at > keyservers, and was very surprised that they're not reflecting the > changes made! > > Here for example (in the bottom) you may see two subkeys with binding > signatures expired at 2007-12-31: > http://pool.sks-keyservers.net:11371/pks/lookup?search=0x8443620A&op=vindex > > But if you look at the original copy you'll see that all regenerated > sigs are in place: > http://www.vladmiller.info/contacts/openpgp.txt > > [EMAIL PROTECTED] ~ $ cat openpgp.txt | gpg --list-packets > [snip] > :signature packet: algo 1, keyid FAEB26F78443620A > version 4, created 1199529401, md5len 0, sigclass 0x18 > digest algo 2, begin of digest 1f 06 > hashed subpkt 26 len 45 (policy: > http://www.vladmiller.info/services/cert.html) > hashed subpkt 27 len 1 (key flags: 0C) > hashed subpkt 2 len 4 (sig created 2008-01-05) > hashed subpkt 9 len 4 (key expires after 3y11d13h6m) > subpkt 16 len 8 (issuer key ID FAEB26F78443620A) > data: [4095 bits] > > If I understand this correctly and not missing something terribly here, > keyservers just looked at newly uploaded key, thought "huh? I already > have that subkey in place, and this 0x18 sig too!", and discarded it > without going into much trouble of analyzing any binding sigs' > timestamps (maybe marking them as duplicates). > > Could anyone confirm this behavior? I had similar problems with many key servers, until I switched to subkeys.pgp.net which is (if I understand correctly) documented to only point to key servers with full subkey support. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OpenPGP and usability
"Steven E. Harris" <[EMAIL PROTECTED]> writes: > Werner Koch <[EMAIL PROTECTED]> writes: > >> Well, the X prefix is not anymore required for user defined headers. > > Was there some change in this prescription? If so, from where? I hadn't > heard about "X-" falling from use. In RFC 822 there was X-, in RFC 2822 it has been removed. X-* is a bad idea: once you want to standardize an experimental header, you have to break the deployment of that header. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Old PC as Hardware Security Module?
"Robert J. Hansen" <[EMAIL PROTECTED]> writes: >> I've been considering getting an OpenPGP Card, but there are three >> reasons I'm reluctant to. The main one is that I want something that >> will only do one signature or decryption at a time. That way if my >> machine is compromised, I'll only suffer one hit before I'll notice >> something's wrong. > > The OpenPGP card actually gives you a substantial advantage in this > situation. > > Let's say that you're running GnuPG on a PC and I'm able to subvert > the box. I put in a keylogger and snarf your passphrase. I also > copy your private keyring and mailspool off the box. I can now read > your mail without ever touching it, except to copy a couple of files > and install a small app. You're none the wiser. > > Compare this to an OpenPGP card, where I have to find you in a dark > alley and have a conversation with your kneecaps to get your card and > PIN. You will most probably know that something has happened to you. What prevents the keylogger in your first example to snarf the PIN code for the OpenPGP card and send decryption requests to the OpenPGP card, using the PIN code, in the background, possibly remotely controlled over the network? Alternatively, if you think remotely controlling the trojan is difficult, let it iterate through your mail spool and send decryption requests to collect all session keys, and then send the mail spool and the session keys to you. I think smart cards in general are somewhat over-rated. You have no idea what they are signing, and the authorization control (PIN code) is easy to get by with a trojan. To be secure with smart cards, I think you'll need a separate single-purpose device that show you what it is going to sign, and signs it only after getting some credential (e.g., PIN), using its own trusted input device. And there should be no caching of the PIN code, or at least authorization should be required when the PIN cache is accessed. The protocol to the single-purpose device would actually be quite similar to what you would use to a 'old PC acting as HSM' device. The protocol is similar to a serialized PKCS#11 interface with the What You See Is What You Sign extensions. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Old PC as Hardware Security Module?
"Robert J. Hansen" <[EMAIL PROTECTED]> writes: >> What prevents the keylogger in your first example to snarf the PIN >> code >> for the OpenPGP card and send decryption requests to the OpenPGP card, >> using the PIN code, in the background, possibly remotely controlled >> over >> the network? > > There exist cryptographic smart cards you can actually be safe > against this kind of attack with. They're pretty cool. How do they work? I'd expect them to have a button, to authorize signing or decryption, but without a display, you still have no idea what you really sign or decrypt. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --sign with smartcard?
Werner Koch <[EMAIL PROTECTED]> writes: > On Fri, 20 Apr 2007 14:03, [EMAIL PROTECTED] said: > >> Use --disable-crl-checks to disable CRL checks. Also, you must put >> the CA fingerprint in your trustlist.txt: > > Or use --allow-mark-trusted in gpg-agent.conf so that the agent will ask > you whether to put it into trustlist.txt. Neat, although I had to manually create the trustlist.txt file first. Otherwise I get: [EMAIL PROTECTED]:~$ echo foo|gpgsm --sign --disable-crl-checks -a gpgsm: checking the trust list failed: No such file or directory gpgsm: error creating signature: No such file or directory [EMAIL PROTECTED]:~$ Maybe gpg-agent could create trustlist.txt if it doesn't exist, if allow-mark-trusted is used? /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --sign with smartcard?
Simon Josefsson <[EMAIL PROTECTED]> writes: > I'm trying to sign something using gpgsm and a smartcard, but here is > what happens: ... > Where do I put the CRL that will be checked? > > Alternatively, how can I tell gpgsm/dirmngr to not check any CRL? I solved this myself, sorry for the noise. For the record: Use --disable-crl-checks to disable CRL checks. Also, you must put the CA fingerprint in your trustlist.txt: [EMAIL PROTECTED]:~$ cat /home/jas/.gnupg/trustlist.txt 15:32:B4:BA:5A:8A:79:88:CA:26:42:83:59:1B:A3:A2:1C:0B:CC:24 S [EMAIL PROTECTED]:~$ Then signing works: [EMAIL PROTECTED]:~$ echo foo | gpgsm --sign -u BD:5F:80:DE:63:03:4E:C9:E2:84:1E:63:09:55:2E:34:5C:5F:22:6F --disable-crl-checks > foo gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: DBG: adding certificates at level 1 gpgsm: signature created [EMAIL PROTECTED]:~$ I can't parse the output using GnuTLS 'certtool', but OpenSSL appears to handle it, so I suppose it may be a bug in GnuTLS. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Scdaemon READCERT
Does this command work? I see that Scute does not use gpg-agent or scdaemon to get the certificates, but it invokes 'gpgsm --server' and uses DUMPKEYS. That works, but I'd rather talk to only gpg-agent and not also gpgsm in GnuTLS. This is what I tried: [EMAIL PROTECTED]:~$ gpg-connect-agent SCD LEARN --force S SERIALNO D27600012401010100010532 0 S APPTYPE OPENPGP S EXTCAP gc=1+ki=1+fc=1+pd=1 S DISP-NAME Key< SCD READCERT OPENPGP.3 ERR 100663420 Unsupported operation /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpgsm --sign with smartcard?
I'm trying to sign something using gpgsm and a smartcard, but here is what happens: [EMAIL PROTECTED]:~$ gpgsm --sign -u BD:5F:80:DE:63:03:4E:C9:E2:84:1E:63:09:55:2E:34:5C:5F:22:6F dirmngr[21860]: error opening `/home/jas/.gnupg/dirmngr_ldapservers.conf': No such file or directory dirmngr[21860]: permanently loaded certificates: 0 dirmngr[21860]: runtime cached certificates: 0 dirmngr[21860]: no CRL available for issuer id 73504958EC804B0DA5501605CFEC58754F0864FE dirmngr[21860]: crl_fetch via issuer failed: Configuration error dirmngr[21860]: command ISVALID failed: Configuration error gpgsm: certificate #4628A165/CN=GnuTLS test CA gpgsm: checking the CRL failed: Configuration error gpgsm: can't sign using `BD:5F:80:DE:63:03:4E:C9:E2:84:1E:63:09:55:2E:34:5C:5F:22:6F': Configuration error [EMAIL PROTECTED]:~$ Where do I put the CRL that will be checked? Alternatively, how can I tell gpgsm/dirmngr to not check any CRL? Thanks, Simon [EMAIL PROTECTED]:~$ gpgsm -K /home/jas/.gnupg/pubring.kbx Serial number: 4628A165 Issuer: /CN=GnuTLS test CA Subject: /CN=Test Key/O=Simon Josefsson aka: (dns-name josefsson.org) validity: 2007-04-20 11:17:59 through 2007-10-17 11:18:02 key type: 1024 bit RSA key usage: digitalSignature keyEncipherment ext key usage: clientAuth (suggested), serverAuth (suggested) fingerprint: BD:5F:80:DE:63:03:4E:C9:E2:84:1E:63:09:55:2E:34:5C:5F:22:6F [EMAIL PROTECTED]:~$ gpgsm -k /home/jas/.gnupg/pubring.kbx Serial number: 4628A165 Issuer: /CN=GnuTLS test CA Subject: /CN=Test Key/O=Simon Josefsson aka: (dns-name josefsson.org) validity: 2007-04-20 11:17:59 through 2007-10-17 11:18:02 key type: 1024 bit RSA key usage: digitalSignature keyEncipherment ext key usage: clientAuth (suggested), serverAuth (suggested) fingerprint: BD:5F:80:DE:63:03:4E:C9:E2:84:1E:63:09:55:2E:34:5C:5F:22:6F Serial number: 46261D27 Issuer: /CN=GnuTLS test CA Subject: /CN=GnuTLS test CA validity: 2007-04-18 13:29:11 through 2008-04-17 13:29:11 key type: 1024 bit RSA key usage: certSign chain length: unlimited fingerprint: 15:32:B4:BA:5A:8A:79:88:CA:26:42:83:59:1B:A3:A2:1C:0B:CC:24 [EMAIL PROTECTED]:~$ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
Werner Koch <[EMAIL PROTECTED]> writes: > On Wed, 18 Apr 2007 14:11, [EMAIL PROTECTED] said: > >> It is possible to avoid a DER/BER decoder if you generate two >> structures, one with NULL parameters and one with absent parameters, >> and compare both against what's in the decrypted signatures. > > There is a plan tomove pkcs#1 decoding into libgcrypt. This would allow > us to do a second compare without too much changes. I'll put it onto my > todo list but don't expect it to happen anytime soon. Doing PKCS#1 in libgcrypt would be useful for GnuTLS too. I'd like to remove that code in the long run... OTOH, it seems likely that GnuTLS will use some assuan-like protocol and an agent to do private key signing operations, so maybe this concern will be moot. >> GnuTLS accepts both variants, so I made the change. I'll release an >> updated stable version to help get it out as soon as possible. > > Would it be sufficient to do that just for SHA-1? In that case a hack > in cipher/rsa.c would do the trick without too much fear of regression. I don't know. If you do it for SHA-1, that will cover many practical situations and that may be enough. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
Werner Koch <[EMAIL PROTECTED]> writes: >> Although it may be argued that RFC 4055 only applies to RSA-PSS, >> although this particular section is not clear that it only applies to >> RSA-PSS. > > The problem is that allowing for different encodings will require a > complete DER (or well for some old specs even BER) parser in libgcrypt. > Not long ago most crypto libraries showed implementaion flaws in that - > libgcrypt didn't suffer from this due its poor man's and simple approach > to checkthe RSA signature. Given that the code in gpgsm/libgcrypt has > passed several compatibility tests I doubnt that it is a good idea to > change it now and open the way to introduce new bugs. It is possible to avoid a DER/BER decoder if you generate two structures, one with NULL parameters and one with absent parameters, and compare both against what's in the decrypted signatures. >> I should probably change GnuTLS here. > > I'd appreciate that. If it later turns out that too many gnutls created > certificates are in use we might consider to add a hack to gpgsm just > for the SHA-1 case. GnuTLS accepts both variants, so I made the change. I'll release an updated stable version to help get it out as soon as possible. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
Werner Koch <[EMAIL PROTECTED]> writes:
> Thus we have an extra NULL and that is the reason that it does not
> verify. I am too tired to read pkcs#1 know; will do that tomorrow.
> Anyway it is the first case that I noticed such a pkcs#1 encoding.
Ah, I see. Whether the parameters should be NULL or absent seem to be
a frequent interop problem.
> Hi,
>
> whether the optional parameter of the AlgorithmIdentifier is really
> optional has changed over time. My ASN.1 derived from the German Sphinx
> profile state:
>
> AlgorithmIdentifier ::= SEQUENCE {
> algorithmOBJECT IDENTIFIER,
> parameters ANY DEFINED BY algorithm OPTIONAL
> -- should be used but set to NULL
> }
>
> rfc3280 (X.509) does not have this remark. Peter Gutmann's X.509 guide
> explains this issue:
>
> Another pitfall to be aware of is that algorithms which have no
> parameters have this specified as a NULL value rather than omitting
> the parameters field entirely. The reason for this is that when the
> 1988 syntax for AlgorithmIdentifier was translated into the 1997
> syntax, the OPTIONAL associated with the AlgorithmIdentifier
> parameters got lost. Later it was recovered via a defect report, but
> by then everyone thought that algorithm parameters were mandatory.
> Because of this the algorithm parameters should be specified as NULL,
> regardless of what you read elsewhere.
>
> How did you create this certificate?
With GnuTLS' certtool.
RFC 3280 references RFC 3279 on this, and it says:
When any of these three OIDs appears within the ASN.1 type
AlgorithmIdentifier, the parameters component of that type SHALL be
the ASN.1 type NULL.
RFC 3279 is updated by RFC 4055 which says in section 2.1 (in
particular the second paragraph):
There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers. The two
alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax. Later the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory. Because of this
history some implementations encode parameters as a NULL element
while others omit them entirely. The correct encoding is to omit the
parameters field; however, when RSASSA-PSS and RSAES-OAEP were
defined, it was done using the NULL parameters rather than absent
parameters.
All implementations MUST accept both NULL and absent parameters as
legal and equivalent encodings.
To be clear, the following algorithm identifiers are used when a NULL
parameter MUST be present:
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL }
sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }
Although it may be argued that RFC 4055 only applies to RSA-PSS,
although this particular section is not clear that it only applies to
RSA-PSS.
I should probably change GnuTLS here.
/Simon
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpgsm --import of CA certificate: Bad signature?
Hi! I'm trying to get Scute working in Mozilla (as a first step
towards making GnuTLS also use it as a PKCS#11 module). I imported my
newly generated certificate into gpgsm as follows:
[EMAIL PROTECTED]:~$ gpgsm --import .gnupg/test-key.pem
gpgsm: issuer certificate {E93C1CFBAD926EE606A4562CA2E1C05327C8F295} not found
using authorityKeyIdentifier
gpgsm: issuer certificate (#/CN=GnuTLS test CA) not found
gpgsm: issuer certificate {E93C1CFBAD926EE606A4562CA2E1C05327C8F295} not found
using authorityKeyIdentifier
gpgsm: total number processed: 1
gpgsm: unchanged: 1
[EMAIL PROTECTED]:~$
I guessed that it wouldn't hurt to import the CA certificate too. But
here's what happened then:
[EMAIL PROTECTED]:~$ gpgsm --import
~/src/www-gnutls/test-credentials/x509-ca.pem
gpgsm: self-signed certificate has a BAD signature: Bad signature
gpgsm: basic certificate checks failed - not imported
gpgsm: total number processed: 1
gpgsm: not imported: 1
[EMAIL PROTECTED]:~$
As far as I can tell, there is nothing wrong with this certificate.
Ideas?
You can retrieve the certificate from:
http://www.gnu.org/software/gnutls/test-credentials/x509-ca.pem
I'm using GnuPG 2.0.3.
I don't know if it is relevant, but the list of 'Supported algorithms'
seems rather short:
[EMAIL PROTECTED]:~$ gpgsm --version
gpgsm (GnuPG) 2.0.3
Copyright (C) 2007 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Home: ~/.gnupg
Supported algorithms:
[EMAIL PROTECTED]:~$
/Simon
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key Certificates in GNUPG
Werner Koch <[EMAIL PROTECTED]> writes: > On Mon, 7 Aug 2006 04:39, Rubis Paul said: > >> a. Is there any function in Libgrypt or Libksba to generate certificates ? > > Not yet. We don't have a need for it right now. For CA software you > need more than just the ability to create a certificate. There is a tool 'certtool' in GnuTLS though, which can generate X.509 certificates. It uses libgcrypt. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: auto-key-locate
Alphax <[EMAIL PROTECTED]> writes: >> gpg: [EMAIL PROTECTED]: skipped: unusable public key >> gpg: [stdin]: encryption failed: unusable public key >> [EMAIL PROTECTED]:~/src/gnupg$ gpg -a -e -r [EMAIL PROTECTED] >> gpg: 1643B926: There is no assurance this key belongs to the named user >> >> pub 2048g/1643B926 2002-01-28 David M. Shaw <[EMAIL PROTECTED]> >> Primary key fingerprint: 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 >> Subkey fingerprint: F0EC 51D9 2ED0 C183 8977 DDD0 AE28 27D1 1643 B926 >> >> It is NOT certain that the key belongs to the person named >> in the user ID. If you *really* know what you are doing, >> you may answer the next question with yes. >> >> Use this key anyway? (y/N) >> > > Have you tried it with > > trust-model always > > in your gpg.conf? The key you're trying to encyrpt to probably isn't > within your trust path. No, that only removes the question on the second invocation of gpg. It doesn't make the first one succeed. The key appear to be found and imported successfully, but gpg doesn't seem to be able to use it immediately. >> Btw, DNS CERT retrieval work fine, see: > > Oh yes, congrats on RFC 4398. Thanks! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
auto-key-locate
Werner Koch <[EMAIL PROTECTED]> writes: > * New auto-key-locate option that takes an ordered list of methods > to locate a key if it is not available at encryption time (-r or > --recipient). Possible methods include "cert" (use DNS CERT as > per RFC2538bis, "pka" (use DNS PKA), "ldap" (consult the LDAP > server for the domain in question), "keyserver" (use the > currently defined keyserver), as well as arbitrary keyserver > URIs that will be contacted for the key. I'm having trouble getting hkp keyservers to work with auto-key-locate. gpg do appear to retrieve the key successfully, but then it complains that it can't use it. Ideas? ~/.gnupg/gpg.conf contains: auto-key-locate x-hkp://subkeys.pgp.net [EMAIL PROTECTED]:~/src/gnupg$ gpg -a -e -r [EMAIL PROTECTED] gpg: searching for names from hkp server subkeys.pgp.net gpg: key 99242560: public key "David M. Shaw <[EMAIL PROTECTED]>" imported gpg: key 3CB3B415: public key "David M. Shaw <[EMAIL PROTECTED]>" imported gpg: key D46DCCC5: "David M. Shaw (High Security) <[EMAIL PROTECTED]>" not changed gpg: key DFF20E79: public key "David M. Shaw <[EMAIL PROTECTED]>" imported gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 4 signed: 21 trust: 0-, 0q, 0n, 0m, 0f, 4u gpg: depth: 1 valid: 21 signed: 43 trust: 1-, 0q, 0n, 1m, 19f, 0u gpg: depth: 2 valid: 29 signed: 223 trust: 24-, 0q, 0n, 0m, 5f, 0u gpg: depth: 3 valid: 24 signed: 158 trust: 24-, 0q, 0n, 0m, 0f, 0u gpg: next trustdb check due at 2006-07-10 gpg: Total number processed: 4 gpg: imported: 3 (RSA: 3) gpg: unchanged: 1 gpg: automatically retrieved [EMAIL PROTECTED]' via x-hkp://subkeys.pgp.net gpg: [EMAIL PROTECTED]: skipped: unusable public key gpg: [stdin]: encryption failed: unusable public key [EMAIL PROTECTED]:~/src/gnupg$ gpg -a -e -r [EMAIL PROTECTED] gpg: 1643B926: There is no assurance this key belongs to the named user pub 2048g/1643B926 2002-01-28 David M. Shaw <[EMAIL PROTECTED]> Primary key fingerprint: 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 Subkey fingerprint: F0EC 51D9 2ED0 C183 8977 DDD0 AE28 27D1 1643 B926 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) Btw, DNS CERT retrieval work fine, see: [EMAIL PROTECTED]:~$ gpg -a -e -r [EMAIL PROTECTED] gpg: key B565716F: public key "Simon Josefsson <[EMAIL PROTECTED]>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: no ultimately trusted keys found gpg: automatically retrieved [EMAIL PROTECTED]' via DNS CERT gpg: A14C401A: There is no assurance this key belongs to the named user pub 1024R/A14C401A 2006-03-18 Simon Josefsson <[EMAIL PROTECTED]> Primary key fingerprint: 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F Subkey fingerprint: 9FB3 8B75 7032 6114 34B5 649E C0C3 8BF5 A14C 401A It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) Thanks, Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
How to sign with non-subkey?
I recently created a signing sub-key (on a smartcard, if it matters) and gpg now use it by default. How do I sign messages using my non-subkey? I thought -u would do it, but it doesn't seem to work: [EMAIL PROTECTED]:~$ echo foo |gpg -a -s -v -u b565716f gpg: using subkey AABB1F7B instead of primary key B565716F gpg: writing to stdout gpg: using subkey AABB1F7B instead of primary key B565716F gpg: RSA/SHA1 signature from: "AABB1F7B Simon Josefsson <[EMAIL PROTECTED]>" -BEGIN PGP MESSAGE- Version: GnuPG v1.4.2.2 (GNU/Linux) owGbwMvMwMS4XF34xKrd8tWMp7mSGFwURP6l5edzdZxiYWBkYjBhZQKJ6Io0MACB KAN/QXaibmJKSlFqcbFDel5pQbpeflF6VmKxQ2pFSWleSr5ecn4uAxenAMzQy+bM /4v/zBGfa+XAOvOGXqTUwQde0rPmL9P6KDS/8HLSjbKjN5fM+bfO0StszgfhZK0N R3X5lKuSzsUa1B5fWvKed/HOTZ9rbrUw8ZdwuT9d33bV/8xzcbFLe+y//76ttcg8 v3G1sbjG1kSh62GcnIEmgay1uU4C06ezaT7wbJ1222IN60yGD7w3DwAA =HgpN -END PGP MESSAGE- [EMAIL PROTECTED]:~$ The key details are: [EMAIL PROTECTED]:~$ gpg --edit-key b565716f gpg (GnuPG) 1.4.2.2; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Secret key is available. pub 1280R/B565716F created: 2002-05-05 expires: 2006-08-14 usage: CS trust: ultimate validity: ultimate sub 1280R/4D5D40AE created: 2002-05-05 expires: 2006-08-14 usage: E sub 1024R/09CC4670 created: 2006-03-18 expires: 2007-04-22 usage: A sub 1024R/AABB1F7B created: 2006-03-18 expires: 2007-04-22 usage: S sub 1024R/A14C401A created: 2006-03-18 expires: 2007-04-22 usage: E [ultimate] (1). Simon Josefsson <[EMAIL PROTECTED]> [ultimate] (2) Simon Josefsson <[EMAIL PROTECTED]> Command> [EMAIL PROTECTED]:~$ Thanks, Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proof of email ownership
Werner Koch <[EMAIL PROTECTED]> writes: > To create a signature on an email (or any other data) you would use: > > gpg -s [EMAIL PROTECTED]@example.org foo I get this: [EMAIL PROTECTED]:~$ gpg -s [EMAIL PROTECTED]@extundo.com foo You need a passphrase to unlock the secret key for user: “Simon Josefsson <[EMAIL PROTECTED]>” 1280-bit RSA key, ID B565716F, created 2002-05-05 gpg: can't put notation data into v3 (PGP 2.x style) signatures [EMAIL PROTECTED]:~$ Is my key unusable with this scheme? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Proof of email ownership
Werner Koch <[EMAIL PROTECTED]> writes: > On Mon, 8 Aug 2005 09:37:10 +0200, Bernd Jendrissek said: > >> Do these TXT records support having multiple keys associated with the >> same email address? For example, I use D7CBA633 for "everyday" signing >> and encryption, and 24EEB426 for tin foil hat applications. > > No. I can be extended to allow for this. The current implementation > with TXT records should be considered experimental. You could have multiple TXT records, one for each key. Would that work? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
