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

[manfred4527]

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

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

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

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

[3dwelcome]

公钥密钥是一对一的关系。只要服务器的密钥不泄漏，客户端用公钥加密的数据，天下就只有一台服务器可以解密，这样就起到了避免第三方伪造服务器的功效。

然后数字签名保证了公钥是无法被修改的（ CA 根证书的签发），所以客户端能识别到正确的服务器，同理，如果服务器需要验证客户端，也可以让客户端给服务器发数字签名证书，确保客户端不会被伪造。

[3dwelcome]

"如果 A B C 三人的公钥相同 是不是可以直接得到互相的摘要值?"
就 HTTPS 而言，数据加密不仅仅公钥密钥，那只是握手验证而已。每次一加密都包含了关键的服务器随机数和客户端随机数，所以 C 要冒充 AB，由于客户端随机数无法伪造，每一次服务器随机数也无法伪造，几乎是不可能的。

所以你最后那句“如果这样不是大家都能解密”，肯定是无法实现的。

[manfred4527]

@3dwelcome 有些资料写是公钥对私钥可以是一对多的看着就比较纳闷

说数字签名是一种逆向的非对称加密,如果是一对一的公钥私钥 用私钥加密的话 是不是意味着只有服务器上对应的那一把公钥能解?如果有外人获取到那一把发送的公钥 是不是意味着可以截取到 数字签名信息

[3dwelcome]

私钥顾名思义，就是不能公开，服务器上一般只能存私钥，而且必须加密保存，不能外泄。

至于公钥，都是嵌入到数字证书里的，让 CA 做认证，打个包，起名叫.cer 扩展，放到服务器上，任何客户端用 HTTPS 访问的时候，都可以获取证书和公钥。

所以，数字证书和公钥和签名信息，都是公开给大众访问的。但仅仅靠这点数据，也是没办法黑到别人客户端上的数据的。因为真的数据加密不是用 RSA，而是用 AES 对称式加密。RSA 只是药引，负责生成加密 KEY 而已。

[GuuJiang]

@manfred4527
第一个问题，取决于具体的算法，有的算法确实是一个私钥可以导出多个公钥的，这没有什么好疑惑的
第二个问题，公钥本来就是公开的，数字签名也本来就是公开的，任何人都可以验证

[3dwelcome]

@GuuJiang "Public-key algorithms such as RSA or ECDSA have exactly one private key for each public key and vice versa."

“一个私钥可以导出多个公钥的", 有具体出处吗？我网上查到的都是一对一关系啊。

[Miary]

这些东西连百度百科都能给你解释清楚。

[glacer]

复习下计算机网络这本书吧

[WuwuGin]

额，首先 pubkey 是 encrypt，privatekey 是 decrypt。

[honeycomb]

公钥和私钥确实是一对的。

但实际的封装中，一般私钥文件同时包含私钥与公钥，公钥文件则只包含公钥。

至于具体的步骤，应该看一下 TLS 协商的流程。

[manfred4527]

@3dwelcome
@honeycomb
谢谢回复

公钥私钥是一对的,所以我去打开 https 加密网页比如 google ,google 会给我一个数字证书,数字证书里面包含了 goolge 给我的公钥. 所以我电脑中的公钥和别人收到 google 发给他们的数字证书中的公钥是不一样的对吗?

[3dwelcome]

你和别人拿到的公钥都是一样的，数字证书的目的，是保护里面关键信息不被第三方篡改，公钥就包含其中。

[keyfunc]

公私钥肯定是 1 对 1 的，请不要把数字证书和公私钥对搞混了。详情可以看下非对称算法的原来，RSA 的很简单。

另外还有一个概念，公钥加密，私钥解密，私钥签名、公钥验签。

TLS 加密并不是通过公钥做加密的，TLS 主要还是使用对称加密，公私钥只是协商对称加密的密钥时用，每个会话的密钥都不同的，不存在泄密的问题。

[blackjar]

@3dwelcome #4 rsa 是用来做 key exchage 的 什么时候“负责生成加密 KEY ”了？

[GuuJiang]

@3dwelcome 嗯，收回我前面的错误说法，确实应该是一对一的，是我把多个比特币钱包地址那一套记混了

[3dwelcome]

@blackjar HTTPS 里面握手关键的一步叫 CLIENT_KEY_EXCHANGE，就是把双方约定的 preMasterSecret，变成真正加密的 MasterSecret，这步就是需要 RSA 参与计算的。

而 MasterSecret 就是用于加密数据的 key，这段数据非常关键，所以并不能直接在网络上传输，需要服务器和客户端做约定，先用客户端 /服务器随机数，填充 preMasterSecret，然后用 RSA 来加密 /解密，相当于生成最终 KEY 了。

而由于 MasterSecret 非常重要，有些移动客户端为了服务器性能考虑(ssl resume ticket)，把 MasterSecret 缓存在本地磁盘，最终导致了把 HTTPS 安全直接降级到了 HTTP，是需要鄙视的。

[manfred4527]

@3dwelcome 如果我和别人的公钥是一样的话,那在服务器上的私钥是不是也一样的? 如果不一样 那不是一个公钥 对应多个私钥的情况
如果公钥私钥都一样 那不是没有安全意义了.

[3dwelcome]

@manfred4527 其实你还是没有仔细看回复，随机数这个概念很重要。

虽然公钥密钥大家都一样，但机器不一样，时间不一样，生成的随机数不一样。所以每一次最终参与时间加密的 KEY，是截然不一样的。

如果你没有办法获取别人的 KEY，那你就没办法解密和监视别人传输的数据内容。这样 HTTPS 的数据流就是安全的。

[3dwelcome]

如果 HTTPS 的文本内容是 RSA 直接加密 /解密的，那么你说公钥一致私钥一致，解密的数据就是一致的。但可惜 HTTPS 不是这样运作的，加密都是对称式加密，RSA 只对 KEY 负责。

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

你作为第三方偷窥者，是无法用 RSA 公钥，来还原出客户端随机数 250。得不到 250，你就没办法填充 permasterkey，没办法填充 permasterkey，就没办法导出最终的 master key。都是一个萝卜一个坑，中间少了任何一个环节，加密结果就差很多。

[minyress]

https://www.v2ex.com/t/460749#reply8