密码学基础:对称加密与非对称加密、哈希函数、数字签名

各位好,欢迎来到第二章。今天聊的是密码学基础——联邦学习的“地基”。说实话,我当年刚入行时,觉得密码学就是数学公式堆砌。

直到自己动手搭联邦学习系统,才意识到:少了这些基础,隐私保护就是个空壳。咱们一步步来。

2.1 对称加密:又快又简单,但有个“死穴”

对称加密,说白了就是通信双方用同一把钥匙开锁。

你加密,我解密,用的密钥一模一样。

典型算法:

  • AES(Advanced Encryption Standard):当前工业标准,128/192/256位密钥。我在联邦学习项目里就常用AES-256来加密中间参数。
  • ChaCha20:流密码,移动端性能极佳。我曾在一些资源受限的边缘设备上用它替代AES,吞吐量翻了一倍。

核心痛点:密钥分发问题。

你想想,如果双方事先要共享密钥,那这个共享过程本身就容易被窃听。

我在项目中遇到过:两个数据方第一次协作,跑的是FTP传密钥。结果密钥文件被中间人截获,整个加密形同虚设。嗯,后来换成了TLS通道传密钥。

我的实践建议:

联邦学习里,参数加密流量很大,CPU做AES会成瓶颈。建议用带AES-NI指令集的CPU,加解密能快5-10倍。

坑位预警:

我曾经直接用ECB模式加密过模型梯度。结果同一批次梯度出现了重复模式,对方通过统计分析猜出了数据分布。

记住:不要用ECB模式!用CBC、GCM或CTR模式,并且每次加密都加随机IV。

2.2 非对称加密:告别密钥分发噩梦

非对称加密的原理,举个例子:你有个“公钥”可以公开,别人用它加密消息发给你;你拿“私钥”解密,私钥只有你自己知道。

这就解决了密钥分发问题。

主流算法:

算法 密钥长度 特点 我在联邦学习中的用法
RSA 2048/4096位 成熟、广泛支持 交换AES密钥
ECC(椭圆曲线) 256位(等效RSA 3072位) 短密钥、高性能 密钥协商 + 数字签名
SM2(国密) 256位 国内标准,合规要求 合作方有合规要求时使用

关键洞察:

联邦学习中,非对称加密主要用于密钥协商阶段。一旦双方协商出共享密钥,后续大数据量的梯度交换就会切换到对称加密。

因为非对称加密实在太慢了——RSA加密1MB数据比AES慢了上千倍。

我自己常用的流程是:先ECC协商出会话密钥,然后用AES-256-GCM加密模型更新。既安全又高效。

2.3 哈希函数:不可逆的“数字指纹”

哈希函数的特点:输入任意长度数据,输出固定长度的摘要。

核心属性:单向性——从摘要反推原文,基本不可能。

常用哈希:

  • SHA-256:输出256位。联邦学习里验证参数完整性时,我经常用它。
  • SHA-3:新一代标准,安全性更高。政府项目中用得多。
  • SM3:国密标准,输出256位。国内银行和政务场景必须用。

抗碰撞性是什么? 就是几乎不可能找到两个不同的输入,却产生相同的哈希值。

我遇到过哈希碰撞的场景吗?还真有,但不是真碰撞而是实现bug——两个不同整数被转成字符串时格式不一致,导致哈希碰撞了。后来直接从字节数组层面去做哈希,问题解决。

千万别踩的坑:

不要在哈希函数里拼接敏感数据。比如:hash(user_id + password)。一旦两个用户ID和密码有重叠模式,就可能被彩虹表攻击。

正确做法是使用HMAC(基于哈希的消息认证码),带上密钥一起计算。联邦学习里验证参数一致性时,我永远用HMAC-SHA256。

2.4 数字签名:确认“你是谁”和“你没改过”

数字签名的作用就两个:身份认证和完整性保障。

流程很简单:

  1. 发送方用私钥对消息或消息的哈希值签名。
  2. 接收方用发送方的公钥验签。

如果验签通过,代表消息确实是对方发的,而且中途没被篡改。

我在联邦学习里怎么用? 每个参与方在上传本地模型更新时,都会附上数字签名。聚合服务器验签后才接受。这能防止恶意节点伪造梯度。

主流签名算法:

算法 基础 签名大小 特点
RSA-PSS RSA 256字节 成熟,性能适中
ECDSA ECC 64字节 签名更小、更快
Ed25519 Edwards曲线 64字节 极快、抗侧信道
SM2签名 SM2椭圆曲线 64字节 国密标准

个人习惯: 新项目我基本只用Ed25519。签名小、速度快、实现稳定。唯一例外是遇到国密要求的客户,才会切到SM2。

联邦学习里的典型签名流程:

  • 参与方A:计算梯度 grad 的哈希 h = SHA256(grad),私钥签名 sig = Sign(private_key, h),发送 (grad, sig)。
  • 聚合服务器:用A的公钥验签 Verify(public_key, SHA256(grad), sig),通过则接受,拒绝则丢弃该梯度。
  • (可选)记录这次签名的唯一ID,防止重放攻击。

2.5 再看联邦学习——为什么必须组合使用?

有人问:能不能只用非对称加密解决所有问题?

答案:不行。原因有二:

  • 性能瓶颈:非对称加密加解密太慢。联邦学习里参数更新频繁,全用非对称加密,训练时间会翻10倍以上。
  • 安全需求维度不同:你需要加密(对称/非对称)、需要完整性校验(哈希)、需要身份认证(数字签名)。单一工具搞不定。

最危险的误解:

不要自己发明哈希函数或数字签名组合方案。直接用SHA-3、ECDSA这些标准方案——虽然不够“酷”,但安全。

我曾经有个同事,为追求“效率”自己拼了个签名方案,结果被分析出安全漏洞。那段时间我们紧急换了整套密钥体系,代价巨大。

我习惯把这四种工具看成联邦学习安全体系的四块积木:对称加密负责速度快,非对称加密负责密钥分发,哈希负责完整性,数字签名负责身份认证。

缺任何一块,系统都会有隐患。

2.6 整体知识结构

下面这张图能帮你快速建立起整体框架:

密码学基础 · 联邦学习场景下的四块积木 对称加密 密钥共享 | 高速加解密 非对称加密 公钥/私钥 | 密钥协商 哈希函数 数字指纹 | 完整性校验 数字签名 身份认证 + 完整性 联邦学习隐私保护实践 参数加密 · 梯度验证 · 身份确认 密钥协商阶段 ECC + AES 混合加密 梯度交换阶段 AES-GCM + HMAC 聚合验证阶段 数字签名验签 核心原则:一个工具不够,四种组合才安全

这张图想传达一个简单道理:联邦学习的隐私保护不是靠某一个密码学工具硬扛,而是靠组合拳——每种工具解决一个不可替代的问题。

对称加密保证速度,非对称加密搞定密钥分发难题,哈希函数确保数据没被篡改,数字签名锁死身份认证。四者协同,才能构成一个可落地的安全体系。

好,这一章就到这里。对密码学基础有了整体认知,接下来就能更顺畅地理解联邦学习里的密钥协商协议到底是怎么运作的。