Java与.NET DES加密：算法一致性解析

Java和.NET使用DES对称加密的区别

没有什么区别DES只是一种加密算法，.NET语言只实现了这个算法，所以没有区别。
算法和密钥本质上是分开的，算法本质上是公开的，而语言只是该算法的实现。
在这种情况下，DES与语言无关，而只是它自己的算法标准。
然而，很多人反映Java中的DES/TDES与.NET中的DES/TDES不兼容，实际上不存在这样的问题。
两者几乎完全可以互换。
所以不存在不兼容的情况。
由于语言的实现是基于各自的习惯和理解，所以不同的语言使用不同的默认参数（默认值，当然即使是同一种语言，这些参数不同时加密和解密也会不同）。
（那些只默认默认参数并认为不通用的人真的无法理解这个问题是如何提出的）。
事实上，除了密钥和iv（初始向量）必须相同之外，DES还有不同的加密解释参数，例如模式和填充模式。
DES加密是块加密的一种，当块级别处理不完整时，有不同的模式，比如电子密码本(CBC)。
DES加密标准并且不能独立存在。
paddingMode是块加密当最后一个块不足时使用的填充方式。
Java和Net在实现加密或解密时，都遵循标准，实现了不同的填充方式供选择。
但是由于各个语言的默认值不同，例如net中默认值是cbc，而Java中又是一个，而且fill方法的默认值也不同，所以当这两个参数不一样时设计上，java和net会有区别。
网络中所谓Java和DES的区别只是默认参数不同，如果你能正确设置这两个参数，DES加密和解密几乎在所有语言中都是通用的（有些语言并没有实现所有标准。
在DES中，因此在特定语言中可能存在无法用另一种语言解析的特定加密方法）。
所以，DES本身没有什么区别，只是一个标准（AC和其他AC有什么区别？不同的实现都要依赖这个标准实现，所以DES标准是一样的。
如果有什么区别的话在Java和.NET中实现DES类库，那么这两种语言的类库就完全没有可比性了（两个人有什么区别，除了一张嘴两只眼睛的标准，恐怕没有任何相似之处）），并且对于至于DES实现支持，两者几乎是一样的，Java和net都实现了DES标准的所有规范。
最后我想说的是，我们只介绍密码学中的DES，而不是它在不同语言中的实现​​因为每种语言实现都依赖于相同的DES加密和解密算法，我认为这个问题应该是“Java中DES实现的类库默认值有什么区别。
和网络？”

Java实现AES256位对称加密算法要替换什么包才能实现

您需要下载合适版本的JavaCryptographyExtension（JCE）并替换JDK安装目录\jre\lib\security中的local_policy.jar和US_export_policy.jar。
如果是独立的JRE，也会覆盖同一路径下的文件。
。
JDK8对应的JCE位于http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html。
你可以参考我的文章http://boytnt.blog.51cto.com。
/966121/1860309

JAVA和.NET使用DES对称加密的区别

如果我说没有区别你信吗？但答案确实是这样的。
两者没有什么区别，只是实现的语言代码不同而已。
那么DES可以在java和dotnet之间通用吗？答案也是完全通用的。
无论是Java的DES加密还是dotnet的DES后端加密，任何其他语言都可以使用，不限于Java或dotnet解密。
这够清楚了吗？DES其实只是一种算法我们都知道加密和解密与算法和密码是分开的。
算法是公开的，可以使用，而密码与算法无关。
因此，不同语言的DES实现的算法基本相同——也正是因为如此，无论何种语言它都是通用的（除非伪DES，需要知道DES算法本身可以查到）网上有一个标准，第一个是（美国安全部门发布的）我们来谈谈为什么有些人不能使用它的原因，DES实际上有像CBC这样的参数，这是为加密块选择的不同加密方法。
正是因为这个参数，不同的语言都使用不同的参数作为默认值，那么使用默认的方法加密和解密两个字符串肯定是不同的，DES可以使用一种模式（方法）进行加密，另一种模式（方法）进行解密吗？技能，但是说这两种语言的DES加密方法不通用（这就是为什么百度说Java和dotnet的DES加密方法不通用的原因有很多）普遍的）。
即使你使用的DES加密代码是通用的（前提是你必须遵守DES分离算法），但不要“重新实现已经实现的（专业术语叫重新发明轮子）”。
附录：DES.Model属性值CBCCipher区块链（CBC）模式引入反馈。
每个明文块在加密之前通过按位异或运算与前一个块的密文组合。
这确保了即使明文包含许多相同的块，这些块中的每一个都会被加密成不同的密文块。
在密码块之前，初始化向量通过按位异或运算与第一个明文块组合。
如果密文块中的一位不正确，则相应的明文块也将不正确。
此外，后续块中与原始错误位位于同一位置的位也将是不正确的。
ECB电子密码本(ECB)模式单独加密每个块。
这意味着同一消息中或使用相同密钥加密的另一消息中的任何相同的明文块都将转换为相同的密文块。
如果待加密的明文包含大量重复块，则有可能逐块破解密文。
此外，准备攻击的对手可以在您不知情的情况下替换和切换各个块。
如果密文块中的一位不正确，则相应的整个明文块也将不正确。
OFB输出反馈(OFB)模式将小间隔的明文处理为密文，而不是立即处理整个块。
该模式与CFB类似，两种模式唯一的区别在于移位寄存器的填充方式。
如果密文中的一位错误，则明文中相应的一位也会错误。
但是，如果密文中存在多余或缺失的位，则该位之后的任何明文都将是错误的。
CFB密码反馈(CFB)模式将小增量明文块处理为密文，而不是立即处理整个块。
该模式使用一个块长并分为多个部分的移位寄存器。
例如，如果块大小为8字节，并且一次处理一个字节，则移位寄存器被分为8部分。
如果密文的一位错误，明文的一位错误，移位寄存器就坏了。
这将导致后续步骤的明文出现错误，直到错误位被移出移位寄存器。
CTS密文窃取（CTS）模式可以处理任意长度的明文，并产生长度与明文长度匹配的密文。
对于除最后两个纯文本块之外的所有块，此模式的行为与CBC模式相同。
DES.Padding属性的值为None并且不填充。
PKCS7PKCS#7填充字符串由字节序列组成，每个字节填充字节序列的长度。
空填充字符串由设置为零的字节组成。
ANSIX923ANSIX923填充字符串由字节序列组成，该字节序列的最后一个字节用字节序列的长度填充，其余字节用零填充。
ISO10126ISO10126填充字符串由一个字节序列组成，该字节序列的最后一个字节用字节序列的长度填充，其余字节用随机数据填充。
当模式不同时，解密出来的内密内容是否可以相同？当PaddingMode不同时，解密内容的结尾可以相同（填充结果只涉及最后一个块）所以当任何语言使用相同的Mode和PaddingMode时，加密和解密结果都是相同的（关闭）。
当然也不排除这个）有些语言没有实现所有模式和padding模式），但是基本的都实现了，所以基本上任意两种语言之间的DES都可以达到相同的加解密结果！java和dotnet中的DES显然指的算法是一样的，可以根据需要使用（Java中dotnet中Mode的默认值是不同的，必须指定相同的Mode和PaddingMode，不要两边都用。
默认值，它真的不起作用）