使用什么密码来加密 UDP 数据包？
我有一个通过 UDP 进行时间敏感通信的应用程序（例如视频流或游戏）。数据包可能会丢失，不需要重传。
我应该使用什么密码来加密数据报？
我倾向于欧洲央行模式下的河豚。我知道ECB模式有问题，但我需要支持丢失数据包，因此加密不能依赖于以前的块。 是否有更好的密码或模式可以用来减少 ECB 问题模式并且仍然允许丢失数据包？
（我想保留一切纯Java，所以我不能使用DTLS。）
I have an application that does time-sensitive communications over UDP (like video streaming or a game). Packets may be lost, and do not need to be re-transmitted.
What cipher should I use to encrypt the datagrams?
I'm leaning towards blowfish in ECB mode. I know ECB mode has problems, but I need to support missing packets, so the encryption cannot rely on previous blocks. Is there a better cipher or mode I can use to reduce the issues with ECB mode and still allow for missing packets?
(I'd like to keep everything pure Java, so I cannot use DTLS.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
计数器模式 (CTR) 中的 AES 是一个可行的选择。建立连接时，您将以发送程序和接收程序都知道的随机选择的值启动计数器。如果每个视频数据包包含一个足够长的序列号 (n)，不会在单个连接内重复，则接收程序可以将其添加到初始计数器值，以获得用于加密该数据包。
当然，对于超过一个块的消息，您需要在一个数据包内多次增加计数器。我将确定最长传输的数据包有多少个块，例如 16 个块，并对数据包中的第一个块使用计数器值
16*n，16*n+1< /code> 为第二个，依此类推。AES in counter mode (CTR) is a feasible option. When establishing a connection, you would start the counter at a randomly selected value known to both the sending and receiving programs. If each packet of video data contains a sequence number (n) long enough to not repeat within a single connection, the receiving program can add that to the initial counter value to get the value of the counter used to encrypt that packet.
Of course, for messages longer than one block, you will need to increment the counter more than once within a packet. I would determine how many blocks long the longest transmitted packet would be, for example 16 blocks, and use counter values
16*nfor the first block in the packet,16*n+1for the second, and so on.您可以使用CBC模式，只需将每个数据包加密为单独的CBC流即可。这意味着使用新的 IV 重新启动每个数据包的 CBC。
顺便说一句，Blowfish 只是一个 64 位（块大小）的块密码，目前这本身就赋予了它相当低的安全边际。
You can use CBC mode, you just need to encrypt each packet as a separate CBC stream. That means re-starting CBC each packet, with a fresh IV.
By the way, Blowfish is only a 64 bit (block size) block cipher, which these days inherently gives it a fairly low margin of security.
ECB 很容易受到攻击，因为每个加密块都完全独立于所有其他加密块，这使得既可以通过注意到某些两个（或更多）密码块相同来推断密文的内容，也可以通过重新排列来以无法察觉的方式更改消息密码块或替换使用相同密钥加密的其他消息中的密码块（这本身不是一个好主意）。
如果您的 UDP 数据包包含一些序列信息，您可以将其用作 CTR 模式下的计数器，也可以使用 XEX（或 XTS）模式。 XEX 是为加密情况而开发的，在这种情况下，数据加密可能必须按块的随机顺序执行，就像硬盘驱动器等加密随机访问设备的情况一样，并且对于像您这样的情况来说是理想的选择。
请参阅http://en.wikipedia.org/wiki/Disk_encryption_theory#XEX
ECB is open to attack because each ciphered block is quite independent of all others, which makes it possible both make deductions about the content of the ciphertext by noticing that some two (or more) cipher blocks are identical and to alter the message undetectably by rearranging cipher blocks or substituting cipher blocks from other messages encrypted using the same key (which is itself not a good idea).
If your UDP packets contain some sequence information you can use that as the counter in CTR mode, or you can use XEX (or XTS) mode. XEX was developed for encryption situations in which data ciphering may have to be performed in random order of blocks, as is the case with encrypted random-access devices like hard drives, and would be ideal for a situation such as yours.
See http://en.wikipedia.org/wiki/Disk_encryption_theory#XEX