扫盲公私钥，各种证书，https基本概念

关于公钥私钥和rsa公钥私钥的问题，很多朋友都不知道。 关注风色小编查看公钥私钥的具体详情。

本文目录列表： 扫盲公私钥、各种证书、https基本概念

最近，我需要写一些脚本来为我的实习生成证书。 我借此机会澄清了很多关于证书的疑惑。 说起这个东西，名词就这么多，对称加密，非对称加密，key，keystore，公钥，私钥，CA，证书，数字签名，ssh，https，ssl，keytool，openssl，PKCS，X.509和令人眼花缭乱的文件扩展名，cer、crt、pem、keystore、jks、key、p12、pfx……

听我先讲个故事，这次不需要Bob和Alice，听完这些概念，我恍然大悟。

故事背景：现在是2018年，为了通信安全，假设每个人都有两把锁，一把叫A锁，一把叫B锁。 这两把锁与普通锁有些不同。 一把锁有自己的锁，另一把锁有一把钥匙，所以A锁和B锁既是锁又是钥匙。 A 锁和 B 锁是唯一配对的。 A锁上锁后，只能打开B锁。 同样，B锁上锁后，只能打开A锁。 其中一把锁是公用的，另一把锁是自己保管的，不是公用的。 假设默认情况下 A 锁是公用的，B 锁是私有的。

故事内容： 阿里巴巴儿童小学的小明想在隔壁班给小华写一封表白信。 为了不被别人看到，他把信放在信箱里，用小华的A锁锁了起来，因为小华的B锁（也是A锁的钥匙）只有小华自己所有，所以除了小华以外的任何人他们拿到信的时候，萧华看不到信的内容。 同样，如果小花要给小明写一封信，小明的A锁必须用来保护信件的内容。

小明和小花就这样聊了一会儿，然后小花觉得差不多了，可以进入秀恩爱阶段了，告诉小明，以后不要写tm加密了，又不是银行卡密码，其他人可以看到。 如何？ 阅读后不要更改它。 于是小明写完信后，把信中每个字的拼音首字母拼成一串，命名为留言摘要，然后就把留言摘要放进了邮箱，锁上了邮箱用他自己的 B 锁。 虽然这封信本身并没有放入安全的邮箱，但是作为情书高手的小明，随便一封信都有几万字。 如果其他人对信的内容做了任何改动，那一串拼音首字母几乎肯定会发生变化，所以小花拿到信后，先用小明的A锁（B锁的钥匙）打开邮箱，得到小明的摘要，然后小花对信件的内容做同样的处理（即计算信件中每个单词的首字母，实际计算出的字符串值如果与小明的信息摘要一致，则说明这封信是小明写给自己的，没有被任何人篡改过。

故事高潮：事情没有那么简单。 小花发现小明只是在书信里对她热情，平时见了连招呼都不打，就好像不认识一样。 终于有一天，小花忍无可忍，当面质问小明，小明却说，我什么时候给你写情书了，你要深情……昨天刚收到小明的脸上：“不是你小明写的吗？怎么了，你害怕吗？” 小明一看果然是自己的名字，只是不知道这封信是不是他写的？ 小明把作业本交给小华，让同桌鉴定字迹。 萧华发现这字迹不像。 好像有人冒充小明，给自己写了一封情书恶作剧。 哎，好尴尬。 . .

故事讲完了，文章开头涉及到的所有概念都与信息的安全传输有关，可以说一切都是为了安全。关于通信安全，我们通常有三个基本需求

下面就以上面的故事为例，来解释一下这三个安全需求。 一开始，小明和小花使用A锁（对应公钥）加密，B锁（对应私钥）解密的通信方式，满足了第一点。 信件内容本身是加密的，而且由于公钥和私钥是唯一配对的，只有配对的密钥才能解密，所以很难被第三方破解。

后来，为了示爱，他们采用了B锁（私钥）加密，A锁（公钥）解密的通信方式，其中用私钥加密后的字符串对消息摘要称为数字签名，所以虽然信件可以被人直接看到，但是如果被篡改了，很容易发现数据被篡改了。 一开始我以为满足了第一个和第二个条件就可以安全通信了，结果发现小明根本就不是小明！ 为什么会出现这样的问题？ 因为“小明”说他是小明，所以小华就认为他是小明，也没有提供任何证明证明他真的是小明。 因此，为了安全地进行通信，我们还需要有权威的第三方机构来做身份认证。 这个组织就是CA组织。 有冒充的例子。 认证过程需要向CA机构提供自己的身份信息和私钥。

对称加密是指通信中两方或多方使用的密钥相同。 加密和解密速度很快，但不够安全。 因为一旦密钥泄露，任何人都可以解密数据。 非对称加密当然是通信双方使用的密钥不同。 公钥和私钥是非对称加密的一种方式。比较常用的对称加密算法如

AES、DES、非对称加密比较常见的有sha256、RSA。

非对称加密算法有两个密钥，公钥和私钥。 公钥和私钥必须配对在一起。 一对公钥和一个私钥统称为密钥，keystore中可以存储多个密钥，即多对公私钥。

如果你使用github，你应该注意到github链接有两种方式。 一个是 https，另一个是 ssh。 通过 https 经常需要输入密码，而通过 ssh 则不需要。 回想一下你设置ssh的步骤，你在本地生成了一个密钥对，并将公钥上传到github。 每次传输都使用本地自动私钥加密，服务器使用您上传的公钥解密，无需手动输入密码。

keytool 和openssl 是两个证书管理工具。 keytool是java JDK自带的证书管理工具。 使用 keytool 可以生成密钥并创建证书。 只要安装好jdk并正确设置环境变量，就可以通过命令行执行keytool命令来管理证书了。

openssl 是一个开源的 Secure Sockets Layer 密码库，功能比 keytool 多。

PKCS的全称是Public-Key Cryptography Standards，即公钥标准。 PKCS 已经发布了 15 个标准。

PKCS#12包含公钥和私钥的二进制格式证书形式，以pfx为后缀的证书文件

X.509是一种通用的证书标准，它规定了证书应该包含哪些内容。 X.509通常有两种编码方式，一种是二进制编码，一种是base64编码。

X.509#DER二进制格式证书，常用后缀.cer .crt

X.509#文本格式的PEM证书，常用后缀.pem

因为http是明文传输的，非常不安全，所以提出了ssl（Secure Sockets Layer）层协议，即在原有的基础上再增加一层协议来保证安全传输。 可以认为https=ssl+http。 很多人刚开始使用https，都是在浏览器F12打开控制台后。 可能会发现数据仍然没有加密。 需要注意的是https是传输层加密，你在浏览器F12控制台看到的仍然是应用层数据。

因为本文主要是概念性的识字和帮助理解，所以这部分的具体细节就不做介绍了。

.keystore、.jks和.truststore都是java用来存储密钥的文件

nginx 中的 .key 私钥文件

不同的证书文件后缀用于区分不同类型的证书，主要有两个分类维度

什么是公钥和私钥？

公钥和私钥是通过算法得到的一对密钥（即公钥和私钥）。 其中之一对外公开，​​称为公钥； 另一个自己保存，称为私钥。 通过该算法得到的密钥对可以保证全球唯一。 使用这个密钥对时，如果一段数据用一个密钥加密，则必须用另一个密钥解密。 例如，如果您使用公钥加密数据，则必须使用私钥对其进行解密。 如果使用私钥加密数据，还必须使用公钥解密，否则解密不成功。

什么是公钥私钥

现在很多对称加密算法都会生成一个密钥对，也就是你要的公私钥~

一般来说，公钥用来加密，私钥用来解密~

私钥是公开的，在客户端使用~而公钥是保密的~

举个例子~

从用户名A，公钥3，可以得到序列号5

然后通过私钥2，可以将序号5解密成A，

这样在不失密的情况下很容易验证序列号的合法性~

3和2的确定是通过使用一些特殊的函数来完成的。 它们之间存在一定的关系。 有3的话推2容易，有2的话推3就难了~

大致就是这个意思~

公钥和私钥的区别和应用。

现实生活中，如果我想转1个比特币给依依，我需要在比特币交易平台、比特币钱包或比特币客户端中输入我的比特币钱包地址、依依的钱包地址以及比特币转账地址。 数量，手续费。 然后，我们等了大约十分钟，矿工处理完交易信息后，这1个比特币就成功转给了依依。

这个过程看起来很简单方便，和我们现在的银行卡转账没什么区别，但是你知道这个过程在比特币系统中是如何实现的吗？ 它隐藏了什么原则？ 或者说，它如何保证交易能够在安全的环境中进行？

今天就来说说吧。

对于发送方和接收方，也就是我和依依（我是转账方，依依是接收方）我们都需要发行两个东西：钱包地址和私钥。

先说钱包地址。 比特币钱包地址其实相当于银行卡、支付宝账户、微信钱包账户。 它是比特币支付转账的“凭证”，记录平台、钱包、钱包之间的转账信息。

我们在使用银行卡、支付宝、微信转账的时候，都需要密码才能成功支付。 那么，在比特币转账中，也有这样一个“密码”，这个“密码”就叫做“私钥”。 一旦掌握了私钥，就掌握了对其对应的比特币地址生死攸关的权力。

“私钥”是属于“非对称加密算法”的一个概念，与之对应的还有一个概念，名称为：“公钥”。

我们可以从字面意思来理解公钥和私钥：公钥可以公开； 而私钥是私有的，归您所有，需要绝对保密。

公钥是根据私钥计算出来的，比特币系统采用椭圆曲线加密算法，根据私钥计算出公钥。 这使得公钥和私钥形成了唯一的对应关系：当你使用其中一个密钥加密信息时，只有配对的另一把密钥才能解密。 因此，正是基于这种独特的对应关系，它们才可以用来验证信息发送者的身份，也可以做到绝对保密。

让我们举个例子来解释公钥和私钥在非对称加密算法中是如何工作的。

我们知道公钥是可以公开的，所以大家都知道我们的公钥。 在转账的过程中，我不仅要保证比特币是转给依依的，而不是转给别人的，还要让依依知道，这些比特币是我转给她的，不是露露或者九哥转给她的。

比特币系统可以满足我的上述需求：比特币系统会将我的交易信息缩短成一个定长的字符串，也就是一个摘要，然后将我的私钥附在这个摘要上，形成数字签名。 因为数字签名包含了我的私钥信息，所以数字签名可以证明我的身份。

完成后，完整的交易信息和数字签名将一起广播给矿工。 矿工会用我的公钥来验证我的公钥和我的数字签名是否匹配。 如果验证成功，没有问题知道别人比特币私钥怎么转账，那么，就可以说明这笔交易确实是我发送的，信息没有被更改过。

接下来，矿工需要验证这笔交易中花费的比特币是否是“未花费”的交易。 如果验证成功，则放入“未确认交易”中等待打包； 如果验证失败，交易将被标记为“无效交易”，不会被打包。

其实对公钥和私钥的简单理解就是：既然是加密的，肯定是不想让别人知道我的消息，所以只有我才能解密，所以可以得出结论：公钥负责加密，私钥负责解密； 道理，既然是签名，我绝对不希望有人冒充我的身份。 只有我才能发布这个数字签名，所以可以得出私钥负责签名，公钥负责验证。

在此，我们简单总结一下以上内容。 上面我们主要说了这几个词：私钥、公钥、钱包地址、数字签名，下面来了解一下它们之间的关系：

(1) 私钥由系统随机生成，公钥由私钥计算，钱包地址由公钥计算，即：私钥-公钥-钱包地址，这样一个过程；

(2) 数字签名由交易信息+私钥信息计算得出。 由于数字签名包含私钥信息，可以证明自己的身份。

私钥和公钥都属于密码学的范畴，属于“非对称加密”算法中的“椭圆加密算法”。 之所以使用这种算法是为了保证交易的安全性。 两者的作用是：

(1)公钥加密，私钥解密：公钥是全网公开的，我用依依的公钥加密信息，依依可以用自己的私钥解密；

(2) 私钥签名，公钥验证：我给依依发消息，我加上自己的私钥信息形成数字签名，依依用我的公钥验证，验证成功证明确实是这条消息我发了。

但是，在比特币交易中，加密、解密、验证都交给了矿工。

至于我们现在经常使用的钱包APP，它只是一个管理私钥、钱包地址等区块链数据的工具。 钱包分为冷钱包和热钱包。 冷钱包是离线的，永远不会连接到互联网。 它们通常以一些实体的形式出现，比如小书； 热钱包是联网的，我们使用的钱包APP就是热钱包。 .

4. 公钥和私钥、加密和数字签名

本文涉及到支付宝SDK的内容，均取自支付宝开放平台。

由于支付宝SDK使用RSA加密生成数字签名，本文涉及的概念也是针对RSA的。

一对密钥生成后，就会有公钥和私钥。 我们需要保存私钥并发布公钥。 一对公钥和私钥，一个不能从另一个派生。

比如在使用支付宝SDK的时候，我们的商户会生成一对密钥A和B，A是私钥，B是公钥，支付宝也会生成一对密钥C和D，C是私钥, D 是公钥。 我们商户端需要保存商户私钥A，将商户公钥B公布给支付宝。 支付宝需要保存支付宝私钥C，并将支付宝公钥D公布给我们的商户。

加密是指我们使用一对密钥中的一个来加密数据，并使用另一个来解密数据。 需要注意的是公钥和私钥都可以用来加解密，没有规定只能用公钥和私钥加解密，但是加解密必须是相互加解密在一对键之间，否则不会成功。

加密的目的是保证数据的不可读性，防止数据在传输过程中被截获。

知道了加密的概念，我们先来看看支付宝的加密过程，再介绍一下数字签名的概念。 继续第1节的例子，当我们的商户终端和支付宝已经互相下发了公钥，我们的商户终端有两个密钥，商户私钥和支付宝公钥，支付宝也有商户公钥和支付宝私钥两个keys.现在假设我们商户端要向支付宝传输订单信息，那么为了保证传输订单信息时数据的安全性，结合我们商户端拥有的密钥，我们可以有两套加密方案

貌似这两套加密方案都可以达到加密订单信息的效果，如果采用第二种方案，我们商户端甚至只需要存储支付宝公钥，不需要申请一对商户端的公私钥来维护，支付宝不需要保存我们这帮商户那么多的商户端公钥。 这不是更简单吗，为什么支付宝的开放平台让我们采用方案一而不是方案二呢？ 下面就来一一解答吧。

支付宝开放平台说明：当我们使用RSA（1024位密钥）加密时，支付宝分发给所有商户的支付宝公钥是相同的，即支付宝只负责维护一对支付宝公私钥对于这么多商户来说，这意味着支付宝公钥谁拿到谁都是一样的； 而当我们使用RSA2（2048位密钥）加密时，支付宝会为每个商户分配一个单独的支付宝公钥，即支付宝为每个商户分别维护一对独立的支付宝公钥和私钥。 当然，一个商户下的多个app的支付宝公钥是一样的。 RSA 已经支持很长时间了，而 RSA2 是最近才支持的。

知道了上面这段话，现在假设我们采用第二种方案，使用RSA加密（很多老业务不使用RSA2加密），业务逻辑会如下。

这是个问题。 在RSA加密下，支付宝公钥是公开发布的，所有商户都使用同一个支付宝公钥（上面说了在RSA2加密下，支付宝为每个商户维护一对公私钥），攻击者很容易得到it，notify_url也很容易被拦截，那么攻击者拿到这两个东西就可以和商家一样的操作发起支付请求，这样就一直扣小明的钱。

因此，支付宝需要确认支付请求确实是商家发给他们的，而不是攻击者发给他们的。 这里用到了数字签名，我们通过方案一的实现过程来介绍数字签名的具体概念。如果采用方案一，我们商户保存的是商户私钥和支付宝公钥，支付宝保存的是商户的公钥和支付宝的私钥。 业务逻辑如下。

这样才能保证交易的安全性。 我们也可以看到，使用支付宝SDK来保证交易的安全，其实并不是订单信息是否加密，而是如何保证商户和支付宝可以相互确认身份，订单信息是明文的文本。 ，但是数字签名是在它后面拼接的。

数字签名实际上是将明文数据加密后得到的密文，只不过是用私钥加密生成的。 我们通常将数字签名拼接在明文数据的后面，传递给接收方。 密钥对数字签名进行解密，从而验证发送者的身份以及明文数据是否被篡改。 数字签名生成过程实际上是一个加密过程，而数字签名验证过程是一个解密过程。

数字签名的目的有两个：第一，发送方和接收方验证对方的身份； 第二，验证数据是否被篡改。

从上面的第一部分我们知道，为了保证商户与支付宝之间的交易安全，约定使用对订单信息进行数字签名的方式进行传输。 支付宝还为我们提供了一键生成RSA密钥的工具，可以帮助我们快速生成一对商户端的公私钥。 下面将对支付宝SDK的支付流程做一个大概的说明，并指出在实际开发中使用支付宝SDK需要注意的几点。

我商户自己生成的RSA私钥（必须和商户的公钥是一对），生成后必须保存在服务器端，不能保存在客户端，也不能从服务端传给客户端.

用于签署订单信息。 添加标志的过程必须在服务器端完成，不能在客户端添加。 客户端仅负责调用支付宝以签署的订单信息进行支付。

我们商户自己生成的RSA公钥（必须和商户私钥是一对），生成后需要填写到支付宝开放平台。

用于验证我们在支付宝服务器上签署的订单信息，确保订单信息确实是我们商家发送给支付宝的，并保证订单信息在传输过程中没有被篡改。

这与我们无关。 支付宝私钥是他们生成的，由他们保管。

用于对支付结果进行签名。

支付宝公钥和支付宝私钥是一对，也是支付宝生成的。 当我们在支付宝开放平台填写商户端公钥时，平台会为我们生成一个支付宝公钥，我们可以复制保存在服务器上。 也不要在客户端保存，也不要传输给客户端。

用于让服务器验证支付宝服务器返回的同步或异步支付结果，确保支付结果确实是支付宝服务器返回给我们服务器的，没有被篡改过。 支付结果的验证也必须在服务器端完成。

如前所述：订单信息的签署和支付结果的验证必须在服务端进行，不能在客户端进行。

以下是客户端签署订单信息的过程。 只是模拟服务端，展示订单信息最终是如何通过签名转化为orderString的。 不要以为订单信息的签署过程也可以放在客户端。 结束。

假设我们的服务器收到支付宝服务器的支付结果，即：支付结果+数字签名。

那么我们的服务器会对支付结果进行校验，如何校验呢？

公钥和私钥

我也是刚学习，给大家举个例子，很有用：

RSA算法概述如下：

找出两个质数 p 和 q

取n=p*q

取 t=(p-1)*(q-1)

取任意数e，要求满足et且e与t互质（即最大公因数为1）

取 d*e%t==1

这以三个数字结尾：nde

令消息为数字 M (M n)

设置c=(M**d)%n得到加密后的消息c

如果m=(c**e)%n，则m == M知道别人比特币私钥怎么转账，从而完成对c的解密。

注：**表示幂次，上式中d和e可以互换。

在加密中：

nd的两个数字构成公钥，可以告诉别人；

ne的两个数字构成私钥，e自己保管，不让任何人知道。

发给别人的信息是用e加密的，只要别人能用d解密，就证明这个信息是你发的，这就构成了签名机制。

别人给你发信息时用d加密，这样只有你有e才能解密

常用的公钥系统有两个主要功能：加密信息和认证。因为内容，我给你链接，你可以参考一下......很容易理解

以上就是“公钥私钥”和“rsa公钥私钥”的详细内容。 我希望它可以帮助你。 更多信息请参考风色百科。