告别 GPG 的瑞士军刀包袱：为什么 age 才是 21 世纪的文件加密利器？
在当今的云原生与 DevOps 实践中，文本配置、敏感凭据和基础设施代码（IaC）的加密存储已经成为刚需。提到文件加解密，许多从业者的第一反应依然是 PGP / GPG（GnuPG）。然而，每次在终端尝试配置 GPG 密钥、管理导入导出、或是给 CI/CD 自动化流水线注入加解密逻辑时，糟糕的交互体验和庞大的配置参数往往让人深感痛苦。
加密工具越庞大、越全能，真的就越安全吗？答案往往恰恰相反。
由知名密码学专家、前 Go 核心团队密码学负责人 Filippo Valsorda 设计的age（Actually Good Encryption），正以一种极其现代、简洁且安全的方式重塑我们对文件加密的认知。相比于设计于 20 世纪 90 年代的 OpenPGP 标准，age 摒弃了过去几十年的历史包袱，专门为 21 世纪的开发运维场景打造。
从密码原语、密钥格式、CLI 设计到云原生生态集成，如下对比图所示，age 在核心维度上全面重构了文件加密体验：
现代密码学算法：拒绝历史包袱与算法协商
GPG 最被现代密码学界诟病的一点，在于它对历史兼容性的过度妥协。
OpenPGP 标准诞生于 1990 年代，为了兼容过去数十年的旧系统，GPG 默认保留并支持了大量老旧、复杂甚至已经被证明存在安全隐患的密码算法（如 RSA、DSA、3DES、CAST5 等）。更致命的是，GPG 采用了算法协商机制（Algorithm Negotiation）——加解密双方在通信时需要动态协商使用哪种算法组合。这种机制不仅极易被攻击者利用进行降级攻击（Downgrade Attack），也为运维人员留下了巨大的安全隐患。
相比之下，age 展现出了极强且果断的现代密码学立场：完全取消算法协商，强制使用现代、高强度且经过严格验证的固化密码原语。
- 非对称/公钥加密：采用基于 Curve25519 的X25519算法，具有极高的计算效率与抗侧信道攻击能力。
- 对称加密与认证：采用ChaCha20-Poly1305结合认证加密（AEAD），保证机密性的同时自带完整性校验。
- 密钥衍生：采用HKDF与针对密码保护的Scrypt算法，有效抵抗暴力破解与 ASIC 专用芯片攻击。
在 age 的世界里，开发者无需再为“选择 2048 位还是 4096 位 RSA”、“挑选哪种哈希函数”而纠结。防错配置（Misuse-Resistant）的设计让加密工具在出厂时就达到了最高的安全防线。
轻量密钥格式：抛弃复杂的 Web of Trust
在 GPG 中，一把公钥往往不是纯粹的公钥，而是一个包含庞大元数据的“综合档案”：包含了复杂的 Web of Trust（信任网）、主钥与多个子钥的关系树、多重签署签名、密钥过期时间以及绑定的 User ID（姓名与邮箱等）。导出这样一把公钥，通常会得到一大串复杂的 Armor 格式字符串或庞大的二进制块。
而在 age 中，密钥重新回归到了最纯粹、最轻量的本真形态：
# age 导出的公钥（类似于 SSH 公钥） age1ql3vw9w42k2m2p5qsgvdms6x2s6m... # age 导出的私钥（干净纯粹的单行文本） AGE-SECRET-KEY-1...公钥仅以age1开头，私钥以AGE-SECRET-KEY-开头。没有冗余的个人邮箱绑定，没有复杂的证书链，也没有任何格式化的包装层。这种干净纯粹的文本格式，使得我们在将私钥写入环境变量、CI/CD Secret 平台（如 GitHub Actions Secrets、GitLab CI）或 Kubernetes Secret 时变得极其自然，彻底告别了二进制编解码和换行符转义的噩梦。
极简防误用设计：恪守 Unix 单一职责哲学
GPG 的命令行体验堪称现代 CLI 设计的反面教材。上百个命令行 Flag（如--armor、--recipient、--trust-model、--keyring等）和复杂的配置文件，不仅极难记忆，更让日常使用充满了误操作的风险。
age 则严格恪守 Unix 的极简主义哲学——“只做一件事，并把它做到极致”。它的命令行工具极其精简，掌握核心功能仅需几秒钟：
# 1. 使用接收者的公钥加密文件age-rage1ql3vw...-osecrets.txt.age secrets.txt# 2. 使用自己的私钥解密文件age-d-ikey.txt secrets.txt.age>secrets.txt没有深奥的配置选项，没有繁琐的交互询问。极其直观的参数命名（-r代表 recipient，-d代表 decrypt，-i代表 identity）极大降低了团队的理解与维护成本。
无缝集成云原生与 DevOps 生态
除了原生的age1密钥外，age 最让 DevOps 工程师惊艳的功能之一，在于它直接原生兼容 SSH 密钥。
age 在云原生生态与 DevOps 自动化架构中的落地图谱如下所示：
在日常研发中，几乎每位开发者和服务器都配置有 SSH 密钥对（如id_ed25519）。通过 age，我们无需重新生成或分发额外的加解密密钥，即可直接复用现有的 SSH 公钥完成文件加密：
# 直接使用现有的 SSH ED25519 公钥加密文件age-R~/.ssh/id_ed25519.pub secrets.txt>secrets.txt.age这种设计打通了基础设施身份认证与配置加密之间的壁垒。目前，现代云原生生态已经全面拥抱 age：
- Mozilla SOPS：业界主流的敏感配置文件加密工具，已将 age 列为首选的底层加密后端，用以替换原先笨重的 GPG 插件。
- GitOps 工具链：Flux CD 与 Argo CD 等 Kubernetes 持续交付控制器，原生支持结合 SOPS 与 age 实施自动化解密交付。
代码库极小与头部隐匿：更高的可审计性与隐私保障
安全性不仅来源于算法本身，更取决于实现代码的质量与复杂度。
- 代码库极其精炼：GPG 拥有数十万行极其复杂的 C 语言代码，历史上曾多次曝光解析器相关的内存安全漏洞。而 age 采用安全的 Go 语言编写（Rust 生态也有同款实现的
rage），核心代码仅有几千行。极小的代码体积使得专业机构的安全审计（Security Audit）变得非常容易，大幅减少了隐蔽的安全盲区。 - 文件头隐私隐匿：GPG 加密后的二进制头部通常会暴露接收者 Key ID 等元数据，外部观察者可以通过解析头部直接得知该文件是发给谁的。而 age 加密后的文件块不仅大小固定，且对 Recipients 信息进行了掩码隐藏，外部无法直接分析出解密者的身份，具备更优异的防追踪与隐私保护特性。
总结：从“瑞士军刀”到“精准手术刀”
如果说 GPG 像是一把集成了几十种旧工具、臃肿繁琐的“瑞士军刀”，那么 age 则像是一把精准、现代、轻量的“手术刀”。
它摒弃了 20 世纪 OpenPGP 遗留的历史包袱与复杂机制，用高强度的固化原语、极简的命令行交互、干净的密钥格式以及对 DevOps 生态的原生支持，完美契合了今天现代软件工程对文件加密与敏感信息管理的诉求。对于任何追求高效、安全与云原生自动化的团队而言，告别 GPG 拥抱 age，已经是一个不可逆转的现代趋势。