但很多人反映的Java中的DES/TDES与.NET中的DES/TDES不通用,其实并不存在这样的问题的。两者是几乎完全通用的。所以没有存在不通用的情况的。
由于语言的实现基于自己的习惯与理解上的不同,不同的语言采用了不同的默认参数(默认值),当然,就算在同种语言下,这些参数不同的时加密与解密也会有所不同的(只会默认默认参数就认为不通用的那些人,真想不通这个问题怎么提出来的)。
事实上DES除了一个key与iv(初始向量)必须保证相同外,还有对加密的不同解释参数,如mode与paddingmode。DES加密是是块加密的一种,在处理块级与未尾块级时,有不同的方式(mode)如电子密码本(CBC)之类的,每个参数有不同的加密行为与意义,当然这只是DES加密标准的一部分,并不能独立出去的。paddingMode则是则块加密当最后一个块不足时的填充方式。而在java与net实现加密或解密时都遵从标准,实现了不同的填充方式以供选择。但由于每个语言的默认值不同,如net中cbc是默认值,而Java中则是另外一个,填充方式的默认值也不相同,所以会出现不设计这两个参数时,在java与net通信时无法正确解密。所谓的不Java与net中DES不同,仅仅只是默认参数不同,如果你能正确设置这两个参数,几乎任何语言中DES加密与解密都是通用的(部分语言中并没有全部实现DES中的标准,所以可能会出现特定语言的某种加密方式无法在另一种语言中解析)。
所以,DES本身没有任何区别,他只是一个标准(你家交流电与他家交流电有什么区别?),对于不同的实现必须依赖于此标准实现,所以DES标准本身而言是相同的。如果说DES在Java与NET中的类库实现有什么区别,那么两种语言类库完全没可比性(两个人有什么区别,一张嘴两只眼睛的标准外,怕是没有相同之处了),而对于DES实现支持上,两者也是几乎相同,Java与net均实现了DES标准全部的规范。
最后想说的是,加密学中只介绍DES,并不说在不同语言中的实现,因为任何语言实现都依赖于相同的DES加解密算法。我觉得这个问题应该问成“在DES在java中与NET中实现的类库默认值有什么不同”才对。
加密锁:威步(WIBU)的CodeMeter,AxProtector(for.net)两款软件加密锁性能非常不错混淆的问题,与传统的代码混淆工具(Obfuscator)不同,AxProtector可以完全阻止对.NET 程序集(由 C#, VB.NET, Delphi.NET, ASP.Net… 等语言编写)的反编译。通俗的讲,AxProtector在破解者和您的 .NET 代码之间构建了强大的防破解保护屏障,生成一个基于 Windows 的而不是基于 MSIL 的兼容格式文件。原始的 .NET 代码完整的被加密后封装在本地代码内,无论何时都不会释放到硬盘,对于破解者是不可见的。与单纯的.net加密软件不同,AxProtector与CodeMeter硬件加密狗配套餐使用,采用了更为严密的密钥管理,及最先进的AES、RSA、ECC等加密算法存储或传输密钥,保证通讯安全。.Net代码编译后生成的 .class 中包含有源代码中的所有信息(不包括注释),尤其是在其中保存有调试信息的时候。所以一个按照正常方式编译的.class 文件可以非常轻易地被反编译。一般软件开发商会采用一种叫做混淆器的工具。混淆器的作用是对编译好的代码进行混淆,使得其无法被反编译或者反编译后的代码混乱难懂。由于混淆器只是混淆了方法名称或流程,而不能防止源代码被反编译,因此混淆器的作用只是增加了反编译的难度,最终的结果也是治标不治本。对于一些掌握工具的人来说几乎还是透明的。AxProtector是一款真正意义的加密源代码、防止反编译的.net软件加密软件。AxProtector加密了.net原代码,任何时候原代码都不可能被还原到硬盘当中。采用AxProtector加密后的.net代码只有在程序调用或执行某一段函数的时候,才能通过AxProtectorClass在内存中解密后返回到程序中执行,运行之后迅速立即加密。这种随机加密、按需解密原代码的功能,能很好的防止.Net程序的反编译,同时能够很好地防止API加密点被摘除。有效地保证了源代码的执行效率和安全性。