What I want to achieve:

I intend to burn a few dozen of single-layer Blu-Rays, 25GB, M-Discs with data that are precious to me in an encrypted form.

  • The hardware needed - Blu-Ray writer and the M-Discs - I already have.

  • I have chosen AES-256 as the encryption method for the data.

Operating systems / platforms which has to be supported by the solution:

  • Linux Mint (18)

  • GNU/Linux Debian (9)

  • Cygwin (on Windows 10)

This may or may not change in the future; let's suppose it would change rather than not.

What software would you recommend me to do the storage?

The conditions follow:

  • The data can't be compressed further, so no compression needed.

  • Generic Linux and Cygwin access needed.

  • I would rather have individual files encrypted, than for instance one VeraCrypt containter for everything.

  • It should have a CLI (command-line interface) so that I could decrypt it on a headless server too.

I think 7-zip with no compression option could do this job well, but I rather ask before I could make a mistake, I would regret later on.

  • 7-zip is open-source, I compile it myself on my Linuxes

  • It supports AES-256

  • It has CLI interface

I forgot to tell you how far to the future I am looking: about 20 years.

  • Hardware: Don't forget you will need a disk reader. What about USB thumb drives? (I haven't researched this). Storage format: How about FAT32 or exFAT? Software: What about something along the lines of CypherSaber, i.e. something simple enough you can write it yourself. I would implement it in C for longevity. It doesn't have to be performant, only reliable. Archive the source code along with your encrypted data. I don't think you need to archive a virtual machine or complier if you write in C. Use standard libraries only.
    – jrw32982
    Commented Dec 12, 2017 at 19:20

3 Answers 3


I just want to finish this Q&A with an actual accepted solution.

I have written POSIX shell scripts available on GitHub using openssl for both encryption and decryption of my files.

So far they are very simple, I intend to make a few enhancements this year.

  • Nice. I see so many requests here where I think to myself "Well, a text editor and a few cups of coffee and I could have a basic version working..." Even better that you used F/OSS to do it.
    – ivanivan
    Commented Dec 15, 2017 at 2:45

This is comment, rather than an answer, but it grew rather too large for a comment box.

I am not going to answer your question, since there a missing details and unforeseeables. However, here is some advice:

No matter what you chose:

  • make sure to use a program where you have the source code, and archive that along with the encrypted documents.
  • also, archive any compiler or interpreter which is required to build and run the encryption program.
  • In the past, I might have considered recommending psychosocially archiving a machine to run the software. However, it ought to be enough to use an o/s which has been, or can be easily, emulated.
  • if all docs are human readable, not binary, then I would recommend converting them to PDF, to make them more cross platform (also consider LaTex).

You might consider saving a virtual machine, although you can't be sure that you will be able to run it in future (how far in the future?)

If I have to give an answer, it would depend on time. Anything over 20 years and I would recommend no software solution, but a physical. Print it on archival paper and put it in a safe in an environmentally sound room. The combination of the safe is your encryption.

  • 20 years ago, I was still using DOS, and some quaint old Word Perfect format :-) Things might be accelerating, so think carefully about how you can reduce risk if there are great changes in future
    – Mawg
    Commented Dec 8, 2017 at 9:58
  • 1
    archiving the source code: do not forget about dependencies (such as linked libraries). That can become tricky. The VM approach seems much more reliable. After all, even today we can run a DOS VM and attach an USB-floppy to it to read those 3.5" plastic squares. Though I couldn't find one for those 5.25" or even 8" flabber-disks – and at least the 5.25" were still quite common in the mid-90s :)
    – Izzy
    Commented Dec 8, 2017 at 15:33
  • thanks, Izzy. I just started a new job in Bremen and I raised this topic yesterday. We generate code from a tool and version control the tool data, but not the tool. They seemed at first not to understand the concept that we might want to recreate an old build. Now we are making a list of everything required to recreate the executable. I will double check that we include the libraries too.
    – Mawg
    Commented Dec 9, 2017 at 9:20
  • And, yes, I still have 8" disks - but how can I read my punch-cards & punched tape? This is a serious point for the OP. back in 19umpteen we just assumed that we would always be able to read those
    – Mawg
    Commented Dec 9, 2017 at 9:22


I found myself in a similar situation a while back. I wanted a portable, open-source, fairly future-proof encryption tool, preferably AES 256. Container-based encryption was not an option as I wanted to store the files online (Dropbox) and be able to edit individual files without re-uploading a big container.

I found two candidates fulfilling my requirements:

  • 7-Zip (with no compression)
  • openssl

I ended up picking 7-Zip for the standardized file format and the wide availability of tools capable of 7-Zip encryption/decryption, and thus that's my recommendation.

After settling on 7-Zip I developed a set of command line tools - 7zetools - wrapping 7-Zip on Linux/Mac and facilitating single-file (or single-directory) encryption. It made it a breeze automating encryption of the files, as well as later on opening or editing the same files.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.