AESD File Format

The AESD file format used by AES Drive is documented below in detail. All algorithms used by AES Drive are standards and publicly documented.

Each encrypted file consists of a header and the encrypted contents. The header is 144 bytes in length and contains the AESD file format version, a checksum of the header bytes, and the encrypted file-specific key and padding length. The original file data is encrypted using XTS-AES with file-specific keys that are derived from a master key for the drive.

4 bytes [0-3] AESD. This is a file signature value which indicates the file is associated with the AES Drive application.
1 byte [4] 0x00. This is the file format version. The only supported value is 0.
7 bytes [5-11] 0x00. Reserved for future use.
4 bytes [12-15] CRC32 checksum. The CRC32 checksum is calculated by first replacing these 4 bytes with 0x00 then computing the checksum over the 144 byte header. The resulting numeric value is converted into 4 bytes using the operation:


						byte[] CRC32Bytes = new byte[4];
						for (int i = 0; i < 4; i++)
							CRC32Bytes[i] = (byte)((CRC32Bytes >> (24 - 8 * i)) & 0xff);
						

16 bytes [16-31] Global salt value. The global salt value is a random value created when the drive is created and used when encrypting newly created files within the drive. It is used when deriving the key to decrypt the encrypted header portion. See the section below for details about the encrypted header portion.
16 bytes [32-47] File-specific salt value. The file-specific salt value is a random value created when the file is created. It is used when deriving the key to decrypt the encrypted header portion. See the section below for details about the encrypted header portion.
80 bytes [48-127] AES-GCM encrypted header portion. The steps to derive the key to decrypt the encrypted header portion are as follows:
  • First use PBKDF2 with the following settings:
    • HMACSHA512 algorithm
    • 50,000 iterations
    • Salt is the 16 byte global salt value read from the header
    • Password is the original encryption password
    • Derived key length of 32 bytes
  • Combine the resulting 32 bytes with the 16 byte file-specific salt to obtain a byte array of length 48. The first 32 bytes are the value derived from the PBKDF process above. The last 16 bytes are the file-specific salt read from the file header.
  • Compute the SHA512 hash over the 48 byte value from the above step.
  • The first 32 bytes of the hashed bytes are the AES-GCM key. The next 12 bytes are the AES-GCM IV. The remaining 20 bytes are unused.

The derived Key and IV are used together with the AES-GCM Auth Tag which are the last 16 bytes of the 144 byte header to AES-GCM decrypt the 80 byte encrypted header portion. The decrypted header portion contains:

2 bytes Padding length. The padding length is represented in Big Endian and may be converted from bytes to an integer using the following operation:
PaddingLen = (decryptedHeaderBytes[0] << 8) + decryptedHeaderBytes[1];
14 bytes 0x00. Reserved. These bytes are all defined as 0x00.
64 bytes File-specific XTS-AES 256 encryption keys.

16 bytes [128-143] AES-GCM auth tag. This auth tag is used when decrypting the previous 80 byte encrypted header portion.
nn bytes The XTS-AES 256 encrypted file content. The data unit size is 512 bytes. The first 32 bytes of the file-specific encryption key from the decrypted header is the first key. The last 32 bytes of the file-specific encryption key from the decrypted header is the second key. Because each data unit must equal 512 bytes, the last plaintext block of data may be padded with null bytes (0x00) as needed to reach 512 bytes in length. The padding length is encrypted and stored in the encrypted header portion. When decrypting the padding is removed.

Copyright (c) 2022 /n software inc. - All rights reserved.
AES Drive 2020 - Version 20.0 [Build 8318]