On Aug 1, 2010, at 7:10 AM, Peter Gutmann wrote:
Thanks to all the folks who pointed out uses of m-of-n threshold
schemes,
however all of them have been for the protection of one-off, very
high-value
keys under highly controlled circumstances by trained personnel,
does anyone
know of any significant use by J.Random luser? I'm interested in
this from a
usability point of view.
As a corollary, has anyone gone through the process of recovering a
key from
shares held by different parties at some time after the point at
which they
were created (e.g. six months later), the equivalent of running a
restore from
your backups at some point to make sure that you can actually
recover your
sysem from it? How did it go?
It'll be interesting to see the responses, but ... in this particular
case, we do actually have plenty of experience from physical
applications. Vaults that can be opened only by multiple people each
entering one part of the combination have been around for some time.
For that matter, that requires mechanisms for having multiple people
set their part of the combination. Even requirements for dual
signatures on checks beyond a certain size are precedents.
One could certainly screw up the design of a recovery system, but one
would have to try. There really ought not be that much of difference
between recovering from m pieces and recovering from one.
Of course, one wonders how well even the simpler mechanisms work in
practice. The obvious guess: At installations that actually exercise
and test their recovery mechanisms regularly, they work. At
installations that set up a recovery mechanism and then forget about
it until a lightning strike takes out their KDC 5 years later ...
well, I wouldn't place big bets on a successful recovery. This isn't
really any different from other business continuity operations:
Backup systems that are never exercised, redundant power systems that
are simply kept in silent reserve for years ... none of these are
likely to work when actually needed.
-- Jerry
Peter.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [email protected]
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [email protected]
