AES-256 encryption/decryption security tool for files | ZeroTools

This chapter explains how the file AES-256 encryption and decryption tool operates within the browser. The tool utilizes the Web Crypto API to encrypt files using the AES-GCM standard.

When a file is encrypted, the output is saved as a .enc file. This .enc file is a custom container format specific to this tool, not a standard ZIP archive or OpenSSL compatible format.

The container structure begins with a fixed header used to identify the format, followed by a randomly generated salt for key derivation, a randomly generated initialization vector (IV) for encryption, the length of the original file name, the original file name encoded in UTF-8, and finally the AES-GCM encrypted payload and its authentication tag.

When you decrypt a file, the tool reads this specific container structure in sequence. It extracts the salt and IV, derives the encryption key from the provided password using the exact same parameters, and then decrypts the payload to restore the original file contents.

Because the output is a custom format, other standard encryption software will not automatically recognize or open these .enc files.

For long-term storage, you must ensure that you retain not only the encrypted file but also information about the specific tool and format used to create it, as relying on a single web tool implementation for decades may not be viable.

Always test decryption in a separate environment or session before deleting your original important files, to confirm that the encrypted container was generated correctly and can be restored.

The file name is stored in plaintext within the header and is not included in the additional authenticated data (AAD) of the AES-GCM payload.

Therefore, the original file name is visible to anyone inspecting the file header and is not cryptographically authenticated; if the file name is altered in the header, the decryption process will not detect it as a tampering event, provided the ciphertext itself remains valid.

The password you enter into the tool is not used directly as the AES encryption key. Instead, the tool processes the password through the PBKDF2 algorithm provided by the Web Crypto API.

The password string is converted exactly as entered into a UTF-8 byte sequence. The tool does not trim surrounding whitespace, nor does it perform Unicode normalization.

Therefore, leading or trailing spaces, as well as different Unicode representations of the same character, will result in different keys and cause decryption to fail.

The tool does not enforce a minimum password length or provide a strength meter. PBKDF2 uses a randomly generated 16-byte salt, the SHA-256 hash function, and 100,000 iterations to derive a 256-bit encryption key.

The inclusion of a random salt means there is an overwhelming likelihood that even if you use the same password to encrypt multiple files, the derived key will be different each time, preventing the reuse of precomputed tables.

The salt itself is not a secret and is stored in the header of the .enc file. The 100,000 iterations purposefully introduce a delay to increase the computational cost of guessing the password.

However, this iteration count is not a magical solution that transforms a weak, easily guessable password into a strong secret. It does not provide absolute protection against brute-force attacks by well-resourced adversaries, and weak passwords remain guessable.

You should avoid using short words, names, dates of birth, or reused passwords. If you require extremely high confidentiality or long-term archiving against nation-state level threats, you should prioritize enterprise-approved encryption products and dedicated key management procedures rather than a web-based utility.

The tool holds your password in the React memory and input state during page use, but there is no persistent storage or recovery feature.

If you lose the password, there is no password recovery mechanism in this tool. Furthermore, after you encrypt or decrypt a file, changing the password alone does not clear the generated Blob from the previous download link.

Changing tabs does call resetStatus and clears the download, and selecting a new file or clearing the file also resets the results.

A fresh operation is required after password edits to generate a new output, so ensure you perform a fresh success check. Keep your plaintext backups safe as well.

For the actual data encryption, the tool employs the Advanced Encryption Standard in Galois/Counter Mode with the derived 256-bit key.

For every single encryption operation, a fresh, cryptographically secure 12-byte random initialization vector is generated. This IV is essential for the security of GCM and is stored in the file header alongside the salt.

AES-GCM is an authenticated encryption mode, meaning it generates an authentication tag simultaneously with the ciphertext. During the decryption process, the algorithm checks this tag to verify that the combination of the ciphertext, the derived key, and the IV is correct and has not been altered.

If the wrong password is provided, the derived key will be incorrect, and the AES-GCM authentication will fail. It is important to note that an authentication failure generates no new result, but the previous download Blob can remain present after a password edit or a failed operation unless it is explicitly reset by changing the tab, selecting a new file, or clearing the current file.

Therefore, you should never assume the old output is automatically removed on a failure. The authentication mechanism only verifies the content and tag, providing no proof of the original creator's identity.

Anyone knowing the correct password can create a completely different encrypted file that authenticates successfully. The 36-byte header and the original filename bytes are unencrypted.

The filename is in plaintext and is not passed as Additional Authenticated Data to the AES-GCM function. Because of this, changing the filename to another name of the exact same UTF-8 byte length can stay layout valid, and the plaintext restores without issue.

Modifying the IV or salt may break the decryption process. We make absolutely no integrity claim for the entire file header, only for the encrypted payload and its associated authentication tag.

The current implementation of this tool processes the entire file in the browser's local memory. File selection initially records the File or FileInfo object.

The entire ArrayBuffer read only occurs when the Encrypt or Decrypt action runs, not at the time of initial file selection. The encryption or decryption process then generates the resulting data as a separate object within the memory.

This architecture introduces strict limitations on the maximum file size that can be processed. There is no hardcoded maximum limit; rather, the actual device RAM and browser limits dictate the specific constraints, alongside the memory consumed by other open tabs and applications.

Processing a file requires significantly more memory than the size of the file itself, as the original file, the intermediate processing buffers, and the final output must all reside in memory simultaneously.

When dealing with large files, the processing time can become substantial, and the browser tab may appear unresponsive or freeze entirely.

If the memory limit is exceeded, the browser may terminate the tab or the tool will throw a generic memory error. We provide no speed or thread model guarantee, and absolutely no safety guarantee is implied by this browser-based execution.

For this reason, this tool is best suited for relatively small files and simple roundtrip operations. If you need to encrypt or decrypt files that are hundreds of megabytes or multiple gigabytes in size on a regular basis, a dedicated desktop encryption application that supports streaming is much more appropriate.

Furthermore, because the entire operation runs within the browser sandbox, it eliminates the need to upload your plaintext files to a remote server for processing.

This local execution handles the whole file payload in separate output buffers.

To understand how the tool processes inputs, let us examine a specific, verifiable example. Suppose you create a small text file named secret.txt containing the exact string Hello World.

You select this file in the tool and enter the password TestPass123. The tool reads the file and derives a key. Because the salt and IV are randomly generated for each operation, the resulting .enc file will be different every time, even with the same input file and password.

The generated file will be named secret.txt.enc. If you inspect this file with a hex editor, you will see that the first 6 bytes are the ASCII string AES256.

The next 16 bytes are the random salt, followed by the 12-byte random IV. At byte offset 34, a 2-byte big-endian integer indicates the length of the original filename.

For secret.txt, this length is 10, so you will see the hex values 00 0A. The next 10 bytes will be the UTF-8 encoding of secret.txt.

Following this header, the remainder of the file contains the AES-GCM ciphertext and the 16-byte authentication tag. Because the header is unencrypted, the original filename secret.txt is plainly visible to anyone who has access to the .enc file.

If you now switch to the Decrypt tab, select the secret.txt.enc file, and enter the exact password TestPass123, the tool will read the header, extract the salt and IV, derive the same key, and decrypt the payload.

The output will be a file named secret.txt containing exactly Hello World. If you attempt to decrypt with the password testpass123, the key derivation will yield a completely different key, AES-GCM authentication will fail, and the tool will display an error message.

It is important to remember that changing the password in the input field while a previously generated download link is still active on the screen does not invalidate that download link; it continues to point to the Blob generated by the previous operation.

You must click the encrypt or decrypt button again to generate a new result based on the new password.

When decryption fails, the tool displays a generic error message indicating an issue. The AES-GCM authentication failure does not distinguish between a wrong password, a modified initialization vector, a modified salt, or a modified ciphertext payload.

From the perspective of the cryptographic algorithm, all these scenarios simply mean that the cryptographic binding is invalid, and the plaintext cannot be restored.

Errors are completely generic, meaning a wrong password, corruption, an unsupported format, API limitations, or memory issues are indistinguishable from the UI alone.

Therefore, you cannot use the error message alone to definitively diagnose the specific cause of the failure. The first step in troubleshooting is always to verify the password.

Passwords are exact; differences in capitalization, full-width vs. half-width characters, or trailing spaces introduced by copying and pasting will all result in a failed decryption.

Check for unintended whitespace or newline characters. If you are confident the password is correct, the file itself may have been corrupted during transfer, storage, or download.

Because this tool provides absolutely no recovery or partial repair mechanism, any corruption in the ciphertext or critical header fields will prevent successful decryption.

There is no absolute guarantee that no one can recover the data or that the data is completely unrecoverable, but this specific tool will not recover or repair it for you.

Backups may restore your data, and weak password guessing is still very much possible by an attacker. We make no recommendation to blindly delete original files after encryption.

To mitigate the risk of data loss due to corruption, it is highly recommended to maintain multiple backup copies of important encrypted files on different storage media and to calculate and record their SHA-256 hash values.

If decryption fails, you can compare the hash of the current file with the recorded hash to see if the file has been altered. This tool is designed for basic tasks.

Remember that a new result failing may leave the prior download Blob available as described above, so always check carefully for a fresh success.

A correct password is retained in memory during the session but is not persistent. Lastly, the privacy of test fixture files should not be confused with the security required for real production documents.