Since Microsoft dropped support for .net frameworks 4.5 and older, I am retargeting to 4.6 and using the Chilkat .NET 4.6 module version 9.50.55. I’ve been a long time user of Chilkat and have literally millions of files encrypted using the module. The software updates have been going smoothly, FTP and encrypted Zip routines were seamless but I seem to be having an issue with decrypting documents. I’m wondering if something has changed or if I need to set an attribute that I didn’t need to before. I’m using “twofish” and CkEncryptFile/CkDecryptFile

Quasi code below…these are the only attributes I’ve been setting. Works with Chilkat version 9.4.1. When I try to decrypt a word document using these settings in Chilkat version 9.5.0.55, it is not decrypting properly. Thoughts?

Encrypt

        Dim lnUnlocked As Boolean
        Dim CryptSuccess As Boolean
        bCrypt = Nothing
        bCrypt = New Chilkat.Crypt2
        bCrypt.KeyLength = 128
        bCrypt.CryptAlgorithm = "twofish"
        bCrypt.SecretKey = bCrypt.GenerateSecretKey("abc12") 'Note using a 5 character key
        CryptSuccess = bCrypt.CkEncryptFile(Hfile, Ofile)
        bCrypt = Nothing

Decrypt

        Dim lnUnlocked As Boolean
        Dim CryptSuccess As Boolean
        bCrypt = Nothing
        bCrypt = New Chilkat.Crypt2
        bCrypt.KeyLength = 128
        bCrypt.CryptAlgorithm = "twofish"
        bCrypt.SecretKey = bCrypt.GenerateSecretKey("abc12") 'Note using a 5 character key
        CryptSuccess = bCrypt.CkDecryptFile(Hfile, Ofile)
        bCrypt = Nothing

Answer

Usually the problems have to do with any possible ambiguity -- such as using CBC cipher mode but without setting an IV, or setting the secret key first, and then changing the KeyLength, etc..

I tested the code, and examined the LastErrorText after calling CkEncryptFile. The IV was never explicitly specified, and thus we see a warning about the IV:

  CkEncryptFile:
    DllDate: Aug 15 2013
    ChilkatVersion: 9.4.1.42
    UnlockPrefix: ABCABCCrypt
    Username: CHILKAT13:Matt
    Architecture: Little Endian; 64-bit
    Language: Visual C++ 11.0 / x64
    VerboseLogging: 1
    inputFile: [qa_data/hamlet.xml]
    outputFile: [qa_output/hamlet_twofish.dat]
    encryptionMethod: 4
    EncryptionParams:
      algorithm: twofish
      keyLength: 128
      paddingScheme: 0
      cipherMode: cbc
      encodingMode: base64
      charset: windows-1252
      secretKey: 60D8 2FA6 9F2B 1919 B08B D705 6F98 2D90
      iv: (empty)
      inDataNumBytes: 279658
    --EncryptionParams
    Warning: IV length is less than the algorithm's block size
    blockSize: 16
    IV_len: 0
    algorithm: twofish
    keyLength: 128
    Success.
  --CkEncryptFile
--ChilkatLog

Normally, the default IV is all zero bytes. This is the case for AES, and I would think it's the case for all other block encryption algorithms. However, I examined the v9.4.1 Chilkat source, and found that the default IV for Twofish is this:

    unsigned char iv[16] = { 
            0xAE, 0x74, 0x81, 0x9A,
            0xF6, 0x31, 0x05, 0x44,
            0x2C, 0xBA, 0xB3, 0x65,
            0x78, 0x5F, 0xD5, 0xD2 };

The default IV for 9.5.* is 0, 0, 0, .... , 0. This is the cause for the error. The solution is to explicitly set the IV to what you were implicitly already using: AE74819AF63105442CBAB365785FD5D2.

Do this with the following line of code:

bCrypt.SetEncodedIV("AE74819AF63105442CBAB365785FD5D2","hex")

A few hints about detecting what's wrong with encryption params when decrypting:

If the cipher mode is CBC, and if all encryption related params are correct except the IV, the result is that the entire file is decrypted correct except for the very first 16-byte block. This was the case when I tested your code with v9.4.1 vs v9.5.*.
If the entire file decrypts successfully, except for the very last block (16 bytes or less), then the problem has to do with the padding scheme.

Archived Forum Post

Index of archived forum posts

Twofish encryption compatibility -- v9.4.1 vs v9.5.*

Jul 01 '16 at 14:01

Answer