Re: gpgme_op_verify regression with gnupg 2.2.6?
Hello Werner, On Friday, 13 April 2018 12:16:22 CEST Werner Koch wrote: > On Thu, 12 Apr 2018 15:26, w...@gnupg.org said: > > Please stay tuned for a GPGME fix. I hope that you can test it too. > > I pushed a fix as weel as a new test to the master branch. I may also > release a 1.10.1 to fix this. The attached pacth should apply to 1.10.0 > and maybe also to 1.9. all tests pass fine with the additional fix for gpgme. Thanks! I'm wondering how to prevent other people from running into this issue. Could gnupg 2.2.7 detect if gpgme is installed at all and if it is, make sure it's at least version 1.10.1 / 1.11.0? Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgme_op_verify regression with gnupg 2.2.6?
On Thursday, 12 April 2018 12:56:30 CEST Thomas Jarosch wrote: > Hi Werner, > > On Thursday, 12 April 2018 11:53:33 CEST Werner Koch wrote: > > I think I will fix it in GnuPG. Attached is an already pushed fix. > > with that fix applied on top of gnupg 2.2.6 vanilla, > one gpgme 1.10.0 unit test fails: > > t-verify.c:239: GnuPG: General error > FAIL: t-verify forgot to mention: The test doesn't fail when the patch is not applied. Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgme_op_verify regression with gnupg 2.2.6?
Hi Werner, On Thursday, 12 April 2018 11:53:33 CEST Werner Koch wrote: > I think I will fix it in GnuPG. Attached is an already pushed fix. with that fix applied on top of gnupg 2.2.6 vanilla, one gpgme 1.10.0 unit test fails: t-verify.c:239: GnuPG: General error FAIL: t-verify Sorry for raining on your parade :) Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgme_op_verify regression with gnupg 2.2.6?
On Wednesday, 11 April 2018 10:03:42 CEST Thomas Jarosch wrote: > Error output from gpgme_op_verify(): > > gpgme_op_verify error: General error thanks to Werner's hint with GPGME_DEBUG in another gpgme related thread, I was able to generate a short log file for gnupg 2.2.5 and gnupg 2.2.6. Here's the relevant part: *** gnupg 2.2.5 *** _gpgme_io_read: enter: fd=0x5, buffer=0x9fab6b8, count=1024 _gpgme_io_read: check: 5b474e5550473a5d 2056455249464943 [GNUPG:] VERIFIC _gpgme_io_read: check: 4154494f4e5f434f 4d504c49414e4345 ATION_COMPLIANCE _gpgme_io_read: check: 5f4d4f4445203233 0a5b474e5550473a _MODE 23.[GNUPG: _gpgme_io_read: check: 5d204e4557534947 0a5b474e5550473a ] NEWSIG.[GNUPG: _gpgme_io_read: check: 5d20455252534947 203531324545 ] ERRSIG 512EEDD _gpgme_io_read: check: 3535393830434335 4220312038203030 55980CC5B 1 8 00 _gpgme_io_read: check: 2031343838393836 35313020390a5b47 1488986510 9.[G _gpgme_io_read: check: 4e5550473a5d204e 4f5f5055424b4559 NUPG:] NO_PUBKEY _gpgme_io_read: check: 203531324545 3535393830434335 512EEDD55980CC5 _gpgme_io_read: check: 420a B. _gpgme_io_read: leave: result=146 _gpgme_io_select: enter: fds=0x9fac1a8, nfds=10, nonblock=0 _gpgme_io_select: check: fds=0x09fac1a8, select on [ r0x5 ] _gpgme_io_select: check: fds=0x09fac1a8, select OK [ r0x5 ] _gpgme_io_select: leave: result=1 _gpgme_run_io_cb: call: item=0x9fac190, need to check _gpgme_io_select: enter: fds=0xbfca2504, nfds=1, nonblock=1 _gpgme_io_select: check: fds=0xbfca2504, select on [ r0x5 ] _gpgme_io_select: check: fds=0xbfca2504, select OK [ r0x5 ] _gpgme_io_select: leave: result=1 _gpgme_run_io_cb: call: item=0x9fac190, handler (0x9faa8e8, 5) _gpgme_io_read: enter: fd=0x5, buffer=0x9fab6b8, count=1024 _gpgme_io_read: leave: result=0 _gpgme_io_close: enter: fd=0x5 _gpgme_io_close: check: fd=0x5, invoking close handler 0xb76790a0/0x9faa8e8 _gpgme_remove_io_cb: call: data=0x9fac180, setting fd 0x5 (item=0x9fac190) done _gpgme_io_close: leave: result=0 gpgme:gpg_io_event: call: gpg=0x9faa8e8, event 0xb7665150, type 1, type_data 0xbfca2574 GPGME 2018-04-12 10:03:58 <0x02d6> gpgme_op_verify: leave GPGME 2018-04-12 10:03:58 <0x02d6> gpgme_op_verify_result: enter: ctx=0x9faaf60 GPGME 2018-04-12 10:03:58 <0x02d6> gpgme_op_verify_result: check: ctx=0x9faaf60, sig[0] = fpr A93971254B380E6EE4CDF80F32064F2D0D3C2EB1, summary 0x3, status Success *** gnupg 2.2.6 *** _gpgme_io_read: enter: fd=0x5, buffer=0x8ebe6b8, count=1024 _gpgme_io_read: check: 5b474e5550473a5d 2054525553545f55 [GNUPG:] TRUST_U _gpgme_io_read: check: 4c54494d41544520 30207067700a5b47 LTIMATE 0 pgp.[G _gpgme_io_read: check: 4e5550473a5d2056 4552494649434154 NUPG:] VERIFICAT _gpgme_io_read: check: 494f4e5f434f4d50 4c49414e43455f4d ION_COMPLIANCE_M _gpgme_io_read: check: 4f44452032330a5b 474e5550473a5d20 ODE 23.[GNUPG:] _gpgme_io_read: check: 4e45575349470a5b 474e5550473a5d20 NEWSIG.[GNUPG:] _gpgme_io_read: check: 4552525349472035 313245453535 ERRSIG 512EEDD55 _gpgme_io_read: check: 3938304343354220 3120382030302031 980CC5B 1 8 00 1 _gpgme_io_read: check: 3438383938363531 3020390a5b474e55 488986510 9.[GNU _gpgme_io_read: check: 50473a5d204e4f5f 5055424b45592035 PG:] NO_PUBKEY 5 _gpgme_io_read: check: 313245453535 393830434335420a 12EEDD55980CC5B. _gpgme_io_read: check: 5b474e5550473a5d 204641494c555245 [GNUPG:] FAILURE _gpgme_io_read: check: 206770672d657869 742035353434 gpg-exit 335544 _gpgme_io_read: check: 0a33. _gpgme_io_read: leave: result=211 _gpgme_io_select: enter: fds=0x8ebf1a8, nfds=10, nonblock=0 _gpgme_io_select: check: fds=0x08ebf1a8, select on [ r0x5 ] _gpgme_io_select: check: fds=0x08ebf1a8, select OK [ r0x5 ] _gpgme_io_select: leave: result=1 _gpgme_run_io_cb: call: item=0x8ebf190, need to check _gpgme_io_select: enter: fds=0xbfd548b4, nfds=1, nonblock=1 _gpgme_io_select: check: fds=0xbfd548b4, select on [ r0x5 ] _gpgme_io_select: check: fds=0xbfd548b4, select OK [ r0x5 ] _gpgme_io_select: leave: result=1 _gpgme_run_io_cb: call: item=0x8ebf190, handler (0x8ebd8e8, 5) _gpgme_io_read: enter: fd=0x5, buffer=0x8ebe6b8, count=1024 _gpgme_io_read: leave: result=0 _gpgme_cancel_with_err: enter: ctx=0x8ebdf60, ctx_err=33554433, op_err=0 _gpgme_io_close: enter: fd=0x5 _gpgme_io_close: check: fd=0x5, invoking close handler 0xb76e80a0/0x8ebd8e8 _gpgme_remove_io_cb: call: data=0x8ebf180, setting fd 0x5 (item=0x8ebf190) done _gpgme_io_close: leave: result=0 gpgme:gpg_io_event: call: gpg=0x8ebd8e8, event 0xb76d4150, type 1, type_data 0xbfd548c8 _gpgme_cancel_with_err: leave gpgme_op_verify:1176: error: General error -> to me it seems gnupg 2.2.6 exits with failure once it encounters an unknown public key. Is this behavior to be expected or considered a regression? >From the 2.2.6 changelog it sounds like this change: "gpg: Emit FAILURE status lines in almost all cases. [#3872]" Versions used f
gpgme_op_verify regression with gnupg 2.2.6?
Hello together,
after updating from gnupg 2.2.5 to 2.2.6, I'm facing a possible regression.
We use the gpgme 1.8.0 library to verify the integrity of our update packages.
Two valid signatures need to be present on the checked file.
One unit test checks a file that is signed by two
known keys + unknown (future) key.
Error output from gpgme_op_verify():
gpgme_op_verify error: General error
Code that produced this:
gpg_err = gpgme_op_verify (gpg_context.get(), gpg_data.get(), NULL, NULL);
if(gpg_err != GPG_ERR_NO_ERROR)
throw runtime_error("gpgme_op_verify error: " +
string(gpgme_strerror(gpg_err)));
Having a file signed with xx known keys and y unknown
keys worked fine in gnupg 2.1.17 and 2.2.5.
Another unit test that just checks a file signed with one unknown key
fails in the same manner.
I'll try to upgrade to gpgme 1.10.0 and see if that helps with gnupg 2.2.6.
Anyway: Thanks for the new gnupg 2.2.6 release!
Cheers,
Thomas
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Is signing a file with multiple keys possible
Hi Dirk, On 03/24/2018 02:04 AM, Dirk Gottschalk via Gnupg-users wrote: >>> Is it possible to sign a file with multiple keys? >> >> Yes. Slightly lower-level operations than normal signing, but not by >> much, you just need to know about enarmor/dearmor and how signatures >> are >> put together. >> ... > > Thank you very much. It's like chaining up PEM Certs in OpenSSL. Why > didn't I even think about this? The Format is so similar. it's even easier when two or more people sign at the same time, just supply "-u KEYID" multiple times. At $dayjob our software updates are signed with two smartcards (four eye principle). Here's the relevant part from the sign script: gpg_cmd = ['/usr/bin/gpg2', '--personal-digest-preferences', 'sha256'] for gpg_id in gpg_sign_ids: gpg_cmd.extend(['-u', gpg_id]) gpg_cmd.extend(['--sign', shlex.quote(target_file)]) Cheers, Thomas signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
openpgp smartcard: ssh auth speed vs. RSA key size
Hello together, here's an interesting observation on ssh auth speed when using different key sizes on the openpgp smartcard: RSA 2048 bit key: 0.7s RSA 4096 bit key: 3.1s Card used is an openpgp smartcard V3.3 with gnupg 2.2.4. The ssh key is accessed via gpg-agent. We found this while creating our keys with 4096 bit and now reverted to 2048 bit. It's secure enough and the speed hit is almost not noticeable. The time was measured with: $ time ssh SERVERNAME /bin/true Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gnupg SmartCard V3.3
Hello Klaus, On Thursday, 01 March 2018 10:08:14 CET Klaus Römer wrote: > This is my target device because it is build-in in our Laptops, > i found this ct 2017-10 (german computer magazine) Article, > where they claim the reader to be working with the openpgp smartcard Version > 2.1 by transfering precreated 4096-Bit keys. This is exactly what i am > tring to do - and it seems to work, only the stub keys are not being > generated… > > So either i am doing something stupid or the V3.3 card incorporated changes > which broke this. I ordered another reader and asked if it would be > possible do buy some 2.1 cards for cross-tersting, but it seems they would > have to be manufactured as they are out of stock. Today I'm also setting up a bunch of V3.3 cards. There is indeed a problem: OpenSC added support for the new cards just in the current git HEAD version. See: https://github.com/OpenSC/OpenSC/issues/1215 -> we compiled opensc from git on Fedora now are able to talk to the card. You might be affected by this if gnupg talks to the card via opensc instead of the builtin libusb based CCID driver. (that's what NIIBE Yutaka suspected in his reply) HTH, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --gen-key with key on smartcard
On Wednesday, 28 February 2018 14:50:39 CET Werner Koch wrote: > If you need this information a small tool to present an enhanced menu > could be written. That tool would then utilize gpgsm and gpg. GPA > might be a candidate to implement this. what do you think about Peter's idea: $ gpg --with-keygrip --card-status to show key ID -> keygrip mapping? Or is that not easily possible protocol wise? (I have zero knowledge about the keygrip stuff) Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gnupg SmartCard V3.3
Hello Klaus, On Tuesday, 27 February 2018 01:04:27 CET Klaus Römer wrote: > i bought two V3.3 cards, but can`t get them to work … > the keytocard command does not move the key but copy it and further on the > gpg2 --card-status -> fetch followed by gpg2 --card-status does not create > the stub keys, so gpg2 --list-secret-keys does not show any keys ... I have > the same (rsa4096) sub-key loaded to each slot 1,2,3 eg SEA and card-status > does show them … gpg2 --version is 2.1.11 > > > I did further tests by calling gpg2 —card-edit -> generate with keylength > 2048 and 4096 which fail with „card-error“ > > Tried gpg (GnuPG/MacGPG2) 2.2.3 > on a completely different machine (mac) > > Tried the other card (i bought two with consecutive serial numbers) > > Tried three different card-reader: > - Cherry GmbH SmartBoard XX44 > - KOBIL EMV CAP - SecOVID Reader III > - Alcor Micro AU9540 00 00 > > Can anybody help? I just tested an openpgp card V3.3 with a Cherry ST-2000 card reader and a Reiner cyberJack Go. It successfully created keys on the card and after a "factory-reset" command it also moved an existing key to the card just fine. Signing and decryption worked, too. Same thing with a V2.1 openpgp card. All tests have been done on a Fedora 27 live USB stick using gnupg 2.2.4. May be try on a non-Mac computer to see if this is the issue? If you want to give the Fedora 27 live CD a try, it might be good to update the included gnupg 2.2.0 to 2.2.4 before starting: dnf update -y gnupg2 libassuan libgcrypt libgpg-error Optionally: If you want "paperbackup" on the live system: dnf install -y git python3 python3-pillow PyX python3-qrencode enscript ghostscript zbar git clone https://github.com/intra2net/paperbackup.git See https://github.com/intra2net/paperbackup With the Fedora live CD, all operations are done on a ramdisk. Just remember to unplug the network cable once you start the key generation process :) HTH, Thomas -- Don't send emails here: jeffer...@intra2net.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpgsm --gen-key with key on smartcard
Hello together, gpgsm can be used to create X.509 certificates for existing secret keys on a openpgp smartcard. "gpg2 --card-status" looks like this: * .. Signature key : E642 8DAC 275A 3247 5B59 A16F A3E9 1268 663A 9918 created : 2018-02-27 23:04:28 Encryption key: 7BD4 D616 869A DABA 40EE 92CE 0B7C A078 D0C4 D69E created : 2018-02-27 23:04:28 Authentication key: 7DA6 B4FD 7E63 CA74 4BDC CE17 A006 6D00 9AD9 3260 created : 2018-02-27 23:04:28 sec> rsa2048/A3E91268663A9918 created: 2018-02-27 expires: never card-no: 0005 3E6D ssb> rsa2048/A0066D009AD93260 created: 2018-02-27 expires: never card-no: 0005 3E6D ssb> rsa2048/0B7CA078D0C4D69E created: 2018-02-27 expires: never card-no: 0005 3E6 * When invoking gpgsm --armor --output public.pem --gen-key one can choose (3) to use an existing key on a smartcard. The next menu present is this: * Available keys: (1) C9CD95DDF9B6430274F55168DE39877474DA66EE OPENPGP.1 (2) 9D81DD6BD19C9C13F9B03915344BCC6BBDFB8428 OPENPGP.2 (3) 24983DADCC9C49692D6BB30675967DD4B003957D OPENPGP.3 * To me it seems it shows the 'keygrip' instead of the smartcard key IDs? Debug output from gpgsm before the "available keys" prompt: * gpgsm: DBG: chan_5 <- S KEY-FPR 1 E6428DAC275A32475B59A16FA3E91268663A9918 gpgsm: DBG: chan_5 <- S KEY-FPR 2 7BD4D616869ADABA40EE92CE0B7CA078D0C4D69E gpgsm: DBG: chan_5 <- S KEY-FPR 3 7DA6B4FD7E63CA744BDCCE17A0066D009AD93260 gpgsm: DBG: chan_5 <- S KEY-TIME 1 1519772668 gpgsm: DBG: chan_5 <- S KEY-TIME 2 1519772668 gpgsm: DBG: chan_5 <- S KEY-TIME 3 1519772668 gpgsm: DBG: chan_5 <- S CHV-STATUS +0+32+32+32+3+0+3 gpgsm: DBG: chan_5 <- S SIG-COUNTER 4 gpgsm: DBG: chan_5 <- S KEYPAIRINFO C9CD95DDF9B6430274F55168DE39877474DA66EE OPENPGP.1 gpgsm: DBG: chan_5 <- S KEYPAIRINFO 9D81DD6BD19C9C13F9B03915344BCC6BBDFB8428 OPENPGP.2 gpgsm: DBG: chan_5 <- S KEYPAIRINFO 24983DADCC9C49692D6BB30675967DD4B003957D OPENPGP.3 gpgsm: DBG: chan_5 <- OK * I guessed which key is the correct one from the gnupg 2.2.4 debug output. When using a smartcard, what about showing the openpgp key IDs in the "Available keys" menu? Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[How-to] Use multiple smartcards simultaneously
Hello, here's a quick howto for using multiple smartcards at the same time on Fedora 26 with gnupg 2.2.4. To access multiple card readers simultaneously, the internal CCID driver of gnupg must be used. Steps: 1. Allow normal users to access the card readers: Create a "hwdb" file in /etc/udev/hwdb.d/99-smartcard-reader.hwdb This file contains a list of USB IDs of the card readers. usb:v04E6pE003* usb:v046Ap003E* usb:v0C4Bp0504* ID_SMARTCARD_READER=1 Adapt the USB device IDs to your card reader, some IDs are found here: https://wiki.gnupg.org/CardReader/PinpadInput The 'ID_SMARTCARD_READER' tag will trigger an udev rule in /usr/lib/udev/rules.d/70-uaccess.rules that adds the "uaccess" tag for the reader. This allows to access the card reader as normal user while you are logged in. 2. Update systemd's hwdb: systemd-hwdb update This re-generates the file /etc/udev/hwdb.bin 3. Prevent pcscd from starting pcscd can prevent gnupg from accessing the card reader using the internal CCID driver. Therefore you can mask (=disable) pcscd via systemd: systemctl mask --now pcscd.socket systemctl daemon-reload 4. Log out and log in again. All smartcards should now be listed when running "gnupg2 --card-status all" You can modify individual smartcards by using "gnupg2 --card-edit SERIALNO" *** Debug tips'n'tricks *** - Use "udevadm monitor --environment" to see how udev detects a card reader when plugged in. Example output: UDEV [10155.134146] add /devices/pci:00/:00:01.1/:01:00.0/usb1/1-3 (usb) ACTION=add BUSNUM=001 DEVNAME=/dev/bus/usb/001/015 DEVNUM=015 DEVPATH=/devices/pci:00/:00:01.1/:01:00.0/usb1/1-3 DEVTYPE=usb_device DRIVER=usb ID_BUS=usb ID_FOR_SEAT=usb-pci-_01_00_0-usb-0_3 ID_MODEL=SPRx32_USB_Smart_Card_Reader ID_MODEL_ENC=SPRx32\x20USB\x20Smart\x20Card\x20Reader ID_MODEL_FROM_DATABASE=SPR532 PinPad SmartCard Reader ID_MODEL_ID=e003 ID_PATH=pci-:01:00.0-usb-0:3 ID_PATH_TAG=pci-_01_00_0-usb-0_3 ID_REVISION=0601 ID_SERIAL=SCM_Microsystems_Inc._SPRx32_USB_Smart_Card_Reader_x ID_SERIAL_SHORT=x ID_SMARTCARD_READER=1 ID_USB_INTERFACES=:ff: ID_VENDOR=SCM_Microsystems_Inc. ID_VENDOR_ENC=SCM\x20Microsystems\x20Inc. ID_VENDOR_FROM_DATABASE=SCM Microsystems, Inc. ID_VENDOR_ID=04e6 MAJOR=189 MINOR=14 PRODUCT=4e6/e003/601 SEQNUM=4699 SUBSYSTEM=usb SYSTEMD_WANTS=smartcard.target TAGS=:seat:systemd:uaccess: TYPE=0/0/0 USEC_INITIALIZED=10155130754 Notice the "uaccess" tag in the output. It also contains the USB device path in DEVNAME=, in this case /dev/bus/usb/001/015. - Inspect the user ACL on the USB device file via "getfacl" getfacl /dev/bus/usb/001/015 # getfacl /dev/bus/usb/001/015 # file: dev/bus/usb/001/015 # owner: root # group: root user::rw- user:alice:rw- group::rw- mask::rw- other::r-- -> there's an extra read/write ACL for username "alice" in there. - enable scdaemon debug output in ~/.gnupg/scdaemon.conf When inspecting the log file, make sure there are no messages like "ccid open error: skip" If that's the case, try masking pcscd like above. Otherwise gnupg will fall back to pcscd mode which currently does not support multiple smartcards. See also: https://dev.gnupg.org/T1621#110805 Hopefully this short guide is useful to someone else when setting up multiple card readers. In fact it can even be helpful when using just one card reader, since setting up the device permissions using udev's uaccess system is tricky and sparely documented: https://github.com/systemd/systemd/issues/4288 Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG card && using the backup secret key
Am 13.06.2017 um 12:20 schrieb Matthias Apitz: >> AFAIK the "backup process" during key creation for the OpenPGP smartcard >> is a bit different: There is no interface / function on the card to >> export a key. Therefore, if you decide to create a backup, a key is >> first created on the host and *then* transferred onto the card. >> At least that's my understanding of it. > > Thanks for your posting, but now I'm really confused. The howto about > the card in https://gnupg.org/howtos/card-howto/en/smartcard-howto-single.html > says: > > ... > 3.3.2. Generating keys > > To generate a key on the card enter generate. You will be asked if you would > like to make an off-card copy of the encryption key. It is useful to say yes > here. > Note > > Without a backup you will not be able to access any data you encrypted > with the card if it gets lost or damaged. > ... just checked the source code: If you want a backup of the key, the "want_backup" variable is set. This later on translates to the "card_backup_key" variable. ---keygen.c--- /* * Generate a keypair (fname is only used in batch mode) If * CARD_SERIALNO is not NULL the function will create the keys on an * OpenPGP Card. If CARD_BACKUP_KEY has been set and CARD_SERIALNO is * NOT NULL, the encryption key for the card is generated on the host, * imported to the card and a backup file created by gpg-agent. If * FULL is not set only the basic prompts are used (except for batch * mode). */ void generate_keypair (ctrl_t ctrl, int full, const char *fname, const char *card_serialno, int card_backup_key) ---keygen.c--- -> so yes, if you want a backup, the key is created on the host. Security wise it would be bad if the card has a function to extract a key from it and there's a bug that could somehow trigger this function. Also it does not make a big difference if the key is created on the host or on the card if it ends up on the host anyway :) May be the documentation needs to clarify the situation a bit. Cheers, Thomas signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG card && using the backup secret key
Hi Matthias, Am 12.06.2017 um 20:12 schrieb Matthias Apitz: > > Please note: I have changed the Subject: of the thread to match better > the real problem. > > During generating the keys on the GnuPG card, one can (and should) > create some backup of the secret key into a file. It is totally unclear > to me how to make something usefull out of this file, for example import > it into a "normal" secret keyring to use it in case of the GnuPG acrd > gots lost. AFAIK the "backup process" during key creation for the OpenPGP smartcard is a bit different: There is no interface / function on the card to export a key. Therefore, if you decide to create a backup, a key is first created on the host and *then* transferred onto the card. At least that's my understanding of it. When we developed the paper backup tool (https://github.com/intra2net/paperbackup/blob/master/README.md) we created several keys on the host machine, transferred the key to the card and created a backup on paper. During this process we also tested the restore of a card, it worked just fine. Basically you re-import a private key from file and tell gpg2 to move it to the card with the --edit-key command. btw: If you create the keys on a preferable air gaped machine, there's the "scdrand" tool to feed the kernel random pool with random numbers generated by the hardware RNG from the OpenGPG card. We used this script: -- #!/bin/bash set -u if [ "$(whoami)" != "root" ]; then echo "Must be root (only root can add entropy to the kernel)" exit 1 fi echo "Activating scdaemon" gpg2 --card-status current_bytes=$(( $(cat "/proc/sys/kernel/random/entropy_avail") / 8)) echo "Emptying existing kernel random pool ($current_bytes)" dd if=/dev/random of=/dev/null bs=1 count="$current_bytes" echo "Starting scdrand with:" echo "- sleep time 2s" echo "- continuously add 128 random bytes from smartcard" ./scdrand.f25 -l -i 2 128 & sleep 3 watch -n 1 cat "/proc/sys/kernel/random/entropy_avail" -- Cheers, Thomas signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.1.19 released
On Wednesday, 01 March 2017 20:27:00 CET Werner Koch wrote: > Noteworthy changes in version 2.1.19 > > > .. > > * scd: Support for multiple card readers. > > * scd: Improved detection of card inserting and removal. thanks for the new release! The support for multiple card readers sounds very promising. I tried that setup a year ago and it was difficult to configure two isolated scademons at the same time. Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How U2F works
On Tuesday, 28 February 2017 00:28:21 CET NIIBE Yutaka wrote: > Anyhow, it would be possible for Gnuk to add U2F support (somehow > limited, because of available resource on board). regarding limited resources, the Yubikey people did a fine trick: There is no per-website data stored on the Yubikey. So the amount of websites you can use a single FIDO U2F key for is unlimited. See "Limited storage on device" for details: https://developers.yubico.com/U2F/Protocol_details/Key_generation.html Also I think the attestation key is not enforced by websites, so gnuk could just send a bogus / user configurable cert. Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Announcing paperbackup.py to backup keys as QR codes on paper
Hi Peter, On Wednesday, 22 February 2017 13:56:22 CET Peter Lebbing wrote: > Oh, as an aside, the advantage of paperkey is that it is > self-describing. I've tried paperkey with Gnupg 2.1.13 and it had trouble parsing the secret key data. May be the internal packet format changed or needs adaption. When I think about long term storage, I'd rather rely on the full data instead of a snippet of the openpgp packets. The argument about re-downloading the public key from the keyservers is valid though, but for the secret key a full backup is preferred in our use case. It's easy for the user to skip the public key backup. Also if the QR code scanning ever fails: There is base64 encoded text output at the end, too. That could be OCRed or typed in by hand if ever needed. (we use paperbackup.py just as additional backup) You can even use paperbackup.py to back up your ssh key :) Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: smartcard reader
Am 22.10.2016 um 00:26 schrieb Gregor Zattler: >> I've posted a "success report" about card readers a year ago: >> https://lists.gnupg.org/pipermail/gnupg-users/2015-August/054102.html >> >> The Reiner cyberJack Go "plus" (USB id 0c4b:0504) works fine, >> not sure about the version with "plus" though. > > Isn't there a contradiction between the last line and the line > before the last one? Sorry: did you test the "plus" version or not? yes, I noticed, too, after sending the message :o) I tested the plus version. The "with" should be a "without". See the earlier success report. May be we can add pictures to the wiki of some readers or include a side-by-side picture. I still have all three of them sitting on my desk. That might help others to decide. Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: smartcard reader
Am 19.10.2016 um 13:01 schrieb Werner Koch: [list of card readers] >> SCM SPR 532 >> USB ID: 04e6:e003 >> PC/SC reader name: SPRx32 > > .. > >> Reiner cyberJack Go >> USB ID: 0c4b:0504 > > Does not work. I've posted a "success report" about card readers a year ago: https://lists.gnupg.org/pipermail/gnupg-users/2015-August/054102.html The Reiner cyberJack Go "plus" (USB id 0c4b:0504) works fine, not sure about the version with "plus" though. The Cherry ST-2000 reader is a bit bulky, personally I like the SPR 532 but the cyberJack Go has a nice display and is easy to carry around. Yesterday I've came up with the idea if the cyberJack Go reader would also work with a USB OTG adapter on an Android based phone. Might be a nice alternative to NFC + software based pinpad. -> I will test this once I get my hands on an USB OTG adapter. HTH, Thomas signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Card reader success report (openpgp card v2.1)
On Tuesday, 11. August 2015 12:10:28 NIIBE Yutaka wrote: Three readers were tested: - Cherry ST-2000 - SCM SPR332 - Reiner SCT cyberjack go plus I think that USB vendor ID and product ID are: Cherry ST-2000 046a:003e Please confirm that and please let me know IDs for those new products of SCM SPR332 and Reiner SCT cyberjack go plus. here are the USB IDs from lsusb: 0c4b:0504 Reiner SCT Kartensysteme GmbH cyberJack go / go plus 04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader 046a:003e Cherry GmbH SmartTerminal ST-2xxx Funny that the SPR332 (that's the name on the backside of the reader) announces itself as a SPR532. That's because I maintain pages: http://wiki.gnupg.org/CardReader/PinpadInput https://wiki.debian.org/GnuPG/CCID_Driver ... along with the scdaemon implementation. that page made me buy those specific readers :) Chances were good they work fine with the openpgp card and I really want the pinpad to work. Besides, if you can include information of your operating system and its version, it helps other users. I tested it on Fedora 22 that ships gnupg 2.1.5. I manually upgraded to gnupg 2.1.6 (recompiled the .rpm package with the updated source tarball) to get the Cherry ST-2000 up and running. Later on I also tested git HEAD. Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Card reader success report (openpgp card v2.1)
Hello, as my first post to the list I wanted to write a little success report about using the openpgp card v2.1 with various smart card readers. Three readers were tested: - Cherry ST-2000 - SCM SPR332 - Reiner SCT cyberjack go plus gnupg2 versions used: 2.1.6 and git HEAD (5b7a80b) All three of them support pin entry via the keypad. I've first tested signing a file using a 2048 bit RSA key. All good. After that I generated a new 4096 bit RSA key via the Cherry ST-2000 as that was the most fragile one from the internal protocol point of view. (increased buffer sizes and other tweaks in the CCID code) All three card readers handle 4096 bit RSA keys without trouble. I've tested signing a file and ssh authentication. My thanks go to NIIBE Yutaka for fixing the Cherry ST-2000. Best regards, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
