Re: [Curdle] IETF time slot / next step for CURDLE

[Ilari Liusvaara <[e-mail]>]

On Tue, Jun 27, 2017 at 08:26:03AM -0700, Mark D. Baushke wrote:
> Hi Daniel,
> 
> Daniel Migault <[e-mail]> writes:
> 
> > As we are close to have all our document sent to the IESG, we would
> > like to understand if you see any future work items. Please provide
> > any thoughts on the mailing list.
> 
> There are a number of expired and dead drafts that should probbly be
> finished (ssh-ed25519, dnskey-ed25519, pkix-eddsa, pkix-newcurves).

ssh-ed25519 actually seems dead, and I can't find any repacment
draft. Note, there are existing implementations here that could be
documented.

dnskey-ed25519 was superceded, replacement is RFC 8080.

pkix-eddsa and pkix-newcurves merged into pkix, currently sent to
IESG (what's up with that currently, last log entry is from beginnning
of may?).

> I think some work on a better way to create Diffie-Hellman primes may
> also be good to consider. There should be a way to use provable primes
> that are not backdoored and do not leak bits due to using a generator
> which does not generate a q-ordered subgroup. I would very much like to
> see this used as long term we know that the use of fixed groups makes an
> attractive target for precomputation.

Basically, there are no known bad primes for ECC except the too small
ones. However, the prime choice makes major impact on performance.
Therefore in most cases, the primes should be selected for performance.

The main problems with Edwards curves is cofactor of at least 4. That
may be problematic for some more exotic ECC algorithms (where just
clearing the cofactor doesn't work).  There are some rather clever
tricks for representations that behave like there is no cofactor.

The main advantages of Edwards curves is fast unified arithmetic, which
makes implementation in side-channel silent way reasonably easy.
Complete Edwards curves also map into complete Montgomery curves,
which are handy for implementing ECDH.

Then there is the two-edged sword of having the neutral point be like
other points. It is sure nice for side-channel silent implementations,
but can cause problems with some algorithms, especially in misuse
situations (CryptoNote recently had a security issue due to misuse of
Ed25519).

> To be fair, this group may also want to start looking at
> Post-Qutanum-Cryptographic algorithms as well. Or, perhaps that will be
> a new working group for the future.

For PQC, I think most that should be done in this group is integration
tests (for discovering hidden problems with things like message sizes).
Those are at most experimential with extra warnings that there is very
little evidence that the algorithm is any good, and should not be
implemented except for testing.


-Ilari