Re: It takes 8-9 secs until pinentry asks for the PIN of the OpenPGP card

[NIIBE Yutaka]

Hello,

Matthias Apitz  wrote:
> This isn't that easy. The pcscd is running (when needed) as:
>
> purism@pureos:~$ ps ax | grep pcscd
>2151 ?Ssl0:00 /usr/sbin/pcscd --foreground --auto-exit
>
> it is launched by a system service:

I see.  IIUC, PureOS is Debian based.  There should be a file for systemd
as /lib/systemd/system/pcscd.service. Its content is something like:
==
[Unit]
Description=PC/SC Smart Card Daemon
Requires=pcscd.socket
Documentation=man:pcscd(8)

[Service]
ExecStart=/usr/sbin/pcscd --foreground --auto-exit $PCSCD_ARGS
ExecReload=/usr/sbin/pcscd --hotplug
EnvironmentFile=-/etc/default/pcscd

[Install]
Also=pcscd.socket
==

Then, to debug PC/SC service, you can have a file /etc/default/pcscd with:
==
PCSCD_ARGS=--debug
LIBCCID_ifdLogLevel=0x
==

Kill pcscd by systemctl, if any.

Kill the scdaemon by:

$ gpgconf --kill scdaemon

And then, when you try to access OpenPGP card by SSH or GnuPG, gpg-agent
invokes scdaemon, scdaemon tries to access PC/SC service, pcscd is
invoked by socket activation with systemd.  You can see the debug log
by journalctl.
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: It takes 8-9 secs until pinentry asks for the PIN of the OpenPGP card

[NIIBE Yutaka]

Hello,

Matthias Apitz  wrote:
> It seems that the first time is longer. I will increase the debug-level
> for scdaemon.

Thank you for the information.  I think that it's better to debug how
PC/SC goes.

To get full debug log in lower level, you can invoke pcscd manually with
root:

# LIBCCID_ifdLogLevel=0x pcscd -f --debug
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: It takes 8-9 secs until pinentry asks for the PIN of the OpenPGP card

[NIIBE Yutaka]

Hello,

I wonder if it taks always 8-9 secs, or it's only for the first time.

Matthias Apitz  wrote:
> /tmp/scdaemon-debug.log:
[...]
> 2024-05-15 11:07:58 scdaemon[16983] DBG: chan_7 <- SERIALNO
>
> It takes 8 secs until scdaemon detects the reader, waht does this maen?
>
> 2024-05-15 11:08:06 scdaemon[16983] detected reader 'L5 built-in SmartCard 
> Reader 00 00'
> 2024-05-15 11:08:06 scdaemon[16983] detected reader 'L5 built-in SmartCard 
> Reader 00 01'

The scdaemon dynamically loads PC/SC shared library and asks PC/SC
service for available card readers.  PC/SC service is invoked, if not
there.  Then, PC/SC service dynamically loads serial driver
(libccidtwin.so).  And it's the serial driver which accesses the card
access chip (IIUC, it's STM32L4xx).  That's what is going on.

But 8 seconds are too much.  Something is going wrong...
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gnupg + TPM 2.0 support request

[NIIBE Yutaka]

Hello,

sergio borghese wrote:
> 2023-12-10 16:46:24 gpg-agent[358316] DBG: chan_11 <- ERR 268435731 Unknown
> IPC command 

This is no harm.  TPM2d doesn't support GETINFO command.

> 2023-12-10 16:46:30 gpg-agent[358316] updating regular key file
> '/home/netresults.wintranet/borghese/gpg2.tmp/private-keys-v1.d/FDEE0860BCFCE24C29738F1ADBF42D4C7D95516B.key'
> by a shadow key inhibited

I fixed this problem in the repo of GnuPG 2.4/master, I suppose.  It's
the commit 9909f622f for 2.4.

The check was introduced (by the commit a1015bf2f) (in GnuPG 2.4.2),
which caused the problem for KEYTOTPM handling of gpg-agent.  Then fixed
in repo (will be in GnuPG 2.4.4).
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: No pinentry but pinentry installed

[NIIBE Yutaka]

Hello,

Your configuration of pinentry-program is:

Caleb Herbert  wrote:
> /gnu/store/rfy36kapnhx9djhxdi3a54x5p2n097xv-pinentry-gtk2-1.2.1/bin/pinentry-gtk-2

But what you tested in your command line is:

> /gnu/stor/gnu/store/rfy36kapnhx9djhxdi3a54x5p2n097xv-pinentry-gtk2-1.2.1/bin/pinentry-gtk-2

Is it intended?  I mean that there is "/gnu/stor" prefix in your command
line.  If you would like to test your configuration, it should be:

/gnu/store/rfy36kapnhx9djhxdi3a54x5p2n097xv-pinentry-gtk2-1.2.1/bin/pinentry-gtk-2

(with no prefix of "/gnu/stor")
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Learning about authentication

[NIIBE Yutaka]

Hello,

Daniel Cerqueira wrote:
> I want to know a bit, on how authentication and authorization works in
> GnuPG.

Do you mean authentication subkey in GnuPG?  It's basically
user-defined;  It's up to user how it is used.

Usually, it means use with OpenSSH.  For example, I have an
authentication subkey as my OpenPGP key.  I use it with GnuPG, when I
accesss git repo with OpenSSH.  SSH authentication is done by OpenSSH
and ssh-agent emulation of gpg-agent.  It means that the key is under
control of GnuPG, actually.

(Other possible use case is use with Scute for X.509 client certificate
authentication, together with Web browser.  This is not that
common/popular, though.)

FYI, I wrote this ten years ago:

Using GPG's authentication key for SSH access:
https://www.gniibe.org/memo/software/ssh/using-gpgkey-for-ssh.html

Hope this helps,
-- 


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

Re: epg-encrypt-string in Emacs seems to be incompatible with GnuPG 2.4.1 on macOS, 2.4.0 works

[NIIBE Yutaka]

Hello,

I'm sorry that I didn't have time yesterday.

"Herbert J. Skuhra"  wrote:
> This issue (bug id: T6481) is obviously fixed on master (commit
> 2f872fa68c6576724b9dabee9fb0844266f55d0d):
>
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=2f872fa68c6576724b9dabee9fb0844266f55d0d
>
> Will this be merged to STABLE-BRANCH-2-4 and part of the next release
> (2.4.4?)?

Yes.  It's pushed now.  If you see any regressions due to this patch,
please let us know.
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: libgcrypt 1.10.2 compile on AIX POWER

[NIIBE Yutaka]

Hello,

Frank Lindner  wrote:
> For 1.10.2 I now run into the following:
>> start ---<
> /opt/freeware/bin/bash ../libtool --tag=CC --mode=link cc
> -I/opt/freeware/include -qmaxmem=16384 -qlanglvl=extc99 -DSYSV
> -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_AIX52 -D_AIX53
> -D_AIX61 -D_AIX71 -D_AIX72 -D_ALL_SOURCE -DFUNCPROTO=15 -O2
> -I/opt/freeware/include -no-install -L/opt/freeware/lib64
> -L/opt/freeware/lib
> -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
> -Wl,-bmaxdata:0x8000 -o hashtest hashtest.o
> ../src/libgcrypt.la ../compat/libcompat.la -L/opt/freeware/lib
> -lgpg-error -lpthread

(line is wrapped by me)

IIUC, you manually supplied LDFLAGS (at configure or make), which
doesn't work well in this particular case (since LDFLAGS has a
precedence over locally specified ../src, compiler finds **installed**
version of libgcrypt, instead of currently building one).

Please check gpgrt-config from libgpg-error is installed correctly.
Possibly, in your case, it might be /opt/freeware/bin.  Then, make sure
/opt/freeware/bin in PATH, and run configure.

This way, configure script should find correct value for -L, by
gpgrt-config (no need to manually supply LDFLAGS).
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gnugp 2.4.3 fails to build with --disable-ldap

[NIIBE Yutaka]

Matthias Apitz  wrote:
> How to fix this?

Here is a commit of mine for GnuPG 2.4:

https://dev.gnupg.org/rG9ae3cfcabec9252c22d67b7a15c36f0a8cf22f0f
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: after OS update I can't use my OpenPGP card anymore

[NIIBE Yutaka]

Matthias Apitz  wrote:
> $ gdb /usr/local/libexec/scdaemon
> ...
> r --debug-all --verbose --verbose --server
> ...
> OK GNU Privacy Guard's Smartcard server ready
> SERIALNO
> [New LWP 101967 of process 2622]
>
> Thread 2 "pipe-connection" received signal SIGSEGV, Segmentation fault.
> Address not mapped to object.
> [Switching to LWP 101959 of process 2622]
> 0x000800434a57 in ?? () from /usr/local/lib/libgpg-error.so.0
> (gdb) bt
> #0  0x000800434a57 in ?? () from /usr/local/lib/libgpg-error.so.0
> #1  0x0008004314ef in ?? () from /usr/local/lib/libgpg-error.so.0
> #2  0x0008004304e4 in ?? () from /usr/local/lib/libgpg-error.so.0
> #3  0x00080042fdad in ?? () from /usr/local/lib/libgpg-error.so.0
> #4  0x00080042d5e3 in ?? () from /usr/local/lib/libgpg-error.so.0
> #5  0x0008004343ad in ?? () from /usr/local/lib/libgpg-error.so.0
> #6  0x000800432bef in gpgrt_log_info ()
>from /usr/local/lib/libgpg-error.so.0
> #7  0x002436e8 in ?? ()

It looks like SEGV when debug output.  Does it work when it's invoked
without --verbose?
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: after OS update I can't use my OpenPGP card anymore

[NIIBE Yutaka]

Hello,

Matthias Apitz  wrote:
> After an update of FreeBSD from 13-CURRENT to 14-CURRENT I can't used
> my OpenPGP card with the USB token anymore. In /var/log/messages
> it says:
[...]
> Any hints how to debug this

You can run scdaemon as a foreground process to debug.  An example
session is like:

$ SOME_PATH_TO_scdaemon --debug-all --verbose --verbose --server
...
SERIALNO
...
BYE
$ 

(Here, "SERIALNO" and "BYE" is input from terminal by a user)

Likewise, you can invoke scdaemon as a foreground process from GDB.
Then, you may locate the place where it crashes.
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: YubiKey/OpenPGP card connection issues for non-root user

[NIIBE Yutaka]

Hello,

Please note that I don't have any experience using scdaemon in a guest
OS of GNU/Linux.  So, my answer may be wrong/irrelevant.

"Felix E. Klee"  wrote:
> [felix@felix-arch ~]$ sudo gpg --card-status
> Reader ...: SCM Microsystems Inc. SPR 532 [CCID Interface]
> (51271741200012) 00 00

Please note that there may be two methods to access the device in
scdaemon:

  * in-stock CCID driver of scdaemon
  * the PC/SC service

Your output shows that you are connecting the smartcard reader through
the PC/SC service.

If it's not your intention and your scdaemon has support of in-stock
CCID driver, I'd recommend not to use the PC/SC service.  Perhaps,
simply uninstall pcscd.

That's because it's simpler for scdaemon.  It's easier to configure and
debug, if your purpose is only for use of OpenPGP smartcard.

If you have a reason using PC/SC service (say, for example, you need the
service for other applications and other cards, as well as your use of
OpenPGP smartcard for GnuPG), please make sure that you configure the
PC/SC service correctly.  You should test and make sure, by a normal
user, if you can access your cards by the PC/SC service correctly.

*   *   *

Also, I'm afraid that you are using older GnuPG.  In GnuPG 2.2, scdaemon
had a feature to fallback to the PC/SC service, when access to in-stock
CCID driver doesn't go well.  The feature is disabled in 2.4.  In GnuPG
2.4, when scdaemon has support of in-stock CCID driver, to use the PC/SC
service, you need manually configure scdaemon with "disable-ccid" (no
use of in-stock CCID driver).
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Air32F103 might run at 108MHz

[NIIBE Yutaka]

Hello,

I learned about Air32F103, another clone of STM32F103.  Unfortunately,
there is no reference manual available yet.

Air32F103:
https://wiki.luatos.com/chips/air32f103/index.html

Datasheet (in Chinese) *is* available here:
https://wiki.luatos.com/chips/air32f103/hardware.html

I looked around the code at:
https://gitee.com/iosetting/air32f103-template/blob/master/Libraries/AIR32F10xLib/inc/air32f10x_rcc.h

Because we can see a constant RCC_USBCLKSource_PLLCLK_4Div5, I guess
that it could run at 108MHz with 0 wait cycle, USB enabled.

If we don't care about side channel signal (for flash accelerator),
perhaps, it could run at 216MHz.

Currently, for Gnuk, GD32F103 (which is used for FST-01SZ) runs at 96MHz
with 0 wait cycle, USB enabled.  (It can run at 108MHz, but not with
USB.)
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Read random bytes from Gnuk potentially frequently without destroying the card

[NIIBE Yutaka]

Damien Goutte-Gattat wrote:
> In the specific case of the Gnuk token, the GET CHALLENGE command is
> implemented using the same logic as the one used in NeuG [2]. I have not
> looked in details how NeuG works, but given that it is specifically intended
> as a random number generator, I’d say it’s safe to assume than using it as
> intended cannot ”destroy the token”. :)

No, it never destroy the token.  So, for Gnuk Token, use it freely.

> # RANDOM 
> # 
> # Get NBYTES of random from the card and send them back as data.
> # This usually involves EEPROM write on the card and thus excessive
> # use of this command may destroy the card.

I didn't know this help text.  I think that it's specific to Zeitcontrol
card.

For Gnuk on STM32F103 (not the emulation version), it runs ADC (Analogue
to Digital Converter) for randomness.  It never destroy anything.

While intended usage of ADC is measurement of some analog input, we use
ADC to get noise (in theory, each sample has 0.5-bit of information,
nobody knows).
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Size for ECC keys have changed from 256 to 255

[NIIBE Yutaka]

Baptiste Beauplat wrote:
> I noticed that the key size reported by gpg --with-colons for ECC keys
> (ed25519) have changed from 256 to 255.

Thank you for sharing.  I didn't know that it is exposed to users.
(I considered it were (only) internal thing in libgcrypt.) 

> I was wondering if that's a bug, since from what I understand (certainly
> way to little) the public key size of ed25519 is fixed at 256 and the
> value 255 is only used in the prime number calculation (2^255 - 19).
>
> Note: The changed comes from the following commit in libgcrypt:
>
> https://dev.gnupg.org/rCdb7b2c591004868abedbc2c19d3bb2efebf8529d

Yes, I did it.

Let me explain the reason why I did.

It is certainly a "fix", from the viewpoint of the library.

The field is NBITS, number of bits (of the curve).  This information
(exact number of bits, instead of rounded one to 2^n) is needed.  For
example, in the computation of X25519, it needs to check if there are
more bit(s) in octet.  Besides, for other curves, this field is used in
this semantics (See NIST P-521).
-- 

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

Re: gpg: keydb_get_keyblock failed: Invalid object

[NIIBE Yutaka]

Hello,

Thank you for your report.

William Holmes wrote:
> gpg failed after I created a second sign-only Curve 448 key.

Please use --quick-add-key instead, while I'm fixing the bug.

My changes of following commits were not enough.

2b50f942672d9a2c325a818f21f69d3ee69255d3
36355394d865f5760075e62267d70f7a7d5dd671

I think that something like this will be needed to apply.

Please note that 448 keys are not yet standardized as OpenPGP.  So,
format for key, signature, encrypted data may be changed in future.

diff --git a/g10/keygen.c b/g10/keygen.c
index 239e7aca1..cb6487ea3 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -5879,7 +5879,12 @@ generate_subkeypair (ctrl_t ctrl, kbnode_t keyblock, 
const char *algostr,
   else if (algo == PUBKEY_ALGO_ECDSA
|| algo == PUBKEY_ALGO_EDDSA
|| algo == PUBKEY_ALGO_ECDH)
-curve = ask_curve (, NULL, NULL);
+{
+  curve = ask_curve (, NULL, NULL);
+
+  if (curve && (!strcmp (curve, "X448") || !strcmp (curve, "Ed448")))
+keygen_flags |= KEYGEN_FLAG_CREATE_V5_KEY;
+}
   else
 nbits = ask_keysize (algo, 0);
 
-- 

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

Re: MS Surface Go Sim Card appears to cause scdaemon crash

[NIIBE Yutaka]

Hello,

Derek C Hoffmann via Gnupg-users  wrote:
> It looks like scdaemon is crashing when attempting to access a sim card
> slot/sim card itself on my Surface Go.

It is my fault.  I added multiple card readers support (for PC/SC) to
GnuPG 2.3, and it causes an issue in your use case.  By default,
scdaemon tries to access all available card readers.  It has a bug
accessing the second reader when the first reader doesn't have a card.

Related bug is tracked at:

https://dev.gnupg.org/T5416

And it will be fixed in GnuPG 2.3.2.

> Any other suggestions as to prevent this crash without disabling the
> Mobile Broadband card?

If you have a line in scdaemon.conf, like:

reader-port Microsoft IFD 0

scdaemon will only access to the card reader.  Please try this, until
fixed version will be released.
-- 

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

Re: HID Omnikey 3121 Smart Card Reader and GPG

[NIIBE Yutaka]

Hello,

Brandon Anderson wrote:
> So I have purchased an Omnikey 3121 smart card reader for use with my
> GPG smart card version 2.1.

Reading the descriptors:

   https://ccid.apdu.fr/ccid/readers/CardMan3121.txt

It says:

   02 Short APDU level exchange

This means that the reader cannot handle larger data.

So, I think that Omnikey CardMan 3121 can work in the use case with
OpenPGP card if it's key is RSA 1024.

But it doesn't work well for RSA-2048 or RSA-4096.
-- 

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

Re: sha256 of libgcrypt is 10 times slower then busybox sha25sum util on qualcomm IPQ4018 board

[NIIBE Yutaka]

Hello,

袁建鹏 wrote:
> Caculate the sha256 of a 6MB file need 3 secoands:
>  # TIME=%e time ./fwtool check ipq4018.bin
> 3.23
[...]
> the libgcrypt build configure in IPQ4018 (ARM cortext A7 soc):
> conf := --disable-doc --enable-neon-support \
> --with-libgpg-error-prefix=$(APP_BUILD)/libgpg-error/ \
> --enable-digests="md5 rmd160 sha1 sha256 sha512 blake2" \
> --enable-ciphers="arcfour des aes cast5 chacha20" \
> --enable-pubkey-ciphers="rsa dsa ecc" \
> CFLAGS="-Wno-switch"

What compiler are you using?  If it emits code which uses integer unit
for FPU/vector operations, it's better to use --disable-neon-support
to build libgcrypt, instead.

> Is this a problem ? the busybox code seems no hardware support. why
> libgcrypt is slower so much than busybox.

It looks like busybox code only uses integer operations (no vector
operations) for ARM.
-- 

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

Re: keydb_search failed: Invalid argument

[NIIBE Yutaka]

Hello,

ಚಿರಾಗ್ ನಟರಾಜ್ wrote:
> I'm getting this error/warning even when I just decrypt an encrypted
> file using plain gpg.

If you keep using ~/.gnupg/pubring.gpg, I think this is the cause of
your problem.

In this case, see this comment in the bug tracker of GnuPG:

https://dev.gnupg.org/T5409#145906

To excerpt the solution from the comment, it's:
--
cd ~/.gnupg
gpg --export-options backup --export >allkeys.gpg
mv pubring.gpg pubring.gpg-saved
gpg --import-options restore --import http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg: keydb_search failed: Broken pipe

[Niibe Yutaka]

 On Sun, 25 Apr 2021 16:41, William Holmes said:
> I encrypted the file with '--hidden-recipient'.
> After decryption failed, gpg-agent was killed.

This is because there is a bug for decryption of anon recipient.

The size of input for decryption should be checked.  So far, we only
have Curve25519 for Montgomery curve.  With X448, we have another
Montgomery curve.  That's the reason.

Werner Koch wrote:
> We will have a solution soon.

Fixed in libgcrypt master by the commit:

060c378c050e7ec6206358c681a313d6e1967dcf
-- 

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

Re: Compile of gnupg-2.2.27 fails on t-keydb.c

[NIIBE Yutaka]

Frank  wrote:
> Hi Werner,
>
> I assume you are busy with the 2.30 release (congratulations!) but you  
> have any more hints how to get more informations on my compile problem?

Since Werner is busy, let me reply, to where I can understand.

IIUC, GnuPG 2.3.0 needs some fix for your environment (xlc on AIX).

> I think AIX might work with __inline__ (? have not tried that):

I think that xlc supports C99 standard.  But unfortunately, it seems
that it is used with an option of "-qlanglvl=extc89", which specifies
C89 standard.

Note that you need a compiler which supports C99 standard for "inline".

I your log:

> 
>  source='t-keydb.c' object='t-keydb.o' libtool=no   
> DEPDIR=.deps depmode=xlc /opt/freeware/bin/bash ../build-aux/depcomp   
> cc -qlanglvl=extc89 -DHAVE_CONFIG_H -I. -I..   
  ^^^

This is the problem.  I wonder where this option comes from.
If it is from autoconf, you would need a fix like:

diff --git a/configure.ac b/configure.ac
index 215a6535f..2a50c5b73 100644
--- a/configure.ac
+++ b/configure.ac
@@ -638,7 +638,7 @@ AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir)
 AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
 AM_SILENT_RULES
 AC_PROG_AWK
-AC_PROG_CC
+AC_PROG_CC_C99
 AC_PROG_CPP
 AM_PROG_CC_C_O
 if test "x$ac_cv_prog_cc_c89" = "xno" ; then

And you need to regenerate the configure script, becoure "make".

Or it is you who specified CC, you invoking make with

CC="cc -qlanglvl=extc99"

... may just work.
-- 

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

Re: Compile of gnupg-2.2.27 fails on t-keydb.c

[NIIBE Yutaka]

Frank  wrote:
> Hi Werner,
>
> I assume you are busy with the 2.30 release (congratulations!) but you  
> have any more hints how to get more informations on my compile problem?

Since Werner is busy, let me reply, to where I can understand.

IIUC, GnuPG needs some fix for your environment (xlc on AIX).

> I think AIX might work with __inline__ (? have not tried that):

I think that xlc supports C99 standard.  But unfortunately, it seems
that it is used with an option of "-qlanglvl=extc89", which specifies
C89 standard.

Note that you need a compiler which supports C99 standard for "inline".

I your log:

> 
>  source='t-keydb.c' object='t-keydb.o' libtool=no   
> DEPDIR=.deps depmode=xlc /opt/freeware/bin/bash ../build-aux/depcomp   
> cc -qlanglvl=extc89 -DHAVE_CONFIG_H -I. -I..   
  ^^^

This is the problem.  I wonder where this option comes from.
If it is from autoconf, you would need a fix like:

diff --git a/configure.ac b/configure.ac
index 215a6535f..2a50c5b73 100644
--- a/configure.ac
+++ b/configure.ac
@@ -638,7 +638,7 @@ AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir)
 AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
 AM_SILENT_RULES
 AC_PROG_AWK
-AC_PROG_CC
+AC_PROG_CC_C99
 AC_PROG_CPP
 AM_PROG_CC_C_O
 if test "x$ac_cv_prog_cc_c89" = "xno" ; then

And you need to regenerate the configure script, becoure "make".

Or it is you who specified CC, you invoking make with

CC="cc -qlanglvl=extc99"

... may just work.
-- 

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

Re: Reiner-SCT CyberJack secoder 2 (v2.2.0 USB 0c4b:0400)

[NIIBE Yutaka]

Daniel Pocock  writes:
> Reiner SCT cyberJack secoder 2
> v2.2.0
> USB: 0c4b:0400

It's good to check the list of CCID readers by libccid:

https://salsa.debian.org/rousseau/CCID/-/tree/master/readers

Since I cannot find the device in this list, I'm afraid it would not
work well.

For some testing (try and error), you can use pyscard:

https://pyscard.sourceforge.io/

Unfortunately, IMHO, smartcard access is not designed well to allow us
using (proprietary or undocumented) card reader easily.

I'd recommend to find a CCID card reader with TPDU exchange support
(lower level direct control of smartcard).
-- 

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

Re: [developer preview] smartcard + opengp as a linux gadget

[NIIBE Yutaka]

Vincent Pelletier wrote:
> I would like to announce my implementation of a software CCID card
> reader targeting the Linux gadget subsystem, along with a smartcard OS
> and openpgp card application to use with this reader.

Great.  (And thanks for the patches for tests of Gnuk.  I'll apply
those, soon.)

FWIW, it was around 2008/2009, when Daiki Ueno had an implementation of
USB token toolkit with Linux gadget, called "Tandoori" (IIRC).  I think
that the purpose was similar.

However, today, I can't find any code.

All that I found is a record of symposium called ComSys2008 (in
Japanese):

https://iss.ndl.go.jp/books/R10002-I09985680-00

Historically, it was done before Gnuk.
-- 

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

Re: SSH CA + gpg-agent + gnuk => error

[NIIBE Yutaka]

Francois Gervais via Gnupg-users wrote:
> Would the SIGCONT be the source of my problem?

No, not at all.  It's completely normal.

You need to locate the place where it fails.

*   *   *

FYI, we have a ticket for signing SSH CA by Gnuk Token.

https://dev.gnupg.org/T5041

This problem is... (for me) because of bad design of digital signature
for SSH CA.  If it's not larger, Gnuk 1.2.16 works.

I think it is possibly related to your issue.
-- 

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

Re: Clearing cached PIN for Yubikey

[NIIBE Yutaka]

ಚಿರಾಗ್ ನಟರಾಜ್ wrote:
> I was attempting to figure out what the 'canonical' way of clearing a
> Yubikey's cached PIN is.

Clearing the authentication status is supported in scdaemon (in the
lower level), but there is no good way by command line.

If you don't care about using a kind of develper's tool
(gpg-connect-agent), you can do following.

For signing, type:

$ gpg-connect-agent "SCD PASSWD --clear 1" /bye

For decryption/authentication, type:

$ gpg-connect-agent "SCD PASSWD --clear 2" /bye


Perhaps, using a tool for users would be more relevant.  Then,

$ gpgconf --kill scdaemon

could be used to clear all authentication status.
-- 

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

Re: agent_genkey failed: Invalid flag

[NIIBE Yutaka]

Hello,

Patrick Brunschwig wrote:
> gpg reports the following error:
>
> gpg: agent_genkey failed: Invalid flag
> gpg: key generation failed: Invalid flag
> [GNUPG:] ERROR key_generate 16777288
> [GNUPG:] KEY_NOT_CREATED
>
> Any idea what could be wrong here?

The error is from libgcrypt.  I think that libgcrypt is too old
to use Ed25519/Curve25519.

When generating Ed25519/Curve25519 key/subkey, gpg uses three flags:

comp
eddsa
djb-tweak

It seems that some flag(s) is not supported by libgcrypt in the user's
system.

Meaning:

comp: compact format
  (only use x or y-coordinate to represent an EC point)
eddsa: use for EdDSA
djb-tweak: specify bits of secret is tweaked DJB's method;
   MSB is set, LSBs are cleared.
-- 

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

Re: command "SCD SERIALNO openpgp" not answered correctly

[NIIBE Yutaka]

Matthias Apitz  wrote:
> On the old system where GnuPG is 2.2.12, the 'gpg2 --card-status' says:
>
> $ gpg2 --card-status
> Reader ...: 04E6:5816:55511725600891:0
> Application ID ...: D2760001240102010005532B
> Version ..: 2.1
> Manufacturer .: ZeitControl
> Serial number : 532B
> Name of cardholder: Matthias Apitz
> ...

Good.  You are using the internal CCID driver to access your card reader.

> But on the new system it does work correctly. Here are the details:
>
> $ uname -a
> FreeBSD c720-r357756 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r357756: Tue Feb 11 
> 18:52:09 CET 2020 guru@jet:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
[...]
> What could be causing this?

Most likely, it is a problem of permission of your usb device.

Please check your /dev/usb/* (in your old system and in your new
system).
-- 

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

Re: pinentry-gtk-2 dialog doesn't appear before getting input

[NIIBE Yutaka]

Andreas Ronnquist  wrote:
> I have a problem on Debian unstable (running in Virtualbox), running the
> Xfce desktop - 
>
> I have my gpg key on a card (a Librem key, which basically is a
> Nitrokey) when using pinentry to enter the card password, I first have
> to press my mouse on the screen (or a key on my keyboard) to make the
> password dialog appear.

I think that it's related to window manager.  For testing, you can
manually invoke pinentry like:

   $ pinentry # run pinentry by command line (-gtk2 or any)
   confirm# shows a dialog box
   bye# finish the session
   $ 

Doing this makes it easy to identify a problem (from complicated
interaction of gpg <-> gpg-agent <-> pinentry).

> Is there any way to make the dialog appear at once, when it is ready to
> take my passphrase entry, or some workaround of any kind?

It seems for me that:

You can somehow control the behavior of the window manager.

In its configuration by "Focus" tab in "Window Manager Tweaks":

https://docs.xfce.org/xfce/xfwm4/wmtweaks

And/or the first entry of "Accessibility" tab which says "Raise windows
when any mous button is pressed".

Or "Focus" tab in "Preferences":

https://docs.xfce.org/xfce/xfwm4/preferences

Looking the commit log of xfwm4 (about "stacking"), it appears something
has been changed.
-- 

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

Re: v2.1 openpgp smartcard -- packing in after a `key to card'

[NIIBE Yutaka]

Dirk-Willem van Gulik wrote:
> During a pretty standard create key; key to card cycle (scripted) - I got an 
> error
>
>   gpg: OpenPGP card not available: Card removed
>
> just after the ‘save’ in the —edit-key. A subsequent status check gives me:
>
>   gpg2 --card-status
>   gpg: OpenPGP card not available: Card removed
>
> with below scdaemon log information.

Unfortunately, your log only includes information _after_ the failure.

So, I could only guess about failure.  I guess that "key to card" was
failed for some reason.

> 2019-12-09 18:15:06 scdaemon[47159] detected reader 'SCM Microsystems Inc. 
> SPR 532'
> 2019-12-09 18:15:06 scdaemon[47159] detected reader 'ACS ACR122U PICC 
> Interface'
> 2019-12-09 18:15:06 scdaemon[47159] detected reader 'OMNIKEY AG CardMan 3121'

While you have three card readers...

> 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S READER OMNIKEY AG 
> CardMan 3121

What you were using was "OMNIKEY AG CardMan 3121", which only supports
short APDU level exchange.

It is listed in this list: https://ccid.apdu.fr/ccid/supported.html
It should work for 1024-bit key.

However, I'm afraid that probably, it doesn't work well with recent
PC/SC lite, because readers with short APDU level exchange only are
getting uncommon.

SCM SPR 532 works better, because it supports TPDU level exchance (lower
level).
-- 

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

Re: gpg-agent only checks for smartcard not for local keys

[Niibe Yutaka]

Hello,

Horst Skatmus wrote:
> The only problem I have is that the gpg-agent always checks for the
> smartcard even when keys are not stored on a smartcard.

When gpg-agent works as ssh-agent, it always checks (possible)
authentication key on smartcard, so that the authenticaiton key (when
available) can be used.

Specifically, SSH client askes ssh-agent about available keys by
REQUEST_IDENTITIES command.  When gpg-agent (as ssh-agent) gets
REQUEST_IDENTITIES command, it checks scdaemon about possible
authentication keys.  Let's call those key(s) "active smartcard key(s)".
There are also keys recorded under ~/.gnupg/private-keys-v1.d/.  Let's
call those keys "recorded keys".  Those "recorded keys" can be private
keys on disk, or keys on smartcard (reference to smartcard, not private
key secret).  For response to REQUEST_IDENTITIES command, gpg-agent
answers SSH "active smartcard key(s)" + "recorded keys".
(Here, "recorded keys" may include "active smartcard key(s)".)

After that, SSH server + client negotiate about keys and select a key.
Then, SSH client asks gpg-agent (as ssh-agent) a challenge-response
authentication by signing with SIGN_REQUEST command.


> I can switch off the scdaemon via --disable-scdaemon but this has no
> effect.

With --disable-scdaemon, gpg-agent should stop accessing scdaemon.
Do you reload setting (gpgconf --reload gpg-agent) after changing
your gpg-agent.conf?
--

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

Re: SSH CA + gpg-agent + gnuk => error

[NIIBE Yutaka]

Brennecke, Simon wrote:
> I have a question regarding the interaction of SSH with gpg-agent
> (and possibly also gnuk).
[...]
> So I generated a new ECC key in gnuk, imported the public keys in gpg.
> Added the keygrip everything to "~/.gnupg/sshcontrol"

Just FYI, for smartcard, adding a keygrip in sshcontrol is not needed,
if it is OK for your gpg-agent to just fail for signing request when
smartcard is not available.

> "ssh-add -L" shows me the key.
> I signed it with the CA.
> ssh tries to use the key...
> ... and this is where the error pops up.
>
> ssh tells me:
> sign_and_send_pubkey: signing failed: agent refused operation
>
> and gpg-agent tells me:
> gpg-agent[21629]: ssh request handler for sign_request (13) started
> gpg-agent[21629]: DBG: detected card with S/N D276000124010200FFFE43032234
> gpg-agent[21629]: smartcard signing failed: General error
> gpg-agent[21629]: ssh sign request failed: General error 

I don't think it is related to OpenSSH certificate.  For some reason,
possibly a bug, smartcard singing failed.  You can configure
.gnupg/scdaemon.conf with something like:

debug-level guru
debug-all
verbose
log-file /run/user/1000/scd.log

to see what's going on.


*   *   *

Here is another information, related.

OpenSSH certificate authentication doesn't work well with gpg-agent
(yet).  Ideally, OpenSSH certificate should be under control of
gpg-agent.

For detail, you can see:

https://dev.gnupg.org/T1756
https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031479.html

Protocol-wise, for gpg-agent, it is expected that the ssh does:

  * ssh askes ssh-agent (in our case, gpg-agent) to get OpenSSH
certificate by REQUEST_IDENTITIES command

  * (only after) REQUEST_IDENTITIES command, ssh askes ssh-agent
challenge-response by SIGN_REQUEST command

But the first part does not occur by current OpenSSH client.  The client
by itself answers back to the server using the certificate on disk
(under .ssh/), without asking ssh-agent.
-- 

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

Re: Cannot decrypt from smartcard using gnupg-2.2, can from 2.0

[Niibe Yutaka]

alejandro Cortez wrote:
> gpg: public key decryption failed: Invalid ID

This means that something goes wrong in your private key file for
your token, I suppose.

> Can anyone help debug this?

You can see more information, by following command line:

$ gpg-connect-agent "KEYINFO --list" /bye

This doesn't reveal secret (but your serial number).

The example output (of mine) is like:

==
$ gpg-connect-agent "KEYINFO --list" /bye
S KEYINFO A97A7983102513844456E5B687E46B936B14155C D - - - P - - -
S KEYINFO 65F67E742101C7FE6D5B33FCEFCF4F65EAF0688C T 
D276000124010200F5170001 OPENPGP.2 - - - - -
S KEYINFO 101DE7B639FE29F4636BDEECF442A9273AFA6565 T 
D276000124010200F5170001 OPENPGP.1 - - - - -
S KEYINFO 5D6C89682D07CCFC034AF508420BF2276D8018ED T 
D276000124010200F5170001 OPENPGP.3 - - - - -
OK
$
==

The third column is a keygrip.  The fifth column is an application ID
(vendor id + serial number) of the card.  The sixth column is the key
identifier.

The key identifier "OpenPGP.2" is used for decription process.

I suspect you have some different string there, for some reason.
-- 

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

Re: PGP Authentication with gpg4win+ssh

[NIIBE Yutaka]

Chris Horry  wrote:
> I also created an Authentication subkey for my other PGP Key, the only
> difference being it's not on my Yubkiey but in my regular keyring with
> Kleopatra.  This same key works just fine on my Linux boxes when I use it
> for authentication between them but not in Windows.  PuTTY shows no keys
> available in the agent and thus my login is rejected.
>
> Is there some setting I'm missing or does gpg4win only support PGP
> authentication with SSH via a smart card?

Your authentication subkey should be listed in .gnupg/sshcontrol, while
it is automatically supported for Gnuk Token and OpenPGP card.

For detail, I found this post:
https://ryanlue.com/posts/2017-06-29-gpg-for-ssh-auth#adding-keys
-- 

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

Re: GPG 2.1.0 Compatibility Metrix(Solaris/Linux/HP Unix) and Installation

[NIIBE Yutaka]

Madhav Narisetty  wrote:
> Can someone let me know the GPG 2.1.0 compatibility Metrix for
> Unix(Solaris/Linux/HP Unix).
> Also, I would require installation binaries and steps on Solaris / Linux
> and HP UX systems.

For GNU/Linux, distributions offer binaries for GnuPG.  These days,
GnuPG 2.1.x/2.2.x is available.

For Solaris, I checked OpenIndiana, but it only offers GnuPG 2.0.x
(yet), while libraries (except npth) are available.

For HP-UX, I checked the HP-UX Porting and Archive Centre [0], situation
is similar.  Since all libraries are available (including npth) there,
building GnuPG is not that hard, I suppose.

I, for myself, do my best to keep supporting those (older) systems, in
our development.  However, we don't actively develop GnuPG on those
systems.  Only occasionally, when needed.  Well, since I don't have any
access to HP-UX system any more, so, it depends on bug reporters.

Last month, in libgpg-error development, I learned that such older
Unixen tend to use ksh (variant) for /bin/sh.

I encourage users on Solaris and HP-UX to migrate GnuPG 2.2.

[0] http://hpux.connect.org.uk/
-- 

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

Re: "gpg: signing failed: Invalid length" when use brainpool512r1 keys to sign things

[NIIBE Yutaka]

mlnl  wrote:
>> gpg: signing failed: Invalid length
>> gpg: make_keysig_packet failed: Invalid length
>> Key generation failed: Invalid length
>
> tested & confirmed with GnuPG 2.2.10, libgcrypt 1.8.3 Debian Stretch 9.5

Not reproducible here (similar on Debian Stretch).

I tested with no configuration.

Is it reproducible under no configuration?

I tested with:

$ export GNUPGHOME=/tmp/g; mkdir -m=0700 $GNUPGHOME
-- 

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

Re: dirmngr cygwin resolv.conf

[NIIBE Yutaka]

Hello,

john doe  wrote:
> I'm willing to confirm that but I'm not sure how I would do that!?

I am considering a patch like following.  If you can build GnuPG for
Cygwin, you can try.  Or, you can ask Cygwin's package maintainer for
GnuPG.

The patch is: Don't try to look the error code, but fallback TOR_PORT2
always.

==
diff --git a/dirmngr/dns-stuff.c b/dirmngr/dns-stuff.c
index ffac816f9..88a4fce5c 100644
--- a/dirmngr/dns-stuff.c
+++ b/dirmngr/dns-stuff.c
@@ -735,13 +735,12 @@ libdns_res_open (struct dns_resolver **r_res)
 static int
 libdns_switch_port_p (gpg_error_t err)
 {
-  if (tor_mode && gpg_err_code (err) == GPG_ERR_ECONNREFUSED
-  && libdns_tor_port == TOR_PORT)
+  if (tor_mode && libdns_tor_port == TOR_PORT)
 {
   /* Switch port and try again.  */
   if (opt_debug)
-log_debug ("dns: switching from SOCKS port %d to %d\n",
-   TOR_PORT, TOR_PORT2);
+log_debug ("dns: switching from SOCKS port %d to %d (%s)\n",
+   TOR_PORT, TOR_PORT2, gpg_strerror (err));
   libdns_tor_port = TOR_PORT2;
   libdns_reinit_pending = 1;
   return 1;
-- 

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

Re: dirmngr cygwin resolv.conf

[NIIBE Yutaka]

Werner Koch  wrote:
> ... on Windows.  Actually I developed the fallback on Windows becuase
> there it is easier to install the Tor browser.  Anyway, Gniibe probably
> found and fixed the problem in our DNS resolver.  I suggest to wait for
> the next release - probably next week.

That's not for Cygwin on Windows, but for GNU/Linux.

In dirmngr, the DNS resolver using Tor assumes that it returns
ECONNREFUSED when Tor doesn't run at 9050, then, it tries to the port
9150.

There was a bug of the DNS resolver.  When there are multiple
"nameserver" in /etc/resolv.conf, it should try all.  It was fixed, but
this fix had a side effect for ECONNREFUSED fallback mechanism for using
Tor.  This was fixed on Monday.


For the particular issue for Cygwin, it seems that connect(2) in Cygwin
environment may return EPERM instead of ECONNREFUSED.  I suspect this.

We can add the case of EPERM for Cygwin for workaround...
-- 

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

Re: dirmngr cygwin resolv.conf

[NIIBE Yutaka]

Hello,

Sorry, my explanation was not accurate.  In the Tor-mode of dirmngr, it
uses the port 9050 at first.  And there is some code to fallback to the
port 9150.  It's like:

libdns_switch_port_p (gpg_error_t err)
{
  if (tor_mode && gpg_err_code (err) == GPG_ERR_ECONNREFUSED
  && libdns_tor_port == TOR_PORT)
{
  /* Switch port and try again.  */
  if (opt_debug)
log_debug ("dns: switching from SOCKS port %d to %d\n",
   TOR_PORT, TOR_PORT2);
  libdns_tor_port = TOR_PORT2;
  libdns_reinit_pending = 1;
  return 1;
}
  return 0;
}

I suspect the error detection is not working well.  If it works,
you should see the debug message of "dns: switching from SOCKS port...".

I tested with the port 9050, my dirmngr works fine.
-- 

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

Re: Choice of ECC curve on usb token

[NIIBE Yutaka]

Hello,

Why not Curve25519, if you use ECC?

Damien Cassou  wrote:
> curves and (2) Bernstein’s Curve 25519 is hard to protect against side
> channel attacks when being implemented in embedded devices.

Quite interesting opinion.  I wonder what kinds of side channel attacks
are discussed there.  Well, it's the first time for me to hear such an
opinion.  Are there some confusions?

Curve25519 is designed against side channel attacks in mind.  Also, it
comes with a reference implementation.  Even if an implementation
doesn't use the methodology directly, it is a bit harder to write weaker
implementation (against side channel attack), if an implementer
understands Curve25519 correctly.  <-- this is my own opinion.

I wrote Curve25519 implementation for libgcrypt.  So far, libgcrypt
doesn't have field specific methods, but libgcrypt 1.9.x will have those
for Curve25519.  If we compare curves in libgcrypt, I think that
Curve25519 is good one.

I also wrote Curve25519 implementation for Gnuk.  Well, I also wrote
ones of NIST P-256 and secp256k1 for Gnuk.  I believe Curve25519 is the
best among those (and RSA).  Gnuk runs on STM32F103 @ 72MHz (or GD32F103
@ 96MHz).  This is an embedded device, of my daily use.
-- 

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

Re: dirmngr cygwin resolv.conf

[NIIBE Yutaka]

john doe  wrote:
> Now, the next step is to configure dirmngr to do the same!:
>
> dirmngr.conf:
>
> use-tor
> http-proxy socks5://localhost:9150

Only "use-tor" is needed, then, dirmngr connects to localhost:9150 for
Tor.
-- 

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

Re: Won't recognize my secret key

[NIIBE Yutaka]

Hello,

Thank you for your report.  I think I located the issue of migration.

Phillip Susi  wrote:
> I just noticed that I do have a bunch of key files in
> ~/.gnupg/private-keys-v1.d, even though gpg -K does not show them.
>
> Ahah, gpg -K -v shows them... it seems to think they are all expired.
> It lists the expiration date on my current key as 2018-1-6.  I believe
> that was the *original* expiration date, but then I extended it.  gpg
> 2.1 seems to be failing to recognize the extension.

For the problem of importing secring.gpg directly, we have a task:

https://dev.gnupg.org/T3101

Basically, secring.gpg only has the information of expiration when it's
created.  After changing expiration, it is only recorded in pubring.gpg.
So, it is recommended to do somthing like:

   $ gpg --homedir ~/.gnupg.old --export-secret-keys | \
gpg --homedir ~/.gnupg --import

(instead of doing --import ~/.gnupg/secring.gpg directly.)

However, in gnupg/g10/migrate.c, GnuPG itself does that (!).  This
should be fixed.
-- 

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

STM32F103 flash ROM read-out service

[NIIBE Yutaka]

Hello,

While learning Chinese language, I found this service (in Chinese):

http://www.pcbcopy.com/2016/ic_1128/1928.html

IIUC, It's a company in ShenZhen, which offers a service reading out
from protected STM32F103, even if it uses anti-tamper feature with a
battery.

I was aware of similar services for PIC18 or ATmega (in different
country).  This is new for me, specifically for STM32F103.

I don't know the detail of this service, but it seems that it's not that
expensive (from not-confirmed information by my friend).

Well, I encourage Gnuk users to new use KDF-DO feature with newer GnuPG.
-- 

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

Re: Problem signing git commits with smartcard key

[NIIBE Yutaka]

Hello,

If I understand correctly, you put:

your primary key to the OPENPGP.1 on card.
your subkey of SEA capability to the OPENPGP.2 on card.
your subkey of A capability to the OPENPGP.3 on card.

In this configuration, the OPENPGP.2 key on card is only for decryption.

You can't sign with that, even if its capability is specified Sign,
Encryption, and Authentication.

In OpenPGP card specification, three keys are different.

You can have a subkey with Sign capability and put it to OPENPGP.1 key
on card.
-- 

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

Re: Wrong Keygrip (gpg2 --card-status --with-keygrip)

[NIIBE Yutaka]

Hello,

Thanks for your report.

Dirk Gottschalk via Gnupg-users  wrote:
> gpg outputs the wrhon keygrip with --card-edit --with-keygrip. The
> output is:
[...]
> As you see, it returns the same grip for enc. and auth. key. This is
> wrong and "gpg2 -K --with-keygrip" returns the correct Keygrips.
>
> My gpg version is 2.2.6

It's a new feature introduced in 2.2.6, and I did not review the patch
well.

Just fixed and pushed in 71903eee8.
-- 

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

Re: Again: Writing DER certificates to ZeitControl Cards

[NIIBE Yutaka]

Dirk Gottschalk via Gnupg-users  wrote:
> I asked this Question a while ago, but unfortunately didn't get any
> response. So, I ask again and I'm in hope that somebody here knows any
> Answer to this. I just want to know if the cards do not support it, or
> is somebething wrong with my setup?

Most likely, the length of certificate matters.  If you can minimize
your certificate, please try.  I don't know the limitation for the card.
In case of my own implementation, I can only support data less than
2048-byte.

> Are these cards not capable of getting certs written on, or am I
> missing something?

FWIW, let me explain my opinion.  This might be irrelevant to the
implementation on ZeitControl Card, though.

The feature is one of the most difficult parts for an implementer of
OpenPGP card.  For my own implementation, I cannot implement it fully,
because of the possibility of larger size.  So, users of Gnuk Token have
to use special tool to write certificate, while reading is OK.

Since the feature is questionable for me (no real good use case), I even
put a compile time option for Gnuk to disable it, and that's the
default now.
-- 

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

Re: git commit signing: Asked for smartcard as it's plugged in

[NIIBE Yutaka]

Gabriel Augendre  wrote:
> Whenever I need to sign a git commit, I need to plug my Yubikey in and
> type the pin code. That works perfectly just after logging into my
> session, but if the computer goes to sleep (that's my guess, not sure
> about that) and I wake it up and try to sign another commit, GPGTools
> pinentry keeps asking to plug the yubikey in even though it's already
> there.

I think that this is related to the bug report:

https://dev.gnupg.org/T3825

I found that there are (at least four) different issues; Device firmware
problem, GnuPG scdaemon problem, PC/SC problem for GNU/Linux, and Linux
kernel problem.

Since your case is on macOS, latter two are not relevant.

I think that Yubikey somehow doesn't work well for USB suspend.  For
this problem, please contact the manufacturer.

I fixed a problem of GnuPG scdaemon and implemented work around for
device problem.  It will be in 2.2.6.  With the fix and the work around,
scdaemon tries to reset device after such a failure.  So, you won't need
to manually re-plug your device, but PIN input will be required, since
the device will be reset.

For GNU/Linux, I'd recommend to use internal CCID driver, instead.  It
seems that PC/SC development doesn't have an interest for suspend/resume.

The kernel problem is here:

https://www.spinics.net/lists/kernel/msg2757378.html

Since it is a kind of corner case which has been there long time, I
could not expect fix will be included soonish (or even getting
attention).  Thus, I changed scdaemon using pipe instead of signal (in
forthcoming 2.2.6).
-- 

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

Re: OpenPGP card bricked

[NIIBE Yutaka]

Matthias Apitz  wrote:
> Floss-shop.de sent me a new OpenPGP Card V3.3. It shows the same
> problem, see the log below. What should I do now? Send the USB-reader
> and the card back to them? I'm clueless

All that I can say is:

The reader has features which should work well for OpenPGP card with GnuPG:

> DBG: ccid-driver:   dwFeatures   000100BA
> DBG: ccid-driver: Auto configuration based on ATR (assumes auto voltage)
> DBG: ccid-driver: Auto voltage selection
> DBG: ccid-driver: Auto clock change
> DBG: ccid-driver: Auto baud rate change
> DBG: ccid-driver: Auto PPS made by CCID
> DBG: ccid-driver: TPDU level exchange

(I like TPDU reader, btw.  The simpler is the better.)

When scdaemon asks the reader to power on the smartcard, it fails.

> DBG: ccid-driver: PC_to_RDR_IccPowerOn:
> DBG: ccid-driver:   dwLength ..: 0
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 1
> DBG: ccid-driver:   bPowerSelect ..: 0x00 (auto)
> DBG: ccid-driver:   [0008]  00 00
> DBG: ccid-driver: RDR_to_PC_DataBlock:
> DBG: ccid-driver:   dwLength ..: 0
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 1
> DBG: ccid-driver:   bStatus ...: 65
> DBG: ccid-driver:   bError : 254
> DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC

So, it's not something complicated.  Just it doesn't work from the beginning.

Given the situation (the card should be OK and the reader should be OK,
possibly the machine is also OK), most likely, I suspect the contact
between the reader and the smartcard.
-- 

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

Re: OpenPGP card bricked

[NIIBE Yutaka]

Hello,

It seems that your smartcard is not working at all.
Possibly, bricked.

The log says (I removed the timestamp and process name):

> DBG: ccid-driver: CCID submit transfer (83): 0
> DBG: ccid-driver: PC_to_RDR_IccPowerOn:
> DBG: ccid-driver:   dwLength ..: 0
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 1
> DBG: ccid-driver:   bPowerSelect ..: 0x00 (auto)
> DBG: ccid-driver:   [0008]  00 00

The host PC asks the reader (RDR) to power on the smartcard.

> DBG: ccid-driver: CCID: interrupt callback 0
> DBG: ccid-driver: CCID submit transfer again 0

Then, the reader's interrupt transfer notifies to the host for change of
card status.  Host keeps the interrupt transfer, so, submit the transfer
to the USB host controller again.

> DBG: ccid-driver: RDR_to_PC_DataBlock:
> DBG: ccid-driver:   dwLength ..: 0
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 1
> DBG: ccid-driver:   bStatus ...: 65
> DBG: ccid-driver:   bError : 254
> DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC

The reader responds it fails to power on the smartcard.

> reader slot 0: using ccid driver
> DBG: enter: apdu_connect: slot=0
> DBG: enter: apdu_reset: slot=0
> DBG: ccid-driver: PC_to_RDR_IccPowerOn:
> DBG: ccid-driver:   dwLength ..: 0
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 4
> DBG: ccid-driver:   bPowerSelect ..: 0x00 (auto)
> DBG: ccid-driver:   [0008]  00 00

The host asks again to the reader.

> DBG: ccid-driver: RDR_to_PC_DataBlock:
> DBG: ccid-driver:   dwLength ..: 0
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 4
> DBG: ccid-driver:   bStatus ...: 65
> DBG: ccid-driver:   bError : 254
> DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC

Same failure.  Host gives up.

> DBG: leave: apdu_reset => sw=0x10009
> DBG: leave: apdu_connect => sw=0x10009
> DBG: enter: apdu_close_reader: slot=0
> DBG: enter: apdu_disconnect: slot=0
> DBG: leave: apdu_disconnect => sw=0x0
> DBG: ccid-driver: PC_to_RDR_IccPowerOff:
> DBG: ccid-driver:   dwLength ..: 0
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 5
> DBG: ccid-driver:   [0007]  00 00 00
> DBG: ccid-driver: RDR_to_PC_SlotStatus:
> DBG: ccid-driver:   dwLength ..: 0
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 5
> DBG: ccid-driver:   bStatus ...: 1
> DBG: ccid-driver:   bClockStatus ..: 0x01 (stopped-L)

And the host asks power off.  The reader replies.

> DBG: ccid-driver: libusb_cancel_transfer
> DBG: ccid-driver: libusb_handle_events_completed
> DBG: ccid-driver: CCID: interrupt callback 3

The host cancels interrupt transfer which watches card status change.

After the failure of internal CCID driver, it tries PC/SC.
-- 

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

Re: OpenPGP card bricked

[NIIBE Yutaka]

Matthias Apitz  wrote:
> After a power-off reset of my laptop the OpenPGP Card seems to be
> damaged. The pcscd can't read the card anymore. It gives up with:
>
> ...
> 6225 commands.c:244:CmdPowerOn Card absent or mute
> 0052 ifdhandler.c:1213:IFDHPowerICC() PowerUp failed
> 0017 eventhandler.c:301:EHStatusHandlerThread() powerState: 
> POWER_STATE_UNPOWERED

If it's really hardware problem, I can't help, but...

> What can I do?
[...]
> Identiv uTrust 3512 SAM slot Token

I believe that GnuPG's in-stock driver just works fine with this reader,
because it runs at TPDU level exchange.

Please try without PC/SC-lite, and see how it goes.

With following ~/.gnupg/scdaemon.conf, you can get debug log.

 ~/.gnupg/scdaemon.conf
verbose
verbose
debug-level guru
debug-all
debug-ccid-driver
log-file /some/where/scdaemon-debug.log

-- 

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

Re: Fwd: gnupg SmartCard V3.3

[NIIBE Yutaka]

Hello,

Werner Koch  wrote:
> @gniibe: Do you have any more up to date information on macOS and
> smartcard readers?

If possible, I recommend to use GnuPG's in-stock driver to access
smartcard.  It is direct access by libusb, not using PC/SC service.

For GNU/Linux, if you don't have any other use of PC/SC service, please
uninstall it, or disable the service, and try again with GnuPG's
in-stock driver.

For the driver, I maintain this list:

https://wiki.debian.org/GnuPG/CCID_Driver

For macOS, I think that it still uses old PC/SC and libccid library.
I'm afraid that new readers (with new features like pinpad support)
don't work well, or don't work at all.

I need macOS developers who build GnuPG with libusb.  Currently, GnuPG
scdaemon uses PC/SC service on macOS and Windows.  On GNU/Linux, people
can use both ways (in-stock driver or PC/SC).


> - Cherry GmbH SmartBoard XX44

  02 Short APDU level exchange

Because of this limitation, this reader cannot handle larger APDU (~=
packet), which is needed for recent RSA key size.  You can still use it
with RSA-1024.

> -  KOBIL EMV CAP - SecOVID Reader III

  bPINSupport: 0x03
 PIN Verification supported
 PIN Modification supported

I'm afraid it doesn't work on macOS.

> - Alcor Micro AU9540 00 00

I had a bug report with this reader: 

https://dev.gnupg.org/T1947

I think it now works fine by GnuPG's in-stock driver on GNU/Linux.
Please test.

It seems that this reader has a problem in PC/SC service, and it's not
supported by PC/SC-lite + libccid.

   https://pcsclite.alioth.debian.org/ccid/unsupported.html#0x058F0x9540

*   *   *

Supporting users' freedom on computing (for their privacy in digital
world), I need have/collect/maintain knowledge of those hardware.

But... when there is a problem, it tends to be because of bad firmware
implementation, which is proprietary.  In the proprietary world, the
practice is... to be "fixed" in the proprietary driver (than the
firmware).  But that "fix" has tendency not to be published to users or
developers of free software.

For me, it's a pity that I somehow need to have knowledge around those
proprietary firmware.

Perhaps, someday, in free software, I will write CCID reader
implementation which accesses smartcard, by free software (I mean,
development environment), for free software (= GnuPG maintenance); Then,
we can proceed to free firmware of smartcard itself.

# About ten years ago, I didn't take that approach but a short cut, that
# was Gnuk.  The reason was that it was difficult to find hardware
# vendors which allowed developing free firmware implementation of
# smartcard.

Having free CCID reader implementation still makes sense, to encourage
free firmware implementation of smartcard.  I'd like to work for some
part this year.
-- 

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

Re: BUG report gnupg-2.2.4 (or npth)

[NIIBE Yutaka]

Hello,

I think that you have some different Pthread library in /usr/local.

Henry  wrote:
> /usr/local/include/pthread.h:357:18: error: conflicting types for
  ^^^

I wonder if you have installed GNU Pth.  Please try without Pth.
-- 

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

Re: Performance regression, 2.2.3/recent?

[NIIBE Yutaka]

Hello,

Phil Pennock  wrote:
>   gpg --with-colons --with-fingerprint --with-subkey-fingerprint 
> --with-secret --list-keys
[...]
> $ grep '^open(' strace.foo | sort | uniq -c
> [...]
>3382 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 10
>   1 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 3
>   1 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 4
>   1 open("/home/pdp/.gnupg/pubring.kbx", O_RDONLY) = 7

It seems that pubring.kbx is accessed recursively (something by depth 3,
by fd: 4, 7 and 10 (fd 3 is to check the file type, I guess)).

Could you please try with --no-expensive-trust-checks option, if it
changes the behavior?
-- 

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

Re: Encrypt to a key without importing it to keyring

[NIIBE Yutaka]

Seby  wrote:
> Basically use gnupg without a keyring or trustdb. And the pass the armored
> pgp public key with each command and operation.

AFAIK, such a usage is not supported by GnuPG.

Well, I would imagine some use cases when we want to avoid any
dependency to specific user's configuration, keyring, and trustdb, of
his own.

Approximation would be using ephemeral GNUPGHOME.

I mean, starting your GnuPG session (or script) with:

   $ export GNUPGHOME=$(mktemp -p /run/user/$(id -u) -d)
   $ chmod og-rwx $GNUPGHOME; echo $GNUPGHOME

and remove the $GNUPGHOME after its use.

This is very useful for testing GnuPG, for example. 
-- 

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

Re: Using the OpenPGP Card on Unix && Win7

[NIIBE Yutaka]

Matthias Apitz  wrote:
> The produced log is:
>
> $ cat ../AppData/Local/VirtualStore/Windows/SysWOW64/scdaemon.log
[...]
> 2017-11-21 08:24:04 scdaemon[3868.2] DBG: enter: apdu_open_reader: 
> portstr=(null)
> 2017-11-21 08:24:04 scdaemon[3868.2] detected reader 'Broadcom Corp Contacted 
> SmartCard 0'
> 2017-11-21 08:24:04 scdaemon[3868.2] detected reader 'Broadcom Corp 
> Contactless SmartCard 0'
> 2017-11-21 08:24:04 scdaemon[3868.2] detected reader 'BROADCOM NFC Smartcard 
> Reader 1'
> 2017-11-21 08:24:04 scdaemon[3868.2] detected reader 'Identiv uTrust 3512 SAM 
> slot Token 0'
> 2017-11-21 08:24:04 scdaemon[3868.2] detected reader ''
> 2017-11-21 08:24:04 scdaemon[3868.2] reader slot 0: not connected

You have five card readers (the last one looks strange, though).

GnuPG's scdaemon select the first one as default.  IIUC, you want to use
'Identiv uTrust 3512 SAM slot Token 0'.

In .gnupg/scdaemon.conf, you should have something like:
===
reader-port "Identiv uTrust 3512 SAM slot Token"
===

... to select the token.
-- 

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

Re: Cannot control GnuPG from shell (IPC parameter error)

[NIIBE Yutaka]

Seby  wrote:
> I am running 2.3.0-beta82. I tried to search for this error and I
> could only find clues that lead to gpg-agent, but # gpg-agent --help
> doesn't allow me to disable it. What is the good approach here?

Please update your installation.

IIUC, you are talking about (old version of) gpg4win, which is based on
GnuPG 2.0.x, and you are trying to use new feature(s) of GnuPG 2.2, like
ECC.
-- 

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

Re: Importing an off-card backup of the encryption key of a Nitrokey fails with "no user ID"

[NIIBE Yutaka]

Hello,

Ralf  wrote:
> I generated keys on a Nitrokey and have chosen the option to make an 
> off-card backup of the encryption key:
>
> gpg: NOTE: backup of card key saved to 
> `/home/archi/.gnupg/sk_26D728A8F09033F1.gpg'

If you want to know the detail, this means that the encryption key is
generated on the host and it is imported to the card.  Generating on
card and extracting is not possible.

> gpg2 --import sk_26D728A8F09033F1.gpg

No.  It doesn't work, because the file is just the raw private key of
the encryption subkey.

> I only found a hint so far that the key can be uploaded to another card 
> with the bkuptocard command 
> (https://lists.gnupg.org/pipermail/gnupg-users/2017-June/058438.html), 
> but 

Yes.  It's "gpg --edit-key" which can be used for this file and it's
"bkuptocard" sub command to import the private key to the card again.

> I had hoped that it is possible to use the backup key without a
> card. Any hints here, is this possible?

In such a case, why not do that straight?  I mean, generating keys on
host and manually importing to device by "keytocard" of "--edit-key"?
You can control your key better.


The sk_26D728A8F09033F1.gpg is written in the OpenPGP format, but it is
not intended to be used by "--import" command; Even if it is created by
the data of subkey, the file uses PKT_SECRET_KEY type.

So, to achieve what you want, I guess, you need to write a small program
to handle this file to recover your private key on host.
-- 

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

Re: gpg-agent UI when waiting for smart card touch?

[NIIBE Yutaka]

David Mandelberg  wrote:
> I'm using gpg-agent with Yubikeys configured to require a physical touch 
> before performing operations. Is there any way to get gpg-agent to 
> display something on screen when it's waiting for me to touch the 
> Yubikey? (Otherwise, I sometimes don't realize it's waiting for 
> anything, and the operation times out.)

Some change in the protocol is required to implement this feature.


>From here, it's development thing.  Please skip reading, if you don't
need.

Most easy change would be adding a new flag into Slot Status register
in the CCID specification 1.1.  See page 55 of the specification for
the Table 6.2-3 Slot Status register.

Say, using bit-2 as: waiting user interaction flag, when Time extension
is required.

With that flag, the device will be possible to notify scdaemon (then,
gpg-agent) to pop up dialog.

Since we already have a flag in the card feature (in OpenPGPcard
specification v3), we can distinguish if a card supports this feature or
not.

That is just a idea.  I'll try with Gnuk Token, perhaps.
-- 

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

Re: Unable to sign or decrypt with card

[NIIBE Yutaka]

Philip Jackson  wrote:
> I created the scdaemon.conf file as you suggested and then ran a decrypt
> test :

Thank you.

> Perhaps there is something you can see which explains the problem ?

As far as I can see, it looks like no problem of scdaemon, but card
failure.

Here is the decrypt operation started:

> 2017-09-15 00:30:20 scdaemon[8306] DBG: send apdu: c=00 i=2A p1=80 p2=86 
> lc=257 le=2048 em=1

Since it's long command, it is devided into two blocks, (1) and (2).

This is the first block (1):

> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: PC_to_RDR_XfrBlock:
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   dwLength ..: 
> 258
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bSlot .: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bSeq ..: 29
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bBWI ..: 
> 0x04
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   wLevelParameter ...: 
> 0x
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   [0010]  00 20 FE 00 2A 
> 80
^
The first block has "more"-bit --

Then, this is the reply asking next block:

> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: RDR_to_PC_DataBlock:
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   dwLength ..: 4
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bSlot .: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bSeq ..: 29
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bStatus ...: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   [0010]  00 90 00 90

This is the next block (2):

> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: PC_to_RDR_XfrBlock:
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   dwLength ..: 16
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bSlot .: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bSeq ..: 30
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bBWI ..: 
> 0x04
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   wLevelParameter ...: 
> 0x
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   [0010]  00 40 0C FD E0 
> 81
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   [0016]  35 DD 4C B4 CA 
> 38 6E 08 00 54

This block is final with no "more" bit.

The expected behavior is the card reader returns text after decryption by card.
But, card reader returns only three bytes, where more than four bytes
are expected at least.

> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver: RDR_to_PC_DataBlock:
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   dwLength ..: 3
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bSlot .: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bSeq ..: 30
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   bStatus ...: 0
> 2017-09-15 00:30:20 scdaemon[8306] DBG: ccid-driver:   [0010]  00 00 00

So, it is interpreted as lower-level communication error.

> 2017-09-15 00:30:20 scdaemon[8306] ccid_transceive failed: (0x1000d)
> 2017-09-15 00:30:20 scdaemon[8306] apdu_send_simple(0) failed: aborted

Sending APDU, the command is somehow aborted.

> 2017-09-15 00:30:20 scdaemon[8306] operation decipher result: Operation 
> cancelled
> 2017-09-15 00:30:20 scdaemon[8306] app_decipher failed: Operation cancelled
> 2017-09-15 00:30:20 scdaemon[8306] DBG: chan_5 -> ERR 100663395 Operation 
> cancelled 
> 2017-09-15 00:30:20 scdaemon[8306] DBG: chan_5 <- CAN
> 2017-09-15 00:30:20 scdaemon[8306] DBG: chan_5 -> ERR 100663571 Unknown IPC 
> command 

This part is a little buggy, though.  The error code of GPG_ERR_CANCEL
is not that appropriate, I suppose.  Because of erroneous
GPG_ERR_CANCEL, gpg-agent wrongly send "CAN" (cancel) command to
scdaemon, which is unknown by scdaemon in this stage.  I'll fix this
part.


I don't know the reason why card error occurs.
-- 

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

Re: Unable to sign or decrypt with card

[NIIBE Yutaka]

Philip Jackson  wrote:
> I have the log file which I attach.
>
> It shows  a number of reports of the same error  (lines 89,91,97,99,101)
> ERR 83886254 Unknown option , before it asks me for the pin
> (line 111). It says 'confidential data not shown' three times but I only
> entered the pin once.
>
> Can you determine anything from this ?

Not much.  It fails just after sending a command to the card.  It seems
that there is some communication problem between host and card reader.

How 'gpg --card-status' works?

You can try to debug scdaemon by having .gnupg/scdaemon.conf:

=
debug-level guru
debug-all
verbose
debug-ccid-driver
log-file /run/user/1000/scd.log
=

Here is what we can see in your log.

> 2017-09-11 18:10:21 gpg-agent[8972] gpg-agent (GnuPG) 2.1.11 started
[...]

gpg-agent started.

> 2017-09-11 18:10:22 gpg-agent[8972] no running SCdaemon - starting it
[...]

And then, scdaemon started after PKDECRYPT command from gpg to gpg-agent.

> 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 -> SERIALNO
> 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 <- S SERIALNO 
> D2760001240102052870 0
> 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 <- OK
[...]

Card works fine to answer its serial number.

> 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 -> PKDECRYPT OPENPGP.2
> 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_7 <- INQUIRE NEEDPIN ||Please 
> enter the PIN
> 2017-09-11 18:10:22 gpg-agent[8972] starting a new PIN Entry
[...]

gpg-agent asks PKDECRYPT command to scdaemon, and scdaemon inquires PIN
for the authentication.

> 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_8 -> SETDESC Please enter the 
> PIN
> 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_8 <- OK
> 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_8 -> SETPROMPT PIN
> 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_8 <- OK
> 2017-09-11 18:10:22 gpg-agent[8972] DBG: chan_8 -> [[Confidential data not 
> shown]]
> 2017-09-11 18:10:23 gpg-agent[8972] SIGUSR2 received - updating card event 
> counter
> 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_8 <- [[Confidential data not 
> shown]]
> 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_8 <- [[Confidential data not 
> shown]]
> 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_8 -> BYE
[...]

This is interaction between pinentry and gpg-agent.

SIGUSR2 (it means: a card is found) comes from scdaemon to gpg-agent,
because scdaemon periodically checks if card is inserted.

> 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_7 -> END
> 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_7 <- ERR 100663395 Operation 
> cancelled 
> 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_7 -> CAN
> 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_7 <- ERR 100663571 Unknown IPC 
> command 
> 2017-09-11 18:10:30 gpg-agent[8972] smartcard decryption failed: Operation 
> cancelled
> 2017-09-11 18:10:30 gpg-agent[8972] command 'PKDECRYPT' failed: Operation 
> cancelled 
> 2017-09-11 18:10:30 gpg-agent[8972] DBG: chan_6 -> ERR 100663395 Operation 
> cancelled 
[...]

gpg-agent sends the PIN to scdaemon (until "END"), and I think that
scdaemon sends command to the card through card reader.  But it fails.

There are two ways to access card reader for GnuPG.  One is through
PC/SC, and another is internal CCID driver of GnuPG.  If it doesn't work
well with PC/SC, it's worth to try the internal CCID driver (or vice virsa).
-- 

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

Re: Bitcoin private key from GnuPG secp256k1 secret key?

[NIIBE Yutaka]

Stefan Claas  wrote:
> I could imagine that no one will do this, because if you have no
> private key for "your" public address (according to your reply),
> you have no control of that address, like spending/ sending
> BTC from this address.

Sorry about my vague description.

As a subkey of 0x00B45EBD4CA7BABE, I have a key of secp256k1.  And the
private key is controlled by me, on a Gnuk Token.  But I have no
"wallet", yet.  This is the situation.

My idea was that we can use WoT of OpenPGP to check Bitcoin address.
It seems that people don't buy this idea.
-- 

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

Re: Bitcoin private key from GnuPG secp256k1 secret key?

[NIIBE Yutaka]

Stefan Claas  wrote:
> just wondering if there is an easy way to generate a Bitcoin secret key
> from a GnuPG  secp256k1 secret key. If so, how would you do that?

I don't know about secret key conversion.

In the past, I did something for public key:

https://lists.gnupg.org/pipermail/gnupg-devel/2014-January/028147.html

However, soon after this scripting, it occurred the Mt. Gox incident in
Japan.  And I learned that most "users" don't control their private key
for Bitcoin at all, just like general citizen don't control printing of
paper money.  So, no further development for my side.  It was not
committed to GnuPG repo.  (I only have a transaction with the address.)

If someone will make transaction to that address for some amount, I
would resume the development again. :-)
-- 

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

Re: scdaemon does not "see" card insertion

[NIIBE Yutaka]

Hello,

Matthias Apitz  wrote:
> The script 'scd-event' is only invoked on card removal (I do just en
> echo of the args):
[...]
> A card insert is only seen *after* some agent requires something, for
> example the SSH client needs access to the secret key on the card;

Right.  Scdaemon only watches the event of card removal and card reader
removal.

In the past, once, scdaemon implementation in 2.0 partially tried to
support watching insertion, too.  The name "scdaemon" would have implied
that, perhaps.  We couldn't go this road well, because a card reader is
shared resource and there are valid use cases for other cards.

Then, the development of scdaemon evolved as openpgp-card-helper for
GnuPG.

This focus could stabilize the use case for GnuPG, and it resulted
less conflict for other use cases for card and card reader.

> On the UNIX system level the card insert triggers via devd(8) the start
> of /usr/local/sbin/pcscd and the card removal triggers a 'killall pcscd'.
> This is working fine, i.e. an inserted card is useable immediately, 
> requesting 
> the PIN entry.

IIUC, system level service like devd can only handle the event of card
reader insertion, not card insertion.  I may be wrong here.

I think that it is good for your use case to use PC/SC daemon
and its related tool.

I found a tool named card_eventmgr in:

https://github.com/OpenSC/pam_pkcs11/tree/master/src/tools/

This may help.  (No, I don't have any experience with this tool.)
-- 

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

Re: scdaemon coredumps

[NIIBE Yutaka]

Hello,

Thank you for your report.

"Yuriy M. Kaminskiy"  wrote:
> When I tried to rebuild gnupg2 2.1.21-2 debian package from
> experimental in pbuilder, I got a number of sigsegv's from scdaemon
> while running tests:
[...]
> Annoyingly, test-suite does not catch this as error, it has not left any 
> core, and name of executable was masked, so after twiddling here and
> there, I got core and discovered that scdaemon dies when it tries to use
> libusb after libusb intiialization failed:

There are two things here.  The selection of default key by gpg frontend
was not good.  It was fixed in:

fbb2259d22e6c6eadc2af722bdc52922da348677
g10: Fix default-key selection for signing, possibly by card.

And by your report, scdaemon core dump is fixed in:

   5c33649782bf255af5a55f16eac5e85f059b00bf
   scd: Handle a failure of libusb_init.

   8defb21d34410d000c8b776e0e3a1edd04762638
   scd: Fix error code on failure at usb_init.

> With patch below, it just freezes at
> === cut ===
> ...
> PASS: tests/openpgp/decrypt-unwrap-verify.scm
> Checking signing with the default hash algorithm
>   > plain-1 plain-2 <<< [here]
> === cut ===
> Have no idea why.

I don't know what's going here.  Let's see...
-- 

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

Re: Did exit codes change in 2.1.21?

[NIIBE Yutaka]

Philip Jocks  wrote:
> gpg: error getting version from 'scdaemon': Not supported
> [GNUPG:] CARDCTRL 6

This is due to my badness.  I wrongly assumed everyone uses smartcard.
:-)

> Is there anything else we can try?

Here is my fix:
   https://dev.gnupg.org/rGa8dd96826f8484c0ae93c954035b95c2a75c80f2

Please try this patch.
-- 

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

Re: command 'LEARN' failed: No inquire callback in IPC

[NIIBE Yutaka]

Dustin Rogers  wrote:
> In fact the native support for smart cards does not seem to support
> network attached HSM "virtual tokens" devices at all. It could be
> possible that I need to specify the local port the installed HSM agent
> is running on, but I dont think I will be that lucky.

No, scdaemon doesn't support it.

> I have this  other scdaemon (gnupg-pkcs11-scd) working fine with gnupg 2.0,

Well, I think that gnupg-pkcs11-scd is not supported by GnuPG, 2.0 or
2.1.  It is a kind of... independently developed program, unfortunately.
It was just coincidence (from my view point) it worked with GnuPG 2.0.

It would be good if someone around gnupg-pkcs11-scd shares developement
information with GnuPG.

> but with manual pinentry for each operation. I cant get it working
> with gnupg 2.1. (again, I am looking for the unattended pinentry
> support the later version seems to have) Thus, I really dont think
> this is an issue with the scdaemon I am using. Moreover, I can see the
> INQUIRE PIN callback is there, the pinentry is just not
> appearing. Really I would like to understand why the gpg-connect-agent
> is allowing the pin call back through, and the gpg-agent itself is
> not?

Well, it's the detail of protocol between gpg-agent and scdaemon.
INQUIRE NEEDPIN from scdaemon is not expected by gpg-agent when LEARN
--force is issued.  This situation is same in GnuPG 2.0.

We don't know how gnupg-pkcs11-scd works, according to your log, it
breaks the protocol for LEARN.

gpg-agent only delegates back the INQUIRE NEEDPIN request to gpg when it
is prepared: PKSIGN, PKDECRYPT, WRITEKEY, and generic SCD.

For gpg-connect-agent with SCD command, it is prepared, thus it works.

I think that it would be good to check why gnupg-pkcs11-scd called back
with INQUIRE NEEDPIN for LEARN command.
-- 

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

Re: command 'LEARN' failed: No inquire callback in IPC

[NIIBE Yutaka]

"Rogers, Dustin"  wrote:
> I have recently installed gnupg 2.1.20 from source on a centos6.8 box.

What's the configure option?  Did you enable smart card support with
libusb?

> [root@system1 ~]# gpg --card-edit
>
> gpg-agent[5158]: DBG: chan_8 -> OK Pleased to meet you, process 5159
[...]
> gpg-agent[5158]: DBG: chan_9 <- OK PKCS#11 smart-card server for GnuPG ready

This is not the scdaemon from GnuPG.

Please install scdaemon of GnuPG and try again with that.
-- 

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

Re: Passphrase cache w/Yubikey varies: sign vs auth

[NIIBE Yutaka]

Steve McKown  wrote:
> Can someone explain why ssh after sign asks for the passphrase again,
> and what I might be able to do to avoid this condition?  It's not a big
> deal, but I do wonder if it suggests a misconfiguration on my part.

It is not misconfiguration.  It is expected behavior.

Please note that there is no passphrase cache on host side for
smartcard.  It is the OpenPGP card which has the "authenticated" status.
Once it gets authenticated by PIN, a user can ask crypto operations.

And there are two different authenticated statuses for a user.  We call
them CHV1 and CHV2, where CHV means Card Holder Verification.  One for
signing (CHV1) and another for others (= decryption and authentication,
CHV2).

For OpenPGP card itself, CHV1 and CHV2 are independent (for v2 and
later).

By using GnuPG, they are not independent.  When a user authenticate for
CHV2, CHV1 is also authenticated automatically (provided the flag of the
card for "Signature PIN" is "not forced").  When a user authenticate for
CHV1, CHV2 is not affected.

I agree this is a bit confusing.  I don't know why it is so.  Perhaps,
we had some compatibility issue with older OpenPGP card.

I don't think we have an easy way to avoid being asked PIN for SSH after
signing.
-- 

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

Re: How U2F works

[NIIBE Yutaka]

NIIBE Yutaka <gni...@fsij.org> wrote:
> Well, I concluded that it is not worth (for me) to try to integrate U2F
> feature into Gnuk.

While I am open to discussion, my current position is that it is better
for Gnuk not to integrate the U2F feature.  I'd rather prefer separate
implementation of U2F, if needed, possibly reusing code of Gnuk (crypto,
USB, etc.).  I mean, by separate device.

My reasons are:

* The nature of two use case (OpenPGP private key vs. authentication for
  network service providers) are quite different.  Generally, Gnuk users
  don't want to allow other new additional attack vectors, because of
  adding "new feature" (and U2F would come with them).  OpenPGP private
  key is so important for Gnuk users.  U2F key is just a thing to enter
  web service which is owned by a device vendor.  For me, it is not wise
  to invite possible attacks just for some usefulness of
  not-so-important thing.

* Resource on physical board is quite limited (20KB RAM and 128KB ROM).
  For code space, we will need some features of Gnuk if we integrate
  U2F or other features.

* Unfortunately, currently, both of Gnuk and U2F uses same protocol of
  USB CCID.  In a host system, it is the practice of CCID on host side
  to access the device exclusively to mitigate some attacks (changing
  while using).  For example, GnuPG's scdaemon requires exclusive access
  to Gnuk Token.  I think it is also same or similar to browser access
  to U2F device.  I think that a single CCID device can't serve two
  different programs on host simultaneously.

Well, we can manage and consider possible solutions for the latter two
technical problems.  The first problem is most important, I suppose.

Keep adding things, it will become a system like host system,
eventually.  The purpose to separate out the management of OpenPGP
private key to a dedicated device is: make it simple and easier to
achieve better security.
-- 

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

Re: Homedir & scdaemon

[NIIBE Yutaka]

Hello,

Sorry, I should have offer more information.

Adam Sherman <a...@sherman.ca> wrote:
> That does not appear to be the case:
>
> scdaemon (GnuPG) 2.1.11
> libgcrypt 1.6.5
> libksba 1.3.3-unknown

Umm... it is better to have libgcrypt 1.7 for GnuPG.

Specifically, it was fixed by following commits.

-
8b6c0bae33bdc36892f4595806665ce61f77dfd2
Author: NIIBE Yutaka <gni...@fsij.org>
CommitDate: Fri Sep 2 13:41:19 2016 +0900

agent: invoke scdaemon with --homedir.
-
4e41745b3ea3bb8ffc50af6bafeb1de9c928812f
Author: Werner Koch <w...@gnupg.org>
CommitDate: Fri Jun 17 08:36:07 2016 +0200

scd: Make option --homedir work.
-

I confirmed that --homedir works fine with 2.1.16 and later.
-- 

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

Re: Homedir & scdaemon

[NIIBE Yutaka]

Adam Sherman  wrote:
> But, scdaemon seems more stubborn, and doesn't respect gpg2's homedir
> option. And trying to start it manually, beforehand, with the --homedir
> option, fails with:

For your information, this is fixed in 2.1.  If you will have a chance,
please try version 2.1.
-- 

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

Re: Generating RSA-4096 on Nitrokey Pro

[NIIBE Yutaka]

NIIBE Yutaka <gni...@fsij.org> wrote:
> I think that the CCID driver has a bug for TPDU handling for time
> extension from the card.

I confirmed that the problem can be reproducible with Gemelto card
reader (TPDU exchange).

The problem is that OpenPGP card (2.0 or 2.1) needs time out detection
of 43 seconds or so, and its BWI request value is 100 (which is quite
unusual).

The internal CCID driver doesn't handle block waiting time (BWT)
correctly according to the card protocol, but uses fixed timeout value
of 13-second.

I put a kludge to handle this special case in the internal CCID driver.

Fixed in 0848cfcce738150b53bfb65b78efc1e6dc9f3d26.
-- 

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

Re: Generating RSA-4096 on Nitrokey Pro

[NIIBE Yutaka]

Szczepan Zalega | Nitrokey  wrote:
> Same is occurring on latest GPG 2.1.19. Attached logs taken under Arch
> Linux. Any ideas how to fix it?

I have read the log which you attached on Monday.

I think that the CCID driver has a bug for TPDU handling for time
extension from the card.

This problem never occurred when a reader handles a time extension from
card and changes into the request of time extension from the reader.

I'll check how it works with my reader and OpenPGP card 2.1.  I will fix
the CCID driver.

Nitrokey Pro also can handle the card's request of time extension to
chang it to reader's request.

Anyhow, scdaemon of GnuPG should be fixed.
-- 

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

Re: How U2F works

[NIIBE Yutaka]

Werner Koch  wrote:
> Frankly, I don't really understand the use case for U2F?  Why not using
> plain user certificates which is supported by browser and servers for
> ages?  Is that because the web frameworks don't have good support for
> this?

Scalability, and some (or the) trust model which supports that.

The common practice for (X.509) user certificates is they are issued by
a specific network service provider, and it's useless for another
network service provider.  Users have to install each certificate issued
by each network service provider.  And this is not easy to manage such a
thing.

Ideally, we would have a good method to handle user certificates on
client machines, and have a practice using X.509 user certificates
by..., say, with "root CA"s.

OpenPGP community would say, it could be done reliably in a way of
distributed mechanism by OpenPGP certificates, right now.  Right,
technically, it's true.  The question is: How about in practice?

I think that user certificates (either, by X.509 or by OpenPGP) won't
work well than something like U2F.  I think that here, U2F offers a
"solution", in clever and practical way.


Well, let me explain from another angle.

I live in a small town.  In some cases, I buy things based on mutual
trust, directly or indirectly.  I use cash (or even credit card in some
specific cases), but shop owners are basically trust me.  We use money,
Japanese Yen.  But in a few cases, it is not needed in that form.  For
our own rice (most important food), I don't have to pay in the form of
money.  I live in such a town, intentionally.

I used to live in Tokyo for many years.  Shop onwers trust some credit
card service company and Japan Bank as an issuer of paper money.  They
don't necessarily care about me or anyone, who is buying their
products/services, as long as they can get paid.


Money scales.  Credit card scales.  That's because they don't require
direct mutual trust between a shop and a stranger who visits a shop.
All that shop owner needs is... to trust money.

That's my understanding.


I think that most important factor is not users, here (it is related,
though).

Using U2F might be easier for a network service provider, when other
network service providers have introduced such a feature in their
service already.  For an engineer or an administrator around web
services, it would be just "easy", like installing a few modules,
probably, while preparing X.509 user certificates requires complex and
difficult things.

>From an engineer who eats rice mainly. :-)
-- 

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

Re: How U2F works

[NIIBE Yutaka]

Thomas Jarosch  wrote:
> 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.

Thanks a lot for the information.


Well, I concluded that it is not worth (for me) to try to integrate U2F
feature into Gnuk.  If some free software friendly network service sites
ask me a possibility to use such a method to authenticate their users,
firstly I would propose better method which can respect users' computing
better instead, secondly I would propose developing as a separate
firmware implementation (possibly re-using Gnuk lower-level code) as
compromise.

The reason is:

The use cases are so different: The model who/how controls crypto
computation is so different.  (I mean, Gnuk vs. U2F)


I had been somewhat naive when I saw U2F specification at first.  I was
considering like:

  * While U2F uses X.509 certificate by the attestation key (in the
specification), it could be OpenPGP certificate.

  * Free Software implementation of U2F would be nice thing.

but, I leaned the reality.


In my opinion, the attestation key is a "key", literary and it is not
wise for network service providers not to check certificates (say, to
avoid MitM attack).

Here is my understanding.

I think that U2F offers network service providers a method of device
authentication and those who can trust the device vendor can use this
method to augment their user authentication.

Here is a picture, explaining the method.

[ Network service provider: A ]  --\ Trust
  ^|
  |  protocol for remote use of token  |
  vv
 [ User: U ]===having a token T1 by [ Device Vendor: D ]
  ^^
  |  protocol for remote use of token  |
  v|
[ Network service provider: B ]  --/ Trust

Note that U2F itself is not user authentication.  User authentication is
composed at network service provider side by traditional
username+passphrase AND the fact a user has the device (which can be
made sure by U2F device authentication).

In the design, the device is assumed to be shared among different
network service providers.

U2F is the protocol to offer remote crypto computation by network
service providers.

Users are... offering electric power to the device.  Users help network
service providers so that the U2F authentication can work effectively
(say, by providing their fingerprint).

In such a scheme, network service providers don't hesitate to send
nonfree JavaScript to their users, because the purpose is doing remote
use of the vendor's token (I don't say, it's user's token, even if
user is a "holder" is the token).
-- 

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

Re: How U2F works

[NIIBE Yutaka]

Hello,

Thanks a lot for your explanation.

Glenn Rempe  wrote:
> Well, the attestation key would be checked by the server side process
> right? And that is optional to check (but perhaps not optional to
> send). So you probably would need to ask those that are integrating
> U2F as a server auth method. Sending this seems to be a requirement
> based on the spec link you sent. Couldn't you get a vendor specific
> attestation key in any case for GnuK and use the same key across all
> devices?

I see.  I read the spec. again, IIUC, the generated keys in token will
be all signed by the attestation key.  I think that it is better for the
server side to check the signature so that it can detect possible MitM
attack.  I don't think it can be "optional" in real fields.

It would be possible to arrange a vendor attestation key of U2F for
Gnuk.  We did in a different level; We got USB vendor ID for our
devices.

However, with the OpenPGP background, I feel that it sounds wrong to
allow such an idea of a single secret shared among many devices.

If we do something like that (to assure authentication key generated
by a specific device), possible method for OpenPGP would be:

(1) Gnuk will have a feature of "device specific key".
(2) As initialization procedure, a distributor let a token generate
"device specific key" when they ship the device to a customer.  They
record the public key of each "device specific key" of customer.
(3) The distributor signs a public key of the "device specific key".
(4) When Gnuk generates authentication key, a signature by "device
specific key" is also generated.
(5) It is up to a user to use distributor's generated "device specific
key" and their signature.  A user can let a token generate new
"device specific key", and anyone can sign the public key of
"device specific key".
(6) Servers can check if an authentication key is signed by "device
specific key" which is signed by trustworthy distributor.

Well, probably, description above would be a different attestation key
for each device, in terms of U2F.

> I believe that at this point almost all use of U2F is through web
> browsers that support talking to the U2F hardware API's directly. Only
> Chrome has full support now, and Firefox and Opera are working on it
> but are not yet generally available. The web Javascript API's are just
> for requesting registration of a token or authentication. So you can't
> use U2F in a browser that does not have support for it no matter what
> JS you load in your page.

I see.  I was afraid that a user has to accept nonfree JavaScript
from server when she wants to use U2F authentication.

> What though is the benefit of using gnupg key as the crypto behind the
> client auth? Seems like you are more exposed by having a portable gpg
> key as opposed to a hardware embedded key. U2F makes it so easy to add
> a backup key, and most implementations let you drop and add keys
> pretty easily. Just trying to figure out if backing U2F with gpg, if
> that is what you are proposing, is worth it?

It is because of a simple reason.  I can't check the hardware and the
firmware in the current implementations of U2F devices.  I would like
to control my crypto computation in a way I can examine.
-- 

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

How U2F works

[NIIBE Yutaka]

Hello,

Let me ask a question about U2F.  Or, more generally, possibility to
enhance GnuPG for web authentication.

While I maintain scdaemon of GnuPG and develop Gnuk (an OpenPGPcard
implementation), I sometimes am asked about U2F support, these days.
(I think that this is due to Yubikey.)

IIUC, major use case of U2F is web authentication.  It seems for me
that it doesn't fit directly to OpenPGPcard use case.

Anyhow, it would be possible for Gnuk to add U2F support (somehow
limited, because of available resource on board).  Also, it would be
possible for scdaemon (or other application) to emulate U2F protocol
(just like Scute does emulate PKCS#11).

Well, I have two concerns for U2F.

(1) Atterstation key

In the document of U2F:

https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-overview-v1.1-id-20160915.html#verifying-that-a-u2f-device-is-genuine

It explains about Atterstation key.

If it were common for services to do this Atterstation key check, U2F
emulation or free U2F implementation will be no real use with no private
key of the vendor.   (It reminds me the old days when Apache couldn't
serve https because no certificate authority issued certificate for servers
with Apache.)  I wondor if Atterstation key check is common or not.


(2) JavaScript

It seems for me that there are special JavaScript(s) to offer access API
to U2F.  I don't quite understand how it works to the physical device.

I don't like nonfree JavaScript which may interfere user' control.

Is it easy for free script (as in freedom) to integrate a script for U2F
access?  Any such example scripts or any such services which do so?

Here, my concern is that if it is all for proprietary world, I am
reluctant to consider seriously about U2F.


And finally, if web authentication is important, I would like to use the
infrastructure of GnuPG to manage my own crypto computation and my own
private keys.  Currently, we can use GnuPG for SSH authentication by
its ssh-agent emulation.  I would like to extend this.

Any thoughts?  Thanks in advance.
-- 

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

Re: Problems with cert validation via CRL

[NIIBE Yutaka]

Hello, again,

David Gray  wrote:
> dave@dave-VirtualBox:~/.gnupg/crls.d$ dirmngr --debug-all --fetch-crl 
> http://crl.comodoca.com/COMODOSHA256ClientAuthenticationandSecureEmailCA.crl

Reading the code of dirmngr, I think that --fetch-crl (or dirmngr-client
--load-crl) doesn't work well for a CRL which is not signed by system CA
directly.  When dirmngr doesn't know the issuer, it inquires back to the
client, and it fails as:

> dirmngr[3184.0]: DBG: find_cert_bysubject: certificate not returned by caller 
> - doing lookup
> dirmngr[3184.0]: error fetching certificate by subject: Configuration error
> dirmngr[3184.0]: CRL issuer certificate 
> {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found
> dirmngr[3184.0]: crl_parse_insert failed: Missing certificate

When it is gpgsm which asks dirmngr to validate a certificate, I think
it works.

I think that you once successfully did that on this box:

> dave@dave-VirtualBox:~/.gnupg/crls.d$ gpgsm --debug-all --list-keys 
> --with-validation

And the CRL is cached.  Thus,

> gpgsm: DBG: chan_6 -> ISVALID 
> 685A02B9E2BD4B5EE1FA51739B8882AEA38FB3C8.3FAADAD7DD3F946B114321153B76F88C

This is gpgsm asking if your X.509 client certificate is valid or not.

> gpgsm: DBG: chan_6 <- INQUIRE ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868

Here, I think that the CRL for your X.509 client certificate is cached
and checked.  dirmngr does not ask about anything about your X.509
client certificate or its issuer.

dirmngr inquires back to gpgsm if the root issuer is trusted.

CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust 
AB,C=SE
fingerprint=02FAF3E291435468607857694DF5E45B68851868

then, gpgsm asks to gpg-agent.

> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_7 <- OK

It is trusted.  Then, gpgsm replies back to dirmngr.

> gpgsm: DBG: chan_6 -> D 1
> gpgsm: DBG: chan_6 -> END

It's trusted.

> gpgsm: DBG: chan_6 <- OK

Then, dirmngr answers OK for the validation of your X.509 client certificate.

> gpgsm: DBG: chan_6 -> ISVALID 
> 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21

This is gpgsm asking if the intermediate certificate of following is
valid or not:

CN=COMODO SHA-256 Client Authentication and Secure Email CA,O=COMODO CA 
Limited,
L=Salford, ST=Greater Manchester, C=GB
fingerprint=59B825FC08860B04B392CC25FEC48C760753B689

> gpgsm: DBG: chan_6 <- INQUIRE ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_7 <- OK
> gpgsm: DBG: chan_6 -> D 1
> gpgsm: DBG: chan_6 -> END
> gpgsm: DBG: chan_6 <- OK

Similar interactions between gpg-agent<->gpgsm<->dirmngr.

> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_7 <- OK

I don't know the exact reason, but gpgsm again asks gpg-agent.

And gpgsm shows your X.509 client certificate:

>ID: 0x2F5900E9
>   S/N: 3FAADAD7DD3F946B114321153B76F88C
>Issuer: /CN=COMODO SHA-256 Client Authentication and Secure Email 
> CA/O=COMODO CA Limited/L=Salford/ST=Greater Manchester/C=GB
>   Subject: /EMail=u...@domain.com
>   aka: u...@domain.com
>  validity: 2017-01-02 00:00:00 through 2018-01-02 23:59:59
>  key type: 2048 bit RSA
> key usage: digitalSignature keyEncipherment
> ext key usage: emailProtection (suggested), 1.3.6.1.4.1.6449.1.3.5.2 
> (suggested)
>  policies: 1.3.6.1.4.1.6449.1.2.1.1.1:N:
>   fingerprint: 4A:53:A9:E6:51:32:23:DF:B4:7D:B8:A3:19:F1:3E:A3:2F:59:00:E9
>   [Note: non-critical certificate policy not allowed]
>   [Note: non-critical certificate policy not allowed]
>   [validation model used: shell]
>   [certificate is good]

On the other hand, on your Windows...

> C:\Users\dave\Downloads>gpgsm --list-keys --with-validation --debug-all
[...]
> gpgsm: DBG: chan_0x01c0 -> ISVALID 
> 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21
> gpgsm: DBG: chan_0x01c0 <- INQUIRE ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868
[...]
> gpgsm: DBG: chan_0x01e8 -> ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_0x01e8 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_0x01e8 <- OK
> gpgsm: DBG: chan_0x01c0 -> D 1
> gpgsm: DBG: chan_0x01c0 -> END
> gpgsm: DBG: chan_0x01c0 <- OK
> gpgsm: DBG: chan_0x01e8 -> ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_0x01e8 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_0x01e8 <- OK
[...]
> gpgsm: DBG: chan_0x01e8 -> ISTRUSTED 
> 02FAF3E291435468607857694DF5E45B68851868
> gpgsm: DBG: chan_0x01e8 <- S TRUSTLISTFLAG relax
> gpgsm: DBG: chan_0x01e8 <- OK
[...]
> gpgsm: DBG: chan_0x01c0 -> ISVALID 
> 

Re: Problems with cert validation via CRL

[NIIBE Yutaka]

Hello,

David Gray  wrote:
> At the same time, I'm curious as to why the Ubuntu installation is
> validating the certificate as 'good' while the Windows installation is not -
> is this just because the Ubuntu installation was able to successfully
> validate the certificate in the past (presumably when a previous and
> non-problematic CRL was published)?  If the CA publishes an updated CRL that
> doesn't have issues, will my Windows installation be able to validate the
> certificate at that point?

Please note that my knowledge of gpgsm and X.509 is pretty much limited.

Do you have .gnupg/trustlist.txt on Ubuntu machine?  It can be created
when you answer dialog of gpgsm by pinentry interaction.
-- 

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

Re: Aw: Re: Re: SmartCard v2.1 : factory reset fails

[NIIBE Yutaka]

Hello,

Thanks a lot for your report in detail, in the style which I can replicate.

I'm afraid you are facing same issue what I encountered in 2011.

CHANGE REFERENCE DATA (OpenPGP card specification 2.0):
https://www.gniibe.org/log/bugreport/gnupg/openpgp-card-spec-2.0-chenge-reference-data.html

IIUC, this protocol is due to smartcard practice and standard.  I had
asked Achim (the author of OpenPGPcard specification) if this could be
changed.  No positive answer, but I think that the problem is clear
enough.

Fib Moro  wrote:
> It then asks me to "Please enter the Admin PIN".
> Now, in the believe that *123456789* was the correct default Admin PIN value,
> I would enter this *wrong* value.
> I am then prompted to enter "New Admin PIN" value and confirm that. 
> Let's say I use the value *smartcardrocks*.
> My change is then confirmed with;
>
>>
> PIN changed.
> <

Yes.  Now, New Admin PIN is *9smartcardrocks*.

> I would now be in the believe that *smartcardrocks* is the new correct Admin
> PIN.

I understand your expectation.  It was exactly same of mine.  But, new
Admin PIN is *9smartcardrocks*, which is totally confusing.

> However, any subsequent command that would require the Admin PIN would fail
> (e.g. moving keys to card, setting reset code, changing admin pin).

Naturally.

> For example, when I try to set a new reset code I am asked to enter the Admin
> PIN. 
> I enter *smartcardrocks* I get "Error setting the Reset Code: Bad PIN".
> I enter *12345678* I also get "Error setting the Reset Code: Bad PIN".
>
> I seems the Admin PIN is then broken and set to an "unknown" value.
>
> Can you replicate the above described behavior?

Yes.  The bug (from my point of view) is still there.


No, I don't have an idea to keep this problem forever.  I am currently
considering KDF generation scheme by host side.  I'm going to send my
proposal to Achim.  In this new scheme, the length of string for PIN is
fixed.  And then, this problem will be no longer valid.  That's my
development now.
-- 

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

Re: Aw: Re: SmartCard v2.1 : factory reset fails

[NIIBE Yutaka]

Hello,

Fib Moro  wrote:
> I start gpg in "--edit-key" mode.
> Then I select a subkey I want to move to the card by issuing command "key 1".
> After the "keytocard" command it asks me where to store the key for which I 
> choose option 1 signature key.
> It then prompts me for the privat key passphrase which I enter successfully.
> Now it asks me for AdminPIN. Again with default value "123456789" I get the 
> message "gpg: KEYTOCARD failed: Bad secret key"
> Also the same issue occurs if I set the AdminPIN manually beforehand.
> _
>
> gpg> key 1
> ...
> gpg> keytocard
> Please select where to store the key:
>(1) Signature key
>(3) Authentication key
> Your selection? 1
> gpg: KEYTOCARD failed: Bad secret key
> __

Let us show more info about your key.  I'm afraid your key size
is not the one OpenPGP card supports.  I tested RSA-2048 with
OpenPGP card version 2.1, it works fine for me.
-- 

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

Re: Aw: Re: SmartCard v2.1 : factory reset fails

[NIIBE Yutaka]

Hello, again,

I found a bug in GnuPG 2.1.18 for factory-reset command handling (it's
not in 2.1.17 or older), I fixed it today.

Then, I tested my OpenPGP card 2.1.

Let us fix a thing one by one.  First, the Reset Code handling.

Fib Moro  wrote:
> It doesn't even get to the point where it prompts me for the Reset Code:
>
> Here is what I do:
>
> When try to set the reset code via "passwd => 4" it prompts me for the 
> AdminPIN.
> I enter the default AdminPIN value of "123456789" and get the message "Error 
> setting the Reset Code: Bad PIN"
> I'm 100% sure I entered AdminPIN correctly.

For my OpenPGP card 2.1, the Admin PIN is "12345678" (no 9).
I can successfuly set the Reset Code.

I confirmed that with wrong Admin PIN, I got the message "Error setting
the Reset Code: Bad PIN".

Please test with 12345678.
-- 

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

Re: SmartCard v2.1 : factory reset fails

[NIIBE Yutaka]

Hello,

Since I got 2.1 card last week, I will test with it.  For time being,
I say something what I know of.

Fib Moro  wrote:
> I can then successfully change the PIN as well as AdminPIN.
>
> However, when I try to write a key to the card (gpg --edit-key xxx; 
> keytocard) I
> get a message "Error setting the Reset Code: Bad PIN".

Umm... This error message can be only happened at setting the Reset
Code.  Strange.

> The same issue occurs when try set a Reset Code on the card (gpg --card-edit;
> admin; passwd => set the Reset Code).

The length of the Reset Code should be more than or equals to 8.  If it
is shorter, it fails.  What is your case?
-- 

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

Re: Non-deterministic behavior using GnuPG and a smart-card

[NIIBE Yutaka]

Hello,

"Dr. Basil Becker"  writes:
> Authentication and signatures work like a charme. I'm only having
> problems concerning the decryption of mails I received.
[...]
> Some messages, however, fail to decrypt:
> bb@melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message-fail.txt
> gpg: armor: BEGIN PGP MESSAGE
> gpg: armor header: Version: GnuPG v2
> # off=0 ctb=85 tag=1 hlen=3 plen=400
> :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189
>   data: [3104 bits]
> gpg: public key is 0xDBC1D85BA9D1D189
> gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key
> 0x8501968486DF0281
> # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
> :encrypted data packet:
>   length: unknown
>   mdc_method: 2
> gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key
> 0x8501968486DF0281
> gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, created
> 2017-01-10
>   "Dr. Basil Becker "
> gpg: public key decryption failed: Hardware problem
> gpg: decryption failed: No secret key
[...]
> The only difference I see, is that the pubkey data is 3103 bits vs 3104
> bits. Unfortunately, I have no idea, whether this is a meaningful
> difference and if this

I think that it is deterministic; The cause is that the RSA keysize is
not the one in the set of: 1024, 1536, 2048, 3072, 4096.  When data to
be decrypted is padded, scdaemon can't decrypt, I suppose.

I am not sure the exact reason why scdaemon only supports limited set of
keysize for encryption.   But we have this handling of padding in the
current code:


https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=scd/app-openpgp.c;h=71c9e1b83003af07b0984688ba1ec5e9013b877c;hb=refs/heads/master#l4334

   /* We might encounter a couple of leading zeroes in the
  cryptogram.  Due to internal use of MPIs these leading zeroes
  are stripped.  However the OpenPGP card expects exactly 128
  bytes for the cryptogram (for a 1k key).  Thus we need to fix
  it up.  We do this for up to 16 leading zero bytes; a
  cryptogram with more than this is with a very high
  probability anyway broken.  If a signed conversion was used
  we may also encounter one leading zero followed by the correct
  length.  We fix that as well.  */
   if (indatalen >= (128-16) && indatalen < 128)  /* 1024 bit key.  */
 fixuplen = 128 - indatalen;
   else if (indatalen >= (192-16) && indatalen < 192) /* 1536 bit key.  */
 fixuplen = 192 - indatalen;
   else if (indatalen >= (256-16) && indatalen < 256) /* 2048 bit key.  */
 fixuplen = 256 - indatalen;
   else if (indatalen >= (384-16) && indatalen < 384) /* 3072 bit key.  */
 fixuplen = 384 - indatalen;
   else if (indatalen >= (512-16) && indatalen < 512) /* 4096 bit key.  */
 fixuplen = 512 - indatalen;
   else if (!*(const char *)indata && (indatalen == 129
   || indatalen == 193
   || indatalen == 257
   || indatalen == 385
   || indatalen == 513))
 fixuplen = -1;
   else
 fixuplen = 0;

Perhaps, it was due to support all existing OpenPGP card
implementations, I mean, somehow historical, and it was easier to list
up specific keysizes.

This should be fixed.
-- 

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

Re: Smartcard working completely with GPG2 and incompletely with GPG1.4

[NIIBE Yutaka]

Hello,

chris.p...@gmx.de wrote:
> With GnuPG 2, signing, encrypting and decrypting a file works without
> any problems. With 1.4, I can encrypt and sign a file, but I can't
> decrypt it. It's failing with the message:
[...]
>
> gpg: public key decryption failed: general error
> gpg: decryption failed: secret key not available
[...]
> sec#  rsa4096/E728903D  created: 2014-04-12  expires: never 
> ssb>  rsa4096/3A07266F  created: 2014-04-12  expires: never 
> card-no: 0005 5031
> ssb>  rsa4096/43F27C98  created: 2017-01-24  expires: never 
> card-no: 0005 5031

I located the cause of this issue.  It is not the issue of scdaemon
incompatibility of GnuPG 2.1, which I addressed yesterday.

With GnuPG 1.4 for smartcard can't work well for RSA 4096-bit keys.  (I
think that it can also occur with the combination of GnuPG 1.4 and GnuPG
2.0.)

In the code of g10/cardglue.c, the buffer length is 1002-byte by the
definition of ASSUAN_LINELENGTH [0], but this length is not enough for
the checking at [1].  (To represent encrypted value of 4096-bit itself,
it requires 1024-byte by hex string.)

[0] 
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=include/assuan.h;h=1170f959df353f33373565c729981891dcd0100c;hb=refs/heads/STABLE-BRANCH-1-4#l91
[1] 
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/cardglue.c;h=809b315e564831aac8727d3c905e53016749f76e;hb=refs/heads/STABLE-BRANCH-1-4#l1395
-- 

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

Re: Smartcard working completely with GPG2 and incompletely with GPG1.4

[NIIBE Yutaka]

Hello,

Thank you for your report in detail.

chris.p...@gmx.de wrote:
> The commands gpg --card-status and gpg2 --card-status seem to display
> mainly the same things, the only strange line is "Key Attributes" at
> GPG 1.4:

gpg 1.4 can use gpg-agent by the option use-agent.  I think that you
enable this option in .gnupg/gpg.conf.

Yes, gpg 1.4 can be used with the gpg-agent of GnuPG 2.0, this usage is
supported well.

scdaemon in GnuPG 2.1 has been enhanced to support ECC, and the particular
protocol of KEY-ATTR has been changed.  This is the cause of the issue.

While I'm sure scdaemon 2.1 doesn't work well with gpg 1.4 by protocol
incompatibility, I'm not sure how gpg 1.4 can be used with the gpg-agent
of 2.1, in general.  In my opinion, I don't think this usage is
well supported in the current development of GnuPG.

Let us see.

Are there any reason why the combination of gpg 1.4 and gpg-agent 2.1 is
useful?
-- 

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

Re: spr332 vs spr532

[NIIBE Yutaka]

Hello,

Elizabeth Ferdman  wrote:
> I'm interning for the PGP Clean Room and am trying to get an OpenPGP
> Card reader. Kernelconcepts is offering a SPR332 which is the successor
> to the 532. According to this page, though,
>
> https://wiki.gnupg.org/CardReader/PinpadInput

I wrote this page, when I added the support of pinpad input to scdaemon.

> the 532 seems to be recommended but the 332 is not. I'm wondering if
> there's a specific reason why it was left out and if I should go for the
> 532 instead.

Since Werner has SCM SPR 532, it was tested and listed.  Please note
that the list is not for recommendation (as of today); Vasco DigiPASS
920 (which I have) worked, but it only supports key length <= 1024-bit
of RSA.  Gnuk Token is listed, but it has no hardware pinpad, in fact.
Some other readers were listed because they requires special handling to
work around issues of their firmware.

I think that: if you need a tested reader, go for the 532.  If you have
time and energy, go for the 332 and please let us know if it works or
not.  I guess that it is likely work well with PC/SC and we need a bit
of change for the internal CCID driver of GnuPG.  If it will work, I'll
put it on the list.  That will be a great contribution to GnuPG
community.
-- 

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

Re: Feature request: treat missing smartcard reader as missing smartcard

[NIIBE Yutaka]

Peter Lebbing  wrote:
> For instance, if I open an encrypted mail in Thunderbird/Enigmail, I see
> the following:
>
> - Card reader is plugged in but no card or different card present in reader:
>
> I am prompted to insert the correct OpenPGP card. Once I do this and
> okay the prompt, decryption is succesful.
>
> - Card reader not plugged in:
>
> Empty message window with Enigmail error on the lines of "Decryption
> failed. No secret key available."

Good point.

In the development branch, I'm currently working for multiple card/token
support (currently only with internal CCID driver).  And I also happened
to notice this difference this month.

Now in the repo (master), signing and decryption work well with multiple
card/token and a user is prompted when there is no relevant card/token.

This is just a lucky coincidence, but I'm glad to see the development of
GnuPG goes well.

Thank you for your support of GnuPG.  Your support encourages me
(hopefully, all of us) fixing bugs and adding feature(s).
-- 

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

Re: [Announce] Libgcrypt 1.7.5: secmem trouble

[NIIBE Yutaka]

Luis Ressel  wrote:
> since I've upgraded to libgcrypt 1.7.5, gpg emits the warning 'Warning:
> using insecure memory!' (and hence refuses to run, since my config file
> includes 'require-secmem').
>
> Any hints for debugging this issue would the greatly appreciated.

I think that you need to debug libgcrypt to locate the bug.  If you are
familiar with GDB, run gpg under GDB with a break point at main, and
then a break point at lock_pool_pages.

Well, please show us the information in which architecuture/OS you runs
GnuPG.  Are you using GnuPG 2.1.x or another version?

I'm afraid you are using libgcrypt 1.7.4.  In version 1.7.4, there was
a bug in configure script, which might cause such a trouble.
-- 

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

Re: Smartcards and tokens

[NIIBE Yutaka]

sivmu  writes:
> it seems using those specific devices actually decreases
> security, assuming it is easy to manipulate specialised vendors of
> security hardware compared to manipulating electronic hardware in general.

Exactly, that's my point.  This is the reason why my approach of Gnuk
and NeuG tries to avoid specialized things.  Even, I avoid using crypto
accelerator, which (many of) experts say mandatory.

I think that an approach using commodity hardware makes sense.  My
theory is that if it's simpler and cheap enough, difficulty putting
backdoor would increase.  I don't know if this is true, but I considered
opposite must be likely; With enough space of silicon and enough
complexly in design, attackers can do something more.

> With nitrokey,  both the hardware design and the software is open source
> and both have been audited.

Is it audited?  I didn't know that.  For me, audit by an expert (or two)
is not enough.  It should be possible by anyone, or at least, by any
user who purchases it.  It's sad for me that Nitrokey is not easy to
open physically.  I mean, opening the device to examine the board.

> Bu I don't think that will keep some people from intercepting
> deliveries of such devices or mess with the production.

I don't know about the former, it depends on country.  For the latter,
it is real concern for me now.

I make the hardware design as simple as possible so that inspection by
human eye can be effective against replacing/adding chip.

Difficult part (for me) is to assure initial firmware flashing in
a factory.

In (most of) factory environment, proprietary operating system
dominates.  I'm not sure if this is the weakest link, but this could be
weaker point.  When an attacker replaces the firmware to be written,
it affects all devices to be shipped.

Perhaps, it would be good if an MCU has a feature of reporting hash of
its content of flash memory (even if flash is protected and it is not
possible to read out its content).  Then, an end user could examine
the hash code.

I think that the better current practice is: purchase commodity hardware
and flash at the user side.
-- 

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

Re: Changing comment in userID

[NIIBE Yutaka]

On 12/15/2016 08:03 PM, unknown wrote:
> i've made a keypair with a comment in the userID. Is it possible to
> delete this part of the key or do I have completely delete the key and
> make a new one?
> I also uploaded it to the sks keyserver. What effect will it have on the
> keyserver?

Please note that modifying user ID (even if it's a comment in user ID)
makes different user ID.  And when people certify your key, signature
is about user ID.

You don't need to create new key.  You can add new user ID to existing
key by: gpg --edit-key YOUR-KEY and "adduid" sub command.  You can
also revoke an old user ID by "revuid" sub command, if you want.
Then, you can upload updated key to keyserver.  There is also "deluid"
sub command but it only affects key on your PC, since keyservers never
support deletion of record.

You need to get your user ID certified again.

Thus, it would be simpler starting with new key with new user ID.
-- 

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

Re: Smartcards and tokens

[NIIBE Yutaka]

sivmu  wrote:
> One question remaining is what is the difference between the openpgp
> smartcard and the USB based tokens.

I think that the OpenPGP card (the physical smartcard) is included in
Nitrokey Pro USB Token.  So, it's exactly same from the view point of
smartcard.

When you want to use a smartcard, you need a card reader to access the
card.  And the card reader you use would bring another attack vectors.
In this point, Nitrokey Pro USB Token is the best approach, I suppose.

IIUC, Yubikey products are JavaCard implementations and somehow emulate
OpenPGP card protocol by "app", and they work as CCID card reader +
OpenPGP card.

In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
is implemented by Gnuk, the software.

> Also how much would you trust those vendors and can the use of such
> tokens actually decrease security?

This is the point.

The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
should consider possibility of backdoor of OpenPGP card.  Well, I don't
know about Yubikey.

When it is replaced to be malicious one to enable an access by others
(to your private keys), or it already has a backdoor in the first place,
it kills the purpose of USB security token.

Here, the question is: how can we build up such a "trust"?

It seems for me that there are two different approaches; (1) physical
difficulty (for example, plastic molding for "protection"), (2)
reproducibility and transparency/openness.  Note that some method of
former makes latter difficult.


For myself, I take (2), and I did my best to make my product as
reproducible.  (Since I don't manufacture semiconductor things,
reproducibility is not 100%, and this part of manufacturing and
technology is not open at all.)  And I intentionally deliver my product
in a style of "transparent" or "open".

Distribution channel is also difficult.  I do in person, and I ask FSF
for my TRNG.  Are there any good method?

Obvious drawback of the apporoach (2) is that people with enough
concern/attention have tendency to do it under their control.
Reasonable.  Since it's reproducible (somehow), it's possible, by
definition.  And then, I can't sell many.
-- 

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

TRNG (was: Specifying entropy source)

[NIIBE Yutaka]

Hello,

I work for my own TRNG implementation.  I realized that the point is:

We should collectively control things so that none can control a
sequence of random bytes.  --- (*)

Second "control" in (*) includes guessing, predicting, or knowing, not
only manipulating directly/indirectly.

Things include software, hardware, and the process of making software,
hardware, etc.

I observed that people have tendency to prefer an exotic noise source,
but it is not that important matter for me.  Rather, if a TRNG device
depends on some exotic technology, I count it as a weakness because it
makes it difficult to be reproducible and transparent.


On 11/17/2016 03:12 AM, NdK wrote:
> Il 16/11/2016 15:55, Juergen Christoffel ha scritto:
> 
>> Then there are http://www.bitbabbler.org and
>> http://ubld.it/products/truerng-hardware-random-number-generator/ as
>> hardware random number generators. Both are worth their money IMO.
> Why not GnuK, that incorporates a TRNG too?

In general, OpenPGP card implementations have a random number
generator.  I mean, it's not only the feature of Gnuk.  It is
accessible by gpg-connect-agent.  Here is an example.


$ gpg-connect-agent --hex "SCD RANDOM 32" /bye
D[]  F8 04 49 F3 BA D9 85 44  47 54 F5 89 B5 49 EA E7   ..IDGT...I..
D[0010]  46 20 1E 09 15 AC 38 7E  9E 50 0E D7 28 19 64 15   F 8~.P..(.d.
OK


I think that this is useful when a person installs an OS into a new
machine, or when people use machines for clean boot with fixed media
like CD.  Feeding those random bytes to /dev/random can make the
barrier higher (against guessing, predicting, or knowing).

> There's even a version that only includes the TRNG, and it's completely
> open.

Thank you, Diego, for the introduction.  The device is available at:


https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator

I think that "completely open" is not achieved, yet.

Although I tried my best making it free, reproducible and transparent
(I use the tube on purpose to demonstrate its transparency), it's not
perfect; While firmware is Free Software assuming Free Software
development environment only, and the PCB design is free and the
design assumes Free Software development environment only, it still
depends on the MCU chip (manufacturer and its distribution channel)
and the manufacturer of PCB assembly.

Suppose that there were a proprietary TRNG device by some alien (I
mean, an external entity).  As a gift, the alien deliberately left the
TRNG which generation of randomness cannot be controlled by anyone in
this planet.  In this case, this TRNG is useful for us, perhaps.

Given no such a gift on earth, I believe that we need free,
reproducible and transparent one even not perfect.

Well, I think that the TRNG device is very good for a gift to hackers.
:-)

Enjoy,
-- 



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

Re: smartcard reader

[NIIBE Yutaka]

On 10/19/2016 12:40 AM, Stephan Beck wrote:
>> FSIJ Gnuk Token
>> USB ID: 234b:

Ah...  This is not a card reader.  It is the project of Free Software
Initiative of Japan (FSIJ) since 2010.  FSIJ acquired USB vendor ID,
specifically for this project.  Please visit:

https://www.fsij.org/category/gnuk.html

Card reader products are more complex than the hardware requirement of
Gnuk.  If you like KISS philosophy, you might prefer Gnuk Token.

> you can order gnuk token at/from
> https://www.seeedstudio.com/FST-01-without-Enclosure-p-1276.html

It is sold as an evaluation board.  It happened to have Gnuk 1.0.1
installed.   It is an implementation of reader+card.

> https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator.

This has TRNG implementation (NeuG 1.0.4), instead.  The source of
noise is not that exotic, though.  You can replace the firmware to
Gnuk by yourself.  The upgrade process doesn't require JTAG/SWD
debugger, but having JTAG/SWD debugger is highly recommended to
control your computing (or just in case when failure of upgrade).

Hardware is same (sans cover).  The support page is here:

https://www.gniibe.org/category/fst-01.html

I tried to sell the hardware widely as possible with help by Seeed and
FSF, but my capability is limited.  Selling hardware product means
we need to follow regulations.  That's difficult for me.


For Europe, I heard that Nitrokey Start runs Gnuk 1.0.4.  Availability
of this product is better, I suppose.

I think that Nitrokey Start and Nitrokey Pro is based on the hardware
design of mine (although I was not involved).  I got a report to Gnuk
Mailing list about firmware upgrade of Gnuk doesn't work well on
Nitrokey Start.  If someone can investigate the cause and possibly fix
an issue, it will be great.


I gave a talk of Gnuk at https://openpgp-conf.org/program.html
There is a link to my slides.
-- 

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

Re: reviewing wiki / shortlist PIN-pad readers

[NIIBE Yutaka]

Sorry, I didn't have time to reply your call the other day.

I think that Gemalto Shelltoken Card Reader, which is available
at http://shop.kernelconcepts.de/ is good one.

Please note that OpenPGP card requires specific card readers.  Its
users usually use RSA-2048, RSA-3072, or RSA-4096.  For those key
sizes, the communication is somewhat difficult for old standard of ISO
7816.  (For RSA-1024, most smart card readers work well.)

I recommend TPDU readers, because readers which support extended APDU
level communication tend to have issues for larger size communication.

On 10/18/2016 04:51 PM, Daniel Pocock wrote:
> I was looking at this page:
> 
> https://wiki.gnupg.org/CardReader/PinpadInput
> 
> Are any of these more outstanding than the others, or it doesn't matter
> which one somebody chooses?
> 
> Could anybody comment on which of those are easily available in small
> quantities for developers, or suppliers who are cost effective for small
> quantities?

I implemented the pinpad input support in scdaemon.  While I know some
claims that it is good feature, I, for myself, don't think it's worth
to have.

I don't think the attack to USB communication could be mitigated by
pinpad card reader.  If such an attack is possible, a user already
would be defeated.

It is common for such card readers to have only numeric pads.  That
limits the entropy of passphrase, considerably.  And, as far as I
know, I don't know any implementation of card readers in the market,
which firmware is Free Software.  With user interface like pinpad
input, it is more difficult for me to trust an implementation of such
a card reader.
-- 

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

Re: using with su/sudo

[NIIBE Yutaka]

On 10/13/2016 12:36 AM, John Lane wrote:
> I just wanted to bring this to your attention because I think it is related.

Thank you.  Actually, I have a problem like that, everyday (literally).

> I tried from a sudo with the tty ownership corrected but it didn't work.
> 
> So I ran an agent with some logging and saw this:
> 
> 
> DBG: error calling pinentry: Inappropriate ioctl for device 

Yes, this is the same error for me, too.

In my case, I do:

$ gpg-connect-agent updatestartuptty /bye

to fix the situation.

My case is that, I configure systemd to start up gpg-agent.  In this
case, gpg frontend works well with its session environment, but ssh
doesn't work.

In this configuration, gpg-agent starts with no env defined, like:

$ gpg-connect-agent "getinfo std_startup_env" /bye
OK
$

Then, the command "updatestartuptty" can fix the situation.

I think that gpg-agent is unkind enough (for error message, at least),
it could/should know pinentry doesn't work well with not proper TTY
ownership, no GPG_TTY.

In the case of su/sudo, I would consider automatic fallback to
loopback mode, or argue about file discriptor passing of UNIX domain
socket.  I have no idea how gpg-agent with null std_startup_env can do
for SSH...
-- 

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

Re: Smartcard reader Precise Biometrics 200 MC

[NIIBE Yutaka]

On 09/20/2016 04:13 PM, Jan Prunk wrote:
> I am wondering if the smartcard reader "Precise Biometrics 200 MC" [1]
> is among the supported readers to be used with GnuPG ? Is there a
> guideline to follow for setting it up ?

For the reader, I found this discussion in 2010:


http://musclecard.996296.n3.nabble.com/pcsc-lite-ccid-Precise-MC-200-problems-with-T-1-td4543.html

It seemed that it became "unsupported" by PC/SC lite.  So, it is
highly likely not working with GnuPG.


Well, I maintain this list:

https://wiki.debian.org/GnuPG/CCID_Driver

Please install scdaemon.  Your operating system may require some
other permission settings.  For example, Debian GNU/Linux has:

/lib/udev/rules.d/60-scdaemon.rules

If your reader is not listed in such a file, you need your own
settings.
-- 

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

Re: :-(( Re: smart card no longer works

[NIIBE Yutaka]

On 09/09/2016 11:52 PM, Philip Jackson wrote:
>> Packaging in Debian had been changed.  Now scdaemon is in a package of
>> "scdaemon" (used to be in "gnupg2" package).
>>
> 
> I have now installed the missing scdaemon deb package and that makes a
> big improvement as far as gpg2 is concerned.
> 
> Both gpg and gpg2 --card-status return essentially the same data which
> looks good.

Good.

> gpg: public key decryption failed: Operation cancelled
> gpg: decryption failed: No secret key
> 
> Since in my first attempts, the pinentry window which came up was
> anonymous, I supposed there might be a problem with the choice of
> pinentry.  So I put "pinentry-program /usr/bin/pinentry-gtk-2" into the
> gpg-agent.conf file.
> 
> The pinentry dialogue is no longer anonymous, it does say
> pinentry-gtk-2, but the result is the same, no decrypt.

I don't have any experience with this error behavior.  Please describe
the situation and the interaction; Did you input passphrase and push
[OK] button, and then gpg failed?

Please try again with pinentry-curses and/or pinentry-tty.  Does it work?
-- 

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

Re: smart card no longer works

[NIIBE Yutaka]

On 09/09/2016 05:21 AM, Robert J. Hansen wrote:
>> The last I checked, Ubuntu's stock install did not include smartcard
> drivers.
>> The good news is these can be easily installed via apt-get.  The bad news
> is I
>> don't remember what the package name is.  :(
> 
> A little searching suggests that "sudo apt-get install gnupg-pkcs11-scd" is
> the magic you need.  Hope this helps!

Please use the standard scdaemon from GnuPG.

apt-get install scdaemon

PC/SC service is optional.  In-stock CCID driver of GnuPG just works
well in most cases.  Only when it doesn't work, please try
to install pcscd and libpcsclite1.

For PKCS#11 things, we (GnuPG team) do totally in different way by
Scute, when people want to use the PKCS#11 API.  I don't think
gnupg-pkcs11-scd works, these days.

Packaging in Debian had been changed.  Now scdaemon is in a package of
"scdaemon" (used to be in "gnupg2" package).
-- 

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