from Hacker News

Eccfrog512ck2: An Enhanced 512-Bit Weierstrass Elliptic Curve [pdf]

by bikenaga on 4/16/25, 6:31 PM with 16 comments

• by commandersaki on 4/20/25, 7:05 AM

  Why this over Curve448 and Ed448. Does the curve lend itself to an easier implementation? From what I can see there doesn't seem to be a compelling story here.

• by Retr0id on 4/20/25, 2:43 PM

  They say coefficient b is determined via BLAKE3, but unless I'm missing it, they don't actually say how?

  They also claim that the prime modulus was chosen "carefully", and enumerate its favourable properties, but do not elaborate on how it was chosen. Presumably they had some code that looped until they found a prime that gave them all the right properties, but it would be good if they shared that process.

• by kevvok on 4/20/25, 10:03 AM

  With the industry pivoting towards focussing on post-quantum algorithms, I’d be surprised if yet another elliptic curve gains much traction.

• by quesomaster9000 on 4/20/25, 6:33 PM

  Well, I've tried manually verifying the curve parameters and I don't trust this.

  * The generator isn't selected deterministically

  * The BLAKE3(seed) in the OpenFrogget code doesn't match what I get with Python & Javascript implementation of Blake3, the index & seed aren't specified in the paper

  * The paper doesn't provide a reference for why `a=-7` was chosen (presumably because of the GLV endomorphism)

  * the various parameters differ between the reference implementation and the paper and the spec...

  There are enough many holes in this that I wouldn't touch it yet, as a very quick glance into the spec & the code leaves me wondering why their claims of reproducibility & determinism re: the constants aren't true, and the documentation & code don't match what I can reproduce locally.

  So uhh yea... No