什麼是數字簽名呢?數字簽名其實是訊息摘要和非對稱加密的一起應用。
數字簽名是怎麼來的呢？
在非對稱加解密中，公鑰方對私鑰方傳送訊息，只需要公鑰方用公鑰加密即可，因為私鑰只有一人持有。
那麼私鑰方給公鑰方傳送資料是否可以用私鑰傳送即可呢？當然可以的啊。
但是又乙個問題就是私鑰加密後，所有的公鑰都可以解開，那麼問題來了是否安全呢？
也就是說私鑰加密公鑰去解密的意義並不大。而且私鑰是單方，單方作為伺服器的話去加密可想而知效率問題就很大了。
回到問題得原點上，我們要驗證的是什麼問題呢？
驗證的是如何保證公鑰方如何確認私鑰方的身份，收到私鑰方的資訊沒有串改過？
確定私鑰方的身份只能通過私鑰要確認，那麼如果用私鑰加密效率低，那麼是否記得如何進行檔案校驗的呢？檔案校驗就是訊息摘要，取一部分進行加密啊。
那麼數字簽名就是這樣子的：
私鑰方 通過hash要傳送的內容，然後用私鑰進行加密就是數字簽名和內容一起傳送出去。
公鑰方取下數字簽名，然後對簽名進行解密，也就是得到hash的內容。這個時候就確認了秘鑰方的身份。
那麼如果確認資訊沒有在中途改過呢？
那麼可以這樣，公鑰方對內容進行hash，然後和數字簽名解密出來的進行對比，如果相等就沒有串改，如果不相等就串改了。
這樣似乎就很愉快了，那麼為啥又有數字證書這東西呢？
是這樣的，我們知道公鑰方是靠公鑰作為探頭來識別私鑰資訊。
那麼問題來了，如果發生一件這種事情就是公鑰方的公鑰被黑客換了，那麼這個時候就有乙個情況了。
加入公鑰被換了，那麼和原來的私鑰方無法確認關係了，但是這不是最恐怖的，最恐怖的在於假設有乙個黑客，生成了b私鑰和b公鑰。
把b公鑰和公鑰方的公鑰換了，然後用私鑰b和公鑰方溝通，那麼這個時候呢，可想而知多麼恐怖。公鑰方會一直認為是在和私鑰方溝通，其實一直在和黑客玩耍。
這時候數字證書的作用就來了。
首先有一家公共的ca機構，專門管理證書。它做了這麼一件事，那就是用自己的私鑰對其他私鑰方的公鑰和其他資訊進行加密。
那麼私鑰方在公鑰方第一次請求自己資訊的時候，把證書給公鑰方，公鑰方通過證書拿到公鑰，而不是乙個固定的公鑰，這樣子就很好了。
來看下https的吧。
下面是阮一峰的解釋:
1.首先，客戶端向伺服器發出加密請求。
伺服器用自己的私鑰加密網頁以後，連同本身的數字證書，一起傳送給客戶端。
客戶端（瀏覽器）的"證書管理器"，有"受信任的根證書頒發機構"列表。客戶端會根據這張列表，檢視解開數字證書的公鑰是否在列表之內。
就是證書裡面的**和我們瀏覽的**不一致。
如果這張數字證書不是由受信任的機構頒發的，瀏覽器會發出另一種警告。
如果數字證書是可靠的，客戶端就可以使用證書中的伺服器公鑰，對資訊進行加密，然後與伺服器交換加密資訊。
《密碼學系列》 分組密碼
繼上一期的流密碼之後，我們就趁熱打鐵趕緊來看看分組密碼是怎麼一回事呢？在常用的一些密碼系統中，分組密碼在維護系統安全中仍然扮演著乙個重要角色，同流密碼一樣，分組密碼的使用也有許許多多需要我們注意的問題。分組密碼是什麼呢？分組分組顧名思義就是將明文訊息分成組來進行加密，也就是說，加密器每次只能處理特定...
密碼學 什麼是數字簽名
1 場景 傳送方 a 需要給 b 傳送一條訊息，為了保證資料的完整性，a 在訊息的後面新增該訊息的 hash 值。問題 由於訊息是明文的，中間人可以截獲該訊息並生成新訊息的 hash 發給 b。為了解決上述問題，有如下方案 1 這條訊息用 a 和 b 共享的金鑰進行對稱加密。2 hash 值用 a ...
Lauren與密碼學9，數字簽名
lauren 我思考了一下，採用訊息認證碼的手套訂單還是有問題。客戶生成訂單，計算hash值，並且給hash值加密。這樣防止了篡改和別人偽造，但是因為密碼是在工廠與客戶之間共享的。客戶和工廠都有生成一模一樣訂單的能力。客戶否認說我沒有發過這個訂單，是工廠自己偽造的訂單。技術上來講，訊息認證碼沒有辦法...