更多关于AES参见这里： https://blog.csdn.net/qq_28205153/article/details/55798628
在计算机领域加密是经常用到的技术。
一、加密算法的种类
大致来讲加密算法分为 散列算法、对称加密、非对称加密 三大类。
1、散列算法：
通常用于验证消息的完整性，散列(hash)函数提供了这一功能。他对不同长度的输入消息产生固定长度的输出，常见的算法有MD5、SHA、HMAC等。
2、对称加密：
双方采用同样的秘钥进行加密和解密(可以就这么认为)。实际上这里更准确的表达应该是加密秘钥能够从解密秘钥中推算出来，反之也能推到出来；只不过在大多数对称加密使用中，加密秘钥与解密秘钥是相同的，所以直接这样认为也是没有问题的。由此可见秘钥对对称加密的安全性至关重要，一旦泄露意味着任何人都可以对发送or接受的消息解密。
优点：这种加密方式加密速度非常快(算法公开、计算量小、速度快、效率高)，适合经常发送数据的场合。
缺点：1)双方使用同样的秘钥，安全性得不到保证。2）每对用户每次使用加密算法时都需要使用其他人不知道的唯一秘钥，这会使得收发双方所有用的秘钥数量呈几何级数增长，秘钥管理称为用户负担。3）它要求发送方和接受方在安全通信之前商定出一个秘钥；而秘钥的传输是比较麻烦的。
常用的对称加密算法有AES、DES、3DES、TDEA，Blowfish、RC5、IDEA等算法。
3、非对称加密 亦可参考
(1)与对称加密不同，对于单方向的通信非对称加密算法也需要两个秘钥，公开秘钥和私有秘钥。共有秘钥和私有秘钥是一对。如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；同样如果用私钥加密，公钥也是可以解密的(注:一般用来签名而不是发信息,后面会提到)。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。有了非对称加密的公私钥对，这样通信中仅需传递公钥，甚至公钥可以开放给所有人。需要发消息给我的人使用我的公钥加密后发给我，只有我可以使用私钥解密，其他人不可能获知信息的内容。这只是单方向的加密，双向加密怎么办呢？对方也创建一个公私钥对就可以了。ps：虽然可能出现有人恶意乱发消息过来的情况，但是这并不会有什么严重的负面影响，因为有用的信息并没有泄漏。
非对称加密主要用于两个场景，1)数据传输 和 2)签名。
(2)非对称加密下的通信过程——防止数据被破解
公钥只是用来加密用的，并不用于解密。前面说了公钥和私钥是成对存在的。 举个例子：现有A、B两人要进行通信，如果要实现双向通信，实际上要有两个<公钥,私钥>对。即<A的私钥,A的公钥>与<B的私钥,B的公钥>。过程如下：
A 根据非对称加密算法生成自己的公私钥对（PUBLIC_A，PRIVATE_A）；B 也根据非对称加密算法生成自己的公私钥对（PUBLIC_B，PRIVATE_B）；A 和 B 可以公开的交换自己的公钥（私钥不需要发送，各自保存好即可）；A 使用 B 的公钥 PUBLIC_B 加密信息，发送给 B；B 接收到消息后，使用自己保存的私钥 PRIVATE_B 解密就可以看到消息内容（这条消息即使被他人获得后也是不能解密的）；同样，B 要发消息给 A 时，使用 A 的公钥 PUBLIC_A 加密发出；A 收到消息后使用自己的私钥 PRIVATE_A 解密，这样就实现了双方加密的通信。
显然，对于上述过程即使接受方的公钥泄漏也不会导致信息泄漏，因为密文只有通通过接受方的私钥才能打开。所以信息安全过程中，接受方只需要保证自己的私钥不泄露即可。
(3)数字签名——验证发送者身份与验证数据未被篡改
有了公私钥对后加密加密通信的问题似乎得到了解决。但是又有另外一个新的问题。那就是"A收到消息后如何确认发送者就是B而不是第三方呢？"。其实也很简单；只要发消息前多进行一次使用自己的私钥加密过程就可以了，这次使用自己私钥加密信息的步骤就叫做签名。具体玩法如下。私钥只有自己持有且公私钥之间存在对应关系，即使用B的公钥只能解密出B的私钥加密的东西；因此这个过程就可以当做验证B身份的手段了。(注:这里都假设私钥又被妥善保存)
从主动使用的角度:公钥一般用来加密，私钥用来签名。
还使用上边的例子来看一下使用了加密和签名之后的通信过程：
- A 先使用自己的私钥 PRIVATE_A 对消息进行一遍加密（习惯性称作签名），再使用 B 的公钥 PUBLIC_B 加密信息，然后将加密结果发送给 B。
- B 接收到消息后，使用自己保存的私钥 PRIVATE_B 解密，然后使用 A 的公钥 PUBLIC_A 再解密一遍，如果能解密成功，就可以确保这条消息不是伪造的。
- 同样，B 要发消息给 A 时先使用自己的私钥 PRIVATE_B 对消息进行一遍加密（习惯性称作签名），再使用 A 的公钥 PUBLIC_A 加密后发出。
- A 收到消息后使用自己的私钥 PRIVATE_A 解密，然后使用 B 的公钥 PUBLIC_B 再解密一遍，这样就实现了双方互相确认身份的加密通信。
由于非对称加密是复杂且耗时的，而且需要加密的内容越长就越耗时。在实际使用中一般经过摘要算法得到一串哈希值，然后使用私钥对哈希值进行加密习惯性将这样对摘要使用私钥加密生成的文件叫做签名文件。于是就演化出了目前使用的签名、加密过程，如下：
A 先使用哈希算法将要发送的消息计算出摘要(例如md5值)，再用自己的私钥 PRIVATE_A 对摘要进行签名得到签名文件，然后将原始消息和签名文件打包到一起，使用 B 的公钥 PUBLIC_B 加密信息，发送给 B。B 接收到消息后，使用自己保存的私钥 PRIVATE_B 解密，得到原始消息和一个签名文件。使用哈希算法对原始消息计算得到一个哈希值，再使用 A 的公钥 PUBLIC_A 对签名文件进行解密，得到消息的哈希值，将这两个哈希值进行对比，如果一致就可以认为这条消息是 A 发送的且未经过篡改。
通常加密解密的速度比较慢，适合偶尔发送数据的场合。优点是密钥传输方便。常见的非对称加密算法为RSA、ECC和EIGamal。
(4)公钥与证书——公钥有可能是假的
从上边的流程来看，似乎一切都完美了，但黑客也是绞尽脑汁的，他们还是从中找到了破绽。那就是我们对 A 的身份识别是建立在相信 PUBLIC_A 的公钥确实是 A 的，然而黑客可以轻易的发布自己的公钥宣称这是 A 的公钥来欺骗我们，那我们又怎么样区分呢？这就需要一个机构来保证了，这个机构把 A 提供的公钥和 A 的相关信息放在一起组合成一份证书，这样你从这个机构获取证书，就可以得到有权威机构背书的公钥与 A 的对应关系。
这个机构叫做 CA，发布的证书叫做 CA 证书。
(5)证书授权中心CA——来确保公钥是ok的
CA 证书授权（CertificateAuthority）中心是数字证书发行的唯一机构。
CA 中心又称 CA 机构，即证书授权中心（Certificate Authority），或称证书授权机构，作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。CA 中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA 机构的数字签名使得攻击者不能伪造和篡改证书。在 SET 交易中，CA 不仅对持卡人、商户发放证书，还要对获款的银行、网关发放证书。它负责产生、分配并管理所有参与网上交易的个体所需的数字证书，因此是安全电子交易的核心环节。
CA 证书是逐级保证安全的，最终的根证书内置在操作系统中。由操作系统来保证，这部分下文中会进行介绍。
(6)对称加密与非对称加密的联合使用
由于非对称加密是耗时的，如果在每一次 HTTPS 的数据传输中都使用非对称加密是不合适的。实际上的做法是在第一次建立 HTTPS 连接时使用一次非对称加密传递对称加密的密钥，然后就使用对称加密来保证接下来的通信过程。
HTTPS 的通信过程如下：
浏览器发出 HTTPS 请求。服务器返回本网站的证书。浏览器基于内置在操作系统中的CA证书链对网站证书的有效性进行校验。校验通过后使用证书中的公钥加密一份对称加密的密钥信息，发送给服务端。服务端收到信息后使用自己的私钥解密信息，得到浏览器提供的用于对称加密的密钥信息。之后的通信过程就使用这个对称加密的密钥来保护。
参考：https://www.cnblogs.com/traditional/p/12693249.html 强烈推荐。。。。
今天这里讨论的是对称加密中的AES加密(这里)。
高级加密标准(AES,Advanced Encryption Standard)为最常见的对称加密算法(微信小程序加密传输就是用这个加密算法的)。对称加密算法也就是加密和解密用相同的密钥，具体的加密流程如下图：
AES加密方式有五种：ECB, CBC, CTR, CFB, OFB
从安全性角度推荐CBC加密方法，本文介绍了CBC,ECB两种加密方法的python实现
python 在 Linux下使用AES时要安装的是pycrypto模块 pip install pycrypto
CBC加密需要一个十六位的key(密钥)和一个十六位iv(偏移量)
ECB加密不需要iv
https://zhuanlan.zhihu.com/p/49494990
https://www.cnblogs.com/niuu/p/10107212.html AES加密的python实现
标签：公钥,私钥,解密,秘钥,使用,对称,非对称,加密 来源： https://blog.csdn.net/mijichui2153/article/details/118822978
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。