Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1N0rKNE091299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 17:53:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q1N0rKas091298; Wed, 22 Feb 2012 17:53:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1N0rJIr091293 for ; Wed, 22 Feb 2012 17:53:20 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta03.emeryville.ca.mail.comcast.net with comcast id dCbH1i0020lTkoCA3CtKcG; Thu, 23 Feb 2012 00:53:19 +0000 Received: from [127.0.0.1] ([98.234.252.65]) by omta04.emeryville.ca.mail.comcast.net with comcast id dCtJ1i00M1RRS8a8QCtJdi; Thu, 23 Feb 2012 00:53:19 +0000 Message-ID: <4F458E56.4030802@brainhub.org> Date: Wed, 22 Feb 2012 16:54:46 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Marko Kreen CC: ietf-openpgp@imc.org Subject: Re: Review of draft-ecc-09 References: <20120218215115.GA18978@gmail.com> <4F4346B7.1040804@brainhub.org> <20120221094901.GA27705@gmail.com> In-Reply-To: <20120221094901.GA27705@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Marco: On 02/21/2012 01:49 AM, Marko Kreen wrote: > On Mon, Feb 20, 2012 at 11:24:39PM -0800, Andrey Jivsov wrote: >> On 02/18/2012 01:51 PM, Marko Kreen wrote: >>> [ I updated the review with diff from -09. Thanks for taking >>> my comments on the ref section into account. ] >> Sorry, I was busy in recent days and this is the first time I take >> close look at your feedback. The credit for -09 should go to Sean >> Turner, IETF Security Area director. > > Heh. I noticed few old references there, then the new draft > fixed those without me sending anything. > > Note - the links in text are not updated (see [nits] on draft page). > >>>> The point is encoded in MPI format. The content of the MPI is the >>>> following: >>>> >>>> B = B0 || x || y >>>> >>>> where x and y are coordinates of the point P = (x, y), each encoded >>>> in big endian format and zero-padded to the underlying field size. >>> *Then*, they are also padded to byte boundary. As this is not mentioned >>> anywhere, it caused me some confusion, because I assumed they already >>> are on byte boundary, perhaps even power-of-two. >>> >>> As it only matters to P-521 keys, the bad assumtions work fine on >>> P-256 and P-384 keys. (Basically I assumed P-521 uses 512-bit values...) >> >> Note, that what you are suggesting would not work in practice, if I >> understand your initial confusion correctly. Note that both x and y >> are taken mod a 521 bit prime. They can be exactly 521 bits, but in >> 50% of cases, 520 bits. Let's say that either x or y is 521 and >> another one is 520 bits. How would we know which one of x and y is >> the longest one? > > The text already states "zero-padded to the underlying field". > So we already are talking about bits in field, not bits > in actual bignum. > > The missing '*then*' part is about rounding field bits. > >> The algorithm is the following: given the MPI with the point, >> * get its size in full bytes ( len=(MPI_bits+7)/8 ) >> * len = len-1 ( to remove the B0 byte ) >> * len = len/2 -- the 'len' is the size of x and y in bytes. > > I think it's better to show how to calculate proper size > from field size, not from MPI size. Because MPI is "untrusted", > we need to validate it. > > Maybe just add: > > where x and y are coordinates of the point P = (x, y), each encoded > in big endian format and zero-padded to the underlying field size, > then zero-padded to multiple of 8 if the field size is not multiple of 8. > Yes, this makes it better. Here is modified text: "The point is encoded in MPI format. The content of the MPI is the following: B = B0 || x || y where x and y are coordinates of the point P = (x, y), each encoded in big endian format and zero-padded to the nearest 8-byte boundary that is higher or equal to the underlying field size. For example, for the 521 bit underlying field each x and y always occupy 66 bytes." ... and adjust the formula bellow in the spec and change the example to use P-521 to get 1059 total bit size recorded in the MPI header. >>> Missing detail: In addition to size check, what other validation must >>> be done when parsing a point? This applies to when reading a public key, >>> but especially when reading incoming ECDH/ECDSA message. I suggest >>> adding: "You must check that the point is on curve." here. >> >> I will take it as a suggestion and think how to integrate it, given >> that this is a general check for ECC and is not specific to OpenPGP. >> This valid concern may be satisfied through sources in References >> section. > > It's security detail, and it's simple to mention. > > The References are rather verbose, so it's easy to miss > the important details. > >>>> 8. EC DH Algorithm (ECDH) >>>> The key wrapping method is based on [RFC3394]. KDF produces the >>>> AES key that is used as KEK as specified in [RFC3394]. Refer to >>>> section 13 for the details regarding the choice of the KEK >>>> algorithm, which MUST be one of three AES algorithms. >>> This is only place which says that KEK *MUST* be AES-only. (Ignoring 12.2) >>> This is in conflict with section 12.1 and 13, where non-AES is not >>> disallowed. I'm not disagreeing with it, just I think it would be good >>> to clarify why. >>> >>> It might be good idea to disallow cipher_ids< AES128, but why disallow >>> Camellia and Twofish? I could imagine that because the algorithm >>> is not per-message but comes from key is the reason - you may not >>> know at key generation time all the people who want to send you messages >>> and what features their software has. But I think it would be >>> good to put the reason in the doc. >>> >>> In any case, 12.1 and 13 should be synced with the requirement. >> >> I also see the need for clarity here. >> >> In reference to compatibility, if the code understands ECC, the >> document assumes that it must supports AES. This is something >> OpenPGP RFC 4880 cannot generally rely upon. One of main criteria of >> this document is simplicity through limited choices, as I recall, >> something that Ian G advocated. It's much easier to write "use AES" >> than to define "strong enough" cipher. > > cipher_num> 7? > >> Suite B and other government >> standards require AES, so most application will implement it to >> comply, leaving us with the question why bother at all about the >> non-AES case? >> >> I am leaning toward fixing KEK at AES. There is no backward >> compatibility issue here. So, the action item for me is to make this >> choice clear. > > Fine by me. > >>>> For convenience, the synopsis of the encoding method is given >>>> below, however, this section, [NIST SP800-56A], and [RFC3394] are >>>> the normative sources of the definition. >>>> >>>> Obtain authenticated recipient public key R >>>> Generate ephemeral key pair {v, V=vG} >>>> Compute shared point S = vR; >>>> m = symm_alg_ID || session key || checksum || pkcs5_padding; >>>> curve_OID_len = (byte)len(curve_OID); >>>> Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 || >>>> 01 || KDF_hash_ID || AES_alg_ID for AESKeyWrap || >>>> "Anonymous Sender " || recipient_fingerprint; >>>> Z_len = key size for AES_alg_ID to be used with AESKeyWrap >>>> Compute Z = KDF( S, Z_len, Param ); >>>> Compute C = AESKeyWrap( Z, m ) as per [RFC3394] >>>> VB = convert point V to octet string >>>> Output (MPI(VB) || len(C) || C). >>>> >>>> The decryption is the inverse of the method given. Note that the >>>> recipient obtains the shared secret by calculating >>>> >>>> S = rV = rvG, where (r,R) is the recipient's key pair. >>>> >>>> Consistent with section 5.13 Sym. Encrypted Integrity Protected >>>> Data Packet (Tag 18) of [RFC4880], the MDC SHOULD be used anytime >>>> symmetric key is protected by ECDH. >>> Missing detail: How to generate v? What requirements it has? >>> I suggest expanding the second step with: >>> >>> Generate ephemeral key pair {v, V} where V=vG and v is random number >>> in range 0< v< n (n - curve modulus) >> This detail is also related to a question of external reference, but >> I am glad you raised this question. FIPS 186-3 defines two methods >> in B.4 on p.61. The idea is this: >> B.4.1: if you do "v = v' mod order", the input v' must be 64 bits >> longer than "order". >> B.4.2: or you can repeatedly getting random bits until "v'< order" >> (probably too wasteful for the entropy) > > I think the "How" can be left to references. I just would like > to see the requirement "0< v< n" mentioned here. > > RFC6090 Appendix A seems even better reference for this. > It seems to reference only method B.4.2. I find that method B.4.1 is more practical. >>> Final note: the section 8 was quite successful at describing ECDH, >>> how hard would it be to have same level of description of ECDSA here? >>> At least I would like to see packet format here, even if the >>> algorithm is not described. >> >> Marko, did you realize that it happens that the signature format for >> ECDSA is identical to DSA? > > Well, FIPS 186-3 tells that actual ECDSA is described in ANS X9.62.. > >> The (r,s) signature pair consists of >> (true) MPIs in both cases. The ECDSA key is defined in section 9. >> Overall, ECDSA for OpenPGP is much simpler because it has no >> complexities like key wrapping. With this in mind, what would you >> like to see added to properly implement ECDSA. > > At minimum, it should mention that > > Algorithm-Specific Fields for ECDSA signatures are: > - MPI of ECDSA value r. > - MPI of ECDSA value s. > > then the spec makes clear the mapping between packet layout > and algorithm. > > I would like to see short algorithm description also here, > with symbols consistent with rest of the document. > > But it's proably OK having good reference in the form "OpenPGP variant > of ECDSA is described here: [REF]". And if the REF describes 4 > different EC signature variants, then point directly to section. > > Eg: "How to pad/shorten H(m) for use in ECDSA" is another > step that needs clear "in OpenPGP we do it like this" > description. (shorten: trunc-left/trunc-right/mod. And how short?) > Thank you for your comments. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1L9n8ro093113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 02:49:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q1L9n8dW093112; Tue, 21 Feb 2012 02:49:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1L9n6xh093107 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 21 Feb 2012 02:49:07 -0700 (MST) (envelope-from markokr@gmail.com) Received: by bkcjg15 with SMTP id jg15so9369888bkc.16 for ; Tue, 21 Feb 2012 01:49:06 -0800 (PST) Received-SPF: pass (google.com: domain of markokr@gmail.com designates 10.204.149.209 as permitted sender) client-ip=10.204.149.209; Authentication-Results: mr.google.com; spf=pass (google.com: domain of markokr@gmail.com designates 10.204.149.209 as permitted sender) smtp.mail=markokr@gmail.com; dkim=pass header.i=markokr@gmail.com Received: from mr.google.com ([10.204.149.209]) by 10.204.149.209 with SMTP id u17mr13395424bkv.46.1329817746071 (num_hops = 1); Tue, 21 Feb 2012 01:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=55Q8kyhs2UBsP8WggcoTWqsOwgyqxm9DYnHiJjTpNk8=; b=KudI+rJyS7QIgozTT8RT6Sfj2GujX7JCwcIvtLZSBHRmPap8QXNxUNNo4J8rVgT4DE GVyTnMOvyJGTs6Qa9ZiuilbXy8xfsnAN8XEfliYTUxw9PibQKCiAXJXYrr5CViw8+j2l 89fIVI8Z/fPnFfbJJY31bQoMz+yv5b5/qL7/A= Received: by 10.204.149.209 with SMTP id u17mr10789299bkv.46.1329817745979; Tue, 21 Feb 2012 01:49:05 -0800 (PST) Received: from gmail.com (turu7.ee. [217.159.207.194]) by mx.google.com with ESMTPS id y9sm44279377bkw.5.2012.02.21.01.49.03 (version=SSLv3 cipher=OTHER); Tue, 21 Feb 2012 01:49:04 -0800 (PST) Date: Tue, 21 Feb 2012 11:49:01 +0200 From: Marko Kreen To: Andrey Jivsov Cc: ietf-openpgp@imc.org Subject: Re: Review of draft-ecc-09 Message-ID: <20120221094901.GA27705@gmail.com> References: <20120218215115.GA18978@gmail.com> <4F4346B7.1040804@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F4346B7.1040804@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Feb 20, 2012 at 11:24:39PM -0800, Andrey Jivsov wrote: > On 02/18/2012 01:51 PM, Marko Kreen wrote: > >[ I updated the review with diff from -09. Thanks for taking > > my comments on the ref section into account. ] > Sorry, I was busy in recent days and this is the first time I take > close look at your feedback. The credit for -09 should go to Sean > Turner, IETF Security Area director. Heh. I noticed few old references there, then the new draft fixed those without me sending anything. Note - the links in text are not updated (see [nits] on draft page). > >> The point is encoded in MPI format. The content of the MPI is the > >> following: > >> > >> B = B0 || x || y > >> > >> where x and y are coordinates of the point P = (x, y), each encoded > >> in big endian format and zero-padded to the underlying field size. > >*Then*, they are also padded to byte boundary. As this is not mentioned > >anywhere, it caused me some confusion, because I assumed they already > >are on byte boundary, perhaps even power-of-two. > > > >As it only matters to P-521 keys, the bad assumtions work fine on > >P-256 and P-384 keys. (Basically I assumed P-521 uses 512-bit values...) > > Note, that what you are suggesting would not work in practice, if I > understand your initial confusion correctly. Note that both x and y > are taken mod a 521 bit prime. They can be exactly 521 bits, but in > 50% of cases, 520 bits. Let's say that either x or y is 521 and > another one is 520 bits. How would we know which one of x and y is > the longest one? The text already states "zero-padded to the underlying field". So we already are talking about bits in field, not bits in actual bignum. The missing '*then*' part is about rounding field bits. > The algorithm is the following: given the MPI with the point, > * get its size in full bytes ( len=(MPI_bits+7)/8 ) > * len = len-1 ( to remove the B0 byte ) > * len = len/2 -- the 'len' is the size of x and y in bytes. I think it's better to show how to calculate proper size from field size, not from MPI size. Because MPI is "untrusted", we need to validate it. Maybe just add: where x and y are coordinates of the point P = (x, y), each encoded in big endian format and zero-padded to the underlying field size, then zero-padded to multiple of 8 if the field size is not multiple of 8. > >Missing detail: In addition to size check, what other validation must > >be done when parsing a point? This applies to when reading a public key, > >but especially when reading incoming ECDH/ECDSA message. I suggest > >adding: "You must check that the point is on curve." here. > > I will take it as a suggestion and think how to integrate it, given > that this is a general check for ECC and is not specific to OpenPGP. > This valid concern may be satisfied through sources in References > section. It's security detail, and it's simple to mention. The References are rather verbose, so it's easy to miss the important details. > >>8. EC DH Algorithm (ECDH) > >> The key wrapping method is based on [RFC3394]. KDF produces the > >> AES key that is used as KEK as specified in [RFC3394]. Refer to > >> section 13 for the details regarding the choice of the KEK > >> algorithm, which MUST be one of three AES algorithms. > >This is only place which says that KEK *MUST* be AES-only. (Ignoring 12.2) > >This is in conflict with section 12.1 and 13, where non-AES is not > >disallowed. I'm not disagreeing with it, just I think it would be good > >to clarify why. > > > >It might be good idea to disallow cipher_ids< AES128, but why disallow > >Camellia and Twofish? I could imagine that because the algorithm > >is not per-message but comes from key is the reason - you may not > >know at key generation time all the people who want to send you messages > >and what features their software has. But I think it would be > >good to put the reason in the doc. > > > >In any case, 12.1 and 13 should be synced with the requirement. > > I also see the need for clarity here. > > In reference to compatibility, if the code understands ECC, the > document assumes that it must supports AES. This is something > OpenPGP RFC 4880 cannot generally rely upon. One of main criteria of > this document is simplicity through limited choices, as I recall, > something that Ian G advocated. It's much easier to write "use AES" > than to define "strong enough" cipher. cipher_num > 7? > Suite B and other government > standards require AES, so most application will implement it to > comply, leaving us with the question why bother at all about the > non-AES case? > > I am leaning toward fixing KEK at AES. There is no backward > compatibility issue here. So, the action item for me is to make this > choice clear. Fine by me. > >> For convenience, the synopsis of the encoding method is given > >> below, however, this section, [NIST SP800-56A], and [RFC3394] are > >> the normative sources of the definition. > >> > >> Obtain authenticated recipient public key R > >> Generate ephemeral key pair {v, V=vG} > >> Compute shared point S = vR; > >> m = symm_alg_ID || session key || checksum || pkcs5_padding; > >> curve_OID_len = (byte)len(curve_OID); > >> Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 || > >> 01 || KDF_hash_ID || AES_alg_ID for AESKeyWrap || > >> "Anonymous Sender " || recipient_fingerprint; > >> Z_len = key size for AES_alg_ID to be used with AESKeyWrap > >> Compute Z = KDF( S, Z_len, Param ); > >> Compute C = AESKeyWrap( Z, m ) as per [RFC3394] > >> VB = convert point V to octet string > >> Output (MPI(VB) || len(C) || C). > >> > >> The decryption is the inverse of the method given. Note that the > >> recipient obtains the shared secret by calculating > >> > >> S = rV = rvG, where (r,R) is the recipient's key pair. > >> > >> Consistent with section 5.13 Sym. Encrypted Integrity Protected > >> Data Packet (Tag 18) of [RFC4880], the MDC SHOULD be used anytime > >> symmetric key is protected by ECDH. > >Missing detail: How to generate v? What requirements it has? > >I suggest expanding the second step with: > > > > Generate ephemeral key pair {v, V} where V=vG and v is random number > > in range 0< v< n (n - curve modulus) > This detail is also related to a question of external reference, but > I am glad you raised this question. FIPS 186-3 defines two methods > in B.4 on p.61. The idea is this: > B.4.1: if you do "v = v' mod order", the input v' must be 64 bits > longer than "order". > B.4.2: or you can repeatedly getting random bits until "v' < order" > (probably too wasteful for the entropy) I think the "How" can be left to references. I just would like to see the requirement "0 < v < n" mentioned here. RFC6090 Appendix A seems even better reference for this. > >Final note: the section 8 was quite successful at describing ECDH, > >how hard would it be to have same level of description of ECDSA here? > >At least I would like to see packet format here, even if the > >algorithm is not described. > > Marko, did you realize that it happens that the signature format for > ECDSA is identical to DSA? Well, FIPS 186-3 tells that actual ECDSA is described in ANS X9.62.. > The (r,s) signature pair consists of > (true) MPIs in both cases. The ECDSA key is defined in section 9. > Overall, ECDSA for OpenPGP is much simpler because it has no > complexities like key wrapping. With this in mind, what would you > like to see added to properly implement ECDSA. At minimum, it should mention that Algorithm-Specific Fields for ECDSA signatures are: - MPI of ECDSA value r. - MPI of ECDSA value s. then the spec makes clear the mapping between packet layout and algorithm. I would like to see short algorithm description also here, with symbols consistent with rest of the document. But it's proably OK having good reference in the form "OpenPGP variant of ECDSA is described here: [REF]". And if the REF describes 4 different EC signature variants, then point directly to section. Eg: "How to pad/shorten H(m) for use in ECDSA" is another step that needs clear "in OpenPGP we do it like this" description. (shorten: trunc-left/trunc-right/mod. And how short?) -- marko Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1L7Oi4u087766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 00:24:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q1L7Oirx087765; Tue, 21 Feb 2012 00:24:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-pw0-f43.google.com (mail-pw0-f43.google.com [209.85.160.43]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1L7OhxN087760 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 21 Feb 2012 00:24:43 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: by pbbro2 with SMTP id ro2so9153751pbb.16 for ; Mon, 20 Feb 2012 23:24:43 -0800 (PST) Received-SPF: pass (google.com: domain of openpgp@brainhub.org designates 10.68.129.168 as permitted sender) client-ip=10.68.129.168; Authentication-Results: mr.google.com; spf=pass (google.com: domain of openpgp@brainhub.org designates 10.68.129.168 as permitted sender) smtp.mail=openpgp@brainhub.org Received: from mr.google.com ([10.68.129.168]) by 10.68.129.168 with SMTP id nx8mr3727959pbb.95.1329809083176 (num_hops = 1); Mon, 20 Feb 2012 23:24:43 -0800 (PST) Received: by 10.68.129.168 with SMTP id nx8mr3108412pbb.95.1329809083117; Mon, 20 Feb 2012 23:24:43 -0800 (PST) Received: from [192.168.1.8] (c-98-234-252-65.hsd1.ca.comcast.net. [98.234.252.65]) by mx.google.com with ESMTPS id kx17sm26906834pbb.19.2012.02.20.23.24.40 (version=SSLv3 cipher=OTHER); Mon, 20 Feb 2012 23:24:41 -0800 (PST) Message-ID: <4F4346B7.1040804@brainhub.org> Date: Mon, 20 Feb 2012 23:24:39 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc13 Thunderbird/3.1.10 MIME-Version: 1.0 To: Marko Kreen CC: ietf-openpgp@imc.org Subject: Re: Review of draft-ecc-09 References: <20120218215115.GA18978@gmail.com> In-Reply-To: <20120218215115.GA18978@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlkG6j73MadgOmJn9f/UWEgmX24kZ8TqtR27+jNPDGM7J1qDaFzqjPtl8OEYOq4+25dGQ8Q Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Marko, thank you for taking time to write this review and for the effort to implement it. Please check my comments inline: On 02/18/2012 01:51 PM, Marko Kreen wrote: > > Hello, > > I tried to implement ECC for pgcrypto, which is crypto module > for PostgreSQL database. And I managed to get it to work, > mainly because of EC module in OpenSSL, which allowed me to be > ignorant of all low-level math details. > > Also, I only implemented ECDH, pgcrypto does not do signing. > It uses PGP as a fancy encrypt/decrypt storage format only. > > So this is a review of draft-08 by app developer who is ignorant > of EC math and has not read any detailed math/crypto papers... > > [ I updated the review with diff from -09. Thanks for taking > my comments on the ref section into account. ] Sorry, I was busy in recent days and this is the first time I take close look at your feedback. The credit for -09 should go to Sean Turner, IETF Security Area director. >> 5. Supported public key algorithms >> >> Supported public key algorithms are Elliptic Curve Digital >> Signature Algorithm (ECDSA), defined in [FIPS 186-2], and Elliptic >> Curve Diffie-Hellman (ECDH), defined in section 8. > Note for later: this basically states that section 8 plans to > fully describe ECDH used in OpenPGP. > >> 6. Conversion primitives >> >> The method to convert an EC point to the octet string is defined in >> [SEC1]. This specification only defines uncompressed point >> format. For convenience, the synopsis of the encoding method is >> given below, however, the [SEC1] is the normative source of the >> definition. >> >> The point is encoded in MPI format. The content of the MPI is the >> following: >> >> B = B0 || x || y >> >> where x and y are coordinates of the point P = (x, y), each encoded >> in big endian format and zero-padded to the underlying field size. > *Then*, they are also padded to byte boundary. As this is not mentioned > anywhere, it caused me some confusion, because I assumed they already > are on byte boundary, perhaps even power-of-two. > > As it only matters to P-521 keys, the bad assumtions work fine on > P-256 and P-384 keys. (Basically I assumed P-521 uses 512-bit values...) Note, that what you are suggesting would not work in practice, if I understand your initial confusion correctly. Note that both x and y are taken mod a 521 bit prime. They can be exactly 521 bits, but in 50% of cases, 520 bits. Let's say that either x or y is 521 and another one is 520 bits. How would we know which one of x and y is the longest one? The algorithm is the following: given the MPI with the point, * get its size in full bytes ( len=(MPI_bits+7)/8 ) * len = len-1 ( to remove the B0 byte ) * len = len/2 -- the 'len' is the size of x and y in bytes. >> B0 is a byte with following values: >> >> value description >> >> 0 Point O. In this case there is no x or y octets present. >> >> 4 Uncompressed point. x and y of EC point values follow. >> >> Note that point O shall not appear in a public or a private >> key. Therefore, the size of the MPI payload is always curve_size*2 >> + 3 bits. For example, for "Curve P-256" the point is represented >> as a bit string of length 515 bits. > Here it is clearly wrong - it is not (curve_size * 2 + 3), but > (curve_size_padded_to_8 * 2 + 3). I accept your correction. The "curve_size*2+3" above is only true for sizes that are even to 8 bits. > Missing detail: In addition to size check, what other validation must > be done when parsing a point? This applies to when reading a public key, > but especially when reading incoming ECDH/ECDSA message. I suggest > adding: "You must check that the point is on curve." here. I will take it as a suggestion and think how to integrate it, given that this is a general check for ECC and is not specific to OpenPGP. This valid concern may be satisfied through sources in References section. >> 8. EC DH Algorithm (ECDH) >> The key wrapping method is based on [RFC3394]. KDF produces the >> AES key that is used as KEK as specified in [RFC3394]. Refer to >> section 13 for the details regarding the choice of the KEK >> algorithm, which MUST be one of three AES algorithms. > This is only place which says that KEK *MUST* be AES-only. (Ignoring 12.2) > This is in conflict with section 12.1 and 13, where non-AES is not > disallowed. I'm not disagreeing with it, just I think it would be good > to clarify why. > > It might be good idea to disallow cipher_ids< AES128, but why disallow > Camellia and Twofish? I could imagine that because the algorithm > is not per-message but comes from key is the reason - you may not > know at key generation time all the people who want to send you messages > and what features their software has. But I think it would be > good to put the reason in the doc. > > In any case, 12.1 and 13 should be synced with the requirement. I also see the need for clarity here. In reference to compatibility, if the code understands ECC, the document assumes that it must supports AES. This is something OpenPGP RFC 4880 cannot generally rely upon. One of main criteria of this document is simplicity through limited choices, as I recall, something that Ian G advocated. It's much easier to write "use AES" than to define "strong enough" cipher. Suite B and other government standards require AES, so most application will implement it to comply, leaving us with the question why bother at all about the non-AES case? I am leaning toward fixing KEK at AES. There is no backward compatibility issue here. So, the action item for me is to make this choice clear. >> For convenience, the synopsis of the encoding method is given >> below, however, this section, [NIST SP800-56A], and [RFC3394] are >> the normative sources of the definition. >> >> Obtain authenticated recipient public key R >> Generate ephemeral key pair {v, V=vG} >> Compute shared point S = vR; >> m = symm_alg_ID || session key || checksum || pkcs5_padding; >> curve_OID_len = (byte)len(curve_OID); >> Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 || >> 01 || KDF_hash_ID || AES_alg_ID for AESKeyWrap || >> "Anonymous Sender " || recipient_fingerprint; >> Z_len = key size for AES_alg_ID to be used with AESKeyWrap >> Compute Z = KDF( S, Z_len, Param ); >> Compute C = AESKeyWrap( Z, m ) as per [RFC3394] >> VB = convert point V to octet string >> Output (MPI(VB) || len(C) || C). >> >> The decryption is the inverse of the method given. Note that the >> recipient obtains the shared secret by calculating >> >> S = rV = rvG, where (r,R) is the recipient's key pair. >> >> Consistent with section 5.13 Sym. Encrypted Integrity Protected >> Data Packet (Tag 18) of [RFC4880], the MDC SHOULD be used anytime >> symmetric key is protected by ECDH. > Missing detail: How to generate v? What requirements it has? > I suggest expanding the second step with: > > Generate ephemeral key pair {v, V} where V=vG and v is random number > in range 0< v< n (n - curve modulus) This detail is also related to a question of external reference, but I am glad you raised this question. FIPS 186-3 defines two methods in B.4 on p.61. The idea is this: B.4.1: if you do "v = v' mod order", the input v' must be 64 bits longer than "order". B.4.2: or you can repeatedly getting random bits until "v' < order" (probably too wasteful for the entropy) > As I noted earlier 8) claims to define ECDH as used in OpenPGP, > and it does - I managed to implement ECDH without digging in those > "real" specs. That was the only point that I needed to look up. > I think is worth adding here, mostly because it simple. So far there are two general ECC methods that you found helpful. I will think what's the best way to integrate them. >> 9. Encoding of public and private keys >> As an implementation note, observe that the ECDH public key fields >> are the super-set of the ECDH key fields. > First one should be ECDSA. Thank you, will correct this. >> 13. Security Considerations >> SHA-1 MUST NOT be used for ECDSA or with KDF in ECDH method. > But MD5 can? How about RIPEMD160? Why single out SHA1? Because it's a hardwired default choice of RFC 4880 for the hash algorithm and so it's implicitly assumed to be present in the hash preference list. I agree that "SHA-1 or weaker" simply looks better. > > Final note: the section 8 was quite successful at describing ECDH, > how hard would it be to have same level of description of ECDSA here? > At least I would like to see packet format here, even if the > algorithm is not described. Marko, did you realize that it happens that the signature format for ECDSA is identical to DSA? The (r,s) signature pair consists of (true) MPIs in both cases. The ECDSA key is defined in section 9. Overall, ECDSA for OpenPGP is much simpler because it has no complexities like key wrapping. With this in mind, what would you like to see added to properly implement ECDSA. The simlilarity ECDSA with DSA in in OpenPGP is a good thing because signature keys are the foundation for interoperability. For example, it's the top signature key that validates the key preferences and holds subkeys. Thank you, again, for your comments. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1KHPdMV057254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 10:25:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q1KHPdMM057253; Mon, 20 Feb 2012 10:25:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-yw0-f43.google.com (mail-yw0-f43.google.com [209.85.213.43]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1KHPcaH057248 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 20 Feb 2012 10:25:38 -0700 (MST) (envelope-from markokr@gmail.com) Received: by yhkk6 with SMTP id k6so3816959yhk.16 for ; Mon, 20 Feb 2012 09:25:37 -0800 (PST) Received-SPF: pass (google.com: domain of markokr@gmail.com designates 10.236.176.233 as permitted sender) client-ip=10.236.176.233; Authentication-Results: mr.google.com; spf=pass (google.com: domain of markokr@gmail.com designates 10.236.176.233 as permitted sender) smtp.mail=markokr@gmail.com; dkim=pass header.i=markokr@gmail.com Received: from mr.google.com ([10.236.176.233]) by 10.236.176.233 with SMTP id b69mr29807623yhm.122.1329758737960 (num_hops = 1); Mon, 20 Feb 2012 09:25:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=esUw652f3Wp440I68S4U63CuV+jp6Kd7mdZgA8mbbkM=; b=moWz9jwHxH3nt1xb3pWZ5i/J1hix0TSp+hJYWhUim77qdrhGxnqTbnPmyeiXiHbuiu u5l4xsvLTBPTl7+WUL320SnnOJPi1M72L70Wc/qkDmmskBHgHWXxou0HQjJYBK19k4LQ 304IqCJvL4lt9zNKq02OVUyWZ0W6AGhVcesWg= MIME-Version: 1.0 Received: by 10.236.176.233 with SMTP id b69mr22983142yhm.122.1329758737918; Mon, 20 Feb 2012 09:25:37 -0800 (PST) Received: by 10.236.48.132 with HTTP; Mon, 20 Feb 2012 09:25:37 -0800 (PST) In-Reply-To: <20120218215115.GA18978@gmail.com> References: <20120218215115.GA18978@gmail.com> Date: Mon, 20 Feb 2012 19:25:37 +0200 Message-ID: Subject: Re: Review of draft-ecc-09 From: Marko Kreen To: ietf-openpgp@imc.org Cc: Andrey_Jivsov@symantec.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id q1KHPcaG057249 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Feb 18, 2012 at 11:51 PM, Marko Kreen wrote: > Missing detail:  How to generate v?  What requirements it has? > I suggest expanding the second step with: > >     Generate ephemeral key pair {v, V} where V=vG and v is random number >     in range 0 < v < n  (n - curve modulus) This should be "n - base point order". Sorry. Btw, is this right place to send feedback about draft? This list has seen some traffic about the draft, but it has quieted down recently. -- marko Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1ILpM5f098086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Feb 2012 14:51:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q1ILpM4w098085; Sat, 18 Feb 2012 14:51:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.171]) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1ILpKnH098078 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Sat, 18 Feb 2012 14:51:21 -0700 (MST) (envelope-from markokr@gmail.com) Received: by eaan12 with SMTP id n12so2061563eaa.16 for ; Sat, 18 Feb 2012 13:51:19 -0800 (PST) Received-SPF: pass (google.com: domain of markokr@gmail.com designates 10.14.50.193 as permitted sender) client-ip=10.14.50.193; Authentication-Results: mr.google.com; spf=pass (google.com: domain of markokr@gmail.com designates 10.14.50.193 as permitted sender) smtp.mail=markokr@gmail.com; dkim=pass header.i=markokr@gmail.com Received: from mr.google.com ([10.14.50.193]) by 10.14.50.193 with SMTP id z41mr7346124eeb.19.1329601879926 (num_hops = 1); Sat, 18 Feb 2012 13:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition; bh=g9+WfYBQ/fuwK8J/QKswYXARQf7rJsPYpToiv7b38FI=; b=czvASDf636Ir8tVZTH1+dGfoHG+A6BFfwHRsgcKEYRaffeS+X63K87GSoxnOA8VG35 nK1T/qV1UbH9EmQ7oSMvkfJnP7sFVAHIlvWKjt26ueYQIRw15AbKfSU4MoXvzg2M7eWf KIUxOmzce8EWseq19/Zx/ns0G+mR9HRel+P7c= Received: by 10.14.50.193 with SMTP id z41mr5903530eeb.19.1329601879834; Sat, 18 Feb 2012 13:51:19 -0800 (PST) Received: from gmail.com (turu7.ee. [217.159.207.194]) by mx.google.com with ESMTPS id a58sm56436923eeb.8.2012.02.18.13.51.17 (version=SSLv3 cipher=OTHER); Sat, 18 Feb 2012 13:51:18 -0800 (PST) Date: Sat, 18 Feb 2012 23:51:15 +0200 From: Marko Kreen To: ietf-openpgp@imc.org Cc: Andrey_Jivsov@symantec.com Subject: Review of draft-ecc-09 Message-ID: <20120218215115.GA18978@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I tried to implement ECC for pgcrypto, which is crypto module for PostgreSQL database. And I managed to get it to work, mainly because of EC module in OpenSSL, which allowed me to be ignorant of all low-level math details. Also, I only implemented ECDH, pgcrypto does not do signing. It uses PGP as a fancy encrypt/decrypt storage format only. So this is a review of draft-08 by app developer who is ignorant of EC math and has not read any detailed math/crypto papers... [ I updated the review with diff from -09. Thanks for taking my comments on the ref section into account. ] > 5. Supported public key algorithms > > Supported public key algorithms are Elliptic Curve Digital > Signature Algorithm (ECDSA), defined in [FIPS 186-2], and Elliptic > Curve Diffie-Hellman (ECDH), defined in section 8. Note for later: this basically states that section 8 plans to fully describe ECDH used in OpenPGP. > 6. Conversion primitives > > The method to convert an EC point to the octet string is defined in > [SEC1]. This specification only defines uncompressed point > format. For convenience, the synopsis of the encoding method is > given below, however, the [SEC1] is the normative source of the > definition. > > The point is encoded in MPI format. The content of the MPI is the > following: > > B = B0 || x || y > > where x and y are coordinates of the point P = (x, y), each encoded > in big endian format and zero-padded to the underlying field size. *Then*, they are also padded to byte boundary. As this is not mentioned anywhere, it caused me some confusion, because I assumed they already are on byte boundary, perhaps even power-of-two. As it only matters to P-521 keys, the bad assumtions work fine on P-256 and P-384 keys. (Basically I assumed P-521 uses 512-bit values...) > B0 is a byte with following values: > > value description > > 0 Point O. In this case there is no x or y octets present. > > 4 Uncompressed point. x and y of EC point values follow. > > Note that point O shall not appear in a public or a private > key. Therefore, the size of the MPI payload is always curve_size*2 > + 3 bits. For example, for "Curve P-256" the point is represented > as a bit string of length 515 bits. Here it is clearly wrong - it is not (curve_size * 2 + 3), but (curve_size_padded_to_8 * 2 + 3). Missing detail: In addition to size check, what other validation must be done when parsing a point? This applies to when reading a public key, but especially when reading incoming ECDH/ECDSA message. I suggest adding: "You must check that the point is on curve." here. > 8. EC DH Algorithm (ECDH) > The key wrapping method is based on [RFC3394]. KDF produces the > AES key that is used as KEK as specified in [RFC3394]. Refer to > section 13 for the details regarding the choice of the KEK > algorithm, which MUST be one of three AES algorithms. This is only place which says that KEK *MUST* be AES-only. (Ignoring 12.2) This is in conflict with section 12.1 and 13, where non-AES is not disallowed. I'm not disagreeing with it, just I think it would be good to clarify why. It might be good idea to disallow cipher_ids < AES128, but why disallow Camellia and Twofish? I could imagine that because the algorithm is not per-message but comes from key is the reason - you may not know at key generation time all the people who want to send you messages and what features their software has. But I think it would be good to put the reason in the doc. In any case, 12.1 and 13 should be synced with the requirement. > For convenience, the synopsis of the encoding method is given > below, however, this section, [NIST SP800-56A], and [RFC3394] are > the normative sources of the definition. > > Obtain authenticated recipient public key R > Generate ephemeral key pair {v, V=vG} > Compute shared point S = vR; > m = symm_alg_ID || session key || checksum || pkcs5_padding; > curve_OID_len = (byte)len(curve_OID); > Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 || > 01 || KDF_hash_ID || AES_alg_ID for AESKeyWrap || > "Anonymous Sender " || recipient_fingerprint; > Z_len = key size for AES_alg_ID to be used with AESKeyWrap > Compute Z = KDF( S, Z_len, Param ); > Compute C = AESKeyWrap( Z, m ) as per [RFC3394] > VB = convert point V to octet string > Output (MPI(VB) || len(C) || C). > > The decryption is the inverse of the method given. Note that the > recipient obtains the shared secret by calculating > > S = rV = rvG, where (r,R) is the recipient's key pair. > > Consistent with section 5.13 Sym. Encrypted Integrity Protected > Data Packet (Tag 18) of [RFC4880], the MDC SHOULD be used anytime > symmetric key is protected by ECDH. Missing detail: How to generate v? What requirements it has? I suggest expanding the second step with: Generate ephemeral key pair {v, V} where V=vG and v is random number in range 0 < v < n (n - curve modulus) As I noted earlier 8) claims to define ECDH as used in OpenPGP, and it does - I managed to implement ECDH without digging in those "real" specs. That was the only point that I needed to look up. I think is worth adding here, mostly because it simple. > 9. Encoding of public and private keys > As an implementation note, observe that the ECDH public key fields > are the super-set of the ECDH key fields. First one should be ECDSA. > 13. Security Considerations > SHA-1 MUST NOT be used for ECDSA or with KDF in ECDH method. But MD5 can? How about RIPEMD160? Why single out SHA1? Final note: the section 8 was quite successful at describing ECDH, how hard would it be to have same level of description of ECDSA here? At least I would like to see packet format here, even if the algorithm is not described. -- marko