我应该使用哪种加密方法？答案

【问题标题】：Which of the encryption approaches should I use?我应该使用哪种加密方法？
【发布时间】：2010-12-06 03:40:06
【问题描述】：

我需要一个系统来交换非常机密的数据（源代码是商业机密）。我将使用 Crypto++，所以实际上我可以使用所有加密算法，尽管我更喜欢使用行业标准。

目前我正在考虑这些方法：

让服务器生成 2048/4096 位 RSA 密钥，将公钥发送给客户端，让客户端加密数据，然后将其发送给服务器。
使用像 Diffie-Hellman（正确的是 Diffie-Hellman-Merkle）这样的密钥交换方法来交换 AES-256 密钥。
启动 TLS 连接并直接告诉服务器 AES 密钥。

您认为我应该使用哪种方法？只要合理，我不关心性能；安全才是最重要的。如果都没有，请建议另一种方法。

P.S.：我可能会在对称算法上使用链接，例如 AES-Twofish-Serpent。

编辑：任何推荐的软件都必须在不限制专有使用的许可中。 LGPL 尽可能严格。这排除了 GPL。

【问题讨论】：

我只会使用 GPG。它可以立即使用，并且是某种电子邮件的行业标准（适用于那些关心安全电子邮件的人）。但你可能有一些特殊要求，我不知道。
AES-128 实际上比其他 AES 变体更安全。 neworder.box.sk/newsread.php?newsid=22916
GPG 在这种情况下真的没用。 @AES-128 更安全，AES 几乎不会被破坏。您链接的页面甚至说这些攻击是完全不切实际的。它还说只有第 9 轮 Rinjdael 有可能被打破。 AES 标准规定最小值为 10 轮，AFAIK 256 位版本有 14 轮。
要添加更多到 GPG，它在 GPLv3 下，我根本无法使用。

标签： encryption rsa aes

【解决方案1】：

不要开发自己的密钥交换和/或密钥配置协议。这在历史上破坏了大多数产品，除非你是一名密码学家（不是具有加密经验的程序员），否则你很可能会弄错。

使用现成的协议，例如 SSL/TLS。例如。使用 RSA 密钥对初始化的 TLS 用于相互身份验证和 AES 会话密钥听起来很适合您的描述

更新

Bruce Schneier:

“一位同事曾经告诉我，这个世界充满了糟糕的安全保障阅读者设计的系统应用密码学”

erickson 在他的帖子中已经为您提供了大量证据，说明为什么设计您自己的密钥配置和管理协议存在缺陷。感谢过度自信的开发人员，我只想说明为什么 Mallory 还活着并且做得很好：

您设计了您提出的方案，其中客户端使用公钥加密并将文档发送回给您。一切都很好，但是 1 年后证书即将到期。您使用包含您希望用户签名的公钥的新证书向您的客户发送一封电子邮件，为您加密文档。您不知道的是，在过去的 4 个月中，您的 ISP 管理员收到了贿赂，以通过远程计算机路由您的所有 IP 流量。您的电子邮件在分发前被截获，并且您附加的证书被另一个证书替换。您的所有客户现在都在发送他们的超级机密文件，这些文件为其他人的私钥加密。一个应用程序对每一个进行解密、存储，然后用您的公钥对其进行加密并将流量转发给您。您甚至不会知道发生了什么，直到您在访问客户网站时偶然发现他使用的证书不是您分发的证书。

您在帖子中提到作为链接算法的选项。没有人会粗暴地强迫你。您的弱点将是密钥管理，并且攻击将采取某种形式的社会工程来欺骗某人使用错误的密钥或陶醉私钥（再次，贿赂有很长的路要走）。行业认可的协议具有防止中间人攻击的步骤，它们可能依赖于识别指定密钥使用和受信任机构的 PKI 基础设施，它们将证书吊销列表检查步骤添加到验证等等等。只是'我用公共加密密钥，你用 private' 解密并不能保证秘密安全。

【讨论】：

实际上，即使如果您是密码学家，您也可能会弄错。这就是为什么密码算法和协议通常由小组开发，在部署之前公开并经过多年严格的公开审查。
我想我会捆绑 OpenSSL 并在这种情况下使用 TLS 进行连接。但是，如果我使用从服务器收到的公钥加密我的数据，为什么我需要使用 TLS？用公钥加密的数据只能用私钥解密，不会离开服务器。
@Wikie：理论上你是对的（忽略所有公钥配置问题，如信任根和处理撤销等）。实际上，没有人使用 RSA 密钥加密数据。您使用会话密钥对其进行加密，并使用 RSA 密钥对会话密钥进行加密。如果是通道加密（耦合、在线、同步），则像 TLS 这样的协议会为您进行密钥管理（会话密钥的派生和交换）。如果是文档加密（解耦、离线、异步），则有 S/MIME 或 PGP 等协议可以解决此问题。
为什么要使用 RSA 密钥加密主密钥？这听起来毫无意义。这是文档加密 AFAIK。
您打算将与文档关联的对称密钥存储在哪里？您打算对所有文档使用一个密钥吗？您将如何处理密钥更新、重新加密所有现有文档？

【解决方案2】：

我建议使用带有可靠加密模块的现有 S/MIME（或 CMS）实施来加密您的内容。

S/MIME 封装数据为存储“静态”加密数据提供了一种很好的格式：信封记录了有关使用的算法和密钥的信息，以便授权接收者在需要时可以使用这些信息。

此外，即使它不支持“最佳”算法（如 ECDH 密钥协议），与一般程序员编写的库相比，好的库也不太可能存在漏洞。由于实现错误比密码分析更可能破坏安全性，因此将这些错误最小化是有意义的。

在合法协议中，公钥由少数受信任的发行者之一签名，其公钥通过某种安全方式“带外”分发。如果您已经有一种安全的方法来获取消息发送者的公钥，为什么还要再发送一个呢？如果你不这样做，你就完蛋了。

TLS 和 S/MIME 依赖于每个客户端都有一组众所周知的 CA 证书。这些用于签署服务器的公钥，以便客户端可以检测到替换密钥的尝试。协议不能自举；必须有一种安全的方式在带外分发“信任锚”。

另请注意，与对称密码相比，RSA 速度非常慢。真实协议为像 AES 这样的对称算法生成 “内容加密密钥”，然后使用 RSA 公钥作为 “密钥加密密钥” 来加密内容加密密钥邮件收件人。

因此，主要问题是将您的公钥安全地提供给客户端。如果你能做到这一点，那么选项#1 或#2 都是好的——假设你只使用那个公钥，而不是尝试“带内”发送另一个公钥。事实上，在CMS中，选项#1被称为“密钥传输”，选项#2被称为“密钥协议”。

在实践中，“服务器”可以使用由众所周知的 CA 颁发的证书，或者客户端可以将证书的哈希值与您通过电话告诉他的证书进行比较，或者刻入悬崖之类的。关键是，所有您的安全性都取决于证书的完整性。你必须保护它不被篡改。

虽然 Crypto++ 是“行业标准”，但其安全性取决于您如何使用它。 Just like Jerry told Kramer,“门必须...关闭！”使用加密Crypto++ 中的原语使用设计不佳的协议将让你无处可去。这就是为什么我要强调使用 CMS（更高级别的协议）以及良好的加密模块（加密原语）。

【讨论】：

Crypto++ 看起来像一个行业标准，至少对我来说是这样。算法很可能不会改变，即使会改变，所有存储的文件都会伴随着元数据，所以改变算法不是问题。
这就是我在这里问的原因，以确保我确实正确使用它。

【解决方案3】：

那么 ssh 呢？（例如 ssh 上的 rsync）？

【讨论】：

SSH 在 Windows 上有点痛苦，我需要的不仅仅是上传文件。我什至可能不会上传它们，只需告诉服务器加密密钥/从服务器获取它。