.NET和Java之间的对称加密

时间:2011-10-24 08:08:22

标签: java .net encryption aes encryption-symmetric

我正在使用第三方平台创建目标网页,我使用此特定平台是一项业务要求。

在他们的页面上,我可以在我的网站上调用资源时通过请求参数加密数据并将其发送到我的服务器。这是通过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==这是完全不同的。

我已经在线查看了许多关于如何解密AES的Java示例。其中一个演示如下:http://blogs.msdn.com/b/dotnetinterop/archive/2005/01/24/java-and-net-aes-crypto-interop.aspx

如何解密使用由Java平台上的.NET框架生成的密码短语,salt和IV的AES对称加密?

如果我可以在java端生成相同的签名并进行比较(如果事实证明这里真正生成的是哈希),我不一定能够解密加密字符串的内容。 / p>

我在生产中使用JDK 1.5,因此我需要使用1.5来执行此操作。

作为旁注,Java中的很多示例需要在java端指定重复计数,但不在.NET端指定。是否需要在java端指定与标准.NET输出匹配的标准迭代次数。

2 个答案:

答案 0 :(得分:2)

这完全取决于如何使用加密的不同部分/参数。

AES用于加密字节。所以你需要将字符串转换为字节数组。所以你需要知道用于转换字符串的编码。 (UTF7,UTF8,......)。

AES中的密钥有一些固定的大小。因此,您需要知道如何使用正确的bitsize从密码短语到AES密钥。

既然你提供盐和Ⅳ,我想盐不是Ⅳ。在.Net中没有标准的方法来处理Salt。据我记得,盐主要用于防止彩虹桌和哈希。我不知道在AES中需要使用盐。

也许使用salt来对密码进行哈希处理(您没有提供相应的方法)来获取AES密钥。

IV并不是秘密。最简单的方法是使用IV预先加密数据。看到加密数据的长度,情况并非如此。

我不认为您对.Net的不熟悉是问题所在。您需要知道加密实施者做出的决定,从您的参数到加密字符串。

答案 1 :(得分:1)

据我所知,这是造成问题的迭代计数。在所有事情相同的情况下(salt,IV,iterations),.Net实现生成与Java实现相同的输出。我想你可能需要问第三方他们正在使用什么迭代