Ensuring an encrypted file can be decrypted in the future

Question

What is a suggested way to:

1. Encrypt a file
2. Put file on USB
3. Give USB to a 3rd party who is not that tech savvy
4. Someday in the future, somehow provide them with the password
5. Ensure that if #4 happens a long from now, the 3rd party will still be able to decrypt the file

It’s just a couple of files. Fine to encrypt files OR drive.

The cloud option could work, but wanting to ensure if Encrypted, before loading onto Google Drive, no one can decrypt without the key (which I assume is correct but want to verify).

If not in the Cloud, and on a usb, should I include the software I used to encrypt on the drive along with the file, to ensure the 3rd party knows what software to use? And if so, what if that software disappears in the future? How could they decrypt?

Answer 1

I would say it is hard to identify your usecase however assuming the following:

1. The solution needs to be used by someone that isn't tech-savvy
2. The solution needs to keep the USB and it's files as a whole secure
3. The solution needs to be future proof.

I would vouch instead to encrypt the whole drive itself using drive encryption tech like BitLocker over encrypting individual files (Step 1 and 2). This would play well with Windows (Step 3), and on the off-chance your non tech-savvy individual picks Linux, you can use applications like Dislocker. For your person they just need to plug in the device, click the USB icon, and enter the password to 'Open Up' the USB.

At this point, hold onto the recovery key incase something goes wrong (step 5), and send them the password for the USB drive when your Someday in the future comes around (Step 4).

Personally I would use a bitclocker encryption method of AES-256 seeing as this is alright future proofing. More information on BitLocker FAQs here.

Answer 2

You haven't mentioned the size of the file/s you want to encrypt, but for files up to the tens of megabytes range, I propose the use of KeepassXC which is an open-source implementation supported on all major platforms. There is also a compatible android option called KeepassDX. This tool has continued to evolve over a number of years and has an active community, so will most-likely still be current on your timeline.

Once you've created and/ or unlocked a database, you can add numerous entries of any kind, and you can also attach any files to these as well.

Your friend will need to instal software on their os - the downside of including the software with the file is this will (likely) encourage the use of an outdated version - the upside is that the software will (probably) be available without needing an internet connection to download it.

RISK OF CORRUPTION and MULTIPLE COPIES

It's worth noting that, due to the nature of the encryption protocol, only one corrupt bit will render the file unusable. This is why you need multiple copies to hopefully avoid total loss of data.

(Other answers that talk about volume encryption of the usb or some container-file, eg. bitlocker or veracrypt, are also able to address this particular problem by storing multiple copies of the source file/s, but look into header backup!)

With this solution I recommend placing multiple redundant copies of the kdbx database file onto one or more usb/ hdd/ optical/ cloud/ whatever directory (as many as you can be bothered with, but at least three). Each copy of the kdbx will keep a redundant copy of everything including the header.

DATABASE SETTINGS

You should choose kdbx version 4, as this version supports strong key-derivation password with a "hardness" factor (argon2d). The reason why this is important is that the file must remain secure for a longer period, and can potentially be subjected to an exhaustive password search over this time.

STRONG PASSWORD

This resource from the Keepass website (the product from which KeepassXC was forked) gives some advice on the security settings choice when you're creating the database for the first time: https://keepass.info/help/base/security.html#secdictprotect

I recommend using the tool's password generator to generate some random password that gives you a choice between a multi-word passphrase or a complex password. (The software comes with this built-in, just click the "fluffy dice" icon to the right of any password field.)

No matter how hard you make the key-derivation settings when you create your database, you should aim for at least 80 bits of password strength in 2022 (which equates to a 7-word passphrase, or 15-char from [0-9] + [a-z] + the "logograms" and "math symbols" groups).

CHOICE OF CIPHER

All of the three cipher options presented at the time of kdbx creation are valid choices. Depending on your cpu the default aes256 will likely be hardware-accelerated. The twofish option gives you a software-only alternative (no hardware-acceleration) which may be desirable. (These two are both block ciphers.) Meanwhile chacha20 is a good option if you need to open the db on a device that uses an arm chip, eg. a mobile phone, as one of its goals was to be implemented on lower-energy hardware. (I usually choose the latter for this reason.)

In any case, the longest wait will be the password kdf, which should take a second or two - while the encryption itself will take fractions of a second by comparison!