Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Psst: Paper-Based Secret Sharing Technique (github.com/sjlver)
149 points by PaulHoule on Jan 12, 2024 | hide | past | favorite | 30 comments



I'd like it if there was a centralized shared secret system available from the following sources: my credit union, my local & state govt, and the fed govt. I'd like to be able to set an arbitrary K-of-N recovery with an additional S "individual" recoverers. I don't mind it being publicly available (it's encrypted!); maybe 16KB for the whole account?

This is because it'd be a way for people to establish identity: let a third party write to my shared account, and I can prove I own it by decrypting the message.

The govt aspect is to prove who I am & establish residence for things like voting, DL#s, birth certificate recovery, passports...


The state part is a pipe dream except in a few specific countries. In some countries nobody would actually trust the system, some simply lack the ressources or educated gov workers to run it. In most rich countries the bureaucrat-industrial-complex (including the national software consultants) would fight tooth and nail against a system that deprives them of sweet sweet taxpayer money. OTOH I'd say Switzerland, Estonia and Costa Rica could actually get it done.


Alas, psst can't help with that. With psst (or indeed any secret sharing scheme), there is a single secret which is only split while at rest. In order to actually make use of the secret, it needs to be recovered from the shares.

Your use-case would probably use other techniques, such as multi-signature schemes, multiparty computation, and zero knowledge proofs. Decentralized identity management is a difficult problem.


As for identification, with the German eID (EU-wide standard for identity cards with an NFC chip) you can get a PGP key signed online. Maybe that's the same for other countries too.


This is fun. I've been designing something similar involving encryption via a custom deck of 64 cards and long term durable secret storage in base-4 as differently sized washers on a bolt (with labels so you only have bother decoding it in extreme circumstances like a house fire).

I think more cryptography should be designed with simplicity as a goal. Being unsure if you can trust the computer should not exclude one from secure communication.


> encryption via a custom deck of 64 cards

Instead of a custom deck, you could use a standard 78 card tarot deck and remove or just ignore one of the 14 card suits. Now you can buy encryption decks at many game or book stores and it's something people might plausibly have sitting around the house.

Do you have any more details about the card or bolt/washer systems anywhere? They both seem like cool ideas.


Well it's kind of cringy because when I was working on it actively I was rather enamored with crypto, much of the prose didn't age well.

But here are some interesting artifacts:

- https://github.com/MatrixManAtYrService/thred.store/blob/mas...

- https://github.com/MatrixManAtYrService/thred.store/tree/mas...

The idea was that if you're going to bind significant value to an artifact that can be stolen it should be:

- kind of heavy, like... not pickpocketable

- hard to destroy, like... can survive a fire or being buried for a million years (happens in some scifi I'm writing)

- made of things you can commonly get with cash, so nobody can look at your purchase history and know you have one

The thought was that we could use it in math class. Sort of like an alternate reality where basic numeracy meant something different.

I can't quite recall the details of why, but I remember that if you do three washers per base-64-symbol, and you stick to messages which are multiples of four symbols long, then any conversions that a student is likely to to are unlikely to run into weird issues involving padding (equals signs are used by base64 converters to say "no data here, but not zero's either', I wanted to sheild the user from having to think about that).

Also, humans are good at preserving near-exact copies of prose, so if you need an entropy source you can take a particular scene in a novel and strip it of non-base64 characters, and use it (in addition to other entropy sources) as a sort of one-time-pad.

I was also working on social key recovery. It would be unreasonable in today's world to expect that average folk would be carrying out such an algorithm by hand, but supposing that it was indeed considered basic numeracy, maybe not. Especially if it's the only way to gain access to your inheritance because something dystopian has happened to the legal system. (Nowadays I'm not sure I think that generational value transfer is a good idea, but this is a snapshot of how I was thinking about it 6 years ago).

As for the cards themselves, I wanted one side to show you how to encode that base64 symbol in washers on a bolt, and the other side to show you how to add/subtract that symbol with every other base64 symbol. There were going to be encryption / decryption mats which told you where to lay the cards and how to carry out the operations.

I was going lock up some money, compromise half of the social-key-recovery scheme at a talk at defcon or somesuch, and see if the community could crack into the other half. I figured I'd just put more money in the prize wallets every year and use the "the money is still there" as a source for warm fuzzy feelings about the security of the system.

The you-cant-trust-computers-and-there-are-no-banks future (probably fiction, possibly not) that I was preparing for... it's not coming as soon as I thought at the time. I still might pick this back up and propose it for use in math classrooms and such, but I haven't been giving it much energy lately.


Have you seen Solitaire by Bruce Schneier [1]? There are issues with it, but it is still interesting.

[1] https://www.schneier.com/academic/solitaire/


Nice!

I like the idea of washers on a bolt. One could conceivably purchase five different sizes to make your idea compatible with psst. A similar idea also exists as a commercial product: https://jlopp.github.io/metal-bitcoin-storage-reviews/review...

At some point during the design of psst, I considered using GF(4) instead of GF(5). I chose GF(5) mainly because it supports up to four shares. It's also slightly more efficient to encode a-z text, and to obtain a random digit using a dice.

Good luck for the card-based encryption!


Plug: I also build a shamir secret sharing tool. It can do unlimited parts https://simon-frey.com/s4/


Very cool!

When designing psst, I considered implementing it as a self-contained website. The advantages would be (1) ease of use, and (2) more features.

In contrast, psst is a simpler design, so simple that the entire system fits on two pages of paper. I never quite managed to make a self-contained website that was small enough to understand/print/etc. Thus, psst is targeted towards people who want a system that they can fully understand and verify, whereas s4 is easier to use.

I was also worried that people might end up with enough shares, but no possibility to reconstruct them. With psst, shares are fully self-contained. A user with two shares has all they need to obtain the secret, plus typically some context that tells them what to do with the secret. With s4, this is a bit more tricky: imagine your heirs finding some papers with s4 shares; they would have to find the s4 website first. Maybe your domain name has since expired and they need to dig a copy out of archive.org...

Have you thought about ways to solve this? For example, it would be nice if s4 could generate zip files containing a share, and all the files needed to run the s4 decoder. (Assuming that zip, JavaScript, and WebAssembly are still easily usable in 2044.)


Very nice! Is there a reason why the start and end signature is different? s4 v0.5 || S4 vs s4 v0.5||S4

Also is it a security risk if you would include in the secrets how many are needed for decoding?


Is there a pattern to how the dice grids are constructed? I'm not finding an explanation in any of the documentation. If they are generated in some deterministic way, it would be possible to memorize the pattern and rebuild the grid on-demand. That would create some fun possibilities for passing messages to other people who are familiar with the system.

To be clear, I'm talking about these grids:

  0  0 0 0 0
  0  1 2 3 4
  0  2 4 1 3
  0  3 1 4 2
  0  4 3 2 1
  0  re-throw


Yes. The 25 rows of the table correspond to the 25 linear polynomials in GF(5), evaluated at x=0, 1, 2, 3, and 4.

GF(5) is the "field" that psst uses. It just means that all math is performed using only digits 0 to 4, and we take the remainder modulo 5 after each operation. A linear polynomial has the form `ax + b`. There are 25 of them because `a` and `b` can each take one of the five values.

For example, consider the polynomial `3x + 0`. If you evaluate it at x=0, the result is 0. At x=1, it's 3. At x=2, it's 6, which corresponds to 1 in GF(5). At x=3, the result is 4, and at x=4, the result is 2. These values (0 3 1 4 2) form the fourth line in the table above.

The table on the first page of the worksheet and the table on each share all have the same rows. They are just sorted differently, to make it easier to lookup a given row.


Thank your for the explanation! The modulo was a big piece that I was missing.

I still need to spend some time understanding how the math guarantees unique combinations of values, but I did figure out how to generate the series now (in Ruby).

  (0..4).map do |b|
    (0..4).map do |a|
      (0..4).map do |x|
        (a * x + b) % 5
      end.join(" ")
    end.join("\n")
  end.join("\n\n").then { puts _1 }
EDIT: To make this line up with the document, I actually had to offset a by the value of b. I'm still not totally sure why this is necessary.

  (0..4).map do |b|
    (0..4).map do |a|
      (0..4).map do |x|
        ((a - b) * x + b) % 5
      end.join(" ")
    end.join("\n")
  end.join("\n\n").then { puts _1 }


Both versions of your code generate the same polynomials (i.e., rows of the table), but in a different order.

The order doesn't affect psst. This is why each page of the worksheet shows the polynomials in the order that's most convenient for the situation at hand.

The only place where the order matters is in choosing which dice throw is assigned to which polynomial. In psst, the dice throws correspond to share #1.


Reminds me of https://superbacked.com/ and https://github.com/Twometer/hyperbacked which is an open source clone of superbacked.

Both Generate Encrypted QR parts using Shamir's secret sharing.


Thanks for the link! I hadn't known about these projects. Superbacked and psst have a similar starting point, but end up being quite different:

Superbacked is a company selling you a backup service for small secrets. They offer a fair amount of features that are no doubt well thought through, albeit closed-source. As their user, you put some trust in the company, their product, and the expectation that they will still exist in a few years time, when you need to recover your secret.

Hyperbacked removes a few of these drawbacks by virtue of being open-source. It's easier (but not necessarily easy) to understand. It's probably easier to use than psst, although power users would want to set up an airgapped computer...

Psst, in contrast, is a humble open-source repo, giving you a PDF that you can fully understand and inspect, with no additional dependencies. I hope it's fun to use. It might even help some people with backing up secrets :)


Yeah you are right. It is more like https://bs.parity.io/#/-BananaSplit-shamir


Cool! In a similar vein, I've wondered if it's possible to design a reasonably secure zero knowledge proof or challenge/response scheme that's simple enough to be performed using only mental math and maybe some simple physical tools like playing cards or dice (ideally no pen and paper). This way you could prove that you know some secret without it ever even leaving your brain. If it can be done without any external tools at all, then you could even use it in public settings without any fear of your secret leaking.


Checkout Solitaire by Bruce Schneier [1].

> In Neal Stephenson’s novel Cryptonomicon, the character Enoch Root describes a cryptosystem code-named “Pontifex” to another character named Randy Waterhouse, and later reveals that the steps of the algorithm are intended to be carried out using a deck of playing cards. These two characters go on to exchange several encrypted messages using this system. The system is called “Solitaire” (in the novel, “Pontifex” is a code name intended to temporarily conceal the fact that it employs a deck of cards) and I designed it to allow field agents to communicate securely without having to rely on electronics or having to carry incriminating tools. An agent might be in a situation where he just does not have access to a computer, or may be prosecuted if he has tools for secret communication. But a deck of cards…what harm is that?

> Solitaire gets its security from the inherent randomness in a shuffled deck of cards. By manipulating this deck, a communicant can create a string of “random” letters that he then combines with his message. Of course Solitaire can be simulated on a computer, but it is designed to be implemented by hand.

[1] https://www.schneier.com/academic/solitaire/


Related: https://www.secretcodex32.com/

Codex32 is another paper-based computer design for performing secret sharing for Bitcoin Master Seeds (and could be repurposed for other similar secrets). It comes with a set of volvelles for performing the sharing and recovery.

Codex32 also contains a checksum that can be used to correct up to 4 errors / 8 erasures / 13 consecutive erasures in each share. Validating the generated checksum helps ensure that mistakes during splitting are caught.

https://www.secretcodex32.com/docs/2023-03-07--color.pdf is the PDF of the Codex32 booklet.


There's another tool like this called horcrux, which I find to be a better name personally.


This is a problem (doing it simply enough for a physical system to work) that I've been turning over head during idle moments for a while. Very nice to see that somebody else has seen it through, and shared the result. Kudos!


I wonder how easy it would be to memorize all of the tables, so you wouldn't even need to rely on the pieces of paper as a possible point of attack. (Fallible memory allowing, of course...)

The other question is: would there be any weaknesses if I used this scheme multiple times to encode a longer message – for example, a 48-long passphrase?


The tables are public knowledge. Memorizing them does not give you any extra security. It might hide the fact that you are using psst. This might make you less of a target for attacks (but probably has a very small or zero effect). It also increases the chance that your secret is lost, for example when your shares are accidentally thrown in the trash because they look like random pieces of paper.

For your other question: There is no weakness when using psst for long messages. That said, weaknesses can be introduced if you don't follow the protocol properly. For example, if you use the same dice throws for more than one psst instance, the system is no longer secure.

This page has further examples for things that could go wrong: https://github.com/Sjlver/psst/blob/main/docs/what-can-go-wr... It can give you a feeling for what kind of use is safe vs unsafe.


Such a fun way to introduce cryptography. My mind was blown this summer when I took a discrete math course this summer. Using math to encrypt and decrypt data is elegant and pure.


The documentation for this project, especially the design choices, is excellent.


Thought this was the Rust Spotify client at first


Honestly I am more excited about the python code that generates the SVG workbook. I am going to borrow that technique!




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: