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