數字簽名：
將報文按雙方約定的HASH算法計算得到一個固定位數的報文摘要。在數學上保證：只要改動報文中任何一位，重新計算出的報文摘要值就會與原先的值不相符。這樣就保證了報文的不可更改性。
將該報文摘要值用發送者的私人密鑰加密，然後連同原報文一起發送給接收者，而產生的報文即稱數字簽名
數字證書：
數字證書就是互聯網通訊中標誌通訊各方身份信息的一系列數據，提供了一種在Internet上驗證您身份的方式，其作用類似於司機的駕駛執照或日常生活中的身份證。它是由一個由權威機構-----CA機構，又稱爲證書授權（Certificate Authority）中心發行的，人們可以在網上用它來識別對方的身份。數字證書是一個經證書授權中心數字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。最簡單的證書包含一個公開密鑰、名稱以及證書授權中心的數字簽名。
以下是我在網上看到的例子，覺得說的很形象，就參考過來具體說明：
原地址 http://netsecurity.51cto.com/art/201108/287971.htm
1.鮑勃有兩把鑰匙，一把是公鑰，另一把是私鑰。
2.鮑勃把公鑰送給他的朋友們----帕蒂、道格、蘇珊----每人一把。
3.蘇珊要給鮑勃寫一封保密的信。她寫完後用鮑勃的公鑰加密，就可以達到保密的效果。
4.鮑勃收信後，用私鑰解密，就看到了信件內容。這裏要強調的是，只要鮑勃的私鑰不泄露，這封信就是安全的，即使落在別人手裏，也無法解密。
5.鮑勃給蘇珊回信，決定採用"數字簽名"。他寫完後先用Hash函數，生成信件的摘要（digest）。
6.然後，鮑勃使用私鑰，對這個摘要加密，生成"數字簽名"（signature）。
7.鮑勃將這個簽名，附在信件下面，一起發給蘇珊。
8.蘇珊收信後，取下數字簽名，用鮑勃的公鑰解密，得到信件的摘要。由此證明，這封信確實是鮑勃發出的。
9.蘇珊再對信件本身使用Hash函數，將得到的結果，與上一步得到的摘要進行對比。如果兩者一致，就證明這封信未被修改過。
10.複雜的情況出現了。道格想欺騙蘇珊，他偷偷使用了蘇珊的電腦，用自己的公鑰換走了鮑勃的公鑰。此時，蘇珊實際擁有的是道格的公鑰，但是還以爲這是鮑勃的公鑰。因此，道格就可以冒充鮑勃，用自己的私鑰做成"數字簽名"，寫信給蘇珊，讓蘇珊用假的鮑勃公鑰進行解密。
11.後來，蘇珊感覺不對勁，發現自己無法確定公鑰是否真的屬於鮑勃。她想到了一個辦法，要求鮑勃去找"證書中心"（certificate
authority，簡稱CA），爲公鑰做認證。證書中心用自己的私鑰，對鮑勃的公鑰和一些相關信息一起加密，生成"數字證書"（Digital
Certificate）。
12.鮑勃拿到數字證書以後，就可以放心了。以後再給蘇珊寫信，只要在簽名的同時，再附上數字證書就行了。
13.蘇珊收信後，用CA的公鑰解開數字證書，就可以拿到鮑勃真實的公鑰了，然後就能證明"數字簽名"是否真的是鮑勃籤的。
14.下面，我們看一個應用"數字證書"的實例：https協議。這個協議主要用於網頁加密。
15.首先，客戶端向服務器發出加密請求。
16.服務器用自己的私鑰加密網頁以後，連同本身的數字證書，一起發送給客戶端。
17.客戶端（瀏覽器）的"證書管理器"，有"受信任的根證書頒發機構"列表。客戶端會根據這張列表，查看解開數字證書的公鑰是否在列表之內。
18.如果數字證書記載的網址，與你正在瀏覽的網址不一致，就說明這張證書可能被冒用，瀏覽器會發出警告。
19.如果這張數字證書不是由受信任的機構頒發的，瀏覽器會發出另一種警告。
20.如果數字證書是可靠的，客戶端就可以使用證書中的服務器公鑰，對信息進行加密，然後與服務器交換加密信息。
----------------------------------------------------------
關於加密解密的一些問題？
參考自：http://blog.csdn.net/sszgg2006/article/details/8199175
問題 1: 最自然的想法是，甲必須對文件加密才能保證不被其他人查看其內容，那麼 , 到底應該用什麼加密技術，才能使合同傳送既安全又快速呢 ?
可以採用一些成熟的對稱加密算法 , 如 DES 、 3DES 、 RC5 等對文件加密。對稱加密採用了對稱密碼編碼技術，它的特點是文件加密和解密使用相同的密鑰，即加密密鑰也可以用做解密密鑰，這種方法在密碼學中叫做對稱加密算法，
問題 2: 如果***截獲此文件，是否用同一算法就可以解密此文件呢 ?
不可以 , 因爲加密和解密均需要兩個組件 : 加密算法和對稱密鑰 , 加密算法需要用一個對稱密鑰來解密 , ***並不知道此密鑰。
問題 3: 既然***不知密鑰，那麼乙怎樣才能安全地得到其密鑰呢？用電話通知，若電話被竊聽，通過 Internet 發此密鑰給乙，可能被***截獲，怎麼辦 ?
方法是用非對稱密鑰算法加密對稱密鑰後進行傳送。與對稱加密算法不同，非對稱加密算法需要兩個密鑰：公開密鑰（ Public Key ）和私有密鑰（ Private Key ）。公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，只有用對應的公開密鑰才能解密。因爲加密和解密使用的是兩個不同的密鑰，所以這種算法叫做非對稱加密算法 ( 公 / 私鑰可由專門軟件生成 ) 。甲乙雙方各有一對公 / 私鑰，公鑰可在 Internet 上傳送，私鑰自己保存。這樣甲就可以用乙的公鑰加密問題 1 中提到的對稱加密算法中的對稱密鑰。即使***截獲到此密鑰，也會因爲***不知乙的私鑰，而解不開對稱密鑰，因此也解不開密文，只有乙才能解開密文。
問題 4 ：既然甲可以用乙的公鑰加密其對稱密鑰，爲什麼不直接用乙的公鑰加密其文件呢？這樣不僅簡單，而且省去了用對稱加密算法加密文件的步驟？
不可以這麼做。因爲非對稱密碼算法有兩個缺點 : 加密速度慢 , 比對稱加密算法慢 10 ～ 100 倍 , 因此只可用其加密小數據 ( 如對稱密鑰 ) ，另外加密後會導致得到的密文變長。因此一般採用對稱加密算法加密其文件 , 然後用非對稱算法加密對稱算法所用到的對稱密鑰。
問題 5 ： 如果***截獲到密文，同樣也截獲到用公鑰加密的對稱密鑰，由於***無乙的私鑰，因此他解不開對稱密鑰，但如果他用對稱加密算法加密一份假文件 , 並用乙的公鑰加密一份假文件的對稱密鑰，併發給乙，乙會以爲收到的是甲發送的文件，會用其私鑰解密假文件 , 並很高興地閱讀其內容，但卻不知已經被替換。換句話說，乙並不知道這不是甲發給他的，怎麼辦 ?
答案是用數字簽名證明其身份。數字簽名是通過散列算法 , 如 MD5 、 SHA-1 等算法從大塊的數據中提取一個摘要。而從這個摘要中不能通過散列算法恢復出任何一點原文，即得到的摘要不會透露出任何最初明文的信息，但如果原信息受到任何改動，得到的摘要卻肯定會有所不同。因此甲可以對文件進行散列算法得到摘要，並用自己的私鑰加密 ( 因爲非對稱算法可逆，即用私鑰可解開公鑰加密的文件，反之亦然 ) ，這樣即使***截獲也無用。因爲***不會從摘要內獲得任何信息，但乙卻不一樣，他可用甲的公鑰解密，得到其摘要 ( 如果用甲的公鑰能夠解開此摘要，說明此摘要肯定是甲發的，因爲只有甲的公鑰才能解開用甲的私鑰加密的信息 , 而甲的私鑰只有甲自己知道 ) ，並對收到的文件 ( 解密後的合同文件 ) 也進行同樣的散列算法，通過比較其摘要是否一樣 , 就可得知此文件是否被篡改過 ( 因爲若摘要相同，則肯定信息未被改動，這是散列算法的特點 ) 。這樣不僅解決了證明發送人身份的問題，同時還解決了文件是否被篡改問題。
問題 6 ： 通過對稱加密算法加密其文件，再通過非對稱算法加密其對稱密鑰 , 又通過散列算法證明其發送者身份和其信息的正確性，這樣是否就萬無一失了 ?
回答是否定的。問題在於乙並不能肯定他所用的所謂甲的公鑰一定是甲的 , 解決辦法是用數字證書來綁定公鑰和公鑰所屬人。
數字證書是一個經證書授權中心數字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件 , 是網絡通信中標識通信各方身份信息的一系列數據，它提供了一種在 Internet 上驗證身份的方式，其作用類似於司機的駕駛執照或日常生活中的身份證，人們可以在交往中用它來識別對方的身份。
最簡單的證書包含一個公開密鑰、名稱以及證書授權中心的數字簽名。一般情況下證書中還包括密鑰的有效時間、發證機關 ( 證書授權中心 ) 名稱、該證書的序列號等信息。它是由一個權威機構—— CA 機構，又稱爲證書授權 (Certificate Authority) 中心發放的。 CA 機構作爲電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。 CA 中心爲每個使用公開密鑰的用戶發放一個數字證書，數字證書的作用是證明證書中列出的用戶合法擁有證書中列出的公開密鑰。 CA 機構的數字簽名使得***者不能僞造和篡改證書， CA 是 PKI 的核心，負責管理 PKI 結構下的所有用戶（包括各種應用程序）的證書，把用戶的公鑰和用戶的其他信息捆綁在一起，在網上驗證用戶的身份。
因爲數字證書是公開的，就像公開的電話簿一樣，在實踐中，發送者（即甲）會將一份自己的數字證書的拷貝連同密文、摘要等放在一起發送給接收者（即乙），而乙則通過驗證證書上權威機構的簽名來檢查此證書的有效性（只需用那個可信的權威機構的公鑰來驗證該證書上的簽名就可以了），如果證書檢查一切正常，那麼就可以相信包含在該證書中的公鑰的確屬於列在證書中的那個人（即甲）。
問題 7 ： 至此似乎很安全了。但仍存在安全漏洞，例如：甲雖將合同文件發給乙 , 但甲拒不承認在簽名所顯示的那一時刻簽署過此文件 ( 數字簽名就相當於書面合同的文字簽名 ) ，並將此過錯歸咎於電腦，進而不履行合同，怎麼辦 ?
解決辦法是採用可信的時鐘服務 ( 由權威機構提供 ) ，即由可信的時間源和文件的簽名者對文件進行聯合簽名。在書面合同中，文件簽署的日期和簽名一樣均是十分重要的防止文件被僞造和篡改的關鍵性內容 ( 例如合同中一般規定在文件簽署之日起生效 ) 。在電子文件中，由於用戶桌面時間很容易改變 ( 不準確或可人爲改變 ) ，由該時間產生的時間戳不可信賴，因此需要一個第三方來提供時間戳服務（數字時間戳服務（ DTS ）是網上安全服務項目，由專門的機構提供）。此服務能提供電子文件發表時間的安全保護。
時間戳產生的過程爲 : 用戶首先將需要加時間戳的文件用哈希編碼加密形成摘要，然後將該摘要發送到 DTS ， DTS 在加入了收到文件摘要的日期和時間信息後再對該文件加密（數字簽名），然後送回用戶。因此時間戳 (time-stamp) 是一個經加密後形成的憑證文檔，它包括三個部分：需加時間戳的文件的摘要， DTS 收到文件的日期和時間， DTS 的數字簽名。由於可信的時間源和文件的簽名者對文件進行了聯合簽名 , 進而阻止了文檔簽名的那一方 ( 即甲方 ) 在時間上欺詐的可能性 , 因此具有不可否認性。
問題 8: 有了數字證書將公 / 私鑰和身份綁定 , 又有權威機構提供時鐘服務使其具有不可否認性 , 是不是就萬無一失了 ? 不 , 仍然有問題。乙還是不能證明對方就是甲，因爲完全有可能是別人盜用了甲的私鑰 ( 如別人趁甲不在使用甲的電腦 ), 然後以甲的身份來和乙傳送信息 , 這怎麼解決呢 ?
解決辦法是使用強口令、認證令牌、智能卡和生物特徵等技術對使用私鑰的用戶進行認證，以確定其是私鑰的合法使用者。
解決這個問題之前我們先來看看目前實現的基於 PKI 的認證通常是如何工作的。以瀏覽器或者其他登記申請證書的應用程序爲例說明，在第一次生成密鑰的時候會創建一個密鑰存儲，瀏覽器用戶會被提示輸入一個口令，該口令將被用於構造保護該密鑰存儲所需的加密密鑰。如果密鑰存儲只有脆弱的口令保護或根本沒有口令保護，那麼任何一個能夠訪問該電腦瀏覽器的用戶都可以訪問那些私鑰和證書。在這種場景下 , 又怎麼可能信任用 PKI 創建的身份呢 ? 正因爲如此，一個強有力的 PKI 系統必須建立在對私鑰擁有者進行強認證的基礎之上，現在主要的認證技術有：強口令、認證令牌、智能卡和生物特徵（如指紋，眼膜等認證）。
以認證令牌舉例 : 假設用戶的私鑰被保存在後臺服務器的加密容器裏，要訪問私鑰，用戶必須先使用認證令牌認證（如用戶輸入賬戶名、令牌上顯示的通行碼和 PIN 等），如果認證成功，該用戶的加密容器就下載到用戶系統並解密。
通過以上問題的解決，就基本滿足了安全發送文件的需求。下面總結一下這個過程 , 對甲而言整個發送過程如下 :
1. 創建對稱密鑰 ( 相應軟件生成，並且是一次性的 ) ，用其加密合同，並用乙的公鑰打包對稱密鑰。
2. 創建數字簽名，對合同進行散列算法 ( 如 MD5 算法 ) 併產生原始摘要，甲用自己的私鑰加密該摘要 ( 公 / 私鑰既可自己創建也可由 CA 提供 ) 。
3. 最後 , 甲將加密後的合同、打包後的密鑰、加密後的摘要 , 以及甲的數字證書 ( 由權威機構 CA 簽發 ) 一起發給乙。
而乙接收加密文件後，需要完成以下動作 :
1. 接收後，用乙的私鑰解密得到對稱密鑰 , 並用對稱密鑰解開加密的合同 , 得到合同明文。
2. 通過甲的數字證書獲得屬於甲的公鑰 , 並用其解開摘要 ( 稱做摘要 1) 。
3. 對解密後的合同使用和發送者同樣的散列算法來創建摘要 ( 稱做摘要 2) 。
4. 比較摘要 1 和摘要 2, 若相同 , 則表示信息未被篡改 , 且來自於甲。
甲乙傳送信息過程看似並不複雜 , 但實際上它由許多基本成分組成 , 如 : 對稱 / 非對稱密鑰密碼技術、數字證書、數字簽名、證書發放機構（ CA ）、公開密鑰的安全策略等 , 這其中最重要、最複雜的是證書發放機構（ CA ）的構建。
在此強調下證書和簽名：
證書實際對於非對稱加密算法（公鑰加密）來說的，一般證書包括公鑰、姓名、數字簽名三個部分。證書好比身份證，證書機構（ca）就好比是公安局，職責就是負責管理用戶的證書也就是身份證。比如我的公鑰是FrankKey,姓名是Frank
Xu Lei。公安局可以給我登記，但是怎麼保證我和別的Frank
XuLei區別開呢，於是公安局（證書機構）就使用我的名字和密鑰做了個組合，再使用一種哈希算法，得出一串值，來標識我的唯一性，這個值就是我的身份證號碼，也就是證書裏的數字簽名（消息摘要），同時爲了不能讓***仿造數字證書，數字證書的發行者用自己的私鑰對數字簽名進行加密，這樣，使用該數字證書的網絡交易實體就可以用證書發行者的公鑰進行解密驗證。（即：數字簽名的目的是證明自己的身份的確是真實的自己而非其他人，所以需要用自己的私鑰進行加密，讓使用者用公鑰進行解密驗證，從而從技術上杜絕了僞造自己的***。）
假設一個朋友給我寫信，他就可以到公安局（證書機構）來查找我的身份證（證書）。上面包括我的個人信息，可以保證這個公鑰就是我的。然後他把新建進行加密，郵寄給我。別人即使拆開我的信件，因爲沒有密鑰進行解密，所以無法閱讀我的信件內容。這樣就保證了信息安全。
所以說加密不一定要證書，取決於你數據安全具體的需求。一般大型的電子商務網站都有自己特定的證書。證書管理的機構比較有名的就是VeriSign（可以
說是互聯網上的身份證管理局）。企業可以申請註冊，它會給申請者生成特定的簽名。我們自己的企業內部應用如果需要的話，可以在企業局域網內部建立企業私有的證書服務器，來產生和管理證書。其實X.509是由國際電信聯盟（ITU-T）制定的一種定義證書格式和分佈的國際標準(相當於製作身份證的規範)。爲了提供公用網絡用戶目錄信息服務，並規定了實體鑑別過程中廣泛適用的證書語法和數據接口，
X.509
稱之爲證書，或者說是身份證的一種形式，類似與我們現在的二代身份證，也是身份證的一種，根據特定的標準製作出來的。另外證書使用的時候還有有效期的限制，和我們的身份證的10年有效期一樣。證書也可以設置有效期。
附：U盾的工作原理介紹
一、什麼是U盾
U盾，即工行2003年推出並獲得國家專利的客戶證書USBkey，是工行爲您提供的辦理網上銀行業務的高級別安全工具。它外形酷似U盤，像一面盾牌，時刻保護着您的網上銀行資金安全。
從技術角度看，U盾是用於網上銀行電子簽名和數字認證的工具，它內置微型智能卡處理器，採用1024位非對稱密鑰算法對網上數據進行加密、解密和數字簽名，確保網上交易的保密性、真實性、完整性和不可否認性
二、工作原理
U盾又作移動數字證書，它存放着你個人的數字證書，並不可讀取。同樣，銀行也記錄着你的數字證書。
當你嘗試進行網上交易時，銀行會向你發送由時間字串，地址字串，交易信息字串，防重放***字串組合在一起進行加密後得到的字串A，你的U盾將跟據你的個人證書對字串A進行不可逆運算得到字串B，並將字串B發送給銀行，銀行端也同時進行該不可逆運算，如果銀行運算結果和你的運算結果一致便認爲你合法，交易便可以完成，如果不一致便認爲你不合法，交易便會失敗。(理論上，不同的字串A不會得出相同的字串B，即一個字串A對應一個唯一的字串B;但是字串B和字串A無法得出你的數字證書，而且U盾具有不可讀取性，所以任何人都無法獲行你的數字證書。並且銀行每次都會發不同的防重放字串(隨機字串)和時間字串，所以當一次交易完成後，剛發出的B字串便不再有效。綜上所述，理論上U盾是絕對安全的****注意是理論上發生僞造概率大約爲2的80次方分之一，但是如果有像變形金剛中的那種DNAbasecomputer的話。