加密（Encryption）就是通过某种方法将可以被理解的数据信息隐藏起来并生成不可被理解的数据信息。可理解的数据信息通常称之为明文（Plain Text），而隐藏了明文的不可被理解的数据信息被称之为密文（Cipher）。至于解密（Decryption），则恰好相反，它是将密文转变为明文的过程，将被隐藏的信息从不可被理解的数据信息中还原出来。
加密解密的历史甚为久远，早在古代就出现了采用字符替代或者字符移位等方式来书写信件，以实现隐藏信息，避免在人工递送书信的过程中，书信被截获而导致信息泄漏。而时至数字化的今日，网络传递信息变得日益频繁，也就有这那么些人想着如何编制更强壮的密码以保守通信信息的就成立了编码学（Cryptography），也有出于正义或者使坏目的的成立了分析学（Cryptanalysis）旨在破译密码以获取通信信息。编码学和分析学总的来说就是密码学（Cryptology）了。
密码学最大的成就在于加解密算法的研究上。当前加解密算法分为三大类：对称加密、非对称加密以及信息摘要。
- 对称加密：又称为私钥加密、共享密钥加密，其算法特点在于加密和解密时使用的是相同的密钥（或者这个密钥可以在加密和解密方相互推算出来）。其优势在于加解密速度最快，关键点在于加密方和解密方共同持有相同的密钥。万一密钥泄漏了，和在网上裸奔没啥区别了，所以它适用于两个或者少数几个成员间共同持有，作为私密专属通信密钥。其中对称加密可以再细分为：序列加密和分组加密；序列加密就是通过某个初始密钥生成一个密钥流，然后明文流和密钥流进行加密生成密文流；而分组加密就是将明文等长划分开来，然后将每个块和密钥进行独立或者关联性地加密。
- 非对称加密：也称之为公开密钥加密，特点是它拥有两个密钥，任意一个密钥都可以对信息进行加密处理，但是解密就需要用到另外一个密钥才能解析出正确的明文，也就是说加密的密钥是没法对密文进行正确的解密。至于他怎么实现的，这是数学问题了，这里不展开细述。该算法类比对称加密使用的相同的密钥去加解密，所以称之为非对称加密。其优势在于可以毫无顾忌地公开其中一个密钥出去（公开出去的称之为公开密钥，简称公钥），而自己保留另一个（保留下来的称之为私有密钥，简称私钥），由此可以确保收到的信息不会被窃听到（发出去的就没法保证了），其弊端在于性能不高。
- 信息摘要：也称之为数字摘要，主要是通过单向的Hash处理转换，将明文信息转换为固定长度的摘要信息。特点就是不需要密钥就可以进行加密了，但是摘要数据是无法被解密的。所以谈不上是加解密算法，或者只能说是单向加密算法。优势在于相同的明文经过相同的算法处理才会得到相同的密文，密文具有“唯一性”（完全不同的明文，密文相同是存在的，但是优秀的算法可以将这概率降到最低），总体上内容相近的明文是不会有相同的密文的，由此可以作为信息完整性的校验。
简单将算法分类以及算法代表进行了脑图分类。
那么加密算法是如何在安全通信中应用的呢？怎么算是安全通信呢？这是一个没有绝对的标准，不同的角度出发会有不同的答案。借用微软开发的STRIDE威胁建模推导一下安全通信会有哪些问题需要处理的。STRIDE威胁建模是指从6个维度去分析：
- Spoofing（伪装）
- Tampering（篡改）
- Repudiation（抵赖）
- Information Disclosure（信息泄露）
- Denial of Service（拒绝服务）
- Elevation of Privilege（提升权限）
每个维度的定义和对应的安全要求有：
| 威胁 | 定义 | 对应的安全诉求 |
| Spoofing | 冒充他人身份 | 认证 |
| Tampering | 修改数据或代码 | 完整性 |
| Repudiation | 否认做过的事 | 不可抵赖性 |
| Information Disclosure | 机密信息泄露 | 机密性 |
| Denial of Service | 拒绝服务 | 可用性 |
| Elevation of Privilege | 未经授权获得许可 | 授权 |
那么可以推导安全通信的诉求应该就有：完整性，通信的内容信息必须要完整，不可被篡改掉或者存在数据丢失；机密性，通信的内容必须要得到有效的隐藏和保护，避免被泄漏第三方；认证性，包括实体认证和消息认证，其中实体认证是指通信的发送方和接收方是可信的未被假冒的，而消息认证是指消息是由认证过的实体用户发出的，不是被仿冒者发出的；不可抵赖性，通信的数据携带有实体特质、不可被模仿复制的信息，确保通信数据是可确认的实体发出的。
为了保证安全通信，前面列举的三类加密算法悉数用上了。
首先是通信数据的完整性，在此信息摘要算法发挥了重要作用，它的摘要密文唯一性，能够保证信息被篡改后可被发现。实际中，为了完整性，还对摘要密文进行了加密操作，这里的加密用的是对称加密算法，密钥来自于通信会话的密钥。那么“通信消息+信息摘要+对称加密=数据验证码”的做法，就是通信中常见的MAC（Message Authorization Code，消息认证码）的实现。
接着是通信数据的机密性，这里选择了使用对称加密算法，为什么没有选择非对称加密算法？因为对称加密算法的性能远优于非对称加密算法，尤其是通信频繁以及信息数据较多的情况下，使用非对称加密算法会消耗大量的CPU资源。当然更不可能选择不可解析的信息摘要算法。那么为了机密性，通信的双方都必须维护一个对称加密的密钥？对于一个服务器来说，有成千上万的接入，每个接入的实体和服务器都维护一个独立的对称加密的密钥？答案毫无疑问是否定的，因为这是不实际的，所以为了使用对称加密算法的同时，确保密钥的安全性。这里的对称加密算法使用的密钥引入了会话密钥（Session Key），每次建立通信的时候，都会进行密钥交换，每次的会话密钥都不同。
那么是如何进行密钥交换的呢？这需要展开来分析一下，除了这里涉及到了非对称加密算法的使用之外，同时与安全通信的认证性相关。假设存在两个通信方A和B，其中A需要和B进行通信，同时A持有B的公钥，B自然持有自己的私钥。他们密钥交换流程是这样的：
- 通信方A生成随机数x，他将该随机数x连同自己支持的非对称加密算法一起发给通信方B，因为加密算法也是需要协商的；
- 通信方B收到A发来的随机数x和加密算法列表，他将从中选择出一个自己也支持的加密算法出来，同时生成随机数y，然后将随机数y和选择的加密算法一起发给A；
- 通信方A收到B发来的随机数y和选择的加密算法后，再次生成一个随机数z，并用选择的加密算法通过B的公钥将z进行加密，生成了密文，然后将密文发给B，需要注意的是A此时拥有了随机数x、y、z；
通信方B收到密文后，用自己的私钥将密文解密，那么他将得到随机数z，至此，B也拥有了随机数x、y、z。最后，通信方A和B会用随机数x、y、z来生成一个会话密钥，双方密钥交换完毕。可能有人看到这个交换密钥的流程很眼熟，是的，这就是SSL/TLS协议握手建立连接的交换密钥简化过程。
最后分析一下安全通信的认证性和不可抵赖性，为什么要一起分析呢？因为认证性和不可抵赖性是相辅相成的关系，而且这里涉及到了一个对安全通信有至关重要的信任体系，他是非对称加密算法的主战场。回顾前面的交换密钥过程，通信方A是持有了通信方B的公钥，这只是一个假设。因为在现实网络当中，通信方A是你我他当中一个普通的通信实体，必然会与千万级别的通信实体进行建立通信会话，不可能拥有所有通信实体的公开密钥，这是不现实的。安全通信是一个整体的解决方案，不是小孩子过家家，我和你是朋友，交换一下公开密钥，我们就可以安全通信了；你和他没有交换过公开密钥，你们的通信是不安全的。更何况网络世界中，你是没法证明你就是你，甚至现实生活中还得依靠身份证来自证身份。所以为了安全通信的可认证，这里引入了一个重要角色，数字证书认证机构（Certificate Authority，缩写CA，也称为电子商务认证中心、电子商务认证授权机构）。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。
那么下面来看一下CA中心是怎么工作的，非对称加密算法是怎么发挥作用的。至于通信方A和B的安全通信，结尾再谈。
CA中心会使用非对称算法生成一对密钥（即公钥和私钥），然后将CA中心的信息、算法信息以及公钥等数据进行摘要计算，再通过私钥将摘要数据进行加密后得到密文，最后将CA中心的信息、算法信息、公钥以及密文等数据整合到一个文件中，这个文件就是数字证书。而这个过程中的私钥加密摘要数据的行为，称之为数字签名。由CA中心用自己私钥对自己的信息和公钥进行数字签名出来的证书就是CA公钥证书，这个自己给自己签发的动作称为自签名，CA公钥证书也就是自签名证书，但同时由于CA中心是证书信任链的起点，所以CA公钥证书通常也称之为根证书（Root Certificate）。
自签名流程：
证书详细信息样例：
CA根证书是怎么用的呢？先放一下，后面细述。现在分析一下证书信任链是怎么构建起来的。如同根证书一样，所有的证书的结构都一样的，包含了证书信息（版本、序列号等）、签发者信息、签名算法、证书有效期、主体公钥、公钥算法以及签名数据等。根证书是由CA自己对自己签发的，作为权威机构必然自己信任自己的。假设有个通信用户甲，甲想得到CA中心的信任认证，那么同样甲会通过非对称加密算法生成一对密钥（公钥和私钥），当然由CA中心自己替甲生成也行，然后甲将自己的信息和公钥生成证书请求，并将证书请求发给CA中心，CA中心通过核实确认该用户是甲真实无误，将会提取证书请求中的数据并加上CA的信息，然后再使用自己私钥对该证书请求进行签发操作，生成该用户的信任证书并返回给用户甲。这就是证书签发的流程，签发的是甲的信任证书，可以直接使用的。由于该证书是CA中心直接签发的，所以也称之为二级证书。
签名流程：
但现实当中，CA中心是不会直接给用户签发证书的，因为CA的私钥是高度机密，它通常是被写入到移动存储介质中并离线保管，频繁使用会产生外泄的风险，这是严重安全事故，而且CA签发证书的时候都是经过官方正式公证后签发的，非常严谨。那么常规用户想得到CA信任怎么办呢？假设前面得到CA签发证书的用户甲是一个证书签发商，那么他就可以对常规用户进行二次签发证书。假设有个用户乙想得到认证证书，他同样需要通过非对称加密算法生成一对密钥（公钥和私钥），然后将自己的信息和公钥生成证书请求，并将证书请求发给签发商甲，甲通过核实确认该用户是乙真实无误，将会使用自己私钥对该证书请求进行签发操作，生成该用户的信任证书并返回给用户乙。由此乙将会得到自己的证书。同样，乙可以用自己的私钥给丙进行签发证书，然后丙给丁签发证书，丁给戊……当然不会无穷无尽的，可以通过证书签署路径（Path Length Constraint）来限定签发深度，超出深度的证书则不可信，这里不具体展开。而且证书签发不限于一对一签发，也可以一对多签发。假设证书签发到戊即止，那么戊不再可以对外签发证书了，那么戊的证书就是最终用户证书（End-user certificate），而甲乙丙丁的证书都称之为中间证书（intermediates Certificates），甲是二级证书，乙是三级证书，丁是四级证书。而甲乙丙丁戊的证书集合就是所谓的证书链（Certificate Chain），这是戊的证书链。对于其他证书用户的而言，它们的证书链是截止到它自身的证书。
证书链：
那么根证书和证书链是怎么工作的呢？以web访问为例，根证书是预置在浏览器中的（虽然这证书管理是操作系统统一管理的，但这里先是认为是浏览器客户端管理的吧），或者由用户通过安全渠道（比如移动存储介质拷贝或者特定链接下载）获取到然后再安装到自己的浏览器当中。而且浏览器预置的都是根证书，极少量的中间证书。如果对浏览器预置证书是怎么来的，可以看一下CA/浏览器论坛的组织管理。假设要访问的网站用的是前面生成证书链中的戊的信任证书。那么打开浏览器访问网站的时候，网站服务器会将整个证书链（即甲乙丙丁戊的证书）发过来给浏览器的，然后浏览器开始验证证书链是否可信。首先，他会打开戊的证书取出签发者丁的信息，然后查找本地是否预置有丁的证书。如果没有，那么接着打开证书链中丁的证书，取出丁的公钥对戊证书的数字签名进行解密得到明文（这个明文是签发戊的证书时，证书信息的摘要值），通过计算得到戊的证书信息的摘要值和该明文对比一致，就可以确认证书是否确信由丁签发的。这对数字签名的解析校验，称之为签名校验。通过逐层签名校验以及本地证书查找，最终校验到甲的证书是由CA签发的，而且本地有该CA的根证书，通过根证书对甲的证书进行签名校验，可以确信甲是经过CA认证的可信的。到此，CA信任甲，甲信任乙，乙信任丙，丙信任丁，丁信任戊，信任链就构成了。这也正好体现了认证性，一环接一环的认证。当然如果浏览器中预置了丁的信任证书，那么只需要签名校验到丁的信任证书就可以确定戊是可信的，而不需要追溯校验到CA证书。
关于信任证书体系的构成到此为止，回到通信方A和B的安全通信问题上。前面是假设A持有B的公钥，现在不需要了。现实中，A和B通信，A信任CA中心，然后只需要预置CA根证书即可，而B只需要获得CA签发到B的所构成的证书链（这个证书链，可能只有B一个证书，也可能是带了多个中间证书）。那么他们之间建立通信的交换密钥和证书认证结合起来的流程是：
- 通信方A仍然是先生成随机数x，他将该随机数x连同自己支持的非对称加密算法一起发给通信方B，同样加密算法也是需要协商的；
- 通信方B收到A发来的随机数x和加密算法列表，他将从中选择出一个自己也支持的加密算法出来，同时生成随机数y，然后将选择的算法、随机数y以及证书链一起发给A；
- 通信方A收到B发来的选择的算法、随机数y以及证书链后，A会先将证书链做签名校验，确认与本地预置的CA证书构成信任链。然后再生成一个随机数z，并用选择的加密算法通过证书链中携带的B的公钥将z进行加密，生成了密文，然后将密文发给B，需要注意的是A此时拥有了随机数x、y、z；
同样通信方B只需要用自己的私钥进行对密文解密，即可获得随机数z，此时将得到了全部的随机数x、y、z。通过对他们进行运算处理，将会得到与A通信的会话密钥。这就是SSL/TLS握手建链的完整过程。在非对称算法当中，公钥加密的密文只能够由对应的私钥才能够解析到正确的明文，能够得到正确的会话密钥和A通信，那必然是B无误了，更何况有CA中心在背书。那么A收到来自B的信息都是不可抵赖的，这就是不可抵赖性的体现。当然有人会说B的私钥被盗了，那就没法了，在网络中持有该私钥的只应该是B自己，每个人都有必要对自己的私钥做好万全的保管。因为不可抵赖是相对的，只能够做到一定层面的不可抵赖。更何况欲加之罪何患无辞，无赖总能找到理由的。
细心的读者留意到了，通信方A与B的通信中都是强调对B的认证，那么如果B也想确认A的身份呢，同理A也只需要获得CA中心签发的证书以及B需要预置CA中心的根证书。具体的实现就涉及到了SSL/TLS双向认证的握手建链的实现了，有兴趣的可以Google一下。
来个收尾，我们在这里从加解密开始，谈到了安全通信的要素，接着到算法在安全要素中的体现，再到证书体系的构建，最后是安全通信的建立。安全通信也不过如此，但是细究，还是有很多地方值得好好品味一番。