.NET和Java之间的对称加密 [英] Symmetric Encryption between .NET and Java

问题描述

我正在使用第三方平台创建目标网页，这是一个业务需求，我使用这个特定的平台。

在他们的页面上，我可以加密数据，并在调用网站上的资源时通过请求参数将其发送到我的服务器。这是通过AES对称加密完成的。

我需要指定一个密码，salt（它必须是十六进制值）和初始化向量（但是是16个字符） 。

他们的后端是一个.NET平台。我知道这是因为如果我指定一个IV长于它所期望的底层异常：

System.Security.Cryptography.CryptographicException：指定的初始化向量（IV）与该算法的块大小不匹配。
资料来源：mscorlib

所以例如，在他们的最后指定：

$ b $加密对称（Hello World，AES，P4ssw0rD，00010203040506070809，000102030405060708090A0B0C0D0E0F）

输入分别为：纯文本，算法，密码，盐和IV。

我得到的值： eg / t9NIMnxmh412jTGCCeQ ==

如果我尝试使用JCE或BouncyCastle提供程序尝试解密这个问题，我得到（相同的算法，通过短语，salt和amp; IV，1000次迭代）： 2rrRdHwpKGRenw8HKG1dsA == 这是完全不同的。

我已经在线阅读了许多不同的Java示例，说明如何解密AES。一个这样的演示如下： http://blogs.msdn.com/b/dotnetinterop/archive/2005/01/24/java-and-net-aes-crypto-interop.aspx

如何解密AES对称加密，它使用Java平台上.NET框架生成的密码，salt和IV？

如果我可以在java端生成相同的签名并进行比较，那么我不一定需要解密加密字符串的内容（如果结果）这里真正的生成是一个哈希）。

我在生产中使用JDK 1.5，所以我需要使用1.5来做到这一点。

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

解决方案

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

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

AES中的密钥有一些固定的大小。所以你需要知道，如何使用正确的bitize从密码短语到AES密钥。

既然你提供盐和Ⅳ，我想盐不是四。在.Net中没有处理Salt的标准方法。据我所知，盐主要用于防止彩虹台和散沙。 AES中的Salt的需要是我不知道的。

也许密码是散列的（你没有提供方法）与盐获得AES密钥。

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

我不认为你不熟悉.Net是这里的问题。你需要知道加密实现者做出什么决定，从你的参数到加密的字符串。

I am using a 3rd party platform to create a landing page, it is a business requirement that I use this particular platform.

On their page I can encrypt data and send it to my server through a request parameter when calling a resource on my site. This is done through an AES Symmetric Encryption.

I need to specify a password, salt (which must be a hex value) and an initialization vector (but be 16 characters).

Their backend is a .NET platform. I know this because if I specify an IV longer than it expects the underlying exception is:

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

So for example, on their end I specify:

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

Where the inputs are: plain text, algorithm, pass phrase, salt, and IV respectively.

I get the value: eg/t9NIMnxmh412jTGCCeQ==

If I try and decrypt this on my end using the JCE or the BouncyCastle provider I get (same algo,pass phrase, salt & IV, with 1000 iterations): 2rrRdHwpKGRenw8HKG1dsA== which is completely different.

I have looked at many different Java examples online on how to decrypt AES. One such demo is the following: http://blogs.msdn.com/b/dotnetinterop/archive/2005/01/24/java-and-net-aes-crypto-interop.aspx

How can I decrypt a AES Symmetric Encryption that uses a pass phrase, salt and IV, which was generated by the .NET framework on a Java platform?

I don't necessarily need to be able to decrypt the contents of the encryption string if I can generate the same signature on the java side and compare (if it turns out what is really being generated here is a hash).

I'm using JDK 1.5 in production so I need to use 1.5 to do this.

As a side note, a lot of the example in Java need to specify an repetition count on the java side, but not on the .NET side. Is there a standard number of iterations I need to specify on the java side which matches the default .NET output.

解决方案

It all depends on how the different parts/arguments of the encryption are used.

AES is used to encrypt bytes. So you need to convert the string to a byte array. So you need to know the encoding used to convert the string. (UTF7, UTF8, ...).

The key in AES has some fixed sizes. So you need to know, how to come from a passphrase to an AES key with the correct bitsize.

Since you provide both salt and IV, I suppose the salt is not the IV. There is no standard way to handle the Salt in .Net. As far as I remember a salt is mainly used to protect against rainbow tables and hashes. The need of a Salt in AES is unknown to me.

Maybe the passphrase is hashed (you did not provide the method for that) with the salt to get an AES key.

The IV is no secret. The easiest method is to prepend the encrypted data with the IV. Seen the length of the encrypted data, this is not the case.

I don't think your unfamiliarity of .Net is the problem here. You need to know what decisions the implementer of the encryption made, to come from your parameters to the encrypted string.

这篇关于.NET和Java之间的对称加密的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！