End-to-End Encrypted File Sharing with Verifiable Keys

The problem: most cloud storage can read your files

Small professional offices share sensitive documents every day: a law firm sending case files, a clinic sharing reports, an accountant collecting tax documents and ID scans. In practice these travel as email attachments, messaging app files or links to ordinary cloud storage. Ordinary cloud storage is encrypted at rest, but the provider holds the keys, so an insider, a breach or a legal demand can expose the files.

End-to-end encryption removes the provider from the trust chain by encrypting in the browser. The cost is that key management becomes the product's hardest problem.

What already exists and the gap

• Tresorit and Proton Drive offer end-to-end encrypted cloud storage and sharing, with business plans.
• Cryptomator encrypts files client-side before they reach any cloud, and its Hub product adds team sharing.
• Wormhole shares files with end-to-end encryption and links that expire.

These are good products, but they are closed or complex systems you cannot study end to end, and most users never verify keys, so a compromised server could in principle substitute its own. Messaging apps like Signal show a better pattern with safety numbers that users compare. The gap for an FYP is a small, fully explained sharing system that makes key verification a first-class feature and documents its limits honestly.

What you build

• Office admin: invites staff, sees who has access to which folder, never sees contents.
• Staff member: uploads files, shares with colleagues or external clients, verifies contacts' fingerprints.
• External recipient: opens a share, creates keys in the browser, downloads and decrypts.

The server stores ciphertext blobs, wrapped file keys, public keys and metadata. It never sees a private key or plaintext.

The technically interesting part

Key distribution is the attack surface. If the server hands out public keys, a malicious server can hand you its own key instead of your recipient's and read everything you share. Fingerprint verification (comparing a short code in person or over a phone call) is the standard defence. Implement it, pin verified keys locally, and warn loudly when a verified contact's key changes. Then build a test harness where the server is malicious and show the client detects it.

Honest limits. Your system does not protect against a compromised browser or device, against your own server serving malicious JavaScript, or against metadata analysis showing who shared with whom and when. Stating this precisely in the threat model shows real understanding; claiming complete security shows the opposite.

The non-negotiable rule. Use WebCrypto primitives only. Never implement a cipher. The project is protocol design and key management.

How to evaluate it

• Security tests: automated scenarios including key substitution, tampered ciphertext, expired links and revoked access, all behaving as documented.
• Performance: encryption and upload time for files of 1 MB, 50 MB and 500 MB on a mid-range laptop.
• Usability: at least 8 participants share a file and verify a fingerprint; record success rate and where they got confused.
• Review: have someone outside the team review the protocol document and record their findings.

Suggested plan

1. Weeks 1 to 4: threat model and protocol document first, reviewed with your supervisor.
2. Weeks 5 to 10: accounts, key generation and wrapping, single-user encrypted upload.
3. Weeks 11 to 15: sharing, recipient flow, chunked large files.
4. Weeks 16 to 20: fingerprint verification, key change warnings, malicious server tests.
5. Weeks 21 to 24: revocation, expiry, usability study.
6. Weeks 25 to 28: external review, fixes, final report.

Path to a product

A realistic first customer is a small law firm or clinic that currently shares documents over email or messaging apps. Offer a hosted version per seat, or a self-hosted licence for firms that want the server in their own office. Open sourcing the client code helps trust, because customers can verify the encryption happens where you say it does.

Scope warning

Two-party and small group sharing only. Large group key management and forward secrecy for files are research areas. Do not build document editing, previews or search over encrypted content in the core scope.

Learn what you need on Sefism

• Backend roadmap : APIs, storage and auth for the server side.
• MDN: HTTP : headers, content security policy and caching that affect a crypto web app.
• OWASP ASVS : verification requirements for the parts outside the crypto.
• Where to start in cybersecurity or IT operations : where applied cryptography fits in a security career.
• Full-stack cheat sheet : quick reference while building the web client and API.

Get help with this idea

The quality of this project is in the protocol document and the threat model, not the upload button. Tauseef can help you scope the sharing model, review your protocol design, and plan evaluation that shows real understanding. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session