用於 64 位明文的 AES
我有一個 64 位純文字，我想使用 AES 進行加密。但是要將 AES 用於 64 位純文字
- 我可以向它添加填充位
- 或在 CTR 流模式下使用 AES。
我的問題是
哪種方法更有效？
是否有任何其他方案可用於加密 64 位數據並且與 AES 一樣安全。
在加密方面沒有“像 AES 一樣安全”這樣的東西。這聽起來很奇怪，但讓我解釋一下。AES 是一種分組密碼。作為分組密碼，它總是使用明文塊中位的確定性排列。並且由於它是確定性的，它總是將相同的明文塊加密為相同的密文塊。
因此，當用作密碼時，它不是IND_CPA安全的。也就是說，你可以清楚的看到同樣的明文加密成同樣的密文；因此，您可以通過查看密文塊來區分明文塊。AES 是一種安全分組密碼，它本身並不是一種安全密碼。
現在，如果您要添加填充位，那麼您仍然無法實現 IND_CPA 安全性。分組密碼的填充方案（例如 PKCS#7 填充）通常是確定性的。所以這在一般情況下是行不通的。
CTR 模式加密被認為是塊大小為 128 位或更大的塊密碼的安全操作模式。然而，CTR 模式需要一個隨機數來操作。因此，您要麼必須生成一個並將其與密文一起儲存，要麼必須使用一些帶外方法來生成隨機數（例如，儲存在數據庫中其他位置的數字）。如果您可以儲存大約 128 位的輸出，這是一個不錯的選擇：只需儲存 64 位隨機生成的隨機數和 64 位密文（對於許多 API，您可能必須通過右填充零將其擴展到 128 位）。
CTR 模式不添加任何完整性保護，因此您可能希望通過使用經過身份驗證的 (AEAD) 密碼來添加它。然而，這將為認證標籤添加更多位到輸出中。
對於 64 位明文，很容易使用 64 位分組密碼進行簡單加密。這不會提供 IND_CPA 安全性，但您可能不在乎是否可以區分相同的明文塊。您還可以查看 Format Preserving Encryption。三重 DES 仍然是一個選擇；在實踐中，它可能會提供與 128 位密碼一樣多的安全性。
也許使用公鑰加密是個好主意。例如，如果您不希望在加密期間暴露解密密鑰，就會出現這種情況。
我已經從一般意義上回答了這個問題。但是你可以看到，我們還有很多未知數。這就是為什麼“是否有任何其他方案可用於加密 64 位數據並且與 AES 一樣安全”的問題。是舖位。
加密不是目標；為您的數據提供安全保障。如果沒有明確定義您的目標、案例、需求和威脅模型，任何答案都可能是錯誤的。
請注意，所有方案都對可以使用單個密鑰加密多少個 64 位塊有限制。