我們正在通過本教程 ( https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ )在 Kubernetes 中實作靜態加密，我們完全不確定為什么 AES-GCM 加密提供程式需要輪換密鑰由于缺乏有關加密如何作業的知識，每 200K 寫入一次。另外，究竟是什么意思：“200K 寫入”，我們如何定義我們應該旋轉密鑰？謝謝
uj5u.com熱心網友回復：
我們完全不確定為什么 AES-GCM 加密提供程式需要輪換
GCM模式基本上是一種內置完整性驗證（訊息驗證碼）的CTR流模式。對于這種模式，防止重復使用相同的 IV/密鑰對非常重要。建議限制使用亂數沖突的相同密鑰限制概率和密鑰分析選項加密的內容的數量（這些是一些數學背后的內容，已在評論中提及）。
是的，200k 是一個任意數字，但必須有人說出一個合理的數字，其中 nonce 碰撞概率仍然可以忽略不計，并且密鑰可以在很長一段時間內使用。
究竟是什么意思：“200K 寫入”，
這通常很難估計，這取決于“寫入”是什么。如果您使用密鑰加密其他隨機密鑰（作為包裝密??鑰）或使用該密鑰加密大量連續內容（例如存盤），則可能會有所不同。
我們如何定義我們應該旋轉密鑰？
讓我們實際一點，例如 AWS KMS 每年都會提供自動密鑰輪換。基于這個問題，假設密鑰用于加密etcd存盤（配置），每年輪換可能是一個安全的選擇。（我希望您在 k8s 集群中沒有 200k 秘密和配置映射）。
密鑰輪換程序通常會創建一個新密鑰（密鑰版本），并使用新密鑰對新內容進行加密。仍然可以使用舊密鑰解密現有內容。
在這方面，我有點擔心檔案中如何描述密鑰輪換。基本上步驟 1-4 看起來沒問題，定義了一個新的加密密鑰并生效。第 5 步和第 6 步是使用新密鑰重新加密所有etcd內容，基本上限制（如果不違背）密鑰輪換的整個目的。如果您有時間和耐心深入研究，也許您可??以通過支持來解決這個問題。
uj5u.com熱心網友回復：
根據 OpenShift 檔案：https ://docs.openshift.com/container-platform/3.11/admin_guide/encrypting_data.html
Kubernetes 沒有合適的亂數生成器，并且使用隨機 IV 作為 AES-GCM 的亂數。由于 AES-GCM 需要適當的亂數才能確保安全，因此不推薦使用 AES-GCM。200,000 次寫入限制只是將致命亂數誤用的可能性限制在合理的低范圍內。
這只是我所看到的任意數字。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/401718.html
標籤：Kubernetes 加密 原子能级数 等 aes-gcm