我需要一个系统来交换非常机密的数据（源代码是商业机密）。我将使用 Crypto++，所以实际上我可以使用所有加密算法，尽管我更喜欢使用行业标准。
目前我正在考虑这些方法：
你认为我应该使用哪种方法？只要合理，我不关心性能；安全才是最重要的。如果都没有，请建议另一种方法。
PS：我可能会在对称算法上使用链接，例如 AES-Twofish-Serpent。
编辑：任何推荐的软件都必须在不会限制专有使用的许可证中。LGPL 尽可能严格。这排除了 GPL。
不要开发自己的密钥交换和/或密钥供应协议。这在历史上破坏了大多数产品，除非您是一名密码学家（不是具有加密经验的程序员），否则您可能会弄错。
使用现成的协议，如 SSL/TLS。例如。使用 RSA 密钥对初始化的 TLS 用于相互身份验证和 AES 会话密钥听起来适合您所描述的内容
更新
“一位同事曾经告诉我，世界上到处都是由阅读应用密码学的人设计的糟糕的安全系统”
埃里克森在他的帖子中已经为您提供了大量证据，说明为什么设计您自己的密钥配置和管理协议存在缺陷。多亏了过于自信的开发人员，我只想说明为什么 Mallory 还活着并且做得很好：
您设计您提出的方案，其中客户端使用公钥加密并将文档发送回给您。一切都很好，但是 1 年后证书即将到期。您使用包含您希望用户签名的公钥的新证书向您的客户发送一封电子邮件，为您加密文档。您不知道的是，在过去的 4 个月中，您的 ISP 管理员收到了贿赂，以通过远程计算机路由您的所有 IP 流量。您的电子邮件在分发前被截获，并且您附加的证书被另一个证书替换。您的所有客户现在都在发送他们的超级机密文件，这些文件为其他人的私钥加密。一个应用程序对每一个进行解密、存储，然后用您的公钥对其进行加密并将流量转发给您。你甚至不会知道正在发生，
您在帖子中提到作为链接算法的选项。没有人会粗暴地强迫你。您的弱点将是密钥管理，并且攻击将采取某种形式的社会工程来欺骗某人使用错误的密钥，或陶醉私钥（再次，贿赂有很长的路要走）。行业认可的协议具有防止中间人攻击的步骤，它们可能依赖于识别指定密钥使用和受信任机构的 PKI 基础设施，它们将证书吊销列表检查步骤添加到验证等等等。只是'我用公共加密密钥，你用私人解密'不会使秘密安全。
我建议使用带有可靠加密模块的现有 S/MIME（或 CMS）实现来加密您的内容。
S/MIME 封装数据为“静态”加密数据的存储提供了一种很好的格式：信封记录了有关所使用的算法和密钥的信息，以便授权接收者稍后在需要时可以使用这些信息。
此外，即使它不支持“最佳”算法（如 ECDH 密钥协议），与一般程序员编写的库相比，好的库也不太可能存在漏洞。由于实施错误比密码分析更有可能破坏安全性，因此将这些错误最小化是有意义的。
在合法协议中，公钥由少数受信任的发行者之一签名，其公钥通过某种安全方式“带外”分发。如果您已经有一种安全的方法来获取消息发送者的公钥，为什么还要发送另一个呢？如果你不这样做，你就完蛋了。
TLS 和 S/MIME 依赖于每个客户端都有一组众所周知的 CA 证书。这些用于签署服务器的公钥，以便客户端可以检测到替换密钥的尝试。协议不能自举；必须有一种安全的方式在带外分发“信任锚”。
另请注意，与对称密码相比，RSA 速度非常慢。真实协议为 AES 等对称算法生成“内容加密密钥”，然后使用 RSA 公钥作为“密钥加密密钥”为消息接收者加密内容加密密钥。
因此，主要问题是将您的公钥安全地提供给客户端。如果你能做到这一点，那么选项#1 或#2 都是好的——假设你只使用那个公钥，而不是尝试“带内”发送另一个公钥。实际上，在CMS中，选项#1 称为“密钥传输”，选项#2 称为“密钥协议”。
在实践中，“服务器”可以使用由众所周知的 CA 颁发的证书，或者客户端可以将证书的哈希值与您通过电话告诉他的证书进行比较，或者刻在悬崖上，管他呢。关键是，您所有的安全性都取决于证书的完整性。你必须保护它不被篡改。
虽然 Crypto++ 是“行业标准”，但其安全性取决于您如何使用它。 就像 Jerry 对 Kramer 说的那样， “门必须……关上！ ”在设计不佳的协议中使用 Crypto++ 中的加密原语会让你一事无成。这就是为什么我要强调使用 CMS（一种更高级别的协议）和一个好的密码模块（密码原语）。
ssh 呢？（例如 ssh 上的 rsync）？