使用混合 RSA、AES 和 HMAC SHA-256 发送加密消息

信息安全 加密 哈希 AES RSA hmac
2021-09-04 01:14:18

这是使用混合 RSA 2048、AES 256 发送大型加密消息并使用 HMAC SHA-256 进行身份验证的安全策略：

鉴于 Alice 已经拥有 Bob 的 RSA 公钥，Alice：

  1. 生成新的 128 位IV（强 PRNG）
  2. 生成新的 AES 256bit/CBC/PKCS7 加密密钥(Kc)
  3. 生成一个新的 AES 256bit/CBC/PKCS7 Auth Key (Ka)
  4. 用(Kc)和IV => (M)e加密她的消息 + 时间戳
  5. 进行认证IV +（M）在线与（KA）使用HMAC SHA-256 => IV +（M）E +标签
  6. 用 Bob 的 RSA 公钥加密(Ka)+(Kc)，并用 OAEP => (Kc+Ka+P)e填充
  7. 进行认证（的Kc +嘉+ P）在线与（KA）使用HMAC SHA-256 => IV +（+的Kc嘉+ P）E +标签
  8. 发送 Bob RSA 加密IV+(Kc+Ka+P)e+Tag和 AES HMAC-256 消息IV+(M)e+Tag

然后鲍勃继续：

  1. 从IV+(Kc+Ka+P)e+Tag 中提取IV
  2. 根据 nonce 缓存检查IV，拒绝重复 IV 的消息
  3. 用他的 RSA 私钥提取和解密(Kc+Ka+P)e => (Ka)+(Kc)
  4. 用(Ka)验证IV+(Kc+Ka+P)e+Tag，拒绝无效消息
  5. 用(Ka)验证IV+(M)e+Tag，拒绝无效消息
  6. 用(Kc)解密IV+(M)e+Tag
  7. 提取时间戳和消息
  8. 验证时间戳不早于 Max Request Age，拒绝过期消息

基本上想知道上述混合 RSA/AES/HMAC SHA-256 方法是否有任何明显的弱点，或者任何人会做不同的事情？

上述策略已经过修改，以包含@puzzlepalace 的反馈，即创建单独的 AES 密钥用于加密和验证，而不是从主密钥的 SHA-512 哈希中派生它们。

欢迎任何其他反馈或改进建议！

1个回答

我将逐步介绍整个加密系统，这对我来说似乎是最合乎逻辑的。

  1. 生成新的 AES 256bit/CBC/PKCS7 主密钥 (Km)
  2. 生成新的 128 位 IV（强 PRNG）

CBC 在这里很好，因为攻击者无法访问任何类型的预言机，并且标签排除了位翻转攻击。随机 IV 是正确的，256 位对于密钥大小来说绰绰有余。

  1. 生成 (Km) => (Hm) 的 SHA-512 哈希
  2. 将 (Hm) 拆分为 Crypt Key => (Kc) 和 Auth Key => (Ka)

这应该没问题。一条评论，我实际上不熟悉通过哈希扩展的主密钥（所以如果这被认为是最佳实践，请纠正我），你有什么理由不只生成两个 256 位密钥？我想说，除非你真的需要在网络上保存数据包大小，否则为什么不只生成两个 256 位密钥，一个用于 AES，一个用于 HMAC？网络上仅多出 256 位。

  1. 用 (Kc) 和 IV => (M)e 加密她的消息 + 时间戳
  2. 使用 HMAC SHA-256 用 (Ka) 符号 (IV)+(M)e => (IV+(M)e+Tag)

这很好，Encrypt-then-MAC 是 IND-CCA（即最好的通用结构）。挑剔的注意事项：HMAC 不是签名，而是标签。（标签提供完整性和真实性，签名也提供不可否认性）。

  1. 用 Bob 的 RSA 公钥加密 (IV+Km)，并用 OAEP => (IV+Km+P)e 填充
  2. 发送 Bob RSA 加密的 AES 密钥 (IV+Km+P)e 和签名的 AES 消息 (IV+(M)e+Tag)

OAEP 是 RSA 填充的不错选择，并且是 IND-CCA，我认为这里没有问题。

在我看来，您的对称和非对称方案都不容易受到选择的密文攻击，这是非常安全的。因此，我不认为在 RSA 和 AES 密文中加密相同的 IV 是一个问题。特别是因为 IV 在 CBC 模式下甚至不必保密（它只是不可预测或重复使用！），因此可以明文发送（也许通过将明文 IV 附加到 AES 密文并计算 MAC那）。然后它也不必在收件人公钥下加密。

希望对您有所帮助，很高兴澄清或扩展您有任何疑问！

其它你可能感兴趣的问题
上一篇Docker 容器、环境变量和数据库 下一篇撤销密钥后验证加密签名文件