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不一样。
