① 数据加密和数据签名的原理作用
加密可以帮助保护数据不被查看和修改，并且可以帮助在本不安全的信道上提供安全的通信方式。例如，可以使用加密算法对数据进行加密，在加密状态下传输数据，然后由预定的接收方对数据进行解密。如果第三方截获了加密的数据，解密数据是很困难的。
在一个使用加密的典型场合中，双方（小红和小明）在不安全的信道上通信。小红和小明想要确保任何可能正在侦听的人无法理解他们之间的通信。而且，由于小红和小明相距遥远，因此小红必须确保她从小明处收到的信息没有在传输期间被任何人修改。此外，她必须确定信息确实是发自小明而不是有人模仿小明发出的。
加密用于达到以下目的：
保密性：帮助保护用户的标识或数据不被读取。
数据完整性：帮助保护数据不更改。
身份验证：确保数据发自特定的一方。
为了达到这些目的，您可以使用算法和惯例的组合（称作加密基元）来创建加密方案。下表列出了加密基元及它们的用法。
加密基元 使用
私钥加密（对称加密） 对数据执行转换，使第三方无法读取该数据。此类型的加密使用单个共享的机密密钥来加密和解密数据。
公钥加密（不对称加密） 对数据执行转换，使第三方无法读取该数据。此类加密使用公钥/私钥对来加密和解密数据。
加密签名 通过创建对特定方唯一的数字签名来帮助验证数据是否发自特定方。此过程还使用哈希函数。
加密哈希 将数据从任意长度映射为定长字节序列。哈希在统计上是唯一的；不同的双字节序列不会哈希为同一个值。
私钥加密
私钥加密算法使用单个私钥来加密和解密数据。由于具有密钥的任意一方都可以使用该密钥解密数据，因此必须保护密钥不被未经授权的代理得到。私钥加密又称为对称加密，因为同一密钥既用于加密又用于解密。私钥加密算法非常快（与公钥算法相比），特别适用于对较大的数据流执行加密转换。
通常，私钥算法（称为块密码）用于一次加密一个数据块。块密码（如 RC2、DES、TrippleDES 和 Rijndael）通过加密将 n 字节的输入块转换为加密字节的输出块。如果要加密或解密字节序列，必须逐块进行。由于 n 很小（对于 RC2、DES 和 TripleDES，n = 8 字节；n = 16 [默认值]；n = 24；对于 Rijndael，n = 32），因此必须对大于 n 的值一次加密一个块。
基类库中提供的块密码类使用称作密码块链 (CBC) 的链模式，它使用一个密钥和一个初始化向量 (IV) 对数据执行加密转换。对于给定的私钥 k，一个不使用初始化向量的简单块密码将把相同的明文输入块加密为同样的密文输出块。如果在明文流中有重复的块，那么在密文流中将存在重复的块。如果未经授权的用户知道有关明文块的结构的任何信息，就可以使用这些信息解密已知的密文块并有可能发现您的密钥。若要克服这个问题，可将上一个块中的信息混合到加密下一个块的过程中。这样，两个相同的明文块的输出就会不同。由于该技术使用上一个块加密下一个块，因此使用了一个 IV 来加密数据的第一个块。使用该系统，未经授权的用户有可能知道的公共消息标头将无法用于对密钥进行反向工程。
可以危及用此类型密码加密的数据的一个方法是，对每个可能的密钥执行穷举搜索。根据用于执行加密的密钥大小，即使使用最快的计算机执行这种搜索，也极其耗时，因此难以实施。使用较大的密钥大小将使解密更加困难。虽然从理论上说加密不会使对手无法检索加密的数据，但这确实极大增加了这样做的成本。如果执行彻底搜索来检索只在几天内有意义的数据需要花费三个月的时间，那么穷举搜索的方法是不实用的。
私钥加密的缺点是它假定双方已就密钥和 IV 达成协议，并且互相传达了密钥和 IV 的值。并且，密钥必须对未经授权的用户保密。由于存在这些问题，私钥加密通常与公钥加密一起使用，来秘密地传达密钥和 IV 的值。
假设小红和小明是要在不安全的信道上进行通信的双方，他们可能按以下方式使用私钥加密。小红和小明都同意使用一种具有特定密钥和 IV 的特定算法（如 Rijndael）。小红撰写一条消息并创建要在其上发送该消息的网络流。接下来，她使用该密钥和 IV 加密该文本，并通过 Internet 发送该文本。她没有将密钥和 IV 发送给小明。小明收到该加密文本并使用预先商定的密钥和 IV 对它进行解密。如果传输的内容被人截获，截获者将无法恢复原始消息，因为截获者并不知道密钥或 IV。在这个方案中，密钥必须保密，但 IV 不需要保密。在一个实际方案中，将由小红或小明生成私钥并使用公钥（不对称）加密将私钥（对称）传递给对方。有关更多信息，请参见本主题后面的有关公钥加密的部分。
.NET Framework 提供以下实现私钥加密算法的类：
DESCryptoServiceProvider
RC2CryptoServiceProvider
RijndaelManaged
公钥加密
公钥加密使用一个必须对未经授权的用户保密的私钥和一个可以对任何人公开的公钥。公钥和私钥都在数学上相关联；用公钥加密的数据只能用私钥解密，而用私钥签名的数据只能用公钥验证。公钥可以提供给任何人；公钥用于对要发送到私钥持有者的数据进行加密。两个密钥对于通信会话都是唯一的。公钥加密算法也称为不对称算法，原因是需要用一个密钥加密数据而需要用另一个密钥来解密数据。
公钥加密算法使用固定的缓冲区大小，而私钥加密算法使用长度可变的缓冲区。公钥算法无法像私钥算法那样将数据链接起来成为流，原因是它只可以加密少量数据。因此，不对称操作不使用与对称操作相同的流模型。
双方（小红和小明）可以按照下列方式使用公钥加密。首先，小红生成一个公钥/私钥对。如果小明想要给小红发送一条加密的消息，他将向她索要她的公钥。小红通过不安全的网络将她的公钥发送给小明，小明接着使用该密钥加密消息。（如果小明在不安全的信道如公共网络上收到小红的密钥，则小明必须同小红验证他具有她的公钥的正确副本。）小明将加密的消息发送给小红，而小红使用她的私钥解密该消息。
但是，在传输小红的公钥期间，未经授权的代理可能截获该密钥。而且，同一代理可能截获来自小明的加密消息。但是，该代理无法用公钥解密该消息。该消息只能用小红的私钥解密，而该私钥没有被传输。小红不使用她的私钥加密给小明的答复消息，原因是任何具有公钥的人都可以解密该消息。如果小红想要将消息发送回小明，她将向小明索要他的公钥并使用该公钥加密她的消息。然后，小明使用与他相关联的私钥来解密该消息。
在一个实际方案中，小红和小明使用公钥（不对称）加密来传输私（对称）钥，而对他们的会话的其余部分使用私钥加密。
公钥加密具有更大的密钥空间（或密钥的可能值范围），因此不大容易受到对每个可能密钥都进行尝试的穷举攻击。由于不必保护公钥，因此它易于分发。公钥算法可用于创建数字签名以验证数据发送方的身份。但是，公钥算法非常慢（与私钥算法相比），不适合用来加密大量数据。公钥算法仅对传输很少量的数据有用。公钥加密通常用于加密一个私钥算法将要使用的密钥和 IV。传输密钥和 IV 后，会话的其余部分将使用私钥加密。
.NET Framework 提供以下实现公钥加密算法的类：
DSACryptoServiceProvider
RSACryptoServiceProvider
数字签名
公钥算法还可用于构成数字签名。数字签名验证发送方的身份（如果您信任发送方的公钥）并帮助保护数据的完整性。使用由小红生成的公钥，小红的数据的接收者可以通过将数字签名与小红的数据和小红的公钥进行比较来验证是否是小红发送了该数据。
为了使用公钥加密对消息进行数字签名，小红首先将哈希算法应用于该消息以创建消息摘要。该消息摘要是数据的紧凑且唯一的表示形式。然后，小红用她的私钥加密该消息摘要以创建她的个人签名。在收到消息和签名时，小明使用小红的公钥解密签名以恢复消息摘要，并使用与小红所使用的相同的哈希算法来散列消息。如果小明计算的消息摘要与从小红那里收到的消息摘要完全一致，小明就可以确定该消息来自私钥的持有人，并且数据未被修改过。如果小明相信小红是私钥的持有人，则他知道该消息来自小红。
请注意，由于发送方的公钥为大家所周知，并且它通常包含在数字签名格式中，因此任何人都可以验证签名。此方法不保守消息的机密；若要使消息保密，还必须对消息进行加密。
.NET Framework 提供以下实现数字签名算法的类：
DSACryptoServiceProvider
RSACryptoServiceProvider
哈希值
哈希算法将任意长度的二进制值映射为固定长度的较小二进制值，这个小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式。如果散列一段明文而且哪怕只更改该段落的一个字母，随后的哈希计算都将产生不同的值。要找到散列为同一个值的两个不同的输入，在计算上是不可能的。
消息身份验证代码 (MAC) 哈希函数通常与数字签名一起用于对数据进行签名，而消息检测代码 (MDC) 哈希函数则用于数据完整性。
双方（小红和小明）可按下面的方式使用哈希函数来确保数据的完整性。如果小红对小明编写一条消息并创建该消息的哈希，则小明可以在稍后散列该消息并将他的哈希与原始哈希进行比较。如果两个哈希值相同，则该消息没有被更改；如果值不相同，则该消息在小红编写它之后已被更改。为了使此系统发挥作用，小红必须对除小明外的所有人保密原始的哈希值。
.NET Framework 提供以下实现数字签名算法的类：
HMACSHA1
MACTripleDES
MD5CryptoServiceProvider
SHA1Managed
SHA256Managed
SHA384Managed
SHA512Managed
随机数生成
随机数生成是许多加密操作不可分割的组成部分。例如，加密密钥需要尽可能地随机，以便使生成的密钥很难再现。加密随机数生成器必须生成无法以计算方法推算出（低于 p < .05 的概率）的输出；即，任何推算下一个输出位的方法不得比随机猜测具有更高的成功概率。.NET Framework 中的类使用随机数生成器生成加密密钥。
RNGCryptoServiceProvider 类是随机数生成器算法的实现。
② 手机相册加密1234为什么打不开提示也是1234
因为手机卡住了，你可以试试重新启动。
③ 加密、签名、证书的作用及运用场景
本文主要是简单介绍了常见的加密类型、各自的运用场景、为什么需要数字签名和数字证书、HTTPS涉及到的加密流程等。这里主要从使用者的角度出发，对算法本身不做过多介绍。
对称/非对称加密均属于 可逆加密，可以通过密钥将密文还原为明文 。
有时候，我们希望明文一旦加密后，任何人（包括自己）都无法通过密文逆推回明文，不可逆加密就是为了满足这种需求。
不可逆加密主要通过 hash算法实现：即对目标数据生成一段特定长度hash值 ；无论你的数据是1KB、1MB、1GB，都是生成特定长度的一个Hash值（比如128bit）。这里大家应该能感受到一点 不可逆 的味道，加密后128bit的hash值显然无法还原出1个G甚至更大的不规则数据的， hash可以看做是原来内容的一个摘要 。
常见算法：
小明给小红写信：
经过九转十八弯后，信的内容有可能：1. 被窥视 2. 被篡改（冒充小明发送假消息） ：
小红先 生成对称加密的密钥key1 ，然后通过一个安全的渠道交予小明。
传输数据时，小明 使用key1加密 ，而小红收到后再 使用key1解密 。
这时候 中间者既看不到原来的内容，也没办法篡改 （因为没有密钥）：
【对称加密】实现简单，性能优秀 ，算法本身安全级别高。然而对 密钥的管理 却是个很头疼的问题：一旦密钥交到对方手里，对方对密钥的保管能力 我方是没办法控制 的，一旦对方泄露的话，加密就形同虚设了。
相对而言，【非对称加密】的公钥就没有这个忧虑，因为 公钥 的设计就是为了 可以公开的 ，尽管对方泄露，我方也不会有任何损失。
小红生成一对公私钥，自己持有私钥（pri_key1），将公钥（pub_key1）交予小明。
传输数据时，小明使用 公钥加密 ，小红使用 私钥解密 。
因为 中间者没有私钥，公钥加密的内容是无法获取的 。此时达到了 防窥视 的效果：
然而因为 公钥是可以公开的 ，如果 中间者知晓公钥 的话，尽管没有办法看到原来的内容，却 可以冒充小明发送假消息 ：
这时小红在想，如果小明发送消息时，能带上 只有他自己才能生成 的数据（字符串），我就能 验证是不是小明发的真实消息 了。
通常这个 能证实身份的数据（字符串） 被称之为 数字签名（Signature）
小明再生成一对公私钥 ，自己持有私钥（pri_key2），将公钥交予小红（pub_key2）。
当小明传输数据时（可能很大），除了公钥加密明文之外，还要带上签名：(1) 对明文做一个hash摘要 (2)对摘要进行私钥加密，加密结果即签名（传输内容=内容密文+签名）
小红收到后：(1) 解密签名获取hash (2)解密内容密文，对解密后的明文进行hash；如果两个hash一致，说明验签通过。
尽管中间者修改了传输内容，但因为签名无法冒认（没有私钥），小红验签失败，自然不会认可这份数据：
通常 非对称加密要做到防窥视和防篡改，需要有两对公私钥 ：对方的公钥用于内容加密，自己的私钥用于签名（让对方验证身份）。
因为HTTP协议明文通信的安全问题，引入了HTTPS：通过建立一个安全通道（连接），来保证数据传输的安全。
服务器是 没办法直接将密钥传输到浏览器的 ，因为在 安全连接建立之前，所有通信内容都是明文的 ，中间者可窥视到密钥信息。
或许这时你想到了非对称加密，因为公钥是不怕公开的：
然而在第2步， 中间者可以截取服务器公钥，并替换成了自己的公钥 ，此时加密就没意义了：
为了 防止公钥被假冒，数字证书（digital certificate ）便诞生了 。
当服务器需要告诉浏览器公钥时，并不是简单地返回公钥，而是响应 包含公钥信息在内的数字证书 。
证书主要包含以下内容：
浏览器通过 【颁发机构的公钥】进行解密验签 ，验签通过即说明证书的真实性，可以放心取 证书拥有者的公钥 了。（ 常用CA机构的公钥都已经植入到浏览器里面 ）
数字证书只做一件事： 保证 服务器响应的 公钥是真实的 。
以上保证了 [浏览器⇒服务器] 是加密的，然而 [服务器⇒浏览器] 却没有（上图第4步）；另外一个是 性能问题 ，如果所有数据都使用非对称加密的话，会消耗较多的服务器资源，通信速度也会受到较大影响。
HTTPS巧妙地结合了非对称加密和对称加密，在保证双方通信安全的前提下，尽量提升性能。
HTTPS（SSL/TLS）期望 建立安全连接后，通信均使用【对称加密】 。
建立安全连接的任务就是让 浏览器-服务器协商出本次连接使用的【对称加密的算法和密钥】 ；协商过程中会使用到【非对称加密】和数字证书。
特别注意的是：协商的密钥必须是不容易猜到（足够随机的）：
其中比较核心的是随机数r3（pre-master secret），因为之前的r1、r2都是明文传输的， 只有r3是加密传输 的。至于为什么需要三个随机数，可以参考：
以上是一个比较简单的HTTPS流程，详细的可以参考文末的引用。
参考资料：
[1] 数字证书应用综合揭秘
[2] SSL/TLS协议运行机制的概述
[3] 图解SSL/TLS协议
[4] 《图解HTTP》
④ 关于公私钥、各种证书、https基本概念扫盲
最近实习需要写一些生成证书的脚本，借此机会顺便搞清楚了许多关于证书这块的疑惑。说到这一块东西，名词多到爆炸，对称加密、非对称加密、密钥、密钥库、公钥、私钥、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中私钥文件
而不同的证书文件后缀都是为了区分不同种类的证书的，主要有俩个分类维度
⑤ 四、公钥和私钥，加密和数字签名
本文涉及到支付宝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的， 千万不要觉得订单信息的加签过程也可以放在客户端完成 。
假设我们服务端收到了来自支付宝服务端的支付结果，即： 支付结果+数字签名 。
那么我们服务端就会对支付结果进行验签，怎么个验法呢？
⑥ flow3d安装一直在keydrivers
在安装Flow3D软件时，如果安装程序一直停留在“keydrivers”阶段，可能是由于以下原因：
1. 未正确安装或未更新驱动程序。Flow3D软件需要与计算机的图形卡进行通信，因此需要安装正确的驱动程序。如果您的计算机没有正确安装或更新驱动程序，那么安装程序可能会在keydrivers阶段卡住。
2. 计算机硬件不符合要求。Flow3D软件需要计算机硬件来提供足够的计算能力，以便进行流体动力学模拟计算。如果您的计算蠢老机硬件不符合Flow3D软件的最低硬件要求，那么安装程序可能会在keydrivers阶段卡住。
3. 安装程序本身存在问题。有时，安装程序本身可能存在错误或损坏，这可能会导致安装程序在keydrivers阶段卡住。
为了解决这个问宴档芹题，您可以尝试以下步骤：
1. 确保您的计算机已正确安装或更新了最新的驱动程序。您可以通过访问图形卡制造商的网站来下载和安装最新的驱动程序。
2. 确保您的计算机符合Flow3D软件的最低硬件要求。您可以在Flow3D软件的官方网站上查看最低硬件要求。
3. 尝试重新下载和安装Flow3D软件。确保您下载的安装程序没有损坏，并且您已经按照安装程序提供的说明正确安装了软件。晌毕
同时，建议您在安装Flow3D软件之前备份您的计算机数据，以防止数据丢失。
⑦ 4. 小明为了方便记忆,把自己的生日设成电脑密码,安全吗
不是很安全。
将密码设置成生日很容易被人破解。
密码是一种用来混淆的技术，它希望将正常的信息转变为无法识别的信息。当然，对一小部分人来说，这种无法识别的信息是可以再加工并恢复的。密码在中文里是"口令"的通称。登录网站、电子邮箱和银行取款时输入的"密码"其实严格来讲应该仅被称作"口令"，因为它不是本来意义上的"加密代码"，但是也可以称为秘密的号码。主要限定于个别人理解的符号系统。如密码电报、密码式打字机。
⑧ 小明q1迷你投影仪密码是多少啊
初始密码为1234.
根据什么值得买网中的相关信息，小明q1迷你悄咐投影仪综合来看是一款性价比非常启滚纯高的入门投影设备，很适合年轻人自由、有追求的生活所需，而此设备的初始密码为1234。
小明Q1迷你投影仪的外观造型非常有个性，相比较“毫无感情”、冷冰冰的方盒子一般的常规投影仪，此作做工比较精细，配合没有棱角的圆润机身和硕大的光源，又萌又可爱，隐约有一种“大眼萌”的备枣既视感。
⑨ 易语言加密解密问题,是bug吗为什么1234解密不出来,还有些也解不出来 .
应该不是漏洞，以下是我对你的源码的改正：
.版本 2
.支持库 dp1
.子程序 BASE64编码, 文本型, , BASE64编码处理(返回编码后的文本)
.参数 待编码数据, 字节集, , 待编码字节集
.局部变量 余数
.局部正升变量 临时, 字节型, , "3"
.局部变量 变量
.局部变量 集合, 字节集
.局部变量 长度, 整数型
.局部变量 字符, 字节集
.局部变量 i
长度 ＝ 取字节集长度 (待编码数据)
.如果真 (长度 ＜ 1)
返回 (“”)
.如果真结束
余数 ＝ 长度 ％ 3
.如果真 (余数 ＞ 0)
待编码数据 ＝ 待编码数据 ＋ 取空白字节集 (3 － 余数)
.如果真结束
长度 ＝ 取字节集长度 (待编码数据)
字符 ＝ 取空白字节集 (长度 × 4 ÷ 3)
i ＝ 1
集合 ＝ 到字节集 (“+/”)
.变量循环首 (1, 长度, 3, 变量)
临时 [1] ＝ 待编码数据 [变量]
临时 [2] ＝ 待编码数据 [变量 ＋ 1]
临时 [3] ＝ 待编码数裂丛据 [变量 ＋ 2]
字符 [i] ＝ 集合 [右移 (临时 [1], 2) ＋ 1]
字符 [i ＋ 1] ＝ 集合 [左移 (位与 (临时 [1], 3), 4) ＋ 右移 (临时 [2], 4) ＋ 1]
字符 [i ＋ 2] ＝ 集合 [左移 (位与 (临时 [2], 15), 2) ＋ 右移 (临时 [3], 6) ＋ 1]
字符 [i ＋ 3] ＝ 集合 [位与 (临时 [3], 63) ＋ 1]
i ＝ i ＋ 4
.变量循环尾 ()
.如果真 (余数 ＞ 0)
长度 ＝ 取字节集长度 (字符)
.如果 (余数 ＝ 1)
字符 [长度 － 1] ＝ 取代码 (“=”, )
字符 [长度] ＝ 取代码 (“=”, )
.否则
字符 [长度] ＝ 取代码 (“=”, )
.如果结束
.如果真结束
返回 (到文本 (字符))
.子程序 BASE64解码, 字节集, , BASE64解码处理(返回解码后的字节集数据)
.参数 编码文本, 文本型, 参考, 待解码的文本
.局部变量 文本长度
.局部变量 整倍数
.局部变量 三字节组, 字节型, , "3"
.局部变量 四字节组, 字节型, , "4"
.局部变量 编码值
.局部变量 X
.局部变量 n
.局部变量 二进制数据, 字节集
编码文本 ＝ 删全部空 (编码文本)
编码文本 ＝ 子文本替换 (编码文本, #换行符, , , , 真)
文本长度 ＝ 取文本长度 (编码文本)
整倍数 ＝ 文本长度 ＼ 4
.如果真 (文本长度 ％ 4 ≠ 0)
整倍数 ＝ 整倍数 ＋ 1
.如果真结束
.计次循环首 (整倍数, X)
.计次循环首 (4, n)
四字节组 [n] ＝ 取代码 (编码文本, (X － 1) × 4 ＋ n)
编码值 ＝ 寻找文本 (“+/”, 字符 (四字节组 [n]), , 假)
.如果真 (编码值 ＝ -1)
跳出循环 ()
.如果真结束
四字节组 [n] ＝ 编码值 － 1
.计次循环尾 ()
三字节组 [1] ＝ 位或 (四字节组 [1] × 4, 四字节组 [2] ÷ 16)
三字节组 [2] ＝ 位或 (四字节肆清樱组 [2] × 16, 四字节组 [3] ÷ 4)
三字节组 [3] ＝ 位或 (四字节组 [3] × 64, 四字节组 [4])
二进制数据 ＝ 二进制数据 ＋ 到字节集 (三字节组)
处理事件 ()
.计次循环尾 ()
.如果真 (n ＜ 5) ' 最后一组4字符是提前退出的,截取字节集
n ＝ 5 － n
二进制数据 ＝ 取字节集左边 (二进制数据, 取字节集长度 (二进制数据) － n)
.如果真结束
返回 (二进制数据)
.子程序 _按钮1_被单击
编辑框2.内容 ＝ BASE64编码 (加密数据 (到字节集 (编辑框1.内容), “123”, 1))
.子程序 _按钮2_被单击
编辑框3.内容 ＝ 到文本 (解密数据 (BASE64解码 (编辑框2.内容), “123”, 1))
⑩ 图文彻底搞懂非对称加密（公钥密钥）
前文详细讲解了对称加密及算法原理。那么是不是对称加密就万无一失了呢？对称加密有一个天然的缺点，就是加密方和解密方都要持有同样的密钥。你可以能会提出疑问：既然要加、解密，当然双方都要持有密钥，这有什么问题呢？别急，我们继续往下看。
我们先看一个例子，小明和小红要进行通信，但是不想被其他人知道通信的内容，所以双方决定采用对称加密的方式。他们做了下面的事情：
1、双方商定了加密和解密的算法
2、双方确定密钥
3、通信过程中采用这个密钥进行加密和解密
这是不是一个看似完美的方案？但其中有一个步骤存在漏洞！
问题出在步骤2：双方确定密钥！
你肯定会问，双方不确定密钥，后面的加、解密怎么做？
问题在于确定下来的密钥如何让双方都知道。密钥在传递过程中也是可能被盗取的！这里引出了一个经典问题：密钥配送问题。
小明和小红在商定密钥的过程中肯定会多次沟通密钥是什么。即使单方一次确定下来，也要发给对方。加密是为了保证信息传输的安全，但密钥本身也是信息，密钥的传输安全又该如何保证呢？难不成还要为密钥的传输再做一次加密？这样不就陷入了死循环？
你是不是在想，密钥即使被盗取，不还有加密算法保证信息安全吗？如果你真的有这个想法，那么赶紧复习一下上一篇文章讲的杜绝隐蔽式安全性。任何算法最终都会被破译，所以不能依赖算法的复杂度来保证安全。
小明和小红现在左右为难，想加密就要给对方发密钥，但发密钥又不能保证密钥的安全。他们应该怎么办呢？
有如下几种解决密钥配送问题的方案：
非对称加密也称为公钥密码。我更愿意用非对称加密这种叫法。因为可以体现出加密和解密使用不同的密钥。
对称加密中，我们只需要一个密钥，通信双方同时持有。而非对称加密需要4个密钥。通信双方各自准备一对公钥和私钥。其中公钥是公开的，由信息接受方提供给信息发送方。公钥用来对信息加密。私钥由信息接受方保留，用来解密。既然公钥是公开的，就不存在保密问题。也就是说非对称加密完全不存在密钥配送问题！你看，是不是完美解决了密钥配送问题？
回到刚才的例子，小明和下红经过研究发现非对称加密能解决他们通信的安全问题，于是做了下面的事情：
1、小明确定了自己的私钥 mPrivateKey，公钥 mPublicKey。自己保留私钥，将公钥mPublicKey发给了小红
2、小红确定了自己的私钥 hPrivateKey，公钥 hPublicKey。自己保留私钥，将公钥 hPublicKey 发给了小明
3、小明发送信息 “周六早10点soho T1楼下见”，并且用小红的公钥 hPublicKey 进行加密。
4、小红收到信息后用自己的私钥 hPrivateKey 进行解密。然后回复 “收到，不要迟到” 并用小明的公钥mPublicKey加密。
5、小明收到信息后用自己的私钥 mPrivateKey 进行解密。读取信息后心里暗想：还提醒我不迟到？每次迟到的都是你吧？
以上过程是一次完整的request和response。通过这个例子我们梳理出一次信息传输的非对称加、解密过程：
1、消息接收方准备好公钥和私钥
2、私钥接收方自己留存、公钥发布给消息发送方
3、消息发送方使用接收方公钥对消息进行加密
4、消息接收方用自己的私钥对消息解密
公钥只能用做数据加密。公钥加密的数据，只能用对应的私钥才能解密。这是非对称加密的核心概念。
下面我用一个更为形象的例子来帮助大家理解。
我有下图这样一个信箱。
由于我只想接收我期望与之通信的朋友信件。于是我在投递口加了一把锁，这把锁的钥匙（公钥）我可以复制n份，发给我想接受其信件的人。只有这些人可以用这把钥匙打开寄信口，把信件投入。
相信通过这个例子，可以帮助大家彻底理解公钥和私钥的概念。
RSA 是现在使用最为广泛的非对称加密算法，本节我们来简单介绍 RSA 加解密的过程。
RSA 加解密算法其实很简单：
密文=明文^E mod N
明文=密文^D mod N
RSA 算法并不会像对称加密一样，用玩魔方的方式来打乱原始信息。RSA 加、解密中使用了是同样的数 N。公钥是公开的，意味着 N 也是公开的。所以私钥也可以认为只是 D。
我们接下来看一看 N、E、D 是如何计算的。
1、求 N
首先需要准备两个很大质数 a 和 b。太小容易破解，太大计算成本太高。我们可以用 512 bit 的数字，安全性要求高的可以使用 1024，2048 bit。
N=a*b
2、求 L
L 只是生成密钥对过程中产生的数，并不参与加解密。L 是 (a-1) 和 (b-1) 的最小公倍数
3、求 E（公钥）
E 有两个限制：
1<E<
E和L的最大公约数为1
第一个条件限制了 E 的取值范围，第二个条件是为了保证有与 E 对应的解密时用到的 D。
4、求 D（私钥）
D 也有两个限制条件：
1<D<L
E*D mod L = 1
第二个条件确保密文解密时能够成功得到原来的明文。
由于原理涉及很多数学知识，这里就不展开细讲，我们只需要了解这个过程中用到这几个数字及公式。这是理解RSA 安全性的基础。
由于 N 在公钥中是公开的，那么只需要破解 D，就可以解密得到明文。
在实际使用场景中，质数 a,b 一般至少1024 bit，那么 N 的长度在 2048 bit 以上。D 的长度和 N 接近。以现在计算机的算力，暴力破解 D 是非常困难的。
公钥是公开的，也就是说 E 和 N 是公开的，那么是否可以通过 E 和 N 推断出 D 呢？
E*D mod L = 1
想要推算出 D 就需要先推算出 L。L 是 (a-1) 和 (b-1) 的最小公倍数。想知道 L 就需要知道质数 a 和 b。破解者并不知道这两个质数，想要破解也只能通过暴力破解。这和直接破解 D 的难度是一样的。
等等，N 是公开的，而 N = a*b。那么是否可以对 N 进行质因数分解求得 a 和 b 呢？好在人类还未发现高效进行质因数分解的方法，因此可以认为做质因数分解非常困难。
但是一旦某一天发现了快速做质因数分解的算法，那么 RSA 就不再安全
我们可以看出大质数 a 和 b 在 RSA 算法中的重要性。保证 a 和 b 的安全也就确保了 RSA 算法的安全性。a 和 b 是通过伪随机生成器生成的。一旦伪随机数生成器的算法有问题，导致随机性很差或者可以被推断出来。那么 RSA 的安全性将被彻底破坏。
中间人攻击指的是在通信双方的通道上，混入攻击者。他对接收方伪装成发送者，对放送放伪装成接收者。
他监听到双方发送公钥时，偷偷将消息篡改，发送自己的公钥给双方。然后自己则保存下来双方的公钥。
如此操作后，双方加密使用的都是攻击者的公钥，那么后面所有的通信，攻击者都可以在拦截后进行解密，并且篡改信息内容再用接收方公钥加密。而接收方拿到的将会是篡改后的信息。实际上，发送和接收方都是在和中间人通信。
要防范中间人，我们需要使用公钥证书。这部分内容在下一篇文章里会做介绍。
和对称加密相比较，非对称加密有如下特点：
1、非对称加密解决了密码配送问题
2、非对称加密的处理速度只有对称加密的几百分之一。不适合对很长的消息做加密。
3、1024 bit 的 RSA不应该在被新的应用使用。至少要 2048 bit 的 RSA。
RSA 解决了密码配送问题，但是效率更低。所以有些时候，根据需求可能会配合使用对称和非对称加密，形成混合密码系统，各取所长。
最后提醒大家，RSA 还可以用于签名，但要注意是私钥签名，公钥验签。发信方用自己的私钥签名，收信方用对方公钥验签。关于签名，后面的文章会再详细讲解。