參考資料：
②基于HTTP在互聯(lián)網(wǎng)傳輸敏感數(shù)據(jù)的消息摘要、簽名與加密方案
其中比較重要的地方：
①簽名消息（數(shù)字簽名）
RSA除了進(jìn)行非對稱加密意外，實(shí)際應(yīng)用中也可以用來為一個(gè)消息署名，也就是做數(shù)字簽名。假如甲想給乙傳遞一個(gè)署名的消息的話，那么她可以為她的消息計(jì)算一個(gè)散列值(Message digest)，然后用她的密鑰(private key)加密這個(gè)散列值并將這個(gè)“署名”加在消息的后面。這個(gè)消息只有用她的公鑰才能被解密。乙獲得這個(gè)消息后可以用甲的公鑰解密這個(gè)散列值，然后將這個(gè)數(shù)據(jù)與他自己為這個(gè)消息計(jì)算的散列值相比較。假如兩者相符的話，那么他就可以知道發(fā)信人持有甲的密鑰，以及這個(gè)消息在傳播路徑上沒有被篡改過。
②為了速度起見，https 連接只在建立連接時(shí)，使用服務(wù)器的公鑰加密，這個(gè)階段是為了交換一個(gè)共享密鑰。
③通常公開鑰算法用于相互驗(yàn)證，之后會建立session key（比如128位AES key）。后續(xù)交互的信息都是用session key和對稱加密算法（比如AES）來加解密的，已經(jīng)與證書本身和公鑰密鑰無關(guān)。因?yàn)楣_密鑰算法比對稱密鑰算法開銷大很多。
根據(jù)以上資料，自己又整理了一下，方案如下：
方案一：客戶端的AES密鑰是隨機(jī)生成，RSA加密不用于加密數(shù)據(jù)，而是用來加密AES的密鑰?？蛻舳伺c服務(wù)端的交互是短連接，每次交互都隨機(jī)生成AES密鑰，數(shù)據(jù)用AES加密，AES密鑰用RSA加密，每次請求同時(shí)傳遞密文和加密后的AES密鑰。
以上僅是個(gè)人的思想，如果有不對的地方還請多指摘。
