Java DTLS与使用JKS/JCE加密UDP数据报

我需要一个加密的UDP连接在Java中。 我知道DTL，但它在Java中有问题。因此，我更愿意使用JKS或JCE进行自己的加密。 为什么是UDP？一些丢失的数据包或重新排序与我无关，但延迟与我无关。 到目前为止，我有这个概念：

服务器创建临时对称加密密钥（对于会话是唯一的），使用客户端的公钥对其进行加密（非对称加密），然后将其发送给him。会话的其余部分，它们仅与使用对称密钥加密的数据报通信

---

与DTL相比，使用这种方法的缺点是什么？速度安全性？

主要的缺点是你自己就想到了。一般来说，除非你是一名真正的密码学家，否则你永远不应该在密码学相关问题上“聪明”或“创新”。由于缺乏关于工具、算法和攻击向量的全面经验，确保加密强度的最佳方法是使用经过良好测试的标准化工具。这意味着DTL

---

在这种情况下，一个问题似乎是易受MITM攻击，假设服务器还不知道所有客户端的公钥。根据对称算法和数据报的内容，它也可能容易受到已知的明文攻击或选定的密文攻击。同样，这些都是你应该读一读的东西，感到害怕，意识到这不是你想花时间在的东西，然后去使用DTL。

这听起来像是你在试图重新发明DTL。你说DTLS有问题，但为什么会这样

理论上你的逻辑是正确的。它让我想起了使用RSA密钥交换的DTL：

• 客户端->ClientHello（共享

  ClientRandom

  ）
• 服务器->服务器你好（共享

  ServerRandom

  ）
• 服务器->证书（共享证书，其中包含服务器公钥）
• 客户端->密钥交换（共享

  预主密钥

  使用服务器公钥加密）

现在双方都有：

ClientRandom

，

ServerRandom

，它们是公共知识，并且只有通过非对称加密才能通过网络共享的

Pre-Master Secret

。只有证书的所有者知道从网络通信中解密

预主密钥所需的私钥，因此客户端验证服务器发送的证书非常重要

DTLS确定从
预主密钥
、
客户端域
和
服务器随机
生成
主密钥
的方法，以及从
主密钥
生成对称加密/MAC密钥的方法。DTLS使用
Pre-Master Secret
来实现模块化，而不是直接共享
Master Secret
。从安全角度来看，直接共享
主密钥
应该同样安全。
ClientRandom
和
ServerRandom
技术上用作密钥生成中的salt。这保证了两个参与者在salt的加密安全方面都有发言权

一旦生成对称加密密钥，参与者在结束握手之前进一步验证他们可以使用这些密钥进行通信

使用CBC时，加密数据包本身的形式为：

[ IV ] + encrypted( [ Data blocks ] [ HMAC ] [ Padding ] )

在每个数据包中发送初始化向量会给传输增加一些开销，但可以抵御某些选择的明文攻击。然而，这只是针对不同攻击的安全措施之一。在有效的（D）TLS实现中有许多不同的细微差别：忽略或隐藏错误条件，确保操作即使失败也需要恒定的时间，等等

因此，虽然DTLS的安全思想可以总结为“将公钥共享给一个参与者。使用非对称加密传输对称密钥。使用对称密钥加密通信”，但还有很多小细节使其安全。当人们发明自己的安全措施时，这些小细节通常会失败

通过验证证书可以减少有效的MITM攻击—当然，在上面的握手中，只有客户端验证服务器身份。如果需要服务器验证客户端身份，客户端还需要发送自己的证书等。
初始握手和对称密钥交换将通过SSL/TLS与JKS可信证书进行。真的会有这样的MITM风险吗？发送的数据报将是用AES/CBC（或更好的东西）加密的视频流。无文本。根据您的加密方式，还可能存在可能应用的填充oracle攻击等。您是否尝试过Bouncy Castle DTLS实现？