在开发大型系统时，涉及安全机制时，请阅读本文章。内容：加密、解密、签名、校验相关的算法的使用。
数据转换算法:
将不可显示的数据转换为可打印文本。用于将任意的数据转成文本形式来表示。( base64算法 / 16进制编码 )
校验算法：
用于检查数据的完整性。当接收到一段数据后，如果不确定该数据中间是否有损失，可以采用校验类算法。（ CRC， MD5， SHA1）
对称加密算法：
加密和解密过程可逆，采用相同的密码。加密算法的特点是，其算法是公开的，而密钥就是所有的秘密。 (DES/3DES/AES)
对非对称加密算法:
加密和解密采用不同的密钥（公钥和私钥），这是商务领域的高级别加密算法。例发，HTTPS协议就是采用了非对称加密算法。
数字签名：
收到一份数据后，用于确认此数据是否被篡改。(HMAC-SHA1 )
1. DES加密
什么是DES
DES: 全称Data Encryption Standard 是一种对称加密算法
特点：
- 加密和解密的密钥相同
- 分组加密，每8字节一组，密钥也是8字节
密钥的特殊性
DES密钥是8个字节，但每个字节的最低位(bit0) 不参与运算。
因此，以下密钥是等效的：
"01234567"
"00224466"
"11335577"
由于密钥中只有56位是有效的，所以DES是一个56位的加密算法。
应用
当数据长度大于8个字节时，每组加密，每组8个字节。
当数据长度小于8个字节时，下节课讨论
填充 Padding
DES是每组8字节的分组加密算法
(1) 如果数据不足8字节。。。
(2) 如果密码不足8字节。。。
当数据不足8字节时，一般不需要特殊处理， 可以填0，可以填其他值。
一般数据本身是携带了长度的，例如 "helloworld"分为2个block
密码的填充
当密码不足8字节时，应该填成8字节。 比如，用户密码为"test"，不足8字节 。
有若干种填充方式，只要加密方和解密方事 先约定好即可。 例如，填0
另外一种名叫PKCS#7的填充方法，7是编号
以"test"为例，缺4个字节，则填充值为4
如果密码为"china"，则填充值为3
加密模式
（1）ECB模式，Electronic Code Book电子密码本。
每一块block的互相独立
先解block1还是先解block2。。。没有影响
其中一个block丢失，其他的block还能解吗？。。 没影响
（2）CBC模式 Cipher Block Chaining 链式加密
由于ECB存在一定的安全缺陷（容易被“重放攻击”？），
发明了CBC模式
CBC模式 c0 = DES_CBC(p0, key, IV);
CRC校验
工程背景
在传送数据时，一段N字节的数据从A传送至B， 在接收到此数据时，如何确信此数据是完整的？
（考虑：以串口传输时，由于传输信道本身 不稳定，存在数据中途出错的可能性） 比如，某位数据是1，传输的过程变成了0)
如果这段数据不敏感，不在乎一两个字节的错误（如，一篇文章），则不用校验。
如果这段数据敏感，即使有一个bit的错误， 也会使整个数据无效（如rar文件)，则需要校验.
CRC, Cyclic Redundancy Check 循环冗余校验
digest = CRC ( data ); 它根据一个N字节的数据，生成一个较短的结果，称为校验码。(8bit,16bit,32bit)
校验过程：
发送方：根据data，生成digest
A --(data, digest ) --> B
接收方：根据data，自己生成digest2
检查方法：
① 如果digest != digest2 ，说明数据不完整
② 如果digest == digest2，则近似相信数据是完整的
注：
存在data不一样，但digest相同情况， 但这种情况发生的概率很小。
注：
data的长度不受限制 CRC8,CRC16,CRC32
CRC32的准确性最高，但速度相对CRC8较慢。
AfCrc32类的用法
**(1)只有一段数据 **
// 生成CRC校验码
AfCrc32 crc;
crc.Restart();
crc.Update(buf, 512);
char digest[4];
crc.Final(digest);
注：每次生成CRC之前，Restart函数需要被调用
(同一个AfCrc32对象可以被使用多次）
内部使用crypto++，见本教程的附录
**(2)多数数据 **
当有多段数据时（一个buf存不下，分成多段了）
AfCrc32 crc;
crc.Restart();
while(1)
{
int n = fread(buf,1,512,fp);
crc.Update(buf, n);
}
char digest[4];
crc.Final(digest);
小结
CRC用于对数据进行校验
如果校验失败，应该要求对方重传
5.2 MD5及SHA1摘要算法
摘要算法
摘要算法和CRC的任务相同，用于检查数据的完整性。
MD2,MD3, MD4, MD5
SHA1, SHA-224, SHA-256, SHA-384,SHA-512
最常用的是: MD5, SHA1
SHA1
SHA1: Secure Hash Algorithm 生成20字节的摘要。
Test Vectors
测试向量：
一组测试数据(data, digest)，用于检验算法的正确性。
例如，
data="The quick brown fox jumps over the lazy dog" (43字节）
MD5: 9e107d9d372bb6826bd81d3542a419d6
MD5和SHA1都是常用的摘要算法，但相对来说，
MD5有点过时
6.1 数字签名HMAC-SHA1
工程背景
在传输数据时，使用摘要digest可以解决数据完整性验证的问题。。。
A --[data, digest] B
但是还存在另外一个安全性问题：
"冒名"问题: B如何确认这个消息是A发出来的？而不是某个捣乱的家伙A'发出来的？
假设B是一家银行，A是B的一个客户。
A发消息告诉B，我想要转账： "client=wang&action=transfer&amount=10000&dest=li"
client: 发起方客户id
action: transfer表示转账
amount: 数额
dest: 目标客户id
涉及钱的问题都不是小事，于是，为了保证数据的完整性，需要加上一个digest作为验证字段："client=...dest=li&digest=XXXXXXX"
蓝色部分：正文
红色部分：SHA1校验码，正文部分的摘要，按十六
进制转成文本（长为40的字符串）
那么现在：银行B可以10000块钱从wang转到li的账户上了吗？
那么现在：银行B可以10000块钱从wang转到li的账户上了吗？
银行肯定不会这么草率。。。这消息是谁发的？
如何确信？
有的同学会说：在把密码附上来，还不能表示A的身份吗？
--可以，但不安全，在明文传输时会被别人肉眼直接观测到。
数字签名
数字签名 Digital Signature
用于解决数据的“真实性”“完整性”两大 问题。
“真实性”：保证这条消息的作者是它
“完整性”：保证这条消息没有被篡改
原理：先做摘要digest，再加密，结果称为 签名Signature。
数字签名算法：HMAC-SHA1
①SHA1: 摘要，得到20字节 digest = SHA1(data);
②HMAC: 加密，结果还是20字节 signature = HMAC(digest, pin);
注：pin,个人密码, personal identity number
HMAC-SHA1可以保证“真实性”和“完整性” , "client=wang&action=transfer&amount=10000&dest=guy&verify=XXXX"
（1）完整性：由SHA1来保证
（2）真实性
假设有人冒名发出这个消息，声称自己是 wang要求转账，但它不知道用户wang的密码。。。
冒名者：
digest = SHA1 (data);
verify = HMAC (digest, "???"); // 乱猜密码
银行进行验证：
digest = SHA1 (data);
verify2 = HMAC(digest, "***"); // 用户密码
显然，verify2 != verify
结论：冒名者由于不知道用户的密码，无法仿冒
AfHmacSha1类
（1）基于crypto++
（2）hmac的密码长度不限，但越长越安全
（3）data 不限于字符串
（4）key不限于字符串
问题及注意事项
1.密码不能附在请求里传输
-- 不安全
2.为什么要摘要、后加密？不能直接对全文加密码？
-- 也可以，但速度慢
3.HMAC-SHA1是应用比较广泛的签名算法
-- 但不限于HMAC-SHA1，还有其他的先摘要后加密的签名算法。
