加密工具

加密不是”安全专家的事”——配置文件加密、Git 签名、密钥管理是每个开发者每天都要面对的实际问题。工具选对了，加密就像系安全带一样自然。

1. 开发者需要了解的加密

很多开发者对加密的印象停留在”密码学是数学家的领域”。但现实中，你每天都在和加密打交道：HTTPS 是加密、SSH 是加密、Git 签名是加密、密码管理器也是加密。

开发者需要掌握的加密场景只有三种：

场景	保护什么	典型工具
文件加密	保护数据内容不被未授权读取	age
密钥管理	保护凭证（API Key、密码）的安全存储和分发	sops、1Password
签名认证	验证身份，证明”这确实是我做的”	GPG

核心理念：加密不是为了完美安全，而是为了提高攻击成本。 你不需要成为密码学家，但你需要知道用什么工具解决什么问题。

2. age — 现代文件加密

age 是 GPG 的现代替代品，由 Go 语言开发者 Filippo Valsorda 设计。它的设计哲学很简单：只做一件事（文件加密），做好它。

为什么不用 GPG 加密文件

GPG 功能过多——它同时处理加密、签名、密钥管理、信任网络。功能多意味着复杂，复杂意味着容易出错。GPG 的 CBC 加密模式已过时，默认配置也不够安全。age 的选择是：砍掉所有不需要的功能，只保留文件加密。

基本用法

# 生成密钥对（私钥保存到文件，公钥打印到终端）
age-keygen -o ~/.age/key.txt
 
# 加密文件（用公钥）
age -r age1xxxxxxxxxx... secrets.txt > secrets.txt.age
 
# 解密文件（用私钥）
age -d -i ~/.age/key.txt secrets.txt.age > secrets.txt
 
# 密码加密（不需要密钥文件，适合一次性分享）
age -p file.txt > file.txt.age
age -d file.txt.age > file.txt

实际场景

加密备份：备份数据库导出文件时，先加密再存储。

pg_dump mydb | age -r age1xxx... > backup.sql.age

加密分享敏感文件：通过邮件或聊天工具发送敏感文件时，用密码加密模式，通过另一渠道告知密码。

与 chezmoi 集成：chezmoi 原生支持 age 加密，dotfiles 中的敏感配置可以安全提交到 Git。

3. sops — 配置文件密钥管理

sops（Secrets OPerationS）解决了 age 无法解决的问题：加密配置文件中的敏感字段，同时保持文件结构可读。

为什么需要 sops

假设你有一个 config.yaml，里面既有公开配置（数据库地址、端口），又有敏感信息（密码、API Key）。用 age 加密整个文件，所有人都看不到任何内容——包括代码审查者。sops 的方案是：只加密 value，保留 key 可读。

# 加密前
database:
  host: localhost
  password: my-secret-password
 
# sops 加密后
database:
  host: localhost
  password: ENC[AES256_GCM,data:xxx,iv:yyy,...]

基本用法

# 创建 .sops.yaml 配置（项目根目录）
 
# creation_rules:
 
#   - path_regex: \.yaml$
 
#     age: age1xxxxxxxxxx...
 
# 加密文件
 
sops -e config.yaml > config.enc.yaml
 
# 编辑加密文件（自动解密 → 打开编辑器 → 保存时重新加密）
 
sops config.enc.yaml
 
# 解密查看
 
sops -d config.enc.yaml

实际场景

Git 仓库中的敏感配置：sops 让你可以安全地把加密配置提交到 Git，而不是用 .gitignore 排除。团队成员各自提供 age 公钥，.sops.yaml 中列出所有公钥，任何人都可以解密。

K8s Secrets / Terraform variables：基础设施即代码中的敏感值，用 sops 加密后和代码一起版本控制。

4. GPG — Git 提交签名

GPG 在开发者日常工作流中的主要用途是：给 Git 提交签名，证明提交确实是你做的。

为什么需要签名提交

GitHub 上的绿色 “Verified” 标记就是 GPG 签名的结果。没有签名的提交，任何人都可以伪造你的邮箱和名字。签名提交后，GitHub 验证签名与你的 GPG 公钥匹配，显示 Verified 标记。

基本用法

# 生成 GPG 密钥
gpg --gen-key
 
# 查看密钥
gpg --list-secret-keys --keyid-format LONG
 
# Git 配置签名
git config --global user.signingkey <KEY-ID>
git config --global commit.gpgsign true
 
# 签名提交
git commit -S -m "feat: add encryption guide"
 
# 验证签名
git log --show-signature -1
git verify-commit HEAD

配置 GitHub

1. 导出公钥：gpg --armor --export [email protected]
2. GitHub → Settings → SSH and GPG keys → New GPG key
3. 粘贴公钥内容

GPG vs SSH 签名

SSH 签名是更简单的替代方案（参考 01-SSH.md）。如果你只需要 Git 签名，SSH 签名配置更简单。但 GPG 的生态更成熟，开源项目和企业合规通常要求 GPG 签名。

5. 密钥管理工具 — 1Password CLI

环境变量中的密钥并不安全——进程列表可见、日志可能记录、容器编排中可能泄露。密码管理器的 CLI 接口是更好的方案。

基本用法

# 登录
 
op signin
 
# 获取密码
 
op item get "My App" --fields password
 
# 直接读取值（适合脚本）
 
op read "op://vault/item/field"
 
# 注入环境变量
 
export DB_PASS=$(op read "op://Private/MyDB/password")
 
# 生成新凭据
 
op item create --category "API Credential" --title "New API Key"

实际场景

CI/CD 中安全读取密钥：CI 环境中通过 1Password CLI 或 Secrets Manager 注入密钥，而不是在 CI 变量中明文存储。

本地开发时注入凭据：启动开发服务器时，从 1Password 读取数据库密码，而不是写在 .env 文件中。

方案对比

方案	安全性	便利性	适用场景
.env 文件	低	高	本地开发（不进 Git）
1Password CLI	高	中	个人/小团队
AWS Secrets Manager	高	中	AWS 生态
HashiCorp Vault	很高	低	企业级

6. 工具对比与选型指南

工具	用途	加密算法	密钥管理	适用场景
age	文件加密	ChaCha20-Poly1305	密钥文件 / 密码	个人文件加密、备份
sops	配置加密	age / GPG / KMS	多种后端	Git 中的敏感配置
GPG	签名 + 加密	RSA / ECC	密钥环	Git 提交签名、邮件加密
1Password CLI	密钥存储	AES-256	云端	团队凭据管理

选型建议：

• 加密单个文件 → age
• 加密配置文件中的敏感字段 → sops + age
• Git 提交签名 → GPG（或 SSH 签名）
• 管理密码和 API Key → 1Password

7. 使用原则

加密工具的目标不是制造复杂感，而是让秘密在正确的位置、被正确的人、以正确方式使用。

文件分享优先 age：一次性文件加密、给明确收件人传文件，age 简单可靠。不要为了简单文件分享拉起完整 GPG 体系。

项目密钥优先 sops：需要把加密配置放进 Git 时，用 sops 这类工具保留结构化 diff 和明确解密流程。

提交签名看团队要求：GPG 或 SSH 签名能证明提交身份，但前提是团队真的会验证它，并且密钥管理流程清楚。

脚本不要裸拿长期密钥：优先使用密码管理器、短期 token、CI secrets 和最小权限账号。

加密不等于权限治理：加密能保护静态秘密，但无法替代撤销、轮换、审计和访问控制。

延伸阅读

• age GitHub — age 官方仓库，设计文档和 RFC
• sops GitHub — sops 官方仓库，支持多种加密后端
• GnuPG 手册 — GPG 官方文档
• 1Password CLI 文档 — 1Password CLI 完整参考
• Filippo Valsorda: “age — a simple, modern and secure file encryption tool” — age 设计者的博客文章