Encryption 加密传输有哪些选项

我正在开发一个应用程序，该应用程序需要在LAN环境中加密其所有通信量，因此加密的速度非常重要，需要减少cpu时间，以使应用程序拥有更多的cpu周期。因此，由于我不是一名密码学家，我试图了解除了自己的滚动之外，我现有的选择是什么

我现在正试图获得所有半有效选项的综合列表，以便能够对其进行测量和测试：

• TLS——速度不快，可能需要调整密码
• SSH——维护SSH隧道可能是一个负担
• UDT——应该是高性能的，可选加密是如何实现的
• CurveCP——由DJB提供，因此加密是好的，不确定传输部分
• Minimant——DJB贡献了加密技术，其他人提供了传输
• IPSec——非常容易配置

---

我还错过了什么？

跟着TLS走。提供商听说过并且已经存在加速的可能性相当高。SSH也是一个选项，但通常用于管理

关于其他选项：

• UDT——应该是高性能的，可选加密是如何实现的？很好的问题，快速搜索并没有找到太多的信息，所以避免
• 所以加密是好的，不确定传输部分，主要由DJB做的任何事情都需要大学程度的密码学知识
• Minimant——DJB贡献了加密技术，其他人负责传输。见上文。主要文档似乎是一篇关于Minimalt的论文
• IPSec——非常容易配置，而且可能是错误级别的安全性。就我个人而言，我会避免，在云提供商上设置可能很棘手

因此，最终，传输级别的安全性似乎总是倾向于TLS

---

如果您希望快速实现和高安全性，请尝试使用带有AES和ECDSA/ECDH（E）的密码套件。

谁认为TLS“不快”？如果你真的有一个主要的CPU使用问题，你应该寻找一个硬件解决方案，而不是一个不同的协议。首选的是不要使用硬件解决方案，我可以有限地使用基于CPU的硬件加速，但不能指望我的云提供商为我的需要添加特定的硬件。1）你担心握手成本还是批量加密成本？在后一种情况下，协议无关紧要，密码的选择和实现很重要。2） 您使用的是哪种CPU？您的性能目标是什么？1）更多关于批量加密，连接设置也是一个问题，但不太重要。假设连接可以在大部分时间保持，并且重新键入不是太频繁就是不太昂贵。2） CPU未知，应用程序在公共云中运行。这个问题已经有一年多的历史了：我在研究一个类似的任务时偶然发现了这个问题，并得出结论，使用djb（Daniel J.Bernstein教授）的nacl库的curvecp具有严重的优势：现代Linux发行版具有“随时可用”的特性名为“nacl工具”的包包含两个程序“curvecpclient”和“curvecpserver”，这两个程序与工具“curvecpmakekey”一起减轻了大部分开发负担。所以我倾向于不同意Marten Bodewes在这里给出的答案。