[HN Gopher] Eccfrog512ck2: An Enhanced 512-Bit Weierstrass Ellip...
___________________________________________________________________
Eccfrog512ck2: An Enhanced 512-Bit Weierstrass Elliptic Curve [pdf]
Author : bikenaga
Score : 39 points
Date : 2025-04-16 18:31 UTC (4 days ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| commandersaki wrote:
| 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.
| geocar wrote:
| No. The claim is that it's about as fast as 22519 but stronger
| than 448, and might be resistant to some specific attacks. If
| that's true, that is a good thing.
|
| But please do not take this as endorsement: I don't think you
| or anyone else should use this.
|
| 448 and 22519 go to great lengths to "nothing-up-my-sleeves"
| the parameters, and this one just keeps saying "custom
| designed" parameters.
|
| This might be my failing to find it, but it's something I've
| come to expect in serious crypto papers front-and-centre.
|
| It might also be the subject of another paper the author is
| working on, mere naivete (on the authors part or mine), or part
| of a deliberate attempt to infiltrate some other/popular piece
| of software (like OpenSSL).
| commandersaki wrote:
| I only see performance comparisons with NIST P-521? I don't
| even see a claim for performance on par with Curve25519.
| geocar wrote:
| That's my bad. I was getting blurry after Table 4.
| kevvok wrote:
| With the industry pivoting towards focussing on post-quantum
| algorithms, I'd be surprised if yet another elliptic curve gains
| much traction.
| Retr0id wrote:
| The industry is mostly pivoting to hybrid schemes, and it's
| sensible to want a higher-security curve to pair with a higher-
| security PQ algorithm.
| ryao wrote:
| The pivot is occurring on both key agreement and signatures.
| Hybrid schemes currently only exist for key agreement.
| Perfect forward secrecy means that as long as the key
| agreement schemes are secure against Shor's algorithm, we can
| afford to do a much more leisurely roll out of PKI with PQ
| signing algorithms. Whether people will opt for "hybrid"
| signatures is yet to be seen.
| ryao wrote:
| That seems like a mistake, since PQAs are an objective
| downgrade from ECC in everything except for immunity to Shor's
| algorithm. It is not clear that machines with the tens of
| millions of qubits needed to run Shor's algorithm will be
| constructed since there is no quantum moore's law that gives us
| a clear roadmap to making them. If they never are made, then
| all of these PQAs will have been a waste and we will have
| missed opportunities for improvements from improved curves. For
| example, the failure to deploy EdDSA certificates in PKI has
| been a missed opoortunity. I hope the industry reverses course
| and deploys them, since they are a clear improvement over the
| current ECDSA certificates.
|
| I can see using hybrid PQAs for key agreement as a hedge
| against quantum machines actually being constructed, but with
| the upcoming 47 day certificates, there really is no need to
| avoid EdDSA. If we come anywhere near constructing a quantum
| computer that can crack the public keys, the industry could
| pivot to ML-DSA with the older EdDSA certificates expiring
| before there is any risk of them being cracked.
| Retr0id wrote:
| If we assume cryptographically-relevant quantum computers
| will one day exist, you don't just need to worry about certs
| being cracked before they expire, but also the ECDH-
| established session keys being cracked. These keys are
| ephemeral, but if you store the ciphertexts long-term, you
| can crack them at any point in the future (aka
| https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later).
| ryao wrote:
| Perfect forward secrecy means harvest now, decrypt later
| does not apply to signature algorithms when ephemeral keys
| are used and TLSv1.3 mandates ephemeral keys. If the
| ephemeral keys are cracked, that would be the fault of the
| key agreement algorithm, not the signature algorithm.
|
| > If we assume cryptographically-relevant quantum computers
| will one day exist
|
| One day could be 10,000 years in the future, so what
| meaning is there to such an assumption? You need to assume
| much more than that such machines will be constructed one
| day to suggest that there is a need for action. The
| industry is switching to hybrid key agreement algorithms
| out of an abundance of caution that it is not just one day
| that such a machine will be made, but one day in our
| lifetimes. It is not certain that will actually happen, but
| if it does, having adopted hybrid key exchange algorithms
| years in advance is enough. There is no need to switch
| signature algorithms from ECC until the creation of such a
| machine is imminent. Thus it is fine to proceed with EdDSA
| adoption in PKI.
| Retr0id wrote:
| The Eccfrog512ck2 curve can be used for both signatures
| and key agreement.
| Retr0id wrote:
| 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.
| GoblinSlayer wrote:
| Here is b:
| https://github.com/victormeloasm/OpenFrogget/blob/main/src/e...
| quesomaster9000 wrote:
| And even with the constant `b=BLAKE("ECCFrog512CK2 forever")`
| there is an open question, while not as problematic as it is
| with the NIST & SEC curves, it's covered in "How to
| manipulate curve standards: a white paper for the black
| hat"[1]
|
| I'm surprised they didn't include the constant in the paper
| and at least a short justification for this approach, despite
| stating "This ensures reproducibility and verifiable
| integrity" in section 3.2, whereas several other curves take
| the approach of 'smallest valid value that meets all
| constraints'.
|
| Really they should answer the question of "Why can't `b` be
| zero... or 1" if they're going for efficiency, given they're
| already using GLV endomorphisms.
|
| Likewise with the generator, I see no code or mention in the
| paper about how they selected it.
|
| [1]: https://eprint.iacr.org/2014/571.pdf
| quesomaster9000 wrote:
| 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
___________________________________________________________________
(page generated 2025-04-20 23:02 UTC)