question re practical use of secret sharing

[Peter Gutmann]

"D. K. Smetters" <smetters at parc.com> writes:

>However, given the difficulty people have in managing keys in general,
>building effective systems that allow them to manage key fragments is beyond
>the range of most current commercial products.

I think that's the perfect summary of the problem with threshold schemes.
The processes they involve is simply too complex both to model mentally for
users and to build an interface to.  If you look at the nCipher manuals (for
example
http://active.ncipher.com/documentation/nCSS/win/user/nShield_Admin.pdf), you
can see that they're really struggling to communicate the operational details
to users, and I've heard from users that it's so hard to use that few bother.
This isn't due to any failing of nCipher, the cognitive load imposed is just
so high that most users can't cope with it, particularly since they're already
walking on eggshells because they're working on hardware designed to fail
closed (i.e. lock everything out) if you as much as look at it funny.

When we were mulling it over to see whether it was worth standardising, we
tried to come up with a general-purpose programming API for it.  We were
working at the very geeky crypto toolkit API level (where you're allowed to be
somewhat non-user-friendly), not at the UI level.  Now if you compare a
standard crypto-op:

  encrypt( data, length, key );

or:

  sign( message, length, key );

with what's needed to manage a threshold scheme:

  "add share 7 of a total of 12, of which at least 8 are needed, returning an
   error indicating that more shares are required"

with a side order of:

  "using 3 existing valid shares, vote out a rogue share and regenerate a
   fresh share to replace it"

then you start coming up with an API with abstract data-access capabilities at
a complexity level of something like ODBC.

(ODBC is the most appropriate API model I could come up with without thinking
about it for too long, obviously you don't need all of ODBC but the data
representation and access model was a reasonably good fit).

So that lead to two questions:

1. Who would want to implement and use an ODBC-complexity-level API just to
   protect a key?

2. How are you going to fit a UI to that?  (This is the real killer, even if
   you come up with some API to do (1), there's probably no effectively usable
   way to do (2)).

At that de facto QED the discussion more or less ended.

Peter.

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