Return-Path: X-Original-To: lwip@ietfa.amsl.com Delivered-To: lwip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C1412082E for ; Tue, 17 Dec 2019 09:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwjEBvjRvG0E for ; Tue, 17 Dec 2019 09:31:19 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BBF2120C36 for ; Tue, 17 Dec 2019 09:30:56 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id e5so8049581qtm.6 for ; Tue, 17 Dec 2019 09:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=PrJWhli52e9tgeJER9efKltMZ5luKXdO8uXA4mRJUbI=; b=r3wjT62q2SRLb2XwXHw2n49AJYJjVq9iCOfe6emvENffR48rJQ4EEA4vNvAe1Jj/HY 120hsZLKUW0GzWfwJ0hkWJPcYKbfi8sMRommC+/s5vXaIrOG05A1LHgpk15w1SK5tDQM o06XbruktsT0tOJx8Wl/oEj7JPy9ADtNS3XHh5NEl7PVJlDLfwLZ+kj6LxQ9cwOfRb0v oGYWiXAYQ12/TPeqaWxeUjy9xKPucULzjb+CGkgqJCI3b8yRMNivMxiaWI7EF1upMJi1 R02q1UIPtoS5C01zkSdANdPZVcwoVoYkfZCi6F1j6JXtCcDFllAKPDEiYIvKcmIsZxSw UeGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=PrJWhli52e9tgeJER9efKltMZ5luKXdO8uXA4mRJUbI=; b=dOa9oqAEMeKT5yIY0puoFOrhhiDiEuCrn752nrVWZJ5/xUBsksFHrW/j5kkdOvZH6k 5IF4TZEEYILZoK/WfUH03eqkFrUxRWYOSy5czJ+b4XorDCGJE2yvuj8m0Ji29R8Ycgg6 iZyrIjd8pcMfu6vxEHgvEfa+V21FD4RVAIbt/xH7ICWEoJuhzEpKl+sCYX2APwlIge+3 HJxo2Qq427Ejks2akd+FkW0dysDqT1IMbRWYnspjli6swrjwgkin/5zHbHa4GsRzV2HH xI2CPFImCvc6m/mslLwHF3VUGQiDRnrTSnNQpPuFJ3hcSijz6vzyDOFAg38Kp0FYoTMm zo2w== X-Gm-Message-State: APjAAAVTfAQNidmWTQRUP8783CM3egclLWZIX984Qop1F5/4AeaaDb7G ZIw4u9UTqfMP+W4Bl32e1gFxCswL X-Google-Smtp-Source: APXvYqzvQZVIQsaFAM2leFyrZ0sjPQ96QwVgD5Rljk55lNWhXwvxPsAdKsaGjRf+sfTkbaKBilyiKw== X-Received: by 2002:ac8:1851:: with SMTP id n17mr5653390qtk.305.1576603855213; Tue, 17 Dec 2019 09:30:55 -0800 (PST) Received: from ?IPv6:2607:fea8:6a0:1a5a:c0ce:9bbd:ea1d:5e1a? ([2607:fea8:6a0:1a5a:c0ce:9bbd:ea1d:5e1a]) by smtp.gmail.com with ESMTPSA id f42sm8374801qta.0.2019.12.17.09.30.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 09:30:54 -0800 (PST) To: Phillip Hallam-Baker References: Cc: cfrg@irtf.org, lwip@ietf.org From: Rene Struik Message-ID: Date: Tue, 17 Dec 2019 12:30:45 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2689BFA19CD74A9763FC74B2" Content-Language: en-US Archived-At: Subject: Re: [Lwip] [Cfrg] Threshold cryptography on CFRG curves X-BeenThere: lwip@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 17:31:21 -0000 This is a multi-part message in MIME format. --------------2689BFA19CD74A9763FC74B2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Phil: The link below provides specifications (Appendix J) and examples (Appendix K) for representations of curve points (where these are represented in a lossless manner). While the examples only deal with curves over the field GF(p), where p=2^255-19, the specifications are general and, thereby, also can be used for, e.g., Curve448. Please see https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-08#appendix-K.1 I hope this helps. Best regards, Rene On 12/17/2019 11:54 AM, Phillip Hallam-Baker wrote: > I am working my way through an ID describing four schemes using > threshold math based on the Ed25519, Ed448, X25519 and X448 curves. > These will specify > > * Threshold Key Generation > * Threshold Decryption > * Mutual Authenticated Key Exchange > * Side channel resistance. > > I think I have the math worked out now for the Montgomery curves. > There is something of an issue with encoding signed results. In > particular for X448. > > X25519 is 255 bits = 31.7 bytes so there is a spare bit we can use to > express the sign. X448 is 448 bits = 56.0 bytes. So there is no extra > space. > > The simplest option seems to be to extend the encoding of X448 results > by one byte so that they are 57 bytes. Which is essentially what we do > for Ed448. > > Should I do the same for X25519 as well? After all RFC 7748 section 5 > says: > > For X25519, the unused, most significant bit MUST be zero. > > These results are going to need separate algorithm identifiers in any > case as they are distinct from the regular CurveX results. But the > only circumstance in which they are going to appear on the wire is in > contexts which are not covered by existing IETF protocols, that is > threshold decryption and threshold key generation. > > Also note that there is a NIST solicitation on this area: > > https://csrc.nist.gov/publications/detail/nistir/8214a/draft > > The proposals at the workshop seem to have been focused on threshold > signatures which don't hold much interest for me. If we want to know > that a document was signed by Alice and by Bob, have Alice and Bob > both sign it. Done. Can even define signature quorums (n out of m). > > The only advantage I can see in having a threshold scheme is if the > signature can sit in the exact same protocol slot that a regular one > could. And it doesn't look like RFC8032 can be adapted for that.. Or > at least, my attempt failed. > > I can split the signature between Alice and Bob so that both of them > have to co-operate to sign. But whoever assembles the contributions > can extract the private key (!). Which isn't going to work if we want > Alice and Bob to split up the signature duties. > > This constraint might be acceptable if we were designing some sort of > TPM device and splitting the signature capability between application > layer code and the TPM with the combination of the signature > contributions taking place inside the TPM. But since the TPM is going > to be able to reverse engineer the private key anyway, why not have > the application code just tell the TPM what its contribution to the > private key is... ? > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------2689BFA19CD74A9763FC74B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Phil:

The link below provides specifications (Appendix J) and examples (Appendix K) for representations of curve points (where these are represented in a lossless manner). While the examples only deal with curves over the field GF(p), where p=2^255-19, the specifications are general and, thereby, also can be used for, e.g., Curve448.

Please see https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-08#appendix-K.1

I hope this helps.

Best regards, Rene

On 12/17/2019 11:54 AM, Phillip Hallam-Baker wrote:
I am working my way through an ID describing four schemes using threshold math based on the Ed25519, Ed448, X25519 and X448 curves. These will specify

* Threshold Key Generation
* Threshold Decryption
* Mutual Authenticated Key Exchange 
* Side channel resistance.

I think I have the math worked out now for the Montgomery curves. There is something of an issue with encoding signed results. In particular for X448.

X25519 is 255 bits = 31.7 bytes so there is a spare bit we can use to express the sign. X448 is 448 bits = 56.0 bytes. So there is no extra space.

The simplest option seems to be to extend the encoding of X448 results by one byte so that they are 57 bytes. Which is essentially what we do for Ed448. 

Should I do the same for X25519 as well? After all RFC 7748 section 5 says:

For X25519, the unused, most significant bit MUST be zero.

These results are going to need separate algorithm identifiers in any case as they are distinct from the regular CurveX results. But the only circumstance in which they are going to appear on the wire is in contexts which are not covered by existing IETF protocols, that is threshold decryption and threshold key generation.

Also note that there is a NIST solicitation on this area:

https://csrc.nist.gov/publications/detail/nistir/8214a/draft  

The proposals at the workshop seem to have been focused on threshold signatures which don't hold much interest for me. If we want to know that a document was signed by Alice and by Bob, have Alice and Bob both sign it. Done. Can even define signature quorums (n out of m).

The only advantage I can see in having a threshold scheme is if the signature can sit in the exact same protocol slot that a regular one could. And it doesn't look like RFC8032 can be adapted for that.. Or at least, my attempt failed.

I can split the signature between Alice and Bob so that both of them have to co-operate to sign. But whoever assembles the contributions can extract the private key (!). Which isn't going to work if we want Alice and Bob to split up the signature duties.

This constraint might be acceptable if we were designing some sort of TPM device and splitting the signature capability between application layer code and the TPM with the combination of the signature contributions taking place inside the TPM. But since the TPM is going to be able to reverse engineer the private key anyway, why not have the application code just tell the TPM what its contribution to the private key is... ?


_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------2689BFA19CD74A9763FC74B2--