3

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.

Dominic
  • 1,294
  • 1
  • 15
  • 29
  • Since it should decrypt to the same value regardless of programming language... have you tried decrypting it with C# instead of Java? Building the decryption code in another language might just help to locate any implementation differences. – S.L. Barth is on codidact.com Oct 24 '11 at 08:27
  • I'm not a C# programmer, so I wouldn't know where to start. I'm just trying to interact with this other platform. – Dominic Oct 24 '11 at 08:29
  • You could use any other language to try this, as long as it has a crypto API that supports AES. Another thought, maybe the problem is a different encoding of the plaintext on the source machine and the target machine? E.g. UTF-8 vs UTF-16. – S.L. Barth is on codidact.com Oct 24 '11 at 08:38

2 Answers2

2

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.

GvS
  • 52,015
  • 16
  • 101
  • 139
  • 'The need of a salt in AES is unknown to me'. Maybe I'm misunderstanding it, but surely AES is as vulnerable to rainbow tables as any other block cipher? – S.L. Barth is on codidact.com Oct 24 '11 at 10:06
  • A hash-function always results in the same number of bytes (the hash). One unique hash result, can be returned from multiple inputs. So there is a limited set of results from a hash. If you take every result from this set, you can calculate a possible input. This way you can build a rainbow table. (Salt is used to create an infinite number of results) For AES the result set is infinite in size, because every input will resolve to one unique encrypted result. – GvS Oct 24 '11 at 10:17
  • 1
    +1. Dominic needs to ask his business partner (i.e. the one providing the third party site) which exact algorithm combination is used. There is no way around this, other than aimless guessing. – Paŭlo Ebermann Oct 24 '11 at 12:16
  • I would guess that they are using a salted hash to generate the key from the pass phrase and that is where the salt comes in. You might be a able to probe it by passing a NULL or unexpected value and look at the stack trace from the exception that is thrown. – Yaur Nov 04 '11 at 22:55
1

As far as I can see, it is the iteration count which is causing the issue. With all things the same (salt,IV,iterations), the .Net implementation generates the same output as the Java implementation. I think you may need to ask the 3rd party what iterations they are using

flipchart
  • 6,548
  • 4
  • 28
  • 53