Subject: [Cfrg] Curves as groups

From: Douglas Stebila <[email-masked]>
Date: Fri, 8 Aug 2014 22:36:25 +0000

Do members of CFRG think it important that the curve(s) we recommend be usable as arbitrary groups?  By this I mean that the implementations readily expose both a scalar point multiplication operation and a point addition operation.  

Utility as arbitrary groups would I think imply criteria R3 (Desired: re-use components between signatures and key exchange algorithms) but the reverse is not necessarily true.  

Curve25519+Ed25519 together give key exchange and signatures, but are high-level cryptographic functions, not groups.  The Curve25519 private API has scalar point multiplication functions but not point addition; the Ed25519 private API has both.  The NUMS library has public interfaces for scalar point multiplication and kP+lQ, but arbitrary point addition is only in the private API with a disclaimer on context of use.  To what extent are these a choice by implementers to only implement the functions needed to achieve their desired cryptographic scheme versus inherent to the mathematical design?

While criteria R3 will ensure we have something that we can use for key exchange and signatures immediately, I think it would be good for cryptographers to also have good, plain old groups from elliptic curves, for whatever new schemes we may invent or try to implement over the next 10 years.  Prior IETF initiatives (RFC 3526, RFC 5114) seem to have focused on groups rather than key exchange / signature functions.

Douglas

---

From: Michael Hamburg <[email-masked]>
Date: Fri, 8 Aug 2014 18:14:58 -0700

> On Aug 8, 2014, at 3:36 PM, Douglas Stebila <[email-masked]> wrote:
> 

I think that’s a good idea.

> Utility as arbitrary groups would I think imply criteria R3 (Desired: re-use components between signatures and key exchange algorithms) but the reverse is not necessarily true.  

Right.  For example, you can do Schnorr signatures with Curve25519’s scalar multiplication API, so long as the signature is in (kG, s) form.

> Curve25519+Ed25519 together give key exchange and signatures, but are high-level cryptographic functions, not groups.  The Curve25519 private API has scalar point multiplication functions but not p…

It’s some and some.  Exposing only a kP+lQ allows you to expose an API that deals only with affine points, or even only serialized points, which avoids committing to the internal point representation format.  Furthermore, the curve might be specified one way for safety or clarity, but implemented another way for speed.

The MSR NUMS library operates on Twisted Edwards curves over a 3 mod 4 field, which have an incomplete addition formula.  This formula can be used safely only if the protocol is is designed to avoid the troublesome points, eg by clearing the cofactor.  The kP+lQ actually computes k(4P) + l(4Q) or something similar to avoid this problem.  So there’s a good reason not to expose the point addition function in the API.

Likewise, my own curve, Ed448-Goldilocks, is specified as an Edwards curve.  But internally my implementation uses an isogenous twisted Edwards curve for speed.  The isogeny clears the cofactor, so this approach is also completely safe.  The library doesn’t need to add points on the untwisted curve, so it doesn’t have that API, but it would be easy and safe to write if it were needed.  By the way, specifying untwisted and implementing twisted is a carefully thought out strategy, and I would recommend adopting it for any CFRG-approved cofactor-4 curves; see http://eprint.iacr.org/2014/027 .

> While criteria R3 will ensure we have something that we can use for key exchange and signatures immediately, I think it would be good for cryptographers to also have good, plain old groups from ell…

Agreed.

Cheers,
— Mike

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 9 Aug 2014 14:45:22 +0300

On Fri, Aug 08, 2014 at 06:14:58PM -0700, Michael Hamburg wrote:
> 
> It’s some and some.  Exposing only a kP+lQ allows you to expose an API
> that deals only with affine points, or even only serialized points,
> which avoids committing to the internal point representation format.
> Furthermore, the curve might be specified one way for safety or clarity,
> but implemented another way for speed.
> 
> The MSR NUMS library operates on Twisted Edwards curves over a 3 mod 4
> field, which have an incomplete addition formula.  This formula can be
> used safely only if the protocol is is designed to avoid the troublesome
> points, eg by clearing the cofactor.  The kP+lQ actually computes
> k(4P) + l(4Q) or something similar to avoid this problem.  So there’s a
> good reason not to expose the point addition function in the API.

Some I-D (and probably some RFCs too) have ECC algorithms that need
point addition and scalar multiplication without extra factors.

Eg, equations of type: Y = a(Z + bX).

Yes, one could premultiply scalars to cancel out extra factors, but:
- There may be not-premultiplied points (e.g. Z above).
- Applications would probably not appriciate having to do the premults.[1]

So the library should also expose:
- Point addition without prefactors
- Scalar multiply without prefactors

And these need to to be correct w.r.t. projection along <G>[2], and result
in points in <G> if inputs are in <G>.

Also: The primary curve specified SHOULD be complete.

Rationale: Using incomplete primary curves awards bad implementations as
it is not at all obvious what the exact failure cases are, probably resulting
in lots of bad implementations (that appear to work, until attacker appears).

MSR "NUMS" Edwards curves fail this (all are incomplete twisted Edwards).
-x^2+y^2=1+(1-1/121666)*x^2*y^2 (mod 2^255-19) would pass, since it is
complete despite being twisted.

Library taking shortcuts is another matter, and then the library maker
should know what they can get away with.

Here's my own list of functions that I think ECC lib should provode for
each Edwards curve (all constant time except failures or if said otherwise,
group ops produce correct projection along <G>, produce elements in <G> if
given inputs in <G>[3]):

- Get curve by name (and possibly by OID).
- Compute X=kG, where X is in Montgomery-x integer form (DH first step)
- Compute Y=kX, where X and Y are in Montgomery-x integer form (DH second
  step)
- Load (un)compressed group element in native/Weierstrss coordinates,
  erroring out on invalid point.
- Save (un)compressed group element in native/Weierstrss coordinates
- Get base prime
- Get number of bits in base prime
- Get order field size
- Get number of bits in order field size
- Group generator (actually generator of order-l subgroup)
- Group (i.e. E) addition
- Group substraction
- Group scalar multiply
- Group scalar multiply with G as base.
- Group double-scalar multiply (can be variable-time?)
- Check for low-order element in group (hX = 0? Edwards curves have
  tricks to do this fast, might not be constant-time)
- Are two group elements equal?
- Get native X coordinate as integer.
- Get native Y coordinate as integer.
- Get Weierstrass X coordinate as integer.
- Load integer as (nonzero) scalar field[2] element, erroring out on
  invalid value
- Reduce integer to (nonzero) scalar field (Z_l) element (timing depends
  on input length)
- Are scalar field elements equal?
- Is scalar field element zero?
- Scalar field addition
- Scalar field substraction
- Scalar field negation
- Scalar field multiplication
- Scalar field reciproal
- Convert scalar field element to integer

The underlying types should depend on kind of thing but not the curve
and can be opaque (hint: don't inline the sizes of various structures
into whatever uses the library[4]).

Additionally, the methods should wipe all temporaries from memory after
completion, including from the stack[5].

This list was chosen so that widest variety of different ECC algorithms
(excluding very specialized ones like pairing-based ones[6]) can be
supported with minimum knowledge about curves or annoying[7] math in the
application, and supporting multiple curves is as easy as possible.

The Weierstrss coordinate methods are there in order to support legacy
algorithms like ECDSA.

[1] Those mults are in order field, which tends to be nastier to work with
than the base field (due to the prime not being too close to power of two).

[2] All practical ECC curves have well-defined projections along <G> and
scalar fields (nobody uses the pathologic or infinite curves that don't).

[3] This is weaker condition than producing correct answers for ever curve
point, but should be sufficient to handle bad inputs safely.

[4] Such inlining creates maintenance problems later.

[5] Yes, I heard somebody complain about this loudly.

[6] These also need specialized MOV-weak curves.

[7] Any such math is likely done using bignum library. Which will be a
disaster if it is e.g. calculation of S for ECDSA.

-Ilari