84669인 학습
152542인 학습
20005인 학습
5487인 학습
7821인 학습
359900인 학습
3350인 학습
180660인 학습
48569인 학습
18603인 학습
40936인 학습
1549인 학습
1183인 학습
32909인 학습
最近在思考安全性的问题。情景是:服务器和客户端之间的数据通讯(更确切的是,主要是服务器给客户端传递数据)。 如果使用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的靠谱