GnuPGv2 & 'pinentry' on Linux w/ remote access
wk at gnupg.org
Thu Nov 9 09:24:46 CET 2017
On Tue, 7 Nov 2017 14:45, gnupg-users at gnupg.org said:
> Could you elaborate on the 'why' part of this enforced pinentry usage
> with GnuPG? It wasn't mandatory in 1.x, now it's forced on us.
It is definitely not new. GnuPG 1.9 was released 14 years ago (it was
renamed to 2.0 2.0 11 years ago). It has been used at quite some places
right away from that time on. The new thing with 2.0 was the
modularized system: The private keys were only managed and accessible by
gpg-agent and gpgsm (gpg for S/MIME) used it this way.
Unfortunately it took until the summer of 2010 before I was able to port
gpg to use the same system as gpgsm and let gpg-agent handle the private
keys. (Before that gpg used gpg-agent only for passphrase caching.)
Not having to care about private keys in gpg allowed us to remove a lot
of semi-duplicated code from gpg. This instantly fixed the long
standing import/merging of secret key bugs.
For an architectural point of view gpg-agent can be viewed as a token
which can be accessed only via a well defined API. gpg does not take
precautions against leaking secret keys. The actual code to do secret
key operations (decrypt, signing) is done only at one place so that gpg
and gpgsm, and other possible crypto protocols share the same code.
Smartcard access is unified - gpg, gpgsm, and ssh can use the same
gpg-agent can be theoretically be run under a different account.
gpg-agent can actually be run on a remote machine, so that you don't
need to have a secret key on a server but delegate that work to a
desktop box or even a box which is used as a HSM.
The drawback is that application don't need to handle passphrases
anymore. However, I would call that a huge benefit because applications
are relieved from handling the sensitive passphrase and can let another
process (pinentry) do that on demand from gpg-agent. On X this works
very well, with curses it is more complicated and needs some adjustments
(or hitting Ctrl-L). On Windows it was easy as well but later got
complicated due to new Windows security measurements so that there is a
small chance that the pinentry won't pop up but blonk only in the
While preparing for the 2.1 release, we decided to add a loopback mode
to gpg-agent/gpg/gpgsm so that instead of writing one's own loopback
pinentry it is in most cases possible to keep on using existing code
which expects to handle the passphrase. Adding --pinentry-mode=loopback
to the gpg invocation does this.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 227 bytes
Desc: not available
More information about the Gnupg-users