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

Peter Gutmann pgut001 at cs.auckland.ac.nz
Mon Aug 2 12:21:12 EDT 2010


Jerry Leichter <leichter at lrw.com> writes:

>Here's how I would do it:  Key segments are stored on USB sticks. There's a
>spot on the device with m USB slots, two buttons, and red and green LED's.
>You put your "USB keys" into the slots and push the first button.  If the red
>LED lights - you don't have enough sticks, or they aren't valid.  If the
>green LED lights, you have a valid key. If the green LED lights, you push the
>second button (which is otherwise disabled), and the device loads your key.

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.

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



More information about the cryptography mailing list