我的问题是，这里有任何可交换的密码都足够安全，足以进行敏感的数据加密/解密（涉及金钱）并且同时时间不足以负担计算机的负担，无法在功能较弱的设备（例如智能手机）上实时运行？
#1 楼
对于一组$ B $元素（例如，对于所有“ $ n $位的块”，$ B = 2 ^ n $），存在$ B！$个可能的排列。理想的分组密码是这样的：在这些$ B！$排列中，具有未知密钥的实例与均匀地随机选择的排列是没有区别的。 “完美的”交换块密码必须在这些$ B！$排列的子集上起作用，其中子集的所有元素实际上都在相互交换，这使得交换块密码与随机选择的排列高度可区分。即，假设有一个黑盒，它实现了分组密码$ E_K $（对于某些未知密钥$ K $）或随机选择的置换。攻击者可以提交纯文本进行加密（这是一个选择明文攻击的情况），并观察结果。他的目标是确定盒子是否真的为$ K $实现了$ E_K $。然后，他执行以下操作：他随机选择键$ K'$以及明文块$ x $。
他发送$ x $和$ y = E_ {K'}（x）$作为纯文本以使用框加密。
该框分别返回$ u $和$ v $。
攻击者检查$ E_ {K'}是否（u）= v $。如果该框实现$ E_K $，则该等式将以$ 1 $的概率成立，但如果该框实现随机选择的排列，则该等式仅出现$ 1 / B $（即几乎为零）。从这个意义上说，交换块密码不能“作为块密码”来确保。交换加密只能作为协议的一部分来保证安全，在该协议中，交换加密原语的使用方式与AES不同。上面说明的情况意味着确定性可交换密码不能是“ IND-CPA安全”（与选择明文攻击设置中的随机排列没有区别）。因此，您需要在“某处”注入某种随机性，这可能是填充或整体协议的其他功能（例如，加密仅应用于在给定集合中随机且均匀选择的值，然后用于得出“正常”值）对称密钥，又名混合加密）。
#2 楼
记住在“立即安全！”中叙述的“锁盒难题”。播客（第33集，标题为“对称块密码”，2006年3月30日）？史蒂夫·吉布森说： / Brain-Teaser探索了使用两个像两个挂锁这样的私人一次性便签“钥匙”来在两方之间安全地传递消息的想法，双方都没有对方的钥匙。然后，我们通过描述对称块密码的操作来继续进行基本的加密技术之旅。两者都进行异或运算并得出她的秘密密钥。但是，如果使用不使用简单XORing加密的复杂的可交换密码，那么我认为密钥交换将是安全的，并且密钥交换将可以工作。
例如：Bob加密消息用他的钥匙。爱丽丝用她的密钥加密鲍勃的上述加密消息。 ALICE将上述加密消息发送回Bob。 Bob用他的密钥解密Alice的上述消息。 BOB将以上内容发送给ALICE。 ALICE用她的密钥解密以上内容。爱丽丝现在可以读取BOB的原始解密密文，而无需交换密钥。如果该算法不是对纯文本和密钥进行简单的XOR运算，则窃听攻击将不起作用。
此密码是可交换的复杂算法。从包含一个字符的文本文件
m开始。符号m是十六进制6d 01101101。 Â是十六进制c2。 11000010由bob加密为“ m”，然后发送给alice。 ø是十六进制的d8 11011000是爱丽丝对Â的加密，鲍勃将其解密为£并发送给爱丽丝。 £是十六进制的a3，alice用她的密钥解密到10100011。 m是爱丽丝的解密结果。窃听者在加密之前看到了爱丽丝的消息。加密后，窃听者会看到ø爱丽丝的味精。窃听XOR m和Â。 Â窃听者的XOR结果= ø（十六进制）。如果窃听者的攻击有效，他会发现11000010 Â 11011000 ø 00011010十六进制1a E，这是爱丽丝钥匙的首字母。相同的加密程序，并在验证者上达成共识。我承认是业余爱好者。如果有人想要C＃程序和/或密码的源代码（以Microsoft Windows为目标），他们可能会拥有它。
下面是带有更长的随机密钥的示例。
纯文本： />
鲍勃的密钥：
this is a test.
爱丽丝的密文：
kZtOfS0kKqcRLjTNPh7OjcJKZZFLjmm5OVm02YlrBQN0zI9SxOD1zJjQcpetUbX
爱丽丝的钥匙：
1IÎ.8Ío#"ëìAùJ'
爱丽丝给鲍勃的密文：
O1yfuV7MpX3n4wtefUhr6YctRaeCcrrzH7LqLNRUQCMVZuL5Mr0Bw3qMeIT92hg
/>
Bob解码Alice的上面= =以下的内容：
µRÖ³#ïÓO,fzkÆaå
并将上面的内容发回给Alice解码的Alice，得到：
øqqøð<ª>P¸&@<
要进行身份验证，只需在邮件内部以纯文本形式添加同意的密码，而不是邮件密文的一部分。仅在最后2次交换中需要。例如：
45。 评论
$ \ begingroup $
如果对所截获的消息（鲍勃加密消息+鲍勃/爱丽丝加密消息+爱丽丝加密消息）进行XOR，您将获得该消息。这些按键不可见，但是可以轻松阅读该消息。这不是真正的加密。
$ \ endgroup $
–Bgs
18-3-12在17:56
#3 楼
正如托马斯·珀金（Thomas Pornin）所说，块密码不能通勤，但是所有流密码似乎都将通勤，不仅是与他们自己，而是与不同的流密码。常用的密码流是DJB在NaCL中的ChaCha密码。现在，密码流的使用需要谨慎。特别是，NaCl需要两个输入，一个必须保持安全性的密钥，以及一个不需要安全性但决不能重用的随机随机数。通过在关键的正确时间点提供关键材料和随机数来应用这种可交换性可能很困难。
顺便说一句，一次性垫通常是使用流密码确定性地生产的，因此在实践中这种区分有些人为。
评论
$ \ begingroup $
不要这样做。以这种方式使用流密码似乎可以工作，但是却被打破了：仅对所有传输的消息进行XOR运算即可获得原始明文。这样做的原因是，通过加密一条消息并解密另一条消息，您正在重用随机数，正如您甚至指出的那样，“永远不可重用”。
$ \ endgroup $
–约瑟夫·西布尔-恢复莫妮卡
18年8月21日在14:12
$ \ begingroup $
您没有阅读我的答案。我显然不鼓励密钥和随机数重用。特别是，匿名网络协议通常完全按照我的描述来做，是的，它们确实利用了流密码的可交换性。所有理智的方法都可以防止您描述的琐碎攻击，但是某些mixnet数据包格式甚至具有安全证明。匿名协议主要使关键资料在端点处可用，而在中间则以一跳的形式提供。
$ \ endgroup $
–杰夫·伯吉斯（Jeff Burdges）
20-2-16在4:53
$ \ begingroup $
您能确切说明如何以可交换的方式使用流密码而不屈服于这种攻击吗？因为据我所知，这是不可避免的。
$ \ endgroup $
–约瑟夫·西布尔-恢复莫妮卡
20-2-16在5:29
$ \ begingroup $
是洋葱加密。您是否认为洋葱加密以简单的方式重复使用密钥？我们使用了不同的密钥层，因此M xor S（k1，n1）xor S（k2，n2）xor S（k3，n3）。在实践中，当使用MAC创建类似AEAD的数据包并保留长度时，您总是需要交换性，因为您需要使常规信息主体和尾部来回运行。参见cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf。存在一些协议，其中混合也添加了自己的层，匿名性相当可疑，但是人们试图使加密工作。
$ \ endgroup $
–杰夫·伯吉斯（Jeff Burdges）
20-2-16在18:48
$ \ begingroup $
也许还需要注意，流密码不适合在Shamir的三通协议（交换密码的主要应用）中使用。
$ \ endgroup $
– SEJPM♦
20-2-16在19:20
评论
您可以使用混合方案，将交换密码应用于对称密钥吗？还有您的留言多长时间？RSA遭受几乎相同的问题，因此我们应用随机填充并将其用作混合加密。
这个问题可能必须改写。就其本身而言，可交换性更多是安全漏洞而不是安全功能。如果您确实需要这种可交换性，则可能必须围绕它构建一个完整的协议，以确保它不会被攻击者利用。仅仅要求交换密码本身的安全性没有多大意义。
@CodesInChaos该应用程序是智能扑克-消息非常简短。
@HenrickHellström-我在另一个问题中询问了它-crypto.stackexchange.com/q/6575/843。