⑴ RSA的公钥、私钥
RSA的公钥、私钥
采用单钥 密码系统 的加密方法，同一个 密钥 可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单 密钥加密 。
与对称加密 算法 不同， 非对称加密算法 需要两个 密钥 ： 公开密钥 （publickey）和私有密钥（privatekey）。 公开密钥 与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的 密钥 ，所以这种算法叫作 非对称加密算法 。
一、举个例子
1、发消息
用对方的公钥给对方发消息
2、发公告
发公告的时候，用自己的私钥形成签名！
二、加密和签名
RSA的公钥、私钥是互相对应的，RSA会生成两个密钥，你可以把任何一个用于公钥，然后另一个就是你必须保护好的私钥了。
RSA的公钥、私钥都可以加密，也都可以解密。
其中：
用公钥加密需要私钥解密，称为“加密”。由于私钥是不公开的，确保了内容的保密，没有私钥无法获得内容；
用私钥加密需要公钥解密，称为“签名”。由于公钥是公开的，任何人都可以解密内容，但只能用发布者的公钥解密，验证了内容是该发布者发出的。
所以：
如果用于加密解密，那就是用公钥加密私钥解密（仅你可读但别人不可读，任何人都可写）
如果用于证书验证，那就是用私钥加密公钥解密（仅你可写但别人不可写，任何人都可读）
三、认证过程
标签: HTTP
⑵ 【深度知识】区块链之加密原理图示(加密,签名)
先放一张以太坊的架构图：
在学习的过程中主要是采用单个模块了学习了解的，包括P2P,密码学，网络，协议等。直接开始总结：
秘钥分配问题也就是秘钥的传输问题，如果对称秘钥，那么只能在线下进行秘钥的交换。如果在线上传输秘钥，那就有可能被拦截。所以采用非对称加密，两把钥匙，一把私钥自留，一把公钥公开。公钥可以在网上传输。不用线下交易。保证数据的安全性。
如上图，A节点发送数据到B节点，此时采用公钥加密。A节点从自己的公钥中获取到B节点的公钥对明文数据加密，得到密文发送给B节点。而B节点采用自己的私钥解密。
2、无法解决消息篡改。
如上图，A节点采用B的公钥进行加密，然后将密文传输给B节点。B节点拿A节点的公钥将密文解密。
1、由于A的公钥是公开的，一旦网上黑客拦截消息，密文形同虚设。说白了，这种加密方式，只要拦截消息，就都能解开。
2、同样存在无法确定消息来源的问题，和消息篡改的问题。
如上图，A节点在发送数据前，先用B的公钥加密，得到密文1，再用A的私钥对密文1加密得到密文2。而B节点得到密文后，先用A的公钥解密，得到密文1，之后用B的私钥解密得到明文。
1、当网络上拦截到数据密文2时， 由于A的公钥是公开的，故可以用A的公钥对密文2解密，就得到了密文1。所以这样看起来是双重加密，其实最后一层的私钥签名是无效的。一般来讲，我们都希望签名是签在最原始的数据上。如果签名放在后面，由于公钥是公开的，签名就缺乏安全性。
2、存在性能问题，非对称加密本身效率就很低下，还进行了两次加密过程。
如上图，A节点先用A的私钥加密，之后用B的公钥加密。B节点收到消息后，先采用B的私钥解密，然后再利用A的公钥解密。
1、当密文数据2被黑客拦截后，由于密文2只能采用B的私钥解密，而B的私钥只有B节点有，其他人无法机密。故安全性最高。
2、当B节点解密得到密文1后， 只能采用A的公钥来解密。而只有经过A的私钥加密的数据才能用A的公钥解密成功，A的私钥只有A节点有，所以可以确定数据是由A节点传输过来的。
经两次非对称加密，性能问题比较严重。
基于以上篡改数据的问题，我们引入了消息认证。经过消息认证后的加密流程如下：
当A节点发送消息前，先对明文数据做一次散列计算。得到一个摘要, 之后将照耀与原始数据同时发送给B节点。当B节点接收到消息后，对消息解密。解析出其中的散列摘要和原始数据，然后再对原始数据进行一次同样的散列计算得到摘要1, 比较摘要与摘要1。如果相同则未被篡改，如果不同则表示已经被篡改。
在传输过程中，密文2只要被篡改，最后导致的hash与hash1就会产生不同。
无法解决签名问题，也就是双方相互攻击。A对于自己发送的消息始终不承认。比如A对B发送了一条错误消息，导致B有损失。但A抵赖不是自己发送的。
在(三)的过程中，没有办法解决交互双方相互攻击。什么意思呢？ 有可能是因为A发送的消息，对A节点不利，后来A就抵赖这消息不是它发送的。
为了解决这个问题，故引入了签名。这里我们将(二)-4中的加密方式，与消息签名合并设计在一起。
在上图中，我们利用A节点的私钥对其发送的摘要信息进行签名，然后将签名+原文，再利用B的公钥进行加密。而B得到密文后，先用B的私钥解密，然后 对摘要再用A的公钥解密，只有比较两次摘要的内容是否相同。这既避免了防篡改问题，有规避了双方攻击问题。因为A对信息进行了签名，故是无法抵赖的。
为了解决非对称加密数据时的性能问题，故往往采用混合加密。这里就需要引入对称加密，如下图:
在对数据加密时，我们采用了双方共享的对称秘钥来加密。而对称秘钥尽量不要在网络上传输，以免丢失。这里的共享对称秘钥是根据自己的私钥和对方的公钥计算出的，然后适用对称秘钥对数据加密。而对方接收到数据时，也计算出对称秘钥然后对密文解密。
以上这种对称秘钥是不安全的，因为A的私钥和B的公钥一般短期内固定，所以共享对称秘钥也是固定不变的。为了增强安全性，最好的方式是每次交互都生成一个临时的共享对称秘钥。那么如何才能在每次交互过程中生成一个随机的对称秘钥，且不需要传输呢？
那么如何生成随机的共享秘钥进行加密呢？
对于发送方A节点，在每次发送时，都生成一个临时非对称秘钥对，然后根据B节点的公钥 和 临时的非对称私钥 可以计算出一个对称秘钥(KA算法-Key Agreement)。然后利用该对称秘钥对数据进行加密，针对共享秘钥这里的流程如下：
对于B节点，当接收到传输过来的数据时，解析出其中A节点的随机公钥，之后利用A节点的随机公钥 与 B节点自身的私钥 计算出对称秘钥(KA算法)。之后利用对称秘钥机密数据。
对于以上加密方式，其实仍然存在很多问题，比如如何避免重放攻击(在消息中加入 Nonce )，再比如彩虹表(参考 KDF机制解决 )之类的问题。由于时间及能力有限，故暂时忽略。
那么究竟应该采用何种加密呢？
主要还是基于要传输的数据的安全等级来考量。不重要的数据其实做好认证和签名就可以，但是很重要的数据就需要采用安全等级比较高的加密方案了。
密码套件 是一个网络协议的概念。其中主要包括身份认证、加密、消息认证(MAC)、秘钥交换的算法组成。
在整个网络的传输过程中，根据密码套件主要分如下几大类算法：
秘钥交换算法：比如ECDHE、RSA。主要用于客户端和服务端握手时如何进行身份验证。
消息认证算法：比如SHA1、SHA2、SHA3。主要用于消息摘要。
批量加密算法：比如AES, 主要用于加密信息流。
伪随机数算法：例如TLS 1.2的伪随机函数使用MAC算法的散列函数来创建一个 主密钥 ——连接双方共享的一个48字节的私钥。主密钥在创建会话密钥（例如创建MAC）时作为一个熵来源。
在网络中，一次消息的传输一般需要在如下4个阶段分别进行加密，才能保证消息安全、可靠的传输。
握手/网络协商阶段：
在双方进行握手阶段，需要进行链接的协商。主要的加密算法包括RSA、DH、ECDH等
身份认证阶段：
身份认证阶段，需要确定发送的消息的来源来源。主要采用的加密方式包括RSA、DSA、ECDSA(ECC加密，DSA签名)等。
消息加密阶段：
消息加密指对发送的信息流进行加密。主要采用的加密方式包括DES、RC4、AES等。
消息身份认证阶段/防篡改阶段：
主要是保证消息在传输过程中确保没有被篡改过。主要的加密方式包括MD5、SHA1、SHA2、SHA3等。
ECC ：Elliptic Curves Cryptography，椭圆曲线密码编码学。是一种根据椭圆上点倍积生成 公钥、私钥的算法。用于生成公私秘钥。
ECDSA ：用于数字签名,是一种数字签名算法。一种有效的数字签名使接收者有理由相信消息是由已知的发送者创建的，从而发送者不能否认已经发送了消息(身份验证和不可否认)，并且消息在运输过程中没有改变。ECDSA签名算法是ECC与DSA的结合，整个签名过程与DSA类似，所不一样的是签名中采取的算法为ECC，最后签名出来的值也是分为r,s。 主要用于身份认证阶段 。
ECDH ：也是基于ECC算法的霍夫曼树秘钥，通过ECDH，双方可以在不共享任何秘密的前提下协商出一个共享秘密，并且是这种共享秘钥是为当前的通信暂时性的随机生成的，通信一旦中断秘钥就消失。 主要用于握手磋商阶段。
ECIES： 是一种集成加密方案,也可称为一种混合加密方案，它提供了对所选择的明文和选择的密码文本攻击的语义安全性。ECIES可以使用不同类型的函数：秘钥协商函数(KA)，秘钥推导函数(KDF)，对称加密方案(ENC)，哈希函数(HASH), H-MAC函数(MAC)。
ECC 是椭圆加密算法，主要讲述了按照公私钥怎么在椭圆上产生，并且不可逆。 ECDSA 则主要是采用ECC算法怎么来做签名， ECDH 则是采用ECC算法怎么生成对称秘钥。以上三者都是对ECC加密算法的应用。而现实场景中，我们往往会采用混合加密(对称加密，非对称加密结合使用，签名技术等一起使用)。 ECIES 就是底层利用ECC算法提供的一套集成(混合)加密方案。其中包括了非对称加密，对称加密和签名的功能。
<meta charset="utf-8">
这个先订条件是为了保证曲线不包含奇点。
所以，随着曲线参数a和b的不断变化，曲线也呈现出了不同的形状。比如:
所有的非对称加密的基本原理基本都是基于一个公式 K = k G。其中K代表公钥，k代表私钥，G代表某一个选取的基点。非对称加密的算法 就是要保证 该公式 不可进行逆运算( 也就是说G/K是无法计算的 )。 *
ECC是如何计算出公私钥呢？这里我按照我自己的理解来描述。
我理解，ECC的核心思想就是：选择曲线上的一个基点G，之后随机在ECC曲线上取一个点k(作为私钥)，然后根据k G计算出我们的公钥K。并且保证公钥K也要在曲线上。*
那么k G怎么计算呢？如何计算k G才能保证最后的结果不可逆呢？这就是ECC算法要解决的。
首先，我们先随便选择一条ECC曲线，a = -3, b = 7 得到如下曲线：
在这个曲线上，我随机选取两个点，这两个点的乘法怎么算呢？我们可以简化下问题，乘法是都可以用加法表示的，比如2 2 = 2+2，3 5 = 5+5+5。 那么我们只要能在曲线上计算出加法，理论上就能算乘法。所以，只要能在这个曲线上进行加法计算，理论上就可以来计算乘法，理论上也就可以计算k*G这种表达式的值。
曲线上两点的加法又怎么算呢？这里ECC为了保证不可逆性，在曲线上自定义了加法体系。
现实中，1+1=2，2+2=4，但在ECC算法里，我们理解的这种加法体系是不可能。故需要自定义一套适用于该曲线的加法体系。
ECC定义，在图形中随机找一条直线，与ECC曲线相交于三个点(也有可能是两个点)，这三点分别是P、Q、R。
那么P+Q+R = 0。其中0 不是坐标轴上的0点，而是ECC中的无穷远点。也就是说定义了无穷远点为0点。
同样，我们就能得出 P+Q = -R。 由于R 与-R是关于X轴对称的，所以我们就能在曲线上找到其坐标。
P+R+Q = 0, 故P+R = -Q , 如上图。
以上就描述了ECC曲线的世界里是如何进行加法运算的。
从上图可看出，直线与曲线只有两个交点，也就是说 直线是曲线的切线。此时P,R 重合了。
也就是P = R, 根据上述ECC的加法体系，P+R+Q = 0, 就可以得出 P+R+Q = 2P+Q = 2R+Q=0
于是乎得到 2 P = -Q (是不是与我们非对称算法的公式 K = k G 越来越近了)。
于是我们得出一个结论，可以算乘法，不过只有在切点的时候才能算乘法，而且只能算2的乘法。
假若 2 可以变成任意个数进行想乘，那么就能代表在ECC曲线里可以进行乘法运算，那么ECC算法就能满足非对称加密算法的要求了。
那么我们是不是可以随机任何一个数的乘法都可以算呢？ 答案是肯定的。 也就是点倍积 计算方式。
选一个随机数 k, 那么k * P等于多少呢？
我们知道在计算机的世界里，所有的都是二进制的，ECC既然能算2的乘法，那么我们可以将随机数k描 述成二进制然后计算。假若k = 151 = 10010111
由于2 P = -Q 所以 这样就计算出了k P。 这就是点倍积算法 。所以在ECC的曲线体系下是可以来计算乘法，那么以为这非对称加密的方式是可行的。
至于为什么这样计算 是不可逆的。这需要大量的推演，我也不了解。但是我觉得可以这样理解：
我们的手表上，一般都有时间刻度。现在如果把1990年01月01日0点0分0秒作为起始点，如果告诉你至起始点为止时间流逝了 整1年，那么我们是可以计算出现在的时间的，也就是能在手表上将时分秒指针应该指向00：00：00。但是反过来，我说现在手表上的时分秒指针指向了00：00：00,你能告诉我至起始点算过了有几年了么？
ECDSA签名算法和其他DSA、RSA基本相似，都是采用私钥签名，公钥验证。只不过算法体系采用的是ECC的算法。交互的双方要采用同一套参数体系。签名原理如下：
在曲线上选取一个无穷远点为基点 G = (x,y)。随机在曲线上取一点k 作为私钥， K = k*G 计算出公钥。
签名过程：
生成随机数R, 计算出RG.
根据随机数R,消息M的HASH值H,以及私钥k, 计算出签名S = (H+kx)/R.
将消息M,RG,S发送给接收方。
签名验证过程：
接收到消息M, RG,S
根据消息计算出HASH值H
根据发送方的公钥K,计算 HG/S + xK/S, 将计算的结果与 RG比较。如果相等则验证成功。
公式推论：
HG/S + xK/S = HG/S + x(kG)/S = (H+xk)/GS = RG
在介绍原理前，说明一下ECC是满足结合律和交换律的，也就是说A+B+C = A+C+B = (A+C)+B。
这里举一个WIKI上的例子说明如何生成共享秘钥，也可以参考 Alice And Bob 的例子。
Alice 与Bob 要进行通信，双方前提都是基于 同一参数体系的ECC生成的 公钥和私钥。所以有ECC有共同的基点G。
生成秘钥阶段：
Alice 采用公钥算法 KA = ka * G ，生成了公钥KA和私钥ka, 并公开公钥KA。
Bob 采用公钥算法 KB = kb * G ，生成了公钥KB和私钥 kb, 并公开公钥KB。
计算ECDH阶段：
Alice 利用计算公式 Q = ka * KB 计算出一个秘钥Q。
Bob 利用计算公式 Q' = kb * KA 计算出一个秘钥Q'。
共享秘钥验证：
Q = ka KB = ka * kb * G = ka * G * kb = KA * kb = kb * KA = Q'
故 双方分别计算出的共享秘钥不需要进行公开就可采用Q进行加密。我们将Q称为共享秘钥。
在以太坊中，采用的ECIEC的加密套件中的其他内容：
1、其中HASH算法采用的是最安全的SHA3算法 Keccak 。
2、签名算法采用的是 ECDSA
3、认证方式采用的是 H-MAC
4、ECC的参数体系采用了secp256k1, 其他参数体系 参考这里
H-MAC 全程叫做 Hash-based Message Authentication Code. 其模型如下：
在 以太坊 的 UDP通信时(RPC通信加密方式不同)，则采用了以上的实现方式，并扩展化了。
首先，以太坊的UDP通信的结构如下：
其中，sig是 经过 私钥加密的签名信息。mac是可以理解为整个消息的摘要， ptype是消息的事件类型，data则是经过RLP编码后的传输数据。
其UDP的整个的加密，认证，签名模型如下：
⑶ 测试那些事儿（十三）- 签名和验签、公钥和私钥、加密和解密
在做接口测试时，大家一定都遇到过需要提供签名的场景。这时，我们就会被各种名词比如 签名和验签、公钥和私钥、加密和解密 冲击。所以，了解一下它们很有必要，可以帮助我们知道为什么要这么做，而不是简单的去当一个验证执行者。甚至，在你了解了它们之后，你也可以在接口的安全性测试上更进一步。
数字签名其实就是一个别人无法仿造，能够证明申请者真实性的一段字符串。 我们在真实生活中，最常用的签名应该就是手签我们的姓名了。
所以，在接口请求时，很多接口也不是你来一个请求我就给你返回你要的数据，而是要验证你的签名，进而证明你的身份后才能做出后续动作。在此过程中，接口调用者需要进行的工作就叫做 签名 ，而被调用者需要进行的工作就叫做 验签 。
公钥 ：由接口被调用方提供，RSA 密钥体系中对外公开的部分，通常用于数据加密、验证数字签名。
私钥 ：由接口被调用方提供，RSA 密钥体系中非公开的部分，需由接口调用方严密保存，通常用于数据解密、数据签名。
这个就很好理解了，传递数据时为了保证数据的安全性，不进行明文传递，而是通过某种算法对敏感数据进行 加密 ，传递后再由接收方使用对应算法进行 解密 来获取明文信息。
将上面的定义总结为图，会更加的清晰：
之所以用发送方的私钥加签，是因为，即便信息被黑客拦截，黑客修改了信息，但是加签需要用发送方的私钥，黑客没有发送方的私钥，所以也无法生成正确的签名，接收方验签就不用通过。
反之如果用接收方的公钥加签，如果信息被黑客拦截，黑客修改了信息，因为接收方的公钥是公开的，黑客就可以重新生成新的签名，替换原有的签名，发送出去，接收方接收到信息，拿自己的公钥校验是通过的，所以接收方无法辨别信息是真正的发送方还是黑客发送过来的，这样的加签不能辨别信息是否被篡改过。
之所以用接收方的公钥加密，是因为，如果信息被黑客拦截，需要用接收方的私钥来解密，黑客无法获取接收方的私钥，即便拦截了信息（情报），黑客也无法看到明文，只能看天书?了。
反之，如果用发送方的私钥加密，如果信息被黑客拦截，因为发送方的公钥是公开的，黑客就可以用发送方的公钥解密密文获得明文，这样的加密所有的人都可以看到明文，不能保证信息的隐私。
了解了以上这些知识，在测试过程中就可以更加深入的了解签名的目的，进而可以更深入的了解签名的实现等。签名的实现有很多种，这个要根据每个团队选择哪种具体分析，但作为测试，基本上我们都是可以按照约定的规则来生成的，这也帮助我们扩展了接口测试覆盖的广度（如接口用例覆盖度、过期时间等隐藏功能），是非常有意义的。
https://blog.csdn.net/liyanlei5858/article/details/84664308
⑷ 四、公钥和私钥，加密和数字签名
本文涉及到支付宝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的， 千万不要觉得订单信息的加签过程也可以放在客户端完成 。
假设我们服务端收到了来自支付宝服务端的支付结果，即： 支付结果+数字签名 。
那么我们服务端就会对支付结果进行验签，怎么个验法呢？
⑸ 加密和签名公钥私钥问题
数字签名主要经过以下几个过程：信息发送者使用一单向散列函数（HASH函数）对信息生成信息摘要；信息发送者使用自己的私钥签名信息摘要；信息发送者把信息本身和已签名的信息摘要一起发送出去；信息接收者通过使用与信息发送者使用的同一个单向散列函数（HASH函数）对接收的信息本身生成新的信息摘要，再使用信息发送者的公钥对信息摘要进行验证，以确认信息发送者的身份和信息是否被修改过。数字加密主要经过以下几个过程：当信息发送者需要发送信息时，首先生成一个对称密钥，用该对称密钥加密要发送的报文；信息发送者用信息接收者的公钥加密上述对称密钥；信息发送者将第一步和第二步的结果结合在一起传给信息接收者，称为数字信封；信息接收者使用自己的私钥解密被加密的对称密钥，再用此对称密钥解密被发送方加密的密文，得到真正的原文。数字签名和数字加密的过程虽然都使用公开密钥体系，但实现的过程正好相反，使用的密钥对也不同。数字签名使用的是发送方的密钥对，发送方用自己的私有密钥进行加密，接收方用发送方的公开密钥进行解密，这是一个一对多的关系，任何拥有发送方公开密钥的人都可以验证数字签名的正确性。数字加密则使用的是接收方的密钥对，这是多对一的关系，任何知道接收方公开密钥的人都可以向接收方发送加密信息，只有唯一拥有接收方私有密钥的人才能对信息解密。另外，数字签名只采用了非对称密钥加密算法，它能保证发送信息的完整性、身份认证和不可否认性，而数字加密采用了对称密钥加密算法和非对称密钥加密算法相结合的方法，它能保证发送信息保密性。
⑹ 关于RSA中公钥和私钥的具体使用情况区分
公钥和私钥在一些银行系统、第三方支付系统SDK中经常会遇到，刚接触公钥私钥的朋友们估计很难区分两者的区别。
RSA公钥和私钥是什么？
首先来说，RSA是一种非对称加密算法，它是由三位数学家（Rivest、Shamir、Adleman）设计出来的。非对称加密是相对于对称加密而言的。对称加密算法是指加密解密使用的是同一个秘钥，而非对称加密是由两个密钥（公钥、私钥）来进行加密解密的，由此可见非对称加密安全性更高。
公钥顾名思义就是公开的密钥会发放给多个持有人，而私钥是私有密码往往只有一个持有人。
公私钥特性
公钥和私钥都可用于加密和解密
公钥和私钥都可以用于加解密操作，用公钥加密的数据只能由对应的私钥解密，反之亦然。虽说两者都可用于加密，但是不同场景使用不同的密钥来加密，规则如下：
1、私钥用于签名、公钥用于验签
签名和加密作用不同，签名并不是为了保密，而是为了保证这个签名是由特定的某个人签名的，而不是被其它人伪造的签名，所以私钥的私有性就适合用在签名用途上。
私钥签名后，只能由对应的公钥解密，公钥又是公开的（很多人可持有），所以这些人拿着公钥来解密，解密成功后就能判断出是持有私钥的人做的签名，验证了身份合法性。
2、公钥用于加密、私钥用于解密，这才能起到加密作用
因为公钥是公开的，很多人可以持有公钥。若用私钥加密，那所有持有公钥的人都可以进行解密，这是不安全的！
若用公钥加密，那只能由私钥解密，而私钥是私有不公开的，只能由特定的私钥持有人解密，保证的数据的安全性。
⑺ “数字签名技术采用的是公钥体制,它是用私钥进行加密”的对不
对。
公钥体制是数字签名的基础，数字签名就是使用数字证书的私钥对数据的摘要加密，以保证数据的完整性、真实性和不可抵赖。
⑻ 加密和签名的区别
加密是对信息的加密，比如A给B发消息则会使用b的公钥加密，发送后只能使用B的私钥才能解密。
签名，是给信息加个身份，是由谁发送的。一般用私钥生成。A给B发送，A使用自己的私钥签名，B收到后用A的公钥解密，来确认是不是A发的。
对称加密:是加密解密使用相同的密钥。
优使用简卜薯单快捷高效。
缺加密强度不高，密钥分发困难
DES采用替换和移位，密钥56位，每次对64位数据块加密。
3DES使唤弊闹用两个密钥K1,k2,
加密时k1加密，k2解密，k1加密
解密时k1解密，k2加密，k1解密
rc-5:rsa 数据安全公司很多产品使用了rc-5
idea:密钥是128位每次对64位数据块加密。
非对称加密:一个公钥一个私钥
优:解决了加密强度不高，密钥分发困难的问题
缺:加密速度慢
rsa:512位密钥，计算量大，难破解。
ecc:椭圆体制曲线密码
信息摘要:一份长文件的数字指纹，可以用于创建数字签名
md5 128位散列值
sha 160位散列值
md5+salt
简单的md5密码加和罩密，黑客可以通过密码md5比较，可以轻松试出密码。
如果加上salt，密码加密之前拼接上salt,之后再散列。
黑客用自己密码和salt值试，就很难找到密码。
⑼ 理解两种加密方式中私钥和公钥的概念
私钥加密算法 ，又称 对称加密算法 ，因为这种算法解密密钥和加密密钥是相同的。也正因为同一密钥既用于加密又用于解密，所以这个密钥是不能公开的。常见的有《 DES加密算法 》、《 AES加密算法 》。
公钥和私钥成对出现
公开的密钥叫公钥，只有自己知道的叫私钥
用公钥加密的数据只有对应的私钥可以解密
用私钥加密的数据只有对应的公钥可以解密
如果可以用公钥解密，则必然是对应的私钥加的密
如果可以用私钥解密，则必然是对应的公钥加的密
公钥和私钥是相对的，两者本身并没有规定哪一个必须是公钥或私钥。
要实现数据的安全传输，当然就要对数据进行加密了。
如果使用对称加密算法，加解密使用同一个密钥，除了自己保存外，对方也要知道这个密钥，才能对数据进行解密。如果你把密钥也一起传过去，就存在密码泄漏的可能。所以我们使用 非对称算法 ，过程如下：
首先 接收方 生成一对密钥，即私钥和公钥；
然后，接收方 将公钥发送给 发送方；
发送方用收到的公钥对数据加密，再发送给接收方；
接收方收到数据后，使用自己的私钥解密。
由于在非对称算法中，公钥加密的数据必须用对应的私钥才能解密，而私钥又只有接收方自己知道，这样就保证了数据传输的安全性。
除了保证数据的安全传输之外，公钥体系的另一个用途就是对数据进行签名。通常 “数字签名” 是用来验证发送方的身份并帮助保护数据的完整性。
例如：一个发送者 A 想要传些资料给大家，用自己的私钥对资料加密，即签名。这样一来，所有收到资料的人都可以用发送者的公钥进行验证，便可确认资料是由 A 发出来的了。（因为只有A使用私钥签名得到的信息，才能用这个公钥来解） 采用数字签名，可以确认两点：
保证信息是由签名者自己签名发送的，签名者不能否认或难以否认。
保证信息自签发辩巧后到收到为止未曾作过任何修改。
之所以可以确认这两点，是因为用公钥可以解密的必然是用对应的私钥加的密，而私钥只有签名者持有。
四、公钥算法的缺点
现实中，公钥机制也有它的缺点，那就是 效率非常低 ，比常用的私钥算法（如 DES 和 AES）慢上一两个数量级都有可能。所以它不适合为大量的原始信息进行加密。为了同时兼顾安全和效率，我们通常结合使用公钥算法和私钥算法：
首先，发送方使用对称算法对原始信息进行加密。
接收方通过公钥机制生成一对密钥，一个公钥，一个私钥。
接收方 将公钥发送给 发送方。
发送方用公钥对对称算法的密钥进行加密，并发送给接收方。
接收方用私钥进行解密得到对称算法的密钥。
发送方再把已加密的原始信息发送给接穗灶粗收方。
接收方使用对称猜镇算法的密钥进行解密。
⑽ 公钥与私钥用于加解密和签名
公钥：公开持有，每个人都可以获得。
私钥：个人持有，需要保密不能泄露。
公钥加密，私钥解密
信息从公钥持有者中的某一个向私钥持有者发送。
加解密是为了让通信的第三方无法获取消息内容。
私钥签名，公钥验签
信息从私钥持有者向公钥持有者中的某一个发送。
签名是为了证明消息发送者的身份合法，即是“我”本人而不是其他人冒充我发送的消息。（但这个消息可能是公开的，如果希望加密发送，则需要另外一对儿公钥和私钥反方向持有，完成加解密过程）
私钥和公钥是一对，谁都可以加解密，只是谁加密谁解密是看情景来用的：
第一种情景是签名,使用私钥加密,公钥解密,用于让所有公钥所有者验证私钥所有者的身份并且用来防止私钥所有者发布的内容被篡改.但是不用来保证内容不被他人获得。
第二种情景是加密,用公钥加密,私钥解密,用于向公钥所有者发布信息,这个信息可能被他人篡改,但是无法被他人获得。
比如加密情景：
如果甲想给乙发一个安全的保密的数据,那么应该甲乙各自有一个私钥,甲先用乙的公钥加密这段数据,再用自己的私钥加密这段加密后的数据.最后再发给乙,这样确保了内容即不会被读取,也不会被篡改。
英文版： http://www.youdzone.com/signature.html
中文版： http://www.blogjava.net/yxhxj2006/archive/2012/10/15/389547.html
https://www.hu.com/question/25912483