公钥私钥[公钥和私钥加密解密过程]

今天给各位分享公钥私钥的知识，其中也会对公钥和私钥加密解密过程进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，如果有不同的见解与看法，请积极在评论区留言，现在开始进入正题！

公钥和私钥是通过一种算法得到的一个密钥对(即一个公钥和一个私钥)，将其中的一个向外界公开，称为公钥；另一个自己保留，称为私钥。通过这种算法得到的密钥对能保证在世界范围内是唯一的。使用这个密钥对的时候，如果用其中一个密钥加密一段数据，必须用另一个密钥解密。比如用公钥加密数据就必须用私钥解密，如果用私钥加密也必须用公钥解密，否则解密将不会成功。

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

因为支付宝SDK使用RSA来加密和生成数字签名，所以本文中涉及到的概念也都是针对于RSA的。

一对儿密钥生成后，会有公钥和私钥之分，我们需要把私钥保存下来，而把公钥发布出去。一对儿公钥和私钥，不能由其中一个导出另一个。

比如使用支付宝SDK的时候，我们商户端会生成一对儿密钥A和B，A是私钥，B是公钥，支付宝也会生成一对儿密钥C和D，C是私钥，D是公钥。我们商户端需要把商户端私钥A保存下来，而把商户端公钥B发布出去给支付宝，支付宝需要把支付宝私钥C保存下来，而把支付宝公钥D发布出去给我们商户端。

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

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

知道了加密这个概念，我们先看一下支付宝的加密过程，再引出数字签名这个概念。接着第1小节的例子，当我们商户端和支付宝互相发布了公钥之后，我们商户端手里就有 商户端私钥 和 支付宝公钥 两个密钥，支付宝手里也有 商户端公钥 和 支付宝私钥 两个密钥。现在假设我们商户端要给支付宝传输订单信息，那么为了保证传输订单信息时数据的安全性，结合我们商户端手里所拥有的密钥，可以有两套加密方案

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

支付宝开放平台说明：当我们采用RSA（1024位密钥）来加密的时候，支付宝分配给所有商户的支付宝公钥都是一样的，即支付宝针对那么多的商户只负责维护一对儿支付宝公私钥，这就意味着支付宝公钥随便什么人拿到后都是一样的；而当我们采用RSA2（2048位密钥）来加密的时候，支付宝会分配给每个商户单独的一个支付宝公钥，即支付宝为每一个的商户单独的维护一对独立的支付宝公私钥，当然一个商户下的多个App的支付宝公钥是一样的。RSA是早就支持的，RSA2是最近才支持的。

知道了上面这段话，现在假设我们采用的是方案二，并且采用RSA加密（很多老业务并没有使用RSA2加密），业务逻辑将会是下面这样。

这就出问题了， RSA加密下，支付宝公钥是公开发布的，而且所有的商户用的都是同一个支付宝公钥（上面声明了RSA2加密下，支付宝才针对每个商户维护了一对儿公私钥），攻击者很容易就能获取到，而 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

这样最终得到三个数： n d e

设消息为数M (M n)

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

设m=(c**e)%n则 m == M，从而完成对c的解密。

注：**表示次方,上面两式中的d和e可以互换。

在加密中：

n d两个数构成公钥，可以告诉别人；

n e两个数构成私钥，e自己保留，不让任何人知道。

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

别人给你发送信息时使用d加密，这样只有拥有e的你能够对其解密

而常用公钥体制主要有两个作用：加密信息和认证。由于内容，我把链接给你，你参考着看看……挺好理解的

现实生活中，我要给依依转1个比特币，我需要在比特币交易平台、比特币钱包或者比特币客户端里面，输入我的比特币钱包地址、依依的钱包地址、转出比特币的数量、手续费。然后，我们等十分钟左右，矿工处理完交易信息之后，这1个比特币就成功地转给依依了。

这个过程看似很简单也很便捷，跟我们现在的银行卡转账没什么区别，但是，你知道这个过程是怎样在比特币系统里面实现的吗？它隐藏了哪些原理呢？又或者，它是如何保证交易能够在一个安全的环境下进行呢？

我们今天就来讲一讲。

对于转出方和接收方来讲，也就是我和依依（我是转出方，依依是接收方）我们都需要出具两个东西：钱包地址、私钥。

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

我们在使用银行卡、支付宝、微信转账时都需要密码，才能够支付成功。那么，在比特币转账中，同样也有这么一个“密码”，这个“密码“被称作“私钥”。掌握了私钥，就掌握了其对应比特币地址上的生杀大权。

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

公钥和私钥，从字面意思我们就可以理解：公钥，是可以公开的；而私钥，是私人的、你自己拥有的、需要绝对保密的。

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

我们举个例子讲一下，在非对称加密算法中，公钥和私钥是怎么运作的。

我们知道，公钥是可以对外公开的，那么，所有人都知道我们的公钥。在转账过程中，我不仅要确保比特币转给依依，而不会转给别人，还得让依依知道，这些比特币是我转给她的，不是鹿鹿，也不是韭哥。

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

完成之后，完整的交易信息和数字签名会一起广播给矿工，矿工用我的公钥进行验证、看看我的公钥和我的数字签名能不能匹配上，如果验证成功，都没问题，那么，就能够说明这个交易确实是我发出的，而且信息没有被更改。

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

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

到这里，我们简单概括一下上面的内容。上面我们主要讲到这么几个词：私钥、公钥、钱包地址、数字签名，它们之间的关系我们理一下：

（1）私钥是系统随机生成的，公钥是由私钥计算得出的，钱包地址是由公钥计算得出的，也就是：私钥——公钥——钱包地址，这样一个过程；

（2）数字签名，是由交易信息＋私钥信息计算得出的，因为数字签名隐含私钥信息，所以可以证明自己的身份。

私钥、公钥都是密码学范畴的，属于“非对称加密”算法中的“椭圆加密算法”，之所以采用这种算法，是为了保障交易的安全，二者的作用在于：

（1）公钥加密，私钥解密：公钥全网公开，我用依依的公钥给信息加密，依依用自己的私钥可以解密；

（2）私钥签名，公钥验证：我给依依发信息，我加上我自己的私钥信息形成数字签名，依依用我的公钥来验证，验证成功就证明的确是我发送的信息。

只不过，在比特币交易中，加密解密啦、验证啦这些都交给矿工了。

至于我们现在经常用的钱包APP，只不过是私钥、钱包地址和其他区块链数据的管理工具而已。钱包又分冷钱包和热钱包，冷钱包是离线的，永远不联网的，一般是以一些实体的形式出现，比如小本子什么的；热钱包是联网的，我们用的钱包APP就属于热钱包。

首先明确一点，公钥和私钥是成对出现的。一个负责加密，另一个负责解密。公开的就是公钥，自己留着的就是私钥。所以不管加密还是解密密钥都是可以是公钥或者私钥的。

所以如果别人发东西给我，我就需要把加密密钥给别人，解密密钥自己藏着，这样就是公钥加密，私钥解密。

如果我想让别人确认我的身份，我就需要把解密密钥给别人，加密密钥自己留着，给自己加密，别人获得密文后用我的解密密钥才可以解密。所以这里就是公钥负责解密，私钥负责加密。

例如服务器证书，一个证书中通常包含很多字段，其中包括：

浏览器收到证书时会对签名颁发机构进行检查。如果这个机构是个很有权威的公共签名机构，浏览器可能已经知道其公开密钥了（浏览器会预先安装很多签名颁发机构的证书），然后用公钥解密，获得相关信息，例如获得证书里面的Web站点的名称和主机名，看看与当前浏览器的地址栏中的地址是否匹配，不匹配的话，浏览器就会给出警告（你可能看到过），提示当前证书是颁给xxx域名的，不是给当前域名的，让你注意。

最近实习需要写一些生成证书的脚本，借此机会顺便搞清楚了许多关于证书这块的疑惑。说到这一块东西，名词多到爆炸，对称加密、非对称加密、密钥、密钥库、公钥、私钥、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锁的钥匙)打开信箱，拿到小明的摘要,然后小花再对信件内容做同样的处理(即计算信件每个字的拼音首字母，实际上不会用这么简单的算法，而是会用不可逆的hash算法)，计算出的字符串值如与小明的信息摘要一致，说明这封信就是小明写给自己的，没有被任何人篡改。

故事高潮: 事情并没有那么简单，小花发现小明只是在信件里对自己热情似火，平常见了面连声招呼都不打，一副不认识的样子。终于有一天小花忍不住了，当面质问小明，小明却说，我什么时候给你写情书了，自作多情吧…于是小花把昨天刚收到的情书狠狠甩在了小明脸上:“上面落款不是你小明吗？怎么了,怂了？”小明一看上面还真是自己的名字，但是自己写没写信自己还不知道吗？小明把自己的作业本拿给小花，并叫自己的同桌做笔迹鉴定，小花发现笔迹的确不大像，看来是有人恶作剧，冒充小明给自己写情书，哎，好尴尬啊。。。

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

我们以上面的故事为例说一下这三点安全需求，一开始小明与小花通过A锁( 对应公钥 )加密,B锁( 对应私钥 )解密的通信方式即符合第一点，信件内容本身被加密，而因为公私钥唯一配对，只有配对的密钥才可以解密，因此很难被第三人破解。

之后，为了秀恩爱，他们采用了B锁( 私钥 )加密，A锁( 公钥 )解密的通信方式，其中用私钥对消息摘要加密后的字符串称为 数字签名 ,这样虽然信件可以被人直接看到，但如果被人篡改掉后可以轻易发现数据被篡改。本来以为满足第一条和第二条就可以安全的通信了，但最后才发现小明根本不是小明！为什么会出现这样的问题？因为“小明”说他是小明，小花就以为他是小明，他没有提供任何证明自己真的是小明的认证。因此要想安全通信，我们还需要一个权威第三方的机构来做身份认证,这个机构就是CA机构，通过认证后，CA机构会颁发权威的证书，而有了证书就可以证明身份，就不会出现身份被假冒的情况。而认证的过程则需要向CA机构提供自己的身份信息以及私钥。

对称加密就是通信双方或多方采用的密钥是一样的。加解密速度快，但不够安全。因为一旦密钥泄露，谁都可以对数据进行解密。非对称加密就是当然就是通信双方使用的密钥不同。而公钥和私钥就是非对称加密的一种方式。比较常用的对称加密算法如

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

非对称加密算法有俩个密钥，一个公钥，一个私钥。公钥和私钥必须配对出现，一对公钥和一个私钥统称为一个 密钥 ，而 密钥库 中可以存放多个密钥，即多对公私钥。

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

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

openssl则是一个开源的安全套接字层密码库，功能比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用来存放密钥的文件

.key nginx中私钥文件

而不同的证书文件后缀都是为了区分不同种类的证书的，主要有俩个分类维度

公钥私钥的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于公钥和私钥加密解密过程、公钥私钥的信息别忘了在本站进行查找喔。