Curve41417?

[WildCryptoFox]

Hello, any chance that we can get a Curve41417 implementation? It is a strong curve with a very large keyspace and I'm sure that I'm not the only cypherpunk who wishes to use this Curve. :-)

Edit: Among other curves such as Ed448-Goldilocks, M-511, E-521, etc.

[jedisct1]

One of the things we absolutely want to avoid is the library becoming a kitchen sink, offering too many options to achieve a given operation.

A new primitive or a new construction is not added because it is new and it looks cool. It is added if:

• It is required to solve a common problem (ex: scrypt)
• It is required for interoperatibility with the rest of the world (ex: chacha20)
• A serious attack is found on an existing primitive

Curve41417 and Ed448-Goldilocks are great, but:

• Implementations are pretty much nonexistent, and will be slower than Curve25519
• I couldn't even find test vectors for Curve41417
• They haven't received much adoption yet

Bigger is better, but there is no urgency for immediately moving away from Curve25519. Because, yes, if another curve is added now, it will be interpreted as "the previous choice was not safe". Which is not the case.

Right now, helping Curve25519 become a standard is probably a better thing to do than causing a diversion.

It doesn't mean that bigger curves won't be added later. But doing it today would be a bit premature.

[tarcieri]

FWIW, the CFRG or IETF will (hopefully) select some new high security curves soon which will be usable within TLS. Once that happens it would be probably be good to add whatever they select to libsodium.

There are many other neat high security curves, such as Ed448-Goldilocks that @jedisct1 mentioned, along with P389 and E-521. We'll see which ones actually get selected.

[WildCryptoFox]

The main reason that they aren't adopted yet is because the implementations barely exist. So no chance for even going into a development-branch for less-standardized functions?

Also; having this as an option in said development-branch would display "we are prepared for alternative methods".

Better still; it would be great to see all of these curves as development options available for audit for future usage if ever needed.

[mouse07410]

On Jan 4, 2015, at 18:35 , james-darkfox notifications@github.com<mailto:notifications@github.com> wrote:

The main reason that they aren't adopted yet is because the implementations barely exist.

AFAIK, the main reason is that it hasn’t been agreed upon by CFRG and there is no “de-facto” acceptance in the field (like already-existing support in popular browsers such as Chrome or Firefox, and in packages such as OpenSSL and OpenSSH).

I don’t think anybody at IETF would even notice - much less case - if NaCl or libsodium were to provide an implementation.

So no chance for even going into a development-branch for less-standardized functions?

IMHO it would be nice to have them in a development branch - the question is who’s going to do that (not me for sure). :-)

Uri Blumenthal uri@mit.edumailto:uri@mit.edu

[WildCryptoFox]

Uri: Who indeed, hence this issue exists! Calling for anyone interested. Sadly; this issue was quickly closed in a wont-fix style instead of considering the development branch as later mentioned.

[mouse07410]

I suspect that the main reason is that the developers lack spare cycles to dedicate to this. But I don't think they can (or want to) preclude others from branching out and adding those algorithms? Though as I said, adding them would help little, if at all, their advancement. The only possible benefit could be providing CFRG with performance numbers.

[tarcieri]

@james-darkfox none of these curves are implemented in such a way that I would consider actually using them. Namely libsodium currently provides optimized assembly implementations ("donna") of Curve25519/Ed25519 that are guaranteed to run in constant time. All of the other curves are a bit "bleeding edge" at the moment.

Furthermore, there's not a whole lot of reasons to use a higher security curve. Attacks that work on Curve25519 are likely to work on larger curves/fields as well.

I would suggest sticking to Curve25519/Ed25519 until more mature implementations of the other curves are produced. All of them are very much "experimental" right now, whereas Curve25519 is definitely production quality.

[WildCryptoFox]

I see the argument; but again, a development branch would provide an open implementation that can be used, improved, and if required enabled for mainstream usage. Existing in such a branch would simply help with their development as a curve. Won't affect the stability, integrity or other concerns of the larger project. If anything, having the options available for testing, auditing and improving it enables research to be done using more curves and should changes need to be made down the track; the code is there and may have been improved at such a time.

I'd love to see these curves implemented in a lib-sodium-compatible and usable form; definitely not modern defaults; just available somewhere. Let that somewhere be a development branch or an external staging repo; it only helps with development and potential future usage.

[tarcieri]

In GitHub land, I believe what you're describing is called a 'fork'

[jedisct1]

What can help these curves have more adoption and performance numbers is having more implementations. Heck, curve41417 is not even in Supercop yet.

My take is that for the time being, having standalone implementations is the thing to do instead of adding them to Sodium.

And once the best curve is being agreed upon by CFRG/IETF, merge implementations for it to Sodium.

[jedisct1]

Got some spare cycles (being unemployed sucks), so as a start, I can write a portable curve41417 C implementation this week. But this is going to be a standalone implementation that you can link to your projects in addition to libsodium if you want to.

[odiferousmint]

Got some spare cycles (being unemployed sucks), so as a start, I can write a portable curve41417 C implementation this week. But this is going to be a standalone implementation that you can link to your projects in addition to libsodium if you want to.

Have you finished implementing Curve41417? If so, could you provide a link to the source code?

[jedisct1]

Never had any use case for it, so no.