question re practical use of secret sharing

Thierry Moreau thierry.moreau at connotech.com
Fri Jun 22 13:23:13 EDT 2007



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" <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.  [...]
> 
> 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: thierry.moreau at connotech.com

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



More information about the cryptography mailing list