DES加解密总结

DES是广泛使用的分组对称加密算法，它要求待加密数据要8位对齐，所以在数据不足8位时候会出现padding的情况，
所以有可能因为padding不同，而出现加解密结果不一样，这种情况在异构系统间的数据通信特别容易出现，例如java和cpp系统之间的通信。
如果在开发过程中，遇到不同语言加解密结果不一样的情况，应该关注一下补齐方式。
关于补齐方式，请参考http://en.wikipedia.org/wiki/Padding_%28cryptography%29

先说说java这里，java api已经集成了DES加解密算法，如果不指定补齐方式的话，默认的补齐方式是使用PKCS5Padding，
这种情况下，长度不足8字节的部分，填充“0x01”—“0x08”，如不
足1字节，则填充1个“0x01”，如不足2字节，则填充2个“0x02”，以此类推。更具
体的描述，参考What Is PKCS5Padding?
如果我们指定补齐方式，如使用DES/ECB/NoPadding的话(其中ECB是加密的模式，也是默认的加密方式)，就需要自己手动补齐，例如补空格字符。
现在的代码为了和后台的加解密结果一致，采用的是手动补齐的方式，即NoPadding方式。

如果cpp实现的padding方式和java的不一致，就可能导致加解密失败。在我们的系统里边，cpp实现的padding是补\0的。
这个字符在显示的时候就直接被当成结束符了，无需特殊处理。所以，如果使用java加密，cpp解密的话，
java这边也要使用补\0的做法，如果使用java解密的话，就只能使用trim进行处理了。

以我们这边使用的两个DES相关的接口为例，用户鉴权接口在配置里边有使用trim进行处理，而wlan密码认证接口没有使用trim处理。
因此按现在使用补空格的方法，在用户鉴权接口是能成功的，但在wlan密码认证接口里边是会导致认证失败的。

如果需要更多关于加密补齐的资料，可以参考Using Padding in Encryption