【发布时间】：2014-10-20 15:18:10
【问题描述】：
我正在开发一个应用程序，该应用程序需要对 LAN 环境中的所有流量进行加密，因此加密速度很重要，并且需要减少 cpu 时间以让应用程序拥有更多的 cpu 周期。因此，由于我不是密码学家，因此我试图了解除了自己滚动之外，我现有的选择是什么。
我现在正在尝试获取所有半有效选项的完整列表，以便能够测量和测试它们：
- TLS -- 速度不快，也许可以调整密码
- SSH -- 维护 ssh 隧道可能是一种负担
- UDT -- 应该是高性能，可选加密如何？
- CurveCP -- 由 DJB 提供，所以加密很好，不确定传输部分
- MinimaLT -- DJB 贡献了加密技术，其他人负责传输
- IPSec -- 配置很重要
我还错过了什么？
【问题讨论】：
-
TLS 被谁“认为不快”？如果你确实有一个主要的 CPU 使用问题，你应该考虑硬件解决方案，而不是不同的协议。
-
偏好是不使用硬件解决方案，我可以有限地使用基于 CPU 的硬件加速，但不能指望我的云提供商为我的需要添加特定的硬件。
-
1) 您是否担心握手成本或批量加密成本？在后一种情况下，协议无关紧要，密码的选择和实现很重要。 2）您使用的是哪种CPU？您的绩效目标是什么？
-
1) 关于批量加密的更多信息，连接设置也是一个问题，但不太重要。假设大部分时间都可以保持连接并且更新密钥不是太频繁或不是太昂贵。 2）CPU未知，应用运行在公有云中。
-
这个问题已经有一年多了：我在研究类似任务的过程中偶然发现了这个问题，并得出结论，curvecp 使用 djb（Daniel J. Bernstein 教授）的 nacl 库具有严重的优点：现代 Linux 发行版有一个名为“nacl-tools”的“即用型”包，其中包含两个程序“curvecpclient”和“curvecpserver”，它们与“curvecpmakekey”工具一起消除了大部分开发负担。所以我倾向于不同意这里给出的 Marten Bodewes 回答。
标签： encryption tcp udp transport