c++ - 为什么 GPGME/GnuPG 使用 pinentry 来输入密码？

Question

GPGME 使用passphrase_cb 方法从用户处获取密码以进行操作，这需要访问私钥。只能为对称加密覆盖此回调，在所有其他情况下使用默认的 pinentry。

所有这些努力似乎都让人很不舒服，特别是因为 GPGME 是一个 API，应该用于编程 C/C++/... 应用程序。在某些情况下，如果可以将密码短语直接传递给加密/签名函数，可能会更容易(对于想要使用 GPGME 的程序员)。我还看到 OpenPGP(更准确地说是 NetPGP)的其他实现使用回调。

所以我想知道这样做是否有任何特定的安全原因？

Answer 1

从 2.1 开始，GnuPG 将最关键的私钥功能移除到 gpg-agent 中，以减少对最私密的 secret ——私钥的攻击面。

这样的回调不仅会将密码短语暴露给您正在编写的应用程序(这可能意味着比 GnuPG 更大的攻击面)，而且 GnuPG 也会知道密码短语。

如果您确实需要控制应用程序的密码输入，您有多种选择。

实现二进位

然后信息流将是:您的应用程序通过 GPGME 调用 GnuPG，GnuPG 从 gpg-agent 请求一些私钥操作，它再次向您的应用程序询问密码。请注意，这仅在您还使用适当的 pinentry 配置启动 gpg-agent 时才有效(您可能必须启动另一个实例，与系统上已经运行的实例分开)。

gpg-preset-passphrase

直接传递密码最重要的用例是在 headless 守护进程中，没有人等待输入密码。 GnuPG 还带来了一个小工具 gpg-preset-passphrase(在 Debian 和衍生版上，它安装为 /usr/lib/gnupg2/gpg-preset-passphrase)，它也可用于预缓存密码(因此在可配置的时间内不会查询)。

Pinentry环回

在 GnuPG 2.1 中，添加了另一个选项:在 gpg-agent 中，您可以使用 allow-loopback-pinentry 选项允许 pinentry 环回。在 GnuPG/GPGME 中将附加参数 pinentry-mode 设置为 loopback 应该允许您再次使用 passphrase_cb 处理密码交互。

但是:考虑到这会同时暴露您的应用程序和 GnuPG 的密码，并且可能被证明是一个(可能很小但存在并且可能是不必要的)安全风险。此外，GnuPG 2.1 尚未广泛传播，如果您不控制环境，这可能会成为一个问题。