My interpretation of the specification is different.
By requiring the condition of setting KDF-DO (it is only valid to setup KDF-DO when PINs are factory setting), Gnuk works well with current "kdf-setup".
If the procedure of setting KDF-DO includes multiple steps with KDF-DO update and PIN update, there is a risk of power down which results unusable card.

Yes, I meant the document. Please note that I am also one of users of the specification (for GnuPG, and for Gnuk Token). I am not defending, but try to explain the current situation.

I was referring to this document:

You describe it as 'manual'. AFAIK, it's the specification for the functionality.
I have an experience implementing the functionality, following the specification.
And my own implementation does always return 512 bytes for RSA-4096. So, I could support your opinion.

I realized that KDF support may be incompatible to Gnuk's feature of "admin-less" mode.
I'm going to implement compatible KDF support to Gnuk; That is, KDF data which only has a single salt.
In this case, all KDF calculation (user, reset-code, and admin) is done with the single salt.
With single salt, admin-less mode can work with no problem.

Furthermore, I changed to have an explicit command: key-attr

I changed the interaction so that user can specify RSA or ECC, then when it's for ECC, specifying curve.

2.2.6 will have this feature in --card-edit, as kdf-setup. Please test.

For factory-reset, rG2c85e202bc30: scd: Better user interaction for factory-reset. fixed the issue.

Hallo Werner,

I've contacted Yubico to review this ticket.

Hi, that works as advertised. If this is the best solution yubikey permits us I am ok with it.

I put an entry: https://wiki.gnupg.org/SmartCard#Known_problem_of_Yubikey

After resume, because resume is not detected, some user interaction is required to cause an error.
gpg --card-status (which will only show partial information) is enough. Or, ssh failure. After failure, scdaemon reconnects the token.
Then, you can use it again without plug-off/plug-in.

Thanks a lot for pointers and suggestion.
Well, the problem of Yubikey itself cannot be solved by others, we can put some workaround for the error recovery.
So, this is another try of mine to improve error recovery.

• There was same problem in yubico-piv-tool and it was solved by detecting error state (0x80100068) and reconnecting to the smart card if necessary [1]
• There is also a thread in OpenSC discussing this issue [2] and relevant PRs [3]
• I also found a project that claims to fix SCARD_W_RESET_CARD by disabling exclusive access to the card before asking for PIN (and then they enable exclusive access again) [4]

New cards will come with a fix. I am not sure whether a production run has yet been done, though.

Part of the problem is Yubikey side, I suppose. (Because my implementation of Gnuk Token has no problem for suspend/resume if it's in-use.)

Again, thanks a lot for your testing. The log said: The code I added cannot detect the event of suspend/resume.
It seems that there is no way to recover from suspend/resume for Yubikey.

Hello again,

Yeah, this is better, we got apdu_get_status => sw=0x0 status=7 and I can auth with this version as usual. After sleep-wake cycle it would however fail with pcsc_transmit failed: reset card (0x80100068). Logs attached.

Thanks a lot for your testing. So, apparently, the PC/SC behavior is different between GNU/Linux and Windows.
Thus, I pushed another change: rG1e27c0e04cd3: scd: More fix with PC/SC for Windows.. Please test this. (Both of previous version and this version work well on GNU/Linux for operations not including suspend/resume with Yubikey and Gnuk Token, while my Yubikey with PC/SC doesn't work well for suspend/resume.)

Thanks, this version of scdaemon executes.

Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).

I realized that: once KDF-DO is written to smartcard/token, factory-reset command won't work because it assumes standard PIN format than hashed.

Sorry again. My script was still wrong (didn't work).

It doesn't work because I did mistake for the salt of reset code, it should be 8-byte instead of 4-byte.
Here is a fixed version, which I tested with Gnuk 1.2.8:

@gniibe it seems the patched scdaemon.exe is 64 bit executable and it requires libassuan6-0.dll. However I got installed 32 bit version of gpg that only has incompatible libassuan-0.dll. I scanned whole computer for the missing lib, skimmed your ftp for 64 bit binaries and looked into gpg4win installer to find it, but no luck. There is also libassuan github repo, but I would like to avoid building the dll myself; there would probably be more than one dll to build anyway.

If possible, please try with this (patched version of scdaemon):

Something like this script should be implemented by gpg frontend:

I realized that suspend/resume is not supported yet on GNU/Linux: https://anonscm.debian.org/cgit/pcsclite/PCSC.git/tree/TODO#n7
So, I can't test myself.
Here is an attempt to improve:

It looks like SCardGetStatusChange doesn't return failure after wake up.
Here, what we need is catching the event of wake up, which requires reset of the card.
I think that we can check by the dwEventState field.
I'll try on GNU/Linux environment, then ask you to try.

@werner there had to be some mix up, as the log snippet is not mine.

This seems to be the relevant part of the log:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed
2017-11-18 07:45:15 scdaemon[8918] ccid open error: skip
2017-11-18 07:45:15 scdaemon[8918] pcsc_establish_context failed: no service (0x8010001d)
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: interrupt callback 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card removed

This would be a good solution.

This has also the advantage that we could list the possible curves and let the user select them.

So should we revert this patch and replace it by an explicit command to switch the card to ECC?

It's in GnuPG 2.2.4, now.

It's a bug in the OpenPGP card implementation.
I put an entry in Wiki: https://wiki.gnupg.org/SmartCard#Known_Bug.28s.29_of_OpenPGPcard

My apologies , after the system upgrade, multiple things around gnupg broke and I got distracted and forgot to check the fetched public key, which somehow didn't contain subkey data.
This particular issue has been resolved by updating upstream public key.
Thank you for your assistance.

I use Debian stretch. It works for me with GnuPG 2.2.4.
The stub is created at the time when --card-edit accesses the card.
When I type RET after fetch command, it shows the key information.

Oh dear what an evening and morning. I reversed the facts I reported. Sure 2.1 is borken - that is the whole point. ( I realized that only after install 2.2.4 and generating fresh keys). To avoid confusion I will delete my last comments.

Duplicate of T3576

@werner It's just simple; With --personal-cipher-preferences 3DES (3DES only), make a encrypted message. Then, try to decrypt the message with OpenPGPcard (version 2.1 and later).

I find your question confusing. I'm the reporter of this bug. All the efforts and tries of gniibe and myself are documented above.
Or do you refrer to something else ?

Can you exactly explain how you tested this?

I also have the 2.1 Card which has this bug
Version ..........: 2.1
Manufacturer .....: ZeitControl

FWIW, I ran the same test with three card versions:

I forwarded the bug report to the OpenPGP card author.
I think that 2.0 card is OK, 2.1, 2.2, and 3.3 card have this bug.

So the assumption is it is an Error of the GnuPG card.
I tried today with an Yubikey 4 and it works. This confirms the theorie.
However - my preference is on the Smartcards. So how would we proceed now. Who can check for the error and correct it / flash a new version on a card.
I would offer to verify if it is fixed.

Here is an extract of the log file which shows the assumed cause

OK. I managed to reproduce same behavior. I think that it is a bug of OpenPGP card implementation.
Here is the log:

I sent the gpg: DBG: DEK frame via encrypted eMail to you. Hope this helps.

FWIW, the old format was only used up to PGP 2.3 . PGP 2.6 used the new format. This is actually more indication that the message has not been generated by an old PGP version.

Could you please give me the debug output line for DEK frame: by encrypted mail to me? So far, I can't find any likely scenario where an error occurs with smartcard. (Use of PGP2.6 is unlikely.)

The conformance problem may (only) happen between PGP 2.6 and OpenPGPcard, because PGP 2.6 uses old format not compatible to PKCS#1, but OpenPGPcard requires PKCS#1.

Ok - thats good news.
Thank you very much for your analysis.

OK, I got the picture, now.

Well, my speculation of SERIALNO undefined may be wrong.

Thanks, I received the log file.

Thank you for your efforts. Logfiles is in the mail

Thanks a lot for your testing. Here are my keys:

All right - that was quicker.
I deinstalled pcscd (apt remove pcscd)
I changed .gnupg/scdaemon.conf as you proposed.
I tried again to decrypt the message (in the meantime I have a file) which works decrypting withoutl SmartCard when I use it on a pc with the key.
Still failed. Can I send you the Logfile encrypted ? If so - what is you eMail / key.

As said - it took me a while. Sorry for the delay.
I could dig out the Key in some archives. So I was able to test the decryption of the message on a computer without smartcard.
It worked.

Thanks a lot. I'm going to push the fix to 2.2 (and then master).
In short, it was the bug in ccid-driver of scdaemon, which was introduced last year when I enhanced it to support multiple card readers at once.

Yes, thank you, the smartcard is being recognized now.

Thanks (again). According to the status code (bStatus), the card reader said no card is available.
Could you please remove the card and re-insert it, and do 'gpg --card-status'?

After

patch -i scdaemon-fix-for-inactive-start.diff scd/ccid-driver.c

the following log obtains.

Thanks a lot for your testing. Please test this patch:

After installing libusb-devel, and configure and make, this is the new log.

Thanks. I think that you configured GnuPG without libusb, thus, ccid-driver is not enabled, and you don't have pcscd installed. In this situation, no way to access any smartcard reader.