前言
在之前的文章《深入淺出密碼學（上）》中，筆者為大家簡要介紹了密碼學中的加密跟單向雜湊函式的概念與應用。在這裡先簡單回顧下，由於網路通訊過程中存在資訊被竊聽的風險，因此需要通過加密來防止竊聽以保護資訊保安。此外，在網路通訊中資料還存在被篡改的風險，因此我們還需要有一種機制能夠識別資料是否被篡改，而單向雜湊函式正是能夠識別資料一致性或完整性的一種機制。然而單向雜湊函式不能解決的乙個問題是不能確認訊息一定是傳送者的本意，也就是說無法識別「偽裝」，為什麼這樣說呢？且聽我細細道來。
一、單向雜湊函式的侷限性
二、訊息認證碼
訊息認證碼是一種確認資料完整性並進行認證的技術，簡稱mac。所謂認證，就是能驗證訊息的確是由某個人傳送過來的，因此可以識別「偽裝」。訊息認證碼的輸入包括任意長度的訊息和乙個傳送者與接收者共享的金鑰，其輸出為固定長度的值，這個值稱為mac值。根據任意長度的訊息輸出固定長度的值，這一點跟單向雜湊函式很類似，但是有乙個最大的區別就是，單向雜湊函式不需要金鑰，而訊息認證碼需要金鑰。並且只有正確的金鑰才能計算mac值，沒有金鑰或者沒有正確的金鑰都是沒辦法計算出預期的mac值的，而因為金鑰是由通訊雙方共享的，因此只有通訊雙方才能對訊息計算出正確的mac值，故而使用訊息認證碼可以起到認證的作用，即驗證訊息確實是由可信方傳送的。訊息認證碼的使用步驟如下：
小明跟小白首先需要約定好共享金鑰。
傳送者小明根據共享金鑰對訊息計算mac值
傳送者小明將訊息與訊息認證碼傳送給接受者小白
小白接收到訊息後根據共享金鑰計算出mac值
小白將計算出的mac值與收到的mac值進行比較
如果兩者一致，則說明訊息沒有被篡改，並且確實是由小明傳送過來的。
從上面的步驟可以看出，訊息認證碼跟對稱加密有點類似。兩者的主要區別是：訊息認證碼的作用是為了驗證訊息完整性以及對訊息傳送者進行認證，而對稱加密是為了保證訊息的私隱性，防止被竊聽；再者，訊息認證碼的認證過程需要傳送訊息跟mac值，而對稱加密只需要傳送密文；還有乙個區別是，mac值一般具有單向性，即只能從訊息計算出mac值，不能從mac值還原出訊息，而對稱加密則既可以將明文加密成密文，也能將密文解密成明文。
三、訊息認證碼的侷限性
對了說明訊息認證碼的侷限性，本文將引入乙個場景進行說明。假設小明跟小白在通訊的過程中使用了訊息認證碼，他們兩個人除了正常通訊外，還需要向第三方小灰證明訊息的確是是自己傳送或者對方傳送的。那麼在這種情況下，訊息認證碼是無法實現這個功能的。為什麼這樣說呢？大家回顧下上述生成訊息認證碼的過程，我們需要使用金鑰才能生成mac值，而金鑰是由通訊雙方共享的，這就意味著通訊雙方都可以生成mac值，也就是說小明跟小白都可以生成mac值，這樣一來就不能證明這個mac值究竟是誰生成的，這也就導致了無法向第三方證明某條訊息一定是對方傳送的，同理也無法證明某條訊息一定是自己傳送的。
除此之外，訊息認證碼還有乙個侷限就是無法防止否認。簡單來說就是存在抵賴的風險。其原因也是因為共享金鑰導致的。因為金鑰是通訊雙方共享的，因此通訊雙方都可以生成訊息的mac值，故而如果通訊的一方傳送了某些訊息，又拒不承認，反而「誣陷」是對方傳送的，在這種情況下訊息認證碼是無法進行仲裁的。
最後乙個侷限性還是因為共享金鑰導致的，在之前的文章《深入淺出密碼學（上）》中，講解了對稱加密帶來的乙個問題就是金鑰的配送問題，同理訊息認證碼同樣也有金鑰的配送問題，金鑰配送的安全性決定了訊息認證碼的安全性。
既然訊息認證碼有這麼多侷限性，那麼是否有其他方法可以解決上述問題的？當然是有的。那就是數字簽名。由於篇幅所限，後續再為大家介紹數字簽名的原理。
深入淺出密碼學（中）
前言 在之前的文章 深入淺出密碼學 上 中，筆者為大家簡要介紹了密碼學中的加密跟單向雜湊函式的概念與應用。在這裡先簡單回顧下，由於網路通訊過程中存在資訊被竊聽的風險，因此需要通過加密來防止竊聽以保護資訊保安。此外，在網路通訊中資料還存在被篡改的風險，因此我們還需要有一種機制能夠識別資料是否被篡改，而...
深入淺出密碼學（上）
前言 無論你有沒有意識到，日常生活中我們幾乎每天都在跟密碼學打交道。只要你接觸過網際網路，那麼基本上離不開密碼學。舉個最簡單的例子，現在的很多 都是通過https協議進行通訊的，而支撐著https協議正常執行的正是密碼學這一理論基礎。作為程式設計師，我們更是有必要了解下密碼學的一些基本理論及其背後的...
深入淺出學Hive Hive引數
第一部分 hive 引數 hive.exec.max.created.files 說明 所有hive執行的map與reduce任務可以產生的檔案的和 預設值 100000 hive.exec.dynamic.partition 說明 是否為自動分割槽 預設值 false hive.mapred.re...