为什么RSA加密在密钥交换中变得很流行?


16

这是一个软问题。我对密码学或其历史不太了解,但RSA的一种常见用法是通过加密对称密钥以发送更长的消息来进行密钥交换(例如,此处的iMessage描述)。难道这不是Diffie-Hellman密钥交换的功能吗?它更旧(对我而言似乎更简单)是为了?在Wikipedia上,它们也都获得了专利,因此对选择不承担任何责任。

明确地说,我并不是在问公钥加密技术在理论上是否重要。我在问为什么它实际上成为进行密钥交换的标准方法。(对于非密码学家来说,DH看起来更易于实现,并且也与所使用组的细节无关。)



3
在诸如DH之类的交互式密钥交换协议是不可能的情况下(例如,仅单向链接可用或往返通信时间过多时),RSA也可以用于安全密钥传输。诸如加密电子邮件之类的用例支持这种方法,因为在您要发送消息的那一刻,接收者的计算机可能未连接到Internet,因此无法参与交互式密钥交换。
凯文·卡斯卡特

您是在问为什么它变得流行于密钥交换吗?
OrangeDog '16

@KevinCathcart DH不一定是交互式的。发件人可以创建一次性密钥对,并在消息中发送公钥。该方法是ECIES / DLIES和ElGamal加密的基础。这样做的开销很小(1024位密钥为128字节)。
CodesInChaos

@CodesInChaos:但是这些都不是密钥交换算法。一旦您从密钥交换转变为成熟的公共密钥密码学,基本的难以逆转的问题的选择就不会影响操作问题,例如确保发送者拥有接收者的公共密钥的副本。我理解要问的问题:“为什么我们经常使用公共密钥加密来交换密钥,而不仅仅是密钥交换算法,这通常更简单?”。显然,基本上任何公钥算法都可以用于在非交互式通道上建立共享机密。
凯文·卡斯卡特

Answers:


14

没有强大的技术理由。我们本可以使用Diffie-Hellman(具有适当的签名)以及RSA。

那么为什么要使用RSA?据我所知,非技术性的历史原因占主导地位。RSA获得了专利,并且背后有一家公司,致力于RSA的营销和倡导。而且,这里有很好的库,并且RSA对开发人员来说很容易理解和熟悉。由于这些原因,选择了RSA,并且一旦它成为流行的选择,由于惯性它就一直保持这种状态。

如今,导致Diffie-Hellman的使用增加的主要驱动力是对完美前向保密性的渴望,使用Diffie-Hellman可以轻松实现这一点,但使用RSA则要慢一些。

顺便说一句:这是Diffie-Hellman密钥交换,而不是Diffie-Hellman秘密共享。秘密共享完全是另外一回事。


2
我认为专利更多是避免使用 RSA 的原因?
user1686 '16

@grawness取决于专利持有人的行为方式;一代人以前,技术专利持有人并没有通过大规模和长期的法律集体贬低自己,而这在智能手机大战或大规模的小公司专利巨变期间都没有。
Dan在Firelight的抚养下

10

Diffie-Hellman缺少一个关键功能:身份验证。您知道您正在与某人共享一个秘密,但是您不知道这是收件人还是中间人。使用RSA,您可能会有一些受信任的团体来存储公共密钥。如果要连接到银行,则可以向受信任方(例如Verisign)询问银行的公共密钥,因为您的计算机上已经具有受信任方的公共密钥。因此,您知道您正在与银行共享一个秘密。

使用Diffie-Hellman,当您用银行创建秘密时,实际上您可能与中间人(MITM)一起创建了一个秘密,而中间人也用您的银行创建了一个秘密,他只需将一个加密密钥转换为另一个保持不可见(同时能够读取整个通信)。


当然,您可以使用RSA进行身份验证,然后使用DH密钥交换。
OrangeDog

4
pk=gskmodp

@kasperd:我很惊讶这获得了如此多的赞成票。
2016年

1
您可以使用长期的Diffie-Hellman密钥进行身份验证(请参见CurveCP作为示例协议),也可以将DH与DSA / Schnorr / ElGamal签名(与DH共享许多基础数学)结合使用结合使用RSA加密和RSA签名。
CodesInChaos

-2

前面提到的RSA算法并不比Diffie-Hellman好很多,后者缺乏身份验证,而且两种算法都依赖于查找离散对数的难度,因此从安全角度来看,它们都非常相似。


2
感谢您的贡献。但是,您说的所有内容都已包含在其他答案中。我们希望您回答尚未有好的答案的问题,而不是重复现有的答案。同样,RSA取决于分解问题的难度(严格来说是RSA问题),而不是离散对数本身,而Diffie-Hellman 一个更经典的基于离散对数的系统(严格来说,它依赖于DDH假设) )。
DW

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.