通用對稱加密

Ⅰ 開發中常見的加密方式及應用

開發中常見的加密方式及應用

一、base64

簡述：Base64是網路上最常見的用於傳輸8Bit 位元組碼 的編碼方式之一，Base64就是一種基於64個可列印字元來表示二進制數據的方法。所有的數據都能被編碼為並只用65個字元就能表示的文本文件。( 65字元：A~Z a~z 0~9 + / = )編碼後的數據~=編碼前數據的4/3，會大1/3左右（圖片轉化為base64格式會比原圖大一些）。

應用：Base64編碼是從二進制到字元的過程，可用於在 HTTP 環境下傳遞較長的標識信息。例如，在java Persistence系統Hibernate中，就採用了Base64來將一個較長的唯一 標識符 （一般為128-bit的UUID）編碼為一個字元串，用作HTTP 表單 和HTTP GET URL中的參數。在其他應用程序中，也常常需要把二進制 數據編碼 為適合放在URL（包括隱藏 表單域 ）中的形式。此時，採用Base64編碼具有不可讀性，需要解碼後才能閱讀。

命令行進行Base64編碼和解碼

編碼：base64 123.png -o 123.txt

解碼：base64 123.txt -o test.png -D Base64編碼的原理

原理：

1)將所有字元轉化為ASCII碼;

2)將ASCII碼轉化為8位二進制;

3)將二進制3個歸成一組(不足3個在後邊補0)共24位，再拆分成4組，每組6位;

4)統一在6位二進制前補兩個0湊足8位;

5)將補0後的二進制轉為十進制;

6)從Base64編碼表獲取十進制對應的Base64編碼;

Base64編碼的說明：

a.轉換的時候，將三個byte的數據，先後放入一個24bit的緩沖區中，先來的byte占高位。

b.數據不足3byte的話，於緩沖區中剩下的bit用0補足。然後，每次取出6個bit，按照其值選擇查表選擇對應的字元作為編碼後的輸出。

c.不斷進行，直到全部輸入數據轉換完成。

d.如果最後剩下兩個輸入數據，在編碼結果後加1個「=」;

e.如果最後剩下一個輸入數據，編碼結果後加2個「=」;

f.如果沒有剩下任何數據，就什麼都不要加，這樣才可以保證資料還原的正確性。

二、HASH加密/單向散列函數

簡述：Hash演算法特別的地方在於它是一種單向演算法，用戶可以通過Hash演算法對目標信息生成一段特定長度（32個字元）的唯一的Hash值，卻不能通過這個Hash值重新獲得目標信息。對用相同數據，加密之後的密文相同。 常見的Hash演算法有MD5和SHA。由於加密結果固定，所以基本上原始的哈希加密已經不再安全，於是衍生出了加鹽的方式。加鹽：先對原始數據拼接固定的字元串再進行MD5加密。

特點：

1) 加密 後密文的長度是定長(32個字元的密文)的

2)如果明文不一樣，那麼散列後的結果一定不一樣

3)如果明文一樣，那麼加密後的密文一定一樣(對相同數據加密，加密後的密文一樣)

4)所有的加密演算法是公開的

5)不可以逆推反算(不能根據密文推算出明文)，但是可以暴力 破解 ，碰撞監測

原理：MD5消息摘要演算法，屬Hash演算法一類。MD5演算法對輸入任意長度的消息進行運行，產生一個128位的消息摘要。

1)數據填充

對消息進行數據填充，使消息的長度對512取模得448，設消息長度為X，即滿足X mod 512=448。根據此公式得出需要填充的數據長度。

填充方法：在消息後面進行填充，填充第一位為1，其餘為0。

2)添加信息長度

在第一步結果之後再填充上原消息的長度，可用來進行的存儲長度為64位。如果消息長度大於264，則只使用其低64位的值，即（消息長度 對264取模）。

在此步驟進行完畢後，最終消息長度就是512的整數倍。

3)數據處理

准備需要用到的數據：

4個常數：A = 0x67452301, B = 0x0EFCDAB89, C = 0x98BADCFE, D = 0x10325476;

4個函數：F(X,Y,Z)=(X & Y) | ((~X) & Z);G(X,Y,Z)=(X & Z) | (Y & (~Z));H(X,Y,Z)=X ^ Y ^ Z;I(X,Y,Z)=Y ^ (X | (~Z));

把消息分以512位為一分組進行處理，每一個分組進行4輪變換，以上面所說4個常數為起始變數進行計算，重新輸出4個變數，以這4個變數再進行下一分組的運算，如果已經是最後一個分組，則這4個變數為最後的結果，即MD5值。

三、對稱加密

經典演算法：

1)DES數據加密標准

DES演算法的入口參數有三個：Key、Data、Mode。其中Key為8個位元組共64位，是DES演算法的工作密鑰；Data也為8個位元組64位，是要被加密或被解密的數據；Mode為DES的工作方式，有兩種：加密或解密。

DES演算法是這樣工作的：如Mode為加密，則用Key去把數據Data進行加密， 生成Data的密碼形式（64位）作為DES的輸出結果；如Mode為解密，則用Key去把密碼形式的數據Data解密，還原為Data的明碼形式（64位）作為DES的輸出結果。在通信網路的兩端，雙方約定一致的Key，在通信的源點用Key對核心數據進行DES加密，然後以密碼形式在公共通信網（如電話網）中傳輸到通信網路的終點，數據到達目的地後，用同樣的Key對密碼數據進行解密，便再現了明碼形式的核心數據。這樣，便保證了核心數據（如PIN、MAC等）在公共通信網中傳輸的安全性和可靠性。

2)3DES使用3個密鑰，對消息進行(密鑰1·加密)+(密鑰2·解密)+(密鑰3·加密)

3)AES高級加密標准

如圖，加密/解密使用相同的密碼，並且是可逆的

四、非對稱加密

特點：

1)使用公鑰加密，使用私鑰解密

2)公鑰是公開的，私鑰保密

3)加密處理安全，但是性能極差

經典演算法RSA:

1)RSA原理

(1)求N，准備兩個質數p和q,N = p x q

(2)求L,L是p-1和q-1的最小公倍數。L = lcm(p-1,q-1)

(3)求E，E和L的最大公約數為1(E和L互質)

(4)求D，E x D mode L = 1

五、數字簽名

原理以及應用場景:

1)數字簽名的應用場景

需要嚴格驗證發送方身份信息情況

2)數字簽名原理

(1)客戶端處理

對"消息"進行HASH得到"消息摘要"

發送方使用自己的私鑰對"消息摘要"加密(數字簽名)

把數字簽名附著在"報文"的末尾一起發送給接收方

(2)服務端處理

對"消息" HASH得到"報文摘要"

使用公鑰對"數字簽名"解密

對結果進行匹配

六、數字證書

簡單說明:

證書和駕照很相似，裡面記有姓名、組織、地址等個人信息，以及屬於此人的公鑰，並有認證機構施加數字簽名,只要看到公鑰證書，我們就可以知道認證機構認證該公鑰的確屬於此人。

數字證書的內容：

1)公鑰

2)認證機構的數字簽名

證書的生成步驟：

1)生成私鑰openssl genrsa -out private.pem 1024

2)創建證書請求openssl req -new -key private.pem -out rsacert.csr

3)生成證書並簽名，有效期10年openssl x509 -req -days 3650 -in rsacert.csr -signkey private.pem -out rsacert.crt

4)將PEM格式文件轉換成DER格式openssl x509 -outform der -in rsacert.crt -out rsacert.der

5)導出P12文件openssl pkcs12 -export -out p.p12 -inkey private.pem -in rsacert.crt

iOS開發中的注意點：

1)在iOS開發中，不能直接使用PEM格式的證書，因為其內部進行了Base64編碼，應該使用的是DER的證書，是二進制格式的；

2)OpenSSL默認生成的都是PEM格式的證書。

七、https

HTTPS和HTTP的區別：

超文本傳輸協議HTTP協議被用於在Web瀏覽器和網站伺服器之間傳遞信息。HTTP協議以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了Web瀏覽器和網站伺服器之間的傳輸報文，就可以直接讀懂其中的信息，因此HTTP協議不適合傳輸一些敏感信息，比如信用卡號、密碼等。

為了解決HTTP協議的這一缺陷，需要使用另一種協議：安全套接字層超文本傳輸協議HTTPS。為了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證伺服器的身份，並為瀏覽器和伺服器之間的通信加密。

HTTPS和HTTP的區別主要為以下四點：

1)https協議需要到ca申請證書，一般免費證書很少，需要交費。

2)http是 超文本傳輸協議 ，信息是明文傳輸，https則是具有 安全性 的 ssl 加密傳輸協議。

3)http和https使用的是完全不同的連接方式，用的埠也不一樣，前者是80，後者是443。

4)http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的 網路協議 ，比http協議安全。

5)SSL：Secure Sockets Layer安全套接字層;用數據加密(Encryption)技術，可確保數據在網路上傳輸過程中不會被截取及竊聽。目前一般通用之規格為40 bit之安全標准，美國則已推出128 bit之更高安全標准，但限制出境。只要3.0版本以上之I.E.或Netscape 瀏覽器 即可支持SSL。目前版本為3.0。SSL協議位於TCP/IP協議與各種應用層協議之間，為數據通訊提供安全支持。SSL協議可分為兩層：SSL記錄協議(SSL Record Protocol)：它建立在可靠的傳輸協議(如TCP)之上，為高層協議提供數據封裝、壓縮、加密等基本功能的支持。SSL握手協議(SSL Handshake Protocol)：它建立在SSL記錄協議之上，用於在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密密鑰等。

Ⅱ 詳解https是如何確保系統安全的

• https協議需要到CA申請證書。

• http是超文本傳輸協議，信息是明文傳輸；https 則是具有安全性的ssl加密傳輸協議。

• http和https使用的是完全不同的連接方式，用的埠也不一樣，前者是80，後者是443。

• http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。

http默認使用80埠，https默認使用443埠

下面就是https的整個架構，現在的https基本都使用TLS了，因為更加安全，所以下圖中的SSL應該換為SSL/TLS。

客戶端首次發出請求

由於客戶端(如瀏覽器)對一些加解密演算法的支持程度不一樣，但是在TLS協議傳輸過程中必須使用同一套加解密演算法才能保證數據能夠正常的加解密。在TLS握手階段，客戶端首先要告知服務端，自己支持哪些加密演算法，所以客戶端需要將本地支持的加密套件(Cipher Suite)的列表傳送給服務端。除此之外，客戶端還要產生一個隨機數，這個隨機數一方面需要在客戶端保存，另一方面需要傳送給服務端，客戶端的隨機數需要跟服務端產生的隨機數結合起來產生後面要講到的 Master Secret 。

客戶端需要提供如下信息：

• 支持的協議版本，比如TLS 1.0版

• 一個客戶端生成的隨機數，稍後用於生成」對話密鑰」

• 支持的加密方法，比如RSA公鑰加密

• 支持的壓縮方法

服務端首次回應

服務端在接收到客戶端的Client Hello之後，服務端需要確定加密協議的版本，以及加密的演算法，然後也生成一個隨機數，以及將自己的證書發送給客戶端一並發送給客戶端，這里的隨機數是整個過程的第二個隨機數。

服務端需要提供的信息：

• 協議的版本

• 加密的演算法

• 隨機數

• 伺服器證書

客戶端再次回應

客戶端首先會對伺服器下發的證書進行驗證，驗證通過之後，則會繼續下面的操作，客戶端再次產生一個隨機數（第三個隨機數），然後使用伺服器證書中的公鑰進行加密，以及放一個ChangeCipherSpec消息即編碼改變的消息，還有整個前面所有消息的hash值，進行伺服器驗證，然後用新秘鑰加密一段數據一並發送到伺服器，確保正式通信前無誤。
客戶端使用前面的兩個隨機數以及剛剛新生成的新隨機數，使用與伺服器確定的加密演算法，生成一個Session Secret。

ChangeCipherSpec
ChangeCipherSpec是一個獨立的協議，體現在數據包中就是一個位元組的數據，用於告知服務端，客戶端已經切換到之前協商好的加密套件（Cipher Suite）的狀態，准備使用之前協商好的加密套件加密數據並傳輸了。

伺服器再次響應

服務端在接收到客戶端傳過來的第三個隨機數的 加密數據之後，使用私鑰對這段加密數據進行解密，並對數據進行驗證，也會使用跟客戶端同樣的方式生成秘鑰，一切准備好之後，也會給客戶端發送一個 ChangeCipherSpec，告知客戶端已經切換到協商過的加密套件狀態，准備使用加密套件和 Session Secret加密數據了。之後，服務端也會使用 Session Secret 加密一段 Finish 消息發送給客戶端，以驗證之前通過握手建立起來的加解密通道是否成功。

後續客戶端與伺服器間通信

確定秘鑰之後，伺服器與客戶端之間就會通過商定的秘鑰加密消息了，進行通訊了。整個握手過程也就基本完成了。

值得特別提出的是：
SSL協議在握手階段使用的是非對稱加密，在傳輸階段使用的是對稱加密，也就是說在SSL上傳送的數據是使用對稱密鑰加密的！因為非對稱加密的速度緩慢，耗費資源。其實當客戶端和主機使用非對稱加密方式建立連接後，客戶端和主機已經決定好了在傳輸過程使用的對稱加密演算法和關鍵的對稱加密密鑰，由於這個過程本身是安全可靠的，也即對稱加密密鑰是不可能被竊取盜用的，因此，保證了在傳輸過程中對數據進行對稱加密也是安全可靠的，因為除了客戶端和主機之外，不可能有第三方竊取並解密出對稱加密密鑰！如果有人竊聽通信，他可以知道雙方選擇的加密方法，以及三個隨機數中的兩個。整個通話的安全，只取決於第三個隨機數（Premaster secret）能不能被破解。

其他補充

對於非常重要的保密數據，服務端還需要對客戶端進行驗證，以保證數據傳送給了安全的合法的客戶端。服務端可以向客戶端發出 Cerficate Request 消息，要求客戶端發送證書對客戶端的合法性進行驗證。比如，金融機構往往只允許認證客戶連入自己的網路，就會向正式客戶提供USB密鑰，裡面就包含了一張客戶端證書。

PreMaster secret前兩個位元組是TLS的版本號，這是一個比較重要的用來核對握手數據的版本號，因為在Client Hello階段，客戶端會發送一份加密套件列表和當前支持的SSL/TLS的版本號給服務端，而且是使用明文傳送的，如果握手的數據包被破解之後，攻擊者很有可能串改數據包，選擇一個安全性較低的加密套件和版本給服務端，從而對數據進行破解。所以，服務端需要對密文中解密出來對的PreMaster版本號跟之前Client Hello階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止發送任何消息。

session的恢復

有兩種方法可以恢復原來的session：一種叫做session ID，另一種叫做session ticket。

session ID

session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且伺服器有這個編號的記錄，雙方就可以重新使用已有的」對話密鑰」，而不必重新生成一把。

session ID是目前所有瀏覽器都支持的方法，但是它的缺點在於session ID往往只保留在一台伺服器上。所以，如果客戶端的請求發到另一台伺服器，就無法恢復對話

session ticket

客戶端發送一個伺服器在上一次對話中發送過來的session ticket。這個session ticket是加密的，只有伺服器才能解密，其中包括本次對話的主要信息，比如對話密鑰和加密方法。當伺服器收到session ticket以後，解密後就不必重新生成對話密鑰了。

目前只有Firefox和Chrome瀏覽器支持。

總結

https實際就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書，等技術進行客戶端與伺服器的數據加密傳輸，最終達到保證整個通信的安全性。

Ⅲ JAVA和.NET使用DES對稱加密的區別

如果我說沒有區別你會信嗎？
但答案還真是這樣，兩者沒有任何區別的，只不過實現的語言代碼不同而已。
那麼java與dot net之間的DES是否可以通用？答案也是完全通用。無論是Java的DES加密還是dot net的DES回密，均可以使用另一種語言且不限於Java或dot net解密。夠明白嗎？
DES其實只是一個演算法，加密與解密我們都知道演算法與密碼是分離的。演算法是公開的，都可以用，而密碼是獨立於演算法的。所以DES在不同的語言中實現的演算法根本就是一樣的——也正是因為如此不管何種語言都是通用的（除非偽DES，要知道DES演算法網上本身能搜到而且是一個標准，最先是由美國安全部門公開的）
再說一下，為什麼有人「通」用不起來的原因。DES其實有CBC之類的參數的，也就是針對加密塊選用的不同的加密手段。正是這個參數的原因，不同的語言中使用不同的參數做為默認值，所以使用默認的方式進行讓兩個串進行加解密肯定是不同的。DES使用一種模式（方法）加密，用另一種模式(方法）進行解密能得到正確的結果嗎？一些人不怪自己的學藝不精，反說是兩種語言的DES不通用（這也就是為什麼網路上會出現諸多說java和dot net的DES加密方法不通用的原因）。
即便是自己使用的DES加密的代碼也是通用的（前提你要遵守DES分開演算法），但不要「重復實現已經實現的東西（專業術語叫造輪子）」。
附：
DES.Model屬性取值
CBC 密碼塊鏈 (CBC) 模式引入了反饋。每個純文本塊在加密前，通過按位「異或」操作與前一個塊的密碼文本結合。這樣確保了即使純文本包含許多相同的塊，這些塊中的每一個也會加密為不同的密碼文本塊。在加密塊之前，初始化向量通過按位「異或」操作與第一個純文本塊結合。如果密碼文本塊中有一個位出錯，相應的純文本塊也將出錯。此外，後面的塊中與原出錯位的位置相同的位也將出錯。
ECB 電子密碼本 (ECB) 模式分別加密每個塊。這意味著任何純文本塊只要相同並且在同一消息中，或者在用相同的密鑰加密的不同消息中，都將被轉換成同樣的密碼文本塊。如果要加密的純文本包含大量重復的塊，則逐塊破解密碼文本是可行的。另外，隨時准備攻擊的對手可能在您沒有察覺的情況下替代和交換個別的塊。如果密碼文本塊中有一個位出錯，相應的整個純文本塊也將出錯。
OFB 輸出反饋 (OFB) 模式將少量遞增的純文本處理成密碼文本，而不是一次處理整個塊。此模式與 CFB 相似；這兩種模式的唯一差別是移位寄存器的填充方式不同。如果密碼文本中有一個位出錯，純文本中相應的位也將出錯。但是，如果密碼文本中有多餘或者缺少的位，則那個位之後的純文本都將出錯。
CFB 密碼反饋 (CFB) 模式將少量遞增的純文本處理成密碼文本，而不是一次處理整個塊。該模式使用在長度上為一個塊且被分為幾部分的移位寄存器。例如，如果塊大小為 8 個位元組，並且每次處理一個位元組，則移位寄存器被分為 8 個部分。如果密碼文本中有一個位出錯，則一個純文本位出錯，並且移位寄存器損壞。這將導致接下來若干次遞增的純文本出錯，直到出錯位從移位寄存器中移出為止。
CTS 密碼文本竊用 (CTS) 模式處理任何長度的純文本並產生長度與純文本長度匹配的密碼文本。除了最後兩個純文本塊外，對於所有其他塊，此模式與 CBC 模式的行為相同。

DES.Padding屬性的取值
None 不填充。
PKCS7 PKCS #7 填充字元串由一個位元組序列組成，每個位元組填充該位元組序列的長度。
Zeros 填充字元串由設置為零的位元組組成。
ANSIX923 ANSIX923 填充字元串由一個位元組序列組成，此位元組序列的最後一個位元組填充位元組序列的長度，其餘位元組均填充數字零。
ISO10126 ISO10126 填充字元串由一個位元組序列組成，此位元組序列的最後一個位元組填充位元組序列的長度，其餘位元組填充隨機數據。

當Mode不同時，解密的內密內容能與相同嗎？PaddingMode不同時，解密的內容的結尾部分能相同嗎（填充結果只涉及到最後的一個塊）.所以當不管何種語言使用相同的Mode及PaddingMode時，加解密的結果是相同的（當然不排除部分語言不實現全部的Mode和PaddingMode)但，基本的都是實現了的，所以基本上任何兩種語言之間的DES都可以實現相同的加解密結果！而java和dot net中的DES顯然指的是演算法，兩者是相同的，可以隨意使用（Java中dot net中的Mode默認值是不同的，一定要設置相同的Mode和PaddingMode才可以的，不要雙方都採用默認值，那樣真的通不起來）

Ⅳ 對稱加密，和不可逆演算法是什麼

加密演算法

加密技術是對信息進行編碼和解碼的技術，編碼是把原來可讀信息（又稱明文）譯成代碼形式（又稱密文），其逆過程就是解碼（解密）。加密技術的要點是加密演算法，加密演算法可以分為對稱加密、不對稱加密和不可逆加密三類演算法。

對稱加密演算法 對稱加密演算法是應用較早的加密演算法，技術成熟。在對稱加密演算法中，數據發信方將明文（原始數據）和加密密鑰一起經過特殊加密演算法處理後，使其變成復雜的加密密文發送出去。收信方收到密文後，若想解讀原文，則需要使用加密用過的密鑰及相同演算法的逆演算法對密文進行解密，才能使其恢復成可讀明文。在對稱加密演算法中，使用的密鑰只有一個，發收信雙方都使用這個密鑰對數據進行加密和解密，這就要求解密方事先必須知道加密密鑰。對稱加密演算法的特點是演算法公開、計算量小、加密速度快、加密效率高。不足之處是，交易雙方都使用同樣鑰匙，安全性得不到保證。此外，每對用戶每次使用對稱加密演算法時，都需要使用其他人不知道的惟一鑰匙，這會使得發收信雙方所擁有的鑰匙數量成幾何級數增長，密鑰管理成為用戶的負擔。對稱加密演算法在分布式網路系統上使用較為困難，主要是因為密鑰管理困難，使用成本較高。在計算機專網系統中廣泛使用的對稱加密演算法有DES和IDEA等。美國國家標准局倡導的AES即將作為新標准取代DES。

不對稱加密演算法不對稱加密演算法使用兩把完全不同但又是完全匹配的一對鑰匙—公鑰和私鑰。在使用不對稱加密演算法加密文件時，只有使用匹配的一對公鑰和私鑰，才能完成對明文的加密和解密過程。加密明文時採用公鑰加密，解密密文時使用私鑰才能完成，而且發信方（加密者）知道收信方的公鑰，只有收信方（解密者）才是唯一知道自己私鑰的人。不對稱加密演算法的基本原理是，如果發信方想發送只有收信方才能解讀的加密信息，發信方必須首先知道收信方的公鑰，然後利用收信方的公鑰來加密原文；收信方收到加密密文後，使用自己的私鑰才能解密密文。顯然，採用不對稱加密演算法，收發信雙方在通信之前，收信方必須將自己早已隨機生成的公鑰送給發信方，而自己保留私鑰。由於不對稱演算法擁有兩個密鑰，因而特別適用於分布式系統中的數據加密。廣泛應用的不對稱加密演算法有RSA演算法和美國國家標准局提出的DSA。以不對稱加密演算法為基礎的加密技術應用非常廣泛。

不可逆加密演算法 不可逆加密演算法的特徵是加密過程中不需要使用密鑰，輸入明文後由系統直接經過加密演算法處理成密文，這種加密後的數據是無法被解密的，只有重新輸入明文，並再次經過同樣不可逆的加密演算法處理，得到相同的加密密文並被系統重新識別後，才能真正解密。顯然，在這類加密過程中，加密是自己，解密還得是自己，而所謂解密，實際上就是重新加一次密，所應用的「密碼」也就是輸入的明文。不可逆加密演算法不存在密鑰保管和分發問題，非常適合在分布式網路系統上使用，但因加密計算復雜，工作量相當繁重，通常只在數據量有限的情形下使用，如廣泛應用在計算機系統中的口令加密，利用的就是不可逆加密演算法。近年來，隨著計算機系統性能的不斷提高，不可逆加密的應用領域正在逐漸增大。在計算機網路中應用較多不可逆加密演算法的有RSA公司發明的MD5演算法和由美國國家標准局建議的不可逆加密標准SHS(Secure Hash Standard:安全雜亂信息標准)等。

加密技術

加密演算法是加密技術的基礎，任何一種成熟的加密技術都是建立多種加密演算法組合，或者加密演算法和其他應用軟體有機結合的基礎之上的。下面我們介紹幾種在計算機網路應用領域廣泛應用的加密技術。

非否認（Non-repudiation）技術 該技術的核心是不對稱加密演算法的公鑰技術，通過產生一個與用戶認證數據有關的數字簽名來完成。當用戶執行某一交易時，這種簽名能夠保證用戶今後無法否認該交易發生的事實。由於非否認技術的操作過程簡單，而且直接包含在用戶的某類正常的電子交易中，因而成為當前用戶進行電子商務、取得商務信任的重要保證。

PGP（Pretty Good Privacy）技術 PGP技術是一個基於不對稱加密演算法RSA公鑰體系的郵件加密技術，也是一種操作簡單、使用方便、普及程度較高的加密軟體。PGP技術不但可以對電子郵件加密，防止非授權者閱讀信件；還能對電子郵件附加數字簽名，使收信人能明確了解發信人的真實身份；也可以在不需要通過任何保密渠道傳遞密鑰的情況下，使人們安全地進行保密通信。PGP技術創造性地把RSA不對稱加密演算法的方便性和傳統加密體系結合起來，在數字簽名和密鑰認證管理機制方面採用了無縫結合的巧妙設計，使其幾乎成為最為流行的公鑰加密軟體包。

數字簽名（Digital Signature）技術 數字簽名技術是不對稱加密演算法的典型應用。數字簽名的應用過程是，數據源發送方使用自己的私鑰對數據校驗和或其他與數據內容有關的變數進行加密處理，完成對數據的合法「簽名」，數據接收方則利用對方的公鑰來解讀收到的「數字簽名」，並將解讀結果用於對數據完整性的檢驗，以確認簽名的合法性。數字簽名技術是在網路系統虛擬環境中確認身份的重要技術，完全可以代替現實過程中的「親筆簽字」，在技術和法律上有保證。在公鑰與私鑰管理方面，數字簽名應用與加密郵件PGP技術正好相反。在數字簽名應用中，發送者的公鑰可以很方便地得到，但他的私鑰則需要嚴格保密。

PKI（Public Key Infrastructure）技術 PKI技術是一種以不對稱加密技術為核心、可以為網路提供安全服務的公鑰基礎設施。PKI技術最初主要應用在Internet環境中，為復雜的互聯網系統提供統一的身份認證、數據加密和完整性保障機制。由於PKI技術在網路安全領域所表現出的巨大優勢，因而受到銀行、證券、政府等核心應用系統的青睞。PKI技術既是信息安全技術的核心，也是電子商務的關鍵和基礎技術。由於通過網路進行的電子商務、電子政務等活動缺少物理接觸，因而使得利用電子方式驗證信任關系變得至關重要，PKI技術恰好能夠有效解決電子商務應用中的機密性、真實性、完整性、不可否認性和存取控制等安全問題。一個實用的PKI體系還必須充分考慮互操作性和可擴展性。PKI體系所包含的認證中心（CA）、注冊中心（RA）、策略管理、密鑰與證書管理、密鑰備份與恢復、撤銷系統等功能模塊應該有機地結合在一起。

加密的未來趨勢

盡管雙鑰密碼體制比單鑰密碼體制更為可靠，但由於計算過於復雜，雙鑰密碼體制在進行大信息量通信時，加密速率僅為單鑰體制的1/100，甚至是 1/1000。正是由於不同體制的加密演算法各有所長，所以在今後相當長的一段時期內，各類加密體制將會共同發展。而在由IBM等公司於1996年聯合推出的用於電子商務的協議標准SET（Secure Electronic Transaction）中和1992年由多國聯合開發的PGP技術中，均採用了包含單鑰密碼、雙鑰密碼、單向雜湊演算法和隨機數生成演算法在內的混合密碼系統的動向來看，這似乎從一個側面展示了今後密碼技術應用的未來。

在單鑰密碼領域，一次一密被認為是最為可靠的機制，但是由於流密碼體制中的密鑰流生成器在演算法上未能突破有限循環，故一直未被廣泛應用。如果找到一個在演算法上接近無限循環的密鑰流生成器，該體制將會有一個質的飛躍。近年來，混沌學理論的研究給在這一方向產生突破帶來了曙光。此外，充滿生氣的量子密碼被認為是一個潛在的發展方向，因為它是基於光學和量子力學理論的。該理論對於在光纖通信中加強信息安全、對付擁有量子計算能力的破譯無疑是一種理想的解決方法。

由於電子商務等民用系統的應用需求，認證加密演算法也將有較大發展。此外，在傳統密碼體制中，還將會產生類似於IDEA這樣的新成員，新成員的一個主要特徵就是在演算法上有創新和突破，而不僅僅是對傳統演算法進行修正或改進。密碼學是一個正在不斷發展的年輕學科，任何未被認識的加/解密機制都有可能在其中佔有一席之地。

目前，對信息系統或電子郵件的安全問題，還沒有一個非常有效的解決方案，其主要原因是由於互聯網固有的異構性，沒有一個單一的信任機構可以滿足互聯網全程異構性的所有需要，也沒有一個單一的協議能夠適用於互聯網全程異構性的所有情況。解決的辦法只有依靠軟體代理了，即採用軟體代理來自動管理用戶所持有的證書（即用戶所屬的信任結構）以及用戶所有的行為。每當用戶要發送一則消息或一封電子郵件時，代理就會自動與對方的代理協商，找出一個共同信任的機構或一個通用協議來進行通信。在互聯網環境中，下一代的安全信息系統會自動為用戶發送加密郵件，同樣當用戶要向某人發送電子郵件時，用戶的本地代理首先將與對方的代理交互，協商一個適合雙方的認證機構。當然，電子郵件也需要不同的技術支持，因為電子郵件不是端到端的通信，而是通過多個中間機構把電子郵件分程傳遞到各自的通信機器上，最後到達目的地

Ⅳ 對稱加密演算法的缺點有哪些

1、對稱加密演算法
優點
加解密的高速度和使用長密鑰時的難破解性。
缺點
對稱加密演算法的安全性取決於加密密鑰的保存情況，但要求企業中每一個持有密鑰的人都保守秘密是不可能的，他們通常會有意無意的把密鑰泄漏出去。如果一個用戶使用的密鑰被入侵者所獲得，入侵者便可以讀取該用戶密鑰加密的所有文檔，如果整個企業共用一個加密密鑰，那整個企業文檔的保密性便無從談起。
2、非對稱加密演算法
優點
非對稱密鑰體制有兩種密鑰，其中一個是公開的，這樣就可以不需要像對稱密碼那樣傳輸對方的密鑰了。這樣安全性就大了很多。
缺點
演算法強度復雜、安全性依賴於演算法與密鑰但是由於其演算法復雜，而使得加密解密速度沒有對稱加密解密的速度快。
3、傳統密碼體制
優點
由於DES加密速度快，適合加密較長的報文。
缺點
通用密鑰密碼體制的加密密鑰和解密密鑰是通用的，即發送方和接收方使用同樣密鑰的密碼體制。
4、公鑰密碼體制
優點
RSA演算法的加密密鑰和加密演算法分開，使得密鑰分配更為方便。
RSA演算法解決了大量網路用戶密鑰管理的難題。

缺點
RSA的密鑰很長，加密速度慢。

Ⅵ 電腦怎樣通過互聯網傳輸數據

網路中數據傳輸過程

我們每天都在使用互聯網，我們電腦上的數據是怎麼樣通過互聯網傳輸到到另外的一台電腦上的呢？

我們知道現在的互聯網中使用的TCP/IP協議是基於，OSI（開放系統互聯）的七層參考模型的，（雖然不是完全符合）從上到下分別為 應用層 表示層 會話層 傳輸層 網路層 數據鏈路層和物理層。其中數據鏈路層又可是分為兩個子層分別為邏輯鏈路控制層（Logic Link Control，LLC ）和介質訪問控制層（(Media Access Control，MAC )也就是平常說的MAC層。LLC對兩個節點中的鏈路進行初始化，防止連接中斷，保持可靠的通信。MAC層用來檢驗包含在每個楨中的地址信息。在下面會分析到。還要明白一點路由器是在網路層的，而網卡在數據鏈路層。

我們知道，ARP（Address Resolution Protocol，地址轉換協議）被當作底層協議，用於IP地址到物理地址的轉換。在乙太網中，所有對IP的訪問最終都轉化為對網卡MAC地址的訪問。如果主機A的ARP列表中，到主機B的IP地址與MAC地址對應不正確，由A發往B數據包就會發向錯誤的MAC地址，當然無法順利到達B，結 果是A與B根本不能進行通信。

首先我們分析一下在同一個網段的情況。假設有兩台電腦分別命名為A和B，A需要相B發送數據的話，A主機首先把目標設備B的IP地址與自己的子網掩碼進行「與」操作，以判斷目標設備與自己是否位於同一網段內。如果目標設備在同一網段內，並且A沒有獲得與目標設備B的IP地址相對應的MAC地址信息，則源設備（A）以第二層廣播的形式(目標MAC地址為全1)發送ARP請求報文，在ARP請求報文中包含了源設備（A）與目標設備（B）的IP地址。同一網段中的所有其他設備都可以收到並分析這個ARP請求報文，如果某設備發現報文中的目標IP地址與自己的IP地址相同，則它向源設備發回ARP響應報文，通過該報文使源設備獲得目標設備的MAC地址信息。為了減少廣播量，網路設備通過ARP表在緩存中保存IP與MAC地址的映射信息。在一次 ARP的請求與響應過程中，通信雙方都把對方的MAC地址與IP地址的對應關系保存在各自的ARP表中，以在後續的通信中使用。ARP表使用老化機制，刪除在一段時間內沒有使用過的IP與MAC地址的映射關系。一個最基本的網路拓撲結構：

PC-A並不需要獲取遠程主機（PC-C）的MAC地址，而是把IP分組發向預設網關，由網關IP分組的完成轉發過程。如果源主機（PC-A）沒有預設網關MAC地址的緩存記錄，則它會通過ARP協議獲取網關的MAC地址，因此在A的ARP表中只觀察到網關的MAC地址記錄，而觀察不到遠程主機的 MAC地址。在乙太網(Ethernet)中，一個網路設備要和另一個網路設備進行直接通信，

除了知道目標設備的網路層邏輯地址(如IP地址)外，還要知道目標設備的第二層物理地址(MAC地址)。ARP協議的基本功能就是通過目標設備的IP地址，查詢目標設備的MAC地址，以保證通信的順利進行。 數據包在網路中的發送是一個及其復雜的過程，上圖只是一種很簡單的情況，中間沒有過多的中間節點，其實現實中只會比這個更復雜，但是大致的原理是一致的。

（1）PC-A要發送數據包到PC-C的話，如果PC-A沒有PC-C的IP地址，則PC-A首先要發出一個dns的請求，路由器A或者dns解析伺服器會給PC-A回應PC-C的ip地址，這樣PC-A關於數據包第三層的IP地址信息就全了：源IP地址：PC-A，目的ip地址：PC-C。

（2）接下來PC-A要知道如何到達PC-C，然後，PC-A會發送一個arp的地址解析請求，發送這個地址解析請求，不是為了獲得目標主機PC-C的MAC地址，而是把請求發送到了路由器A中，然後路由器A中的MAC地址會發送給源主機PC-A，這樣PC-A的數據包的第二層信息也全了，源MAC地址：PC-A的MAC地址，目的MAC地址：路由器A的MAC地址，

（3）然後數據會到達交換機A,交換機A看到數據包的第二層目的MAC地址，是去往路由器A的，就把數據包發送到路由器A，路由器A收到數據包，首先查看數據包的第三層ip目的地址，如果在自己的路由表中有去往PC-C的路由，說明這是一個可路由的數據包。 （4）然後路由器進行IP重組和分組的過程。首先更換此數據包的第二層包頭信息，路由器PC-A到達PC—C要經過一個廣域網，在這里會封裝很多廣域網相關的協議。其作用也是為了找下一階段的信息。同時對第二層和第三層的數據包重校驗。把數據經過Internet發送出去。最後經過很多的節點發送到目標主機PC_C中。

現在我們想一個問題，PC-A和PC-C的MAC地址如果是相同的話，會不會影響正常的通訊呢！答案是不會影響的，因為這兩個主機所處的區域網被廣域網分隔開了，通過對發包過程的分析可以看出來，不會有任何的問題。而如果在同一個區域網中的話，那麼就會產生通訊的混亂。當數據發送到交換機是，這是的埠信息會有兩個相同的MAC地址，而這時數據會發送到兩個主機上，這樣信息就會混亂。因此這也是保證MAC地址唯一性的一個理由。

• 我暫且按我的理解說說吧。

先看一下計算機網路OSI模型的七個層次：

┌—————┐

│ 應用層 │←第七層

├—————┤

│ 表示層 │

├—————┤

│ 會話層 │

├—————┤

│ 傳輸層 │

├—————┤

│ 網路層 │

├—————┤

│數據鏈路層│

├—————┤

│ 物理層 │←第一層

└—————┘

而我們現在用的網路通信協議TCP/IP協議者只劃分了四成：

┌—————┐

│ 應用層 │ ←包括OSI的上三層

├—————┤

│ 傳輸層 │

├—————┤

│ 網路層 │

├—————┤

│網路介面層 │←包括OSI模型的下兩層，也就是各種不同區域網。

└—————┘

兩台計算機通信所必須需要的東西：IP地址（網路層）+埠號（傳送層）。

兩台計算機通信（TCP/IP協議）的最精簡模型大致如下：

主機A---->路由器（零個或多個）---->主機B

舉個例子：主機A上的應用程序a想要和主機B上面的應用程序b通信，大致如下

程序a將要通信的數據發到傳送層，在傳送層上加上與該應用程序對應的通信埠號（主機A上不同的應用程序有不同的埠號），如果是用的TCP的話就加上TCP頭部，UDP就加上UDP頭部。

在傳送成加上頭部之後繼續嚮往下傳到網路層，然後加上IP頭部（標識主機地址以及一些其他的數據，這里就不詳細說了）。

然後傳給下層到數據鏈路層封裝成幀，最後到物理層變成二進制數據經過編碼之後向外傳輸。

在這個過程中可能會經過許多各種各樣的區域網，舉個例子：

主機A--->（區域網1--->路由器--->區域網2）--->主機B

這個模型比上面一個稍微詳細點，其中括弧裡面的可以沒有也可能有一個或多個，這個取決於你和誰通信，也就是主機B的位置。

主機A的數據已經到了具體的物理介質了，然後經過區域網1到了路由器，路由器接受主機A來的數據先經過解碼，還原成數據幀，然後變成網路層數據，這個過程也就是主機A的數據經過網路層、數據鏈路層、物理層在路由器上面的一個反過程。

然後路由器分析主機A來的數據的IP頭部（也就是在主機A的網路層加上的數據），並且修改頭部中的一些內容之後繼續把數據傳送出去。

一直到主機B收到數據為止，主機B就按照主機A處理數據的反過程處理數據，直到把數據交付給主機B的應用程序b。完成主機A到主機B的單方向通信。

這里的主機A、B只是為了書寫方便而已，可能通信的雙方不一定就是個人PC，伺服器與主機，主機與主機，伺服器與伺服器之間的通信大致都是這樣的。

再舉個例子，我們開網頁上網路：

就是我們的主機瀏覽器的這個應用程序和網路的伺服器之間的通信。應用成所用的協議就是HTTP，而伺服器的埠號就是熟知埠號80.

大致過程就是上面所說，其中的細節很復雜，任何一個細節都可以寫成一本書，對於非專業人員也沒有必要深究。

Ⅶ https如何進行加密傳輸

HTTPS在傳輸數據之前需要客戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸數據的密碼信息。TLS/SSL協議不僅僅是一套加密傳輸的協議，更是一件經過藝術家精心設計的藝術品，TLS/SSL中使用了非對稱加密，對稱加密以及HASH演算法。握手過程的具體描述如下：
1.瀏覽器將自己支持的一套加密規則發送給網站。
2.網站從中選出一組加密演算法與HASH演算法，並將自己的身份信息以證書的形式發回給瀏覽器。證書裡麵包含了網站地址，加密公鑰，以及證書的頒發機構等信息。
3.瀏覽器獲得網站證書之後瀏覽器要做以下工作：
a) 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出證書不受信的提示。
b) 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。
c) 使用約定好的HASH演算法計算握手消息，並使用生成的隨機數對消息進行加密，最後將之前生成的所有信息發送給網站。
4.網站接收瀏覽器發來的數據之後要做以下的操作：
a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致。
b) 使用密碼加密一段握手消息，發送給瀏覽器。
5.瀏覽器解密並計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之後所有的通信數據將由之前瀏覽器生成的隨機密碼並利用對稱加密演算法進行加密。
這里瀏覽器與網站互相發送加密的握手消息並驗證，目的是為了保證雙方都獲得了一致的密碼，並且可以正常的加密解密數據，為後續真正數據的傳輸做一次測試。另外，HTTPS一般使用的加密與HASH演算法如下：
非對稱加密演算法：RSA，DSA/DSS
對稱加密演算法：AES，RC4，3DES
HASH演算法：MD5，SHA1，SHA256