Re: [openpgp] Catch 22 in ECC support of OpenPGP?

Andrey Jivsov <openpgp@brainhub.org> Sat, 01 February 2014 06:31 UTC

Return-Path: <openpgp@brainhub.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13831A0531 for <openpgp@ietfa.amsl.com>; Fri, 31 Jan 2014 22:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] 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 rIGJ-iKRYg0b for <openpgp@ietfa.amsl.com>; Fri, 31 Jan 2014 22:31:52 -0800 (PST)
Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 290691A0530 for <openpgp@ietf.org>; Fri, 31 Jan 2014 22:31:52 -0800 (PST)
Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta15.emeryville.ca.mail.comcast.net with comcast id LuW71n0050vp7WLAFuXcmi; Sat, 01 Feb 2014 06:31:36 +0000
Received: from [192.168.1.8] ([71.202.164.227]) by omta05.emeryville.ca.mail.comcast.net with comcast id LuXn1n0094uhcbK8RuXnt7; Sat, 01 Feb 2014 06:31:47 +0000
Message-ID: <52EC94D3.3000001@brainhub.org>
Date: Fri, 31 Jan 2014 22:31:47 -0800
From: Andrey Jivsov <openpgp@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: openpgp@ietf.org
References: <87iot0y1su.fsf@vigenere.g10code.de> <E238B88A-6259-4D1F-A432-AD0D20652392@callas.org> <874n4kxqop.fsf@vigenere.g10code.de>
In-Reply-To: <874n4kxqop.fsf@vigenere.g10code.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391236296; bh=2crd7UabNzt8sQD5v9UgJbPmkmGb6Sx/Dh3zSUO3dAI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dWEC+D37qMeu5aQgQSd+coYLJOsIyojIk49EGhVEyWqYXPU63prmzrB+gPMSehRhI LwJNIC7ws6ZdrwQJW9g7RF2dY1K17SK6ohWaUvL8nK35c5aFURhGO+st3VFNcDIHbp 1kbThU0JfFmAKMnOGm4ndC1LJjcOXBGB9FwezBq8aBXo3iehKJDEdQFdX6BrwWYpVW nuABSdW3a/ZKu2n1YrWJ+laxK2GTVnf0PwyLQYfu4pm5nyNvZldhYFqIoQBhyzrU77 dlbubxsVKR6gy+f3h788075jCjDHAZiGxDoqupbiscrBFW0R7amPYe3cK+1MIwnED4 tpz6r7+PkKzsQ==
Subject: Re: [openpgp] Catch 22 in ECC support of OpenPGP?
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2014 06:31:54 -0000

On 01/31/2014 04:48 AM, Werner Koch wrote:
> I explained it below.  RFC-6637 requires the use of SEC encoding which
> is nice because you will never have the problems with leading zeroes.
> However, EdDSA uses a different compression format without any
> identifier (which makes up nice 32 bytes).  A leading zero may however
> happen.  RFC-4880 does not allow that and thus one would need to check
> whether to left pad a read MPI before using it with Ed25519 code.  As I
> said, not a real problem but it would be possible to save 2 lines of
> code if we could use a raw octet string.

Werner, it's an unexpected argument...

I would say that the MPI encoding is even more appropriate format when 
considering a compact representation (i.e. (x) v.s. (x,y) )

For example, with http://tools.ietf.org/html/draft-jivsov-ecc-compact 
the compact representation is exactly an element in the underlying 
field, Fp. It's exactly an integer mod p. If we use an MPI for an RSA 
key component, why shouldn't we use an MPI for the x as well?

Likewise, with Ed25519 high-bit encoding the value is (almost) an 
integer in a Fp field.

It's a good idea to ensure that when you copy the value of an MPI into a 
buffer, the highest bytes of the buffer are zeros ;-)