如何将 AES 初始化向量传递给混合密码系统的客户端

发布于 2024-08-07 19:14:00 字数 604 浏览 1 评论 0原文

我需要实现客户端-服务器通信的安全性。我已经实现了以下混合加密系统

为了在混合加密系统中加密发送给 Alice 的消息,Bob执行以下操作:

  1. 获取 Alice 的公钥。
  2. 为数据封装方案生成新的对称密钥。
  3. 使用刚刚生成的对称密钥在数据封装方案下加密消息。
  4. 使用 Alice 的公钥,在密钥封装方案下加密对称密钥。
  5. 将这两个加密发送给 Alice。

为了解密这个混合密文,Alice 执行以下操作:

  1. 使用她的私钥解密密钥封装段中包含的对称密钥。
  2. 使用该对称密钥来解密数据封装段中包含的消息。

我使用 RSA 作为公钥加密系统,使用 AES 作为对称密钥加密系统。一切正常,但我不确定如何处理 AES 初始化向量。目前,我正在连接 AES 密钥和初始化向量,用公钥对其进行加密并将其发送到服务器。

我只是想得到一些关于这种方法的意见。这个问题如何通过其他通信协议SSL等解决。

谢谢。

I need to implemented security for client-server communication. I have implemented the following hybrid cryptosystem

To encrypt a message addressed to Alice in a hybrid cryptosystem, Bob does the following:

  1. Obtains Alice's public key.
  2. Generates a fresh symmetric key for the data encapsulation scheme.
  3. Encrypts the message under the data encapsulation scheme, using the symmetric key just generated.
  4. Encrypt the symmetric key under the key encapsulation scheme, using Alice's public key.
  5. Send both of these encryptions to Alice.

To decrypt this hybrid ciphertext, Alice does the following:

  1. uses her private key to decrypt the symmetric key contained in the key encapsulation segment.
  2. uses this symmetric key to decrypt the message contained in the data encapsulation segment.

I am using RSA For a public-key cryptosystem, and AES for symmetric-key cryptosystem. Every thing works fine, but I am not sure how to handle AES initialization vector. Currently, I am concatenating the AES key and initialization vector encrypting it with the public key and sending that to server.

I just wanted to get some opinions about this approach. How this problem is solved by other communication protocols SSL etc.

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

甜点 2024-08-14 19:14:00

您不加密 IV。将其与加密密钥捆绑在一起并将其(以明文形式)发送给收件人。

这方面的标准确实存在。这种方案在 CMS(S/MIME 的基础)中称为“KeyTransRecipientInfo”,PGP 也提供类似的模式。 TLS 还包括初始化向量作为密钥加密算法标识符中的参数,使用与 CMS 相同的 ASN.1 语法。执行此操作的强大开源库可用于许多平台。

至少,研究 CMS 规范可能有助于避免自制实现中的一些陷阱。请参阅 RFC 3369 的第 6.1 节和第 6.2.1 节。

You don't encrypt the IV. Bundle it with the encrypted key and send it (in the clear) to the recipient.

Standards for this do exist. This scheme is called "KeyTransRecipientInfo" in CMS (upon which S/MIME is based), and PGP offers a similar mode. TLS also includes the initialization vector as a parameter in the key encryption algorithm identifier, using the same ASN.1 syntax as CMS. A robust, open-source library to perform this operation is available for many, many platforms.

At the very least, studying the CMS specification might help avoid some of the many pitfalls in a home-brew implementation. See §6.1 and §6.2.1 of RFC 3369.

無處可尋 2024-08-14 19:14:00

我做了同样的事情,并以相同的方式处理它 - 将 AES 密钥与 IV 连接起来并对它们进行加密。

您也可以只发送密钥并使用密钥本身生成 IV - 例如,使用密钥哈希的前 128 位作为 IV。只要您为每个会话生成新的 AES 密钥,而不是在相同的 IV 中一遍又一遍地重复使用相同的 AES 密钥,那么从安全角度来看,这应该是没问题的。

I've done the same thing, and I handled it the same way - concatenate the AES key with the IV and encrypt them both.

You could also just send the key and use the key itself to generate an IV - for example by using the first 128 bits of a hash of the key as the IV. That should be OK security-wise as long as you are generating a new AES key for each session and not re-using the same AES key over and over with the same IV.

┾廆蒐ゝ 2024-08-14 19:14:00

没有理由加密 IV - 您可以明文发送。只需确保每次都选择一个新密钥(与 AES 密钥的操作方式相同)。

也就是说,将 AES 密钥和 IV 打包在一起通常很方便。 16 字节的加密并不是那么昂贵。

There is no reason to encrypt the IV - you can send that in the clear. Just make sure you pick a new one each time (the same way you do the AES key).

That said, it is often convenient to package the AES key and IV together. Encryption of 16 bytes ain't that expensive.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文