数字加密签名模块

⑴ 数字签名的加密方式是怎样的原理

数字签名（又称公钥数字签名、电子签章）是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。

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

公钥加密系统允许任何人在发送信息时使用公钥进行加密，数字签名能够让信息接收者确认发送者的身份。当然，接收者不可能百分之百确信发送者的真实身份，而只能在密码系统未被破译的情况下才有理由确信。

• 鉴权的重要性在财务数据上表现得尤为突出。举个例子，假设一家银行将指令由它的分行传输到它的中央管理系统，指令的格式是(a,b)，其中a是账户的账号，而b是账户的现有金额。这时一位远程客户可以先存入100元，观察传输的结果，然后接二连三的发送格式为(a,b)的指令。这种方法被称作重放攻击。

• 完整性。传输数据的双方都总希望确认消息未在传输的过程中被修改。加密使得第三方想要读取数据十分困难，然而第三方仍然能采取可行的方法在传输的过程中修改数据。一个通俗的例子就是同形攻击：回想一下，还是上面的那家银行从它的分行向它的中央管理系统发送格式为(a,b)的指令，其中a是账号，而b是账户中的金额。一个远程客户可以先存100元，然后拦截传输结果，再传输(a,b3)，这样他就立刻变成百万富翁了。

• 不可抵赖。在密文背景下，抵赖这个词指的是不承认与消息有关的举动（即声称消息来自第三方）。消息的接收方可以通过数字签名来防止所有后续的抵赖行为，因为接收方可以出示签名给别人看来证明信息的来源。

⑵ 什么是邮件加密，什么是数字签名，提供了哪些方面的安全功能

邮件加密就是把邮件从明文转换为密文的过程。数字签名是一个加密的信息摘要，附加在消息后面，模拟文件中的亲笔签名或印章以保证文件的真实性。数字签名是认证技术之一，认证主要包括三个方面：消息认证、数字签名、身份认证。而加密和认证时是现代信息安全领域中常见的信息保护手段。

⑶ 数字签名机制和简单加密的区别是什么

数字签名机制和简单加密的区别分别是：

数字签名机制是：所谓数字签名就是附加在数据单元上的一些数据，或是对数据单元所作的密码变换。

这种数据或变换允许数据单元的接收者用以确认数据单元的来源和数据单元的完整性并保护数据，防止被人(例如接收者)进行伪造。

简单加密是：简单加密的基本过程，就是对原来为明文的文件或数据按某种算法进行处理，使其成为不可读的一段代码，通常称为“密文”。通过这样的途径，来达到保护数据不被非法人窃取、阅读的目的。

简单加密方式的种类有：

1、凯撒加密：凯撒密码（Caesar）加密时会将明文中的每个字母都按照其在字母表中的顺序向后（或向前）移动固定数目（循环移动）作为密文。

2、单表代换：随机选取字母代替原来的字母顺序表，故一共有26！-1种可能。

3、一次一密：一次一密乱码本是一个大的不重复的真随机密钥字母集，这个密钥字母集被写在几张纸上，并被粘成一个乱码本。

4、栅栏加密法：栅栏加密法将明文分为若干栏（行），每个栏的字母数量相同与key相同，如meet me after party,首先骂我们去掉空格。

明文就变为meetmeafterparty。一共16个字母，key为4，则我们可以将其分为16/key=4栏，从上到下排列，每栏个字母个数为4。

⑷ 四、公钥和私钥，加密和数字签名

本文涉及到支付宝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）和非对称加密（即公钥和私钥加密）。
非对称加密的主要用途就是：密钥交换（交换对称加密的密钥）和数字签名。

数字签名的作用主要是：确保发送的报文没有被篡改。
数字签名：
1、发送方A对发送的报文M生成一个摘要X1。（大多使用hash）
2、发送方A用自己的私钥加密这个摘要X1。
3、接收方B对使用A的公钥解开这个加密摘要，得到X1。
4、B对比一下接收到的报文M重新生成摘要X2.
如果一样，说明报文M在传递过程没有被修改，的确是A发送的。

而数字证书：就是包含发送方（比如一个网站）公钥、发送方信息的一个文件，该文件被CA所认证过（CA对此进行了数字签名），从而保证发送方是可信的。

⑹ 如何使用加密和数字签名

用非常基本的词汇说，加密是一种以密码方式发送信息的方法。只有拥有正确密钥的人才能解开这个信息的密码。对于其他人来说，这个信息看起来就像是一系列随机的字母、数字和符号。如果你要发送不应该让其他人看的敏感信息时，加密是特别重要的。由于电子邮件是在互联网上发送的，可能被攻击者拦截，对敏感的信息增加一个额外的保护层是很重要的。 同数字签名一样，公共密钥加密使用PGP等软件，使用数学算法转换信息并且依靠公共和专用密钥。但是，加密和数字签名是有区别的，加密的目的是通过把信息翻译成密码秘密地隐藏内容。数字签名的目的是完整性和身份识别性，验证一个信息的发送者和指出内容没有被修改。虽然加密和数字签名能够单独使用，但是，你还可以对加密的信息采用数字签名。 当你签署一个信息时，你使用你的专用密钥，任何有你的公共密钥的人都能够验证这个签名是合法的。当你加密一个信息的时候，你为接收你的信息的人使用这个公共密钥，并且使用他或者她的专用密钥解码这个信息。用于人们要保持自己的专用密钥的机密，并且使用口令保护这些密钥，这个信息的接收者应该是惟一的能够观看这个信息的人。 1.获得你要他能够阅读这个信息的人的公共密钥。如果你从一个公共密钥环得到这个密钥，你可以直接与那个人取得联系，使用密钥验证一系列有关的字母和数字是正确的指纹。 2.使用他们的公共密钥加密这个电子邮件。大多数电子邮件客户端软件都有轻松进行这项工作的功能。 3.当这个人收到这个信息的时候，他或者她将能够对这个信息解密。