我们正在嵌入式设备上部署 ipsec，并从 ike 中的 diffie hellman 2048 小组获得灾难性的性能。之后，共享安全用于 3des、sha1。单个隧道的 ipsec 协商远远超过 20 秒。网络堆栈正在使用 openssl 进行协商
在这种情况下，我是否正确地说 1024 在 DH 中使用足够安全？我的理解是 dh 1024 可以协商 ipsec sa，生命周期为 24 小时，直到 dh 1024 可以在 <24 小时内强制执行。这不太可能在 2030 年之前
没有保密要求，所以我们不关心是否有人可以在 24 小时后解密流量，只要他们不能重新注入或篡改当前的数据包就可以了。
使用 dh 2048 的原因是因为“1024 不再安全”。我对 dh 2048 没有任何反对意见，但考虑到性能问题，我正试图推动 1024 组。如果我错过了一些问题，我不想这样做。
1024 不安全的建议与长寿命（1-2 年）的 RSA 密钥有关。由于 DH 协商短期（24 小时）会话密钥，因此 1024 组中的 DH 对我们来说是可以的。
在 2048 组中使用 dh，则生成的共享密钥具有 160 位的安全性，在 10 - 15 年内无法强制使用。10-15 年，因为 rsa 2048 在 2030 年之前被认为是安全的，我假设 dh 2048 是相似的
如果使用 1024 组中的 dh，那么生成的共享密钥可能在几年内都是安全的。为 ike 定义 dh 1024 的 RFC 2409 说它产生超过 160 位的安全性。然而，它应该是所需安全位数的两倍，我们需要 224，因为 224 = 2 * 112 而 3des 需要 112。所以 rfc 中的“超过”是什么意思。
默认情况下，openssl 将 dh 秘密生成为长度等于 dh 共享素数的随机数，所以我认为它将处于“超过”含义的大端。我不知道如何验证虽然
RSA 1024 尚未强制实施，但预计将在不久的将来推出，可能需要数月或数年的计算。但是，我们的产品在 10 年后仍将继续使用。也许 RSA 1024 会在 2025 年很容易实施，只要需要超过一天的时间 dh 1024 仍然可以。（我并不是说 dh 1024 会在 2025 年成为一个不错的选择，我是说如果我们今天选择它，那么我们将不必在 2025 年之前逐步淘汰它）
我们的 dh 产生的共享密钥仅使用 24 小时。SA 生命周期为 24 小时，因此我们将每 24 小时重新协商一次隧道。这意味着每 24 小时就有一个新的 DH 秘密。因此，只要不能在 24 小时内强制使用 dh 1024，我们就可以使用 dh 1024。只要我们认为 DH 1024 仍然需要一天以上的时间，就可以强制使用 dh 1024 的共享密钥可能几周后。
后续问题，如果我们使用 3des tat 需要 112 位安全性，DH 应该生成所需的两倍多的位，但 DH 1024 只生成 160 位。在实践中这有多大问题？
我们还可以选择修改协商，我们可以说使用 dh 2048，但在较小的值空间中生成秘密。在 openssl 中，我们可以在 DH 结构上设置 q 参数以确定要在 DH_generate_key 中生成的字节数。但是，这似乎不如使用 dh 1024 有吸引力
如果这不成立，有人可以纠正我吗？谢谢