jdk和android的DES加密

前段时间负责开发了javaweb后台与android端的通信接口，其中传递了一些重要信息需要加密处理，我们使用了最常见的DES，加解密的核心代码如下：

令人始料未及的是，对于同一串加密信息（一般是字符串），jdk与android sdk加密出来的东西完全不一样，以至于无法对交互中接收到的数据进行解密。

百度了一些资料，了解了一下大概原因，原文解释如下（参考出处：http://www.docin.com/p-438365141.html）：

 “调用DES加密算法最精要的就是下面两句话：  

Cipher cipher = Cipher.getInstance("DES/CBC/PKCS5Padding");  

cipher.init(Cipher.ENCRYPT_MODE, key, zeroIv);  

CBC是工作模式，DES一共有电子密码本模式（ECB）、加密分组链接模式（CBC）、加密反馈模式（CFB）和输出反馈模式（OFB），  PKCS5Padding是填充模式，还有其他的填充模式：  

然后，cipher.init()一共有三个参数：Cipher.ENCRYPT_MODE、key、zeroIv，zeroIv就是初始化向量，一个8位字符数组。  

工作模式、填充模式、初始化向量这三种因素一个都不能少。否则，如果你不制定的话，那么程序就要调用默认实现。问题就来了，这就与平台有关了。”

这几段话把原理解释的非常清楚，不过有一些知识还可以深挖一下。

1、工作模式的机制，度娘到一个参考文章：http://wenku.baidu.com/view/8e329bc50c22590102029d3d.html

2、初始化向量的作用。  找到这样一个解释：初始化向量那是PBE密钥加密，没有向量的那是普通的加密，对安全方面来说PBE更安全些。

根据以上的分析，把加解密方法再重新修改一下：

开发的环境是eclipse+jetty，以上代码在与android端联调时可正常通信。但打成war包部署到win2003+tomcat上之后，解密的信息却出现了乱码，可笑的是部分乱码而另一部分正常。又折腾了好一阵子，把编码从"utf-8"修改为"gb2312"，这才能正常加解密。

一直到现在也没有完全搞清楚，为什么能win2003服务器在"utf-8"的编码设置下，能正常显示web页面，却不能支持加解密通信。

转载于:https://www.cnblogs.com/langzibuhuitou/archive/2013/01/30/2883331.html