MD5---- Hash加密算法（本質上說不是加密算法，因為無法解密，准確來說是一種簽名算法）
MD5算法在實際應用中常用於鑒別信息的加密存儲（鑒別信息在傳輸前通過MD5轉為密文，與數據庫中鑒別信息進行比對，在等保測評中符合鑒別信息在傳輸過程中的保密性和完整性）
其實在Java庫當中，java.security.MessageDigest 已經實現了Md5算法(ps：該類實現了Md5和SHA算法，我們可以根據需要調用相應實例)我們可以直接調用，信息摘要是安全的單向哈希函數，它接收任意大小的數據，並輸出固定長度的哈希值。
import java.io.UnsupportedEncodingException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
public static String getDigest(String msg) throws NoSuchAlgorithmException, UnsupportedEncodingException
{
final MessageDigest md5 = MessageDigest.getInstance("MD5");
final byte[] byteArray = msg.getBytes("UTF-8");
final byte[] md5Bytes = md5.digest(byteArray);
//將生成的md5Bytes轉成16進制形式
final StringBuffer hexValue = new StringBuffer();
for (int i = 0; i < md5Bytes.length; i++)
{
int val = ((int) md5Bytes[i]) & 0xff;
if (val < 16)
hexValue.append("0");
hexValue.append(Integer.toHexString(val));
}
return hexValue.toString();
}
MD5Hash算法的特點：
1：輸入任意長度的信息，經過摘要處理，輸出為128位的信息.。（數字指紋）
2：不同輸入產生不同的結果，（唯一性）
3：根據128位的輸出結果不可能反推出輸入的信息(不可逆)
既然不可能反推出輸入的信息，可以說Md5只能用於信息驗證，而不能用來加密解密進行消息傳遞。這是與RC4的根本區別。
MD5Hash算法作用：
1：防止數據被篡改
2：防止直接看到明文 ps:在密碼存儲中，即使采用md5存儲密碼也是有可能出現安全漏洞的，比如撞庫的暴力破解
3：數字簽名
先介紹到這里，等下補上H-MAC的
HMAC算法的實現過程需要一個加密用的散列函數（表示為H）和一個密鑰。
一般我們采用的散列函數為Md5或者SHA-1，這兩個散列函數的分割數據塊長度都是64字節，即512位，HMAC-MD5算法就是采用密鑰加密+Md5信息摘要的方式形成新的密文。
由於數據塊長度為64，為了保證密鑰+data進行digest的時候的數據完整性(為什么需要保證？)最終加進數據的密鑰保證為64個字節長。
密鑰的長度可以是小於等於數據塊長度的任何正整數值。應用程序中使用的密鑰長度若是比B大，則首先使用散列函數H作用於它，然后用H輸出的L長度字符串作為MAC中實際使用的密鑰。一般情況下，推薦的最小密鑰K長度是L長(與H的輸出數據長度相等，比如MD5的L就是16字節，SHA-1是20字節)
過程如下：
(1) 在密鑰key后面添加0來創建一個長為B(64字節)的字符串（str）；
(2) 將上一步生成的字符串(str) 與ipad（0x36）做異或運算，形成結果字符串（istr）
(3) 將數據流data附加到第二步的結果字符串(istr)的末尾
(4) 做md5運算於第三步生成的數據流(istr)
(5) 將第一步生成的字符串(str) 與opad（0x5c）做異或運算，形成結果字符串（ostr）
(6) 再將第四步的結果(istr) 附加到第五步的結果字符串（ostr）的末尾
(7) 做md5運算於第6步生成的數據流（ostr），最終輸出結果(out)
注意：如果第一步中，key的長度klen大於64字節，則先進行md5運算，使其長度klen = 16字節
有人說HMAC-MD5的產生是因為碰撞率 比MD5更低？
HMAC-MD5的應用？先看下面這篇文章
通過實例演示如何建立基於SSL的安全通道連接
在當前世界中，網絡已成為不可或缺的元素。它將原來遙不可及的事物，方便快捷的聯系到一起。為了充分利用網絡所帶來的便捷，越來越多的企業選擇將信息發布在網絡上。電子商務、物聯網、雲計算與服務，也都在計划與實施中。與此同時，網絡的普及，也給信息安全帶來了挑戰。如何保證信息在不可靠網絡中的安全傳輸，成為企業 IT 實施優先考慮的問題。
SSL 是指安全套接字（Secure Socket Layer），是應用最為廣泛的安全協議。它在 TCP/IP 協議之上提供了一條安全通道，可以保證在不安全網絡環境下的數據安全。它支持各種加密算法、數字簽名、數字證書，可以防御常見的網絡攻擊。WebSphere MQ 對 SSL 具有很好的支持，從而保證消息在網絡中安全的傳送。本文在介紹 SSL 的基礎上，以實例方式詳細描述了如何在 MQ 中實現基於 SSL 的安全傳輸。文章中的實例，主要基於 MQ 7.0.1.9，同時也會介紹新版本 MQ 7.1 及 MQ 7.5 的變化。
網絡攻擊類型及應對策略
網絡將數以千萬計的機器連接在一起，環境復雜多變，所以網絡攻擊也是花樣百出。這里，根據攻擊對消息產生的影響，主要可以划分為三類：竊聽、篡改、仿冒。這三種攻擊方式，分別會破壞消息的私密性、完整性和通信雙方的互信。針對這些攻擊的特點，SSL 提供了可靠的防御策略。
1)竊聽與加密
竊聽，即偷聽別人的談話，在網絡中意味着攔截消息並偷看其中的內容。那么，為了避免消息被別人竊聽，就需要對消息進行加密。這樣，即使消息被攻擊者截獲，他們也無法輕松獲知其中的內容。
加密即按照一定的規則（加密算法）將原消息（明文）轉化為對竊聽者不可讀的密文。通信雙方共享加密的規則，所以消息接收者可以將密文再轉回可讀的明文。密鑰是一個隨機字符串，是加密及解密不可或缺的元素。發送者使用密鑰對明文加密，接收者使用密鑰對密文解密。
通信雙方可以共享一個相同的密鑰，用於加密和解密。這稱為對稱加密或者秘密密鑰加密。這種方法的優勢是速度快，劣勢是難以安全的傳遞密鑰，特別是有很多通信對象時。要安全的將密鑰交到通信方，你需要和每一個人見面。為了解決這個問題，就出現了不對稱加密或者公共密鑰加密。使用這種方法，每一個通信對象都有一個密鑰對：公鑰和私鑰。發送者使用對方的公鑰加密，接收者使用自己的私鑰解密。因為公鑰是公開的，這就解決了密鑰傳遞的問題。但是，也造成了一些性能的損失。在實際的應用中，為了避免密鑰傳遞問題同時保證性能，通常使用不對稱加密來交換密鑰，然后使用對稱加密傳輸數據。
加密是一個非常重要，也非常活躍的研究領域，有非常多的加密算法。例如，數據加密標准（DES），三重 DES，RC2 和 RC4 等。
2)篡改與消息摘要
篡改是指攻擊者攔截並修改消息的內容。加密不能避免消息被修改，接收者也無法判斷消息是否被修改過。這里，就需要用到消息摘要（Message Digest）技術。消息摘要是一個表示消息特征的定長字符串。它有兩個重要的特征：不可逆性和抗沖突性。不可逆性是指從消息可以計算出消息概要，但是從消息摘要基本不可能得到消息；抗沖突性是指要想產生具有相同摘要值的兩條消息是相當困難的。這兩個特性，使消息摘要可以用來驗證消息的完整性。發送者使用摘要算法計算出消息摘要，並隨同消息發送給對方；接收者收到消息以后，同樣會根據消息計算出消息摘要 , 並和收到的摘要對比。如果兩者相同，則表示消息沒有被篡改。
在實際應用中，消息摘要很少被單獨使用，通常用於數字簽名和消息認證碼（MAC）。消息認證碼是基於消息和密鑰生成的消息摘要。它在驗證完整性同時，可以在一定程度上完成用戶驗證功能。數字簽名是經過加密的消息摘要。
(PS:似乎就是消息被篡改了我必須知道，從而發現並處理這個篡改事件)
3)仿冒與數字證書
仿冒即假冒別人進行通信。消息認證碼可以用來驗證消息的發送者。數字簽名則更進一步，具有不可抵賴性。因為數字簽名是使用發送者私鑰加密的消息摘要，只有發送者才能產生。這一切似乎都很完美，使用加密防止竊聽，使用摘要防止篡改，使用數字簽名防止仿冒，似乎不要什么數字證書。
事實當然不是這樣，下面的攻擊方式將瓦解以上所有的防線。這就是中間人攻擊（man-in-the-middle attack）。在通信雙方交換公鑰的過程中，攻擊者攔截雙方的公鑰，並將自己的密鑰發送給通信雙方。這樣，通信雙方就會使用攻擊者的密鑰加密。在這樣情況下，所有的加密、簽名都失效了。中間人攻擊細節如下圖所示：
圖 1.中間人攻擊
就會使用攻擊者的密鑰加密。在這樣情況下，所有的加密、簽名都失效了。中間人攻擊細節如下圖所示：
圖 1.中間人攻擊
從上圖可以看出，第 1, 2, 3, 4 步是公鑰交換過程。在此過程中，攻擊者獲得了發送方和接收方的公鑰，而將自己的公鑰發送給通信雙方。第 5, 6, 7, 8 步是發送消息的過程。在此過程中，發送方和接收方都是用攻擊者公鑰加密，而攻擊者截獲數據后重新使用通信雙方公鑰加密，這就使雙方難以察覺攻擊者的存在。
要防范中間人攻擊，就需要使用數字證書，這里，數字證書主要指由專門的證書頒發機構（CA）授權的證書，稱為 CA 證書。CA 證書將證書屬主信息和公鑰綁定到一起。證書頒發機構負責驗證證書申請者的身份信息。通過可信的第三方（CA），通信方可以向任何人證明其擁有的公鑰，其他人也可以通過 CA 驗證其證書真偽，這就阻止了中間人攻擊。CA 證書一般包含所有者的公鑰 , 所有者的專有名稱 , 簽發證書的 CA 的專有名稱 , 證書開始生效的日期 , 證書過期日期等信息。
與 CA 證書相對應的，還有自簽署證書。
自簽署證書一般用在測試環境中。在后面的章節中，會使用自簽署證書實現基於 SSL 的安全連接。
SSL 握手
SSL 連接實現主要分為兩部分：SSL 握手和數據傳輸。前者使用 SSL 握手協議建立連接，后者使用記錄協議傳輸數據。這里，主要介紹 SSL 握手流程。握手是 SSL 客戶端和 SSL 服務器端完成認證，並確定用於數據傳輸的加密密鑰的過程。這里，SSL 客戶端是指主動發起連接的一端，不要和 MQ 客戶端混淆。SSL 握手具體流程如下：
- SSL 客戶端發送“Hello”消息給 SSL 服務器端，並列出客戶端所支持的 SSL 版本、加密算法和摘要算法。在實際應用中，一般將加密算法和摘要算法結合到一起，組成一個加密套件。同時，客戶端還會發送一個隨機數，用於以后產生加密密鑰。
- SSL 服務器端對客戶端的連接請求作出回應。從客戶端提供的加密套件列表中，選擇要使用的加密套件，並產生另外一個隨機數。同時，服務器端會發送自己的數字證書給客戶端，里面包含服務器端的認證信息及公共密鑰。如果服務器端需要驗證客戶端，它還會在消息中包含要求客戶端提供數字證書的請求。
- 客戶端收到服務器端的回應。它首先使用 CA 證書驗證服務器端證書的有效性。在此過程中，客戶端會檢查證書的簽名、證書認證路徑、有效日期、證書狀態等。驗證通過后，抽取出其中的公鑰。客戶端產生另外一個隨機數，並使用服務器端的公鑰加密后發送給服務器端。
- 如果服務器端要求客戶端提供證書，客戶端會將隨機數用私鑰加密，連同證書發送給服務器端。服務器端對客戶端的證書進行驗證，並使用客戶端的公鑰解密收到的隨機數。
- 服務器端和客戶端基於前面提供的隨機數，計算出用於數據加密的共享密鑰。
- 客戶端將所有握手消息的 MAC 值發送給服務器端，服務器端也將所有握手消息的 MAC 值發送給客戶端。這么做是為了防止攻擊者在握手過程中篡改了消息內容。
- 客戶端和服務器端使用握手過程中產生的加密密鑰交換握手結束消息。握手結束，SSL 連接建立。
在 SSL 連接建立后，將開始遵循記錄協議對數據進行傳輸。
WebSphere MQ SSL 配置與管理
WebSphere MQ 支持安全套接字協議（SSL）和傳輸層安全協議（TLS，是 SSL 的后續版本）。在本章中，主要介紹 GSKit，以及與 SSL/TLS 相關的隊列管理器屬性及通道屬性。用戶可以使用 MQ 資源管理器設置這些屬性，也可以使用 MQSC 命令設置。
MQ 與 GSKit
MQ 對 SSL 的支持，是通過 GSKit（Global Security Kit）實現的。GSkit 提供實現 SSL 所必須的函數庫及工具，被應用於很多 IBM 產品。
在 MQ 7.0 及以前的版本中，GSKit 是單獨安裝的，版本是 GSKit V7.0。從 MQ 7.0.1 開始，引入 GSKit V8.0 作為可選版本。在 MQ 后續版本 MQ 7.1 和 MQ 7.5 中 GSKit V8.0 完全取代 GSKit 7.0，成為默認版本並集成到 MQ 安裝包中。
與 GSKit V7.0 相比，GSKit V8.0 支持新的更安全的散列算法 SHA-2，支持所有 Java 環境中的密鑰重置，支持更嚴格的 FIPS 認證以及多語言的錯誤輸出。具體的細節，請參考 MQ 信息中心文檔。
GSKit V7.0 和 GSKit V8.0 可以共存於同一系統中，不同的隊列管理器可以選擇使用不用的 GSKit 版本。
此外，GSKit V8.0 還集成了 GSKCapiCmd 命令，用於管理密鑰、證書請求及證書。同時，用戶也可 iKeyman （IBM Key Management）工具實現同樣的功能。一般來說，iKeyman 可以隨 MQ 一起安裝，並且具有 GUI 界面，使用比較方便。
（注：本文部分內容來源於網絡）