DEV Community: Sanjoy Karmakar

Is it safe to send files with a link? What the server actually sees

Sanjoy Karmakar — Fri, 31 Jul 2026 08:46:50 +0000

You drop a file into a "share a link" tool, get a URL back, and send it along. Is it safe to send files with a link? It depends entirely on one question most people never ask: what does the server hosting that link actually have access to? For most link-based transfer tools, the honest answer is "your file, in plaintext, sitting on someone else's storage." Here's what that risk looks like in practice, and what changes when the file is encrypted before it ever leaves your device.

What a typical file-link service actually holds

A conventional "send a file, get a link" service works by uploading your file as-is. The server receives the plaintext bytes, stores them, and hands out a link that lets anyone with the URL fetch them back. That means the provider — and anyone who compromises the provider, or is legally compelled to hand over data, or simply mis-configures a storage bucket — has the same access to your file that you do. The link itself is usually just an opaque ID; it doesn't protect the contents, because nothing about the file was ever hidden from the server that's serving it.

This is the same category of risk covered in is it safe to use online PDF tools: once a file is uploaded to a server you don't control, its confidentiality rests entirely on that server's security practices, retention policy, and legal exposure — not on anything you did.

The one FileX tool that isn't fully local — and why

Every other tool in FileX runs 100% in your browser: nothing is ever uploaded, full stop. FileX Send is the deliberate exception, because a link that works later — potentially from a different device — has to hold the file somewhere in between. Rather than pretend otherwise, FileX documents exactly what that costs you on a dedicated Send threat model page.

The design minimizes what the server ever gets to see:

Your browser generates a random encryption key locally.
The file is encrypted with that key — AES-256-GCM, the same authenticated cipher used everywhere else in FileX — before a single byte is uploaded.
Only the ciphertext goes to the server.
The key never travels with the upload request. It's appended to the share link after a #, a URL fragment — a client-side-only part of the URL that browsers never send in an HTTP request. So the server storing your ciphertext never receives the key that unlocks it.

FileX Send's Team tier adds a second layer: an optional password. When set, the actual file key isn't the link key alone — it's derived by combining the link key with the password through HKDF, a standard key-derivation function (RFC 5869), the same construction FileX's hybrid encryption already relies on elsewhere. That means possessing the link alone isn't enough to decrypt a Team file — the password has to reach the recipient through a separate channel, the same "don't send the key with the message" principle covered in how to send a password securely.

What the server can see — and what it can't

Being upfront about this is the point. FileX Send's server side can see:

The ciphertext bytes and their size.
A routing ID — an opaque key with no information about the file itself.
The link's expiry time and how many times it's been downloaded.
Which pricing tier the sender is on, but only if a license key was attached to the upload.

It can never see: the encryption key, the Team password, the plaintext file contents, or the original filename — which also travels only in the link fragment, never in the request.

Links don't sit around indefinitely, either, and the limits are enforced server-side rather than just suggested by the UI. They vary by tier and do change as the product evolves, so check the Send tool page for current numbers rather than trusting an old post. Free-tier links expire fastest and self-destruct after a single download; paid tiers get longer-lived links with higher size caps and unlimited downloads until expiry; Team links add the password requirement above. Once a link expires or hits its download limit, both the encrypted object and its metadata are deleted.

So — is it safe?

"Safe" depends on what you're protecting against. Encrypting client-side before upload closes off the biggest risk in ordinary link-sharing services: a server operator, or anyone who breaches that server, reading your file. With FileX Send, they'd get ciphertext and nothing to decrypt it with. What client-side encryption doesn't change is availability — the encrypted blob still has to exist somewhere until the recipient downloads it, and its size and rough timing are visible to whoever hosts it. If even that tradeoff isn't one you're willing to make — ciphertext held temporarily, in exchange for a link that works without both people online at once — keeping the file off any server entirely is still an option: encrypt a file to a FileX ID so only one recipient's private key can ever open it, and hand it over however you like.

For most people sharing a document or photo with someone who isn't ready to receive it in the next five minutes, a link where the host only ever holds ciphertext is a meaningfully safer proposition than one where it holds your file in the clear.

Ready to try it? Send a file securely — your file is encrypted before it leaves your browser, and you can read exactly what the server does and doesn't see on the threat model page.

What is a SHA-256 checksum and how do you verify a download?

Sanjoy Karmakar — Fri, 31 Jul 2026 08:31:52 +0000

A software vendor posts a download link next to a string like a94a8fe5ccb19ba61c4c0873d391e987982fbbd3. That string is a checksum — and if you've ever wondered whether you're supposed to do anything with it, the answer is yes. Here's what a SHA-256 checksum actually is, when checking one matters, and how to verify a download's checksum in your browser.

What a checksum actually is

A checksum (also called a hash or digest) is the output of a cryptographic hash function run over a file's bytes. SHA-256 — part of the SHA-2 family, published by NIST — always produces the same 256-bit (64 hex character) output for the same input, and a single changed byte anywhere in the file produces a completely different output. That's what makes it useful for verification: it's not a summary of the file, it's a fingerprint of every byte in it.

Two properties matter here:

Deterministic. The same file, hashed twice, always produces the same digest — on any machine, in any browser, with any implementation, because the algorithm is a fixed public specification, not something proprietary to one tool.
Collision-resistant. Finding two different files that produce the same SHA-256 digest is, as far as anyone has publicly demonstrated, computationally infeasible. So a matching digest is strong evidence the bytes are identical, not just similar.

A checksum doesn't tell you a file is safe — malware can ship with a perfectly valid checksum for its own bytes. What it tells you is that the file you have is the exact file the checksum was computed from: nothing added, removed, or flipped in transit.

When to actually check one

Most downloads, most of the time, you don't bother. Checking a checksum earns its keep in a few specific situations:

Installers and firmware. A corrupted download of an OS installer or a firmware image can brick a device or fail installation halfway through in a way that's hard to diagnose. Confirming the checksum before you run it catches that up front.
Large file transfers. The bigger the file, the more likely a partial download or flaky connection leaves you with a truncated or corrupted copy. A checksum mismatch tells you immediately, instead of discovering it when the file won't open.
Verifying nothing changed. If you need to prove a document or dataset is identical to a version you fingerprinted earlier — for an audit trail, a compliance record, or just your own peace of mind — comparing checksums over time does that without needing to diff the whole file by hand.
Confirming a publisher's signature. Many open-source projects publish a SHA256SUMS file alongside their releases specifically so downloaders can verify integrity independently of the download mirror they used.

If the checksum you compute doesn't match the one the publisher listed, don't run the file. A mismatch means the bytes differ from what was published — from ordinary network corruption at best, to a tampered file at worst. Either way, re-download from the source rather than trusting it.

How to verify a checksum in your browser

FileX's file integrity tool computes cryptographic digests entirely client-side, using the browser's built-in Web Crypto API (crypto.subtle.digest) — the file is read locally and never uploaded anywhere:

Open the integrity tool and drop in the file you downloaded.
Pick an algorithm. SHA-256 is the most common for public checksums; SHA-384 and SHA-512 are also available for cases that call for a longer digest, and SHA-1 is offered only for comparing against older, legacy-published checksums — it's cryptographically broken for anything security-sensitive and shouldn't be trusted to detect deliberate tampering.
Paste the checksum the publisher listed into the "compare against" field, and hit compute. FileX hashes the file locally and tells you outright whether it matches — no eyeballing a 64-character hex string for a typo.

If you need to fingerprint several files at once — say, an entire release directory — the tool's Manifest mode hashes every file you drop in and produces a downloadable SHA256SUMS-style checksum list in one pass, matching the format most open-source projects already publish.

Checksum vs. HMAC: when you need a shared key

A plain checksum verifies integrity — that the bytes weren't altered — but anyone can compute a SHA-256 digest of a file, including whoever might have tampered with it and then republished a matching checksum alongside it. If you need to prove the digest itself couldn't have been forged by someone without a shared secret, that's what HMAC (keyed-hash message authentication) is for.

FileX's integrity tool includes an HMAC mode: you supply a secret key alongside the file, and it computes a keyed digest via crypto.subtle.sign('HMAC', ...). Anyone verifying the HMAC needs the same key — so unlike a plain checksum, a valid HMAC also proves the digest came from someone who holds that key, not just from someone recomputing a hash after the fact. This is the same authenticated pattern that underlies how AES-256-GCM protects your files: encryption alone tells you a file is confidential, but an authentication tag (or here, an HMAC) is what tells you it hasn't been altered by someone without the key.

The short version

A SHA-256 checksum is a deterministic fingerprint of a file's exact bytes — matching digests mean identical files, a mismatch means something changed.
Check checksums for installers, firmware, large transfers, and anything you need to later prove wasn't altered.
Use HMAC instead of a plain checksum when you need to prove the digest came from someone holding a shared key, not just anyone who recomputed a hash.
FileX computes SHA-1/256/384/512 digests and HMACs entirely in your browser via the Web Crypto API — the file is read locally and never uploaded.

Have a download to verify? Compute its checksum now — nothing leaves your browser, and the live monitor on the page shows exactly zero bytes uploaded.

How to send a password securely (stop pasting it in chat)

Sanjoy Karmakar — Fri, 24 Jul 2026 10:10:00 +0000

You just reset a shared account's password, or you're handing a Wi-Fi key to a houseguest, or a client needs a login for a portal. The easy move is to paste it straight into Slack, WhatsApp, or an email. The problem: that message doesn't disappear. It sits in your chat history, the recipient's chat history, both parties' cloud backups, and any device either of you is signed into, indefinitely — in plain text, readable by anyone who later gets into any one of those places.

Here's how to send a password securely instead: encrypt it before it touches a chat or email thread, and split it from its own decryption channel.

Why pasting it in chat is the weak point

A password typed into a messaging app isn't "sent and gone." It's stored, usually more than once:

Chat history, searchable by anyone who later gains access to either account.
Cloud backups of that chat, often kept far longer than the conversation itself.
Notification previews, which can flash the password on a lock screen.
Server-side logs, if the tool routes messages through a provider you don't control.

None of that requires anyone to "hack" anything — it just requires someone who already has access to one of those places, at any point in the future. The fix isn't a better messaging app. It's not leaving a readable secret in any of those places to begin with.

Encrypt the secret, then send the encrypted version

FileX's Secret Note tool turns your message into ciphertext before it ever leaves your device:

Open the Secret Note tool and type or paste the password (or address, or message) into it.
Set a password to protect it. This encrypts the text locally with AES-256-GCM, the same authenticated cipher FileX uses for file encryption — the key is derived from your password with PBKDF2-HMAC-SHA256 and a random salt, run entirely in your browser.
Copy the output. It's a plain-text block — ----- BEGIN FILEX NOTE ----- … ----- END FILEX NOTE ----- — that pastes cleanly into any chat app, email, or ticket, because it is just text, base64-encoded.
Send that block over whatever channel you'd already planned to use.

Nothing about this step touches a server. The note is encrypted on your device and never uploaded — you can check the "nothing uploaded" monitor on the page while you do it.

To read it back, the recipient pastes the block into the same tool's Decrypt mode and enters the password. If the password is wrong, or the block was altered in transit, decryption fails outright rather than returning garbled text — that's the authentication tag in AES-GCM doing its job, the same mechanism covered in how AES-256-GCM keeps your files safe.

The part that actually matters: use a second channel

Encrypting the note only helps if the password protecting it doesn't travel the same path as the note itself. If you encrypt a secret and then send both the encrypted block and its password down the same Slack thread, you've just moved the plaintext-in-chat problem one message later — anyone who can read that thread can decrypt the note too.

Split it instead:

Send the encrypted note by chat, email, or a shared doc.
Deliver the password by a different channel — a phone call, an SMS, in person, or a separate app entirely.

An attacker (or a future account compromise) now has to control two channels, not one, to reconstruct the secret. That's the entire value of encrypting it in the first place — don't undo it by keeping the password on the same thread.

Don't reuse a weak password for the wrapper either

The password protecting your note is doing real cryptographic work — it's the input to the key derivation, and a short or guessable one narrows the search space an attacker has to try. Don't reuse an existing account password as the wrapper; generate a fresh one for this purpose with FileX's password generator, which draws randomness from your browser's CSPRNG (crypto.getRandomValues, never Math.random) rather than anything predictable:

A random password (8–64 characters, with toggles for lowercase, uppercase, digits, and symbols) — every character sampled with unbiased rejection sampling, one character guaranteed from each class you select.
A diceware-style passphrase (3–10 words from a 7,776-word list, optionally capitalized or suffixed with a number) — easier to read aloud over that phone call than a random string, and just as calculable: each word contributes about 12.9 bits of entropy, so a 5-word passphrase lands around 65 bits before any added number.

Either way, the generator shows you the resulting entropy so you're not guessing at strength.

The short version

Don't paste a password directly into chat, email, or a ticket — it lives on in history and backups long after you've forgotten it.
Encrypt it first with the Secret Note tool: AES-256-GCM, PBKDF2-derived key, nothing uploaded.
Send the encrypted block and the password over separate channels — that split is what actually protects the secret.
Generate the wrapper password with a CSPRNG-based password generator rather than reusing one you already know.

Ready to send one? Encrypt your secret note now — it runs entirely in your browser, and the live monitor on the page shows exactly zero bytes leaving it.

How to redact a PDF properly (black boxes aren't enough)

Sanjoy Karmakar — Fri, 24 Jul 2026 10:09:59 +0000

If you've ever learned how to redact a PDF by drawing a black rectangle over the sensitive part, you should know: in most tools, that rectangle is decoration. The text underneath is still there, and it usually takes nothing more than a copy-paste or a drag of the shape to get it back. Real redaction means the underlying content is gone — not covered.

Why a black box usually isn't redaction

A PDF page isn't a flat picture by default — it's a set of objects: text runs, positions, fonts, images, all still readable by software even when something visually sits on top of them. Drop a black rectangle over a paragraph in a word processor, export to PDF, and you've added one more object to the stack. The paragraph is still in the file underneath it.

That gap has caused real, public leaks. Redactions have been reversed by selecting and copying the "hidden" text, by deleting the covering shape in a PDF editor, or by extracting the underlying text layer with any PDF parser. None of that requires special tools — just the willingness to try.

What real redaction requires

Genuine redaction has one job: make sure the sensitive content cannot be recovered from the file you hand out, by any method. That means the original text and image data covered by a redaction has to be destroyed, not layered over. A tool that draws a shape and calls it done hasn't done the job — the safe assumption for anyone downstream is that a redaction is real only if the file's underlying structure no longer contains what it's hiding.

How FileX redacts a PDF

The Redact a PDF tool (part of the FileX PDF Editor, a Pro feature) handles this by rasterizing, not overlaying. When you mark an area for redaction and export the document, any page that has a redaction on it is rendered to a flattened image — the original text, fonts, and vector objects on that page are replaced entirely by that image, with your black boxes baked directly into the pixels. There's no text layer left to copy, no hidden object to peel away, and no shape you can nudge aside — because there's no shape at all in the output, just a picture. Pages you didn't redact keep their original, unmodified content, so you only lose text-selectability on the pages that actually needed it.

As with every FileX tool, this happens entirely in your browser — the document is never uploaded to redact it.

Redaction isn't metadata removal

These solve two different problems, and it's easy to fix one while forgetting the other:

	What it removes	What it leaves alone
Redaction	Visible content on the page (text, images)	Document properties (author, software, timestamps)
Metadata removal	Author, producer, creation/modification dates, title, keywords	The visible page content

A PDF you've redacted can still name you as the author in its document properties. If you're sending a document out and you want both — no visible sensitive content and no author fingerprint — run it through both tools: redact first, then clear the metadata. We cover the metadata side in more depth in the hidden metadata your photos and PDFs leak.

Before you send it

Don't rely on a black box drawn in a word processor or a basic PDF viewer. If the shape can be deleted or the text can be copy-pasted, it isn't redaction.
Cover the area completely. A redaction that clips the edge of a word can leave a legible fragment.
Check the metadata separately. Redacting content doesn't clear the author or producer fields — that's a separate step.
Confirm you can't select the "hidden" text in the exported file. If you can highlight it with your cursor, it wasn't redacted.

Redacting properly costs you one thing: the redacted page becomes an image, so its text is no longer selectable or searchable — that's the trade-off for the content actually being gone. For a document you're about to share outside your organization, it's the right trade to make. Try the PDF Editor's Redact mode — the file stays on your device the entire time, redaction included.

What is EXIF data, and how do you remove it from a photo?

Sanjoy Karmakar — Wed, 15 Jul 2026 08:56:08 +0000

Every photo your phone or camera takes carries an invisible passenger: EXIF data. It rides along inside the file, adds nothing to what you see on screen, and can quietly tell a stranger where you were standing when you took the picture. Here's what EXIF data actually is, what it can reveal, and how to strip it before you share a photo.

What is EXIF data, exactly?

EXIF stands for Exchangeable Image File Format — a standard, maintained by the Camera & Imaging Products Association (CIPA), for embedding a block of metadata inside a JPEG photo. When a digital camera or phone saves a JPEG, it writes a small binary block right after the start of the file (technically, an APP1 segment structured like a miniature TIFF file) containing tags about the shot: not the pixels, but facts about the pixels.

It's not a hack or a leak in the traditional sense — EXIF was designed to be there. The problem is that almost nobody ever looks at it before hitting send.

What's actually inside an EXIF block

A camera can write dozens of EXIF fields, but the ones that matter for privacy are a short list:

Field	What it reveals
`Make` / `Model`	The exact phone or camera model that took the photo
`Software`	The app or firmware version used to process it
`DateTime` / `DateTimeOriginal`	When the photo was taken and last saved, to the second
`Artist` / `Copyright`	A name, if the device or app was configured with one
`Orientation`	Which way to rotate the image for display
`ExposureTime` / `FocalLength`	Camera settings — not private, but confirms real gear was used
`GPSLatitude` / `GPSLongitude`	The exact location the photo was taken, often to within a few metres

That last one is the field that actually causes harm. GPS coordinates baked into a photo are precise enough to point at a front door, a workplace, or a child's school — from a single JPEG, with no other information needed.

The Orientation tag is worth a specific mention because it's the one EXIF field browsers already act on: the CSS image-orientation property's default value, from-image, tells the browser to auto-rotate a JPEG using this exact tag — proof that EXIF isn't some obscure forensic curiosity, it's live metadata your own browser reads today.

How to see what your photo is carrying

You don't have to take any of this on faith — you can look. FileX's Inspect tool reads a JPEG's EXIF block and lists every tag it finds, including a specific warning if GPS coordinates are present, before you decide to share anything. It's read-only: nothing is written back to the file, and because it runs entirely in your browser, the photo itself never leaves your device just to be checked.

How to remove EXIF data from a photo

Once you know what's there, removing it is one step: FileX's Scrub tool takes a JPG or PNG and re-encodes it as a fresh JPEG at 95% quality, using the browser's <canvas> element. That re-encode is the whole mechanism — a canvas only ever knows about pixels, so when it redraws your photo it has no way to carry the old EXIF block along. The output is visually identical, full resolution, same content — just without the metadata that came in.

Two things worth knowing about that process:

It always produces a JPEG, even if you dropped in a PNG. If your source was a PNG with embedded metadata, re-encoding still discards it.
Because it's a genuine re-encode at high quality (not a lossless strip), there's no meaningful visible quality loss, but it isn't a bit-for-bit copy of the original either.

Does resizing or cropping remove EXIF automatically?

Not necessarily — plenty of photo editors preserve the EXIF block when they resize or crop, because they write the new pixels back into the same container without touching the metadata section. The only way to be sure is to either check with a tool like Inspect, or use a tool that explicitly re-encodes through a metadata-blind path like canvas — which is exactly what removes it here.

A quick before-you-send checklist

Selling something online? Product photos taken at home routinely carry GPS. Scrub before you post the listing.
Sharing photos from an event or trip? Timestamps and device model are low-risk alone, but combined with GPS they build a fuller picture than most people intend to share.
Sending a photo to someone you don't fully trust? Inspect first — it takes seconds and costs nothing to know.

EXIF is only half the metadata story — PDFs and other documents carry their own hidden properties (author names, software fingerprints, timestamps), which works a little differently. The deeper look at hidden metadata covers both photos and documents side by side if you want the fuller picture.

Curious what your own photos are carrying? Drop one into the Inspect tool — it's free, read-only, and nothing is uploaded.

How to securely erase an SSD (and why overwriting isn't enough)

Sanjoy Karmakar — Fri, 10 Jul 2026 09:35:35 +0000

If you're about to sell, return, or recycle a laptop, the instinct is to delete your files, maybe run an overwrite tool, and call it done. On a spinning hard drive that instinct is basically correct. On a solid-state drive (SSD) — which is what's inside almost every laptop sold today — it isn't. You can securely erase an SSD, but not by overwriting files in place. Here's why, and what actually works.

Why file overwrites don't reliably erase an SSD

Overwriting a file writes new bytes over the old ones so the original content is physically replaced — that's real erasure, and it's exactly what an in-browser eraser tool does. The catch is what "in place" means on flash storage.

An SSD can't rewrite a single cell the way a magnetic platter can. To spread physical wear evenly and stay fast, SSD controllers use wear-leveling: when your OS "overwrites" a file, the controller frequently parks the new data in a different physical location and retires the old block instead of erasing it there. The filesystem reports success. The original bytes may still exist in a block the OS can no longer even address. We cover this mechanism — and the related myth that more overwrite passes helps — in more depth in does deleting a file actually erase it?

The upshot: a software overwrite on an SSD is a best-effort logical wipe. It defeats undelete and file-recovery tools, which is the level NIST calls "Clear." It cannot promise a lab with the right equipment won't recover a fragment from a retired block. For most everyday deletions, Clear is genuinely enough. For a drive that's about to leave your hands entirely, it usually isn't.

The reference standard: NIST SP 800-88

NIST Special Publication 800-88, "Guidelines for Media Sanitization," defines the escalating levels that matter here:

Level	What it does	Defeats
Clear	Overwrite user-addressable storage with new data	Standard undelete / recovery software
Purge	Techniques that resist laboratory recovery — cryptographic erase, or the drive's own firmware sanitize command	Forensic recovery
Destroy	Physical destruction of the media	Everything

A whole SSD you're decommissioning calls for Purge, not Clear. NIST 800-88 lists two practical ways to get there on flash media:

Cryptographic erase — if the drive (or a volume on it) was encrypted, destroying the encryption key instantly makes every block unreadable, no matter which physical location the controller actually wrote to. This is the fastest and most broadly applicable Purge method for SSDs, provided encryption was on from the start.
The drive's own sanitize / secure-erase command — issued directly to the controller (ATA Secure Erase for SATA drives, NVMe Sanitize for NVMe drives). The firmware erases the flash itself, which is the one layer that isn't fooled by wear-leveling, because it operates below it.

Both require access a web browser simply doesn't have — this is OS- and firmware-level work, not something JavaScript running in a tab can issue.

What that actually looks like

Concretely, reaching Purge on a real machine means one of:

Linux, LUKS-encrypted drive: destroy the volume key (cryptsetup luksErase) for an instant crypto-erase.
Linux, NVMe: issue an NVMe Sanitize block-erase (nvme sanitize) — the drive's firmware wipes itself.
Linux/any OS, SATA SSD: the drive's ATA Security Erase Unit command (often run via hdparm --security-erase).
macOS: disable FileVault and destroy the APFS volume key for a crypto-erase, or use the drive's native secure-erase utility.
Windows: turn off BitLocker and reformat to destroy the key, or run the drive vendor's secure-erase tool.

These are irreversible, whole-device operations — exactly the kind of thing that shouldn't run silently or by accident, and exactly why FileX draws a hard line around them.

Where FileX's two erasure tools fit

FileX ships two erasure tools, and each is honest about which level it reaches:

The in-browser Eraser overwrites and deletes the contents of a folder you choose, entirely in your browser via the File System Access API — nothing leaves your device. That's Clear: it reliably defeats recovery software, and it's the right tool for cleaning out sensitive files you're done with day to day. It is not, and doesn't claim to be, a whole-drive Purge tool — a browser tab can't touch drive firmware.

The downloadable FileX Eraser Tool (native, Windows/macOS/Linux, Pro-licensed) also supports crypto-erase and purge methods for whole devices. Deliberately, it does not fire the firmware sanitize command itself — that's a destructive, irreversible action on an entire disk, and an unsigned CLI shouldn't auto-execute it. Instead it detects your OS and prints the correct, vetted native command for your platform (nvme sanitize, hdparm --security-erase, cryptsetup luksErase, diskutil secureErase, or the BitLocker equivalent) so you run it deliberately, as an admin, against the right device. For file- and folder-level clear jobs it runs the erase itself and produces the same tamper-evident certificate as the web tool.

The practical takeaway

Deleting or even overwriting individual files on an SSD is Clear-level protection — good for day-to-day cleanup, not a guarantee for hardware leaving your control.
The reliable way to reach Purge on an SSD is cryptographic erase (destroy the key) or the drive's own ATA Secure Erase / NVMe Sanitize command — both need OS- or firmware-level access.
Turn on full-disk encryption from day one on any drive you might ever resell or return. It makes a future crypto-erase instant instead of impossible.
For files you want gone right now, not a whole drive, the in-browser Eraser overwrites and deletes them locally and hands you a certificate — nothing uploaded.

PBKDF2 vs Argon2 vs bcrypt — which key-derivation function and why

Sanjoy Karmakar — Wed, 08 Jul 2026 09:20:39 +0000

If you've read anything about password hashing or encryption, you've run into all three names: PBKDF2, bcrypt, Argon2. They get lumped together as "ways to turn a password into something safe to store or use," but they were built for different problems, at different times, and they don't defend against the same attacks equally well. Here's what each one actually does, where they diverge, and why FileX derives its encryption keys with PBKDF2 rather than the others.

What a key-derivation function is for

A password like correct horse battery staple is not usable directly as a cryptographic key, and it's not safe to check by comparing it to a plain stored copy either. A key-derivation function (KDF) — sometimes called a password-hashing function in the login context — takes the password plus a random salt and runs it through a deliberately expensive one-way computation. Two properties matter:

The salt makes every derivation unique, even for two people who pick the same password, so an attacker can't precompute one giant table of results and reuse it against every target.
The cost (iterations, memory, or both) makes each guess slow. An attacker who steals a salt and a ciphertext (or a stored hash) still has to pay that cost for every single password they try. That's the entire point — the cipher or the login check is rarely the weak link; how expensive it is to brute-force the password is.

PBKDF2, bcrypt, and Argon2 all satisfy this shape. Where they differ is what they make expensive.

PBKDF2: CPU-hard, standardized, everywhere

PBKDF2 (Password-Based Key Derivation Function 2) dates to 2000 and is specified in RFC 2898. It derives a key by running an underlying HMAC (commonly HMAC-SHA256) over the password and salt thousands of times in sequence. The only cost knob is iterations — more repetitions, more CPU time, no memory requirement beyond the hash itself.

That single-dimension cost is PBKDF2's main weakness: it parallelizes cleanly on GPUs and ASICs, which can run huge numbers of hash iterations concurrently far cheaper than a general-purpose CPU can. NIST SP 800-63B sets the floor at "typically at least 10,000 iterations," while the current OWASP Password Storage Cheat Sheet recommends 600,000 iterations for PBKDF2-HMAC-SHA256 in new systems specifically because commodity GPU cracking has gotten so much faster since the function was designed. PBKDF2 is still considered sound — it just needs a high, regularly-revisited iteration count to stay expensive against modern hardware.

bcrypt: built for login checks, not general key derivation

bcrypt (1999) wraps the Blowfish cipher into a password-hashing scheme with a configurable, exponential cost factor. It was a real improvement over unsalted or fast-hashed passwords at the time, and OWASP still lists it as an acceptable choice with a work factor "as large as verification server performance will allow, with a minimum of 10."

Two things limit it outside login-check use cases: it silently truncates input past 72 bytes, and — like PBKDF2 — its cost is CPU time only, so it doesn't resist a well-funded, memory-rich cracking rig as well as a memory-hard function does. It's also not part of any Web Crypto API standard, so a browser can't produce it without shipping a separate implementation.

Argon2: memory-hard, the modern default

Argon2 won the Password Hashing Competition in 2015 and is standardized in RFC 9106. Its cost has three independent dials: iterations (time), memory (how much RAM each computation must hold), and parallelism. That memory requirement is the important change — a GPU or ASIC that can run millions of cheap hash operations in parallel can't cheat past a function that demands, say, 19 MiB of memory per guess. Memory is expensive to parallelize at scale in a way that raw compute isn't.

OWASP now recommends Argon2id (a hybrid variant resistant to both side-channel and GPU-style attacks) as the first choice for new password-hashing systems, falling back to PBKDF2 only when FIPS-140 compliance is required.

The three, side by side

	PBKDF2	bcrypt	Argon2id
Defined	RFC 2898 (2000)	1999, no formal RFC	RFC 9106 (2021)
Cost dimension	Iterations (CPU only)	Cost factor (CPU only)	Time + memory + parallelism
GPU/ASIC resistance	Weaker — parallelizes well	Moderate	Strong when memory is tuned high
Input limits	None significant	Truncates past 72 bytes	None significant
Native in the browser (Web Crypto API)	Yes	No	No
FIPS-140 status	Approved	Not a NIST/FIPS algorithm	Not currently FIPS-approved

Why FileX uses PBKDF2

FileX derives the AES-256 key for every .filex container with PBKDF2-HMAC-SHA256, a random 16-byte salt, and 250,000 iterations, calling crypto.subtle.deriveKey directly — the Web Crypto API built into every modern browser. That's the deciding factor: SubtleCrypto.deriveKey supports PBKDF2, HKDF, and ECDH natively. It does not support Argon2 or bcrypt. Getting either of those into the browser means shipping a third-party WebAssembly implementation and trusting it the way you'd trust any dependency — which cuts against FileX's rule of using only the browser's own audited, self-hosted crypto primitives with nothing extra to fetch or verify.

That's an honest trade-off, not a claim that PBKDF2 is the strongest KDF available. Argon2id's memory-hardness is a genuine advantage against large-scale GPU cracking, and if you're designing a server-side login system today, OWASP's guidance to prefer Argon2id over PBKDF2 is worth following. FileX's use case is different in one respect but not immune to the same math: it derives a file encryption key from a password, not a login-check hash, but an attacker who obtains a .filex file still faces the same offline brute-force economics — the salt and iteration count are exactly what slow them down. FileX's 250,000 iterations sit well above the NIST floor of 10,000, though below OWASP's newer 600,000-iteration figure for stored password verifiers; iteration counts are a moving target as hardware gets faster, which is why the cheat sheets keep raising them.

The practical upshot for you: the KDF is only half the defense. A long, random password does more for your file's security than any iteration count can compensate for on its own — generate one in your browser with the same zero-upload guarantee. For the full picture of how the derived key gets used — AES-256-GCM, the random IV, the authentication tag that rejects tampering — see how AES-256-GCM keeps your files safe.

Takeaway

All three — PBKDF2, bcrypt, Argon2 — exist to make password guessing slow, not to make encryption itself stronger.
PBKDF2 and bcrypt cost CPU time only; Argon2 also costs memory, which is why it resists GPU/ASIC cracking better.
Web browsers only implement PBKDF2 natively (via the Web Crypto API), which is why FileX — and most in-browser crypto — uses it rather than Argon2 or bcrypt.
The password you choose still matters more than the KDF choice. Encrypt a file in your browser — nothing is uploaded, and the live monitor on the page proves it.