Secure File Transfer

Why this is a separate service

Secure file movement has different failure modes from secure text messaging. A signed file reference can state what a file should be, but transferring the bytes also requires recipient authorization, interruption handling, destination safety, integrity verification, quarantine, and an understandable operator workflow.

I kept this service separate from P2P Messaging so those boundaries remain visible. Integration is a future design task rather than an implied capability.

Operator workflow

Transfer Desk is a loopback-only browser workspace backed by the same Python core as the command-line interface. It guides a local operator through certificate generation, account creation, server startup, file selection, recipient choice, inbox review, and verified download destinations.

Passwords remain request-scoped in the interface. Dashboard request logging and caching are disabled, and a random per-session token protects local actions. The CLI remains available for automation and for inspecting behavior without the interface.

Trust boundaries

TLS protects transport only after certificate trust is established. The service therefore separates certificate setup, account authentication, recipient authorization, storage isolation, audit records, and post-transfer digest verification.

• Passwords are stored using scrypt-derived verifiers rather than plaintext.
• Authentication attempts are throttled.
• Recipient inboxes are isolated from one another.
• Paths and filenames are normalized to resist traversal.
• Upload and download records bind expected sizes and SHA-256 digests.
• Audit output avoids recording reusable passwords.

Failure and quarantine behavior

Interrupted uploads can resume from a validated offset. Downloads are written to a temporary destination, checked against the expected size and digest, and promoted only after verification. A mismatch or unsafe destination prevents the file from being presented as successful and leaves evidence for review.

The service also rejects malformed framing, unauthorized recipients, traversal attempts, and inconsistent metadata. These are application-level checks; they complement TLS rather than being replaced by it.

Measurements

I verified eight upload/download round trips totaling 13,632,512 bytes and resumed a 2,097,152-byte upload after interruption at 700,000 bytes. Sixteen automated tests cover authentication, throttling, recipient isolation, traversal attempts, interruption, tampering, quarantine, dashboard setup, and password-safe audit logging.

These measurements prove specific controlled paths. They do not prove internet-scale throughput, resistance to every denial-of-service strategy, independent cryptographic review, or safe exposure of the current local interface to an untrusted network.

Tradeoffs and next work

The application favours an inspectable Python implementation and a restrained local interface over distributed storage or a large service framework. That keeps the security boundaries understandable but leaves multi-device identity, NAT traversal, external deployment, key lifecycle, and formal review outside the current result.

Future integration with P2P Messaging requires explicit mapping between messaging identities and transfer accounts, authorization for each attachment, recovery after either peer disconnects, and a single user-visible record of message and file status.