possible pinentry enhancement
gniibe at fsij.org
Fri May 20 09:55:00 CEST 2016
On 05/20/2016 03:30 PM, Werner Koch wrote:
> On Fri, 20 May 2016 04:04, gniibe at fsij.org said:
>> Let the pinentry computes KDF (on host computer).
>> (KDF: Key Derivation Function)
> Why pinentry? Why not scdaemon?
True, I see that scdaemon is better place for this feature to be
implemented. (I was considering about use of pinentry by gpg-agent,
and gpg-agent would also want pinentry's computing KDF.)
When scdaemon does KDF, the DEK string to token will be constant
length. That's great for me.
Constant length is so great, I learned today, again.
Today, I made a Gnuk Token blocked by three failures, due to the
OpenPGPcard protocol design. In the protocol, PIN is variable length,
but there is no delimiter in CHANGE_REFERENCE_DATA command, nor length
of the PIN. Old PIN and New PIN is concatenated to make a single
string and it is sent to a token. I think that this is bad.
I was testing new Gnuk implementation. I invoked "gpg --edit-key" for
subcommand "keytocard" to register private keys to a token. In the
procedure, it asked for admin PIN multiple times, when I did
"keytocard" for primary key and two subkeys. I entered factory
setting admin PIN = 12345678 many times.
Then, I do "gpg --card-edit" to change user PIN. There, it asked for
user PIN and new user PIN. I should have entered factory user PIN =
123456 at first, but since I had entered 12345678 many times, I
mistakenly entered 12345678. Then, I entered new PIN (suppose it
was "new passphrase").
GnuPG said "PIN changed" (successfully).
However, in fact, the new user PIN became "78new passphrase", while I
thought it were "new passphrase". Since I was so confident for "new
passphrase", I tried three times. And it got blocked.
Because it was a testing environment, I enabled the CCID driver log.
I examined the log, and I found that I entered 12345678 where I should
More information about the Gnupg-devel