AES128 bit encryption string is not similar as on .net

I am Implementing the AES128 bit encryption/Decryption in iOS application for sending/receiving data from .net server, I almost done but during unit testing I got some issue in encryption string, some encrypted string are not similar as on .net server, Can say 98 percent strings are correct at both side but issue comes in 2 percent strings , when I match the both side encrypted string then found at iOS end generated string is little short and .net end it is long string. One more thing i found the iOS string is the substring of .net string. When i tried to decrypt the iOS generated encrypted string, it is not decrypted showing null but when I try to decrypt the .net server generated encrypted string (it was larger than the iOS) I am able to se the decrypted string.

Using the same KEY(16 character long at server and iOS end).

  • AES gets different results in iOS (Obj-C) and Android (Java)
  • send push notification to Iphone from asp.net C#
  • AES string encryption in Objective-C
  • SignalR .Net Client fails with 500 server error on device, on simulator works fine
  • Get Variable from httpcontext coming from NSUrlRequest
  • AES encryption makes different result in iOS and Android
  • could you please suggest the solution or where I am wrong .

    Thanks a lot to all.

    Original string: “custId=10&mode=1”
    KEY= “PasswordPassword”

    at iOS encrypted string:
    r51TbJpBLYDkcPC+Ei6Rmg==

    at .net encrpted string:
    r51TbJpBLYDkcPC+Ei6RmtY2fuzv3RsHzsXt/RpFxAs=

    padding for encryption = kCCOptionPKCS7Padding;

    I followed this tutorial.
    http://automagical.rationalmind.net/2009/02/12/aes-interoperability-between-net-and-iphone/

    2 Solutions Collect From Internet About “AES128 bit encryption string is not similar as on .net”

    A similar question found on CryptoSE

    My Version TL;DR

    Essentially .net and iOS both have different implementations, and since the guide you are following is from 2009 I would expect that it is rather out of date by now given there have been at least 1 major revision bump in each of the platforms since then.

    Original Answer Gives the following answer:

    I can immediately think of four reasons:

    1. They’re both not using AES256. I see in the Obj-C document a direct statement that they are using AES256 (unless you deliberately change it), I don’t see any statement in the Visual Basic document that says what key size they’re using (unless that’s what they mean by “Block Bits”).

    2. Different keys. AES256 takes a key of 256 bits; there’s no standard method to take a five character string and convert that into a 256 bit value. Now, there are a lot of possible methods; there’s no particular assurance that they both use the same one.

    3. Different modes of operation. The AES block cipher takes 128-bit values, and translates that into 128-bit values. However, not all our messages can fit into 128 bits, and in addition, sometimes there are other things we’d like to do other than message encryption. A Mode of Operation is a method that takes a block cipher, and uses it as a tool to perform some more generally useful function (such as encrypting a much longer message). There are a number of standard modes of operations, the Obj-C document states that it is using CBC mode; the Visual Basic document has scary sounding words which might be a garbled explination of CBC mode.

    4. IVs. Some modes of operation (such as CBC mode) have the encryptor select an “Initialization Vector” randomly; that can be translated along with the encrypted message (because the decryptor will need that value). One of the things that this Initialization Vector does if you encrypt the message a second time, the second ciphertext will not resemble the first ciphertext at all; that way, someone listening will not be able to deduce that you’ve just repeated a message. The Obj-C document specifically says that it will pick a random IV (unless to tell give it one yourself).

    5. As you can see, there are a bunch of reasons why the two ciphertexts may be different. One thing you can try: hand the ciphertext from one to the other, and ask them to decrypt it; if they can, you can be pretty sure that both sides are doing basically the same thing.


    As you can see, there are a bunch of reasons why the two ciphertexts may be different. One thing you can try: hand the ciphertext from one to the other, and ask them to decrypt it; if they can, you can be pretty sure that both sides are doing basically the same thing.