☰

Duplicity - 使用多个设备的 GPG 密钥加密

tag-icon • tag-icon backup encryption gnupg duplicity
Duplicity - 使用多个设备的 GPG 密钥加密

我正在努力为使用 Duplicity 的备份建立一个有效且强大的配置，因为我知道我需要基于密钥对的非对称 GPG 加密。并且能够从多个设备安全地备份。

我今天所拥有的：

我已成功将加密数据发送到远程存储并从中恢复了备份文件。

现在，我对这个设置有 2 个问题：

  1. 我必须在每次备份操作时输入密钥密码

我怀疑是这样的，因为我的签名密钥受密码保护（使用相同的密码保护所有子密钥，据我所知，这是 GPG 的限制）我尝试设置 gpg 代理并将密码无限期地存储在缓存中。但这不起作用，而且无论如何可能不明智。这种限制使得设置无人值守备份变得非常困难/不可能

-> 我应该使用没有密码保护的签名子项吗？这似乎也不是正确的做法...

  1. 我想从多个设备备份

使用我当前的设置，我需要将同一组密钥导入新设备。这显然是我想要避免的。如果设备被盗，我不希望攻击者能够访问我的所有备份，攻击者可以使用被盗密钥解密所有数据。->“不要把鸡蛋放在同一个篮子里”。

首先，“不要把鸡蛋放在同一个篮子里”也可以理解为你不应该依赖一个 PGP 密钥对来做所有事情。例如，你应该创建一个与“电子邮件/Git”密钥对分开的“备份/存储”密钥对。毕竟，它们的用途和要求完全不同——你的备份完全是内部的，所以无论如何，它们都不会从由你的“主”PGP 密钥对签名中受益。

=> 这很有道理，谢谢，创建一个新的备份特定密钥对似乎是合理的。

但是，如果我对系统的理解正确的话，Duplicity 不需要能够解密您的备份 - 它只需要加密它们。（当然，除非您需要恢复。）这意味着您实际上不需要在备份存储库的任何设备上使用加密子密钥的私有部分，它只需要在恢复时存在。

=> 我认为您说得对。除了增量备份失败并需要重新启动的情况外，这种情况不应该经常发生，我想手动干预是可以接受的。所有这些都表明，是的，用于加密的私有子密钥可能不在任何设备上。

-> 这里推荐的策略是什么？据我目前了解，使用同一个 GPG 主密钥管理多个加密/签名子密钥是不可行的？我是否应该生成多个主密钥以用于备份？

我会尽量总结一下：

  • 如果我想为每个设备使用不同的加密密钥（似乎是最安全的选择），我必须为每个设备生成一个新的密钥对，对吗？
  • 至于签名密钥，我仍然不清楚如何继续......
    • 它应该作为设备特定密钥对的子密钥进行管理吗？
    • 或者所有设备都使用同一个密钥？
    • 多个签名密钥作为单独密钥对的子密钥？

这有道理吗？再次感谢您的帮助！

答案1

我想从多个设备备份

使用我当前的设置，我需要将同一组密钥导入新设备。这显然是我想要避免的。如果设备被盗，我不希望攻击者能够访问我的所有备份，攻击者可以使用被盗密钥解密所有数据。->“不要把鸡蛋放在同一个篮子里”。

首先，“不要把鸡蛋放在同一个篮子里”也可以理解为你不应该依赖一个 PGP 密钥对来做所有事情。例如，你应该创建一个与“电子邮件/Git”密钥对分开的“备份/存储”密钥对。毕竟，它们的用途和要求完全不同——你的备份完全是内部的，所以无论如何，它们都不会从由你的“主”PGP 密钥对签名中受益。

但如果我理解正确的话，Duplicity 不需要能够解密你的备份——它只需要加密它们。（当然，除非你需要恢复。）这意味着你实际上不需要加密子密钥的私有部分任何在构成备份存储库的设备中，它仅需在恢复时出现。

据我今天了解，使用同一个 GPG 主密钥来管理多个加密/签名子密钥是不可行的？

您不能有多个加密子密钥（因为发件人无法知道您想在哪个设备上阅读消息，所以唯一可行的选择是加密到全部加密子密钥——这反而违背了拥有多个密钥的意义）。

另一方面，你可以轻松地拥有多个签署每个密钥有多个子密钥，因为它与加密的情况相反。

（使用相同的密码保护所有子密钥，据我所知，这是 GPG 的限制）

这更可能是一个 UI 选择。gpg-agent做支持对每个私钥进行不同的保护（它实际上并不关心关系），但如果 GnuPG UI 使“更改密码”操作仅影响特定子键，则它可能会让更多用户感到困惑，而不是提供帮助。

从中找到每个私钥的“keygrip” gpg -K --with-keygrip，然后使用gpg-connect-agent直接更改其密码（绕过 GnuPG）：

gpg-connect-agent "passwd KEYGRIP" /bye

相关内容