密码学笔记

《网络安全基础：应用与标准》第五版。随手笔记

对称加密：加密和解密的密钥相同
DES/3DES

AES讲解视频：
https://www.bilibili.com/video/av46440862?from=search&seid=7085284325896270887

RC4:

分组密码工作模式：ECB、CBC等

kerberos：仅依赖对称加密机制
假如你要去社区事务中心去办理居住证，但是社区事务中心并不能确定你的身份，因此需要你去派出所开据证明，证明你就是你。

简单地说，Kerberos提供了一种单点登录(SSO)的方法。考虑这样一个场景，在一个网络中有不同的服务器，比如，打印服务器、邮件服务器和文件服务器。这些服务器都有认证的需求。很自然的，不可能让每个服务器自己实现一套认证系统，而是提供一个中心认证服务器（AS-Authentication Server）供这些服务器使用。这样任何客户端就只需维护一个密码就能登录所有服务器。 因此，在Kerberos系统中至少有三个角色：认证服务器（AS），客户端（Client）和普通服务器（Server）。客户端和服务器将在AS的帮助下完成相互认证。 在Kerberos系统中，客户端和服务器都有一个唯一的名字，叫做Principal。同时，客户端和服务器都有自己的密码，并且它们的密码只有自己和认证服务器AS知道。

参考链接
https://blog.youkuaiyun.com/sky_jiangcheng/article/details/81070240
https://www.freebuf.com/articles/system/45631.html

X.509：是公钥证书的格式标准，应用在包括TLS/SSL的众多协议内。

联合身份管理：

消息认证部分：
本文目录：

1. 摘要
2. MAC
3. 数字签名
4. CA 证书
5. 根 CA 证书
   这是一个从弱到强的过程，对数据安全的功力，从一个普通扫地僧到武林至尊的过程。

我们来逐步推进这个过程：

1. 摘要
   首先，我们想要确认一段文本的完整性。于是用上 MD5 或者 SHA 算法，从一段文本中摘要出一段信息附在文本后面。使用文本的期间，可以用同样的摘要算法，摘要出相关信息和之前摘要的信息比较一下。因为摘要算法摘要出来的信息冲突概率小到几乎可以忽略不计，所以可以认为，文本是完整的。

2. MAC
   但是，如果文本在网络上传输，被人拦截了，而对方也知道摘要算法，重新摘要后再附在文本后面再发给我们，客户端不就发现不了这个文本是被篡改的？

这时候 MAC 就派上用场，MAC 使用对称密钥技术，比如 DES 算法，对上面的摘要进行加密。服务端和客户端都协商好的对称密钥进行加解密，因为只有对方持有密钥，所以我们可以认为这个文本来源是可靠的。

3. 数字签名
   但是这个还有个疑问，怎么确保这个密钥真的只有服务端和客户端持有？这个对称密钥如何通知服务端和客户端？如果直接明文传输密钥，中途还是有被中间人拦截的可能。

于是，我们使用数字签名。和 MAC 比较，数字签名对摘要采用的是非对称密钥加密技术。加密方式为私钥加密，公钥解密，公钥公开，被拦截了也没关系。然后因为只有服务端才有私钥，所以如果解密并且验证摘要成功，那么就可以确定文本来源可靠。

数字签名就像一个人的指纹，也可以称为文件指纹，具有唯一性。

客户端拿到信息和服务端的签名。也用相同的摘要算法获取摘要，然后用公钥解开数字签名作比较，摘要信息一样就可以确认服务端的身份，也可以确认数据中途没有被篡改过。

4. CA 证书
   但是大魔王中间人又来了，如果中间人拦截服务端传递过来的公钥，换成自己的公钥，那么文本还是有可能被篡改。我们怎么保证公钥是服务端传过来的？

这个时候，CA 证书就派上了用场。服务端公钥证书通过证书中心 “Certificate authority”，也叫做 CA 的地方进行认证，证书中心用自己的私钥，对服务端的公钥和一些信息再进行一次数字签名，发送给客户端。然后只要客户端信任这些 CA 证书机构，拿出来验证一下服务端的公钥证书。认证成功后，服务端的公钥也就可信任了。数字签名也就可信任了。

5. 根 CA 证书
   那么问题来了，服务端带的 CA 是假证书怎么办？也就是怎么知道我们的客户端是信任这些证书的？而不是某些中间人伪造的？

那么根 CA 证书派上了用场。验证服务端证书的 CA 证书，也要有 CA 证书认证，这些统称为中级证书。一直到根 CA 证书。全世界被认可和支持的，大部分浏览器和操作系统信任的根 CA 证书没几家。服务端要用 HTTPS，要让地球上几乎所有设备能够用上安全的 HTTP，就需要买这几家的证书：

Symantec（VeriSign/GeoTrust）
Comodo
GoDaddy

作者：Oblee
来源：优快云
原文：https://blog.youkuaiyun.com/firefile/article/details/80535426
版权声明：本文为博主原创文章，转载请附上博文链接！

注：为保证根CA证书公钥的安全性，公钥必须要安全地转交给客户端（CA根证书必须先安装在客户端），因此，CA的公钥一般来说由浏览器开发商内置在浏览器的内部。于是，该前提条件在各种信任机制上，基本保证成立。

数字签名和证书
数字签名是什么？

鲍勃有两把钥匙，一把是公钥，另一把是私钥。

鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。

苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。

鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。

鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用Hash函数，生成信件的摘要（digest）。

然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。

鲍勃将这个签名，附在信件下面，一起发给苏珊。

苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。

苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。

复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。

后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。

鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。

苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。

下面，我们看一个应用"数字证书"的实例：https协议。这个协议主要用于网页加密。

首先，客户端向服务器发出加密请求。

服务器用自己的私钥加密网页以后，连同本身的数字证书，一起发送给客户端。

客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。

如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告。

如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告。

如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥，对信息进行加密，然后与服务器交换加密信息。

报文鉴别码：MAC是满足某些安全性质的带密钥的hash函数

hash函数：不带密钥
mac：带密钥

两种构造MAC的方式：
1.通过不带密钥的hash函数构造：HMAC。密钥、消息、sha1共同组成的函数。
2.CBC-MAC