9
$\begingroup$

Threshold secret sharing is pretty cool, but unlike, say, public-key cryptography, I haven't really heard about it "in the wild". It appears to be confined to discussions of theoretical scenarios, as I have not found any real-world software that claims to use it "in anger".

So, are there practical examples of threshold secret sharing in commercial, or at least publicly-available, systems?

Improve this question
$\endgroup$
1
  • 2
    $\begingroup$ Secure multiparty computation often uses secret sharing. There are a number of startups out there building on top of this technology. $\endgroup$
    – mikeazo
    Apr 13, 2020 at 19:55

4 Answers 4

Reset to default
11
$\begingroup$

I worked on a secure document management project 20 years ago which used secret sharing. It is widely used in financial networks. Actual use cases with public details that are easily accessible include:

  1. Threshold key sharing is used in Hardware Security Modules, for example to unlock the administrator account. In the Amazon CloudHSM documentation, this is explained in detail: Amazon CloudHSM: About M of N
  2. Hashicorp's Vault uses Shamir's Secret Sharing during the "unsealing" process as explained here: (https://www.vaultproject.io/docs/concepts/seal.html) This enables reading and decrypting secrets from the storage backend.
Improve this answer
$\endgroup$
7
$\begingroup$

Yes, Atakama uses verifiable secret sharing in its encryption product.$^1$ Every file's AES key is secretly shared between your desktop and phone (and more devices if you want). This allows every file to be encrypted with a different key without having to remember a different password for every file or having a single point of failure.

$^1$Full disclosure: I work there.

Improve this answer
$\endgroup$
4
  • 2
    $\begingroup$ "or having a single point of failure" It would appear that you now have multiple points of failure, each being completely devastating, since it's becomes impossible to decrypt your files if 1 out of n devices ever fail. $\endgroup$
    – Maeher
    Apr 14, 2020 at 7:46
  • $\begingroup$ @Maeher: I thought the whole point of secret sharing was that you only need any m out of n devices to recover the secret (e.g. 3 out of n), so it can tolerate at least (n-m) failures? $\endgroup$
    – user1686
    Apr 14, 2020 at 8:43
  • 1
    $\begingroup$ That's threshold secret sharing, which does not seem to be what they're doing. (It also wouldn't make much sense with only two devices.) $\endgroup$
    – Maeher
    Apr 14, 2020 at 11:44
  • 1
    $\begingroup$ An n-out-of-n scheme has issues, if you're the only person with access. If you're sharing files (on a network drive or in the cloud), then as long as 1 person as all her n devices, she can provide access to anyone who has lost his device. If you need files locally, n has to be strictly greater than m. $\endgroup$
    – Aman Grewal
    Apr 14, 2020 at 12:04
5
$\begingroup$

NIST has recently been exploring standardizing various threshold cryptographic primitives. The relevant webpage is here. I imagine that page would be useful for exploring real-world use cases of it.

Particular papers in threshold crypto often explain some motivation for it as well. For example, the intro to DiSE mentions things like:

  • Secret Management Systems (with pointers to specific real-world ones)
  • Enterprise Network Authentication (again with pointers)
  • Multi-device IoT authentication (no pointers, but seems like a plausible application).
Improve this answer
$\endgroup$
4
$\begingroup$

You quite possibly have already used one, and if you haven't, you are likely to do so soon.

Rateless erasure codes (fountain codes, raptor, whatever name you use) are nothing but "secret sharing" if you want to look at them from the right angle. Indeed, the Reed-Solomon coding on a music CD is secret sharing... so if you've ever listened to a music CD, there you go.

They are used in present-time and future [1]media sharing applications.

One fundamental problem with distributing huge amounts of data to large number of clients is that a server can only do one thing at a time. Thus, you can only either process data live as it comes in, i.e. it's being streamed, or you have to wait until you have received every piece to form a complete file. Which may, in some cases, take a very long time for the last segment to be received.
Imagine a checksum error in a segment somewhere in the middle of a terabyte-sized file. This horror even has its proper name.

Secret sharing in the form of a fountain code has the advantage that you only need any N pieces. So, no matter what, after a very finite time you are good to go. One segment was corrupt? Who cares, just use the next one that comes in.

Mainstream P2P sharing software like e.g. BitTorrent does not currently use secret sharing (simply because peers are cheap, the possible gains are limited...), but there exist implementations that indeed do so. It will remain to be seen whether such a thing becomes mainstream in the future.

Improve this answer
$\endgroup$

Your Answer

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

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