From singpolyma@singpolyma.net Sat Jan 4 07:34:19 2014 Return-Path: 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 AD5381ACCD8 for ; Sat, 4 Jan 2014 07:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.96 X-Spam-Level: X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[BAYES_60=1.5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 ezTEfAFhanTL for ; Sat, 4 Jan 2014 07:34:18 -0800 (PST) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id BBC431ADF39 for ; Sat, 4 Jan 2014 07:34:18 -0800 (PST) Received: by singpolyma.net (Postfix, from userid 1000) id 86A21F210D; Sat, 4 Jan 2014 15:34:10 +0000 (UTC) Date: Sat, 4 Jan 2014 15:34:10 +0000 From: Stephen Paul Weber To: openpgp@ietf.org Message-ID: <20140104153410.GA5499@singpolyma.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [openpgp] rfc6637 question X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 15:34:19 -0000 RFC4880 S 5.5.2 says: > A series of multiprecision integers comprising the key material. but the additions to 5.5.2 by RFC6637 S 9 add non-MPI fields to this section without really indicating the intention to change the above situation and to have possibly-arbitrarily-typed algorithm-specific data. It feels like this could be made a little more clear with a statement to that effect being added to RFC6637 or something. -- Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph From paul@nohats.ca Sun Jan 5 18:10:00 2014 Return-Path: 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 C1B341ADF31; Sun, 5 Jan 2014 18:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538] 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 fBC0HY8EwbCX; Sun, 5 Jan 2014 18:09:58 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5371ADF44; Sun, 5 Jan 2014 18:09:56 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 7128A80055; Sun, 5 Jan 2014 21:09:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1388974186; bh=9+Ih7YDuwO+rpCA0MXU8scmnpS35MvVu3/GsPoq79+s=; h=Date:From:To:Subject; b=VcqJ3QizgoAEmm6EtS5qpJ77NKrv8KGFHOtdbh8oMzaI9Lyli+BnH31iFgTUuTLFr 2M1SdNXCU8tdvdgiLtTmIsRy1IYv1XTxEMJeEukySomDvfSzczdEt+jlT8WE6Nobba a9+2fls6RjYLvA/X1i5ik9rdYB7jUpjGo3nfCHoQ= Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5DCD880048; Sun, 5 Jan 2014 21:09:46 -0500 (EST) Date: Sun, 5 Jan 2014 21:09:46 -0500 (EST) From: Paul Wouters To: dane WG list , openpgp@ietf.org, dnssec-deployment Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [openpgp] first release of openpgpkey-milter, DANE assisted GnuPG email encryption milter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 02:10:01 -0000 I've released the first version of openpgpkey-milter, a sendmail/postfix milter service that attempts to automatically encrypt emails using gnupg based on the precense of a DNSSEC signed OPENPGPKEY record as specified in http://tools.ietf.org/html/draft-wouters-dane-openpgp It currently uses the private-use RRTYPE 65280. Version 2.3 of hash-slinger has a new openpgpkey command that you can use to generate OPENPGPKEY records. It supports generating the generic type syntax. (http://people.redhat.com/pwouters/hash-slinger/) My paul@nohats.ca email address is pusblishing this record. Feel free to send me test emails, although if you don't hear back from me, perhaps follow up at paul@cypherpunks.ca :) This initial version does not yet handle multipart / MIME emails, and the python-gnupg module has some known bugs with utf-8 / IDN. Punycode support is also not included in this release. It was also not stress tested on a busy mail server. You can grab the tar ball at ftp://ftp.nohats.ca/openpgpkey-milter/ or have a look at https://github.com/letoams/openpgpkey-milter/ Enjoy! Paul From wk@gnupg.org Fri Jan 31 00:56:29 2014 Return-Path: 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 786E51A0575 for ; Fri, 31 Jan 2014 00:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 sKp9MB7s8BrW for ; Fri, 31 Jan 2014 00:56:26 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 227671A056A for ; Fri, 31 Jan 2014 00:56:25 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1W99td-0005rY-OQ for ; Fri, 31 Jan 2014 09:56:21 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1W99m5-0004z2-BX for ; Fri, 31 Jan 2014 09:48:33 +0100 From: Werner Koch To: openpgp@ietf.org Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Fri, 31 Jan 2014 09:48:33 +0100 Message-ID: <87iot0y1su.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 08:56:29 -0000 Hi, [gniibe asked on the gnupg-devel list on how to support EdDSA. We better continue the discussion here.] On Fri, 31 Jan 2014 04:46, gniibe@fsij.org said: > I think that adding new signature scheme requires its algorithm ID. Right, for EdDSA we should have a new id. Yesterday I changed the GnuPG code and replaced the EdDSA hacks with new experimental algorithm id. The code is not finished and actually the whole ECC stuff is currently broken. I'll fix that soon. For EdDSA we need a new RFC to have the IANA assign a new algorithm id. While doing that we should also address two questions: 1. Shall we keep the OID field or shall we replace it with either a curve size parameter or maybe assign a single algorithm identifier for Ed25519/EdDSA? 2. Does the use of MPIs make sense? Bernstein defines the key as well as the signature material as octet strings and not as MPIs. A reason to drop the OID field would be smaller key material which may help with key backup or direct use of the key. However, it complicates parsing because we would need two methods. I am fine with the OIDs (after all I suggested them) because for key backup we can use our own format. Such a format should be URI encoded for use in QR codes anyway. The problem with fitting an EdDSA key or signature material into an MPI is the usual leading zero problem. Thus for processing the red MPIs needs to be left-padded with zeroes up to the size indirecty specified by the OID. Note that we do not have the compression flag byte in plain EdDsA (but see below). For GnuPG/Libgcrypt this is not a big problem because we already have code in place to do that. New OpenPGP implementations may benefit from a simpler scheme. Related to question 1, a length byte could also be used to distinguish between different curves (i.e. Ed25519 and Curve41417). RFC-4880 describes the key material as a series of MPIs, which would rule out the above idea. However, RFC-6637 already uses non-MPIs for the OID and the KDF params. > (1) Possible algorithm ID 22 for ECDH+ECDSA: > http://www.ietf.org/mail-archive/web/openpgp/current/msg07163.html I am not in favor of mixing them. Encryption, and in particular DH, is different from signing. Having different algorithms ids also helps to avoid mixing encryption and signing keys due to implicit capabilities. > (2) Possible algorithm ID 22 for EdDSA: > http://www.ietf.org/mail-archive/web/openpgp/current/msg07194.html Before we can request the assignment of a new algo id, we need to write the specs. This is why I am currently using 105 for EdDSA. Some of you may have noticed that the CFRG (the IRTF crypto research group) is currently discussing standardization of non-Weierstrass curves (e.g. Curve25519 an its variants). Watson Ladd is working on an I-D[1]. The TLS WG is also discussing these curves. There are many ideas floating around and it would be useful to wait until we have a clear picture. This will help to solve the problem of missing standard documents for the Bernstein (aka Chicago) curves. The available papers are not suitable for normative use in an RFC (maybe with the exception of the Ed25519 paper). Of course we could informally agree on an algorithm id for EdDSA, as we always did in the OpenPGP WG. However, a new algorithm id is not sufficient as long as we do not have answers to the above questions. We better go in lock-step with the Ladd I-D. Is there anyone with free time to write an I-D? Shouldn't we continue this discussing at the IETF OpenPGP mailing list? Salam-Shalom, Werner [1] http://www.ietf.org/id/draft-ladd-safecurves-03.txt -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jon@callas.org Fri Jan 31 02:04:36 2014 Return-Path: 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 7925A1A0583 for ; Fri, 31 Jan 2014 02:04:36 -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, 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 tMJBXz_abD8t for ; Fri, 31 Jan 2014 02:04:34 -0800 (PST) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id AD26F1A0580 for ; Fri, 31 Jan 2014 02:04:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id E14BD4C3BACB; Fri, 31 Jan 2014 02:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2YWcyINlo8X; Fri, 31 Jan 2014 02:04:29 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 1918E4C3BAC1; Fri, 31 Jan 2014 02:04:26 -0800 (PST) Received: from [192.168.10.68] ([192.76.146.51]) by keys.merrymeet.com (PGP Universal service); Fri, 31 Jan 2014 02:04:29 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 31 Jan 2014 02:04:29 -0800 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Jon Callas In-Reply-To: <87iot0y1su.fsf@vigenere.g10code.de> Date: Fri, 31 Jan 2014 02:04:24 -0800 Message-Id: References: <87iot0y1su.fsf@vigenere.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.1827) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "openpgp@ietf.org OpenPGP" , Jon Callas 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 10:04:36 -0000 > For EdDSA we need a new RFC to have the IANA assign a new algorithm = id. > While doing that we should also address two questions: >=20 > 1. Shall we keep the OID field or shall we replace it with either a > curve size parameter or maybe assign a single algorithm identifier > for Ed25519/EdDSA? OIDs are just unique constants. It's quasi-IANA governed. Getting an OID = is easy as long as you have a base OID from the IEEE. I've gotten OIDs = for a number of organizations, and once you have one, you just put your = own off of that. So suppose they give you [1.2.3.4]. All you need to do is make = [1.2.3.4.x.y.z...] for your own OIDs for whatever purpose. If you look at , particularly question = 10, there are easy ways to get one. There are suggestions that include = how to get an OID from IANA, and also how to use a UUID as an OID. >=20 > 2. Does the use of MPIs make sense? Bernstein defines the key as well > as the signature material as octet strings and not as MPIs. As you've noted, in RFC 6637, Andrey codes an EC point into an MPI, = which I think is clever, and works fine. Why not just do it? >=20 > A reason to drop the OID field would be smaller key material which may > help with key backup or direct use of the key. However, it = complicates > parsing because we would need two methods. I am fine with the OIDs > (after all I suggested them) because for key backup we can use our own > format. Such a format should be URI encoded for use in QR codes = anyway. That's a good argument for not using a UUID, because it's going to be = over 16 bytes long. But you can go to IANA for an OID, or get your own = OID base and then just issue one from there. >=20 > Of course we could informally agree on an algorithm id for EdDSA, as = we > always did in the OpenPGP WG. However, a new algorithm id is not > sufficient as long as we do not have answers to the above questions. = We > better go in lock-step with the Ladd I-D. Is there anyone with free > time to write an I-D? I'd say just do something that will work. Get an OID, we agree on an = algorithm ID, and then Bob's your uncle and Alice is your auntie. >=20 > Shouldn't we continue this discussing at the IETF OpenPGP mailing = list? You mean this isn't? Jon From wk@gnupg.org Fri Jan 31 04:56:28 2014 Return-Path: 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 962E01A05F7 for ; Fri, 31 Jan 2014 04:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 SyphsoE1Npm2 for ; Fri, 31 Jan 2014 04:56:26 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 510881A05A2 for ; Fri, 31 Jan 2014 04:56:26 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1W9Ddu-0007ys-06 for ; Fri, 31 Jan 2014 13:56:22 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1W9DWQ-0005mJ-Jp; Fri, 31 Jan 2014 13:48:38 +0100 From: Werner Koch To: Jon Callas References: <87iot0y1su.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Fri, 31 Jan 2014 13:48:38 +0100 In-Reply-To: (Jon Callas's message of "Fri, 31 Jan 2014 02:04:24 -0800") Message-ID: <874n4kxqop.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "openpgp@ietf.org OpenPGP" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 12:56:28 -0000 On Fri, 31 Jan 2014 11:04, jon@callas.org said: > If you look at , particularly question 1= 0, there are easy ways to get one. There are suggestions that include how t= o get an OID from IANA, and also how to use a UUID as an OID. Sure. We already use one from the GNU arc in Libgcrypt: 1.3.6.1.4.1.11591.15 ellipticCurve 1.3.6.1.4.1.11591.15.1 Ed25519 This is a different OID than Peter Gutman's for Curve25519. > As you've noted, in RFC 6637, Andrey codes an EC point into an MPI, > which I think is clever, and works fine. Why not just do it? 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. > I'd say just do something that will work. Get an OID, we agree on an algo= rithm ID, and then Bob's your uncle and Alice is your auntie. An OID is given above. The following public key algorithm ID is added to expand Section 9.1 of [RFC4880], "Public-Key Algorithms": ID Description of Algorithm -- -------------------------- 22 EdDSA signature algorithm [EdDSA] [EdDSA] 23pp. (PDF) Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, Bo-Yin Yang. High-speed high-security signatures. Journal of Cryptographic Engineering 2 (2012), 77=E2=80=9389. Document ID: a1a62a2f76d23f65d622484ddd09caf8. URL: http://cr.yp.to/papers.html#ed25519. Date: 2011.09.26. I have not yet seen the specs for Curve41417 and thus I do not know whether it also defines EdDSA for signatures. EdDSA according to the paper requires the use of SHA512 but it also tells that other hash algorithms are possible. Hopefully Watson Ladd's I-D can eventually be used as a reference. Salam-Shalom, Werner p.s. >> Shouldn't we continue this discussing at the IETF OpenPGP mailing list? > > You mean this isn't? I forwarded the entire message text ;-) --=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From openpgp@brainhub.org Fri Jan 31 22:31:54 2014 Return-Path: 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 ; 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 ; 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 ; 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 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> <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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ;-)