Re: [Cfrg] [saag] A proposal for compact representation of an elliptic curve point (ECC point compression)

Russ Housley <housley@vigilsec.com> Wed, 12 December 2012 18:43 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FF321F87C9 for <cfrg@ietfa.amsl.com>; Wed, 12 Dec 2012 10:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.565
X-Spam-Level:
X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOkNjFZdy37h for <cfrg@ietfa.amsl.com>; Wed, 12 Dec 2012 10:43:41 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9693721F87EE for <cfrg@irtf.org>; Wed, 12 Dec 2012 10:43:41 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9B6039A4023; Wed, 12 Dec 2012 13:43:50 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id lOVl++H6dLy7; Wed, 12 Dec 2012 13:43:27 -0500 (EST)
Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DB52E9A401E; Wed, 12 Dec 2012 13:43:49 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF50ECB6A@XMB111CNC.rim.net>
Date: Wed, 12 Dec 2012 13:43:39 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B13CF7D-9D78-40DF-B3E9-C20EAE5AE03C@vigilsec.com>
References: <50C79E2A.9040100@brainhub.org> <810C31990B57ED40B2062BA10D43FBF50ECB6A@XMB111CNC.rim.net>
To: Dan Brown <dbrown@certicom.com>
X-Mailer: Apple Mail (2.1085)
Cc: 'Andrey Jivsov' <openpgp@brainhub.org>, "cfrg@irtf.org" <cfrg@irtf.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [Cfrg] [saag] A proposal for compact representation of an elliptic curve point (ECC point compression)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Dec 2012 18:43:42 -0000

Dan:

OCTET STRING was chosen to avoid the need to carry an extra byte to make the sign bit a zero.

Russ


On Dec 12, 2012, at 1:40 PM, Dan Brown wrote:

> My belief is that octet strings, rather than integers, were chosen (long before I was involved) for these formats because (at least partly, and perhaps mainly) these standards also allowed other finite fields (binary and odd characteristic extension fields), which are not naturally represented by integers.