AES-GCM加密是指
本頁面由日文原文機器翻譯而成。 閱讀日文原文
AES-GCM是結合加密和篡改驗證的方式。 解說nonce、認證標籤的作用、與其他方式的差異、應用程式的保護範圍，可以在瀏覽器中嘗試驗證失敗。
更新：2026年9月9日。 確認了NIST・IETF・Apple的一次資料和SimpleMemo公開版5.8.26的實施。 筆者是SimpleMemo的開發者。
密碼文・nonce・標籤做什麼？
AES是通用金鑰密碼，GCM是那個動作模式。 AES-GCM是處理加密正文和不加密認證的附加資料（AAD）的AEAD。 例如，在隱藏正文的同時，可以將格式的版本號與正文聯絡起來進行驗證。 AAD本身不是秘密。
nonce（IV）是每個加密的值，同一金鑰需要不重複使用的設計。 和秘金鑰匙的作用不同，可以和密碼文一起儲存。 認證標籤用於解密時的驗證。 驗證失敗的資料不採用，作為錯誤處理。
方式的定義：NIST SP 800-38D。 輸入和nonce的條件：RFC 5116。
如果改變密碼文，會怎麼樣？
只用瀏覽器的Web Crypto API處理本頁內準備好的例文。 首先確認可以加密並恢復原狀，然後將密碼文的副本更改為1位進行驗證。 不是稽核應用程式的加密處理的演示。
例句： Review the draft at 10:00.
可以從第一個按鈕開始嘗試。
處理中...
驗證成功：解密為原來的例文。
驗證失敗：更改的密碼文被拒絕，平文沒有返回。
無法完成處理。 可以從第一個按鈕重新開始。
在這個環境下不能執行演示。 需要HTTPS對應的瀏覽器和JavaScript。
- nonce（12位元組）
- 原來的密碼文（16進位制數）
- 認證標籤（16位元組）
每次執行都會製作新的256位金鑰和nonce。 演示不儲存、傳送金鑰和結果。 重新載入標籤後，結果會重置。 結構：Web Cryptography API的AES-GCM。
與AES-CBC・ChaCha20-Poly1305的區別
方式的差異如下。 速度因終端和安裝而異，這個表不是實測排名。 僅憑使用CBC的資訊，無法判斷結合認證的產品整體的安全性。
| 專案 | AES-GCM | AES-CBC | ChaCha20-聚1305 |
|---|---|---|---|
| 加密和認證 | 一體型（AEAD） | CBC單體僅加密 | 一體型（AEAD） |
| AES的使用 | 使用 | 使用 | 不使用 |
| 透過設計確認 | 鑰匙・nonce・標籤・使用量的上限 | 與認證的組合・IV・填充處理 | 鑰匙・nonce・標籤・使用量的上限 |
TLS 1.3不是隻有AES-GCM的規格。 RFC 8446 §9.1必須安裝AES-128-GCM，也推薦AES-256-GCM和ChaCha20-Poly1305。 ChaCha20-Poly1305的規格請參考RFC 8439。
SimpleMemo會保護哪些資料？
確認的公開版的本地儲存處理，使用Apple的CryptoKit的AES-GCM和Keychain管理的金鑰。 新生成的金鑰是256位。 Outbox是等待傳送資料的保管場所，不能以這種加密為依據說“郵件也會被E2E加密到傳送地址”。
這個實現從Keychain讀取對稱金鑰後使用。 Keychain中儲存的金鑰和Secure Enclave內生成、利用的秘密金鑰不是相同的說明。 Apple的CryptoKit金鑰的儲存和Secure Enclave的金鑰說明了區分使用。
郵件傳送時，透過應用程式的轉播處理和配送企業，接收方也會留下副本。 結合加密方式，請確認隱私政策、收件人設定和到達確認、終端、郵件賬戶的管理。 從Outbox開始專案消失和完全刪除所有副本是不同的。
常見問題
AES-256-GCM的“256”是什麼？
AES鑰匙的長度是256位元的意思。 不是表示nonce和認證標籤的長度、終端整體安全性的數字。
nonce有必要保密嗎？
nonce與秘密金鑰不同，可以附加密碼文儲存。 重要的是，用同一個金鑰加密時不要重複使用nonce。
標籤驗證失敗的話，可以顯示正文嗎？
驗證失敗的結果不能作為正確的平文使用。 分離損壞、錯誤的鑰匙、變更的資料等，處理認證錯誤。
使用AES-GCM的話可以進行E2E加密嗎？
僅靠方式名是無法決定的。 需要設計整個系統，包括誰擁有鑰匙，在哪裡解密。 終端內的Outbox加密和郵件的配送、接收地址的儲存是不同的範圍。
Keychain儲存的話，鑰匙不會從Secure Enclave出來嗎？
不一定如此。 這個應用程式確認的實現，從Keychain讀取對稱金鑰的資料後使用。 與在Secure Enclave中進行秘密金鑰運算的API不一樣。
