Split key export

[rugk]

Add an option to "borg key export", which allows to split the backup key into multiple parts, so you need "k of n" to restore it and print multiple pages.

E.g. when I have three different locations for storing the paper backup and I want to have some redundancy should one backup get lost, I could choose "2 of 3" (command e.g. borg key export --split-num 3 --split-require 2; split-require defaults to split-num and split-num is 1 by default, so that the old behaviour is the default). Then on the page with QR code or paper code or so there is another line:

Backup ID dhsai767. Piece 1 of 3. You need 1 other backup in order to restore the key.

This is somewhat similar to https://github.com/borgbackup/borg/issues/2428 for backups, but I think this issue here is far easier to implement.

[enkore]

Why not print multiple copies? If you require n-out-of-m, cut them into stripes.

Or, use tools like par2 or python-zfec.

[rugk]

Why not print multiple copies?

Because when one is stolen, the thief got the key. When you have a n of m approach you need at least 2 ones.

If you require n-out-of-m, cut them into stripes.

Haha, never thought about that, but it is really unreliable. Especially as you have the paper backup and QR code on the same site, so it may happen that one can restore the key from the half of the site by combining the information in the QR code and paper. Really, that's just not professional and can leads to problems.

That's why a n of m thing would be good, not multiple m's or so… That's not the point.

Or, use tools like par2 or python-zfec.

par2 seems to be about some error correction. Don't know what this could help here. It can also split files looking like splitted ZIP archives, but how on hell should I print them afterwards…? That's ugly.

zfec also just generates some redundant blocks of data. I have no idea how this could help with this issue/is even related to it…

---

Basically I imagine something similar to how Armory (it's FLOSS) does it. See https://www.youtube.com/watch?v=nyeMtM-Gclw. They call it "fragmented backups". They also have a secure print (https://www.youtube.com/watch?v=sm3JTO6c6NU) feature but well…

[enkore]

zfec also just generates some redundant blocks of data. I have no idea how this could help with this issue/is even related to it…

Blocked FEC implements what you describe. FEC splits some data into a number of blocks (=m) of which any subset of size k (=your n) is sufficient to reconstruct the original data. Having less blocks than the limit k yields an underdetermined system which has no unique solution, i.e. a virtually infinitely large set of solutions.

(Note that block erasure codecs, like zfec, by themselves are neither error detecting nor error correcting codes; bad blocks simply result in bad data)

Because when one is stolen, the thief got the key. When you have a n of m approach you need at least 2 ones.

The exported key is still encrypted with your passphrase. So, set a passphrase, then export.

Especially as you have the paper backup and QR code on the same site, so it may happen that one can restore the key from the half of the site by combining the information in the QR code and paper.

So... cut the QR code off?

[rugk]

Okay, I understand FEC now, but that's still a low-level utility there and as it is python you could include it in borg. And that's about all that I am asking in this issue.

I mean the thing here is a new feature ("enhancement") I am proposing and it should try to avoid trading security against usability – what is, AFAIK, also your general aim in borg. Of course I as a user could use some low-level block splitting tools like you proposed, then split the key, reencode/base64/whatever it, so I can print it in a nice way and include it in a QR code. However, that's crazy. Nobody does that. The desired behaviour would be a simple call borg key export --qr-html --split-num 3 --split-require 2 split1.html split2.html split3.html ( or similar), so you have all these backups ready. And there you can also use the nice per-line checksums in borg's paper backup e.g., which I could not use when doing my own self-created approach (which could, BTW, also be a security risk as you should never built your own crypto stuff…). And cutting of the QR code is also no solution, because of course I want that feature – QR-code scanning. That's why I'd like an implementation in borg and also urge you to reopen this. It could be in borg v2, no problem. This is a long-standing feature request. (Edit: Just saw you have a later tag, so maybe use this one here.)

Have you watched the video I linked? There you can see how such a thing can work. It's a GUI application obviously, so your implementation could be way easier in a CLI, with less explanatory things.

So finally about the point of "Why should you want to do something?". As you said:

The exported key is still encrypted with your passphrase. So, set a passphrase, then export.

Ah, yeah, of course, but people are different, people have different use cases and here are some where this feature request would be useful:

1. What if I do not want to remember a password (as I do not like them :wink: ) but just want my backup to be encrypted and store my key on paper, which is how it's currently possible in borg. Now, maybe you trust your home space enough to not have the backup sheet stolen, but this does not help you if a fire burns down your house. So you need a backup at less trusted spaces, at work, in a forest :deciduous_tree: hidden somewhere, whatever… But of course you do not want to have your whole data to be exposed when one accidentally finds your sheet. So you want to split it and distribute sheets of paper at different places. And voila… here you need this feature.
2. Maybe you have a password set, of course. But you know how weak passwords tend to be and how fast machines/computers can crack them (especially if they do not use a modern KDF, https://github.com/borgbackup/borg/issues/747). To improve your security you thus choose the keyfile mode instead of repokey (that's the only reason for choosing this mode anyway…). So you see you cannot 100%ly trust your password. So you also have to trust your local key. And yet here, you may have the same requirements as described in 1., so you want to split the key across multiple locations to increase your security.

[enkore]

I'll think about this some more when I'm not quite so preoccupied as right now.

A quick note: Please don't try to use a block erasure code (like zfec) and assume that "Having less blocks than the limit k yields an underdetermined system which has no unique solution, i.e. a virtually infinitely large set of solutions." is cryptographically secure; it is not. A subset of the blocks required to uniquely decode the message can still reveal a fraction of the original message (i.e. parts of the key).

[rugk]

Ah, okay, that's of course right. Don't know how Armory does it, it's open-source so you could have a look. However also the "algo" "cutting the piece of paper into parts" is affected by this problem.

[enkore]

That'd be secure secret sharing.