[Webinar] Streamline your web hosting managementRegister Today

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 564
  • Last Modified:

Two AES implementations generated different encryption results

I have an application that uses an opensource "libgcrypt" to encrypt/decrypt a data block (32 bytes). Now I am going to use Microsoft CryptAPI to replace it. My problem is that the libgcrypt and CryptApi approaches generate different ciphertext contents as I use the same AES-256 algorithm in CFB mode, same key (32 bytes), and same IV (16 bytes), although the ciphertexts can be decrypted by their own correspndingly.

Could some one tell me what is the problem? Thanks.
1 Solution
I believe this comes down to different implementations of the algorithm.  

NIST may have a more detailed explanation of why.


More than likely a cause of the random number generator to generate the seed key.
yingchunliAuthor Commented:
By using libgcrypt library, Cipher.InitilizeCipher( Key , KeySize , IV ) is used to init the cipher.
By CryptAPI, the same Key is imported to the CSP, by calling CryptImportKey() and pass the PLAINTEXTKEYBLOB object which holds the key (Key) data.   IV is set by calling CryptSetKeyParam(hKey, KP_IV, IV, 0).
This way, no random generator is used.
Why don't you try some testvector? If the results are different, you can spot the failing library and, maybe, spot the error... http://csrc.nist.gov/groups/STM/cavp/documents/aes/KAT_AES.zip

Featured Post

The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now