iossha加密解密

㈠ iOS中的簽名機制

說到簽名機制，首先要了解一下 加密解密 ,簽名文件就是 加密解密 的過程。

加密 是將明文信息改變為難以讀取的密文內容，使之不可讀的過程。

解密 是通過特殊的對象，將密文還原為正常可讀的內容的過程。而在這個過程中，我們所使用的方法，就是加密解密演算法。

加密分為 對稱加密 與 非對稱加密（公開密鑰加密） 。

對稱加密就是加密和解密使用的都是同一套密鑰

常見的對稱密碼演算法有：

如下圖，在使用對稱密碼時，一定會遇到密鑰配送問題， 假設，Alice將使用對稱密碼加密過的消息發給了Bob， 只有將密鑰發送給Bob，Bob才能完成解密， 在發送密鑰過程中，可能會被Eve竊取密鑰，最後Eve也能完成解密。

加密和解密使用的不是同一個密鑰，即為非對稱加密演算法，也稱公開密鑰加密；

公鑰密碼中，密鑰分為加密密鑰、解密密鑰2種，它們並不是同一個密鑰， 公鑰密碼也被稱為非對稱密碼（Asymmetric Cryptography）

在公鑰密碼中：

加密密鑰 ，一般是公開的，因此該密鑰稱為 公鑰 （public key）

解密密鑰 ，由消息接收者自己保管的，不能公開，因此也稱為 私鑰 （private key） 公鑰和私鑰是一 一對應的，是不能單獨生成的，一對公鑰和密鑰統稱為密鑰對（key pair）

這樣就能 解決秘鑰配送的問題 了，如下圖：

上圖解析：

這其中如果有第三者竊聽，只有第2步和第4步能夠監聽數據，由於Bob公鑰是公開的誰都可以獲取，那麼第二步也不用擔心被誰獲取，第4步如果數據被第三者截獲，那麼他看到的也是加密後的數據，由於他沒有Bob的私鑰，那麼他也無法知道消息的真實內容。而且他即使篡改密文消息也無任何意義。

雖然非對稱加密解決了密鑰配送問題，但是它的加解密速度較慢，下面我們總結一下對稱和非對稱加密的優缺點：

混合密碼 系統，是將對稱密碼和公鑰密碼的優勢相結合的方法:

為本次通信隨機生成的臨時密鑰； 作為對稱密碼的密鑰，用於加密消息，提高速度

首先，消息發送者要擁有消息接收者的公鑰； 生成會話密鑰，作為對稱密碼的密鑰，加密消息； 用消息接收者的公鑰，加密會話密鑰； 將前2步生成的加密結果，一並發給消息接收者。

發送出去的內容包括

用會話密鑰加密的消息（加密方法：對稱密碼）

用公鑰加密的會話密鑰（加密方法：公鑰密碼）

1 消息接收者用自己的私鑰解密出會話密鑰

2 再用第1步解密出來的會話密鑰，解密消息

發送過程，加密過程

接收過程，解密過程

1.Bob利用自己的私鑰解密會話密鑰（使用的是公鑰密碼解密，也就是非對稱密碼解密）

2.Bob利用會話密鑰解密發送過來的消息（使用的是對稱密碼解密）

上面的加密演算法解決了數據傳輸的安全問題，那麼 數據的完整性 是沒法驗證的，就是我這個數據有沒有被改過，因為公鑰大家都能獲取，如果有中間人攔截了消息，並改動了內容。那麼我們如何驗證這個 消息有沒有變動 呢?

單向散列函數 ，又稱單向 Hash函數 、 雜湊函數 ，就是把任意長的輸入消息串變化成 固定長的輸出串 且由輸出串難以得到輸入串的一種函數。這個輸出串稱為該消息的散列值。一般用於產生消息摘要，密鑰加密等

單向散列函數，可以根據根據消息內容計算出散列值 散列值的長度和消息的長度無關 ，無論消息是1bit、10M、100G，單向散列函數都會計算出 固定長度的散列值 。

單向散列函數 ，又被稱為 消息摘要函數 （message digest function），哈希函數輸出的散列值，也被稱為消息摘要（message digest）、指紋（fingerprint）

MD4、MD5 產生128bit的散列值，MD就是Message Digest的縮寫，目前已經不安全 Mac終端上默認可以使用md5命令

SHA-1 產生160bit的散列值，目前已經不安全

SHA-2 SHA-256、SHA-384、SHA-512，散列值長度分別是256bit、384bit、512bit

SHA-3 全新標准

不同的數據生成的散列值是不一樣的，只要你對一個文件改動過，那麼它的散列值就會發生變化，要想確定我們的數據有沒有發生變化，只要對比兩次散列值相不相同就可以了，我們常常做的登錄功能，在保存用戶密碼的時候就採用單項散列函數生成的值來進行保存，防止第三方人員串改密碼。

數據防篡改的技術我們知道了，在數據傳輸的過程中，我們對數據生成一個散列值，和發送的數據一並發給接收者，當接收者收到這個數據的時候，它拿接收到的數據重新生成散列值，然後跟接收到的散列值進行比較，就可以判斷這個數據有沒有被人改過。

到此我們通過混合密碼技術解決的傳輸數據的保密性，通過單項散列函數確定數據的一致性，但是還是沒有解決 中間人截獲篡改 的問題，因為散列函數中間人也可以重新生成一次，接下來我們就要講數字簽名了，他可以對消息發送者的真實性進行認證。

數字簽名 （又稱公鑰數字簽名）是只有信息的發送者才能產生的別人無法偽造的一段數字串，這段數字串同時也是對信息的發送者發送信息真實性的一個有效證明。

它是一種類似寫在紙上的普通的物理簽名，但是使用了公鑰加密領域的技術來實現的，用於鑒別數字信息的方法。一套數字簽名通常定義兩種互補的運算，一個用於簽名，另一個用於驗證。數字簽名是非對稱密鑰加密技術與數字摘要技術的應用。

說白了就是用用消息發送者的私鑰進行簽名就是數字簽名

在數字簽名中，任何人都可以使用公鑰驗證簽名

在數字簽名技術中，有以下2種行為:

生成簽名 由消息的發送者完成，通過「簽名密鑰」生成

驗證簽名 由消息的接收者完成，通過「驗證密鑰」驗證

數字簽名由於是消息發送者的私鑰進行簽名，消息發送者的私鑰只有他自己擁有，別人是沒有的，從而我們通過私鑰進行簽名，別人通過消息發送者的公鑰就能確定消息發送者的真實身份。

接下來我們看一下數字簽名和公鑰密碼的對比:

上圖Alice將要發送的消息用自己的私鑰加密，發送給Bob,Bob用Alice的公鑰解密消息，這里其實有一個不好的點，就是如果Alice如果發送的消息比較大，比如發1GB的視頻文件，那這個簽名過程就太慢了，本身非對稱加密的速度就是比較慢的，

下面我們來看一個改進版的:

這里我們將要發送的消息先生成固定大小的散列值，然後再簽名，這樣簽名文件就小的多了，然後我們將消息和簽名一同發送該Bob,然後Bob再用公鑰解密 對比等。

下面有關數字簽名的一些點進行一下說明：

1 如果有人篡改了文件內容或者簽名內容，會是什麼結果？ 結果是：簽名驗證失敗，證明內容會篡改

2 數字簽名不能保證機密性？ 數字簽名的作用不是為了保證機密性，僅僅是為了能夠識別內容有沒有被篡改

3 數字簽名的作用

數字簽名是能確定消息發送者，前提是你要確定你獲取的公鑰是確定是消息發送者的，如果你拿到的公鑰是中間人偽造的，那麼你就無法驗證消息發送者的真實性了，就如下圖：

[圖片上傳中...(image-b6d6e1-1614756605461-3)]

A問B要公鑰，M從監聽到了中間，B給A發的公鑰被M攔截了並保存，M把他自己的公鑰給了A，A以為這個公鑰是B的，A用公鑰加密發消息給B，M攔截然後用自己的私鑰解密，修改消息內容後，然後用保存的公鑰加密把消息發送給B，B解密消息。A,和B都以為是正常通信的，但消息確實不是那個消息了，那麼如何確定公鑰合法？也就是如何確定這個公鑰就是B的呢？

接下來就是我們要講的證書了，我們引入一個第三方權威機構來認正，說這個公鑰就是B的。接下來我們來看一下。

CA是證書的簽發機構，它是公鑰基礎設施（Public Key Infrastructure，PKI）的核心。CA是負責簽發證書、認證證書、管理已頒發證書的機關。

CA 擁有一個證書（內含公鑰和私鑰）。網上的公眾用戶通過驗證 CA 的簽字從而信任 CA ，任何人都可以得到 CA 的證書（含公鑰），用以驗證它所簽發的證書,密碼學中的證書，全稱叫公鑰證書（Public-key Certificate，PKC），跟駕駛證類似 裡面有姓名、郵箱等個人信息，以及此人的公鑰； 並由認證機構（Certificate Authority，CA）施加數字簽名。

圖已經表示的很清楚了，消息發送者先向CA機構 注冊自己的證書，那麼任何拿到消息發送者的公鑰都可以向CA進行驗證公鑰的真實性。

首先我們要知道iOS簽名機制的作用是什麼？

保證安裝到用戶手機上的APP都是經過Apple官方允許的

不管是真機調試，還是發布APP，開發者都需要經過一系列復雜的步驟：

大致如下圖：

[圖片上傳中...(image-169a4f-1614756605461-0)]

總結：

1、.cerSigningRequest文件 ： Mac公鑰

2、.cer文件：利用Apple私鑰（CA）,對Mac公鑰生成了數字簽名

3、.mobileprovision : 利用Apple私鑰，對【.cer證書 + devices + AppID + entitlements】進行數字簽名

㈡ 字元串的加密與解密（3DES、sha1、MD5） - swift3.1

對於字元串的加密解密，可以給String類擴展方法，方便使用

Swift中使用3DES/sha1/MD5加密解密演算法 必須要引入這個庫 - 在橋接文件中
#import <CommonCrypto/CommonCrypto.h>

3DES的加密是可逆的， sha1和MD5的是不可逆的

使用方法：
直接在xib界面拖一個textFiled的控制項，然後放置3個按鈕，分別是進行MD5、sha1、3DES加密點擊方法，然後分別測試加密解密數據

可以參考文章 http://www.cnblogs.com/jukaiit/p/5039803.html
使用這個第三方來實現 JKEncrypt
** https://github.com/jukai9316/JKEncrypt 。**

㈢ SHA256 加密後能不能解密

SHA是散列演算法，不是加密演算法，不存在解密的問題。

原因：

對數據解密破解就是找到任意一個源數據，能夠生成相同的目標數據。

SHA256基本上是不可破解的，即找不到（或概率極小）「碰撞」結果。

網站的解密規則：

網站從瀏覽器發送過來的信息當中選出一組加密演算法與HASH演算法，並將自己的身份信息以證書的形式發回給瀏覽器。證書裡麵包含了網站地址，加密公鑰，以及證書的頒發機構等信息。

(3)iossha加密解密擴展閱讀：

加密解密過程中，瀏覽器對網站的驗證：

1、驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出證書不受信的提示。

2、如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。

3、使用約定好的HASH演算法計算握手消息，並使用生成的隨機數對消息進行加密，最後將之前生成的所有信息發送給網站。

㈣ Mac OS X：如何驗證 SHA

要驗證從「Apple 下載」網站手動下載的軟體更新（這些更新包含 SHA-1 摘要），請執行以下步驟：1. 打開終端（位於「/Applications/Utilities」下）。 SHA-1 摘要按如下形式顯示：SHA1 (文件的完整路徑)= [校驗和大小] SHA1(/Users/myaccount/Documents/1024SecUpd2003-03-03.dmg) =其他信息關於SHA-1SHA-1 實際上是數據文件的安全校驗和。SHA-1 校驗和基於某種加密標准。對於給定的文件，SHA-1 會產生一個 160 位的加密輸出，此輸出稱作「消息摘要」。經過修改的數據集極不可能會產生同樣的消息摘要。如果文件在傳輸過程中遭到修改，其消息摘要也會發生變化。 SHA-1 和「Apple 下載」網站可以從 Apple 下載網站下載可手動安裝的更新。Apple 在某些「Apple 下載」網站中使用了 SHA-1 摘要，因此您可以驗證（可信性很高）您所下載的軟體是否就是自己想要下載的軟體（請參閱下面的「相關文檔」）。當您所下載的文件的 SHA-1 摘要與「Apple 下載」網站上為該文件顯示的摘要匹配時，您便可以確定該文件是真實的。為了最大限度地保證安全，可以使用安全的 https 下載頁面來下載手動更新。例如，Mac OS�0�2X�0�2v10.6.6 組合更新的手動下載 URL 為：

㈤ ios中https的證書鏈接驗證的簡單理解

https是運行在 TLS/SSL之上的http，與http醒目就是在數據傳輸的安全性問題上做了提高，其實原理也很簡單，就是所謂的 對稱加密 和 非對稱加密

01. 對稱加密只有一個密鑰，加密和解密都用這個密鑰

02.非對稱加密有公鑰和私鑰，私鑰加密後的內容只有公鑰才能解密，公鑰加密的內容只有私鑰才能解密。

為了提高安全性，通常的做法是使用對稱加密的方法進行加密，但是對稱加密也有問題，雙方通信的開始總會以明文的方式傳輸密鑰。那麼一開始這個密鑰就泄露了，所以風險不言而喻。。。

所以TLS/SSL在握手的階段，結合非對稱加密的手段，保證只有通信雙方才知道對稱加密的密碼；

數字證書的生成是分層級的，下一級的證書需要其上一級證書的私鑰簽名。

所以後者是前者的證書頒發者，也就是說上一級證書的Sbuject Name 是其下一級證書的 Issure Name.

在得到證書申請者的一些必要信息（對象名稱，公鑰私鑰）之後，證書頒發者通過 SHA-256 哈希得到證書內容的摘要，再用自己的私鑰給這份摘要加密，得到數字簽名。綜合已有的信息，生成分別包含公鑰和私鑰的兩個證書。

01.根證書是自簽名的，即用自己的私鑰簽名，不需要其他證書的私鑰來生成簽名

02.當客戶端走https訪問站點時，伺服器會返回整個證書鏈。

01.  信任鏈中如果只含有有效證書並且可信錨點結尾，那麼這個證書就被認為是有效的。可信錨點指的是系統隱式信任證書，通常是包括在系統中的CA根證書，不過可以在驗證證書鏈時，設置自定義證書為可信錨點。

02. NSURLSession實現https，使用 NSURLSession 走 HTTPS 訪問網站，-URLSession:didReceiveChallenge:completionHandler: 回調中會收到一個 challenge，也就是質詢，需要你提供認證信息才能完成連接，這時候可以通過 challenge.protectionSpace.authenticationMethod 取得保護空間要求我們認證的方式，如果這個值是 的話，我們就可以插手 TLS 握手中「驗證數字證書有效性」這一步。

系統的默認實現（也即代理不實現這個方法）是驗證這個信任鏈，結果是有效的話則根據 serverTrust 創建 credential 用於同服務端確立 SSL 連接。否則會得到 「The certificate for this server is invalid...」 這樣的錯誤而無法訪問。

比如在訪問 https://www.google.com 的時候咧，我們不實現這個方法也能訪問成功的。系統對 Google 伺服器返回來的證書鏈，從葉節點證書往根證書層層驗證（有效期、簽名等等），遇到根證書時，發現作為可信錨點的它存在與可信證書列表中，那麼驗證就通過，允許與服務端建立連接。

看考地址： http://www.cnblogs.com/oc-bowen/p/5896041.html    02. ios中的網路加密

㈥ ios手機115sha1碼怎麼用

使用115網盤分享鏈接下載文件的方法如下：
1、可以看到他人分享的115網盤文件鏈接，點擊復制按鈕。
2、在瀏覽器的地址欄中粘貼該鏈接並回車。
3、然後在提取文件的輸入框中編輯對應的訪問碼，點擊確定按鈕。
4、頁面跳轉以後可以看到已經找到了該文件，勾選文件以後點擊下載按鈕。

㈦ sha256可以解密嗎

SHA是散列演算法，並非加密演算法，也當然也不存在解密的問題。正確的說法應該叫「破解」。所謂破解就是找到任意一個源數據，能夠生成相同的目標數據，即「碰撞」。目前的計算能力下，SHA256基本上是不可破解的，即找不到（或概率極小）「碰撞」結果。

㈧ 簡單講解iOS應用開發中的MD5加密的使用

一、簡單說明

1.說明

在開發應用的時候，數據的安全性至關重要，而僅僅用POST請求提交用戶的隱私數據，還是不能完全解決安全問題。

如：可以利用軟體（比如Charles）設置代理伺服器，攔截查看手機的請求數據

「青花瓷」軟體

因此：提交用戶的隱私數據時，一定不要明文提交，要加密處理後再提交

2.常見的加密演算法

MD5 SHA DES 3DES RC2和RC4 RSA IDEA DSA AES

3.加密演算法的選擇

一般公司都會有一套自己的加密方案，按照公司介面文檔的規定去加密

二、MD5

1.簡單說明

MD5:全稱是Message Digest Algorithm 5，譯為「消息摘要演算法第5版」

效果：對輸入信息生成唯一的.128位散列值（32個字元）

2.MD5的特點

（1）輸入兩個不同的明文不會得到相同的輸出值

（2）根據輸出值，不能得到原始的明文，即其過程不可逆

3.MD5的應用

由於MD5加密演算法具有較好的安全性，而且免費，因此該加密演算法被廣泛使用

主要運用在數字簽名、文件完整性驗證以及口令加密等方面

4.MD5破解

MD5解密網站：http://www.cmd5.com

5.MD5改進

現在的MD5已不再是絕對安全，對此，可以對MD5稍作改進，以增加解密的難度

加鹽（Salt）：在明文的固定位置插入隨機串，然後再進行MD5

先加密，後亂序：先對明文進行MD5，然後對加密得到的MD5串的字元進行亂序

總之宗旨就是：黑客就算攻破了資料庫，也無法解密出正確的明文

代碼示例：

復制代碼 代碼如下:

#import "HMViewController.h"

#import "NSString+Hash.h"

#define Salt @"fsdhjkfhjksdhjkfjhkd546783765"

@interface HMViewController ()

@end

@implementation HMViewController

- (void)viewDidLoad

{

[super viewDidLoad];

[self digest:@"123"]; //

[self digest:@"abc"];

[self digest:@"456"];

}

/**

* 直接用MD5加密

*/

- (NSString *)digest:(NSString *)str

{

NSString *anwen = [str md5String];

NSLog(@"%@ - %@", str, anwen);

return anwen;

}

/**

* 加鹽

*/

- (NSString *)digest2:(NSString *)str

{

str = [str stringByAppendingString:Salt];

NSString *anwen = [str md5String];

NSLog(@"%@ - %@", str, anwen);

return anwen;

}

/**

* 多次MD5

*/

- (NSString *)digest3:(NSString *)str

{

NSString *anwen = [str md5String];

anwen = [anwen md5String];

NSLog(@"%@ - %@", str, anwen);

return anwen;

}

/**

* 先加密, 後亂序

*/

- (NSString *)digest4:(NSString *)str

{

NSString *anwen = [str md5String];

// 注冊: 123 ----

// 登錄: 123 ---

NSString *header = [anwen substringToIndex:2];

NSString *footer = [anwen substringFromIndex:2];

anwen = [footer stringByAppendingString:header];

NSLog(@"%@ - %@", str, anwen);

return anwen;

}

@end

（1）直接使用MD5加密（去MD5解密網站即可破解）

（2）使用加鹽（通過MD5解密之後，很容易發現規律）

（3）多次MD5加密（使用MD5解密之後，發現還是密文，那就接著MD5解密）

（4）先加密，後亂序（破解難度增加）

三、注冊和驗證的數據處理過程

1.提交隱私數據的安全過程 – 注冊

2.提交隱私數據的安全過程 – 登錄

㈨ iOSRSA加密和SHA驗簽

RSA是一種非對稱加密演算法，常用來對傳輸數據進行加密，配合上數字摘要演算法，也可以進行文字簽名。

padding即填充方式，由於RSA加密演算法中要加密的明文是要比模數小的，padding就是通過一些填充方式來限制明文的長度。後面會詳細介紹padding的幾種模式以及分段加密。

加密：公鑰放在客戶端，並使用公鑰對數據進行加密，服務端拿到數據後用私鑰進行解密；

加簽：私鑰放在客戶端，並使用私鑰對數據進行加簽，服務端拿到數據後用公鑰進行驗簽。

前者完全為了加密；後者主要是為了防惡意攻擊，防止別人模擬我們的客戶端對我們的伺服器進行攻擊，導致伺服器癱瘓。

RSA使用「密鑰對」對數據進行加密解密，在加密解密前需要先生存公鑰（Public Key）和私鑰（Private Key）。

公鑰(Public key): 用於加密數據. 用於公開, 一般存放在數據提供方, 例如iOS客戶端。

私鑰(Private key): 用於解密數據. 必須保密, 私鑰泄露會造成安全問題。

iOS中的Security.framework提供了對RSA演算法的支持，這種方式需要對密匙對進行處理, 根據public key生成證書, 通過private key生成p12格式的密匙

首先我們要會生成RSA密鑰文件，現在一步步的來給大家展示一下，如何生成我們所需的公鑰和私鑰文件：

$ openssl genrsa -out private.pem 1024

openssl:是一個自由的軟體組織,專注做加密和解密的框架。

genrsa:指定了生成了演算法使用RSA

-out:後面的參數表示生成的key的輸入文件

1024:表示的是生成key的長度,單位位元組(bits)

$ openssl req -new -key private.pem -out rsacert.csr

可以拿著這個文件去數字證書頒發機構（即CA）申請一個數字證書。CA會給你一個新的文件cacert.pem,那才是你的數字證書。(要收費的)

$ openssl x509 -req -days 3650 -in rsacert.csr -signkey private.pem -out rsacert.crt

509是一種非常通用的證書格式。

將用上面生成的密鑰privkey.pem和rsacert.csr證書請求文件生成一個數字證書rsacert.crt。這個就是公鑰

$ openssl x509 -outform der -in rsacert.crt -out rsacert.der

注意: 在 iOS開發中,公鑰是不能使用base64編碼的,上面的命令是將公鑰的base64編碼字元串轉換成二進制數據

在iOS使用私鑰不能直接使用，需要導出一個p12文件。下面命令就是將私鑰文件導出為p12文件。

$ openssl pkcs12 -export -out p.p12 -inkey private.pem -in rsacert.crt

IOS客戶端的加解密首先我們需要導入Security.framework，

在ios中，我們主要關注四個函數

RSA演算法有2個作用一個是加密一個是加簽。從這幾個函數中，我們可以看到，我們第一種是使用公鑰能在客戶端：加密數據，以及伺服器端用私鑰解密。

第二個就是用私鑰在客戶端加簽，然後用公鑰在伺服器端用公鑰驗簽。第一種完全是為了加密，第二種是為了放抵賴，就是為了防止別人模擬我們的客戶端來攻擊我們的伺服器，導致癱瘓。

(1)獲取密鑰，這里是產生密鑰，實際應用中可以從各種存儲介質上讀取密鑰 (2)加密 (3)解密

(1)獲取密鑰，這里是產生密鑰，實際應用中可以從各種存儲介質上讀取密鑰 (2)獲取待簽名的Hash碼 (3)獲取簽名的字元串 (4)驗證

(1)私鑰用來進行解密和簽名，是給自己用的。

(2)公鑰由本人公開，用於加密和驗證簽名，是給別人用的。

(3)當該用戶發送文件時，用私鑰簽名，別人用他給的公鑰驗證簽名，可以保證該信息是由他發送的。當該用戶接受文件時，別人用他的公鑰加密，他用私鑰解密，可以保證該信息只能由他接收到。

使用事例:

Demo鏈接

㈩ 加密演算法總結

iOS加密相關演算法框架：CommonCrypto
明文： 明文指的是未被加密過的原始數據。
密文： 明文被某種加密演算法加密之後，會變成密文，從而確保原始數據的安全。密文也可以被解密，得到原始的明文。
密鑰： 密鑰是一種參數，它是在明文轉換為密文或將密文轉換為明文的演算法中輸入的參數。密鑰分為對稱密鑰與非對稱密鑰，分別應用在對稱加密和非對稱加密上。

對稱加密又叫做私鑰加密 ，即信息的發送方和接收方使用 同一個密鑰 去加密和解密數據。
對稱加密的特點是 演算法公開、計算量少、加密和解密速度快效率高 ，適合於對大數據量進行加密；
缺點是 雙方使用相同的密鑰、密鑰傳輸的過程不安全、易被破解、因此為了保密其密鑰需要經常更換
常見的對稱加密演算法有 AES、DES 、3DES、TDEA、Blowfish、RC5和IDEA。【不過DES被認為是不安全的】
加密過程：明文 + 加密演算法 + 私鑰 => 密文
解密過程： 密文 + 解密演算法 + 私鑰 => 明文
對稱加密中用到的密鑰叫做 私鑰 ，私鑰表示個人私有的密鑰，即該密鑰不能被泄露。
其 加密過程中的私鑰與解密過程中用到的私鑰是同一個密鑰 ，這也是稱加密之所以稱之為「對稱」的原因。由於對稱加密的 演算法是公開 的，所以一旦私鑰被泄露，那麼密文就很容易被破解，所以對稱加密的 缺點是密鑰安全管理困難 。

3DES是DES加密演算法的一種模式，它使用3條64位的密鑰對數據進行三次加密。是DES像AES過渡的加密演算法，是DES的一個更安全的變形，它以DES為基本模塊，通過組合分組方法設計出分組加密演算法。

非對稱加密也叫做公鑰加密 。非對稱加密與對稱加密相比，其安全性更好。對稱加密的通信雙方使用相同的密鑰，如果一方的密鑰遭泄露，那麼整個通信就會被破解。而 非對稱加密使用一對密鑰，即公鑰和私鑰 ， 且二者成對出現 。私鑰被自己保存，不能對外泄露。公鑰指的是公共的密鑰，任何人都可以獲得該密鑰。用公鑰或私鑰中的任何一個進行加密，用另一個進行解密。兩種使用方法：

哈希演算法加密是通過哈希演算法對數據加密、加密後的結果不可逆，即加密後不能在解密。

SHA加密，安全哈希演算法，主要適用於數字簽名簽名標准（ DSS ）裡面定義的數字簽名演算法（ DSA ）。對於長度小於 2^64 位的消息， SHA1 會產生一個160位的消息摘要。當接收消息的時候，這個消息摘要可以用來驗證數據的完整性。在傳輸的過程中，數據很可能會發生變化，那麼這時候就會產生不同的消息摘要。當然除了 SHA1 還有 SHA256 以及 SHA512 等。

HMAC加密，給定一個密鑰，對明文加密，做兩次「散列」，得到的結果還是32位字元串。

就是或、與、異或、或者加上某個數據
特點：可逆、原始數據和加密數據長度保持一致