"D. K. Smetters" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]