File Encryption Options

The file encryption option for the selected mounted storage can be set in the following dialog box.

Encrypt files during upload and decrypt them when downloading

Select this option to transparently encrypt files when uploading to the selected cloud storage and decrypt them when downloading from it.

Encryption key

Select an encryption key for the files to be encrypted. You first need to add an encryption key in the following dialog box.

File format

Select a format for the encrypted files. You can either select the AES Crypt or AES-GCM file formats.

Exclude / Include the following subfolders

Either select exclude or include a subfolder list for the encryption, and then add one or more subfolder names to the list. Files in these subfolders will be either excluded or included from encryption, depending on the selection.

Exclude / Include these file types

Either select exclude or include file types for the encryption, and then add one or more file extensions to the list. These file types will be either excluded or included from encryption, depending on the selection.

The following encrypted formats are used to encrypt files when uploading them to a cloud storage.

   AESCrypt encrypted file format.

CloudFolder can encrypt files in an AESCrypt file format on-the-fly when copying files from the local drive to a cloud storage, i.e., it reads a chunk of file data in memory, encrypts that data, and then writes the encrypted data to the file on the cloud storage. It will also decrypt files in the same way when downloading it from the cloud storage. We are using the AES File Format specification v2 as described on that website (but not any code from that project). So, you can use the AESCrypt utility program from that website to decrypt files if needed. Below is a copy of the AES file format v2 used by the CloudFolder.

 3 Octets - 'AES'
 1 Octet  - 0x02 (Version)
 1 Octet  - Reserved (set to 0x00)
 .... Start of repeating extension block section
 2 Octet  - Length in octets (in network byte order) of an extension
            identifier and contents.  If 0x0000, then no further
            extensions exist and the next octet is the start of the
            Initialization Vector (IV).  Following an extension,
            this length indicator would appear again to indicate
            presence or absence of another extension and the size of
            any such extension.
nn Octets - Extension identifier.  This is either a URI or an
            identifier defined by the AES developer community and
            documented on the standard extensions page, either
            of which is terminated by a single 0x00 octet.  All
            extension identifiers are case sensitive.
              CloudFolder inserts the following URI:
                 urn:uuid:7EB104C5-C965-4DE9-ACFC-F9161D54DEBA
              Then the following fields:              
               8 Octets - File size in bytes.
               8 Octets - File modification time in Windows UTC format.
               8 Octets - File creation time in Windows UTC format.
                 A URI was used to allow anybody to define extension
                 types, though we should strive to define a standard
                 set of extensions.
              Examples of standard extension identifiers:
                 CREATED-DATE
                 CREATED-BY
            A special extension is defined that has no name, but is
            merely a "container" for extensions to be added after the
            AES file is initially created.  Such an extension avoids
            the need to read and re-write the entire file in order to
            add a small extension.  Software tools that create AES
            files should insert a 128-octet "container" extension,
            placing a 0x00 in the first octet of the extension
            identifier field.  Developers may then insert extensions
            into this "container" area and reduce the size of this
            "container" as necessary.  If larger extensions are added
            or the "container" area is filled entirely, then reading
            and re-writing the entire file would be necessary to add
            additional extensions.
nn Octets - The contents of the extension
.... End of repeating extension block section
16 Octets - Initialization Vector (IV) used for encrypting the
            IV and symmetric key that is actually used to encrypt
            the bulk of the plaintext file.
48 Octets - Encrypted IV and 256-bit AES key used to encrypt the
            bulk of the file
            16 octets - initialization vector
            32 octets - encryption key
32 Octets - HMAC
nn Octets - Encrypted message (2^64 octets max)
 1 Octet  - File size modulo 16 in least significant bit positions
32 Octets - HMAC

   AES-GCM encrypted file format.

This is our own file format that uses the AES-256/GCM algorithm for encrypting file data and a password-based key derivation algorithm like PBKDF2 for generating the encryption key. This file format has the following characteristics:

• File meta-data is encrypted and saved in the header.
• File data is encrypted in fixed size blocks with authentication data. So, it is possible to read and decrypt any such data block randomly, enabling some random access to the encrypted file.
• Saves key derivation and encryption algorithm names in the header. So, different algorithms can be supported.
• It also saves the encryption information header at the end of the file as associated data for the last encrypted data block. So, it is possible to decrypt the file even if the file header is lost.

Below is the AEG File format used by CloudFolder.

 3 Octets - 'AEG'
 1 Octet  - 0x01 (Version)
 2 Octets - Two bytes unsigned integer in little-endian order, representing the
            total size of the encryption information block and the file meta-data
            block in bytes. Encrypted file data starts at the end of this block.
            CloudFolder uses a 4096 bytes fixed-size block for it now.
 1 Octet  - Length of the key derivation and encryption algorithm names in bytes.
nn Octets - Name of the key derivation algorithm followed by its parameters
            separated by commas. Then the name of the encryption algorithm
            proceeded by a semicolon. Currently, CloudFolder uses PBKDF2 with
            10,000 iterations for key derivation and AES-256/GCM as encryption
            algorithm. So, this string will look like:
            PBKDF2-HMAC-SHA-256,10000;AES-256/GCM
 1 Octet  - Length of the salt in bytes to follow.
nn Octets - An array of salt bytes. CloudFolder currently uses a 16-byte salt.
 2 Octets - Length of the encrypted meta-data in bytes including a 16-byte HMAC. 
            This is a 2-byte unsigned integer in little-endian order.            
nn Octets - Encrypted meta-data for the file. CloudFoler currently saves the
            following meta-data as a key/value pair for a file.
            date_modified - The last modification time for a file.
            date_created - The creation time for a file.
            file_size - The file size in bytes.
            file_name - The file name in UTF-8 character set.
            These meta-data is encrypted and saved with its HMAC value.
            CloudFolder uses the proceeding encryption information block
            as associated data when calculating the HMAC.
nn Octets - Encrypted file data in 4096 octets blocks. The last block
            can be less than 4096 octets.
64 Octets - Footer block to be appended to the last encrypted block as
            associated data. First two octets contains the length of 
            this block. Then the key derivation and encryption algorithm 
            names followed by the salts just as they are in the file header.