Inside an .efs vault
An .efs vault is an encrypted file. It can contain one file or a group of files.
Encryption protects the contents and original names. You need the correct password to read them.
What is inside the file?
Each vault has three parts. Only the first part is public.
- Header
- The header identifies the format and version. It contains the settings that the browser needs to make the encryption key.
- File list
- This encrypted list contains original names, folder paths, file types, sizes, and times. The technical name for this list is the manifest.
- File contents
- The browser divides each file into data blocks. Each block contains up to 1 MiB (1,048,576 bytes) before encryption.
Each encrypted part has a 16-byte check tag. The browser uses this tag to detect changes.
The public filename starts as a random identifier with the .efs extension. You can change this filename before download.
How does encryption work?
The browser makes an encryption key from your password. A key is the secret value that an encryption algorithm uses.
PBKDF2 is a key derivation algorithm. An iteration is one repeated calculation.
The repeated calculations increase the work for each password guess. A salt prevents the reuse of the same password calculation across different vaults.
AES-256-GCM encrypts the file list and file contents. It also makes the check tags.
The browser uses a different record number for each encrypted part. This number helps prevent the reuse of encryption settings within a vault.
The browser uses its Web Crypto API for these operations. The app does not use its own replacement for these encryption algorithms.
What happens when you unlock a vault?
- The browser uses your password and the public salt to make a key.
- The browser tries to decrypt the file list and check its tag.
- If the check succeeds, the browser shows the original names.
- You select the files that you want to decrypt.
- The browser checks all selected data blocks before it shows a complete file.
If the file list check fails, the password can be incorrect. The file list can also have damage. The app cannot distinguish these two causes.
Unlocking the names does not check all file contents. The browser checks each selected file during decryption.
What protects your files?
Encrypted names and contents
The vault does not expose original names, file types, or folder paths without the correct key.
Checks for changed data
The checks include the public header and each record number. They help detect changes, missing data, and blocks in the wrong position.
These checks do not identify the person who made the vault.
Separate keys for separate vaults
Each new vault gets a new salt. The same password produces different keys for these vaults.
Processing in your browser
File encryption and decryption occur in your browser. The app does not send your encryption password to a server.
Know the limits
- A weak password can be guessed. Someone with a vault can test passwords without this app. Use a long password that you do not use elsewhere.
- There is no password recovery. Keep your password in a safe place. The app cannot replace a lost password.
- Some information is public. The file size, format settings, and encrypted file list size are visible. These sizes can give information about the contents.
- Your filename is public. A name that you give the .efs file can reveal information.
- Your browser and device must be safe. Harmful software or changed app code can read your password or decrypted files.
- The source files remain unchanged. Encryption does not delete the source files. A password change does not change old vault copies.
- This version has no independent security review. Standard algorithms alone do not prove that an app is secure.
The current workspace can retain up to 256 MiB of file data. This is an app memory limit.
The app clears its workspace when you close the tab. This action does not erase downloaded files or guarantee removal from device memory.
Technical details
Each header contains a version number and an algorithm identifier. The reader rejects versions and settings that it does not support.
This check allows future formats to use different algorithms or layouts. A future format needs a reader that supports its version.
Show the version 1 settings
| Key derivation | PBKDF2-HMAC-SHA-256, 600,000 iterations |
|---|---|
| Salt | 16 random bytes per vault |
| Encryption | AES-GCM, 256-bit key |
| Check tag | 128 bits (16 bytes) per record |
| Record IV | 12 bytes: four zero bytes, then the 64-bit record number |
| Record numbers | 0 for the file list, then 1 and above for data blocks |
| Additional authenticated data | The exact 64-byte header, then the 64-bit record number |
| Data block size | Up to 1,048,576 bytes before encryption |
| Empty file | One record with a check tag and no content bytes |
| Password text | UTF-8. Case and spaces stay unchanged. |
| Integer byte order | Big-endian |
An IV is an initialization vector. GCM requires a different IV for each record under the same key.
Additional authenticated data is data that a check tag protects without encryption.
The reader calculates the expected file size from the decrypted file list. It rejects missing or added bytes.
A password change creates a new vault with a new salt. The app does not change encrypted data in place.
Read the full format specification (.md) ↗References
These documents describe the algorithms. They do not certify this app.