Re: [Cfrg] When's the decision?

[Watson Ladd <[e-mail]>]

On Mon, Oct 6, 2014 at 9:07 PM, David Jacobson <[e-mail]> wrote:
> On 10/6/14, 4:28 PM, Watson Ladd wrote:
>
>
> On Oct 6, 2014 8:57 AM, "Stephen Farrell" <[e-mail]> wrote:
>>
>>
>> Hiya,
>>
>> On 06/10/14 16:53, Yoav Nir wrote:
>> > They’re all good enough
>>
>> Tend to agree. But CFRG, pretty-please don't pick them all!
>
> This ignores the significance of choices such as which coordinates to use on
> the wire, whether to use compression, and which signature scheme to use.
>
> These are not make or break items, and any curve could be used several ways,
> but these issues do not go away with the choice of curve.
>>
>> If you do we'll just have to pick elsewhere (e.g. saag or
>> specific IETF wgs) with less clue immediately involved.
>
> Agreed: the buck stops here.
>>
>> S.
>>
>
>
> I've implemented elliptic curve systems quite a few times.  But never with
> compression.  (The patent just expired.)  Could someone with experience
> implementing compression and with the short list of candidates, comment, for
> each curve, on how much of a hassle compression is to write, how much it
> expands the code, and how much it slows down the computation?

Huh? The choice of formula doesn't have much of an impact. For any
prime not 1 mod 8, a single square root is pretty quick: equivalent to
a single modular exponentiation. Compression doesn't add much time.

Montgomery form never needs compression: the question is whether
Edwards points should be compressed. This reduces the size of
signatures, but isn't as critical for security as
compression/validation of points for use in ECDH.

The code bloat is another addition chain, but you can probably take
advantage of the relation between (p+1)/4 and p-1 when code size is a
concern.

Sincerely,
Watson Ladd

>
> If the hassle, code bloat, and slowdown are minor, I suggest we just do
> compressed.  (Rationale:  Compression is always a win so do compressed.
> Keep it simple---no options)
>
> If the hassle, code bloat, or slowdown are considerable, I suggest we
> require uncompressed and make compressed optional.  (Rationale:  Compression
> is sometimes a win, e.g. for applications were bits on the wire are
> precious, and sometimes a lose.  For guaranteed interoperability there
> should be one variant that is always there, and that one should be the
> simpler, smaller.)
>
> This probably interacts with the on-the-wire representation.  That will make
> the deciding a bit harder, but such is life.
>
>    --David Jacobson
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin