关于公钥 私钥 非对称数字加密 数字签名 和数字证书 原理

[manfred4527]

现在对公钥 私钥 非对称数字加密 数字签名 和数字证书理解非常混乱,

公钥和私钥是成对的吗?一对一 还是一对多的关系?

数字签名是用私钥加密 公钥解密,如果 A B C 三人的公钥相同 是不是可以直接得到互相的摘要值?这样安全性没有问题吗?

数字证书一般是服务器发送给客户端的,各个客户端的数字证书是一样的吗?客户端收到的数字证书,里面包含了公钥.那服务器发起的数据加密是用服务器的私钥加密再发送给客户端公钥解密吗?如果这样不是大家都能解密?

[manfred4527]

@3dwelcome
我感觉我概念又混乱了 请大佬帮忙解答一下 谢谢
我之前提到一个问题的结论
1.公钥私钥是成对的

我之后问了一个问题就是我们浏览网页 收到的数字证书上有一个公钥是负责加密的(一般都是 RSA) 大家电脑上的这个公钥是不是都是不一样的 大佬你的回答是都一样的
所以按我的理解 因为公钥私钥是成对的 所以大家在服务器上的私钥也是一样的

你说主要传输用对称算法 比如 AES 这种 , 非对称只是为了传输 对称的 KEY 就是你说的随机数.
那按我的理解 如果在数字证书这一步

"举个例子，你客户端生成了一个随机数 250，用 RSA 公钥加密了，发给服务器。然后服务器用 RSA 私钥还原，计算得出 master key，用于数据加密。 "

我对 250 这个随机数加密是和别人用同样的公钥 ,服务器上的私钥也是一样的.是不是意味着 大家的加密方式(算法和公钥一样的) 解密方式也是一样的,只是我们大家的私钥虽然一样.但是这个私钥在服务器上,我们大家都没法得到私钥,所以传输这个 随机数的 KEY 是安全的..

是这么理解吗?

[deadEgg]

@GuuJiang 请问什么非对称加密算法一个私钥可以对应多个公钥？

[deadEgg]

@GuuJiang 才看到纠正。。sorry。

[3dwelcome]

@manfred4527

是的，终于理解了，理解万岁。

PS：进度条快结束了，攒满后就没办法回贴了。哎，要是 V2EX 的进度条能升级就好了-_-

[hatcloud]

@manfred4527 #11 看一下 RSA 吧

[msg7086]

RSA 生成密钥这个也已经淘汰了吧。
现在主流都是 DHE 或者 ECDHE。（迪菲-赫尔曼密钥交换）
甲有一个秘密随机数 a，乙有一个秘密随机数 b，然后通过一顿黑科技骚操作，让甲能得知 b，乙能得知 a，而不被第三方得到 a 和 b 的具体数字。有了 a 和 b 以后，再得到密钥 s，作为对称加密密钥。
这种密钥交换的好处是不需要事先传送公钥，以及完备向前安全性（即窃听者以后若能破解这种密钥交换，也无法回过头破解过去的加密通信数据）。
DHE 还有个好处就是速度比 RSA 快得多。

现代浏览器一般用这样的：
ECDHE-ECDSA-CHACHA20-POLY1305
其中 ECDHE 负责密钥交换，ECDSA 负责证书签名认证，擦擦玻璃负责加密和完整性验证。
当然还有用 AESGCM 加密 SHA384 负责验证的 Cipher，等等。

现在网站证书里的私钥公钥的利用率其实是很小的。

[3dwelcome]

@msg7086 你似乎对 AES_GCM 加密算法有什么误解。本身 GCM 和 CHACHA20_POLY1305 一样，都是属于 AEAD 同时处理数据验证和加密的算法。摘要算法默认都是为空的，和 SHA384 没一点关系。

[3dwelcome]

GCM 的后缀 SHA384 只负责握手协议的摘要算法，只要握手成功后，所有的实际内容数据传输验证，SHA 都不会参与进去的。

还有你说的 ECDSA，是需要网站签发 ECC 曲线证书的，有多少网站会折腾这个嘛，大部分还不是 RSA。

诚然，TLS1.3 规定了不让用 RSA，是需要淘汰，但这不是没有普及的嘛。TLS1.3 改了太多协议上的东西，自己都咽到了，推广不开。虽然 RSA 慢，可现在有硬件加速卡，而且 TLS1.2 是有办法利用各种 resume ticket 黑科技，能把 RSA 的计算量大大减少。相比之下，TLS1.3 优势就没那么大了，也是很尴尬。

[manfred4527]

@3dwelcome
突然想到一个问题
我在访问一个 https 网站的时候
网站服务器是先给我数字签名 还是先传网页内容

我在网页里输入账号密码的时候 我要不要发一个数字签名给网站服务器
如果我需要发数字签名给网站服务器 那是不是意味着我需要发一个公钥给网站服务器,然后用我自己的私钥加密摘要

[3dwelcome]

@manfred4527 "如果我需要发数字签名给网站服务器 那是不是意味着我需要发一个公钥给网站服务器,然后用我自己的私钥加密摘要"

完全正确，这在 SSL 里有专门的协定，叫做客户端证书验证。当服务器需要认证客户端的时候，会告诉客户端，让其发一个证书。比如 FIREFOX，会跳出对话框，让你手动选择一个证书。当你选择完成后，FIREFOX 就会用私钥来对证书签名，发到服务器。服务器通过这个证书，就知道你是谁谁谁了。

当然，一般这种情况是对安全要求比较高的情况。比如 V2EX 录入用户名和密码，就没实现这种功能。通常来说，就是服务器给客户端数字签名，双方协定一个 KEY，建立加密通道后，再开始传输实际网页内容。

[manfred4527]

@3dwelcome
那第一个问题
我在访问一个 https 网站的时候
网站服务器是先给我数字签名 还是先传网页内容

[3dwelcome]

楼上回复了呀，通常来说，就是服务器先给客户端数字签名，建立加密通道后，再开始传输实际网页内容。

你可以假设，任何通过 HTTPS 传输的数据，每一个字节，都是加密后的。

[manfred4527]

@3dwelcome
有哪些网站是需要客户传送数字证书的呀?
举个列子? 淘宝要吗?

[3dwelcome]

@manfred4527 淘宝肯定不需要，因为加了客户端认证，就不是任何人都可以访问。

一般只有公司 OA，或者对数据非常敏感的国外网站，才会加这种功能。

[msg7086]

@3dwelcome SHA384 这个我不太熟悉，想当然了。
至于 ECDSA，我也说了是「现代」。我自己网站 RSA+ECC 双证书已经很久了，ECC 证书优先，不支持的再回落，nginx 就能支持这种配置，LE 也可以轻松签发，我不觉得这哪里折腾了。

@manfred4527 你说的这个叫做客户端证书，主要是认证用的，而不是加密。
加密，现在主流的就是 DHE 和 ECDHE，双方什么东西都不用，凭空就可以建立起加密隧道防止窃听，然后通过验证服务器证书来防止中间人攻击。

服务器生成：a = 123
服务器说：A = 456
客户端生成：b = 321
客户端说：B = 765
服务器和客户端现在知道密钥 s = 23432，以下所有消息都用 s 加密。
服务器说：我证书是 X，公钥是 Y，用私钥签名后是 Z。
客户端用 s 解密后，验证 X 可信，验证 X 包含 Y，验证 Y 和 Z 匹配。

以上数字是乱填的，仅供演示之用。


很久以前，加密是用 RSA 永久密钥生成的，后来因为向前安全性的原因，改用一次性密钥了，包括 ERSA （已失宠）和 DHE 家族（已上位），目的就是让加密与永久密钥独立开，保证有朝一日万一密钥泄露了，以前的通讯不会被同样破解。所以现在加密都是在证书交换之前就完成了，哪怕服务器没有 SSL 证书，原理上也是可以进行加密连接的。

[honeycomb]

@manfred4527 就这个话题来说，公钥是相同的，至于为什么公钥相同，还是建议你读一遍 TLS/HTTPS 的原理，这些已经有很好的文章阐述，在这里再说一遍反而没有那么清楚

[e8c47a0d]

首先公钥和私钥是仅出现在非对称加密。对称加密的密钥不存在公私之分。

没错，公钥和私钥是一对的。目前没有也用不到一对多的情况。

数字签名又是另外一回事，数字签名的目的尽在证明[我确实是谁谁谁]。

我认为理解数字签名之前，先研究好 rsa 和 dh 等算法。