最近在思考安全性的问题。情景是：服务器和客户端之间的数据通讯（更确切的是，主要是服务器给客户端传递数据）。 如果使用https的话，不可避免的是每次链接都会有更多的握手步骤，带来的时间开销，会大大的降低移动端的用户体验吧。而且，用经典的ASIHttprequest似乎也不支持https╮(╯_╰)╭。
不知道大侠们有些什么更好的建议？
认证0级讲师
@gaosboy 提到的對稱加密的方法基本上可行。為增強安全性，另外提供一個簡易的方案：
這樣做的好處是，即使密鑰K或任意一次會話過程中的密鑰被破解，仍然無法完全對所有會話進行解密，必須同時知道K、密鑰拼接規則以及加密方法才可完全破解。
覺得 @yuanlizbyy 的方案不夠可靠。程式碼和金鑰都在客戶端，對於真想要破解的人來說，不是什麼難事。 LZ嫌https的握手羅嗦，大可自己實現一個，要簡單得多，只需要使用一對RSA（或其他非對稱加密體系）的公鑰、私鑰。客戶端拿著公鑰，伺服器拿著私鑰。
連接流程：
1. 客戶端產生一個隨機的金鑰K(當然K需要夠強)，將它用公鑰加密，然後傳送給伺服器 2. 伺服器用私鑰解密得到K 3. 二者直接使用AES（金鑰為K）加密通訊。
優點：安全(除非入侵伺服器拿到私鑰、或破解久經考驗的RSA/AES演算法）、快速（只有第一次來回需要RSA解密稍慢）。 缺點：需要一次握手（但可以解決：握手的來回，實際上可以用金鑰K來進行加密額外傳送資料）。
歡迎拍磚。
我曾經用的是對稱加密。 AES，客戶端維護一個私鑰，把需要加密的資料加密就http傳到服務端，然後解開
@felix021的方案比@yuanlizbyy的可靠度
@gaosboy 提到的對稱加密的方法基本上可行。為增強安全性，另外提供一個簡易的方案：
這樣做的好處是，即使密鑰K或任意一次會話過程中的密鑰被破解，仍然無法完全對所有會話進行解密，必須同時知道K、密鑰拼接規則以及加密方法才可完全破解。
覺得 @yuanlizbyy 的方案不夠可靠。程式碼和金鑰都在客戶端，對於真想要破解的人來說，不是什麼難事。 LZ嫌https的握手羅嗦，大可自己實現一個，要簡單得多，只需要使用一對RSA（或其他非對稱加密體系）的公鑰、私鑰。客戶端拿著公鑰，伺服器拿著私鑰。
連接流程：
1. 客戶端產生一個隨機的金鑰K(當然K需要夠強)，將它用公鑰加密，然後傳送給伺服器
2. 伺服器用私鑰解密得到K
3. 二者直接使用AES（金鑰為K）加密通訊。
優點：安全(除非入侵伺服器拿到私鑰、或破解久經考驗的RSA/AES演算法）、快速（只有第一次來回需要RSA解密稍慢）。
缺點：需要一次握手（但可以解決：握手的來回，實際上可以用金鑰K來進行加密額外傳送資料）。
歡迎拍磚。
我曾經用的是對稱加密。
AES，客戶端維護一個私鑰，把需要加密的資料加密就http傳到服務端，然後解開
@felix021的方案比@yuanlizbyy的可靠度