possible pinentry enhancement

NIIBE Yutaka gniibe at fsij.org
Sat May 21 03:44:18 CEST 2016


On 05/20/2016 04:55 PM, NIIBE Yutaka wrote:
> 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.

I considered further.

It might be good to define a (pseudo) data object for SALT, so that
scdaemon can access it.  Factory default of the data object is NULL.

We can extend the (interpretation of) CHANGE_REFERENCE_DATA command in
this form:

	CHANGE_REFERENCE_DATA <OLD DEK> <NEW DEK> <NEW SALT>

When a user uses his token on the go with other's environment, he can
change SALT/PASS-PHRASE back in home, by "gpg --card-edit" -> passwd
(in case of he cares a possibility of USB sniffer).  Even when he
doesn't change his passphrase (in case of he doesn't care about
keyboard logger for pinentry in other's environment), DEK can be
updated with new SALT.
-- 



More information about the Gnupg-devel mailing list