一般我们可能就做简单的防篡改和密文加密。
很多时候做一个加密只不过是一个小小的心理安慰吧了,因为纯粹的从安全角度来说,安全性真的不高。
对于一些手机支付以及银联的客户端,我看到有用的证书什么来实现。
因为没做过,所以也不是太了解。
这边就说下最简单的加密方案。
一:MD5数字摘要。
准确来说,MD5不能叫做加解密,因为它不可逆性。
一般我们理解的加解密是能加密,然后解密的。
MD5只是根据数据生个一个校验码,然后对于数据接受者接受到内容后同样的在通过md5来生成校验码于之前的校验码对比是否一致,
从而来判断数据在传送过程中是否被截取篡改过。
说白了,其实在传输过程中,仅仅md5技术,数据任然是明文的。
下面我来来看下IOS中对md5加密的支持。
代码很简单,因为内部算法都是系统已经完成的。
对于以上来看,仍然没有很好的处理密文传输只是在数据传输过程成做了一个简单的防篡改。
因此需要使用一种能生成密文的安全机制类支持。
二:ios中3DES加密
3DES是一种对称的加密方式,因为用的同一个密钥。
对于加解密的安全性什么大家可以google,baidu自己找资料参考。
我也不过是简单的说一下通信加密中的一种可实现方案而已。
同样的3DES加密基本也都是统一的,系统也直接提供了API,基本代码如下
这个在网上也能搜索到详细代码。
但是要注意到一点:
这个里面的参数可能会根据你服务端使用的对应的3des算法构造时参数的不同而需要自己调整。
比如我在网上看到的这个第三个参数只是用了kCCOptionPKCS7Padding,第六个可选参数用了上面一个自定义的iv。
但是这边根据服务器,这个参数是nil才对应。
这边也附上java端的加解密代码
内容也很少,这这么点。
然后是key,也就是共用密钥的客户端和服务端都保存一个。
简单从数据传输来说,密文传输了,安全性相对来说提高了不少。
但是如果破解了客户端代码,那么其实密钥也就暴露了。
这对于android上面来说,因为反编译额纯在,安全性不敢恭维,
ios的貌似好一点,因为暂未听说反编译ios的app的。
以上就是一种简单的通信加密方案。
原文链接: http://www.cnblogs.com/xiaobaizhu/archive/2013/05/03/3056068.html
很多时候做一个加密只不过是一个小小的心理安慰吧了,因为纯粹的从安全角度来说,安全性真的不高。
对于一些手机支付以及银联的客户端,我看到有用的证书什么来实现。
因为没做过,所以也不是太了解。
这边就说下最简单的加密方案。
一:MD5数字摘要。
准确来说,MD5不能叫做加解密,因为它不可逆性。
一般我们理解的加解密是能加密,然后解密的。
MD5只是根据数据生个一个校验码,然后对于数据接受者接受到内容后同样的在通过md5来生成校验码于之前的校验码对比是否一致,
从而来判断数据在传送过程中是否被截取篡改过。
说白了,其实在传输过程中,仅仅md5技术,数据任然是明文的。
下面我来来看下IOS中对md5加密的支持。
代码很简单,因为内部算法都是系统已经完成的。
对于以上来看,仍然没有很好的处理密文传输只是在数据传输过程成做了一个简单的防篡改。
因此需要使用一种能生成密文的安全机制类支持。
二:ios中3DES加密
3DES是一种对称的加密方式,因为用的同一个密钥。
对于加解密的安全性什么大家可以google,baidu自己找资料参考。
我也不过是简单的说一下通信加密中的一种可实现方案而已。
同样的3DES加密基本也都是统一的,系统也直接提供了API,基本代码如下
这个在网上也能搜索到详细代码。
但是要注意到一点:
这个里面的参数可能会根据你服务端使用的对应的3des算法构造时参数的不同而需要自己调整。
比如我在网上看到的这个第三个参数只是用了kCCOptionPKCS7Padding,第六个可选参数用了上面一个自定义的iv。
但是这边根据服务器,这个参数是nil才对应。
这边也附上java端的加解密代码
内容也很少,这这么点。
然后是key,也就是共用密钥的客户端和服务端都保存一个。
简单从数据传输来说,密文传输了,安全性相对来说提高了不少。
但是如果破解了客户端代码,那么其实密钥也就暴露了。
这对于android上面来说,因为反编译额纯在,安全性不敢恭维,
ios的貌似好一点,因为暂未听说反编译ios的app的。
以上就是一种简单的通信加密方案。
原文链接: http://www.cnblogs.com/xiaobaizhu/archive/2013/05/03/3056068.html