加密主要包含通信數據和存儲數據加密，目的都是為了保證其傳送和儲存的隱秘性，從而保證數據的安全。目前常見的加密方式有對稱加密、非對稱加密、hash加密、hash加鹽加密等,這些在游戲中都會用的，我們會對其用途以及缺陷一一說明，當然了，為了保證其加密算法的安全以及高效，我們也會介紹幾種自定義的加密算法，看看加密如何來維護我們的數據安全。
1、對稱加密
對稱加密算法是應用較早的加密算法，技術成熟。主要就是對密鑰的一個維護，發送方把數據和密鑰通過一定的加密算法處理后，發送給接收方，接受方接到之后在使用相同密鑰及算法的逆算法對密文進行解密。這就是一般的對稱加密算法過程。常見的對稱加密算法有AES、DES，3DES，TDEA，Blowfish，RC5，IDEA等，建議用AES,速度快，安全性也可以。
對稱加密算法的特點是算法公開、計算量小、加密速度快、加密效率高。缺點主要就是密鑰需要雙方都有，如果密鑰被竊取，那么加密就會比第三方破解，特別是游戲中，密鑰如果存放在客戶端中，容易被破解反編譯到。
我們可以采取登陸消息和邏輯消息采用不同的密鑰，登陸驗證通過之后，服務器為每個用戶分配不同的密鑰，然后把邏輯密鑰傳送給客戶端，以此保證密鑰的不確定性，從而增加游戲的安全。
2、非對稱加密
非對稱加密算法使用兩把完全不同但又是完全匹配的一對鑰匙—公鑰和私鑰。在使用不對稱加密算法加密文件時，只有使用匹配的一對公鑰和私鑰，才能完成對明文的加密和解密過程。這對於對稱加密算法來說，又安全了一步，也是目前https常用的加密方式，公鑰可以分配和暴露給所有想要訪問的請求者，但密鑰一定牢牢的掌握在服務器這邊，如此對通信來說，安全性有保證。常用的加密算法，RSA,DSA,ECC。
非對稱加密算法，優點就是安全，但缺點就是不夠快，比較耗費cpu，如果在游戲中每一次消息都有其加密，對cpu的損耗還是挺高的，所以游戲中一般不用這種加密方式，當然了也看游戲類型，如果對這方面的性能要求不高，安全性要求有很高，采用業務科厚非（那個游戲這么傻啊）。
3、hash加密
hash加密，就是常見的使用MD5、SHA1等單向HASH算法保護密碼，使用這些算法后，無法通過計算還原出原始密碼，而且實現比較簡單也高效，因此很多互聯網公司都采用這種方式保存用戶密碼。
但安全性越來越擔憂了，因為隨着彩虹表技術的興起，可以建立彩虹表進行查表破解，目前這種方式已經很不安全了。
4、hash 加鹽加密
hash加密既然容易被彩虹表破解，那么可以采用加鹽、多次HASH等擴展，這樣可以在一定程度上增加破解難度。常見的方式也是發送方和接受方，維護一個鹽池，加密和解密的時候加上這一段鹽池來進行hash。
不過這種算法又回到了對稱加密中對密鑰的保護問題了，如果鹽池泄露，別人依然會破解。
怎么辦？有人又想出了，讓鹽池隨機的方式，比如PBKDF2算法，原理大致相當於在HASH算法基礎上增加隨機鹽，並進行多次HASH運算，隨機鹽使得彩虹表的建表難度大幅增加，而多次HASH也使得建表和破解的難度都大幅增加。一次密碼驗證過程進行1000次HASH運算，對服務器來說可能只需要1ms，但對於破解者來說計算成本增加了1000倍，而至少8字節隨機鹽，更是把建表難度提升了N個數量級，使得大批量的破解密碼幾乎不可行，該算法也是美國國家標准與技術研究院推薦使用的算法。
5、自定義加密
終於到這個了，以上那么多高大上的加密算法，都是業界比較成熟的算法，好處是處處有API支持也有人實現，拿來就用，壞處也是，算法格式規整透明，除了非對稱算法，都有其對應的破解方式。游戲的加密要怎樣？安全、安全，高效、高效，你不能一個加密算法就耗費我100ms的cpu吧，太浪費了。
我們可以嘗試一種動態加密的方式，就是每一次請求保證用不同的密鑰，這樣即便一個消息被截取破解了，下一次密鑰又不一樣，如此破解者會比較崩潰。怎么做？我簡單說下思想。
每個消息必須有唯一id，一個是防止消息重放，一個可以用來做我們的加密。比如我們初始的時候有一個密碼池 A=【1,2,3,4,5】，每次消息從服務器發送出去的時候，消息ID都+1，
當前密鑰=A.index(消息ID%A.length)，如此就能保證每次密鑰不一樣，具體拿到密鑰如何加密，完全可以用自己的加密方式，比如把二進制一部分截取通過密鑰移位操作，或者算法運算都可以。
我們的目的一個保證密鑰動態，一個就是保證算法足夠高效。
| 算法 | 特點 | 有效破解方式 | 破解難度 | 其它 | 算法名字 |
| 對稱加密 | 可以解密出明文 | 獲取密鑰 | 中 | 需要確保密鑰不泄露 | AES，3DES |
| 非對稱加密 | 一對鑰匙—公鑰和私鑰 | 獲取私鑰 | 高 | 效率低，安全性高 | RSA,DSA,ECC,DH |
| HASH加密 | 簡單，高效 | 碰撞、彩虹表 | 中 |
|
MD5，SHA1，SHA1256 |
| 加鹽HASH | 對hash加鹽處理 | 碰撞、彩虹表 | 中 | 需要確保“鹽”不泄露 | 同上 |
| Pbkdf2 | 對hash的鹽池進行隨機處理 | 無 | 難 | 隨機鹽池不能太大，8個字節比較合適 | 同上 |
| 自定義算法 | 非標准，高效，安全 | 無 | 難 | 算法的靈活性 | 動態密鑰 |