# Weaker alternative to Ed25519?

For me, the main advantages of Ed25519 are that it avoids patents (by computing in one dimension) and that it is fast.

However, the 128bit security of Ed25519 is sometimes too strong to comply with export regulations.

So I wonder if there are any weaker curves of the same type (i.e. also patent-free and fast) that I can use instead? (or should I go deeper into ECC and try to determine myself the parameters of such a curve?)

• Which export regulations?
– user2552
Apr 14 '15 at 12:36
• @Bristol : In the Wassenaar arrangement (dual-use list - cat. 5 – part 2 – "information security") it says "Discrete logarithms in a group other than mentioned in 5.A.2.a.1.b.2. in excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve);" Apr 14 '15 at 12:47
• @Chris Why use crypto at all, if its extremely weak? 56 bits of security is rather dubious. You should rather figure out how to comply with the export regulations of your country. Some countries (like Germany) don't care at all. In the US you need to jump through a couple of bureaucratic hoops, but shouldn't be too difficult. Apr 14 '15 at 14:52
• @CodesInChaos : I can then put a demo online without worrying who is downloading the stuff. Further, I also use temporary Pederson commitments and zero-knowledge proofs to ensure that participants do not cheat in a multi-party protocol. An attacker would have to falsify the commitment during the execution, and I think that even a weak curve can provide a few seconds of security. :) But I will also follow your recommendation and try the bureaucratic route. Thanks! Apr 14 '15 at 16:33
• Most countries in the Wassenaar arrangement have relaxed export rules for "mass-market" encryption hardware and software, as such rules are required for the modern Internet to work at all. From the US for instance, you only have to avoid exporting common stuff like this to the 5 "rogue states" or to terrorists. Apr 14 '15 at 19:42

## 2 Answers

You could try the 112-bit secp112r1 cited in [1].

Before you do this, the problem with that paper is they actually show how to break the discrete log problem on this curve! And this was back in 2012. So any export-strength implementation of ECC is definitely breakable by governments, research groups and sufficiently determined/resourceful commercial adversaries.

So you'd be selling crypto that, while safely exportable, is known to be breakable and you're competing against other crypto libraries that don't have this "feature". I'm skeptical whether this is a sensible idea.

EDIT: oops, I forgot to check the key point - that it's patent-free. But the problem remains that any 112-bit curve, patented or not, is small enough that one can feasibly if not easily take discrete logs.

EDIT2: on my machine, openssl ecparam -list_curves includes secp112r1 and according to [2] sun wrote the OpenSSL ECC package "precisely to avoid any patented method". To me it looks like you should be fine with that curve as long as you don't re-implement it using any of the patented implementation techniques. This is not legal advice of course.

• Its a pity that the curve is broken already, but I think it can still be very useful. For instance, I can put a weakened demo version of my application online, without having to worry about potential legal problems. Thank you! Apr 14 '15 at 15:50

While Bristol's answer solves the problem of finding any 112-bit curve, it's not actually a proper alternative to Ed25519 in the sense that it isn't a (twisted) Edwards curve.

I state again, agreeing the common consensus in this thread, that it is pointless from a security perspective to pursue 112-bit curves. But sometimes you do want your demo code to be available in those “rogue states”. Or your legal department makes you, anyway.

Disclaimer: I am not a lawyer. This is not legal advice on how to properly comply with all or any applicable laws, including the Wassenaar agreement and its transformation(s) in applicable jurisdiction(s).

# Finding a curve

I'm not aware of any such curve already having been specified, but [1] specifies a validation program written in Magma for their curves of varying levels. They do not specify a 112-bit curve in their paper, but their Magma script can be repurposed to generate a curve at the 112-bit “security” level by picking a suitable prime and incrementing $$d$$ by one until a curve checks out.

Following the strategy outlined in [1] to pick a prime $$p$$ as close as possible to $$2^{112}$$ and adapting their code, you get the Edwards curve $$x^2+y^2=1-1260x^2y^2$$ over $$\mathbb{F}_{2^{111}-37}$$:

• field prime $$p = 2^{111}-37$$, observing that $$p \equiv 3 \pmod 4$$ and $$37 < 111$$
• curve parameters $$a=1$$, $$d=-1260$$
• prime group order $$r=649037107316853431433280197358493$$; the curve has cofactor $$h=4$$, so the full group size is $$4r=2596148429267413725733120789433972$$, which is indeed less than $$2^{112}$$ as required by the Wassenaar agreement
• $$\rho$$ “security” of $$2^{54.3}$$
• base point $$y$$-coordinate $$y=2$$ (if you are contemplating use of Decaf or Ristretto, instead use base point at $$s=14$$)

(Aside: A suitable Montgomery curve can be found with the same code for $$p=2^{112}-75$$ at $$A=160072$$.)

I must stress that 112-bit “security” is uncomfortably thin, having been broken in an academic setting using with a cluster of PS3s; the whole thing just took a few months of number crunching in 2009.[2] At the time of writing, this was over a decade ago. Access to number-crunching GPUs is now widespread. If you rely on this for anything but the demo mentioned in the question, your system is probably going to be broken by literal brute force by any reasonably motivated attacker (quite possibly including a bunch of students their pooling free cloud provider student credit together).

It is unlikely to find an actually secure alternative in the elliptic curve space – it is likely intended that only cryptography that is reasonably breakable by nation-state actors is excluded from any kind of restrictions entirely.

# Instantiating EdDSA

Ed25519 is an instantiation of EdDSA.[3] The parametrization of EdDSA is described more closely in [4]. The following parameters would work for the curve described above:

• $$q$$ is $$p$$ above
• $$b = 112$$ (rounding up $$p$$ to the nearest byte)
• $$H$$ is instantiated as either SHA-224, SHA-512/224 or SHA3-224 (you may need avoid BLAKE2 because its native support for being used as a MAC introducing a component with a [long] key again; at least the Wassenaar agreement itself doesn't seem to care about hash functions)
• $$c = 2$$ (because cofactor $$h=4$$, $$c$$ being $$\log_2 h$$)
• $$n = b-1 = 111$$
• $$a$$ and $$d$$ as per the curve noted above
• $$B$$ as either of the possible points that are valid for the $$y$$-coordinate for the base point above or the Decaf/Ristretto point at $$s$$ above if using Decaf/Ristretto
• $$\ell$$ is $$r$$ above

(Note that [3] requires you to use domain separation strings and the dom2() function since you instantiate EdDSA as not-Ed25519.)

# References

[1] Diego F. Aranha, Paulo S. L. M. Barreto, Geovandro C. C. F. Pereira, Jefferson E. Ricardini. A note on high-security general-purpose elliptic curves, 2013 (version 20190123:033905).

[2] Joppe W. Bos, Marcelo E. Kaihara, Thorsten Kleinjung, Arjen K. Kenstra, Peter L. Montgomery. On the Security of 1024-bit RSA and 160-bit Elliptic Curve Cryptography, 2009.

[3] S. Josefsson, I. Liusvaara. Edwards-Curve Digital Signature Algorithm (EdDSA), RFC 8032, 2017.

[4] Daniel J. Bernstein, Simon Josefsson, Tanja Lange, Peter Schwabe, Bo-Yin Yang. EdDSA for more curves, 2015.

• Has anybody verified these parameters as actually correct? I have tried to implement these parameters on various platform (Boost multiprecision, Sage, and ARM custom multiprecision library) and all three yield the same incorrect result. I have imlpemented 25519, 336 ,414, 448, and 521 curves without issue, so I suspect there is something incorrect in one of the parameters here. How could I go about verifying that all the specified parameters are actually correct? Note : B * l is supposed to be NEUTRAL, yet I consistantly get the same erroenous value on all three platforms. Jun 1 at 21:34