[Gnuk-users] State of EdDSA in Gnuk / GnuPG

[Bertrand Jacquin]

On 21/01/2015 01:12, NIIBE Yutaka wrote:

>> I can see that it fail on function gnuk_token.__init__ on line 75:
>> 
>>         self.__devhandle.claimInterface(interface)
>> 
>> This happens when gpg-agent is running. After that can changing the
>> admin PIN for g.cmd_verify, it's better.
> 
> Only a single process can claim the interface of Gnuk Token.  If
> scdaemon is running, you need to stop it before running any scripts.
> I should have addressed that in the previous mail.

Right, my message was not clear enough. It could be helpful to get a 
message asking us to check if nothing is currently claiming the 
smartcard and that we may run gpg-connect-agent "SCD KILLSCD" "SCD BYE" 
/bye or equivalent, rather can getting the python stacktrace. That is 
really minor.

>>   $ gpg --card-status | grep -F attributes
>> 
>>   Key attributes ...: 2048R 4096R 255?
> 
> It seems that it works.  It seems that you have registered RSA-4096
> subkey for decryption.

Right

> I haven't decided a character for EdDSA (and Curve25519), or shall we
> change the format here (a single character is not so expressive)?
> Thus, it's '?' here.

Why not stick on GnuPG naming convention ? Is there a naming limitation 
from the smartcard itself ?

>> Then after when trying to transfer a key to the smartcard:
>> 
>>   $ gpg --edit-key ..
>>   ..
>>   sub* ed25519/0x7E28893D85B7D8D1
>>        created: 2015-01-20  expires: 2017-01-19  usage: A
>>   [ultimate] (1). esdf fwesdf <fwesdf at gesdg>
>> 
>>   gpg> keytocard
>>   Please select where to store the key:
>>      (3) Authentication key
>>   Your selection? 3
>> 
>>   gpg: WARNING: such a key has already been stored on the card!
>> 
>>   Replace existing key? (y/N) y
>>   gpg: KEYTOCARD failed: End of file
>> 
>> Is this something you already experienced ?
> 
> 'KEYTOCARD failed: End of file' is unexpected.

Right, the key on smartcard is well present and usable. That end of life 
looks strange in any case.

> Let me try to reproduce your failure.  I will be back.
> 
> P.S.  Please check your e-mail configuration (MUA).  In your reply
> message, you specified the address:
> 
>    <gnuk-users-bounces+bertrand=jacquin.bzh at lists.alioth.debian.org>
> 
> but this is a artificial (virtual) address for mailing list manager to
> detect transmission error, and it's not for use by human being.

I am using the Reply-All. This list does not define a Reply-To: header 
so in this case MUA use as an alternative the Sender: header that here 
is present. I'll drop bad recipient manually but this is something that 
can be fixed on the list itself.

-- 
Bertrand