通过了解以前前辈们使用的消息认证慢慢渐进到现代的完整的认证体系。所以在学习的时候也很蒙圈，因为前期的很多技术都是有很严重的不可靠性，因此本篇用作加深理解认证技术的发展史还有到目前为止完整的不可抵赖的认证体系是如何形成的，并且了解是如何吸收之前的认证技术的教训或者说吸收好的一些技术。
按照惯例先说原理与技术，再加上我个人理解方便后续复习。
约定：下面很多的加密和认证方式的前提是通讯双方接受了这个传送方式，在他们看来就是可信的，而我们看来肯定是不可信的，这里不要硬犟，但是他们使用了漏洞重重的方式那就代表了他们随时会翻脸不认人的可能性，或者被黑客攻击的可能性，这才会有了今天的比较完善的认证系统。（但是为了循序渐进的学习到后面系统的认证技术方式必须要先了解最简单的几种技术）
加密认证
这里的加密认证应该是我们在了解这方向的知识之前，能够想到的最简单的也是最直接明了的认证方式：通过双方协商的方式来实现认证。（下面介绍两种）
对称密钥体制
双方协商好某种对称加密方式，这就会需要协商好一个会话密钥，双方共享该密钥（共享意思是都知道这个密钥密码），然后对称性的意思就是双方在加密和解密用的都是同一个密钥。
这种只能够实现加密不能实现认证（因为随时会话密钥会被泄露或者被破解掉，没有验证的手段说这个消息没有被篡改掉）
缺点：
我们需要对每一个希望跟自己互相发送消息的人都协商好一个共享会话密钥，这是一个很愚蠢的方式，因为每次对话都要建立一个密钥，用户庞大的话这个密钥数量可想而知，有的用户还希望和不同的人交流。
对整个消息进行加密解密，这个过程十分耗时间。
某一方的密钥丢失了怎么办？
密钥被暴力破解了呢？
基于上面两个问题，任何一方都可以说由于上面两个问题发生的可能性，A有可能说我没有发过这条消息，也有可能是B说我根本没有收到这条消息。双方就出现了争执。
公钥密码体制
公钥的加密
- 简单了解一下公钥加密原理
通过某个算法生成公钥和私钥，公钥是可以公开的，私钥是自己拿着谁都不知道的。因为公钥是公布出去的，所以别人使用公钥加密的信息发给我的时候，只有我能够使用私钥解密。
公钥加密这种方式其实有认证的感觉出现了，因为使用别人的公钥只能够给该公钥的发布者发布加密消息，因为只有持有该公钥的私钥才能够解密，这其实也就是间接的验证了消息接收者的正确性，而不是其他人。
优化了什么：
公钥发布出去，谁都可以使用该公钥给我发送消息，而不用每个人都需要特地的来和我协商好某个会话密钥，大大减少了工作量。
缺点：
双方依旧可以赖皮。。。
B可以对A说你这个消息发出去是不是别人截获了直接替换掉了啊？
A也可以对B说，我发出去的时候不是这样写的，中间肯定是给黑客攻击篡改了。
公钥身份认证和加密
这个图其实不太准确，理论上是可以使用同一对公钥和私钥进行签名还能进行加解密，但是一般情况不是，我们只需要了解能够这么干就可以实现认证和加解密就行。
- Sig表示签名，签名和使用公钥加密私钥解密顺序反过来了，但是他们公私钥的生成方式是可以一样的比如使用RSA，所以这里就将就一下都用同一对公钥私钥既签名又加解密。然后签名是私钥签名，公钥验证，这里签名是不会暴漏自己的私钥的，且只有发送方知道，只做验证，因此不必担心私钥泄露。（再深入了解原理就是单向函数原理了，也不要说被人暴力破解，破解完我信息都到对方了，或者对方早就跑路了。在网络的信息传递是十分快的）
- 实现流程
A使用私钥对信息M进行签名，让接收方可以使用我的公钥进行验证签名是否是我的
↓
A继续使用B的公钥进行加密
↓
B拿到消息后，第一时间是使用自己的私钥进行解密，因为对方使用了B的公钥进行加密
↓
解密后信息还是不可信，因为不知道是不是A发过来了，这时候我们就取出A的签名，使用A的公钥进行签名验证
↓
验证成功的话就可以相信这份消息是A发过来且可信的。（否则反之）
这个认证和加密中，接收方使用公钥密钥的顺序不能乱，其实也乱不了，人家最后一步操作是加密那你拿到消息后不就是第一时间进行解密么。然后解密完成后你知道对方之前是签名了后加密，你现在解密完成了不就到了签名验证了？这就是一个认证和加密的过程。
多说一句，这种其实不用纠结顺序，有时候你可以先加密再对密文验证，我这里使用的是对明文验证，然后再加密。这里其实就是看你希望对哪一个签名而已。（但是这种可以随便顺序的在鉴别码中就不可以使用，后面会讲）
缺点：
依旧没有解决发送方会耍赖皮说：我的私钥不见了或者泄露了。
同时接收方可能会赖皮说：我的私钥泄露了，中途肯定被黑客拿到消息篡改了，因为你公钥是公开的，那估计是被黑客修改了。
鉴别码认证
为什么会出现鉴别码认证？
经过加密认证的学习，最合理的貌似是签名，但是签名更多是对身份验证，不是对消息的认证，所以MAC就出现了，能够给消息再加一层壳（这里数字签名思想逐渐成型了）
MAC鉴别码
Message Authentication Code，MAC
这种码是依附在消息中的，当你取出这个MAC码的时候可以通过被依附的这个消息用同样的算法生成另一个MAC码，对比依附在消息的MAC码是否一样就知道消息是否被修改过。（你是否担心MAC同样被修改成能够与篡改信息一样的MAC码？你的担心是正确的，确实是可以，但是有限时间内是难以破解，而且MAC是一个通用模版，模版的意思是，里面的函数是根据你使用的函数进行替换的，哪个安全就用哪个，但是具体的流程还是不变）
MAC的特点就是需要将密钥送进你采用的函数里面来生成一个固定长度的短数据块，然后把数据块附加在消息后，用来后面发送给对方后，对方能够进行验证消息是否被篡改过。
-
公式可以写为：
MAC码 = C(K, M)
C 表示加密，K是密钥，M是发送的消息
然后两个参数K和M送进加密函数中生成MAC码
K是双方协商好的密钥 -
问题很大
既然你又是协商好的密钥，那你这个没啥必要了，黑客直接暴力破解你的密钥了，还有可能某一方密钥泄露出去了，不是吗？
当然我们MAC码的引出肯定在真实情况下不会这么做，目的是引出这个理论，为后面的私钥数字签名提供了很大的帮助。但是还需要继续了解MAC工作方式。 -
直接生成鉴别码贴在原文消息后面
下图是使用MAC鉴别码最简单的一种使用方式，通过密钥还有M生成MAC后直接贴在原文后面作为原文的签名，若对方使用同一个密钥和直接送过来的M生成的MAC2与原来的MAC比较出来不同的话那这个消息就是不可信任的，否则就是可以信任。
好处就是在密钥不泄露的情况下，我们的消息是不会被人篡改的，因为篡改过的话鉴别码就会报错。
注意了，MAC都是双方协商好的密钥，不会对外公布。
-
对原文进行认证
下图中就是输入M原文和密钥K生成MAC鉴别码，这个鉴别码就是用来鉴别原文的，然后再通过另一个密钥对整个消息进行加密。对方就是先解密后验证。
-
对密文进行认证
下图是先进行加密，然后加密完事后使用加密好的密文再与另一个密钥生成鉴别码，这个鉴别码就是用来鉴别密文是否正确的，因为我们就是完成了加密后，输入的密文生成的鉴别码，所以对方也应该先对密文进行鉴别后再解密。
重大发现：鉴别码使用的都是对称密钥，因为函数生成需要使用密钥作为参数，所以对方肯定也是使用一样的密钥来验证MAC是否一致。
以上几种认证方式的缺点都是：密钥依旧是需要双方协商。依旧可以翻脸不认人，只是说在一定程度上，接收方可以相信报文是正确的。
总结一下：引出了鉴别码这种方式后，第一大我认为很好的就是把认证和加解密分离开了，原先的公钥私钥等等方式都是直接使用全文加密的方式进行认证，先不提代价是否减少的问题，先是灵活性这方面，MAC已经success了，通过MAC分离了认证和加密后，起码我能够明显感受到之前存在的漏洞好像可以逐渐别填补了，具体是用什么方法先不管，分离开后我们实现的方式就简单了，只用针对一个方面去找和实现的方式即可。
报文摘要认证
Message Digest，MD
报文摘要使用的是散列函数，散列函数是单向散列函数。也可以叫做哈希函数等等，且散列函数是公开的，谁都知道，只不过将散列函数出来的值进行加密的秘钥是保密的，这个后面再说。
即选定了x，直接散列函数H(x) = y很容易计算，反过来你有y但是你希望得到x就是很困难的事情。
注意：x选择是可以随机长度的，但是生成出来的值是固定长度的。希望攻破散列函数值的话那就是碰撞性，能够在较短的时间和次数下真的找到生成y的散列函数参数x。这个不是暴力破解就能解决的，因为这个参数不是我们想的一个数字这么简单，而是摘要，一个文章摘要你能列举出来多少种，能暴力破解出来可能电脑都报废了还没破解到。
这里不深入探究原理
- 常用的散列函数
- MD5：生成128位的哈希值
- SHA-1：生成生成160位的哈希值
- 当然上面两个现在已经不安全了…只是说常用，真实的企业或者自己在知道不安全的情况下其实也不敢用…
认证 + 加密
别的不说，真的太像MAC鉴别码了
首先区分的是，我们的散列哈希操作也就是【H】，他只使用了M报文内容的摘要作为内容传进散列函数生成H贴在M的后面，这里跟MAC不同，MAC使用的是密钥和M原文，这里直接摘要就可以生成了，很吊，不仅减少了一个参数K密钥，而且这个散列值反推回去也很那破解。
- 操作流程
M直接放进哈希取摘要生成H哈希值
将哈希值贴到原文后面使用共享密钥进行加密
对方接收到后先解密，然后取出M原文进行哈希，哈希之后对附加过来的哈希进行比较就能够实现消息认证了。
因为我们的散列哈希值是固定的，破解是不大可能，除非双方使用的散列哈希函数已经被人攻击成功了。要说缺点肯定是有，就是当攻击方可以知道了你的哈希函数，然后破解了你的密钥K，在途中截取了密文C ，直接将整个密文替换掉，攻击方就可以自己随便写，然后哈希一下贴在自己随便写的内容里面发送给接收方，这样的话直接第三方攻击了，即使双方没有恶意，有第三方的篡改也没办法。
只认证
看到这的时候绷不住了，这里是在散列值产生后进行一次密钥加密然后这样的还我们接收方有一次解密的过程，解出来的哈希值跟原文自己生成的哈希值对比即可完成消息认证。这大大提升了我们收到的消息的可信度。
- 这里就不说缺点了，很明显这两个是可以结合起来的，结合起来后就有数字签名的影子了，但是有一点就是数字签名使用的是公钥私钥而不是双方私下自己协商好的。
但是！但是！这已经接近数字签名了，消息认证手段逐渐成熟。
数字签名
这里简单提一下数字签名
数字签名就是在哈希完成后，使用公钥和私钥进行签名，也就是我们公钥认证中提到的Sig就是签名，签名使用私钥，验证使用公钥，所以我们在发送给对方的时候使用的是自己的私钥，这个私钥是只有你只知道的，除非你自己泄露出去，这种肯定是可信度高的，将哈希值签名后，贴到原文的后面，这样传输过程中哈希就得到了保证，因为是私钥加密的，只有一个人知道，公钥一验证就知道是不是对方发过来的了。（不要纠结是否能破解密钥，这里肯定是还没到最后的很完善的地步，起码这个签名实打实的得到了认证保证）
以下是扩充（没有疑惑的就可不看）：
实在是忍不住补充，希望自己复习的时候能够明白，这里还是有很多不完美性，因为密钥还是没有得到保证，需要密钥得到保证就要有一个可信任的第三方权威机构，通过可信机构给下来的证书，里面有机构私钥的签名，签名是私钥的话，我们有可信机构的公钥那就可以解出来一个哈希值，然后将证书里面的其他东西也做一个哈希进行对比就知道证书知否有效，为何要证明有效性？=>因为对方也应该要有这个证书，交换证书的过程就是实现安全的彼此的公钥交换（不是交换机构的，因为机构的两个人都知道），为什么是安全的？因为你选择了可信任的第三方机构，你相信机构的私钥不会被人知道。IKE就是验证身份的一个过程，其中协商加密算法，交换公钥，由于公钥得到了安全交换，所以我们就不会担心公钥是否被人篡改替换等等。还有就是那个数据包里面协商的种种信息需要用到发送方的私钥，所以由于私钥的签名，对方拿到我这个消息后，就可以用证书里面存着的发送方公钥解出来哈希，然后进行对比即可完完全全确定就是他发送的了，还解决了互相赖皮的可能性，因为可信机构就是可以作为一个正义使者确保消息就是他发的没有篡改过，也无法抵赖，因为既然能够接受且信任机构就代表是对方送过来的消息，无法抵赖！(其实就是PKI机构，后面会继续学习)
