• Stars
    star
    1,146
  • Rank 40,695 (Top 0.9 %)
  • Language
    Rust
  • License
    GNU General Publi...
  • Created almost 7 years ago
  • Updated about 1 month ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Paper backup generator suitable for long-term storage.

paperback

NOTE: While paperback is currently fully functional, all of the development of "paperpack v0" is experimental and the format of the various data portions of paperback are subject to change without warning. This means that a backup made today might not work with paperback tomorrow. However, once there is a proper release of paperback, the format of that version of paperback will be set in stone and any new changes will be done with a new version of paperback (paperback can detect the version of a document, so older documents will always be handled by paperback).

paperback is a paper-based backup scheme that is secure and easy-to-use. Backups are encrypted, and the secret key is split into numerous "key shards" which can be stored separately (by different individuals), removing the need for any individual to memorise a secret passphrase.

This system can also be used as a digital will, because the original creator of the backup is not required to be present (or consent to) the decryption of the backup if enough of the "key shards" are collected. No individual knows the secret key (not even you), and thus no party can be compelled to provide the key without the consent of k-1 other parties.

To make this system as simple-to-use as possible, paperback creates several PDFs which you can then print out and laminate, ready for recovery. Here are some examples of the generated documents:

Mockups Current Status
Main Document
Key Shard

These "key shards" can then be given to a set of semi-trusted people. paperback also supports (k, n) redundancy, allowing for n key shards to be created but only k being required in order for the backup to be recovered.

"Semi-trusted" in this context means that you must be sure of the following two statements about the parties you've given pieces to:

  1. At any time, at least k of the parties you've given pieces to will provide you with the data you gave them. This is important to consider, as human relationships can change over time, and your friend today may not be your friend tomorrow.

  2. At any time, no party will maliciously collude with more than k-1 other parties in order to decrypt your backup information (however, if you are incapacitated, you could organise with the parties to cooperate only in that instance). Shamir called this having a group of "mutually suspicious individuals with conflicting interests". Ideally, each of the parties will be unaware of each other (or how many parties there are), and would only come forward based on pre-arranged agreements with you. In practice, a person's social graph is quite interconnected, so a higher level of trust is required.

Each party will get a copy of their unique "key shard", and optionally a copy of the "master document" (though this is not necessary, and in some situations you might want to store it separately so that even if the parties collude they cannot use the "master key" as they do not have the "master document"). We recommend laminating all of the relevant documents, and printing them duplex (with each page containing the same page on both sides).

Note that this design can be used in a more "centralised" fashion (for instance, by giving several lawyers from disparate law firms each an individual key shard, with the intention to protect against attacks against an individual law firm). Paperback doesn't have a strong opinion on who would be good key shard holders; that decision is up to you based on your own risk assessment.

A full description of the cryptographic design and threat model is provided in the included design document.

Usage

Paperback is written in Rust. In order to build Rust you need to have a copy of cargo. Paperback can be built like this:

% cargo build --release
warning: patch for the non root package will be ignored, specify patch at the workspace root:
package:   /home/cyphar/src/paperback/pkg/paperback-core/Cargo.toml
workspace: /home/cyphar/src/paperback/Cargo.toml
    Finished release [optimized] target(s) in 3m 42s
% ./target/release/paperback ...

The general usage of paperback is:

  • Create a backup using paperback backup -n THRESHOLD -k SHARDS INPUT_FILE. The -n threshold is how many shards are necessary to recover the secret (must be at least one), the -k shards is the number of shards that will be created (must be at least as large as the threshold). The input file is the path to a file containing your secret data (or - to read from stdin).

    The main document will be saved in the current directory with the name main_document-xxxxxxxx.pdf (xxxxxxxx being the document ID), and the key shards will be saved in the current directory with names resembling key_shard-xxxxxxxx-hyyyyyyy.pdf (with hyyyyyyy being the shard ID).

  • Recover a backup using paperback recover --interactive OUTPUT_FILE. You will be asked to input the main document data, followed by the shard data and codewords. The output file is the path to where the secret data will be output (or - to write to stdout).

    Note that for key shards, the QR code data will be encoded differently to the "text fallback". This is because it is more space efficient to store the data in base10 with QR codes. As long as you copy the entire payload (in either encoding), paperback will handle it correctly.

    Paperback will tell you how many QR codes from the main document remain to be scanned (they can be input in any order), as well as how many remaining key shards need to be scanned (along with a list of the key shards already scanned).

  • Expand a quorum using paperback expand-shards -n SHARDS --interactive. The -n shards number is the number of new shards to be created. You will be asked to input enough key shards to form a quorum.

    Paperback will tell you how many remaining key shards need to be scanned (along with a list of the key shards already scanned).

    The new key shards will be saved as PDF files in the same way as with paperback backup.

  • Re-generate key shards with a specific identifier using paperback recreate-shards --interactive SHARD_ID.... You can specify as many shard ids as you like. Shard ids are of the form "haaaaaaa" ("h" followed by 7 alphanumeric characters). You can specify any arbitrary shard id.

    This operation is mostly intended for allowing a shard holder to recover their key shard (which may have been lost). Using recreate-shards is preferable because (assuming you're sure the ID you recreate is the ID of the shard you originally gave them) it means that they cannot trick you into getting new distinct shards by pretending to lose an old shard. The recreated shards are identical in almost every respect to the old shards (except with a new set of codewords), so having many copies gives you no more information than just one.

    Paperback will tell you how many remaining key shards need to be scanned (along with a list of the key shards already scanned).

    The new key shards will be saved as PDF files in the same way as with paperback backup.

  • Re-print an existing paperback document using paperback reprint --[type] --interactive. --[type] can either be --main-document or --shard and indicates what type of document needs to be reprinted.

    You will be asked to enter the data of the document you have specified. The new document will be saved as a PDF file in the same way as with paperback backup.

    When reprinting a main document, paperback will tell you how many QR codes from the main document remain to be scanned (they can be input in any order).

Note that when inputting data in "interactive mode" you have to put an extra blank space to indicate that you've finished inputting the data for that QR code. This is to allow you to break the input up over several lines.

Currently, paperback only supports "interactive" input. In the future, paperback will be able to automatically scan the data from each QR code in an image or PDF version of the documents.

Paper Choices and Storage

One of the most important things when considering using paperback is to keep in mind that the integrity of the backup is only as good as the paper you print it on. Most "cheap" copy paper contains some levels of acid (either from processing or from the lignin in wood pulp), and thus after a few years will begin to yellow and become brittle.

Archival paper is a grade of paper that is designed to last longer than ordinary copy paper, and has standardised requirements for acidity levels and so on. The National Archives of Australia have an even more stringent standard for Archival paper and will certify consumer-level archival paper if it meets their strict requirements. Though archival paper is quite a bit more expensive than copy paper, you can consider it a fairly minor cost (as most users won't need more than 50 sheets). If archival paper is too expensive, try to find alkaline or acid-free paper (you can ask your state or local library if they have any recommendations).

In addition, while using hot lamination on a piece of paper may make the document more resistant to spills and everyday damage, the lamination process can cause documents to deteriorate faster due to the material most lamination pouches are made from (not to mention that the process is fairly hard to reverse). Encapsulation is a process similar to lamination, except that the laminate is usually made of more inert materials like BoPET (Mylar) and only the edges are sealed with tape or thread (allowing the document to be removed). Archival-grade polyester sleeves are more expensive than lamination pouches, though they are not generally prohibitively expensive (you can find ~AU$1 sleeves online).

The required lifetime of a paperback backup is entirely up to the user, and so making the right price-versus-longevity tradeoff is fairly personal. However, if you would like your backups to last indefinitely, I would recommend looking at the National Archives of Australia's website which documents in quite some detail what common mistakes are made when trying to preserve paper documents.

It is recommended that you explain some of the best practices of storing backups to the people you've given shard backups to -- as they are the people who are in charge of keeping your backups safe and intact.

For even more recommendations (from archivists) about how best to produce and store paper documents, the Canadian Conservation Institute has publicly provided very detailed explanations of their best practice recommendations. Unfortunately, there aren't as many details given about what a producer of a document should do.

License

paperback is licensed under the terms of the GNU GPLv3+.

paperback: resilient paper backups for the very paranoid
Copyright (C) 2018-2022 Aleksa Sarai <[email protected]>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <https://www.gnu.org/licenses/>.

More Repositories

1

orca-build

Build OCI images from Dockerfiles.
Python
180
star
2

filepath-securejoin

Proposed filepath.SecureJoin implementation
Go
85
star
3

mkonion

A simple way to create a Tor onion service for existing Docker containers.
Go
82
star
4

devgibson

Hackers in yo' kernel!
C
59
star
5

redone

A *correct* implementation of regular expression matching (using finite state automata).
Python
48
star
6

matrix-utils

Random matrix-related scripts.
Python
32
star
7

remainroot

A set of shims to allow unmodified programs to run nicely in rootless containers.
C
31
star
8

heisig-rtk-index

A Complete Index of Heisig's "Remember the Kanji" 6th Edition
Python
29
star
9

dotfiles

... everybody needs one, right?
Shell
29
star
10

rawline

A small, self-contained line editing library.
C
21
star
11

cyphar.com

My personal website.
Shell
18
star
12

initrs

[OUTDATED] Please switch to https://github.com/openSUSE/catatonit
Rust
17
star
13

voicemail-check

A small web app to check if your (Australian) voicemail is vulnerable to information disclosure.
Python
13
star
14

talks

Source for all talks I've presented at various conferences
PostScript
12
star
15

ascii-snake

A remake of the old Nokia Snake game.
C
12
star
16

sched

A simple scheduler (non preemptive) for the Arduino, written in C.
C
11
star
17

ttu

A small tool that silently converts TCP sockets to Unix sockets.
C
10
star
18

parcel

Proposal for an OCI image extensions for *completely static* distribution.
Go
7
star
19

synge

An unholy hack that can do too many things.
C
6
star
20

hacktoberfest-anti-spam

Automatically detects, closes, and flags PRs made by users who are likely to be part of the Hacktoberfest spam.
JavaScript
4
star
21

radial

A totally rad(ial) circular buffer implementation for GNU/Linux.
C
3
star
22

seccomp-nova

A new container-focused seccomp-cBPF generation library for runc.
3
star
23

ncss

My solutions for various NCSS Challenge years.
Python
3
star
24

keplerk2-halo

A research project to see if photometry can be done on halo contamination of K2 postage stamps.
Python
3
star
25

tic-tac-toe

A heuristic implementation of the classic game.
C
3
star
26

pure-quartic-solitons

PQS Research Project
Python
3
star
27

heartthreader

Mass, multithreaded testing for servers against Heartbleed (CVE-2014-0160).
Go
2
star
28

perfectgift

Group 4's 2014 NCSS Project.
Python
2
star
29

comp3520

COMP3520 2019
C
2
star
30

undertale-docker

Knowing that you can run UNDERTALE in a Docker container fills you with determination.
Shell
2
star
31

comp2129

COMP2129 2017
C
2
star
32

ncss-2020-syd-group1

"Should I Go Outside" Bot
Python
2
star
33

docksh

Use a Docker container as your shell.
Shell
1
star
34

jpn-stardicts

GitHub-based Mirror of Freely-Licensed Japanese Dictionaries
1
star
35

awful-travel-bot

An absolutely useless travel bot. It probably doesn't even know what countries are.
Python
1
star
36

ScrambleEbook

A calibre plugin to scramble eBook contents to be sharable (without infringing copyright) for bug reports.
Python
1
star
37

epyc

Embedded PYthon Code (a templating engine).
Python
1
star