我最近在 Web 服务器上看到了用于 HTTPS 的 CAMELLIA、SEED 和 IDEA 密码套件，我不确定向所有者建议什么。使用的密钥长度均超过 128 位，并且正在使用标准 OpenSSL。
IDEA 在rfc5469中被弃用，因为它没有被广泛使用，但实际上可能并不安全。
使用上述密码套件的可能原因可能涉及对潜在的 NSA 干扰过于偏执，并希望改用日本/欧洲/韩国密码套件。使用这些密码不受任何当地法律要求的影响。
不使用这些密码的可能原因包括它们并未在整个行业中广泛使用，因此与 AES 或其他替代方案相比，安全社区的研究可能较少。有可能有人可以通过调整用于其他密码的侧信道攻击来开发侧信道攻击，但这对于这个服务器来说是极不可能的。大多数现代浏览器都取消了对它们的支持，我想不出任何可以使用这些密码套件的客户端不支持也可用的 AES 的情况。
除了提醒所有者注意弃用 IDEA 并建议使用事实上的行业标准密码套件通常是一个好主意，因为这些密码套件已经进行了最多的研究，还有什么我应该注意的吗？
总的来说，我希望所有支持现代模式的现代密码套件（目前通常是 GCM 或 CCM，到目前为止只有 GCM 开始广泛使用）。
这将允许通过禁用已知的弱密码同时仍然具有已经广泛部署的其他仍然强大的密码来减轻未来的算法弱点（例如 RC4 的渐进式弱化）。当在其中一个中发现缺陷时，拥有各种好的、可靠的选择至关重要。
IDEA 是古老的 64 位，如您所见，应根据RFC5469弃用。我建议永远不要再使用它。
CAMELLIA 是欧洲 NESSIE 项目在最终选择算法时与其他三种分组密码（包括 AES）一起接受的现代密码。
日本CRYPTREC项目在其《电子政务推荐密码规范》中也接受了CAMELLIA 。
我建议根据 RFC6367 在 GCM 模式下完全支持CAMELLIA。
SEED 是一种较旧的韩国密码；我不建议支持它，尤其是因为我不知道 TLS 中有任何 GCM 或其他现代模式可用；只有RFC4162中的旧模式。
更现代的韩国密码是 ARIA ( RFC5469 )。ARIA 在RFC6209中为 TLS 添加了几个密码套件，包括值得强烈考虑的 GCM 模式套件。
IDEA使用 64 位块。这意味着它开始遇到麻烦，从密码学上讲，如果您使用相同的密钥（在 CBC 模式下）加密超过 2 32 个块的数据。那是 32 GB，这是相当大的，但按照今天的标准并不是无法达到的。因此，应该避免。
Camellia和SEED是分组密码的存在，主要是因为日本和韩国政府患有NIH 综合症。据我们所知，它们是相当不错的算法——就像 AES 一样。没有充分的理由相信它们更强大；如果您是偏执狂，请考虑如果有一些未知的方法可以使 AES 受到影响，那么没有理由相信 Camellia 和 SEED 不会受到同等影响。
更喜欢 AES 的一个实际原因是，在实现 AES 的恒定时间实现方面已经做了很多工作。此外，一些 CPU 提供了一些硬件支持，这对于防止侧信道攻击甚至更好，并提供更好的性能。使用这些算法中的任何一个，典型的 Web 服务器都不会出现任何性能问题；旁道攻击在实践中是否适用是任何人的猜测。
仍然在实际方面，如果客户端不支持 Camellia 或 SEED，那么在服务器上启用它们是毫无意义的——它们无论如何都不会被使用。
我认为没有理由支持例如 AES 而不是其他经过良好测试的密码。即使 IDEA 和其他密码可能没有那么多关于其安全性的研究，它们也不是未经测试的。
我认为更大的问题是，使用的是旧版本的 TLS（甚至是旧的 SSL）。由此产生的攻击面以及通过旧 OpenSSL 版本的错误产生的攻击面要大得多。
因此，在我看来（我不是密码学家或安全专家），使用经过良好测试但不是很流行的密码不是问题。然而，它并没有增加安全性，所以没有特别的理由要使用异国密码。