Projects / SEP Encryptor

SEP
Encryptor

Multi-file and directory encryption powered by a 1024-byte XOR stream key with optional AES-256-GCM double-layer protection. Every operation runs entirely in your browser — no data ever leaves your device.

XOR Stream Cipher AES-256-GCM PBKDF2 · 100k Rounds WebCrypto API Zero-Server FSAA Directory Encrypt
Input Files No files selected
🗂️
Drop files or folders here, or click to browse
All file types · Multiple files at once
Encrypt Directory to Disk FSAA · Native I/O

Uses the File System Access API to read a folder directly from disk, encrypt every file inside with the current strategy, and write the results to a second folder — no browser download dialogs. Folder structure is fully preserved.

Source Folder
not selected
Output Folder
not selected
Choose Output Folder...
Replace in Source Folder
Encryption Strategy
Strategy
Double Layer: SEP + AES (Key + Password)
Double Layer: SEP + AES (Password Only)
SEP Only (Key File)
SEP Only (Password)
AES-256-GCM Only (Password)
Credentials
Key File · .sep · 1024 bytes of entropy
No key loaded
Actions processes files in list above
Encryption Documentation
01 · Overview
SEP1 Container
Before any encryption, the file is packed into the SEP1 binary container. This attaches lightweight metadata — the original file extension and a format version byte — alongside the data so both can be recovered automatically on decryption without any user input. [SEP1][ver][extLen][ext bytes][gzip(data)] The 4-byte magic header allows the decryptor to verify the format. Data is also gzip-compressed at this stage, reducing payload size and increasing byte entropy before the XOR pass.
02 · Layer 1
XOR Stream Cipher
The SEP layer XOR-encrypts the packed payload against a 1024-byte key. With a key file, the key is raw cryptographic randomness from crypto.getRandomValues(). With a password, the key is derived via stretch-and-repeat over a per-file 16-byte random salt: key[i] = (passBytes ‖ salt)[i mod len] The salt is prepended to the ciphertext so every encryption is unique. The 1024-byte key cycle length significantly weakens frequency analysis against short files.
03 · Layer 2
AES-256-GCM
The optional second layer wraps the SEP output in NIST-standard authenticated encryption. The password is hardened through PBKDF2-HMAC-SHA256 at 100,000 iterations: key = PBKDF2(pwd, salt₁₆B, 100000, SHA-256) A 12-byte IV is generated per-file. AES-GCM appends a 128-bit authentication tag — any bit-flip in the ciphertext causes decryption to fail entirely, providing tamper detection. Output layout: [16B salt][12B IV][ciphertext + 16B tag].
04 · Strategies
Strategy Guide
SEP+AES Key Strongest. Key file = physical second factor. Both key and password required to decrypt.
SEP+AES Pwd Double-layer from a password. Two separate derive operations increase brute-force cost.
SEP Only Fast XOR cipher. Good for very large files where AES compute overhead matters.
AES Only Standard AES-256-GCM only. Extension is not recovered on decrypt; best for interoperability.
05 · Security
Properties & Caveats
All operations use the browser's WebCrypto API — no keys or plaintext are ever transmitted. The key file stores 8192 bits of getRandomValues() entropy. XOR with a random key file provides information-theoretic security proportional to key-length/data-length. XOR with a password-derived key is weaker — use Double Layer for high-sensitivity data. AES-GCM provides IND-CCA2 security. The Self-XSS warning in DevTools is intentional.
06 · Key Format
Key File Encoding
Raw 1024 random bytes are packed into a UTF-16LE text file with a BOM header (0xFEFF). Two bytes of entropy are combined into one UTF-16 character code to maximise density in a plain-text container: char = (byte₁ << 8) | byte₂ On load, the BOM is stripped and character codes are re-expanded to the original byte pairs. The .sep extension is just a label — the format is a standard UTF-16LE text file.