Extensions to block cipher functions for files

[New in v4.5] We have added two options to the file block cipher functions to (1) enable the IV to be embedded in the ciphertext file and (2) to allow the padding to be ignored when decrypting. The former option removes the requirement to send the IV separately when using CBC, CFB, OFB or CTR modes. The latter option can be used as a fudge to decrypt a file that has been padded in a non-standard manner. These options are available with the [all new in v4.5] functions :

• AES128_FileExt
• AES192_FileExt
• AES256_FileExt
• BLF_FileExt
• DES_FileExt
• TDEA_FileExt

Prefixing the IV

The usual behaviour of the block cipher functions that encrypt files (e.g. TDEA_File, AES128_File, etc. and their hex variants) is just to write out the ciphertext in binary format. All modes except ECB require a unique Initialization Vector (IV) to be used as part of the encryption process. The IV must be of the same block length as the algorithm: 16 bytes for AES and 8 for the others. It is the responsibility of the sender to communicate the IV used to the recipient separately by some other means. The IV does not need to be kept secret and can be sent in the clear. Provided it is unique each time it is used, an IV provides extra security against cryptanalysis for similar messages encrypted with the same key. The usual method is generate the IV at random.

An alternative convention to sending the IV by a separate channel is to prepend the IV to the ciphertext bytes in the file. The recipient can then extract the value of the IV from the file itself and use this together with the secret key to decrypt the remainder. This relies on the sender and recipient both agreeing to use this convention. Given the recipient knows the cipher algorithm, he can extract the correct number of bytes for the IV (16 for AES, 8 for the others) from the beginning of the file.

+--------------------+---------------------------------------+
| IV (8 or 16 bytes) | Ciphertext bytes (variable length)... |
+--------------------+---------------------------------------+

To use this convention, add the option API_IV_PREFIX (or CipherFileOption.PrefixIV in .NET). It must be used both when encrypting and when decrypting.

Decrypting with non-standard padding

Files encrypted in ECB or CBC mode are automatically padded with between 1 and 8 (or 16) padding bytes to make the final length a multiple of the block size (16 bytes for AES, 8 for the others). This form of padding is known variously as PKCS#5, PKCS#7 or CMS (see Padding). It provides an unambiguous method of removing the padding when decrypting as well as a check that the decryption has succeeded (if you don't find n bytes all of value n between 1 and 8 (or 16) at the end, decryption has failed).

If you need to decrypt a file that has been encrypted using a different form of padding (and there are many varieties), you should use the API_PAD_LEAVE option (CipherFileOption.LeavePadding in .NET). This will leave any padding in place in the decrypted file and will prevent the usual checks being carried out on their values. It's then up to you to deal with any extraneous bytes you find at the end of your document. This option only works when decrypting in ECB or CBC mode. It is ignored in all other cases.

Example

KEY=   0123456789ABCDEFFEDCBA987654321089ABCDEF01234567
IV=    1234567890ABCDEF
PT=    N o w   i s   t h e   t i m e   f o r
PT=    4E6F77206973207468652074696D6520666F72
INPUT= 4E6F77206973207468652074696D6520666F720505050505
CIPHER=204011F986E35647199E47AF391620C5D6D85A7D8D2784CC

204011F986E35647199E47AF391620C5D6D85A7D8D2784CC

1234567890ABCDEF204011F986E35647199E47AF391620C5D6D85A7D8D2784CC

4E6F77206973207468652074696D6520666F72

4E6F77206973207468652074696D6520666F720505050505

[Contents] [Index]