第七章 单向散列函数
单向散列函数是用来确保完整性的。
7.2 单向散列函数
7.2.2 什么是单向散列函数
单向散列函数有一个输入和一个输出,其中输入称为消息,输出称为散列值,这里的消息可以是字符串,也可以是图像文件、声音文件等等。
散列值的长度和消息的长度无关,单向散列函数总是会计算出固定长度的散列值。比如 SHA-1 单向散列函数,它计算出的散列值的长度永远是160比特(20字节)。
单向散列函数必须确保要找到和该消息具有相同散列值的另外一条消息是非常困难的,这一性质称为弱碰撞性。
7.4 单向散列函数的具体例子
- MD4,MD5
- SHA-1,SHA-256,SHA-384,SHA-512(SHA-256,SHA-384,SHA-512统称为SHA-2)
- RIPEMD-160
- AHS与SHA-3
第八章 消息认证码
使用消息认证码可以判断消息是否被篡改,以及该消息是否来自期望的发送者。
8.2 消息认证码
- 消息的完整性:消息没有被篡改
- 消息的认证:消息来自正常的发送者
8.2.2 什么是消息认证码
消息认证码是一种确认完整性并进行认证的技术。简称为MAC
消息认证码的输入包括任意长度的消息和一个发送者接收者之间共享的**,它可以输出固定长度的数据,这个数据称为MAC值。
消息认证码是一种和**相关联的单向散列函数。
8.2.3 消息认证码的使用步骤
假设Alice银行要向Bob银行转账:
- 发送者Alice和接收者Bob事先共享**
- Alice根据汇款请求消息和**计算MAC值
- Alice将汇款请求信息和MAC值发送给Bob
- Bob根据接收到的信息汇款信息计算MAC值,将它和从Alice处接收的MAC值对比
- 如果两个MAC值一致,则Bob就可以断定汇款请求来自于Alice
8.2.4 消息认证码的**配送问题
要解决消息认证码的**配送问题,需要和对称加密中一样。
8.3 消息认证码的应用实例
- SWIFT
- IPsec
- SSL/TLS
8.7 消息认证码无法解决的问题
8.7.1 对第三方证明
假设Bob收到了Alice的消息后,想要向第三方验证者Victor证明这条消息是Alice发送的,用消息认证码无法进行这样的证明。
因为Victor无法判断这条消息到底是Alice发的,还是Bob发的,因为Alice和Bob双方都可以计算Mac值,所以对于Victor来说,Alice和Bob都无法证明是对方计算了MAC值,而不是自己。
8.7.2 防止否认
Alice向Bob发送了消息后,Alice可以向Victor声称:我没有发过这条消息给Bob。而Bob也没法向Victor证明这条消息确实是Alice发的,这样的行为就称为否认。
第九章 数字签名
数字签名可以识别篡改和伪装,还可以防止否认。
9.3 数字签名
Alice发送消息给Bob。Alice使用只有自己知道的**生成一个签名,接收者Bob使用一个和Alice不同的**对签名进行验证。
使用Bob的**无法根据消息生成签名,但是用Bob的**却可以对Alice生成的签名进行验证。
9.3.3 签名的生成和验证
在数字签名技术中,有下面两种行为:
- 生成数字签名的行为
- 验证数字签名的行为
生成消息签名的行为由发送者Alice完成,验证消息签名的行为由接收者Bob或者需要验证消息的第三方来完成。
签名**只能由签名的人持有,而验证**则是任何需要验证签名的人都可以持有。
数字签名就是将公钥密码反过来用而实现的。
用私钥加密生成签名,用公钥来解密来验证签名。使用私有加密的密文只能用公钥来解密。
9.4 数字签名的方法
9.4.1 直接对消息签名的方法
因为使用公钥密码加密的速度很慢,因此这种方式基本不使用。
9.4.2 对消息的散列值签名的方法
9.5 对数字签名的疑问
9.5.2 数字签名不能保证机密性吗
数字签名的作用本来就不是保证机密性的。如果要保证消息的机密性,则可以不直接发送消息,而是将消息加密之后再发送,关于密码和签名的组合方法,参考第十三章 PGP。
比如一些世界组织经常会发布一些信息,这些信息的目的就是为了让尽可能多的人知道,因此没有必要对信息进行加密,但是必须要防止有人恶意伪装成组织来发布假消息。
9.6 数字签名的应用实例
9.6.3 公钥证书
在验证数字签名时需要合法的公钥,那么怎么知道得到的公钥是合法的呢?我们可以将公钥当做消息,对它加上数字签名,像这样对公钥施加数字签名所得到的就是公钥证书。
9.9 对数字签名的攻击
9.9.1 中间人攻击
对于公钥密码的中间人攻击对于数字签名也颇有威胁。
要防止中间人攻击:
- 可以确认自己得到的公钥是否正确,比如打电话
- 公钥证书
9.10 各种密码技术的对比
9.11 数字签名无法解决的问题
数字签名可以识别出篡改和伪装,还可以防止否认,也就是说,我们同时实现了确认消息的完整性,进行认证以及防止否认。
但是使用数字签名有一个大前提,那就是用于验证签名的公钥必须属于真正的发送者。
这里形成了一个死循环,数字签名是用来识别消息篡改,伪装以及否认的,但是为此我们又必须从没有被伪装的发送者得到没有被篡改的公钥才行。
为了能够确认自己得到的公钥是否合法,我们需要使用 证书,所谓证书,就是将公钥当做一条消息,由一个可信的第三方对其签名后所得到的公钥。
第十章 证书–为公钥加上数字签名
无论是公钥密码还是数字签名,公钥都扮演了重要的角色。然而如果我们不能判断公钥是否合法,就有可能遭到中间人攻击。
10.1 什么是证书
公钥证书里面包含有姓名、组织、邮箱等个人信息,以及属于此人的公钥,并由认证机构施加数字签名。
10.4 公钥基础设施
10.4.4 证书的层级结构
认证机构的公钥可以由另一个认证机构来认证,这样的关系可以迭代好几层。
对于最根一层的认证机构(根 CA),由自己来颁发证书。