Workerman中AES密钥严禁硬编码，须动态生成、RSA加密后分发至客户端，并存入Redis按token缓存且设15分钟过期；同时必须启用WSS传输层加密与应用层AES双重保护，RSA需用OAEP填充、2048位以上密钥，服务端解密失败应返回模糊错误而非明示密钥无效。
Workerman里不能把AES密钥硬编码在代码或配置中
直接写死 $aesKey = 'my-secret-32-byte-key' 是最常见也最危险的做法。一旦代码泄露、服务器被入侵或通过调试信息暴露，整个加密体系就形同虚设。
真正可行的路径是：密钥必须动态生成、按需分发、生命周期可控。Workerman本身不提供密钥管理服务，它只负责通信——所以密钥的生成、加密、传递和缓存，全得由你控制。
- 登录成功后，服务端用
RSA公钥加密一个临时AES密钥（比如 32 字节随机值），连同IV一起返回给客户端 - 服务端将该密钥对（
key+iv）以token为 key 存入 Redis 或内存缓存，设置合理过期时间（如 15 分钟） - 后续每次请求都带
token，服务端从缓存取密钥解密，不用每次都重新生成或查库 - 禁止把密钥存在
$_SESSION或全局变量里——Worker 进程常驻，$_SESSION不生效，全局变量跨连接不隔离
用RSA加密AES密钥时，必须用PKCS#1 v1.5或OAEP填充
PHP 的 openssl_public_encrypt() 默认使用 PKCS#1 v1.5 填充，但这个模式有理论上的选择密文攻击风险。生产环境建议强制用 OAEP（需要 PHP 7.2+ 和 OpenSSL 1.0.1+）。
错误示范：openssl_public_encrypt($aesKey, $encrypted, $publicKey) —— 没指定填充方式，且未检查返回值是否为 true，失败时 $encrypted 可能为空字符串，导致客户端解密失败却无报错。
- 务必显式指定
OPENSSL_PKCS1_OAEP_PADDING：openssl_public_encrypt($aesKey, $encrypted, $publicKey, OPENSSL_PKCS1_OAEP_PADDING) - RSA 密钥长度至少 2048 位；若用 1024 位，现代算力可在数小时内破解
- 加密前确认
$aesKey长度 ≤ RSA 密钥长度限制（2048 位公钥最多加密约 214 字节明文）——而 AES-256 密钥才 32 字节，完全够用
传输层（WSS）和应用层（AES）加密必须同时启用，不能二选一
只开 wss:// 不等于安全。TLS 被降级、证书被绕过、中间人装了恶意根证书，或者客户端信任了自签名证书，TLS 层就可能失效。这时候如果消息还是明文，敏感数据就裸奔了。
只做应用层 AES 加密也不行：没有 TLS，密钥交换过程（比如登录时返回加密后的 AES 密钥）本身就被监听，攻击者拿到加密后的密钥和密文，再暴力破解 RSA 就能还原出 AES 密钥。
- Workerman 启动时必须设置
$worker->transport = 'ssl'，协议地址用wss://或ssl://，并传入正确local_cert和local_pk - 客户端必须校验服务端证书（即不设
verify_peer => false），否则无法防中间人 - 应用层 AES 加密应只针对真正敏感字段（如密码、金额、身份证号），不是所有消息都套一层——避免无谓性能损耗和 IV 管理复杂度
Workerman中AES密钥轮换和失效处理容易被忽略
很多团队实现了一次登录发密钥，之后长期复用，既不更新也不主动失效。这放大了密钥泄露后的危害范围。
更现实的做法是：密钥与会话绑定，且支持主动吊销。例如用户登出、修改密码、检测到异常登录时，立刻从缓存删掉对应 token 的密钥对。
- 不要依赖客户端“自觉”清除本地密钥——它可能被截获、重放、复用
- 服务端解密失败时，别直接返回
Invalid key这类提示，应统一返回模糊错误（如400 Bad Request），防止攻击者试探密钥有效性 - 定期（如每 24 小时）让活跃会话刷新密钥：客户端收到特定指令后，用旧 AES 密钥解密新密钥包，再切换使用
