【问题标题】:Digital Signature VS. Message Digest数字签名VS。信息摘要
【发布时间】:2014-09-21 00:50:50
【问题描述】:

我有消息 (m),我想在以不安全的方式发送后存储一些数据以验证其完整性..

我可以创建数字签名 (DSA / RSA)。

  • S(m) = m 的数字签名。

或者我可以计算一个摘要(哈希)并加密它。

  • H(m) = m 的摘要
  • C( H(m) ) = H(m) 的加密数据

无论如何,当接收者收到消息时,应该验证它的完整性。

S(m)和C(H(m))哪种方法更安全?

更新

假设 Alice 想给 Bob 发送一条消息

使用数字签名:

爱丽丝的部分:

  • 使用她的私钥计算 S(m)
  • 将 m、S(m) 和她的公钥发送给 Bob

鲍勃的部分:

  • Bob 收到 S(m)、m 和 Alice 的公钥
  • Bob 使用 m 和 Alice 的密钥验证 S(m)。

使用摘要:

爱丽丝的部分:

  • 使用 Bob 的公钥计算 C( H(m) )
  • 将 C( H(m) ) 和 m 发送给 Bob

鲍勃的部分:

  • 使用他的私钥 (d) 解密 C( H(m) )
  • 计算 H(m)
  • 验证 m ( H(m) = d ) 的完整性

我看到一个软件使用我发布的第二种方法,但我认为第一种更安全,对吗?

更新 2

总之,最好的方法是使用第一种方法,以安全的方式与 Bob 共享 Alice 的公钥。

第二种方法根本不提供安全性。

感谢@Perseids

【问题讨论】:

  • 加密不提供身份验证——实际上加密的消息通常也经过身份验证。所以你必须去签名。
  • 我用更多细节更新了我的问题。
  • 这个问题似乎离题了,因为它与编程无关。询问crypto.stackexchange.com

标签: security hash cryptography digital-signature digest


【解决方案1】:

它们都不起作用。

第一次攻击: Eve 在中间攻击并拦截了 Alice 发送的所有消息。她没有转发m,而是转发n。她没有用 Alice 的私钥在m 上签名,而是用她的私钥在n 上签名。她将自己的公钥发送给 Bob,而不是 Alice 的公钥。 Bob 永远不会看到差异,因为他事先不知道 Alice 的公钥。

第二次攻击:拦截来自 Alice 的所有消息(并丢弃它们)并创建与 Alice 相同的消息,但使用 n 而不是 m。不要忘记伪装成爱丽丝。

问题的根源在于 Bob 需要了解爱丽丝的真实身份。如果你只知道“比尔盖茨”的名字,那么我很容易冒充他。数字签名的标准假设是 Bob 从安全来源知道 Alice 的公钥,或者他们之前已经通过安全通道交换了它。然后 Bob 可以对照 Alice 的已知良好的公钥检查 Alice 的签名。

【讨论】:

  • 第一种方法,如果Bob有Alice的公钥,Alice只发送签名和消息,是不是更安全?
  • @vhax:是的,这就足够了。
  • 谢谢,在这个架构中使用数字签名而不是摘要有好处吗?
  • 任何人都可以创建摘要,因此没有(直接)方法可以仅使用摘要来验证数据。
  • @vhax 数字签名证明文档来自某一方(来自拥有相应私钥的人)。加密散列可用于识别具有固定长度短散列的任意长度消息。所需的属性称为抗碰撞性。但散列本身并不提供任何真实性。具体来说,您的第二个方案中没有任何内容可以阻止我冒充爱丽丝:没有只有爱丽丝拥有的秘密。
【解决方案2】:

在数字签名的上下文中,“消息”通常是一个哈希值——即某个文档的摘要(常规意义上的“消息”)。因此,当您以适当的方式“签署文档”时,您是在将由签名算法定义的单向变换应用于该文档的摘要,而不是应用于整个文档。

当然,您可以基于对称或非对称密码学,或同时基于这两种方法,发明一些其他的消息身份验证方法。但因此你肯定会重新发明轮子,你的轮子很有可能变成四倍左右。数字签名算法专为在公钥基础设施内进行无缝身份验证而设计。所以要适当地使用它们。

【讨论】:

  • 我看到一个软件使用我贴的第二种方法,但我觉得第一种更安全,对吗?
  • 第二个在我看来不像是正确的 MAC 结构,所以它是无效的。否则,由您来创建签名(使用非对称密钥)或消息验证码(使用对称密钥)。这取决于您希望如何实施密钥管理。
  • @Anton 原则上,大多数签名算法由散列方法、填充方法和陷门函数(即 RSA 的模幂运算)组成。散列函数被认为是签名方案的一部分。哈希函数和填充方法的选择被认为是签名函数的参数。
  • @vhax 我还在现实世界的软件中看到了许多“解决方案”,即在成熟的商业软件中。其中一些“解决方案”甚至可能在整个行业范围内实现标准化。但是这些事实本身并没有让这些“解决方案”变得不那么愚蠢,因为它们要么促进破解到可行性和可负担性的程度,要么几乎没有提供任何额外的安全性——除了针对最不成熟的用户。但是,关于您的第二个方案,请参阅我的下一条评论。
  • @owlstead 不能同意你的第二个方案无效。想象一下对称密码C(m, k) 依赖于发送者和接收者都知道的预共享密钥k。假设它是受 DRM 保护的数据供应商和订阅者的硬件知道的某个“安装 ID”(以非顺序方式生成),但人类订阅者本人不知道。这样就可以确实验证数据的真实性,而无需使用重量级的数字签名数学。当然,这可能会为已知的明文攻击打开可能性,因此 HMAC 似乎要好得多。
猜你喜欢
  • 2015-04-09
  • 1970-01-01
  • 2020-03-14
  • 1970-01-01
  • 2023-03-18
  • 2012-12-30
  • 2012-08-19
  • 2013-12-20
  • 1970-01-01
相关资源
最近更新 更多