2

The goal

We’ve been using EasyByte’s Cryptocx library to encrypt documents using AES256. The library is 32-bit and is preventing us from building a 64-bit version of our application. EasyByte went out of business and there’s no 64-bit version, source code or support for the library.

We’d like to use Chilkat’s 64-bit ActiveX component to be able to decrypt the documents directly. Migrating all our customer’s documents by decrypting and re-encrypting them would be a huge cost.

I’m trying to infer the mode of operation (ECB, CBC…) so that I can send Chilkat the right parameters. The Cryptocx method we’re using only accepts the source and destination files and a string password:

http://www.easybyte.com/support/cryptocx/aesfileencrypt.html

What I tried

I don’t have a strong background in cryptography, but this is what I tried.

A 64-byte input file (4 blocks in AES) filled with As (hex 41). A 32-character string for the password, also filled with As. By calling the previous method to encrypt several times (same file, same password) and using a hex editor I can observe that files have five 16-byte blocks in the encrypted file.

The first four blocks are identical and the fifth differs. Is this the initialization vector being stored in the file? If it is and it’s different in all the files, shouldn’t the first four blocks also be different?

Assuming it was CBC (since the Wikipedia article claims it’s the most used) I tried removing the last 16 bytes from the file (using a hex editor) and using them as the IV to decrypt the file.

But I didn’t get the expected clear text.

Some code

This is the code I tried, in VB.net:

Dim chilkat As ChilkatCrypt2 = New ChilkatCrypt2

chilkat.UnlockComponent(licenseKey)
chilkat.CryptAlgorithm = "aes"
chilkat.KeyLength = 256
chilkat.CipherMode = "cbc"
chilkat.SetEncodedKey("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", "ascii")
chilkat.SetEncodedIV("36cd36dae64316e80d50871e3b26b4bb", "hex")

Dim result = chilkat.CkDecryptFile(pathToEncryptedFile, pathToDecryptedFile)

If result = 0 Then
    Console.WriteLine(chilkat.LastErrorText)
    Console.ReadLine()
End If

I would appreciate some direction. Can the right parameters even be inferred from the output without knowing the implementation details?

Thanks a lot.

fergroops
  • 111
  • 2
  • 7
  • *...The first four blocks are identical and the fifth differs...* Then it's using ECB mode, not CBC, and it is probably using PKCS7 padding which would account for the fifth block. Not very secure. – President James K. Polk Jun 25 '20 at 18:18
  • I suspect the hardest part will be figuring out what algorithm EasyBytes uses to derive a 256 bit key from a password. Given that the code uses ECB mode and does not seem to have a salt I'd guess it does something pretty simple, like using the first 32 bytes of the ASCII encoding and throwing the rest away. Or, something truly terrible like using the first 32 bytes of the utf-16 encoding and throwing the rest away. – President James K. Polk Jun 25 '20 at 18:23
  • You'll need to find out how the password is transformed to the 32-byte (256-bit) secret key. Try contacting them (even though they are out of business). Their website is still up and gives the impression they are still in business.. – Chilkat Software Jun 26 '20 at 01:16
  • @PresidentJamesK.Polk investigating further, the key derivation seems time-dependent. It seems the 5th block changes with the file time. All files created at hh:mm:ss have the same 5th block. All files created at hh:mm:ss+1 have the same 5th block. The first four blocks never change. – fergroops Jun 26 '20 at 14:19
  • @ChilkatSoftware we tried contacting support a couple of years ago but got no response. The contact form in their web site currently posts to a not found page. – fergroops Jun 26 '20 at 14:21
  • Just for fun I might be interested in reverse engineering this, but I doubt I have the tools. I use a macbook pro, although I do have Win 10 running in a virtual machine – President James K. Polk Jun 26 '20 at 14:32
  • Note that this library claims OpenPGP compatibility. OpenPGP uses CFB mode, could be something to look into... – Maarten Bodewes Jun 27 '20 at 11:32
  • "Can the right parameters even be inferred from the output without knowing the implementation details?" Generally no, unless there is meta information but they you'd still need to know the protocol (well, there could be a readable string in there I suppose). You can make educated guesses and try... It buggers the mind that people can use software that has no open source or protocol documentation, to be honest. That's killing especially for one-man projects. – Maarten Bodewes Jun 27 '20 at 11:34
  • "Fastest file encryption/decryption available, 20 MB per second on a sub 1000 dollar PC." Yeah, that site is **seriously** outdated. – Maarten Bodewes Jun 27 '20 at 11:37

0 Answers0