[Cfrg] draft-irtf-cfrg-curves question
"Jim Schaad" <ietf@augustcellars.com> Mon, 28 December 2015 19:17 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAAB1A90A7 for <cfrg@ietfa.amsl.com>; Mon, 28 Dec 2015 11:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 6ahPnF45HDup for <cfrg@ietfa.amsl.com>; Mon, 28 Dec 2015 11:17:25 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B871AC39D for <Cfrg@irtf.org>; Mon, 28 Dec 2015 11:17:25 -0800 (PST)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 6F9A72CA06 for <Cfrg@irtf.org>; Mon, 28 Dec 2015 11:17:24 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: "'cfrg@irtf.org'" <Cfrg@irtf.org>
Date: Mon, 28 Dec 2015 11:14:43 -0800
Message-ID: <04db01d141a4$028c34c0$07a49e40$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdFBozT6EQnUdRrTROWbvD8WKyXOAA==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/Tr6wLf1ElSda51Z_CUj83_iTlR8>
Subject: [Cfrg] draft-irtf-cfrg-curves question
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Dec 2015 19:17:27 -0000
In the process of going through an implementation and dealing with the latest set of questions about non reduced public keys, I ended up with a question that has some implementations If the public key I am given has not be reduced, then I compute K_B' = K_B mod p Now when I run the KDF function, I am supposed to include K, K_A and K_B in the key derivation step. The question is should I be using K_B or K_B'? Given that the reduction is described as being computed by the routine computing K, I would think that using K_B makes more sense as K_B' would not normally be returned from that function. However it does mean that there are going to be two different values of K_B that compute the same K and one needs to make sure that one never computes and saves K_B' and start distributing it as it would then be potentially impossible to compute the correct KDF result. Does this mean that we need to have stronger language on only sending K_B' rather than K_B when encoding public keys? Jim
- [Cfrg] draft-irtf-cfrg-curves question Jim Schaad
- Re: [Cfrg] draft-irtf-cfrg-curves question Ilari Liusvaara