Re: [DNSOP] [dnsext] New Version Notification for draft-mcgrew-tss-02 (fwd)

Michael StJohns <mstjohns@comcast.net> Wed, 11 March 2009 22:49 UTC

Return-Path: <mstjohns@comcast.net>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D9428C21C for <dnsop@core3.amsl.com>; Wed, 11 Mar 2009 15:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.938
X-Spam-Level:
X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXUZr72rIHjU for <dnsop@core3.amsl.com>; Wed, 11 Mar 2009 15:49:04 -0700 (PDT)
Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id E3D3228C221 for <dnsop@ietf.org>; Wed, 11 Mar 2009 15:49:03 -0700 (PDT)
Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA02.westchester.pa.mail.comcast.net with comcast id RubY1b04D0cZkys52yphh3; Wed, 11 Mar 2009 22:49:41 +0000
Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA10.westchester.pa.mail.comcast.net with comcast id Rypg1b00G4LCBKY3WypgdH; Wed, 11 Mar 2009 22:49:41 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 11 Mar 2009 18:49:40 -0400
To: David McGrew <mcgrew@cisco.com>
From: Michael StJohns <mstjohns@comcast.net>
In-Reply-To: <150BF658-516A-4643-A0C5-34AFADEE6700@cisco.com>
References: <150BF658-516A-4643-A0C5-34AFADEE6700@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <20090311224903.E3D3228C221@core3.amsl.com>
Cc: namedroppers@ops.ietf.org, Alfred HÎnes <ah@tr-sys.de>, dnsop@ietf.org
Subject: Re: [DNSOP] [dnsext] New Version Notification for draft-mcgrew-tss-02 (fwd)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 22:49:05 -0000

At 06:27 PM 3/11/2009, David McGrew wrote:
>Hi Mike,
>>Hi Alfred -
>>A better scheme for threshold signing for the root might be the  
>>Shoup paper: "Practical Threshold Signatures", Victor Shoup (sho@zurich.ibm.com ), IBM Research Paper RZ3121, 4/30/99
>>The major difference between the two is that the Shamir system  
>>(which you describe) requires the base secret (private key) be  
>>reconstituted (by a trusted entity) before it can be used, where the  
>>Shoup system allows partial signatures with a public gather  
>>function.  E.g. In a 3 of 5 system, each of the 3 key share holders  
>>partial-sign the data using their share of the private key and send  
>>it (as public data) to a central location where a gather function is  
>>used to form the actual signature.
>I agree that threshold signatures have nice security properties, and  
>that Shoup's PTS method looks good, especially because its signature- share generation step does not require any interaction between the  
>signers.
>
>As you say, the TSS draft lacks the partial-signature capability, but  
>TSS does have the benefit of simplicity.
>>Shamir is nice in that it can be used for any set of key bits. But  
>>the reconstitution requirement is a point of weakness where the  
>>actual private key may be compromised. The Shoup system is only  
>>specified for RSA as far as I know.
>Shoup's PTS method requires the use of a trusted dealer to generate  
>the private keys of all of the signers.   So while it eliminates the  
>need for a trusted dealer during the signing step, it does not  
>eliminate that need entirely.  (At least this is the case for the  
>paper that you cited above; if there is work that eliminates the  
>trusted dealer, I would be very interested to see it.)
>
>best regards,
>
>David

Hi David -

What I would recommend doing here is build a computer and set it up with no connections to the outside world.  Load it with the generation software and the public keys of the N share holders.  Connect it to a printer.  Run the generation software and then print out the 5 public key wrapped shares armored as HEX ascii in an OCR font.  Destroy the hard drive.   Melt, burn, magnetize, disassemble, etc.

Send the wrapped shares off to the various share holders.  Have them OCR them into the encrypted key shares they'll use later to do the signing.

The ceremony for doing the generation in a reasonably trusted manner and ensuring that information doesn't leak is manageable.. :-) 

But it would be nice if we didn't need a trusted dealer....

Mike