⑴ java checksum的校驗方式
public class CRC {
/**
* CRC-CCITT(Kermit)驗證模式
* @param str
* @return
*/
public String CRC_CCITT_Kermit(String str) {
int j, b, rrrc, c, i;
String tmpBalance;
int k;
rrrc = 0;
tmpBalance = str;
int tmpInt, CharInt;
String tmpChar, tmpStr;
tmpStr = "";
int High;
int Low;
for (j = 1; j <= 3; j++) {
if (Character.isDigit(tmpBalance.charAt(2 * j - 2))) {
High = Integer.parseInt(tmpBalance.charAt(2 * j - 2) + "");
} else {
High = 0;
}
if (Character.isDigit(tmpBalance.charAt(2 * j - 1))) {
Low = Integer.parseInt(tmpBalance.charAt(2 * j - 1) + "");
} else {
Low = 0;
}
High = (High & 0xff) << 4;
High = High | Low;
k = High;
for (i = 1; i <= 8; i++) {
c = rrrc & 1;
rrrc = rrrc >> 1;
if ((k & 1) != 0) {
rrrc = rrrc | 0x8000;
}
if (c != 0) {
rrrc = rrrc ^ 0x8408;
}
k = k >> 1;
}
}
for (i = 1; i <= 16; i++) {
c = rrrc & 1;
rrrc = rrrc >> 1;
if (c != 0) {
rrrc = rrrc ^ 0x8408;
}
}
c = rrrc >> 8;
b = rrrc << 8;
rrrc = c | b;
tmpInt = rrrc;
tmpStr = "";
for (i = 1; i <= 4; i++) {
tmpChar = "";
CharInt = tmpInt % 16;
if (CharInt > 9) {
switch (CharInt) {
case 10:
tmpChar = "A";
break;
case 11:
tmpChar = "B";
break;
case 12:
tmpChar = "C";
break;
case 13:
tmpChar = "D";
break;
case 14:
tmpChar = "E";
break;
case 15:
tmpChar = "F";
break;
}
} else {
tmpChar = Integer.toString(CharInt);
}
tmpInt = tmpInt / 16;
tmpStr = tmpChar + tmpStr;
}
System.out.println("tmpStr:" + tmpStr);
return tmpStr;
}
/**
* CRC-CCITT(XModem)
* CRC-CCITT(0xFFFF)
* CRC-CCITT(0x1D0F)
* 校驗模式
* @param flag< XModem(flag=1) 0xFFFF(flag=2) 0x1D0F(flag=3)>
* @param str
* @return
*/
public String CRC_CCITT( int flag,String str) {
int crc = 0x00; // initial value
int polynomial = 0x1021;
byte[] bytes=str.getBytes();
switch(flag){
case 1:
crc=0x00;
break;
case 2:
crc=0xFFFF;
break;
case 3:
crc=0x1D0F;
break;
}
for (int index = 0 ; index< bytes.length; index++) {
byte b = bytes[index];
for (int i = 0; i < 8; i++) {
boolean bit = ((b >> (7-i) & 1) == 1);
boolean c15 = ((crc >> 15 & 1) == 1);
crc <<= 1;
if (c15 ^ bit) crc ^= polynomial;
}
}
crc &= 0xffff;
str = Integer.toHexString(crc);
return str;
}
⑵ 校驗和怎麼計算
檢驗和(checksum)，在數據處理和數據通信領域中，用於校驗目的地一組數據項的和。它通常是以十六進制為數製表示的形式。如果校驗和的數值超過十六進制的FF，也就是255. 就要求其補碼作為校驗和。通常用來在通信中，尤其是遠距離通信中保證數據的完整性和准確性。
這些數據項可以是數字或在計算檢驗的過程中看作數字的其它字元串。校驗和（checksum）是指傳輸位數的累加，當傳輸結束時，接收者可以根據這個數值判斷是否接到了所有的數據。如果數值匹配，那麼說明傳送已經完成。TCP和UDP傳輸層都提供了一個校驗和與驗證總數是否匹配的服務功能。[1]
它通常是以十六進制為數製表示的形式
發送方生成檢驗和
1.將發送的進行檢驗和運算的數據分成若干個16位的位串，每個位串看成一個二進制數，這里並不管字元串代表什麼，是整數、浮點數還是點陣圖都無所謂。
2.將IP、UDP或TCP的PDU首部中的檢驗和欄位置為0，該欄位也參與檢驗和運算。
3.對這些16位的二進制數進行1的補碼和(one'scomplementsum)運算，累加的結果再取反碼即生成了檢驗碼。將檢驗碼放入檢驗和欄位中。
其中1的補碼和運算，即帶循環進位(end round carry)的加法，最高位有進位應循環進到最低位。反碼即二進制各位取反，如0111的反碼為1000。
接收方校驗檢驗和
1.接收方將接收的數據(包括檢驗和欄位)按發送方的同樣的方法進行1的補碼和運算，累加的結果再取反碼。
2.校驗，如果上步的結果為0，表示傳輸正確；否則，說明傳輸有差錯。
⑶ IP/UDP/TCP/ICMP數據報協議的校驗和的區別和計算
首先，IP、ICMP、UDP和TCP報文頭部都有校驗和欄位，大小都是16bit，演算法也基本一樣：
在發送數據時，為了計算數據包的校驗和。應該按如下步驟：
（1）把校驗和欄位置為0；
（2）把需校驗的數據看成以16位為單位的數字組成，依次進行二進制反碼求和；（3）把得到的結果存入校驗和欄位中。在接收數據時，計算數據包的校驗和相對簡單，按如下步驟：
（1）把首部看成以16位為單位的數字組成，依次進行二進制反碼求和，包括校驗和欄位；
（2）檢查計算出的校驗和的結果是否為0；
（3）如果等於0，說明被整除，校驗是和正確。否則，校驗和就是錯誤的，協議棧要拋棄這個數據包。
雖然上面四種報文的校驗和演算法一樣，但在作用范圍存在不同：IP校驗和只校驗20位元組的IP報頭；而ICMP校驗和覆蓋整個報文（ICMP報頭+ICMP數據）；UDP和TCP校驗和不僅覆蓋整個報文，而且還有12位元組的IP偽首部，包括源IP地址(4位元組)、目的IP地址(4位元組)、協議(2位元組，第一位元組補0)和TCP/UDP包長(2位元組)。另外UDP、TCP數據報的長度可以為奇數位元組，所以在計算校驗和時需要在最後增加填充位元組0（注意，填充位元組只是為了計算校驗和，可以不被傳送）。
這里還要提一點，UDP的校驗和是可選的，當校驗和欄位為0時，表明該UDP報文未使用校驗和，接收方就不需要校驗和檢查了！那如果UDP校驗和的計算結果是0時怎麼辦呢？書上有這么一句話：「如果校驗和的計算結果為0，則存入的值為全1（65535），這在二進制反碼計算中是等效的。」
講了這么多，那這個校驗和到底是怎麼算的呢？
1. 什麼是二進制反碼求和
對一個無符號的數，先求其反碼，然後從低位到高位，按位相加，有溢出則向高位進1（跟一般的二進制加法規則一樣），若最高位有進位，則向最低位進1。
首先這里的反碼好像跟我們以前學的有符號數的反碼不一樣（即正數的反碼是其本身，負數的反碼是在其原碼的基礎上，符號位不變，其餘各位取反），這里不分正負數，直接每個位都取反！
上面加粗的那句是跟我們一般的加法規則不太一樣的地方：最高位有進位，則向最低位進1。確實有些疑惑，為什麼要這樣做呢？仔細分析一下（為了方便說明，以 4bit二進制反碼求和舉例），上面的這種操作，使得在發生加法進位溢出時，溢出的值並不是10000，而是1111。也即是當相加結果滿1111時溢出，這樣也可以說明為什麼0000和1111都表示0了（你同樣可以發現，任何數與這兩個數做二進制反碼求和運算結果都是原數，這恰好符合數0的加法意義）。
下面再舉例兩種二進制反碼求和的運算：
原碼加法運算 反碼加法運算
3（0011）+ 5（0101）= 8（1000） 3（1100）+ 5（1010）= 8（0111）
8（1000）+ 9（1001）= 1（0001） 8（0111）+ 9（0110）= 2（1101）
從上面兩個例子可以看出，當加法未發生溢出時，原碼與反碼加法運算結果一樣；當有溢出時，結果就不一樣了，原碼是滿10000溢出，而反碼是滿1111溢 出，所以相差正好是.
1。舉例只是為了形象地觀察二進制反碼求和的運算規則，至於為什麼要定義這樣的規則以及該運算規則還存在其它什麼特性，可能就需要涉及 代數理論的東西的了（嗚嗚~~數學理論沒學好啊，只能從表面上分析分析）。
另外關於二進制反碼求和運算需要說明的一點是，先取反後相加與先相加後取反，得到的結果是一樣的！（事實上我們的編程演算法里，幾乎都是先相加後取反。）
2. 校驗和演算法的實現
講了什麼是二進制反碼求和，那麼校驗和的演算法實現就簡單多了。廢話少說，直接上代碼：
[cpp] view plain
//計算校驗和
USHORT checksum(USHORT *buffer,int size)
{
unsigned long cksum=0;
while(size>1)
{
cksum+=*buffer++;
size-=sizeof(USHORT);
}
if(size)
{
cksum+=*(UCHAR *)buffer;
}
//將32位數轉換成16
while (cksum>>16)
cksum=(cksum>>16)+(cksum & 0xffff);
return (USHORT) (~cksum);
}
buffer是指向需校驗數據緩存區的指針，size是需校驗數據的總長度（位元組為單位）
4~13行代碼對數據按16bit累加求和，由於最高位的進位需要加在最低位上，所以cksum必須是32bit的unsigned long型，高16bit用於保存累加過程中的進位；另外代碼10~13行是對size為奇數情況的處理！
14~16行代碼的作用是將cksum高16bit的值加到低16bit上，即把累加中最高位的進位加到最低位上。這里使用了while循環，判斷cksum高16bit是否非零，因為第16行代碼執行的時候，仍可能向cksum的高16bit進位。
有些地方是通過下面兩條代碼實現的：
cksum = (cksum >> 16) + (cksum & 0xffff);
cksum += (cksum >>16);
這里只進行了兩次相加，即可保證相加後cksum的高16位為0，兩種方式的效果一樣。事實上，上面的循環也最多執行兩次！
17行代碼即對16bit數據累加的結果取反，得到二進制反碼求和的結果，然後函數返回該值。
3. 為什麼使用二進制反碼求和呢？
好了，最後一個問題，為什麼要使用二進制反碼來計算校驗和呢，而不是直接使用原碼或者補碼？
這個問題我想了很久，由於水平有限實在弄不明白，於是在網路上一陣狂搜，什麼都沒有（不知道是網路不給力，還是大家都不關注這個問題呢？）。果斷換google，敲了3個關鍵詞：why checksum tcp，嘿嘿 結果第二篇就是我想要的文章了！！！
先把鏈接給大家吧：http://www.netfor2.com/checksum.html
這篇文章主要介紹二進制反碼求和（the 1's complement sum）與補碼求和（the 2's complement sum）的區別，另外還說明了在TCP/IP校驗和中使用反碼求和的優點。
It may look awkword to use a 1's complement addition on 2's complement machines. This method however has its own benefits.
Probably the most important is that it is endian independent. Little Endian computers store hex numbers with the LSB last (Intel processors for example). Big Endian computers put the LSB first (IBM mainframes for example). When carry is added to the LSB to form the 1's complement sum (see the example) it doesn't matter if we add 03 + 01 or 01 + 03. The result is the same.
Other benefits include the easiness of checking the transmission and the checksum calculation plus a variety of ways to speed up the calculation by updating only IP fields that have changed.
上面是原文的一部分，說明在TCP/IP校驗和中使用反碼求和的一些優點：
a. 不依賴系統是大端還是小端。 即無論你是發送方計算或者接收方檢查校驗和時，都不需要調用htons 或者 ntohs，直接通過上面第2節的演算法就可以得到正確的結果。這個問題你可以自己舉個例子，用反碼求和時，交換16位數的位元組順序，得到的結果相同，只是位元組順序相應地也交換了；而如果使用原碼或者補碼求和，得到的結果可能就不相同！
b. 計算和驗證校驗和比較簡單，快速。說 實話，這個沒怎麼看明白，感覺在校驗和計算方面，原碼或者補碼求和反而更簡單一些（從C語言角度），在校驗和驗證上面，通過一樣的演算法判斷結果是否為全 0，確實要方便一些，所以可能從綜合考慮確實反碼求和要簡便一些。另外，IP報文在傳輸過程中，路由器經常只修改TTL欄位（減1），此時路由器轉發該報 文時可以直接增加它的校驗和，而不需要對IP整個首部進行重新計算。當然，可能從匯編語言的角度看，反碼求和還有很多高效的地方，這里就不在深入追究 了~~~
⑷ 網路安全-哈希演算法和數字簽名
常見 HASH 演算法：
HASH 演算法主要應用：
1）文件校驗
我們比較熟悉的校驗演算法有奇偶校驗和CRC校驗，這2種校驗並沒有抗數據虛仔篡改的能力，它們一定程度上能檢測並糾正數據傳輸中的信道誤碼，但卻不能防止對數據的惡意破壞。
MD5 Hash演算法的"數字指紋"特性，使它成為目前應用最廣泛的一種文件完整性校驗和（Checksum）演算法，棗耐不少Unix系統有提供計算md5 checksum的命令。
2）數字簽名
Hash 演算法也是現代密碼體系中的一個重要組成部分。由於非對稱演算法的運算速度較慢，所以在數字簽名協議中，單向散列函數扮演了一個重要的角色。對 Hash 值，又稱"數字摘要"進行數字簽名，在統計上可以認為與差岩汪對文件本身進行數字簽名是等效的。而且這樣的協議還有其他的優點。
3）鑒權協議
如下的鑒權協議又被稱作"挑戰--認證模式：在傳輸信道是可被偵聽，但不可被篡改的情況下，這是一種簡單而安全的方法。
數字簽名簽署和驗證數據的步驟如圖所示：
PKCS1 和 PKCS7 標准格式的簽名：
1. PKCS1簽名：即裸簽名，簽名值中只有簽名信息。
2. PKCS7簽名：簽名中可以帶有其他的附加信息，例如簽名證書信息、簽名原文信息、時間戳信息等。
PKCS7 的 attached 和 detached 方式的數字簽名：
1. attached 方式是將簽名內容和原文放在一起，按 PKCS7 的格式打包。PKCS7的結構中有一段可以放明文，但明文必需進行ASN.1編碼。在進行數字簽名驗證的同時，提取明文。這里的明文實際上是真正內容的摘要。
2. detached 方式打包的 PKCS7格式包中不包含明文信息。因此在驗證的時候，還需要傳遞明文才能驗證成功。同理，這里的明文實際上是真正內容的摘要。