TLS 中 CCM 的安全性，與摘要的 GCM、SHA 或 SHA2 相比

我一直在研究 OpenSSL 和 mbedTLS（以前稱為 PolarSSL）的 TLS 密碼套件，並註意到 mbedTLS 支持CCM操作模式（請參閱此處的列表），而 OpenSSL 不支持。如果我理解正確，這提供了經過身份驗證的加密，因此涵蓋了 TLS 中的消息散列，如 GCM。

查找 CCM，我找不到太多關於其安全性的資訊。它與 GCM 或 SHA1/2 相比如何？

---

編輯：

帶有 CCM 的 mbedTLS TLS 密碼套件：

• TLS-RSA-WITH-AES-128-CCM
• TLS-RSA-WITH-AES-256-CCM
• TLS-RSA-WITH-AES-128-CCM-8
• TLS-RSA-WITH-AES-256-CCM-8
• TLS-DHE-RSA-WITH-AES-128-CCM
• TLS-DHE-RSA-WITH-AES-256-CCM
• TLS-DHE-RSA-WITH-AES-128-CCM-8
• TLS-DHE-RSA-WITH-AES-256-CCM-8
• TLS-ECDHE-ECDSA-WITH-AES-128-CCM
• TLS-ECDHE-ECDSA-WITH-AES-256-CCM
• TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8
• TLS-ECDHE-ECDSA-WITH-AES-256-CCM-8
• TLS-PSK-WITH-AES-128-CCM
• TLS-PSK-WITH-AES-256-CCM
• TLS-PSK-WITH-AES-128-CCM-8
• TLS-PSK-WITH-AES-256-CCM-8
• TLS-DHE-PSK-WITH-AES-128-CCM
• TLS-DHE-PSK-WITH-AES-256-CCM
• TLS-DHE-PSK-WITH-AES-128-CCM-8
• TLS-DHE-PSK-WITH-AES-256-CCM-8

就典型的 TLS 使用而言，GCM 和 CCM 基本上都很好，儘管對它們有很多警告：

1. 如果您不能保證您使用的是 AES 的硬體實現，那麼任何涉及 AES 的東西都可能容易受到定時側通道攻擊。（可移植的 C 程式碼不能。）
2. 如果您不能保證您使用的是硬體伽羅瓦域算法，GCM 也很可能容易受到不同時序側通道攻擊。（可移植的 C 程式碼不能。）
3. 身份驗證標籤的長度直接影響安全性：GCM 和 CCM 套件使用 128 位標籤，但 CCM-8 套件使用 64 位標籤，因此它們無法獲得比 64 位更好的防偽安全級別。
4. 對於 GCM 和 CCM，安全合約要求密鑰永遠不會與 nonce 一起重用。如果它們被明智地集成到 TLS 中，協議將強制使用順序隨機數，這樣每條消息只有一個隨機數的可能選擇，如果對等點選擇任何其他隨機數，它將無法互操作。 TLS 1.3 會做到這一點，但是當GCM 首次引入 TLS時，它被愚蠢地設計為允許對等方隨意選擇隨機數，以達到搞笑的效果，並且TLS 中的 CCM重複了這個錯誤。

除非選擇完全不同的密碼套件，否則您無法解決任何這些問題，但您可以檢查這些問題是否是 mbedTLS 或您的特定部署的問題 - 例如，確保 mbedTLS 使用順序隨機數，並仔細查看關於它如何計算 AES 和 GHASH。

或者，如果 mbedTLS 和您的客戶支持它，則始終使用ChaCha20/Poly1305 密碼套件，它們沒有這些問題。

查找 CCM，我找不到太多關於其安全性的資訊。它與 GCM 或 SHA1/2 相比如何？

• CCM 速度較慢，因為它每個塊需要兩次密碼呼叫，而不是像 GCM 中那樣進行欄位乘法和密碼呼叫。請注意，只有當欄位乘法實際上可以在您的平台上快速實現和/或您沒有 AES 的硬體加速時，這才成立。
• CCM 需要在開始加密過程之前知道消息長度。雖然在其他場景中有限制，但這在 TLS 中不是問題。
• CCM 更簡單。CCM 實際上只是 CTR 和 CMAC（CBC-MAC 的一種變體），正確實現應該不會太難，而且肯定比 GCM 更容易。
• 如果您需要縮短標籤，CCM比 GCM*好得多。*如果縮短標籤，GCM 會對要加密的數據量施加（甚至更強）限制（參見NIST SP 800-38D (PDF) 的附錄 C），而 CCM 不會發生這種情況。對於 CCM，查詢的數量占主導地位（參見NIST SP 800-38C (PDF) 的附錄 B）。

引用自：https://crypto.stackexchange.com/questions/50364