des算法java
没有区别，DES只是加密的一种算法，Java与.NET语言中只是对这种算法的实现，所以两者是没有任何区别的。算法与密钥本来就是分开的，算法本来就是公开的，语言只是对这种算法的实现而已，在这种情况下DES与语言没有任何相关性，只有自己的算法标准。
但很多人反映的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中实现的类库默认值有什么不同”才对。
2. java加密的几种方式
朋友你好，很高兴为你作答。
首先，Java加密能够应对的风险包括以下几个：
1、核心技术窃取
2、核心业务破解
3、通信模块破解
4、API接口暴露
本人正在使用几维安全Java加密方式，很不错，向你推荐，希望能够帮助到你。
几维安全Java2C针对DEX文件进行加密保护，将DEX文件中标记的Java代码翻译为C代码，编译成加固后的SO文件。默认情况只加密activity中的onCreate函数，如果开发者想加密其它类和方法，只需对相关类或函数添加标记代码，在APK加密时会自动对标记的代码进行加密处理。
与传统的APP加固方案相比，不涉及到自定义修改DEX文件的加载方式，所以其兼容性非常好；其次Java函数被完全转化为C函数，直接在Native层执行，不存在Java层解密执行的步骤，其性能和执行效率更优。
如果操作上有不明白的地方，可以联系技术支持人员帮你完成Java加密。
希望以上解答能够帮助到你。
3. java 中使用DES加密算法 生产的密钥为啥是8个字节
使用DES加密算法生产密钥，java6对DES算法仅支持56位密钥长度，但生成的密钥是64位的.在这64位中，实际的密钥只有56位，另有8位是奇偶校验位，分布灶森悄于64位密钥中，每隐渣8位中春码有1 位奇偶检验位.
4. 用java实现des加密和解密
一个用DES来加密、解密的类
http://www.javanb.com/java/1/17816.html
import java.security.*;
import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.DESKeySpec;
/**
* 字符串工具集合
* @author Liudong
*/
public class StringUtils {
private static final String PASSWORD_CRYPT_KEY = "__jDlog_";
private final static String DES = "DES";
/**
* 加密
* @param src 数据源
* @param key 密钥，长度必须是8的倍数
* @return 返回加密后的数据
* @throws Exception
*/
public static byte[] encrypt(byte[] src, byte[] key)throws Exception {
//DES算法要求有一个可信任的随机数源
SecureRandom sr = new SecureRandom();
// 从原始密匙数据创建DESKeySpec对象
DESKeySpec dks = new DESKeySpec(key);
// 创建一个密匙工厂，然后用它把DESKeySpec转换成
// 一个SecretKey对象
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance(DES);
SecretKey securekey = keyFactory.generateSecret(dks);
// Cipher对象实际完成加密操作
Cipher cipher = Cipher.getInstance(DES);
// 用密匙初始化Cipher对象
cipher.init(Cipher.ENCRYPT_MODE, securekey, sr);
// 现在，获取数据并加密
// 正式执行加密操作
return cipher.doFinal(src);
}
/**
* 解密
* @param src 数据源
* @param key 密钥，长度必须是8的倍数
* @return 返回解密后的原始数据
* @throws Exception
*/
public static byte[] decrypt(byte[] src, byte[] key)throws Exception {
// DES算法要求有一个可信任的随机数源
SecureRandom sr = new SecureRandom();
// 从原始密匙数据创建一个DESKeySpec对象
DESKeySpec dks = new DESKeySpec(key);
// 创建一个密匙工厂，然后用它把DESKeySpec对象转换成
// 一个SecretKey对象
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance(DES);
SecretKey securekey = keyFactory.generateSecret(dks);
// Cipher对象实际完成解密操作
Cipher cipher = Cipher.getInstance(DES);
// 用密匙初始化Cipher对象
cipher.init(Cipher.DECRYPT_MODE, securekey, sr);
// 现在，获取数据并解密
// 正式执行解密操作
return cipher.doFinal(src);
}
/**
* 密码解密
* @param data
* @return
* @throws Exception
*/
public final static String decrypt(String data){
try {
return new String(decrypt(hex2byte(data.getBytes()),
PASSWORD_CRYPT_KEY.getBytes()));
}catch(Exception e) {
}
return null;
}
/**
* 密码加密
* @param password
* @return
* @throws Exception
*/
public final static String encrypt(String password){
try {
return byte2hex(encrypt(password.getBytes(),PASSWORD_CRYPT_KEY.getBytes())); }catch(Exception e) {
}
return null;
}
比较长, 转了一部分.
5. JAVA和.NET使用DES对称加密的区别
如果我说没有区别你会信吗？
但答案还真是这样，两者没有任何区别的，只不过实现的语言代码不同而已。
那么java与dot net之间的DES是否可以通用？答案也是完全通用。无论是Java的DES加密还是dot net的DES回密，均可以使用另一种语言且不限于Java或dot net解密。够明白吗？
DES其实只是一个算法，加密与解密我们都知道算法与密码是分离的。算法是公开的，都可以用，而密码是独立于算法的。所以DES在不同的语言中实现的算法根本就是一样的——也正是因为如此不管何种语言都是通用的（除非伪DES，要知道DES算法网上本身能搜到而且是一个标准，最先是由美国安全部门公开的）
再说一下，为什么有人“通”用不起来的原因。DES其实有CBC之类的参数的，也就是针对加密块选用的不同的加密手段。正是这个参数的原因，不同的语言中使用不同的参数做为默认值，所以使用默认的方式进行让两个串进行加解密肯定是不同的。DES使用一种模式（方法）加密，用另一种模式(方法）进行解密能得到正确的结果吗？一些人不怪自己的学艺不精，反说是两种语言的DES不通用（这也就是为什么网络上会出现诸多说java和dot net的DES加密方法不通用的原因）。
即便是自己使用的DES加密的代码也是通用的（前提你要遵守DES分开算法），但不要“重复实现已经实现的东西（专业术语叫造轮子）”。
附：
DES.Model属性取值
CBC 密码块链 (CBC) 模式引入了反馈。每个纯文本块在加密前，通过按位“异或”操作与前一个块的密码文本结合。这样确保了即使纯文本包含许多相同的块，这些块中的每一个也会加密为不同的密码文本块。在加密块之前，初始化向量通过按位“异或”操作与第一个纯文本块结合。如果密码文本块中有一个位出错，相应的纯文本块也将出错。此外，后面的块中与原出错位的位置相同的位也将出错。
ECB 电子密码本 (ECB) 模式分别加密每个块。这意味着任何纯文本块只要相同并且在同一消息中，或者在用相同的密钥加密的不同消息中，都将被转换成同样的密码文本块。如果要加密的纯文本包含大量重复的块，则逐块破解密码文本是可行的。另外，随时准备攻击的对手可能在您没有察觉的情况下替代和交换个别的块。如果密码文本块中有一个位出错，相应的整个纯文本块也将出错。
OFB 输出反馈 (OFB) 模式将少量递增的纯文本处理成密码文本，而不是一次处理整个块。此模式与 CFB 相似；这两种模式的唯一差别是移位寄存器的填充方式不同。如果密码文本中有一个位出错，纯文本中相应的位也将出错。但是，如果密码文本中有多余或者缺少的位，则那个位之后的纯文本都将出错。
CFB 密码反馈 (CFB) 模式将少量递增的纯文本处理成密码文本，而不是一次处理整个块。该模式使用在长度上为一个块且被分为几部分的移位寄存器。例如，如果块大小为 8 个字节，并且每次处理一个字节，则移位寄存器被分为 8 个部分。如果密码文本中有一个位出错，则一个纯文本位出错，并且移位寄存器损坏。这将导致接下来若干次递增的纯文本出错，直到出错位从移位寄存器中移出为止。
CTS 密码文本窃用 (CTS) 模式处理任何长度的纯文本并产生长度与纯文本长度匹配的密码文本。除了最后两个纯文本块外，对于所有其他块，此模式与 CBC 模式的行为相同。
DES.Padding属性的取值
None 不填充。
PKCS7 PKCS #7 填充字符串由一个字节序列组成，每个字节填充该字节序列的长度。
Zeros 填充字符串由设置为零的字节组成。
ANSIX923 ANSIX923 填充字符串由一个字节序列组成，此字节序列的最后一个字节填充字节序列的长度，其余字节均填充数字零。
ISO10126 ISO10126 填充字符串由一个字节序列组成，此字节序列的最后一个字节填充字节序列的长度，其余字节填充随机数据。
当Mode不同时，解密的内密内容能与相同吗？PaddingMode不同时，解密的内容的结尾部分能相同吗（填充结果只涉及到最后的一个块）.所以当不管何种语言使用相同的Mode及PaddingMode时，加解密的结果是相同的（当然不排除部分语言不实现全部的Mode和PaddingMode)但，基本的都是实现了的，所以基本上任何两种语言之间的DES都可以实现相同的加解密结果！而java和dot net中的DES显然指的是算法，两者是相同的，可以随意使用（Java中dot net中的Mode默认值是不同的，一定要设置相同的Mode和PaddingMode才可以的，不要双方都采用默认值，那样真的通不起来）