密码学与秘密处理

• 只加密需要的数据，明确数据分类
• 使用现代标准算法与安全模式
• 密钥管理与传输/存储分离

OWASP Cryptographic Storage Cheat Sheet 提供了"数据加密存储"的权威实践指南，核心要点包括：1）只加密需要保护的数据，先做数据分类（哪些是敏感数据、需加密、需保留多久），避免过度加密增加复杂性与合规成本；2）使用现代、经过验证的标准算法与安全模式——如 AES-GCM（AEAD 认证加密）、ChaCha20-Poly1305，避免使用过时/弱算法（DES、RC4、ECB 模式、无认证的 CBC）；3）区分"加密"与"哈希"——敏感数据（如信用卡号）用对称加密，而密码/口令用慢哈希（加盐），不可混淆；4）加密密钥必须与密文分离存储，通过密钥管理系统（KMS/Vault）管理，而非硬编码在代码中；5）使用唯一随机 IV/nonce，避免重用；6）对密文做完整性认证（AEAD 或 MAC），防止篡改；7）密钥定期轮换，制定密钥生命周期管理（生成、分发、使用、备份、销毁）；8）在传输层（TLS）与存储层（加密）分别实施保护。遵循"已知好算法 + 安全密钥管理 + 正确使用"是核心。

存储加密的关键是"算法正确 + 密钥安全 + 模式安全"。答题强调"现代 AEAD 算法、密钥与密文分离、IV 唯一、哈希与加密区分"。注意"加密≠哈希"的区分是高频考点。

• 密钥生命周期：生成、分发、存储、使用、轮换、销毁
• 密钥与数据分离、最小权限、审计
• 轮换与备份策略

OWASP Key Management Cheat Sheet 强调密钥管理是加密安全的核心，覆盖密钥的完整生命周期：1）生成——使用安全的随机数生成器（CSPRNG），避免弱熵；2）分发——安全分发密钥，避免明文传输；3）存储——密钥与密文分离，用硬件安全模块（HSM）或软件密钥保险库（KMS/Vault）集中存储，遵循最小权限访问；4）使用——密钥按用途分离（加密、签名、MAC 各用独立密钥），限制使用范围；5）轮换——定期轮换密钥，降低泄露影响，并支持离密钥（离职/泄露时立即吊销）；6）备份与恢复——安全备份密钥以防丢失，同时保证备份也受保护；7）销毁——退役密钥安全销毁（不可恢复），并处理多副本/备份中的残留。此外要求：做好密钥访问审计（谁在何时用了哪个密钥）、密钥元数据管理（版本、算法、用途）、应急响应（泄露时快速轮换）。把密钥管理"自动化 + 集中化 + 可审计"是工程最佳实践。

密钥生命周期管理的关键是"全生命周期 + 集中 + 最小权限 + 审计 + 轮换"。答题要覆盖各阶段并强调"密钥与数据分离"。说明密钥管理是加密安全的"地基"。

• 对称加密：加解密同密钥，高速
• 非对称加密：公钥/私钥，密钥分发
• 哈希：完整性（无密钥）、MAC：带密钥完整性、签名：认证+抗抵赖

密码学按功能分类，各自解决不同问题：对称加密（AES、ChaCha20）——加解密使用同一密钥，速度快，适合数据加密，但需解决密钥分发问题；非对称加密（RSA、ECC）——使用公钥/私钥对，公钥可公开、私钥保密，解决密钥分发与数字签名，但速度慢；哈希（SHA-256 等）——把任意数据映射为固定长度摘要，无密钥，用于完整性校验（检测数据被篡改），但无认证（任何人都能算）；MAC（消息认证码，如 HMAC）——带密钥的哈希，用于"完整性 + 认证"（验证数据未被篡改且来源可信），但对称双方共享密钥；数字签名（如 ECDSA、Ed25519）——基于非对称，用私钥签名、公钥验证，用于"完整性 + 认证 + 抗抵赖"（signer 无法否认），可公开验证。工程上按需选择：加密用对称+非对称组合，完整性用哈希/MAC，认证与抗抵赖用签名。注意"哈希与 MAC 的区别"在于是否有密钥、是否认证。

分类的关键是"解决的问题"与"是否有密钥、是否对称"。答题要点：哈希无密钥只防篡改、MAC 带密钥防篡改+认证、签名防篡改+认证+抗抵赖。区分"保密"与"完整性/认证"是核心。

• DH 原理：双方协商共享密钥而不泄露
• ECDH：基于椭圆曲线的 DH
• Curve25519：现代高效安全曲线

密钥交换用于"双方在不安全信道上协商出共享密钥而不泄露"：Diffie-Hellman（DH）——双方各自生成私钥和公钥，交换公钥后各自计算共享密钥，即使攻击者窃听公钥也无法反推私钥（离散对数难题）；ECDH——把 DH 实现到椭圆曲线上，同样原理但密钥更短、计算更快；Curve25519——一种现代高性能安全椭圆曲线（Montgomery 曲线），成为 X25519（ECDH 的现代实现）的基础，抗侧信道、常数时间、性能优秀，被广泛采用。前向保密（PFS，Perfect Forward Secrecy）指"即使长期密钥（如服务器的长期私钥）泄露，也无法解密历史会话内容"——因为每个会话使用独立的临时密钥（ephemeral）生成会话密钥，会话密钥不依赖长期密钥的持久性。TLS 中 ECDHE（ECDH 临时密钥）/DHE 提供 PFS，而静态 RSA 密钥交换不提供。因此现代 TLS 与安全通信优先采用 ECDHE 临时密钥交换 + Curve25519 以获得 PFS。

关键区分"静态 vs 临时（ephemeral）密钥交换"。PFS 依赖临时密钥：每次会话独立生成，长期私钥泄露不影响历史。答题强调"ECDHE/临时密钥 + Curve25519 = PFS"。

• AEAD：认证加密（加密 + 完整性认证一体）
• AES-GCM 与 ChaCha20-Poly1305 的差异
• 应用注意事项：IV/nonce 唯一、密钥管理

AEAD（Authenticated Encryption with Associated Data，带关联数据的认证加密）同时提供"机密性（加密）+ 完整性认证（认证标签）"，是现代对称加密的推荐范式。AES-GCM：AES 的 Galois/Counter Mode（GCM），在 CTR 模式基础上加 GHASH 认证，性能高（硬件加速好），广泛用于 TLS、数据加密；对 IV 重用极敏感（重用会导致密钥泄露）。ChaCha20-Poly1305：ChaCha20 流密码 + Poly1305 MAC 组合，纯软件实现也很快，抗侧信道、无需硬件加速，在资源受限或缺乏 AES 硬件加速的环境表现好，也是 TLS 的推荐套件之一。工程应用要点：1）两者都要求 nonce/IV 唯一（每个加密操作用不同 nonce，随机或计数器），绝不可重用；2）密钥用 CSPRNG 生成并安全管理；3）AEAD 的"关联数据（AAD）"可用于绑定上下文（如版本号、元数据），防篡改；4）优先使用成熟库（如 libsodium、Java 的 AES/GCM）、避免自实现；5）二者在 TLS 中互为补充（AES-GCM 与 ChaCha20-Poly1305 都是 TLS 1.3 标准套件）。

AEAD 的核心是"加密+认证一体"。答题要点：AES-GCM 硬件加速快、ChaCha20-Poly1305 软件高效抗侧信道、nonce 唯一性至关重要。区分两者性能场景。

• RSA 与 ECC 的密钥长度与安全强度
• ECC 优势：更短密钥、更快、前后兼容
• Ed25519（签名）与 Curve25519（X25519，密钥交换）

RSA 与 ECC 是两类非对称方案，工程取舍主要看"安全强度、性能、密钥长度、生态"。RSA：基于大整数分解，成熟、生态广泛，但需足够长度（如今最低 2048 位，推荐 3072/4096 位）才能保证安全，密钥大、加解密（尤其签名）较慢、且对量子攻击也更脆弱。ECC（椭圆曲线）：基于椭圆曲线离散对数，同等安全强度下密钥更短（如 256 位 ECC 约等于 3072 位 RSA），计算更快、带宽更省，是现代推荐。其中 Ed25519 是 EdDSA 签名方案（基于 Curve25519 的签名变体），签名快、密钥短、抗侧信道、确定性；Curve25519 用于密钥交换（X25519）。工程取舍：新系统优先使用 ECC（Ed25519/X25519），以获得短密钥、高性能与抗量子裕度；RSA 仍大量用于兼容旧系统（如旧的证书、签名）；对多种算法混用需注意协议兼容性（如 TLS 证书、JWT 签名算法）。现代最佳实践大多倾向 Ed25519 签名与 X25519 密钥交换。

取舍核心是"同强度下 ECC 密钥更短更快、更现代"。答题强调"同等安全强度 ECC 密钥更短、Ed25519 签名/X25519 交换是被推荐现代选择、RSA 用于兼容旧系统"。

• KMS/Vault 的定位：集中密钥管理
• 动态密钥：临时/短时凭证（如数据库动态密码）
• 按需获取：应用运行时从 Vault 拉取，替代静态配置

密钥管理系统（云 KMS、HashiCorp Vault、AWS Secrets Manager 等）用于集中、安全地管理密钥，应用通过"按需获取"替代把密钥硬编码或静态配置在代码/环境变量中。集成方式：应用启动或运行时调用 Vault/KMS API 获取密钥（认证后），密钥不在源码、配置文件中出现，密钥泄露面被缩小。Vault 的"动态密钥"是其显著优势：可为数据库、云服务、SSH 动态生成"临时凭证"（如数据库连接密码，带 TTL 自动过期），应用在用完即失效，避免长期静态密钥；即使凭证泄露，也因 TTL 短而风险可控。按需获取还支持：密钥轮换（应用重启后自动拿到新密钥）、细粒度访问控制（Vault 策略限制谁可读哪个密钥）、审计日志（追踪访问）。相比静态配置（硬编码/环境变量），集中密钥管理提供了"加密存储、动态/短时凭证、访问控制、审计、自动轮换"五大能力。工程上用 External Secrets Operator 等把 Vault 密钥注入 Kubernetes，或引入 SDK 在应用内按需获取。

核心是"密钥从静态配置迁移到集中动态管理"。答题强调"动态/短时凭证 + 按需获取 + 访问控制 + 审计 + 轮换"。硬编码凭证（CWE-798）类风险的核心缓解手段也是把密钥从静态配置迁移到集中动态管理。

• 信封加密：数据密钥（DEK）加密数据 + 主密钥（KEK）加密 DEK
• 主密钥轮换的代价
• 信封加密解耦使轮换高效

密钥轮换（rotation）指定期更换密钥以降低泄露影响、满足合规。信封加密（envelope encryption）是一种"分层加密"架构：用数据密钥（DEK）加密实际数据，再用主密钥（KEK）加密 DEK，密文 = 加密数据 + 加密的 DEK。用户只持有/管理 KEK（由 KMS 管理），DEK 可每次生成或短期复用。信封加密的核心价值在于"主密钥轮换无需重加密全部数据"：由于数据本身由 DEK 加密，轮换 KEK 时只需用新的 KEK 重新加密 DEK（用新 KEK 加密 DEK 得到新 envelope），而数据本身无需重新加密——只有 DEK 的"包装"被更新。相比"直接用一个密钥加密所有数据"（轮换要全量重加密），信封加密把"轮换代价"从"全量数据"降到"仅重新加密 DEK/元数据"，大幅提升轮换效率与可行性。密钥分层还可实现"细粒度密钥、最小权限、按密钥分类"。

信封加密的关键是"数据由 DEK 加密、DEK 由 KEK 加密"的分层。轮换 KEK 只重加密 DEK，数据不动，这是"高效轮换"的答案。答题要讲清 DEK/KEK 两层与解耦收益。

• git-secrets 等钩子拦截硬编码密钥提交
• External Secrets Operator 从 Vault 注入 K8s
• CI 变量遮蔽（mask）防止日志泄露

"secrets 不入库"是防止密钥泄露的工程底线，主要有三类手段：1）提交前拦截——git-secrets（AWS Labs）、trufflehog、gitleaks 等工具作为 git pre-commit 钩子或 CI 扫描，扫描代码中是否含疑似密钥（AWS 密钥、私钥、密码模式），命中即阻止提交，防止密钥进入版本历史；2）运行时注入——External Secrets Operator（ESO）在 Kubernetes 中把 Vault/AWS Secrets Manager 等外部密钥同步为 K8s Secret，使应用通过 Secret 挂载/注入获取密钥，源码和配置文件里不含真实密钥；3）CI 变量遮蔽（mask）——CI 平台（GitHub Actions、GitLab CI）提供"掩蔽"能力，把密钥定义为 masked 变量，日志中输出会被自动替换为 ***，防止密钥在构建日志中泄露；同时配合 CI 变量加密存储、不打印秘密。此外还有：.gitignore 排除密钥文件、密钥扫描历史提交、仓库泄露后立即轮换。三者构成"提交前拦截 + 运行注入 + 日志保护"的完整防线。

答题要点是"防上库（git-secrets）、防运行泄漏（ESO 注入）、防日志泄漏（mask）"三类手段的配合。强调"secrets 与代码分离 + 多层防泄露"。

• 各密钥长度的安全强度
• 量子计算疑虑对 256 的偏好
• 性能差异（AES-NI 下接近）

AES 支持 128、192、256 位三种密钥长度。安全强度：128 位已提供 2^128 的安全性，面对经典暴力破解已足够；192 位与 256 位提供更高强度，256 位在考虑"量子攻击（Grover 算法将密钥强度减半）"时被更推荐，是许多合规标准（如等保、联邦机构）要求用于敏感数据。性能：在通用 CPU 上，密钥长度增加会略微增加轮数（128→10 轮、192→12 轮、256→14 轮），但现代 CPU 有 AES-NI 硬件加速，三种长度的加解密性能差异很小，可忽略不计。工程取舍：一般数据 128 位已足够；对高敏感、长生命周期、面向未来的数据，优先 256 位；同时结合密钥管理与轮换。注意"密钥长度"与"算法/模式"无关，AES 的强度还取决于密钥的随机性与管理。现代实践普遍倾向 AES-256（尤其云 KMS 默认）。

取舍是"安全强度 vs 性能"。AES-NI 使性能差异忽略，256 位因量子裕度与标准要求更受青睐。答题强调"128 已够用、256 更面向未来、性能差异可忽略"。

• IV/nonce 的作用：提供随机性避免相同明文产生相同密文
• 重用 IV 的危害
• 生成与管理 IV 的实践

IV（初始化向量，或 nonce）用于保证加密的随机性：即使加密相同明文，使用不同 IV 也会产生不同密文，从而防止攻击者通过密文相同推断明文关系。IV 的"唯一性"至关重要——在 CTR 加密流类模式（GCM、CTR、ChaCha20）中，重用 IV 会直接导致密钥流重用，攻击者可对两条密文做 XOR 得到两个明文的 XOR，进而破解明文；在 GCM 中 IV 重用甚至可能泄露认证密钥（GHASH），导致严重的认证破解。因此绝不可重用 IV。生成实践：IV 应使用加密安全随机数生成器（CSPRNG）随机生成，或使用单调递增计数器（但需确保不回溯、不重复），其长度与算法要求匹配（GCM 推荐 12 字节）。IV 不必保密（可随密文一起存储），但必须唯一。密钥管理上，更换密钥时也可降低 IV 碰撞概率。工程上：优先使用成熟库的默认随机 IV 生成，避免手工计数。

核心是"IV 必须唯一，重用会导致密钥流重用/认证失败"。答题强调"随机+唯一、GCM 的 12 字节、IV 不保密但必唯一"。这是 AEAD 使用的最重要注意点。

• 对称加密处理数据加密（快），非对称处理密钥交换/签名
• 混合加密（hybrid）方案
• 选型原则

对称与非对称加密各有用途，工程上常"混合使用"（hybrid cryptography）。对称加密（如 AES）速度快，适合大批量数据加密，但需解决密钥分发问题；非对称加密（RSA、ECC）速度慢，但公钥可公开，适合密钥交换、数字签名与加密小数据。典型混合方案（如 TLS 的密钥交换）：用非对称（ECDHE 等）协商/交换对称会话密钥，再用对称加密（AES-GCM/ChaCha20）加密实际数据。选型原则：加解密数据用对称（AES-GCM 等 AEAD）；密钥交换/协商用非对称（ECDHE/X25519）；签名用非对称（Ed25519/ECDSA/RSA）；存储小量敏感配置可用非对称加密（如 RSA-OAEP 加密会话密钥）。非对称中，ECC 因密钥短、性能好在现代优先于 RSA（RSA 用于兼容旧系统）。核心是"非对称解决密钥分发与认证，对称解决数据加密，二者结合"。

选型核心是"非对称管密钥分发/签名，对称管数据加密，混合用"。答题强调"混合加密 + 各司其职 + ECC 优先"。

• GCM：AEAD，认证加密
• CBC：分组 + 填充，无认证
• CTR：流式计数器，无认证

分组模式决定如何用分组密码（如 AES）加密多块数据。CBC（Cipher Block Chaining）：每个明文块与前一个密文块异或后再加密，引入填充（padding），需 IV，安全性好但无认证（需配合 MAC），且填充可能引发 Padding Oracle 攻击；抗并行加密。CTR（Counter）：把计数器加密后与明文异或，形成流式加密，可并行、无需填充，但同样无认证（需配合 MAC）。GCM（Galois/Counter Mode）：基于 CTR 作计数器加密，并加入 GHASH 认证标签，属于 AEAD——同时提供机密性与完整性认证，无需额外 MAC，是推荐的现代模式。工程取舍：优先使用 GCM（AEAD，认证+加密一体）；若必须用 CBC/CTR，必须自行附加认证（HMAC）并处理填充与 IV；避免使用 ECB（相同明文产生相同密文，不安全）。GCM 的注意点是 IV 唯一性与 tag 校验。现代 TLS、数据加密普遍用 GCM（或 ChaCha20-Poly1305）。

关键区别是"是否认证（AEAD）"。GCM 认证加密一体化，CBC/CTR 无认证需补 MAC。答题强调"GCM 优先、避免 ECB、CBC/CTR 需认证"。

• 数据由 DEK 加密，主密钥只加密 DEK
• 轮换主密钥只需重加密 DEK
• 数据、DEK、KEK 三层解耦

信封加密的"数据—数据密钥（DEK）—主密钥（KEK）"三层结构使主密钥轮换无需重新加密全部数据。原理：实际数据由 DEK 加密，DEK 又由 KEK（主密钥）加密。轮换主密钥 KEK 时，数据本身保持不变（仍由原 DEK 加密），只需把 DEK 用新的 KEK 重新加密一次（生成新的 envelope 包装），即"用新主密钥重新包装 DEK"。由于 DEK 是唯一的、反复可用的，而 KEK 只负责"包装" DEK，因此轮换代价从"全量重加密所有数据"降为"只需重加密 DEK（元数据级）"。这也允许 KMS 在不解密数据的情况下完成轮换（KMS 只对 DEK 做加解密，数据仍在客户端加密）。结果：轮换高效、可频繁执行、数据停机最小化，且每份数据可关联不同版本 DEK，便于细粒度密钥管理。这是信封加密在云 KMS 中广泛采用的原因。

核心是"分层解耦"——轮换只影响包裹层（DEK 的加密），不影响数据层。答题要讲清 DEK/KEK 两层与"重新包装 DEK"这一关键动作。

• 集中密钥管理（KMS/HSM）
• 定期轮换与生命周期
• 安全存储与访问控制

密钥管理的工程要点包括：1）集中管理——使用 KMS/HSM/Vault 集中生成、存储、加解密密钥，密钥与数据分离，避免散落在代码与配置中；2）安全存储——密钥加密存储于受控环境（HSM 硬件或 KMS 托管），遵循最小权限与访问控制（仅授权应用/人可以访问），并做访问审计；3）轮换——制定定期轮换策略（按时间或按操作量），支持自动轮换与紧急吊销，泄露时可立即轮换；轮换结合信封加密可高效完成（只重加密 DEK）；4）生命周期——覆盖生成、分发、使用、备份、归档、销毁全流程，销毁要不可恢复（含备份副本）；5）密钥隔离——按用途分密钥（加密、签名、MAC 分开），按环境分密钥（生产/测试），避免密钥复用；6）备份与恢复——安全备份密钥以防丢失，同时保证备份受同等保护。现代实践强调"密钥永不离开 HSM/KMS、自动轮换、集中审计"。

密钥管理要点是"集中 + 隔离 + 轮换 + 生命周期 + 审计 + 备份"。答题要覆盖"KMS 集中、定期轮换、安全存储、最小权限"等方面。

• 环境变量：简单但非安全存储
• 保险库：集中、加密、动态密钥
• 取舍与最佳实践

处理秘密需区分"环境变量"与"保险库（Vault）"的边界。环境变量：简单、易用、跨平台，适合非敏感或易轮换的配置（如 API 密钥、非生产值），但环境变量本身不加密、可能被进程/日志/容器镜像泄露，且难以审计与轮换，不适合高风险秘密。保险库（Vault/KMS/Secrets Manager）：集中加密存储、细粒度访问控制、动态/短时密钥、自动轮换、审计日志，适合高敏感、长期、需要可控的密钥（数据库密码、云凭证、签名密钥）。工程最佳实践：优先用保险库存放敏感秘密并以"按需获取"方式注入；环境变量仅用于低敏感、易轮换的配置；在容器/K8s 场景用 External Secrets Operator 把保险库秘密注入为 Secret；避免把秘密硬编码、写进日志或提交到仓库；对必须暂时放环境变量的秘密，也要遮蔽并尽快迁移到保险库。原则是"秘密越敏感，越应集中管控"。

取舍是"简单 vs 安全可控"。答题强调"环境变量适合低敏感，保险库适合高敏感并支持动态/审计/轮换"，并给出边界。

• 哈希：无密钥，用于完整性校验、密码存储（加盐慢哈希）
• MAC：带密钥，用于完整性+认证
• 区别：是否有密钥、是否认证

哈希与 MAC 都用于"完整性"，但有无密钥是核心区别。哈希（如 SHA-256）：无密钥，任何人都能计算，用于校验数据是否被篡改（检测到改动则摘要变化），但无法认证"谁生成的数据"；密码存储用"加盐慢哈希"（bcrypt/scrypt/Argon2）而非普通哈希，因为普通哈希太快、易被暴力破解。MAC（消息认证码，如 HMAC）：带密钥，只有持有密钥的双方能计算和验证，用于"完整性 + 认证"（数据未被篡改且来自可信来源），常用于防篡改、防伪造（如 JWT 的 HS256 签名本质是 HMAC）。区别：哈希无密钥（仅防篡改）、MAC 有密钥（防篡改+认证来源）。工程上：普通数据完整性校验用哈希；需要认证来源/防伪造时用 MAC/签名；密码必须用加盐慢哈希；注意"哈希不能用于认证，MAC 不能用于密码存储"。

关键区别是"是否有密钥、是否认证"。答题强调"哈希无密钥防篡改、MAC 带密钥防篡改+认证、密码用加盐慢哈希"。

• 协议版本：TLS 1.2/1.3，禁用旧版
• 密码套件：优先 AEAD、ECDHE、PFS
• 禁用弱套件与配置要点

TLS 配置的核心是"协议版本 + 密码套件"的现代化。协议版本：优先 TLS 1.3（支持前向保密、更快的握手、更安全的套件），兼容 TLS 1.2，禁用 TLS 1.0/1.1 及 SSL（已过时、有已知漏洞，如 POODLE、BEAST）。密码套件：优先选择 AEAD 认证加密（AES-GCM、ChaCha20-Poly1305）+ 前向保密（ECDHE 临时密钥交换）+ 强签名（ECDSA/Ed25519）；禁用静态 RSA 密钥交换（无 PFS）、RC4/DES/3DES（弱算法）、MD5/SHA-1 签名（弱哈希）、CBC 模式（填充攻击风险）。配置要点：证书链完整、密钥强度足够（RSA 2048+ 或 ECC 256+）、证书有效期与吊销检查、HSTS 强制 HTTPS、禁用不安全的压缩与重协商。可参考 Mozilla SSL Config Generator 等生成推荐配置。现代 TLS 1.3 默认套件已满足安全要求，运维重点是"禁用旧版与弱套件"。

TLS 配置要点是"TLS 1.3/1.2 + AEAD + ECDHE（PFS）+ 禁弱套件"。答题强调"版本升级 + 套件现代化 + 禁用旧版/弱算法"。