Transmitting Material of Consequence

Jun. 10, 2024 [libre] [technology] [privacy-security] [guides]

You have a file you would like to share with a friend, or to a colleague. Something personal. Or some damning information. Either way, you want to be certain that only the recipient is able to access the data. But it needs to traverse the internet. How can you do it in a way that minimizes opportunity for SIGINT, adtech or other adversaries to eavesdrop on your exchange?

It’s really quite mundane. And I have shared file sets on occasion in such a way. Sometimes it was just because I didn’t want the recipient to access the files until after a certain date. Or because the person to whom I was sharing resides out on another continent with no chance of ever meeting in person.

The short answer is simply to symmetrically encrypt the data using GPG and then share the passphrase out-of-channel. The catch, of course, is that the lynchpin in this chain of confidentiality often comes down to the OPSEC of the person to whom you are sending files. The longer answer is rarely detailed clearly in an online guide and I would like to offer some additional tips.

Start

Have GPG 🗹

Prepare the file you wish to share

This is your opportunity to redact anything you don’t want the recipient to see. Metadata can end up betraying you, depending on the nature of the exchange and your relationship with the recipient. Strip away usernames and file ownership.

tar -cf info-dump.tar --owner=0 --group=0 --no-same-owner --no-same-permissions /path/to/info-dump

ffmpeg can manipulate file metadata with the -metadata switch parameters. mat2 is an excellent metadata scrubbing tool. And if unencrypted copies of the file(s) fall into the possession of anyone other than the intended recipient, then your device info, username, or other potentially unique information won’t be plastered all over it.

Tip

Consider padding the file(s) with junk data. If what you are transmitting is of a known filesize, an outside observer might be able to infer its likely content by filesize alone, despite it being encrypted. File compression may also foil this, although video data will change comparatively little after compression compared to something textual. It all depends on what you’re sending.

In case you don’t feel like sourcing 80 MB of cat pictures, it is possible to conjure up junk files of any size using dd.

dd bs=80M count=1 if=/dev/urandom of=junk.bin

Just include these when you assemble the file set before encrypting it.

Encrypt the file symmetrically

gpg -c --cipher-algo aes256 info-dump.tar

Will create “info-dump.tar.gpg”, prompting for a passphrase along the way. The -c switch instructs GPG to handle the passphrase with case sensitivity.

Boilerplate: Assume that adversaries will get to retain a copy of the encrypted file set indefinitely with which to brute force against. Select a long, high entropy passphrase that has not and will not be used elsewhere. The LUKS folks have a good writeup on this.

Tip

If you’ll also be transmitting the passphrase electronically, avoid transmitting both the data and its passphrase at or around the same time. Doing so will make it easier for a passive global adversary to correlate the two. Staggering transmission by several hours should suffice, although allotting several days is preferred.

Decide how each component will be sent

Something like Tox is a good candidate for sending the passphrase to the recipient. Although nothing beats offline, non-digital exchange. Pre-shared knowledge is ideal. Maybe something cryptically scribbled on a note. Although if you’re sharing files electronically at all, it stands to reason that face-to-face hand off isn’t an option.

You can use steganography to covertely share the passphrase embedded in an innocuous looking message. Email a picture of your garden “Look! The tomato plant is budding!” in which it has already been pre-embedded using stegosuite. Or send a DM which suggests passphrase reconstruction based on knowledge that you and the recipient already share. Creativity will stretch your options.

The encrypted file itself can be transmitted through any medium. A flashdrive, a file host, your web server. As long as it is through a different channel by which you’ll be sending the passphrase. I would recommend some ephemeral service. Catbox has a good option for this at litterbox.catbox.moe. Anything uploaded there will be removed after a pre-selected duration. So if you can arrange with your recipient to acquire the encrypted file within the next twelve hours or three days or whatever, it later becomes inaccessible which is perfect for this usage case.

Tip

It might be polite to include a SHA sum of the file(s).

sha512sum info-dump.tar > sha512sum.txt

Decryption

Decrcyption on thier end should be a simple matter of

gpg --output /path/to/info-dump.tar --decrypt /path/to/info-dump.tar.gpg

Once it has been decrypted, the ball is totally in their court. It might be helpful to know ahead of time if the recipient is using Windows or some other leaky botnet contrivance. And just how sensitive is the thing that you are sharing?