FILE CRYPTO SETTINGS CHECKINGCipher IV. Check crypto primitives. Apply settings.

CONTENTS

1. Initialization vector (cipher IV)
2. Hash salt
3. Selection of test files
4. Encryption process test
5. Decryption process test
6. Control reports
7. Restore settings

INITIALIZATION VECTOR (CIPHER IV)

In cryptography, an initialization vector (IV) or starting variable (SV) is an input to a cryptographic primitive being used to provide the initial state.

The IV is typically required to be random or pseudorandom, but sometimes an IV only needs to be unpredictable or unique. Randomization is crucial for some encryption schemes to achieve semantic security, a property whereby repeated usage of the scheme under the same key does not allow an attacker to infer relationships between (potentially similar) segments of the encrypted message.

For block ciphers, the use of an IV is described by the modes of operation.

Some cryptographic primitives require the IV only to be non-repeating, and the required randomness is derived internally. In this case, the IV is commonly called a nonce (number used once), and the primitives (e.g. CBC) are considered stateful rather than randomized.

This is because an IV need not be explicitly forwarded to a recipient but may be derived from a common state updated at both sender and receiver side. (In practice, a short nonce is still transmitted along with the message to consider message loss.) An example of stateful encryption schemes is the counter mode of operation, which has a sequence number for a nonce.

The IV size depends on the cryptographic primitive used; for block ciphers it is generally the cipher's block-size.

In encryption schemes, the unpredictable part of the IV has at best the same size as the key to compensate for time/memory/data tradeoff attacks.

When the IV is chosen at random, the probability of collisions due to the birthday problem must be taken into account.

Traditional stream ciphers such as RC4 do not support an explicit IV as input, and a custom solution for incorporating an IV into the cipher's key or internal state is needed.

Block cipher processing of data is usually described as a mode of operation.

Modes are primarily defined for encryption as well as authentication, though newer designs exist that combine both security solutions in so-called authenticated encryption modes.

While encryption and authenticated encryption modes usually take an IV matching the cipher's block size, authentication modes are commonly realized as deterministic algorithms, and the IV is set to zero or some other fixed value.

In stream ciphers, IVs are loaded into the keyed internal secret state of the cipher, after which a number of cipher rounds are executed prior to releasing the first bit of output.

For performance reasons, designers of stream ciphers try to keep that number of rounds as small as possible, but because determining the minimal secure number of rounds for stream ciphers is not a trivial task, and considering other issues such as entropy loss, unique to each cipher construction, related-IVs and other IV-related attacks are a known security issue for stream ciphers, which makes IV loading in stream ciphers a serious concern and a subject of ongoing research.

Note: In all versions of the FPS using standard encryption methods, the IV applies only to block ciphers.

HASH SALT

In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes data, a password or passphrase.

Salts are used to safeguard passwords in storage. Historically, only a cryptographic hash function of the password was stored on a system, but over time, additional safeguards were developed to protect against duplicate or common passwords being identifiable (as their hashes are identical). Salting is one such protection.

A new salt is randomly generated for each password. Typically, the salt and the password (or its version after key stretching) are concatenated and fed to a cryptographic hash function, and the output hash value (but not the original password) is stored with the salt in a database. Hashing allows later authentication without keeping and therefore risking exposure of the plaintext password if the authentication data store is compromised. Note that due to this, salts don't need to be encrypted or stored separately from the hashed password itself, because even if an attacker has access to the database with the hash values and the salts, the correct use of said salts will hinder common attacks.

Salts defend against attacks that use precomputed tables (e.g. rainbow tables), as they can make the size of table needed for a successful attack prohibitively large without burdening users.

Since salts differ from one another, they also protect redundant (e.g. commonly used, re-used) passwords, as different salted hashes are created for different instances of the same password.

Cryptographic salts are broadly used in many modern computer systems, from Unix system credentials to Internet security.

Salts are closely related to the concept of a cryptographic nonce.

The modern shadow password system, in which password hashes and other security data are stored in a non-public file, somewhat mitigates these concerns. However, they remain relevant in multi-server installations which use centralized password management systems to push passwords or password hashes to multiple systems. In such installations, the root account on each individual system may be treated as less trusted than the administrators of the centralized password system, so it remains worthwhile to ensure that the security of the password hashing algorithm, including the generation of unique salt values, is adequate.

Another (lesser) benefit of a salt is as follows: two users might choose the same string as their password, or the same user might choose to use the same password on two machines. Without a salt, this password would be stored as the same hash string in the password file. This would disclose the fact that the two accounts have the same password, allowing anyone who knows one of the account's passwords to access the other account. By salting the passwords with two random characters, even if two accounts use the same password, no one can discover this just by reading hashes.

SELECTION OF TEST FILES

The selection of test files is an essential element of the testing process of the underlying crypto primitives.

It is recommended that the files that will be used to run tests, to verify the crypto primitives, be saved in a separate directory.

It is a good practice to create subdirectories in the test directory whose names correspond to the type of files that are generated in the process of running the control tests. For example:

• Source files - Directory where source test files are stored;
• Encrypted files - A directory where the resulting encrypted files will be saved;
• Decrypted files - Directory in which the resulting decrypted files will be saved;
• Crypto settings - Directory for recording the tested settings;
• Test reports - Directory, in which the system reports will be saved.

The selection of a test file to be encrypted or decrypted is done by entering the absolute address in the Source file field, or by clicking on the button to the right of this field, which will activate the file selection module as is shown in the image.

After File Explorer is activated, it is necessary to select a test file and press the Enter key to confirm the selection or click on the Select button located in the lower right corner.

ENCRYPTION PROCESS TEST

Encryption of selected test files are used to verify the functionality of selected crypto primitives.

This check is performed by sequentially encrypting and decrypting the selected file.

The test encryption procedure is started by pressing the F9 key after selecting the source file or clicking the Encryption button as shown in the image.

In the event that a block cipher is selected, the system will automatically generate an IV, the length of which will be consistent with the length of the secret key and the block size of the selected algorithm. Additionally, a hash salt will be created, the size of which in bytes is fixed, depending on the application winder used and the crypto mechanism used.

After the file is encrypted, the results of the process are recorded in the control table for subsequent analysis.

The control table contains the following basic fields:

• No - Process number;
• Process Type - Test process type;
• Result - Result of the conducted test;
• Source File - Source file аbsolute address;
• Result File - Result file аbsolute address;
• Process Start Time - Start of test process;
• Process End Time - End of test process;
• Process Duration - Test process duration;
• Cipher - Cipher algorithm used;
• Hash function - Hash function used;
• Concatenating mode - Block cipher mode used.

Note: Depending on the version of the application (Educational, Standard, Expandable, Professional, etc.), the results table may contain much more information than is displayed.


If the test encryption has passed successfully, the result that will be recorded in the spreadsheet will be "OK". Also, the encryption process control light located at the top right will be green and the decryption light will be orange. This indicates that the file is encrypted and can be decrypted.

Note: If the absolute address of the result file was entered in the Result file field, the selected output file will be encrypted.

DECRYPTION PROCESS TEST

Testing the decryption process allows to verify that the encrypted file will be restored to its original form, using the crypto primitives that form the encryption mechanism.

It is important to know that if only one of the base crypto primitives used in the decryption process differs from those used to encrypt the selected test file, decryption will be impossible.

The test decryption procedure is started by pressing the F10 key after selecting the source file or clicking the Decryption button as shown in the image.

During the decryption process, IV and hash salt are not generated and in the corresponding fields "N/A" (Not Available) will be written.

The results of the decryption process will be recorded in the control table.

If the test decryption has passed successfully, the result that will be recorded in the spreadsheet will be "OK". The decryption process control light located at the top right will be green and the encryption light will be orange. This indicates that the file is decrypted and is restored to its original form.

IMPORTANT!

Under no circumstances should attempts be made to decrypt a file that is not encrypted, as this would damage it irreversibly.

Decryption is only performed for files that are known to be encrypted while strictly following the protocols in place.

A characteristic feature of encryption in FPS is the way the user password is handled. In addition to salting, which has already been described in detail, there are also many specialized mechanisms that make it difficult for unregulated access to user passwords.

In practice, the cryptosystem does not work directly with the entered password, but uses its derivatives. This in no way affects the result of the execution of the processes.

After the performed settings have been verified, they should be activated. For this purpose, the Ctrl + Enter key combination is used or the Apply button is clicked as shown in the image.

After the settings are activated, the system is ready to encrypt files and folders.

CONTROL REPORTS

All settings made can be documented in a way that provides information about the crypto primitives used without revealing critical information such as a secret key or user password.

The documentation includes specialized reports, inquiries about the results of the control processes, as well as the ability to save the settings in system files (automatically and at the request of the operator).

The best form of documentation is control reports. They are generated completely automatically and can easily be converted to different file formats.

In order to generate a control report, it is necessary to click on the Report button located on the control panel or to use Ctrl + P keys combination.

RESTORE SETTINGS

In FPS, there is a rich set of system functions, allowing to restore the settings of the encryption process in case of need.

It is necessary to distinguish between restoring the current settings and returning the system to its original state.

A system reset returns the crypto primitives to the state when they were last verified and enabled for use. This state may differ significantly from the original. The reason is that it is possible that cryptoprimitives have been selected to form a mechanism that the operator of the system considers suitable for the purpose for which it will be used.

Restoring the current settings is realized by clicking the button Refresh or using a system key F5

In addition to the above-mentioned recovery of the system settings, it is possible to perform a soft system reset. As a result of this action, all settings will be restored to the state in which they were immediately after the installation was completed.

File and directory encryption settings are reset by clicking the Trash button located on the control panel or using the Alt + Del key combination.

Regardless of which of the two recovery methods is chosen, the system will automatically check the functionality of cipher algorithms, hash functions and all other basic cryptographic primitives.

The results of this check will be displayed in the process operational control field as shown on the system or in a specialized module as in higher versions of the application.

When the results are displayed in the operational process control field, the system report is activated using the drop-down menu or by means of a key combination Alt + P




More information on the subject can be found in the official documentation of the application, as well as in the specialized courses we conduct.


Note: The correct choice of cryptographic primitives ensures that the encryption mechanism used will meet the requirements for Provable security. Only in-depth knowledge of the processes can guarantee the best solutions for each specific case.

< Previous        Contents