.NET和Java之間的對稱加密

我正在使用第三方平臺創建登錄頁面，這是我使用此特定平臺的業務需求。.NET和Java之間的對稱加密

在我們的網站上調用資源時，我們可以在其頁面上加密數據並通過請求參數將其發送到我的服務器。這是通過AES對稱加密完成的。

我需要指定一個密碼，salt（它必須是一個十六進制值）和一個初始化向量（但是是16個字符）。

他們的後端是一個.NET平臺。我知道這是因爲如果我指定的IV長於預計潛在的例外是：

System.Security.Cryptography.CryptographicException: Specified initialization vector (IV) does not match the block size for this algorithm. Source: mscorlib

因此，例如，在他們最後我註明：

EncryptSymmetric("Hello World","AES","P4ssw0rD","00010203040506070809", "000102030405060708090A0B0C0D0E0F")

出輸入的：純文本，算法，密碼短語，鹽和IV分別。

我得到的值：eg/t9NIMnxmh412jTGCCeQ==

如果我嘗試使用JCE或BouncyCastle的供應商，我得到解密這個在我結束（相同的算法中，傳語，鹽& IV，具有1000次迭代）：2rrRdHwpKGRenw8HKG1dsA==它是完全不同的。

我已經在線查看了許多不同的Java示例，瞭解如何解密AES。其中一個演示如下：http://blogs.msdn.com/b/dotnetinterop/archive/2005/01/24/java-and-net-aes-crypto-interop.aspx

如何解密使用由Java平臺上的.NET框架生成的密碼短語salt和IV的AES對稱加密？

我不一定需要能夠解密加密字符串的內容，如果我可以在java端生成相同的簽名並比較（如果結果是真正生成的是哈希）。

我在生產中使用JDK 1.5，因此我需要使用1.5來完成此操作。作爲一個方面說明，Java中的很多示例需要在java端指定重複計數，但不在.NET端。是否有我需要在java端指定的標準迭代次數與默認的.NET輸出相匹配。

來源

2011-10-24 Dominic

因爲無論編程語言如何，它都應該解密爲相同的值......您是否嘗試用C＃而不是Java解密？用另一種語言構建解密代碼可能僅僅有助於查找任何實施差異。 –

我不是C＃程序員，所以我不知道從哪裏開始。我只是想與這個平臺互動。 – Dominic

您可以使用任何其他語言來嘗試此操作，只要它具有支持AES的加密API即可。另一個想法，也許問題是源機器和目標機器上的純文本的不同編碼？例如。 UTF-8與UTF-16。 –

這一切都取決於如何使用加密的不同部分/參數。

AES用於加密字節。所以你需要將字符串轉換爲字節數組。所以你需要知道用於轉換字符串的編碼。（UTF7，UTF8，...）。

AES中的密鑰有一些固定的大小。所以你需要知道，如何使用正確的比特大小從密碼到AES密鑰。

既然你提供了鹽和IV，我猜鹽不是IV。在.Net中處理Salt沒有標準的方法。據我記得，鹽主要用來防止彩虹桌和哈希。 AES中鹽的需求對我來說是未知的。

也許密碼被哈希（你沒有提供該方法）與鹽來獲得AES密鑰。

四是不是祕密。最簡單的方法是用IV預先加密數據。看到加密數據的長度，情況並非如此。

我不認爲你對.NET的不熟悉是這裏的問題。您需要知道加密的實施者做出的決定，從您的參數到加密的字符串。

來源

2011-10-24 08:40:59 GvS

'我不知道AES中鹽的需求'。也許我誤解了它，但是AES確實和其他分組密碼一樣容易受到彩虹表的攻擊？ –

散列函數總是導致相同數量的字節（散列）。一個獨特的散列結果可以從多個輸入中返回。所以有一組散列結果。如果你從這個集合中得到每個結果，你可以計算一個可能的輸入。這樣你可以建立一個彩虹桌。（Salt用於創建無限數量的結果）對於AES，結果集的大小無限大，因爲每個輸入都會解析爲一個唯一的加密結果。 – GvS

+1。多米尼克需要問他的商業夥伴（即提供第三方網站的商業夥伴）使用了哪一種精確的算法組合。除了漫無目的的猜測之外，沒有辦法解決這個問題。 –

就我所見，它是導致問題的迭代計數。在所有事情都一樣的情況下（salt，IV，迭代），.Net實現產生與Java實現相同的輸出。我想你可能需要問第三方他們正在使用什麼迭代

來源

2011-10-24 08:40:16 flipchart

.NET和Java之間的對稱加密

回答

相關問題