DES加解密总结

| Comments

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

Comments