c++ - Why does GPGME / GnuPG use pinentry for password input? -
gpgme uses passphrase_cb
method fetch password user operations, require access private keys. callback can overwritten symmetric encryption, in other cases default pinentry used.
all effort seems pretty uncomfortable, because gpgme api shall used programming c/c++/... applications. might easier (for programmer use gpgme) in cases if passphrase passed encrypt/sign functions directly. saw other implementations of openpgp (to more precise netpgp) use callback.
so wonder if there security specific reason so?
gnupg starting 2.1 removed critical private key functionality gpg-agent
, reduce attack surface on intimate secrets -- private keys.
such callback not expose passphrase application you're writing (which means larger attack surface gnupg be), gnupg gets aware of passphrase.
if need control entry of passphrase application, have several choices.
implementing pinentry
the information flow be: application calls gnupg through gpgme, gnupg requests private key operation gpg-agent
, again asks application passphrase. aware work if started gpg-agent
appropriate pinentry configuration (you might have start instance, separate 1 running on system).
gpg-preset-passphrase
the important use case of passing passphrase directly in headless daemons, no humans waits entering passphrase. gnupg brings small utility gpg-preset-passphrase
(on debian , derivatives, installed /usr/lib/gnupg2/gpg-preset-passphrase
), can used precache passphrase (so not queried configurable time).
pinentry loopback
with gnupg 2.1, option added: in gpg-agent
, can allow pinentry loopback allow-loopback-pinentry
option. additional parameter pinentry-mode
set loopback
in gnupg/gpgme should allow handle passphrase interaction using passphrase_cb
again.
but: consider exposes passphrase not both application , gnupg, , might prove (possibly minor existing , maybe unnecessary) security risk. also, gnupg 2.1 not yet spread, might problem if not control environment.
Comments
Post a Comment