How to Securely Share Files Without Cloud Services
Key Takeaways
- For a one-time handoff, an encrypted removable drive or an end-to-end encrypted transfer tool can avoid storing files in a cloud account.
- SFTP is the practical choice for controlled transfers to known recipients, but SSH host-key verification and restricted accounts are essential.
- Syncthing suits recurring synchronization between devices you control; verify device IDs before accepting a connection and understand when relays are involved.
- Encryption protects confidentiality, while checksums confirm that received bytes match the original file. Neither proves a file is safe to open.
“No cloud” can mean several different things. It may mean no third-party storage account, no public link, no vendor-operated service, or no internet connection at all. Those are different threat models. A USB drive passed in person avoids network exposure but can be lost. A direct peer-to-peer transfer avoids storing the file in a conventional cloud drive, but it may still use a relay server to establish or carry a connection.
The right method depends on distance, the recipient’s identity, the security of both endpoints, file size, and whether access is temporary or ongoing. Before sharing anything sensitive, make sure the recipient’s device is trustworthy. Encryption cannot protect a file after it is opened on a compromised computer.
For related practical security guidance, see Hubkub’s how-to section and cybersecurity coverage.
Choose a Method Based on the Situation
| Situation | Best approach | Why it fits | Main caution |
|---|---|---|---|
| Same location; recipient and device are trusted; very large files; one-time transfer | Encrypted removable drive | No network service is required and transfer speed is limited mainly by the drive and ports. | Physical loss, theft, and incompatible encryption formats. |
| Remote recipient; known and technically capable; one-time or occasional delivery | SFTP over SSH | Uses authenticated, encrypted transport and offers administrative controls. | Do not skip SSH host-key verification or reuse a broad server account. |
| Your own devices or a small trusted team; recurring access | Syncthing | Designed for ongoing folder synchronization without a central cloud drive. | Every authorized device receives the synced data; remove old devices promptly. |
| Remote, one-off transfer; recipient has limited technical skills | Magic Wormhole or an encrypted archive sent by an agreed channel | Short-lived, code-based exchange can be simpler than operating a server. | Some transfers may use relays; verify the transfer code out of band. |
Start With File Encryption and Integrity Checks
Encrypt a sensitive file before transfer when practical. This creates a second layer of protection if a drive is misplaced, a transfer destination is misconfigured, or a recipient forwards the file accidentally.
For a simple cross-platform handoff, create an encrypted archive with a well-maintained tool that supports AES encryption. The 7-Zip format supports AES-256 encryption, including optional encryption of archive headers, which prevents filenames from being visible without the password. See the official 7-Zip format documentation for the format’s encryption details.
Use a passphrase generated randomly, not a memorable sentence assembled from personal facts. A strong practical method is six randomly selected words from a sufficiently large list. The Electronic Frontier Foundation’s long word list contains 7,776 words; six independently selected words provide roughly 77 bits of search space when selected fairly at random. Use a trusted random generator or physical dice, following the EFF Dice-Generated Passphrases guidance. Do not choose the words yourself, and do not send the passphrase in the same email, chat thread, or USB envelope as the encrypted file.
Create a SHA-256 checksum before sending a file, then share that checksum through a separately authenticated channel. On macOS and Linux, shasum -a 256 filename will generate one; on Windows, Get-FileHash filename -Algorithm SHA256 does the same. A matching checksum establishes byte integrity: it shows that the received file matches the original file used to create the hash. It does not establish that the file is malware-free, safe to open, or from the person claimed unless the checksum itself was authenticated.
Use an Encrypted Removable Drive for In-Person Transfers
For large files exchanged locally, an encrypted SSD or USB flash drive is often the least complicated option. It is particularly useful for video footage, backups, disk images, and data sets that would be inconvenient to upload or relay over the internet.
Pick an Encryption Format Deliberately
On Windows, BitLocker To Go can encrypt removable drives. Microsoft documents that encrypted removable data drives can be unlocked with a password on compatible Windows systems; confirm the recipient can unlock the drive before relying on it. See Microsoft’s BitLocker To Go FAQ.
On macOS, FileVault is intended for encrypting a Mac’s startup disk, not as the normal method for encrypting an external drive. Disk Utility can erase a compatible external drive using an encrypted APFS or Mac OS Extended format, but that is primarily appropriate for Apple devices. Apple’s Disk Utility documentation explains the available erase and format options.
For mixed Windows, macOS, and Linux use, encrypting the files in a cross-platform archive may be less troublesome than encrypting the whole drive. Test opening the encrypted archive on the recipient’s device before travelling or deleting the source copy.
Handle the Drive as a Security Boundary
Label the drive with a contact method, not a description such as “Payroll” or “Medical Records.” Deliver the password through a separate channel, confirm the recipient’s identity before disclosure, and securely erase temporary copies after the recipient confirms receipt. On solid-state media, secure deletion is not always straightforward because of wear leveling; encryption from the beginning is safer than relying on deletion later.
Use SFTP for Controlled Remote Delivery
SFTP runs over SSH and is a strong option when you can administer a server or use a trusted recipient’s server. It is better suited to professional transfers than emailing attachments because it supports key-based authentication, restricted accounts, logs, and predictable folder permissions.
Verify the SSH Server Before Uploading
The first connection to an SSH server is a critical moment. Obtain the server’s SSH host-key fingerprint from the administrator through a separate trusted channel, then compare it with the fingerprint shown by your SSH client. Do not blindly accept a changed host key. OpenSSH documents host-key checking and the StrictHostKeyChecking setting in its ssh_config manual. This prevents an attacker from silently impersonating the server during a man-in-the-middle attack.
Use separate SSH keys for separate people or workflows. The recipient should confirm their public key fingerprint through a known contact method before you authorize it. Password-only accounts are a poor fit for sensitive exchanges because passwords are easier to reuse, disclose, or phish.
Restrict the Account and Clean Up
Create a dedicated account or destination folder for each recipient rather than granting access to a general administrator account or a shared home directory. OpenSSH supports restrictions in authorized_keys, including restrict, no-pty, forced commands, and forwarding controls. These options are documented in the OpenSSH authorized_keys format. A properly restricted file-transfer account should have access only to the folder and functions it needs.
After delivery, remove the recipient’s key or disable the account, delete server-side copies that are no longer required, and review transfer logs. Retention is a security decision: leaving a “temporary” download directory online for months defeats the purpose of a controlled handoff.
Use Syncthing for Ongoing Device-to-Device Sharing
Syncthing is a useful choice for continuously synchronizing folders between your own computers, phones, NAS devices, or a small group. Its model is not a public download link: every participating device is explicitly added and receives synchronized content according to the folder configuration.
Verify a new device ID by comparing it through a separate channel, such as a voice call or in-person scan. Syncthing’s security documentation explains that device IDs are derived from device certificates and that connections are authenticated and encrypted. Do not approve an unfamiliar device simply because it appears in the interface.
Syncthing may establish direct connections when possible, but it can use relay servers when direct connectivity fails. Its relay documentation states that relay traffic is encrypted end to end, so the relay cannot read the transferred content; however, using a relay still exposes connection metadata to that relay and may affect performance. Review the official relaying documentation before treating it as an entirely infrastructure-free workflow.
Use receive-only folders carefully, avoid syncing confidential folders to devices that are shared or rarely updated, and remove retired phones or laptops from every shared folder. Syncthing is highly private against a conventional cloud-storage provider in this threat model, but it is not protection against an authorized device being stolen, infected, or used by the wrong person.
For One-Off Remote Transfers, Verify the Code
Magic Wormhole is designed for direct, short-lived exchanges using a human-readable code. Its protocol uses password-authenticated key exchange, meaning the code helps establish an encrypted transfer without sending the secret itself as ordinary plaintext. The project documents the design in its official Magic Wormhole documentation.
Read the transfer code to the recipient over a separate trusted channel. If an attacker can alter the code in the same compromised chat session where the file invitation was sent, they may be able to redirect the transfer. Also be aware that connectivity tools can rely on transit or relay infrastructure when peers cannot connect directly. “No cloud storage account” does not automatically mean “no third party can observe connection metadata.”
Frequently Asked Questions
Is email with a password-protected ZIP file secure enough?
It can be acceptable for low-to-moderate sensitivity if the archive uses strong encryption, the passphrase is randomly generated, and the passphrase is delivered through a different channel. It is a poor choice for highly sensitive material when email accounts, mailboxes, or recipient devices may be compromised.
Can I trust a checksum as proof that a file is safe?
No. A checksum confirms that file bytes have not changed relative to the original checksum. It does not scan for malware or prove that the original file was benign. Use endpoint protection, file-type controls, and cautious handling for untrusted files.
What should I delete after a secure transfer?
Delete temporary archives, server-side staging copies, obsolete SSH keys, and unnecessary synchronized-folder access. Retain only what your organization, project, or legal obligations actually require.







