我需要一个 Java 中的加密 UDP 连接。 我知道 DTLS，但它在 Java 中是有问题的。所以我更喜欢使用 JKS 或 JCE 进行自己的加密。 为什么是 UDP？一些丢失的数据包或重新排序与我无关，但延迟确实如此。 到目前为止我有这个概念：
服务器创建一个临时的对称加密密钥（会话唯一），用客户端的公钥加密（非对称加密）并将其发送给他。他们与仅使用对称密钥加密的数据报进行通信。
与 DTLS 相比，使用这种方法有哪些缺点？速度？安全吗？
【问题讨论】：
标签： java udp datagram jce dtls
这听起来几乎就像您正在尝试重新发明 DTLS。你是说 DTLS 有问题，但这是为什么呢？
理论上你的逻辑是合理的。它让我想起了带有 RSA 密钥交换的 DTLS：
ClientRandom)ServerRandom)Pre-Master Secret，使用服务器公钥加密）现在双方都有：ClientRandom、ServerRandom 是公共知识，Pre-Master Secret 仅通过非对称加密在网络上共享。只有证书的所有者知道从网络通信中解密Pre-Master Secret 所需的私钥，因此客户端验证服务器发送的证书非常重要。
DTLS 确定从Pre-Master Secret、ClientRandom 和ServerRandom 生成Master Secret 的方法以及从Master Secret 生成对称加密/MAC 密钥的方法。 DTLS 使用Pre-Master Secret 而不是直接共享Master Secret 以实现模块化。从安全的角度来看，直接分享Master Secret 应该同样安全。 ClientRandom 和 ServerRandom 在技术上用作密钥生成中的盐。这保证了两个参与者在盐的加密安全方面都有发言权。
一旦生成对称加密密钥，参与者在结束握手之前进一步验证他们可以使用它们进行通信。
使用 CBC 时，加密数据包本身的形式为：
[ IV ] + encrypted( [ Data blocks ] [ HMAC ] [ Padding ] )
为每个数据包发送初始化向量会增加一些传输开销，但可以防御某些选择的明文攻击。然而，这只是针对不同攻击的安全措施之一。有效的 (D)TLS 实施有很多不同的细微差别：忽略或隐藏错误条件，确保操作即使失败也需要恒定的时间等。
因此，虽然 DTLS 的安全理念可以概括为“将公钥共享给一个参与者。使用非对称加密传输对称密钥。使用对称密钥加密通信”，但还有更多的小细节使其安全。当人们发明自己的安全措施时，这些小细节通常会失败。
通过验证证书可以减少有效的 MITM 攻击 - 当然，在上述握手中，只有客户端验证服务器身份。如果您需要服务器验证客户端身份，客户端也需要发送自己的证书等。
【讨论】：
主要缺点是您自己想到的。一般来说，除非一个人实际上是密码学家，否则永远不应该尝试在密码学相关问题上变得“聪明”或“创新”。在工具、算法和攻击向量方面缺乏全面的经验，确保加密强度的最佳方法是使用经过良好测试的标准化工具。这意味着 DTLS。
在这种情况下，一个问题似乎是对 MITM 攻击的敏感性，假设服务器还不知道所有客户端的公钥。根据对称算法和数据报的内容，它也可能容易受到已知明文攻击或选择密文攻击。同样，这些是您应该阅读的内容，感到害怕，意识到这不是您想要花时间做的事情，然后使用 DTLS。
【讨论】：