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才可以的，不要雙方都採用默認值，那樣真的通不起來）