Is this the first ever practically-deployed use of a threshold scheme?

Thierry Moreau thierry.moreau at connotech.com
Tue Aug 3 11:45:16 EDT 2010


Peter Gutmann wrote:
> 
> That's a good start, but it gets a bit more complicated than that in practice
> because you've got multiple components, and a basic red light/green light
> system doesn't really provide enough feedback on what's going on.  What you'd
> need in practice is (at least) some sort of counter to indicate how many
> shares are still outstanding to recreate the secret ("We still need two more
> shares, I guess we'll have to call Bob in from Bratislava after all").  Also
> the UI for recreating shares if one gets lost gets tricky, depending on how
> much metadata you can assume if a share is lost (e.g. "We've lost share 5 of
> 7" vs. "We've lost one of the seven shares"), and suddenly you get a bit
> beyond what the UI of an HSM is capable of dealing with.
> 

There is more than the UI at stake here, i.e. the basic functionality of 
the scheme. Say you distribute shares in a 4 out of 7 scheme (ABCDEF) 
and share A is published on the web. How do you recover from the 
remaining 3 out of 6 scheme into a 4 out of 6 scheme without having a 
key ceremony? In an ad-hoc multi-party scheme, you request 4 of the 
remaining compliant parties to destroy key material allowing them to 
participate in a group with the traitor A, but no other key material. No 
system UI, but admittedly a coordination nightmare!


-- 
- Thierry Moreau


> With a two-share XOR it's much simpler, two red LEDs that turn green when the
> share is added, and you're done.  One share is denoted 'A' and the other is
> denoted 'B', that should be enough for the shareholder to remember.
> 
> If you really wanted to be rigorous about this you could apply the same sort
> of analysis that was used for weak/stronglinks and unique signal generators to
> see where your possible failure points lie.  I'm not sure if anyone's ever
> done this [0], or whether it's just "build in enough redundancy that we should
> be OK".
> 
> Peter.
> 
> [0] OK, I can imagine scenarios where it's quite probably been done, but
>     anyone involved in the work is unlikely to be allowed to talk about it.
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list