系统安全。

理论概念

五大要素

几种加密/摘要算法

对称加密

AES DES 3DES RC5

3重DES加密，2个密钥加密3次，1个密钥56位，2个112位。

非对称加密

有公钥、私钥。

RSA

信息摘要

SHA1 160比特 20字节
SHA265 265比特 32字节
MD5 128比特 16字节

注：信息摘要可以选以上的一种进行。

报文摘要用于为发送的报文生成一个非常小的摘要信息，这个摘要信息保证原报文的完整性，防止篡改。即原报文只要有一位被改变，则摘要信息就会不匹配。
用私钥对摘要做加密不仅保证了摘要的私密性，还可以防止抵赖，因为只有匹配的公钥能够解开。也就是说，如果用某人的公钥能够解开报文，说明就是某人做的。

数字签名

注：hash算法有不同的种类，双方需使用同一个。

数字签名不能保证明文的保密性。只是验证发送的内容是否一致（是否被篡改）。数字签名解决的核心问题是：确保收到的文件没有被更改。

数字签名三个特征的验证
不可否认——只有用户A拥有私钥A，并能使用私钥A产生”加密的摘要”，这样用户A就不能否认给用户B发送了经过签名的密文。
报文的完整性——用户B通过比较得出的两份摘要是否相等，可以判断签名或文件内容是否发生改变。
报文鉴别——用户B可以使用收到的公钥对”加密的摘要”进行解密，从而核实用户A对文件的签名。
用户A使用私钥对由文件生成的128位摘要进行加密的过程称为数字签名的过程，得到的”加密的摘要”，称为该文件的数据签名。
用户A使用私钥加密的是摘要而不是文件。
用户B验证签名实际上是比较得出的两份摘要是否相等。

一般的过程

签名过程（发送方）：
1、将要签名的明文（文件）进行hash计算，得到hash值（即摘要）。
2、用发送方的私钥将hash值进行加密（即把摘要加密，得到的数据就叫签名）。
3、将明文（文件）与签名一起发送。

验证过程（接收方）：
1、将原文件进行hash计算得到hash值。
2、用发送方的公钥将签名数据解密，得到hash值。
3、将步骤1中得到的hash值和步骤2得到的hash值进行对比，如果对比结果一致则验证通过，反之验证失败。

图示：

数字信封

前面明文不加密，此处加了加密机制。

签名过程（发送方）：
0、将要发送的明文（文件），用某个对称加密的密钥KEY加密，得到密文。
1、将要发送的明文（文件）进行hash计算，得到hash值（即摘要）。
2、将hash值用发送方的私钥加密，得到签名（即把摘要加密，得到的数据就叫签名）。
3、将密钥KEY用接收方的公钥加密。
4、将密文、签名、加密后的KEY三者一起发送。

验证过程（接收方）：
1、将加密后的KEY用接收方的私钥解密，得到KEY。
2、用KEY解密密文，得到明文。
3、计算明文的hash值。
4、用发送方的公钥将数字签名解密，得到hash值。
5、将步骤3中得到的hash值和步骤4得到的hash值进行对比，如果对比结果一致则验证通过，反之验证失败。

注：此处多了将明文加密的步骤，一般情况下明文较大，故用对称加密KEY，因此，需要用接收方的公钥来加密KEY，接收者用自己的私钥解得KEY，再得到明文。其它的是数字签名步骤，与前一节的步骤相同。

数字证书