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?

  • welcome - the infosec aspect of this question is straight-forward: strong password + the choice of open software, and will depend largely on your runtime environ/ os (please edit your q to include this info) ; but how iron-clad of a guarantee do you want to be able to recover from the usb in question?
    – brynk
    Jul 10, 2022 at 23:30
  • I have Mac, 3rd party most likely Windows. But when it has to be opened by them, I can just tell them to use a Mac and they will figure it out. This is not about how to provide the password. It’s about what type of encryption I should use for a file on a USB, then they will then be able to decrypt down the road. I think the idea is simple, I just don’t know the “best” way to get strong encryption and ensure they will be able to decrypt using the password, at some point in the future.
    – MrBob2022
    Jul 11, 2022 at 20:26
  • 2
    Why not just encrypt the file using 7zip (or something similar, which uses AES encryption under the hood), then put the encrypted file on a USB and give it to the other party. When it is time to decrypt, just give them the password. 7zip is available on just about every platform.
    – mti2935
    Jul 11, 2022 at 20:31
  • 3
    @mti2935 and keep a copy of 7zip stored on the USB as a fail-safe
    – schroeder
    Jul 11, 2022 at 20:38
  • 1
    @MrBob2022: What future do you mean? In 1-2 years? In 10-20 years?
    – mentallurg
    Jul 11, 2022 at 20:57

2 Answers 2


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.

  • OP asked for a file, not an entire drive. For all you know, the file could be 10mb. A drive could be terabytes (and include sensitive information).
    – user279911
    Jul 11, 2022 at 6:15
  • 1
    can a bitlocker volume be placed into a file container, and then later mounted as a drive? (ie. in a manner similar to veracrypt, formerly truecrypt?) this article seems to imply that it can: howtogeek.com/193013/…
    – brynk
    Jul 11, 2022 at 10:46
  • @free_coupons_for_sale_1023 For all we know drive size could be anything. I'm being pragmatic here and most corporates that have to transfer files use BitLocker. This is because of BitLockers connection with Microsoft making it easy to use with Windows, and the assurance that whatever bits are written to the drive will be encrypted (underlying encryption). Jul 11, 2022 at 10:57
  • @brynk you sure can, you can do the following in the article and carry around the encrypted VHD (would be funny to bitlocker encrypt a drive to hold an encrypted VHD). Thank you for the article too didn't realise and worth noting here that this feature would require a professional or enterprise edition of Windows Jul 11, 2022 at 11:02
  • The point is that encrypting an entire drive compared to a single file is completely unnecessary. However, the larger point is that it is extremely insecure, as you are revealing the entire contents of your drive (not just the file). If you're recommending @brynk's method, then I ask (on behalf of OP and all future readers) that you edit your answer to make it explicit that you are talking about a virtual hard-drive that only contains the file.
    – user279911
    Jul 11, 2022 at 22:25

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.


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.


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.


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).

KeepassXC password generator


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!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .