DEV Community: Aayush

How I Built an End-to-End Encrypted File Sharing App with Flask and ChaCha20 in 30 Days

Aayush — Fri, 23 Jan 2026 17:20:26 +0000

TL;DR: I built a self-destructing file sharing app in 30 days. Files are encrypted with ChaCha20-Poly1305, passwords are hashed with Argon2id, and everything deletes after one download. On launch day, I found a race condition that would have let attackers bypass my password limit. Here's the full story.

Aayushbankar / onetimeshare

Secure, one-time file sharing web app

🚀 One-Time Secure File/Text Sharing App

30-Day Build Challenge

🔴 LIVE DEMO: https://onetimeshare.onrender.com

📸 Screenshots

🧐 The Problem

Sharing sensitive information (API keys, passwords, configuration files) via email, Discord, or WhatsApp is insecure. Third-party services like Pastebin or WeTransfer store your data on their servers, creating a privacy risk.

💡 The Solution

Build a lightweight, containerized Python web application that allows you to:

Upload a file or text snippet.
Generate a unique, secure link.
Permanently delete the data from the server immediately after it is viewed once (or after a short timer expires).

Project Overview

Goal: Build a secure, one-time file sharing application within 30 days. Timeline: December 24, 2025 → January 24, 2026 Tech Stack:

Backend: Python / Flask
Storage: Dockerized Redis (Ephemeral storage)
Containerization: Docker
UI: Bootstrap
CI/CD: GitHub Actions

🚀 Quick Start (Docker - Recommended)

The fastest way…

View on GitHub

The Problem

Every developer has done it.

Shared an API key in Slack. Sent a .env file over WhatsApp. Pasted credentials into a Discord DM.

These messages live forever. They're indexed. They're searchable. They're a breach waiting to happen.

I wanted a tool where:

Files are encrypted at rest (the server can't read them)
Files delete themselves after one download
Password protection is zero-knowledge (the key never touches the server)

Existing tools either store data indefinitely, require accounts, or cost enterprise money.

So I built my own. In 30 days. In public.

The Stack

Component	Choice	Why
Backend	Flask (Python 3.13)	Lightweight, flexible, I know it
Database	Redis	TTL auto-expiry = perfect for ephemeral data
Encryption	ChaCha20-Poly1305	Constant-time, used by Signal, no AES-NI needed
KDF	Argon2id	Memory-hard, GPU-resistant
Deployment	Docker + Render	Free tier, Gunicorn-ready

Why ChaCha20 over AES-GCM?

AES-GCM performance varies based on hardware (AES-NI). ChaCha20-Poly1305 is software-optimized and constant-time everywhere — critical for containerized deployments where you don't control the CPU.

The Build: Week by Week

Week 1: Foundation (Days 1-7)

Day 1: Flask application factory, Dockerfile, docker-compose with Redis.

Day 2: Core upload endpoint. UUID filenames (path traversal prevention), extension validation, 20MB limit.

Day 3: The first "graveyard" moment.

I built an entire RedisService class. Flask ignored it completely.

The bug: Missing __init__.py.

Two hours. Zero bytes of actual code.

Day 6: Atomic self-destruct with Redis WATCH/MULTI/EXEC:

pipeline.watch(token)
metadata = redis_client.hgetall(token)
if metadata:
    pipeline.multi()
    pipeline.delete(token)
    pipeline.execute()
    return metadata

Week 1 Bug Count: 29

Week 2: The Security Core (Days 8-14)

This is where 80% of the bugs lived.

Day 10: The HTTP Statelessness Disaster

I implemented password retry limits:

# THE BUG
attempts = 0
if attempts > 5:
    block_user()
attempts += 1

26 bugs in one day.

All from the same root cause: I forgot that HTTP is stateless. Python variables don't persist across requests. The retry counter had to live in Redis.

The lesson: Every persistent state must be externalized.

Day 14: The DoS I Built

My "security" feature: delete files after 5 wrong passwords.

The attack I didn't consider: anyone could delete anyone's file by sending 5 wrong passwords.

The fix: Lock files, don't delete them. Deletion = DoS vector.

Week 3: Encryption and Hardening (Days 15-21)

Day 16: Streaming Encryption

The naive approach: read entire file into memory, encrypt, write back.

The problem: 500MB file = 500MB RAM = OOM kill.

The solution: 64KB streaming chunks:

def encrypt_file_chunked(input_path, output_path, key):
    base_nonce = os.urandom(12)  # Unique per file
    cipher = ChaCha20Poly1305(key)

    with open(input_path, 'rb') as infile:
        with open(output_path, 'wb') as outfile:
            chunk_num = 0
            while chunk := infile.read(64 * 1024):
                chunk_nonce = increment_nonce(base_nonce, chunk_num)
                encrypted = cipher.encrypt(chunk_nonce, chunk, None)
                outfile.write(len(encrypted).to_bytes(4, 'big'))
                outfile.write(encrypted)
                chunk_num += 1
    return base_nonce

Critical detail: Nonce = base_nonce + chunk_number using arithmetic addition. XOR would cause collisions.

Day 20: Load Testing

Ran Locust across 3 tiers:

Tier 1 (30 users): 174 RPS, 355ms p95
Tier 2 (100 users): 116 RPS, 1.3s p95
Tier 3 (300 users): 97 RPS, 3.5s p95

Result: Grade A, 0% error rate. Production-ready.

Week 4: Launch (Days 22-30)

Days 22-25: CI/CD (GitHub Actions), Playwright E2E tests, security headers (CSP, HSTS, X-Frame-Options).

Day 29: Deep security audit. Fixed nonce edge cases, added constant-time comparison.

Day 30: The audit that almost didn't happen.

The Day 30 Crisis

9 PM. Launch day. Everything ready.

I almost shipped.

Then I ran one more pass.

Critical Bug #1: Race Condition

# THE BUG
attempts = int(metadata.get('attempt_to_unlock', 0))
attempts += 1
metadata['attempt_to_unlock'] = str(attempts)
redis_service.store_file_metadata(token, metadata)

The attack: 50 parallel requests hit this simultaneously.

All 50 read attempts = 0
All 50 compute attempts = 1
All 50 write attempts = 1

Result: 50 password guesses for the price of 1. My "5 attempt limit" was fiction.

The fix: Atomic increment:

# THE FIX
def increment_file_attempt(self, token: str) -> int:
    return self.redis_client.hincrby(token, "attempt_to_unlock", 1)

HINCRBY is atomic. Redis serializes operations. No race condition possible.

Critical Bug #2: Missing CSRF

Admin login had no CSRF token.

The attack: Login CSRF. Attacker forces victim to log into attacker's account.

The fix: Flask-WTF. 15 minutes.

The Architecture

┌─────────────────────────────────────────────────────┐
│                     CLIENT                           │
│  Browser → Drag/Drop → Password (Optional)          │
└─────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────┐
│                 FLASK + GUNICORN                     │
│  Routes (HTTP) → Services (Logic) → Utils (Crypto)  │
└─────────────────────────────────────────────────────┘
                          │
           ┌──────────────┼──────────────┐
           ▼                             ▼
┌──────────────────────┐    ┌─────────────────────────┐
│       REDIS          │    │    ENCRYPTED DISK       │
│  Metadata (TTL: 5h)  │    │  ChaCha20-Poly1305      │
│  Atomic Counters     │    │  UUID Filenames         │
│  Rate Limit State    │    │  64KB Chunks            │
└──────────────────────┘    └─────────────────────────┘

Final Stats

Metric	Value
Days	30
Commits	60
Bugs Fixed	100+
Critical Vulns (Day 30)	6
Lines of Code	~5,000

Key Lessons

1. Read-Modify-Write = Race Condition

If you're incrementing anything in a distributed system, use atomic operations. Always.

2. Security is Logic, Not Libraries

I had ChaCha20. I had Argon2. I still had a brute-force bypass in the application logic.

3. The Final Audit is Non-Negotiable

If I'd shipped on Day 29, I'd be writing an incident report.

4. Build in Public Works

The pressure of knowing people were watching made me do the extra audit. That audit caught the race condition.

Future Roadmap

[ ] S3 integration for files > 20MB
[ ] Public API for CLI access
[ ] Mobile-optimized UI

Try It

Live Demo: onetimeshare.onrender.com

Source Code: github.com/Aayushbankar/onetimeshare

If you learned something, I'd appreciate a follow. I build in public and document everything — including the failures.

What's the scariest bug you've found on launch day? 👇

Day 0: Launching OneTimeShare30 - My 30-Day Public Build Challenge

Aayush — Wed, 24 Dec 2025 17:38:11 +0000

Day 0: Launching #OneTimeShare30 - A 30-Day Public Build Challenge

Photo by Lukas Blazek on Unsplash

Date: December 24, 2025

Status: Planning Phase

Repository: github.com/Aayushbankar/onetimeshare

Hashtag: #OneTimeShare30

Twitter: @enthusiadev
Linkedin: @aayushbankar

🎄 Christmas Eve Announcement

It's December 24th, 10:00 PM, and I'm sitting here on Christmas Eve with an idea that won't wait. Starting tomorrow, I'm embarking on a 30-day public build challenge to create something I genuinely need: a secure, one-time file sharing application.

Why today? Why not wait until after the holidays? Because good ideas don't follow calendars, and the problem I'm solving doesn't take time off.

🧐 The Problem That Keeps Me Up at Night

As a developer and student, I constantly face this dilemma:

"How do I share this API key/config file/password securely right now?"

My current options all suck:

Email attachments - They live forever on multiple servers
Discord/WhatsApp - University projects with sensitive keys exposed in group chats
Pastebin - Public by default, retention unclear
Google Drive/WeTransfer - Third-party servers storing my data
Self-built solutions - Time-consuming, over-engineered

Just last week, I needed to share a Google Gemini API key with a batchmate for our machine learning project. I spent 15 minutes debating the "least bad" option before settling on splitting the key across multiple messages. There has to be a better way.

Think about it: API keys, configuration files with database credentials, project secrets, authentication tokens - we're sharing these daily through completely insecure channels.

💡 The Vision: OneTimeShare

Imagine this workflow:

You upload a file or paste text (like that Gemini API key)
You get a unique, unguessable link
You share that link with one person
They view/download the content once
The data is permanently deleted from the server
The link becomes invalid forever

No accounts. No tracking. No permanent storage. Just secure, ephemeral sharing.

Perfect for:

Sharing API keys with teammates
Sending configuration files for projects
Temporary password sharing
Code snippets with sensitive data
Project credentials for group assignments

🗓️ The 30-Day Challenge Timeline

Start Date: December 26, 2025

End Date: January 24, 2026

Duration: 30 days of daily progress

Weekly Breakdown:

Week 1: Foundation & Planning (Dec 26 - Jan 1)

Flask application setup
File upload system
Text snippet handling
Unique URL generation

Week 2: Core Features (Jan 2 - Jan 8)

One-time view implementation
Timer-based expiration
Password protection
API development

Week 3: Security & Polish (Jan 9 - Jan 15)

Advanced security measures
Rate limiting and abuse prevention
Docker optimization
Testing suite

Week 4: Advanced Features & Launch (Jan 16 - Jan 24)

Performance optimization
CI/CD pipeline
Documentation
Public launch

🛠️ Technology Stack Decisions

After much deliberation (and several cups of coffee), here's what I'm going with:

Component	Choice	Why
Backend Framework	Flask	Lightweight, easy to prototype, Python ecosystem
Containerization	Docker	Reproducible environments, easy deployment
Ephemeral Storage	Redis	Built-in TTL, fast in-memory operations
Frontend	Bootstrap 5	Responsive, minimal CSS, rapid UI development
Database	SQLite (for metadata)	Simple, file-based, no setup required
Hosting	DigitalOcean/Railway	Affordable, developer-friendly
CI/CD	GitHub Actions	Free, integrated with repository

📁 Day 0: What I've Built Today

1. GitHub Repository Setup

The foundation is live: github.com/Aayushbankar/onetimeshare

What's included:

Detailed README with 30-day roadmap
MIT License for open source distribution
Project structure skeleton
Issue templates for community feedback
Workflow diagram of the planned architecture

2. Initial Workflow Design

I've mapped out the core user journey:

Student/Developer Uploads API Key/Config
        ↓
Generate Unique ID (UUID + timestamp)
        ↓
Encrypt Data (AES-256)
        ↓
Store in Redis with TTL (5 min - 24 hr)
        ↓
Return Unique URL to User
        ↓
Teammate Accesses URL
        ↓
Decrypt & Serve Data
        ↓
DELETE from Redis Immediately
        ↓
Invalidate URL Forever

3. 30-Day Daily Breakdown

Each day has specific, achievable goals. No vague "work on backend" tasks. For example:

Day 1 (Tomorrow):

Flask "Hello World" application
Basic file upload endpoint
Docker container setup
HTML template with Bootstrap

Day 8:

One-time view implementation
Database flags for "viewed" status
Atomic operations to prevent race conditions

🤔 Why Build in Public?

This isn't my first project, but it's my first public build challenge. Here's why I'm doing it:

1. Accountability

When you tell the internet you're going to do something, you're more likely to actually do it. No more abandoned side projects.

2. Community Wisdom

I don't know everything. By sharing my process, I'll get feedback from people who've solved similar problems.

3. Learning Acceleration

Mistakes made in public are lessons learned faster. If I architect something poorly, someone will (hopefully kindly) point it out.

4. Portfolio Building

A 30-day public build with documented challenges and solutions is better than any resume bullet point.

5. Helping Others

If one person looks at this and thinks "I could do that too," it's worth it.

📊 Success Metrics

By Day 30, I aim to have:

✅ Working MVP with all core features
✅ 100+ GitHub stars (showing community interest)
✅ Security audit completed (or at least started)
✅ Production deployment live and working
✅ Comprehensive documentation for users and developers
✅ 10+ community contributions (issues, PRs, feedback)

👥 How You Can Participate

Level 1: The Observer

Follow #OneTimeShare30 on Twitter
Read these weekly Dev.to updates
Watch the GitHub repository

Level 2: The Supporter

Star the GitHub repository
Share updates with batchmates or colleagues who might find it useful
Give thumbs up on social media posts

Level 3: The Contributor

Open issues for feature requests or bugs
Test early versions and provide feedback
Share your expertise in the comments
Submit PRs for improvements

Level 4: The Co-Builder

Build your own version alongside me
Create complementary tools (CLI, browser extension)
Document your learnings from following along

🚀 What's Next?

Tomorrow (December 26, Day 1):

Flask application skeleton
Basic file upload endpoint (even if it just prints to console)
Docker container that runs the app
First commit to the repository

I'll be posting:

Twitter: Daily progress threads with code snippets
GitHub: Commit-by-commit development
Dev.to: Weekly retrospective articles like this one
LinkedIn: Technical deep-dives on specific challenges

❓ Questions for You

As a student/developer, how do you currently share API keys or config files with teammates?
Which security feature should I prioritize first? (Encryption, rate limiting, file validation, etc.)
Have you ever accidentally committed an API key to GitHub? (I have! 🫣)
What would make this tool genuinely useful for your projects or assignments?

🔗 Quick Links

🎄 Final Thoughts on Christmas Eve

It's almost midnight on Christmas Eve. My family is asleep, the house is quiet, and I'm excited.

Excited to build something useful.
Excited to learn in public.
Excited to see where this 30-day journey takes me.

If you're reading this, thank you. Whether you're a fellow student working on group projects, a developer tired of insecure file sharing, or just someone curious about building in public - you're part of this journey.

Here's to 30 days of building, learning, and sharing.

See you tomorrow for Day 1.

Merry Christmas, and happy building! 🎄👨💻