在開發(fā)大型系統(tǒng)時，涉及安全機制時，請閱讀本文章。內(nèi)容：加密、解密、簽名、校驗相關(guān)的算法的使用。

數(shù)據(jù)轉(zhuǎn)換算法:

將不可顯示的數(shù)據(jù)轉(zhuǎn)換為可打印文本。用于將任意的數(shù)據(jù)轉(zhuǎn)成文本形式來表示。( base64算法 / 16進制編碼 )

校驗算法：

用于檢查數(shù)據(jù)的完整性。當(dāng)接收到一段數(shù)據(jù)后，如果不確定該數(shù)據(jù)中間是否有損失，可以采用校驗類算法。（ CRC， MD5， SHA1）

對稱加密算法：

加密和解密過程可逆，采用相同的密碼。加密算法的特點是，其算法是公開的，而密鑰就是所有的秘密。 (DES/3DES/AES)

對非對稱加密算法:

加密和解密采用不同的密鑰（公鑰和私鑰），這是商務(wù)領(lǐng)域的高級別加密算法。例發(fā)，HTTPS協(xié)議就是采用了非對稱加密算法。

數(shù)字簽名：

收到一份數(shù)據(jù)后，用于確認(rèn)此數(shù)據(jù)是否被篡改。(HMAC-SHA1 )

1. DES加密

什么是DES

DES: 全稱Data Encryption Standard 是一種對稱加密算法

特點：

• 加密和解密的密鑰相同
• 分組加密，每8字節(jié)一組，密鑰也是8字節(jié)

密鑰的特殊性

DES密鑰是8個字節(jié)，但每個字節(jié)的最低位(bit0) 不參與運算。

因此，以下密鑰是等效的：

"01234567"
"00224466"
"11335577"

由于密鑰中只有56位是有效的，所以DES是一個56位的加密算法。

應(yīng)用

當(dāng)數(shù)據(jù)長度大于8個字節(jié)時，每組加密，每組8個字節(jié)。

當(dāng)數(shù)據(jù)長度小于8個字節(jié)時，下節(jié)課討論

填充 Padding

DES是每組8字節(jié)的分組加密算法

(1) 如果數(shù)據(jù)不足8字節(jié)。。。

(2) 如果密碼不足8字節(jié)。。。

當(dāng)數(shù)據(jù)不足8字節(jié)時，一般不需要特殊處理， 可以填0，可以填其他值。

一般數(shù)據(jù)本身是攜帶了長度的，例如 "helloworld"分為2個block

加密解密.png

密碼的填充

當(dāng)密碼不足8字節(jié)時，應(yīng)該填成8字節(jié)。 比如，用戶密碼為"test"，不足8字節(jié) 。

有若干種填充方式，只要加密方和解密方事 先約定好即可。 例如，填0

加密解密2.png

另外一種名叫PKCS#7的填充方法，7是編號

以"test"為例，缺4個字節(jié)，則填充值為4

加密解密3.png

如果密碼為"china"，則填充值為3

加密解密4.png

加密模式

（1）ECB模式，Electronic Code Book電子密碼本。
每一塊block的互相獨立

先解block1還是先解block2。。。沒有影響 
其中一個block丟失，其他的block還能解嗎？。。 沒影響

（2）CBC模式 Cipher Block Chaining 鏈?zhǔn)郊用?br> 由于ECB存在一定的安全缺陷（容易被“重放攻擊”？），
發(fā)明了CBC模式
CBC模式 c0 = DES_CBC(p0, key, IV);

加密解密5.png

CRC校驗

工程背景

在傳送數(shù)據(jù)時，一段N字節(jié)的數(shù)據(jù)從A傳送至B， 在接收到此數(shù)據(jù)時，如何確信此數(shù)據(jù)是完整的？

（考慮：以串口傳輸時，由于傳輸信道本身 不穩(wěn)定，存在數(shù)據(jù)中途出錯的可能性） 比如，某位數(shù)據(jù)是1，傳輸?shù)倪^程變成了0)

如果這段數(shù)據(jù)不敏感，不在乎一兩個字節(jié)的錯誤（如，一篇文章），則不用校驗。

如果這段數(shù)據(jù)敏感，即使有一個bit的錯誤， 也會使整個數(shù)據(jù)無效（如rar文件)，則需要校驗.

CRC, Cyclic Redundancy Check 循環(huán)冗余校驗

digest = CRC ( data ); 它根據(jù)一個N字節(jié)的數(shù)據(jù)，生成一個較短的結(jié)果，稱為校驗碼。(8bit,16bit,32bit)

校驗過程：

發(fā)送方：根據(jù)data，生成digest

A --(data, digest ) --> B

接收方：根據(jù)data，自己生成digest2

檢查方法：

① 如果digest != digest2 ，說明數(shù)據(jù)不完整

② 如果digest == digest2，則近似相信數(shù)據(jù)是完整的

注：

存在data不一樣，但digest相同情況， 但這種情況發(fā)生的概率很小。

注：

data的長度不受限制 CRC8,CRC16,CRC32

CRC32的準(zhǔn)確性最高，但速度相對CRC8較慢。

AfCrc32類的用法

**(1)只有一段數(shù)據(jù) **

// 生成CRC校驗碼

AfCrc32 crc; 
crc.Restart(); 
crc.Update(buf, 512); 
char digest[4]; 
crc.Final(digest); 

注：每次生成CRC之前，Restart函數(shù)需要被調(diào)用

(同一個AfCrc32對象可以被使用多次）

內(nèi)部使用crypto++，見本教程的附錄

**(2)多數(shù)數(shù)據(jù) **

當(dāng)有多段數(shù)據(jù)時（一個buf存不下，分成多段了）

 AfCrc32 crc; 
 crc.Restart(); 
 while(1) 
 { 
 int n = fread(buf,1,512,fp); 
 crc.Update(buf, n); 
 } 
 char digest[4]; 
 crc.Final(digest); 

小結(jié)
CRC用于對數(shù)據(jù)進行校驗
如果校驗失敗，應(yīng)該要求對方重傳

5.2 MD5及SHA1摘要算法

摘要算法

摘要算法和CRC的任務(wù)相同，用于檢查數(shù)據(jù)的完整性。
MD2,MD3, MD4, MD5
SHA1, SHA-224, SHA-256, SHA-384,SHA-512
最常用的是: MD5, SHA1

SHA1

SHA1: Secure Hash Algorithm 生成20字節(jié)的摘要。

Test Vectors

測試向量：
一組測試數(shù)據(jù)(data, digest)，用于檢驗算法的正確性。
例如，

data="The quick brown fox jumps over the lazy dog" (43字節(jié)） 
MD5: 9e107d9d372bb6826bd81d3542a419d6

MD5和SHA1都是常用的摘要算法，但相對來說，
MD5有點過時

6.1 數(shù)字簽名HMAC-SHA1

工程背景

在傳輸數(shù)據(jù)時，使用摘要digest可以解決數(shù)據(jù)完整性驗證的問題。。。
A --[data, digest]? B

但是還存在另外一個安全性問題：
"冒名"問題: B如何確認(rèn)這個消息是A發(fā)出來的？而不是某個搗亂的家伙A'發(fā)出來的？

假設(shè)B是一家銀行，A是B的一個客戶。
A發(fā)消息告訴B，我想要轉(zhuǎn)賬： "client=wang&action=transfer&amount=10000&dest=li"
client: 發(fā)起方客戶id
action: transfer表示轉(zhuǎn)賬
amount: 數(shù)額
dest: 目標(biāo)客戶id

涉及錢的問題都不是小事，于是，為了保證數(shù)據(jù)的完整性，需要加上一個digest作為驗證字段："client=...dest=li&digest=XXXXXXX"
藍色部分：正文
紅色部分：SHA1校驗碼，正文部分的摘要，按十六
進制轉(zhuǎn)成文本（長為40的字符串）
那么現(xiàn)在：銀行B可以10000塊錢從wang轉(zhuǎn)到li的賬戶上了嗎？

那么現(xiàn)在：銀行B可以10000塊錢從wang轉(zhuǎn)到li的賬戶上了嗎？
銀行肯定不會這么草率。。。這消息是誰發(fā)的？
如何確信？
有的同學(xué)會說：在把密碼附上來，還不能表示A的身份嗎？
--可以，但不安全，在明文傳輸時會被別人肉眼直接觀測到。

數(shù)字簽名

數(shù)字簽名 Digital Signature
用于解決數(shù)據(jù)的“真實性”“完整性”兩大 問題。
“真實性”：保證這條消息的作者是它
“完整性”：保證這條消息沒有被篡改
原理：先做摘要digest，再加密，結(jié)果稱為 簽名Signature。

數(shù)字簽名算法：HMAC-SHA1
①SHA1: 摘要，得到20字節(jié) digest = SHA1(data);
②HMAC: 加密，結(jié)果還是20字節(jié) signature = HMAC(digest, pin);

注：pin,個人密碼, personal identity number

加密解密之?dāng)?shù)字簽名.png

HMAC-SHA1可以保證“真實性”和“完整性” , "client=wang&action=transfer&amount=10000&dest=guy&verify=XXXX"

（1）完整性：由SHA1來保證
（2）真實性
假設(shè)有人冒名發(fā)出這個消息，聲稱自己是 wang要求轉(zhuǎn)賬，但它不知道用戶wang的密碼。。。

冒名者：

digest = SHA1 (data); 
verify = HMAC (digest, "???"); // 亂猜密碼 

銀行進行驗證：

digest = SHA1 (data); 
verify2 = HMAC(digest, "***"); // 用戶密碼 

顯然，verify2 != verify
結(jié)論：冒名者由于不知道用戶的密碼，無法仿冒

AfHmacSha1類
（1）基于crypto++
（2）hmac的密碼長度不限，但越長越安全
（3）data 不限于字符串
（4）key不限于字符串

問題及注意事項

1.密碼不能附在請求里傳輸
-- 不安全
2.為什么要摘要、后加密？不能直接對全文加密碼？
-- 也可以，但速度慢
3.HMAC-SHA1是應(yīng)用比較廣泛的簽名算法
-- 但不限于HMAC-SHA1，還有其他的先摘要后加密的簽名算法。