des加密net
Ⅰ 求一簡單的 DES加密實例。要c#.net實現！
public sealed class DES
{
private static string iv = "123456789";
private static string key = "12345678"; /// <summary>
/// DES加密偏移量，必須是>=8位長的字元串
/// </summary>
public string IV
{
get { return iv; }
set { iv = value; }
} /// <summary>
/// DES加密的私鑰，必須是8位長的字元串
/// </summary>
///
public string Key
{
get { return key; }
set { key = value; }
} /// <summary>
/// 對字元串進行DES加密
/// </summary>
/// <param name="sourceString">待加密的字元串</param>
/// <returns>加密後的BASE64編碼的字元串</returns> public static string Encrypt(string sourceString)
{
if (sourceString != "")
{
byte[] btKey = Encoding.Default.GetBytes(key);
byte[] btIV = Encoding.Default.GetBytes(iv);
DESCryptoServiceProvider des = new DESCryptoServiceProvider();
using (MemoryStream ms = new MemoryStream())
{
byte[] inData = Encoding.Default.GetBytes(sourceString);
try
{
using (CryptoStream cs = new CryptoStream(ms, des.CreateEncryptor(btKey, btIV), CryptoStreamMode.Write))
{
cs.Write(inData, 0, inData.Length);
cs.FlushFinalBlock();
}
return Convert.ToBase64String(ms.ToArray());
}
catch
{
throw;
}
}
}
else
return "";
} /// <summary>
/// 對DES加密後的字元串進行解密
/// </summary>
/// <param name="encryptedString">待解密的字元串</param>
/// <returns>解密後的字元串</returns> public static string Decrypt(string encryptedString)
{
if (encryptedString != "")
{
byte[] btKey = Encoding.Default.GetBytes(key);
byte[] btIV = Encoding.Default.GetBytes(iv);
DESCryptoServiceProvider des = new DESCryptoServiceProvider();
using (MemoryStream ms = new MemoryStream())
{
byte[] inData = Convert.FromBase64String(encryptedString);
try
{
using (CryptoStream cs = new CryptoStream(ms, des.CreateDecryptor(btKey, btIV), CryptoStreamMode.Write))
{
cs.Write(inData, 0, inData.Length);
cs.FlushFinalBlock();
}
return Encoding.Default.GetString(ms.ToArray());
}
catch
{
throw;
}
}
}
else
return "";
}}
Ⅱ 關於ASP.NET中的DES加密
當你執行到 des.Key=b;時 des.Key才被賦值，
所以當你使用 des.Key[i] = Convert.ToByte(temkey[i]);時
des.Key應該為null，當然會報錯了。
你如果硬要用你注釋掉的寫法的話，
改成這樣：
des.Key= new byte[8];
des.Key[i] = Convert.ToByte(temkey[i]);
Ⅲ net des加密java怎麼解密
遵循兩個原則:
1) 演算法的獨立性和可靠性。
2) 實現的獨立性和相互作用性。
演算法的獨立性是通過定義密碼服務類來獲得。用戶只需了解密碼演算法的概念,而不用去關心如何實現這些概念。實現的獨立性和相互作用性通過密碼服務提供器來實現。密碼服務提供器是實現一個或多個密碼服務的一個或多個程序包。軟體開發商根據一定介面,將各種演算法實現後,打包成一個提供器,用戶可以安裝不同的提供器。安裝和配置提供器,可將包含提供器的ZIP和JAR文件放在CLASSPATH下,再編輯Java安全屬性文件來設置定義一個提供器。
DES演算法及如何利用DES演算法加密和解密類文件的步驟：
DES演算法簡介
DES（Data Encryption Standard）是發明最早的最廣泛使用的分組對稱加密演算法。DES演算法的入口參數有三個：Key、Data、Mode。其中Key為8個位元組共64位，是DES演算法的工作密鑰；Data也為8個位元組64位，是要被加密或被解密的數據；Mode為DES的工作方式，有兩種：加密或解密。
Ⅳ C# .net 加密與解密 DES
Ⅳ 使用.net內置的DES進行加密
好了，明白了它的License種類，我們得看看它是如何驗證合法的License的，換句話說就是它的License是如何構成的。它通過定位/bin目錄下的License文件，License文件由類名(FreeTextBox)+ 「.lic」構成。FreeTextBox.Lic文件內容分三個部分，第一部分為明文FreeTextBox License，也就是類名+ License」字元串，第二部分為[License種類的加密文本]，加密演算法採用的.NET內置的DES，用於DES加密的密鑰和偏移量均為{ 0x39, 0x48, 0x42, 50, 0x38, 0x31, 70, 0x36 }，當然它不是直接對文本加密的，做了一個小小的處理，這個處理就是加上原文本的長度，並預留5位，不夠則補零,例如字元串DistributionLicense，那用於加密的就是00019DistributionLicense，因為字元串DistributionLicense的長度是19位，前面還有3個空位就補3個零。這樣加密後的結果就是=，注意需要用[]分隔，FreeTextBox設計者出於方便使用正則匹配所以使用[]來分隔，第三部分就是你注冊標識的加密文本，當然也有[]，處理方式跟第二部分的一樣，例如我的域名為Ycweb.Net，我想以此作為標識來生成License，於是對字元串00009Ycweb.Net進行DES加密，結果為tyn3Gf1Y5GH2VphAJ2U++g==，所以綜合這個三個部分的內容，就構成了一個完整的License文件內容，整理一下就是： FreeTextBox License [=] [tyn3Gf1Y5GH2VphAJ2U++g==] 這是Distribution的License，如果是Professional的License，內容就是： FreeTextBox License [tyn3Gf1Y5GH2VphAJ2U++g==] 補充： 我現在是要加密的方法，求一個函數，將原文：00019DistributionLicense，加密為密文：=]，不知所謂，連內容都不看就回答了 補充： 又多一個不看內容的，文章裡面不是說了嗎：
Ⅵ Java和.NET使用DES對稱加密的區別
沒有區別，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中實現的類庫默認值有什麼不同」才對。
Ⅶ 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才可以的，不要雙方都採用默認值，那樣真的通不起來）
Ⅷ JAVA和.NET使用DES對稱加密的區別
DES加密演算法原理：DES 使用一個 56 位的密鑰以及附加的 8 位奇偶校驗位（每組的第8位作為奇偶校驗位），產生最大 64 位的分組大小。這是一個迭代的分組密碼，使用稱為 Feistel 的技術，其中將加密的文本塊分成兩半。使用子密鑰對其中一半應用循環功能，然後將輸出與另一半進行「異或」運算；接著交換這兩半，這一過程會繼續下去，但最後一個循環不交換。DES 使用 16 輪循環，使用異或，置換，代換，移位操作四種基本運算。
.NET中的DES加密：
對於.NET，框架在System.Security.Cryptography命名空間下提供了DESCryptoServiceProvider作為System.Security.Cryptography.DES加密解密的包裝介面，它提供了如下的4個方法：
public override ICryptoTransform CreateDecryptor(byte[] rgbKey, byte[] rgbIV)
public override ICryptoTransform CreateEncryptor(byte[] rgbKey, byte[] rgbIV)
public override void GenerateIV()
public override void GenerateKey()
從.NET類庫封裝情況，加解密需要傳入一個Key和IV向量。而且Key必須為8位元組的數據，否則會直接拋異常出來，當使用ECB模式下，不管傳入什麼IV向量，加密結果都一樣
JAVA中的DES加密：
JAVA的javax.crypto.Cipher包下，提供了加密解密的功能，它的靜態getInstance方法，可以返回一個Cipher對象，一般有public static final Cipher getInstance(String transformation)方法，transformation為：algorithm/mode/padding，分別表示演算法名稱，比如DES，也可以在後麵包含演算法模式和填充方式，但也可以只是演算法名稱，如為："DES/CBC/PKCS5Padding"，"DES"等。JAVA中默認的演算法為ECB，默認填充方式為PKCS5Padding。Cipher的Init方法用來初始化加密對象，常見的有：
public final void init(int opmode, Key key, AlgorithmParameterSpec params) ，
public final void init(int opmode,Key key, SecureRandom random)，用SecureRandom時，一般用於不需要IV的演算法模式
總結
對於.NET和JAVA在使用DES對稱加密時，需要大家指定一樣的演算法和填充模式，並且JAVA在寫DES加解密演算法時，還需要根據創建Cipher對象的不同，正確使用IV向量。在不同系統需要互相數據時，必須要明確的是加密演算法，Key和演算法模式，再根據不同模式是否需要IV向量，最後是填充模式。
Ⅸ JAVA和.NET使用DES對稱加密的區別
JAVA和.NET的系統類庫里都有封裝DES對稱加密的實現方式，但是對外暴露的介面卻各不相同，甚至有時會讓自己難以解決其中的問題，比如JAVA加密後的結果在.NET中解密不出來等。
沒區別,演算法是標準的 不過,演算法的入參和出餐都是 byte[],你要自己轉換,在轉換過程中可能會出現不一致的情況。
Ⅹ JAVA和.NET使用DES對稱加密的區別
JAVA和.NET的系統類庫里都有封裝DES對稱加密的實現方式，但是對外暴露的介面卻各不相同，甚至有時會讓自己難以解決其中的問題，比如JAVA加密後的結果在.NET中解密不出來等，由於最近項目有跨JAVA和.NET的加解密，經過我的分析調試，終於讓它們可以互相加密解密了。
DES加密
DES是一種對稱加密(Data Encryption Standard)演算法，以前我寫過一篇文章：.NET中加密解密相關知識，有過簡單描述。
DES演算法一般有兩個關鍵點，第一個是加密演算法，第二個是數據補位。
加密演算法常見的有ECB模式和CBC模式：
ECB模式：電子密本方式，這是JAVA封裝的DES演算法的默認模式，就是將數據按照8個位元組一段進行DES加密或解密得到一段8個位元組的密文或者明文，最後一段不足8個位元組，則補足8個位元組（注意：這里就涉及到數據補位了）進行計算，之後按照順序將計算所得的數據連在一起即可，各段數據之間互不影響。
CBC模式：密文分組鏈接方式，這是.NET封裝的DES演算法的默認模式，它比較麻煩，加密步驟如下：
1、首先將數據按照8個位元組一組進行分組得到D1D2......Dn（若數據不是8的整數倍，就涉及到數據補位了）
2、第一組數據D1與向量I異或後的結果進行DES加密得到第一組密文C1（注意：這里有向量I的說法，ECB模式下沒有使用向量I）
3、第二組數據D2與第一組的加密結果C1異或以後的結果進行DES加密，得到第二組密文C2
4、之後的數據以此類推，得到Cn
5、按順序連為C1C2C3......Cn即為加密結果。
數據補位一般有NoPadding和PKCS7Padding(JAVA中是PKCS5Padding)填充方式，PKCS7Padding和PKCS5Padding實際只是協議不一樣，根據相關資料說明：PKCS5Padding明確定義了加密塊是8位元組，PKCS7Padding加密快可以是1-255之間。但是封裝的DES演算法默認都是8位元組，所以可以認為他們一樣。數據補位實際是在數據不滿8位元組的倍數，才補充到8位元組的倍數的填充過程。
NoPadding填充方式：演算法本身不填充，比如.NET的padding提供了有None，Zeros方式，分別為不填充和填充0的方式。
PKCS7Padding（PKCS5Padding）填充方式：為.NET和JAVA的默認填充方式，對加密數據位元組長度對8取余為r，如r大於0，則補8-r個位元組，位元組為8-r的值；如果r等於0，則補8個位元組8。比如：
加密字元串為為AAA，則補位為AAA55555;加密字元串為BBBBBB，則補位為BBBBBB22；加密字元串為CCCCCCCC，則補位為CCCCCCCC88888888。