possible pinentry enhancement

[NIIBE Yutaka]

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
enter 123456.
--