« Micky | 首页 | fan »
在 数字签名是什么？ 留言：
第八步如果用别人的密钥解密的话是会报错的，也就是得不到结果
2011-08-12 16:16:17
看来不止一个人误会了“解得开”“解不开”的问题。 设想一个签名场景，我们叫“理想中的签名”：Bob 直接用自己的私钥对原文加密，把结果发送给 Alice，Alice 用 Bob 的公钥去解密，得出原文。在这种情况下，的确存在一个“解开”或“解不开”的问题。如果 Alice 用别的什么人的公钥去解密，这次计算仍然能得出一串符号，但是结果没什么意义，这就是你说的“解不开”。 但实际中为了效率起见，被广泛应用的签名是这样的：Bob 对原文做一次 hash，然后用私钥对 hash 值加密，加密得到的结果我们称之为“签名”，然后把原文与“签名”发给 Alice。 Alice 首先作的计算（也就是原文的第 8 步）是用 Bob 的公钥对“签名”作一次解密，从而得出一个有待于与第 9 步得出的结果相比较的一串符号。 这串符号有什么意义么？ 没有。 与原文有什么关系么？ 看不出来。 通过这次计算，Alice 能不能断定“签名”是 Bob 发出的呢？ 不能。因为**如果用别的什么人的公钥参与这次计算，同样能得到一个符号串，也同样看不出什么意义**。 所以，这一步计算没有所谓的“解得开”“解不开”的问题。 这就是为什么原文第 8 步是错误的，原文说：
收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。
2011-08-11 18:33:46
@mazhechao 我不知道你所说的“解开签名”是什么意义，它只是一步数学计算而已。 让我们更细致地看一下“验签”的过程： 1: 输入签名和公钥，算出 hash 值 h1; 2: 输入原文，算出 hash 值 h2; 3: 比较 h1 和 h2，发现 h1 和 h2 相等。在这一步上，我们开始推理，得出原文是 bob 发出且没有修改过。也就是你说的抗抵赖和数据完整。 请注意，这两个有价值的结论都是第三步得出的。 原文第 8 步和你都认为：经过第 8 步的计算，即可以得出原文由 bob 发出的结论。这是错误的，实际上1 2 两步只是可以交换顺序的两个计算步骤，它们不是任何有价值结论的充分条件，连必要条件也不是。
2011-08-10 21:07:54
引用mazhechao的发言： Bob的签名怎么会可以用任何人的公钥解密？Bob是用他的私钥签的啊，当然只有用Bob的公钥才能解密。
引用mazhechao的发言：
2011-08-10 17:50:52
@mazhechao 原文的 5 6 7 8 9 是一个完整的签名场景，请在这个场景下重新考虑一遍。然后重新看一下 8 的表述：
8.苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。
2011-08-10 14:46:06
8.苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。 9.苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。 -------------- 8 的说法有问题，只此一步，是无法确定信由鲍勃发出的。 必须 8 9 两步都完成了，才能确定：信由鲍勃发出，信未修改。 20.如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥，对信息进行加密，然后与服务器交换加密信息。 ------------- Ciger 的说法是正确的。 为了速度起见，https 连接只在建立连接时，使用服务器的公钥加密，这个阶段是为了交换一个共享密钥。接下来的过程使用的是对称算法。
2011-08-10 13:18:50
留言（6 条）
在 数字签名是什么？ 留言：
以 RSA 算法为例。
拿其它人的公钥去解 Bob 的签名会发生什么，与 RSA 的原理无关，与具体的算法实现有关。从 RSA 的原理来说，所谓“公钥”“私钥”在数学上没有区别，所谓的“加密”、“解密”、“签名”、“验签”本质上是一回事，只是一个乘方和一个取模运算。
报错，报什么错，为什么报错？因为标准实现下，Bob 要对他的信息进行编码和填充。用别的人的公钥解密，会因为填充的字节不对而无法继续计算，或无法从计算结果提取出字符，或与 hash 串规则不符，大多数实现会在此处返回错误或抛出异常。
但是，RSA 从原理上并没有保证这一点，因为它只是三个数字参与的计算而已：把一个数与另一个数作乘方运算，然后除以第三个数，得到余数。
我们完全可以采用另一套字符编码规则、字节补齐规则、以及另外的 hash 算法，让其他人的公钥参与这次计算，也能得到一个符合规则的 hash 值。
所以从逻辑上，Alice 不能作出这样的推理：用 Bob 的公钥对签名作了一次计算，就断定签名是 Bob 发过来的。
2011-08-12 16:16:17
在 数字签名是什么？ 留言：
看来不止一个人误会了“解得开”“解不开”的问题。
设想一个签名场景，我们叫“理想中的签名”：Bob 直接用自己的私钥对原文加密，把结果发送给 Alice，Alice 用 Bob 的公钥去解密，得出原文。在这种情况下，的确存在一个“解开”或“解不开”的问题。如果 Alice 用别的什么人的公钥去解密，这次计算仍然能得出一串符号，但是结果没什么意义，这就是你说的“解不开”。
但实际中为了效率起见，被广泛应用的签名是这样的：Bob 对原文做一次 hash，然后用私钥对 hash 值加密，加密得到的结果我们称之为“签名”，然后把原文与“签名”发给 Alice。
Alice 首先作的计算（也就是原文的第 8 步）是用 Bob 的公钥对“签名”作一次解密，从而得出一个有待于与第 9 步得出的结果相比较的一串符号。
这串符号有什么意义么？
没有。
与原文有什么关系么？
看不出来。
通过这次计算，Alice 能不能断定“签名”是 Bob 发出的呢？
不能。因为**如果用别的什么人的公钥参与这次计算，同样能得到一个符号串，也同样看不出什么意义**。
所以，这一步计算没有所谓的“解得开”“解不开”的问题。
这就是为什么原文第 8 步是错误的，原文说：
Alice 的确得到了一个被暂时当作是原文 hash 值的符号串，但这个符号串还有待接下来的比对。这句话里的因果关系是不成立的。
2011-08-11 18:33:46
在 数字签名是什么？ 留言：
@mazhechao
我不知道你所说的“解开签名”是什么意义，它只是一步数学计算而已。
让我们更细致地看一下“验签”的过程：
1: 输入签名和公钥，算出 hash 值 h1;
2: 输入原文，算出 hash 值 h2;
3: 比较 h1 和 h2，发现 h1 和 h2 相等。在这一步上，我们开始推理，得出原文是 bob 发出且没有修改过。也就是你说的抗抵赖和数据完整。
请注意，这两个有价值的结论都是第三步得出的。
原文第 8 步和你都认为：经过第 8 步的计算，即可以得出原文由 bob 发出的结论。这是错误的，实际上1 2 两步只是可以交换顺序的两个计算步骤，它们不是任何有价值结论的充分条件，连必要条件也不是。
2011-08-10 21:07:54
在 数字签名是什么？ 留言：
在原文第 8 步的场景里，所谓的“解密”只是一次数学运算（典型算法RSA）。输入是 signature 和 某个人的公钥，输出是一个 hash 值。重申一次，得到的这个 hash 没有任何价值。因为可以用任何人的公钥参与这次运算。
以上可以简单归结为：没有原文的数字签名是没有价值的。
2011-08-10 17:50:52
在 数字签名是什么？ 留言：
@mazhechao 原文的 5 6 7 8 9 是一个完整的签名场景，请在这个场景下重新考虑一遍。然后重新看一下 8 的表述：
实际上 Bob 的 “数字签名” 可以用任何人的公钥解密，得到一个 hash 值。如果不加上第 9 步（比对原文的 hash值）。这个第 8 步得不到任何有价值的信息。
2011-08-10 14:46:06
在 数字签名是什么？ 留言：
8.苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。
9.苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。
--------------
8 的说法有问题，只此一步，是无法确定信由鲍勃发出的。
必须 8 9 两步都完成了，才能确定：信由鲍勃发出，信未修改。
20.如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥，对信息进行加密，然后与服务器交换加密信息。
-------------
Ciger 的说法是正确的。
为了速度起见，https 连接只在建立连接时，使用服务器的公钥加密，这个阶段是为了交换一个共享密钥。接下来的过程使用的是对称算法。
2011-08-10 13:18:50