公钥加密数字签名

‘壹’ 公钥加密与数字签名的联系与区别

一、密钥加密：密钥加密也称不对称加密，其常用算法是RSA、ElGamal。 不对称加密算法不对称加密算法使用两把完全不同但又是完全匹配的一对钥匙—公钥和私钥。在使用不对称加密算法加密文件时，只有使用匹配的一对公钥和私钥，才能完成对明文的加密和解密过程。加密明文时采用公钥加密，解密密文时使用私钥才能完成，而且发信方（加密者）知道收信方的公钥，只有收信方（解密者）才是唯一知道自己私钥的人。不对称加密算法的基本原理是，如果发信方想发送只有收信方才能解读的加密信息，发信方必须首先知道收信方的公钥，然后利用收信方的公钥来加密原文；收信方收到加密密文后，使用自己的私钥才能解密密文。显然，采用不对称加密算法，收发信双方在通信之前，收信方必须将自己早已随机生成的公钥送给发信方，而自己保留私钥。由于不对称算法拥有两个密钥，因而特别适用于分布式系统中的数据加密。广泛应用的不对称加密算法有RSA算法和美国国家标准局提出的DSA。以不对称加密算法为基础的加密技术应用非常广泛。
二、数字签名： 数字签名技术是不对称加密算法的典型应用。数字签名的应用过程是，数据源发送方使用自己的私钥对数据校验和或其他与数据内容有关的变量进行加密处理，完成对数据的合法“签名”，数据接收方则利用对方的公钥来解读收到的“数字签名”，并将解读结果用于对数据完整性的检验，以确认签名的合法性。数字签名技术是在网络系统虚拟环境中确认身份的重要技术，完全可以代替现实过程中的“亲笔签字”，在技术和法律上有保证。在公钥与私钥管理方面，数字签名应用与加密邮件PGP技术正好相反。在数字签名应用中，发送者的公钥可以很方便地得到，但他的私钥则需要严格保密。通俗地说，就是A用自己的私钥机密，B用A的公钥解密来确定是否是A发送的。

可是实际的情况是，用双钥密码体制加密消息非常慢，单钥加密比双钥加密要快1000倍，所以实际应用中，不是直接加密消息，而是先通过散列函数处理消息，得到消息摘要，然后用双钥密码体制中的私钥来加密这个消息摘要，就得到了数字签名。
三、两者的区别：密钥加密是用来数据加密与解密的一种手段，增强了密文的安全性。而数字签名是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。
四、从两者的定义及两者的区别中，我们也可以看出两者之间的联系其实也是很紧密的。在公钥加密的基础上附加数字签名，不仅保证了密文的安全性，同时也可以验证密文是否由真实的发送方发送的，从而做到不轻易被解密。数字签名仅仅只能保证消息的来源，却不能加密消息本身，而公钥加密恰恰弥补了这一缺陷。两者的关系，简单地说，这就类似一封写好的信和一个签上了名字的信封一样。

‘贰’ 电子合同数字签名中的公钥加密是什么意思

每个人都有一对“钥匙”（数字身份），其中一个只有她/他本人知道（密钥），另一个公开的（公钥）。
签名的时候用密钥，验证签名的时候用公钥。
又因为任何人都可以落款声称她/他就是你，因此公钥必须向接受者信任的人（身份认证机构）来注册。注册后身份认证机构给你发一数字证书。
对文件签名后，你把此数字证书连同文件及签名一起发给接受者，接受者向身份认证机构求证是否真地是用你的密钥签发的文件。

‘叁’ “数字签名技术采用的是公钥体制,它是用私钥进行加密”的对不

对。
公钥体制是数字签名的基础，数字签名就是使用数字证书的私钥对数据的摘要加密，以保证数据的完整性、真实性和不可抵赖。

‘肆’ 什么是数字签名 数字签名的介绍

1、数字签名（又称公钥数字签名）是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

2、它是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术来实现的，用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。数字签名是非对称密钥加密技术与数字摘要技术的应用。

‘伍’ 公钥加解密、数字签名、CA证书简介

本文对信息安全领域中的公钥加密、数字签名、CA证书技术进行初步介绍。

如图：

Source:

issuePublicKey.dia

由图可知，A与B各自持有自己的私钥，并对外发布自己的公钥；导致双方拥有对方的公钥。

关键在于：发送者是否真的将内容发送给了正确的接收者。

如图：

Source:

rsa_encrypt_decrypt.dia

由图可知：

问题：发送者A需要为整个信件加密，过程缓慢。

关键在于：接收者接受的是否真的是发送者是本人发送的信息。

为确保B从正确的来源收到数据A。

如图：

Source:

ca.dia

问题：发送者A的公钥，可能是伪造的。

前面只介绍了公钥加密与数字签名两个基本的技术。而CA才能确保这些技术更为实用，这里将用具体例子的方式，来逐步对它们进行讲述。

发送者a：发送信件给b。

接受者b:

发送者a：

接收者b：

注：信件经过公钥加密得到密文，密文只能通过与公钥配对儿的私钥才能解密还原为信件。

发送者a：

接收者b：

注：信件通过hash生成摘要，摘要用私钥加密生成签名；签名只能通过与私钥配对儿的公钥才能解密回摘要，再次计算信件摘要与之匹配才算成功。

发送者a：

接收者b：

注：权威机构用权威私钥将发送者公钥及其它信息加密生成证书；用众所周知的权威机构公钥解密证书得到发送方公钥进而可靠地验证签名。

‘陆’ 大多数使用公钥密码进行加密和数字签名的产品及标准使用的都是

RSA算法。RSA系统是公钥系统的最具有典型意义的方法，大多数使用公钥密码进行加密和数字签名的产品和标准使用的都是RSA算法。公钥：相当于钱包的地址，可理解成银行账户。拥有私钥，可以算出公钥，拥有公钥却不能算出私钥。

‘柒’ 公钥密码体系的数字签名的原理是什么

原理？首先公钥体系你明白吧？用私钥加密的内容只有公钥能解密。
那么数字签名就是将需要签名的内容进行散列（一般是SHA算法）后用私钥加密，得到数字签名。
验证签名就是将内容进行散列后与附带的数字签名用公钥解密的结果做比较，如果一致，则说明内容未被篡改过。

‘捌’ 四、公钥和私钥，加密和数字签名

本文涉及到支付宝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的， 千万不要觉得订单信息的加签过程也可以放在客户端完成 。

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

那么我们服务端就会对支付结果进行验签，怎么个验法呢？