headers
Marko Kreen | 18 Feb 2012 22:51
Picon

Review of draft-ecc-09


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
(Continue reading)

Permalink | Reply |
headers
Marko Kreen | 20 Feb 2012 18:25
Picon

Re: Review of draft-ecc-09


On Sat, Feb 18, 2012 at 11:51 PM, Marko Kreen <markokr <at> gmail.com> 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
Permalink | Reply |
headers
Andrey Jivsov | 21 Feb 2012 08:24

Re: Review of draft-ecc-09


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.
(Continue reading)

Permalink | Reply |
headers
Marko Kreen | 21 Feb 2012 10:49
Picon

Re: Review of draft-ecc-09


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
(Continue reading)

Permalink | Reply |
headers
Andrey Jivsov | 23 Feb 2012 01:54

Re: Review of draft-ecc-09


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...)
(Continue reading)

Permalink | Reply |
headers
Marko Kreen | 21 Mar 2012 00:32
Picon

Review of draft-ecc-10


> Therefore, the exact size of the MPI payload is 515 bits for
> "Curve P-256", 771 for "Curve P-256", and 1059 for "Curve P-521".

Second P256 should be P384.

---------------------

Section 8. says MDC "SHOULD" be used with EC, secition 13. says
it "MUST" be used.

---------------------

> Marco Kreen

Thanks for the credit.  Please use correct spelling of "Marko".

--

-- 
marko
Permalink | Reply |
headers
Andrey Jivsov | 26 Mar 2012 20:32

Re: Review of draft-ecc-10


On 03/20/2012 04:32 PM, Marko Kreen wrote:
>
>> Therefore, the exact size of the MPI payload is 515 bits for
>> "Curve P-256", 771 for "Curve P-256", and 1059 for "Curve P-521".
>
> Second P256 should be P384.
>
> ---------------------
>
> Section 8. says MDC "SHOULD" be used with EC, secition 13. says
> it "MUST" be used.
>
> ---------------------
>
>> Marco Kreen
>
> Thanks for the credit.  Please use correct spelling of "Marko".
>

I integrated these comments into the posted -11 revision, along with 
editorial changes in response to "Gen-ART review".

http://datatracker.ietf.org/doc/draft-jivsov-openpgp-ecc/history/

Thank you for the comments, Marko.
Permalink | Reply |

Gmane