Detailed File Encryption Project Notes
Detailed File Encryption Project Notes
This document provides a comprehensive explanation of how the File Encryption & Decryption
project works, its processes, security mechanisms, advantages, disadvantages, and practical
considerations for usage.
1. Introduction
This project is a browser-based file encryption and decryption tool built with HTML, CSS, and
JavaScript. It leverages the Web Crypto API, a powerful cryptographic interface available in modern
browsers. The primary goal of the project is to allow users to securely lock (encrypt) and unlock
(decrypt) files without requiring a backend server or internet connection. By using this tool, users
can protect sensitive documents, text files, or other data against unauthorized access. Only
someone with the correct password can successfully decrypt and access the file contents.
2. Encryption Process - Step by Step
Encryption is the process of transforming readable data (plaintext) into unreadable scrambled data
(ciphertext). In this project, encryption follows these steps: 1. File Selection: The user selects a file
from their device. 2. Password Entry: The user provides a password, which will act as the secret
key. 3. Password Derivation: Instead of using the raw password, the system derives a strong
cryptographic key using PBKDF2. - Salt (16 bytes) is randomly generated to make keys unique. -
100,000 iterations ensure resistance against brute-force attacks. - SHA-256 is used as the hashing
algorithm. 4. Key Generation: The derived key is configured for AES-GCM (256-bit). 5.
Initialization Vector (IV): A random 12-byte IV is generated for added randomness. 6.
Encryption: The file's data is encrypted using AES-GCM. 7. File Packaging: The salt + IV +
encrypted data are combined into one file. 8. Download: The encrypted file is offered for download
with the extension “.enc”.
3. Decryption Process - Step by Step
Decryption is the reverse of encryption. It converts scrambled ciphertext back into readable
plaintext, provided the correct password is supplied. 1. File Selection: The user selects the
encrypted “.enc” file. 2. Password Entry: The user enters the same password used during
encryption. 3. Extracting Metadata: The system extracts the Salt (16 bytes) and IV (12 bytes) from
the encrypted file. 4. Key Regeneration: PBKDF2 derives the same cryptographic key from the
provided password using the extracted Salt. 5. Decryption Attempt: AES-GCM uses the
regenerated key and IV to attempt decryption. 6. Validation: - If the password is correct, the
original file content is restored. - If the password is wrong, decryption fails with an error message.
4. Sharing Encrypted Files Across Devices
The encrypted file can be safely transferred across devices by email, USB drive, or cloud storage.
Since the encrypted file contains only Salt, IV, and ciphertext, it cannot be decrypted without the
original password. On another device: - Open the project (HTML file) in a browser. - Upload the
encrypted file. - Provide the same password used during encryption. - The file is decrypted back to
its original form.
5. Security Mechanisms in the Project
Several mechanisms ensure security in this project: - PBKDF2 (Password-Based Key Derivation
Function): Strengthens passwords by repeatedly hashing them with Salt. - Salt: Prevents
attackers from using precomputed rainbow tables. - Iterations (100,000): Slows down brute-force
attacks by making each guess computationally expensive. - AES-GCM: Provides both
confidentiality (encryption) and integrity (detecting tampering). - IV (Initialization Vector): Adds
randomness to each encryption, ensuring that encrypting the same file twice produces different
ciphertexts.
6. Advantages
1. Strong encryption (AES-256 GCM + PBKDF2 with SHA-256). 2. Client-side only, no server
required. 3. Files remain private; nothing is uploaded to the internet. 4. Encrypted files are portable
and safe for transfer. 5. Lightweight and easy to use.
Disadvantages
1. Password loss means permanent file loss (irreversible). 2. Requires manual password entry each
time (no storage). 3. Large files may take longer to encrypt/decrypt in the browser. 4. Entirely
password-dependent; no multi-factor authentication. 5. No automatic backup or recovery
mechanism.
7. Practical Considerations
- Choose strong, memorable passwords (avoid weak ones like '12345'). - Share the password
securely with recipients (not via email with the file). - Always test decrypting an encrypted file before
deleting the original. - Keep the HTML tool handy for future decryption. - Educate users about the
irreversible nature of forgotten passwords.
8. Conclusion
This project functions as a secure, browser-based file locker. It leverages modern cryptography
standards to protect data without relying on servers. Its strength lies in strong encryption and
client-side execution, but its weakness lies in password dependency. For personal and lightweight
file protection, it is an excellent solution. For enterprise use, integration with password managers or
additional authentication mechanisms is recommended.