是否存在二密钥对称交换加密函数?

发布于 2024-11-16 03:11:13 字数 217 浏览 2 评论 0原文

我想知道是否有一些强大的(如 AES 等)加密函数,其工作原理如下:

  • 对称
  • 2 键:纯文本 -> 2keys -> 密文,但是密钥的顺序无关紧要,即

Key1 (Key2 (plaintext)) == Key2 (Key1(plaintext)) 例如“可交换” (解密也需要 - 你需要两个密钥,顺序无关)

谢谢

I'm wondering if there is some strong (like AES or so.) encryption function that works like this:

  • symetric
  • 2 keys: plaintext -> 2keys ->ciphered text, however it must not matter order of keys, i.e

Key1 (Key2 (plaintext)) == Key2 (Key1(plaintext))
e.g. "commutative"
(also required for decryption - you need two keys, doesn't matter order)

thanks

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

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

发布评论

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

评论(4

睡美人的小仙女 2024-11-23 03:11:13

通过将任何块加密算法放入 CTR 模式,可以轻松完成此操作。单键点击率模式如下所示:

ciphertext = plaintext XOR cipher(key, counter)

计数器初始化为您的 IV 并为每个递增堵塞。解密是完全相同的操作。因此,如果您使用两个密钥进行 CTR 加密两次,您将得到:

ciphertext = plaintext XOR cipher(key0, counter) XOR cipher(key1, counter)

由于 XOR 是可交换的,因此您可以按任一顺序反转它。

这有一个很好的特性,即您不需要将所有密钥放在同一位置。考虑一下:Alice、Bob 和 Charlie 正在参与一个协议,其中 Charlie 将对 Alice 和 Bob 的数据进行双重加密(该协议将假设所有点对点通信都通过通常的类似 SSL 的通道进行保护):

  1. Alice 和 Bob执行经过身份验证的 Diffie-Hellman 交换来生成 IV。然后将该 IV 发送给 Charlie。
  2. Alice 为 ctr = 0...number-of-ciphertext-blocks 计算摘要(key0, IV + ctr),并将结果 KS_A 发送给 Charlie
  3. Bob 为 ctr = 0...number 计算摘要(key1, IV + ctr) -of-ciphertext-blocks,并将结果 KS_B 发送给 Charlie
  4. Charlie 计算 KS_A XOR KS_B XOR 明文,并将结果密文发送给 Alice 和 Bob。
  5. Alice 和 Bob 各自签署一个元组(IV、散列(密文)、加密数据描述)。这是附在密文后面的。

随后,要解密:

  1. Charlie(执行解密)将签名的 (IV, hash(ciphertext)) 元组以及密文发送给 Alice 和 Bob。
  2. Alice 验证他的签名元组,计算 KS_A,并将密文 XOR KS_A = D_A 发送给 Charlie
  3. Bob 验证他的签名元组,计算 KS_B,并将密文 XOR KS_B = D_B 发送给 Charlie
  4. Charlie 计算 KS = D_A XOR D_B = KS_A XOR KS_B
  5. Charlie 计算明文= 密文 XOR KS

这里签名元组和DH交换的目的是为了确保 Alice 和 Bob 不会通过向他们发送不同的 IV 来欺骗他们解密错误的流。这可能与您的使用场景无关。此外,在实际实现中,查理的角色可以由爱丽丝或鲍勃扮演。

如果您担心 CTR 模式的潜在安全风险,另一种选择是对会话密钥使用 CTR 模式加密,该会话密钥又用于以更正常的模式进行加密,例如 CBC。也就是说:

sessionkey = RANDOM
IV_0 = RANDOM
IV_1 = RANDOM
enc_sessionkey = sessionkey XOR cipher(key0, IV_0) XOR cipher(key1, IV_0)
ciphertext = enc_sessionkey + IV_0 + IV_1 + cipherCBC(IV_1, sessionkey, plaintext)

虽然其他一些发帖者对秘密共享发表了评论,但如果您不需要解密只需要密钥子集的属性,那么这就太过分了 - 即,通过秘密共享,您可以使用三个密钥进行加密,但只需要任意两个即可解密。如果您想需要所有密钥,那么秘密共享方案并不是真正必要的。

This can be easily done by putting any block encryption algorithm into CTR mode. CTR mode with a single key looks like:

ciphertext = plaintext XOR cipher(key, counter)

Where counter is initialized to your IV and incremented for each block. Decryption is exactly the same operation. As such, if you CTR-encrypt twice with two keys, you get:

ciphertext = plaintext XOR cipher(key0, counter) XOR cipher(key1, counter)

And since XOR is commutative, you can reverse it in either order.

This has the nice property that you don't need to have all keys in the same location. Consider: Alice, Bob, and Charlie are participating in a protocol in which Charlie will double encrypt data for both Alice and Bob (this protocol will assume all point-to-point communication is secured through usual SSL-like channels):

  1. Alice and Bob perform an authenticated Diffie-Hellman exchange to produce the IV. This IV is then sent to Charlie.
  2. Alice computes digest(key0, IV + ctr) for ctr = 0...number-of-ciphertext-blocks, and sends the result KS_A to Charlie
  3. Bob computes digest(key1, IV + ctr) for ctr = 0...number-of-ciphertext-blocks, and sends the result KS_B to Charlie
  4. Charlie computes KS_A XOR KS_B XOR plaintext, and sends the resulting ciphertext to both Alice and Bob.
  5. Alice and Bob each sign a tuple (IV, hash(ciphertext), description-of-encrypted-data). This is attached to the ciphertext.

Later, to decrypt:

  1. Charlie (performing the decryption) sends the signed (IV, hash(ciphertext)) tuples to each of Alice and Bob, as well as the ciphertext.
  2. Alice verifies his signed tuple, computes KS_A, and sends ciphertext XOR KS_A = D_A to Charlie
  3. Bob verifies his signed tuple, computes KS_B, and sends ciphertext XOR KS_B = D_B to Charlie
  4. Charlie computes KS = D_A XOR D_B = KS_A XOR KS_B
  5. Charlie computes plaintext = ciphertext XOR KS

The purpose of the signed tuple here and DH exchange is to ensure Alice and Bob can't be tricked into decryption the wrong stream by sending them a different IV. This may not be relevant in your usage scenario. Also, the role of Charlie may be played by Alice or Bob in a real implementation.

If you're worried about the potential security risks of CTR mode, one other option would be to use CTR-mode encryption on a session key, which in turn is used to encrypt in a more normal mode, such as CBC. That is:

sessionkey = RANDOM
IV_0 = RANDOM
IV_1 = RANDOM
enc_sessionkey = sessionkey XOR cipher(key0, IV_0) XOR cipher(key1, IV_0)
ciphertext = enc_sessionkey + IV_0 + IV_1 + cipherCBC(IV_1, sessionkey, plaintext)

Although some other posters have commented on secret sharing, this is overkill if you don't need the property that only a subset of keys are needed for decryption - ie, with secret sharing you might encrypt with three keys, but require only any two to decrypt. If you want to require all keys, secret sharing schemes aren't really necessary.

想念有你 2024-11-23 03:11:13

它不是交换加密,但有经过充分验证的秘密共享算法(请注意,这与“密钥协议”不同。)

其中两种最著名的方法是 Shamir 的和 Blakley 的。一般来说,这些算法采用秘密并产生许多“份额”。当有足够的可用份额达到阈值时,可以恢复秘密。最简单的情况,需要两份,但门槛可以更高。

为了简单地解释沙米尔的方法,请考虑图表上的一条线。如果你知道线上的任意两点,你就知道了这条线的一切。任何字节串(如对称密码的加密密钥)只是一个以 256 为基数的大数字。 Shamir 的算法将此秘密视为直线的“y 截距”(x=0 时直线的 y 坐标)。然后随机选择线的斜率。计算 x=1、x=2、x=3、... 处直线的 y 坐标,并将每个点分配给不同的股东。

如果这些股东中的任何两个聚集在一起,他们可以通过这两个点画一条线,回到 y 轴。它与轴相交的 y 坐标是原始秘密。然而,每个股东只有一个积分;他们自己无法猜出任何关于原始秘密的事情。

可以通过增加多项式的次数来增加阈值。例如,如果使用抛物线而不是直线,则需要三股而不是两股。

真正的实现还有更多内容,例如模块化算术的使用,但这就是其背后的概念。布莱克利的方法类似,但它使用平面的交集来编码秘密。

您可以在线尝试 Shamir 方法的实现。

It's not a commutative encryption, but there are well-proven algorithms for secret sharing (note, this is not the same thing as "key agreement.")

Two of the best known methods are Shamir's and Blakley's. In general, these algorithms take a secret and produce many "shares". When enough shares are available to reach a threshold, the secret can be recovered. In the simplest case, two shares are required, but the threshold can be higher.

To explain Shamir's method in simple terms, think about a line on a graph. If you know any two points on the line, you know everything about the line. Any string of bytes, like the encryption key of a symmetric cipher, is just a large number, in base-256. Shamir's algorithm treats this secret as the line's "y-intercept" (the y-coordinate of the line when x=0). Then the line's slope chosen randomly. The y-coordinates of the line at x=1, x=2, x=3, … are computed, and each point is given to a different share-holder.

If any two of these share-holders get together, they can draw a line through their two points, back to the y-axis. The y-coordinate at where it crosses the axis is the original secret. However, each share-holder has only one point; by themselves, they can't guess anything about the original secret.

The threshold can be increased by increasing the degree of the polynomial. For example, if a parabola is used instead of a line, three shares are needed instead of two.

There's more to a real implementation, like the use of modular arithmetic, but this is the concept behind it. Blakley's approach is similar, but it uses the intersection of planes to encode the secret.

You can play around with an implementation of Shamir's method online.

〆凄凉。 2024-11-23 03:11:13

您可以制定交换加密算法,但加密方法必须限于交换运算 。这将限制加密函数的强度,因为它大大减少了可以使用的可能的加密方法。因此,如果黑客想要破坏你的算法并且新的算法是可交换的,那么他破坏算法的机会就会大大增加,因为他需要尝试的解密方法减少了。但是,这可能适合您的目的,具体取决于您期望的黑客攻击程度。

另外,我不确定“秘密分裂”是否是您想要的,正如 atk 提到的那样。我已经简要地看过它,但从我所看到的(至少对于基本情况)你不能单独执行操作,因为需要一起提供两个密钥来执行加密/解密操作。换句话说,您无法使用一个人的密钥调用加密来获得可以使用第二个密钥调用加密的结果。但是,如果您同时拥有两个可用的密钥,这可能是一个值得尝试的好方法。

You can make a commutative encryption algorithm, but the encryption methods must then be limited to commutative operations. This will limit the strength of the encryption function because it greatly reduces the possible encryption methods that can be used. Thus, if a hacker wanted to break your algorithm and new it was commutative, it would greatly improve his chances of breaking it because of the reduction in decryption methods he would need to try. However, it might be okay for your purposes, depending on how much hacking you expect.

Also, I'm not sure if "secret splitting" is what you are going for, as mentioned by atk. I've looked at it briefly, but from what I've seen (at least for the basic case) you can't perform the operations separately, as both keys need to be provided together to perform the encrypt/decrypt actions. In other words you can't call encrypt with one person's key to get a result that you can call encrypt on with a second key. However, if you have both keys available at once, this might be a good method to try.

如梦初醒的夏天 2024-11-23 03:11:13

你说的是秘密分裂。是的,对此已有很多研究。维基百科将是一个很好的起点。

You're talking about secret splitting. Yes, there's been a lot of research on it. Wikipedia would be a good starting point.

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