A key point to keep in mind about the FesfSa functions is that they may be used only on systems where FESF is not installed (or where it can be unambiguously guaranteed that none of the FESF kernel-mode or user-mode components are running). Using the FesfSa functions on systems where FESF is active will result in undefined behaviors, including file corruption.
PLEASE READ THIS: Important Note on the Future Direction of the FESF Stand-Alone Library
As described above, the only supported use of the FESF Stand-Alone Library has been on systems where FESF is not installed. However, for OSR internal design reasons that are now obsolete, the FESF Stand-Alone Library included code that, in some limited cases, would allow it to work on systems where FESF was installed and running.
As part of ongoing efforts to update the FESF architecture, OSR plans to change the FESF Stand-Alone Library so that its functions will fail (returning an error) on systems on which FESF is running. We expect to implement this behavior in an upcoming release of FESF.
This should have no impact on your product because the Library was never supported for 3rd party use on systems where FESF was installed. If, however, your Solution DID make use of the FESF Stand-Alone Library on systems where FESF was running, this will no longer be possible. We recommend using FesfUtil2 or some other approach. Please only ever use the FESF Stand-Alone Library on systems in which FESF is known not to be running.
Given the design patterns implemented by FesfSaEncrypt and FesfSaDecrypt, your stand-alone application’s code
will be responsible for performing the actual encryption and decryption
operations on file data. This is in contrast to the practice when FESF is
installed, in which FESF performs all encryption and decryption operations.
Because you will be responsible for implementing the data encryption and decryption functions, it should go without saying that, in order for newly encrypted files to be recognized and accessible by FESF, you must perform encryption and overall file operations in a way that is fully compatible with FESF. FESF uses the Microsoft CNG implementation for its encryption operations. Ensuring that your stand-alone application creates compatible FESF encrypted files is the responsibility of your application.
For algorithms requiring a fixed block size, we use a value of 256 bytes. This choice is arbitrary. Normally, algorithms that provide a CBC mode also include a non-secret value known as the initialization vector. This prevents identical blocks from appearing to be identical in the encrypted file content.
When calling CNG encryption methods that require an initialization vector (IV), FESF generates this from the key material using a technique adapted from the disk drive field and known as the Encrypted Salt-Sector Initialization Vector (ESSIV). In general:
IV(O)= Cs(O)
Where O is the offset, C is a cryptographic function and s is a cryptographic hash of the password. However, our specific implementation varies slightly. Specifically, we limit the value of O to be less than 263 bits (8EB) in keeping with the largest possible size in the Windows environment. Rather than sign extend the value, we shift the value by 64 bits. Thus, we implement:
IV(O)=Cs(O*264)
We derive s (the encryption key we use) by computing the SHA-256 checksum of the file key material. This provides us with the “salt” to permute the underlying encryption algorithm, as necessary.
Our choice for C (the cryptographic function) is AES-256 in Electronic Code Book (ECB) mode.