Subject: Re: [Cfrg] Editing work on github of draft-ladd-safecurves - References

From: =JeffH <[email-masked]>
Date: Sun, 12 Jan 2014 09:00:49 -0800

Watson Ladd wrote..
 >
 > Quite a few people have argued that I need to explain the
 > double-and-add algorithm, even though it is standard

perhaps cites of..

Silverman, Joseph H. The arithmetic of elliptic curves. Vol. 106. Springer, 
2009.
http://ivanych.net/doc/TheArithmeticOfEllipticCurves.pdf

Eisentraeger, Kirsten, Kristin Lauter, and Peter L. Montgomery. "An 
Efficient Procedure to Double and Add Points on an Elliptic Curve."
http://eprint.iacr.org/2002/112.ps

..would address (most of) those concerns?

 > some
 > people want something ala RFC 6090, while I want to avoid massive
 > bloat with implementation details that anyone implementing this draft
 > probably knows anyway.

Perhaps citing RFC 6090 as appropriate would allay those concerns?

Also, I ran across this which might be of related interest..

Walter, Colin D. "Simple power analysis of unified code for ECC double and 
add." Cryptographic Hardware and Embedded Systems-CHES 2004. Springer Berlin 
Heidelberg, 2004. 191-204.
http://www.iacr.org/archive/ches2004/31560191/31560191.pdf

HTH,

=JeffH

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 13 Jan 2014 00:47:39 +0100

> Perhaps citing RFC 6090 as appropriate would allay those concerns?
RFC 6090 is about curves in short Weierstrass form, which the curve from the
draft are not. (Of course you could convert them to short Weierstrass, but that
would not be a good idea.)

Manuel.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 12 Jan 2014 16:02:38 -0800

> would not be a good idea.)

I'm sure someone out there will do it, even though I've given them all
the details of better
multiplication algorithms in the github draft. It would be a clever
way to reintroduce weaknesses
that the current curve shapes avoid, and if you don't give your
customers the source, they would
never know.

RFC6090 was also published to avoid Certicom IPR and document
algorithms that were unpatented.
But with Montgomery curves there is none of that:
the necessary formulas appear in a paper published in 1985.

Anyway, if you think we need more implementor guidance, feel free to
send me a diff. In about a week this should
stabilize enough to be the basis for more IETF/IRTF actions, like
getting the OIDs.

Sincerely,
Watson

>
> Manuel.
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

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