4. 传统RSA/ECC轮换策略回顾：基于时间的轮换、基于事件的轮换、混合轮换

聊PQC适配之前，咱们得先把老本行捋清楚。RSA和ECC的密钥轮换，说白了就是「什么时候换钥匙」的问题。我在好几个金融项目里见过，有人把密钥用到过期才想起来换，结果业务中断了一小时。嗯，这种坑咱们今天先填上。

传统轮换策略分三种：基于时间、基于事件、混合。你想想看，它们各自适合什么场景？我带你过一遍。

4.1 基于时间的轮换

这是最朴素的做法。定个周期，到期就换。比如每90天换一次TLS证书，或者每30天轮换一次API签名密钥。

我在一个支付网关项目里用过这种策略。当时合规要求：交易签名密钥必须每季度轮换一次。我们直接写了个cron job，每90天凌晨3点自动生成新密钥对，推送到所有节点。

优点很明显：简单、可预测、审计友好。缺点呢？如果密钥在轮换前就泄露了，你只能干瞪眼等到下一个周期。

参数	典型值	适用场景
轮换周期	30天 / 90天 / 1年	TLS证书、代码签名
宽限期	7天（新旧共存）	API签名、JWT签发
自动触发	Cron / 定时任务	内部系统、微服务

4.2 基于事件的轮换

这种策略不按时间走，而是按「发生了什么事」来触发。比如：

• 检测到密钥泄露（比如日志里出现异常签名）
• 员工离职（特别是拥有私钥的管理员）
• 系统架构变更（比如从单体拆成微服务）
• 算法被攻破（比如SHA-1碰撞攻击）

我曾经在一个政务云项目里遇到过：某天监控告警说CA私钥被异常访问了。我们立刻启动了事件驱动轮换，30分钟内完成了密钥吊销和新密钥分发。要是等时间轮换，黄花菜都凉了。

实现上，事件轮换需要一套监控体系。比如：

# 伪代码：事件驱动的密钥轮换触发器
def on_key_compromise_alert(key_id):
    revoke_key(key_id)
    new_key = generate_key()
    distribute_key(new_key)
    log_event("Key rotated due to compromise", key_id)

这里有个坑：事件检测的延迟。我记得有一次，从日志异常到触发轮换，中间隔了15分钟。攻击者完全可能在这段时间内用泄露的密钥做坏事。所以事件轮换的响应速度，决定了它的有效性。

4.3 混合轮换

说白了，就是把时间和事件结合起来。这是生产环境里最常用的策略。

我参与过的一个大型电商平台，密钥管理策略是这样的：

1. 基线轮换：每90天自动换一次（时间驱动）
2. 应急轮换：检测到异常时立即换（事件驱动）
3. 灰度切换：新旧密钥共存48小时，逐步切流量

为什么这么做？因为纯时间轮换太死板，纯事件轮换又可能漏掉「没被检测到的风险」。混合策略相当于上了双保险。

下面这张图展示了混合轮换的决策流程：

4.4 三种策略的对比

我整理了一张表，方便你对照选型：

维度	时间轮换	事件轮换	混合轮换
触发条件	固定周期	安全事件/变更	周期 + 事件
可预测性	高	低	中
安全性	中（有窗口期）	高（及时响应）	高
运维复杂度	低	高（需要监控）	中
典型场景	TLS证书、代码签名	CA私钥、管理员密钥	生产环境通用

4.5 传统策略的局限性

嗯，说到这里，我得泼点冷水。这些传统策略在RSA/ECC时代够用，但到了PQC时代，有些地方就不太灵了。

• 密钥尺寸暴增：RSA 2048位的轮换成本，和Kyber-1024的轮换成本，完全不是一个量级。你想想看，传输和存储开销大了10倍以上。
• 混合模式需要双倍密钥：PQC过渡期，你得同时维护传统密钥和PQC密钥。轮换策略得同时管两套。
• 事件检测更难：PQC算法刚出来，攻击面还不完全清楚。你很难判断「什么时候该触发事件轮换」。