Thierry Moreau
Fri, 22 Jun 2007 12:18:11 -0700
Very interesting discussion.I bring a different angle to the very topic of discussion ("practical use"). See below, after the quotes which I fully agree.
Peter Gutmann wrote:
"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. [...] 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. [...] working at the very geeky crypto toolkit API level (where you're allowed to be 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.
Here is a different perspective.Forget about mathematics (who wants to go farther than 2 out of 3, 3 out of 4, and 2 out of 4).
Forget about an API: think first of a potential application area.Forget about HCI (Human Computer Interface): focus on the control/liability allowed/implied by a key share and the administrative procedures.
Forget about processors and computers altogether!If I didn't lose you yet, think of secret sharing for the *long-term cryptographic key material* for DNSSEC support at the root.
I.e. share the control over delegation of DNSSEC *routine* signature operations (to IANA staff in the foreseeable future) among secret sharing entities, say USG NTIA, an European entity, and a third one elsewhere.
Store the key shares on paper sheets of bar codes - the user interface is a safe box for the secure hardware, and a diplomatic briefcase for transport layer.
Actually, secret sharing implies significant procedural overhead for key management, and hence may find applications only in "master keys" of some orgnizations.
I did propose a scheme where the above principles are implicitly put forward, i.e. TAKREM for DNSSEC (root) trust anchor key rollover. The above "long-term cryptographic key material" is specified in the TAKREM documentation (perhaps other "routine" public key cryptoperiod management schemes might use the same principles for secret sharing).
From some of those who develop interoperability specifications (i.e. IETF participants) I was called a "patent troll". From those organizations who control the Internet, i.e. USG NTIA, Verisign, and ICANN, I seem to be nobody. Hence the proposal made little progress.
In summary, to answer the question "practical use of secret sharing", I don't see it in my crystal ball. Nonetheless, control of DNSSEC root signature key would be a good candidate application area for secret sharing.
Admittedly, the above change in perspective does not solve "the difficulty people have in managing keys in general" -- it merely shifts it from trusted system administrators to diplomats and like individuals. (A DHS sponsored study even ignored or downplayed mere split key storage for protecting the DNSSEC root private key.)
Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]