Preparing for “EOL”

[In software parlance, EOL means this. But of course we’re not talking about software, we’re talking about people!]

A few weeks ago, we lost a colleague to an unexpected heart attack/stroke. He was 45, and left a wife and three kids. His oldest was barely into her teens, so they have their whole life ahead of them. Apart from the tragedy of losing the bread-winner, it soon became apparent that no one, not even the wife, knew anything about the family’s financial situation.

This led to some serious thinking on my part. I was already using KeePassXC on my laptop (KeePassDX on Android) to maintain all my passwords, and I was periodically sending a copy to my wife and kids. But that was barely a couple of megabytes, so I just used Signal Messenger to send it to them.

I needed a way to safely keep a bunch of PDFs or scans of various documents that my family would need if I were to be unavailable. I took a look at what I needed, and it turned out to be more than 40-50 MB – too much for Signal.

The problem was, how to make sure this file was available to my family any time, but without compromising security. I came up with the following requirements:

usability: the solution must be usable on Windows, Linux, and Android
availability: no cloud services (because of the catch-22 of how to access them!)
security: it should of course be encrypted with a password
redundancy: there should be multiple copies with multiple people (wife, kids, brothers, cousins, friends)
- although the password need not be known by all of them, only wife and kids
automation: file should be synchronised automatically (if possible)

The simplest method is to use a ZIP file. But there is one important caveat.

The ZIP format had a problem – some versions are vulnerable to what is called a “known plaintext attack” (see “appendix 1” below). It took barely a few minutes to find that the zip file generated by the standard “Info-ZIP” package on Linux is vulnerable. Luckily, all the other software I tested (7z on Linux, Fossify File Manager and Ghost Commander on Android) produced zip files that did not have this problem. I did not test anything on Windows, but I am positive that 7zip on Windows will be safe. Peazip uses 7zip under the covers to produce a zip file so that should also be safe. I don’t know, nor care, about non-open-source tools – one should never use proprietary tools for security-related tasks anyway.

So, the first step is to create this file on my laptop, and keep it updated (for example when I renew my health insurance every year, or get my end-of-year statement from the bank, etc).

The second step is to send this file to a certain bunch of people. I eventually realised this takes several forms.

For my own phone, I am already using Syncthing to sync my laptop and my phone, so this file becomes part of that.
Similarly for my wife and my son, I have also setup Syncthing to backup their data, so it was easy to add a copy of this file into that mix.
- Syncthing synchronises both ways, so this works.
- Syncthing works even though my son lives in another country !
For other copies, since the file does not have to be super-uptodate, I would take any opportunity to send the file via USB, or Pairdrop, or other similar tools – to a brother, a friend, etc. Since the file is encrypted, I also have a copy on a USB stick sitting right there on my desk.

This leads to the most important (and maybe the hardest) part of this: the password! I needed a password that (a) is at least 20+ characters, (b) is impossible for anyone outside my family to guess, and yet (c) is quite memorable for my wife and kids.

I was lucky to find a few good candidates for this, based on family events and shared experiences and inside jokes.

Appendix 1: What’s a “known plaintext attack”?

A simple way to describe it is this: let’s say I created a zip file with about 20 documents inside it. Then let’s say I have to send one of those documents – say a PDF of my passport – to someone, for a legitimate reason. Then that someone effectively has the password to the entire ZIP file. In other words: every file within the ZIP file is effectively a kind-of, sort-of, “password” for the entire ZIP file!

The tool to use to test this is at https://www.unix-ag.uni-kl.de/%7Econrad/krypto/pkcrack.html, if you want to try. Luckily, my experiments show that most newer versions of any ZIP software are probably safe. If in doubt, use a really long password (20 or more characters); that reduces the risk considerably – enough that for normal people’s data it’s probably not a concern any more.

Appendix 2: Geopolitics

A side note: 7zip is by a Russian author. I generally avoid software by Chinese and Russian authors. Not that I don’t trust the authors themselves, but, using 7zip as an example, it is quite possible for Igor Pavlov to be forced by the FSB to include a backdoor in 7zip, on pain of him or a loved one being thrown out of a window or fed Polonium.

However, I am making a considered exception for 7zip because it has been around for such a long time, and in such wide use, that I (fondly) hope any supply chain attack on it will be detected by someone outside Russia if it happens. Plus I don’t think Putin really wants my financial and medical details ;-)

On the other hand, I do think government agencies or large enterprises should not be using 7zip or its derivatives.

It’s really sad that 7z appears to be the only tool on Linux that produces safe zip files, though if push comes to shove one can always use Info-ZIP but create a zip inside a zip to bypass the known plaintext attack vulnerability. (I.e., zip inner.zip my-files then zip -e outer.zip inner.zip and put a (long) password on that. Extraction of an individual document (e.g., PDF of my passport, to use my previous example), takes two steps now, but that PDF cannot be used to attack outer.zip!)