Encrypt and decrypt a string in C# and C++ RRS feed

  • Question

  • Hello,

    I would like to encrypt and decrypt a string in C# and C++ Qt. I know there is AES256, but when I use some code from AES256 in C# and C++ Qt, I have different result for the encryption of the string, but the decryption is correct.

    So I wonder how with a different result of encryption, we obtain a good decryption, it is very strange for me.

    So, I would want to know if there is a good alternative in C# and C++ Qt to encrypt end decrypt a string without using AES256?


    • Edited by speed780 Friday, October 23, 2020 11:43 PM correction
    Friday, October 23, 2020 10:48 PM

All replies

  • A way to encrypt strings is with CryptProtectMemory
    Saturday, October 24, 2020 7:41 AM
  • So I wonder how with a different result of encryption, we obtain a good decryption, it is very strange for me.

    If I remember right, AES Cryptography has several options for PADDING during Encryption.  Padding just extends the length of the encrypted data to meet a boundary - I think the boundary is the same size as whatever your cryptographic buffer size is (ie 128 bits aka 16 bytes or 256 bits aka 32 bytes or etc).  What this means is that the file will have another value appended until the total file size is evenly divisible by whatever number, so you never have empty space at the end of a buffer in decryption.  Such padding can be all 00s (which I think is default in DotNET's AES engine) or it can be PKCS7 which goes 01 02 03 04 and etc until the total file size (or the last encrypting buffer data) meets the boundary.

    The "experts" used to tout that this was as good as salting the cryptography!!!  Then some enterprising black or grey hats figured out that if an encrypted file size meets such a boundary, it's a lot easier to decrypt the last few bytes since you know that they're either 00 00 00 00 or else 01 02 03 04.  So much for adding to the value of the cryptography!!! This bit isn't relevant to your issue - it's just information.

    Then after that, any AES decryption algorithm should be starting at the front using your supplied password, and if it encounters 00 or PCKS7 padding at the end it should drop that data from any output.

    My guess is that you get different output when encrypting with each engine because we know DotNET wants to pad with 00, and that other engine probably doesn't pad at all.  You can explicitly tell DotNET to use PADDING_NONE when you instantiate your crypto engine or maybe when you call the actual encrypt method, and doing so will most likely make your encryption output look the same on both.

    So that's why you're seeing different output from encryption on the two engines, but either engine can still decrypt the other's output.

    Before you can learn anything new you have to learn that there's stuff you don't know.

    Saturday, October 24, 2020 12:19 PM
  • So I wonder how with a different result of encryption, we obtain a good decryption, it is very strange for me.

    This is done on purpose for security, so that the same message encoded twice results in two different encoded messages, so that any attacker looking at the encrypted data cannot infer that the same message has been sent twice.

    So, how is this done? This is achieved by means of the Initialization Vector (IV). If you look at the encryption libraries for AES you will see that they take two input parameters, the IV and the Key. Both parameters are required for decryption, and the encrypted message varies if either the IV or the Key are different. The Key is secret, and you need to know it for decryption.

    The IV is not secret. It is generated at random when starting encryption, and it is saved at the beginning of the encrypted message.

    During decryption, the first thing to be read from the message to decrypt is the IV. Then this IV, along with the secret Key, are used to decrypt the rest of the message.

    In this way, a message encrypted twice is different thanks to the IV that is generated each time at random. And the rest of the message is different because it depends on the IV, which is different. And the different messages can be decrypted into the original plaintext because the IV is included at the beginning of the message.

    Saturday, October 24, 2020 2:28 PM
  • Hi speed780,
    For your question, a detailed explanation has been given above.
    Here are more discussions about encrypting and decrypting strings in C#, and  hope these are helpful to you.
    [Encrypting & Decrypting a String in C# [duplicate]]
    [Encrypt and decrypt a string in C#?]
    Best Regards,
    Daniel Zhang

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, October 26, 2020 2:44 AM
  • Hi Speed,

    In case you are interested in a real-world type of scenario, I wrote a blog post last year about encryption. It's overkill for what you're asking about, but you might find it interesting anyway: https://geek-goddess-bonnie.blogspot.com/2019/01/encryption-for-messaging-exchange.html

    ~~Bonnie DeWitt [C# MVP]


    Monday, October 26, 2020 3:30 PM