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.
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.
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.
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 naiveté (on the authors part or mine), or part of a deliberate attempt to infiltrate some other/popular piece of software (like OpenSSL).
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.
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).
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.
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.
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.
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.
Here is b: https://github.com/victormeloasm/OpenFrogget/blob/main/src/e...
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
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.
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 naiveté (on the authors part or mine), or part of a deliberate attempt to infiltrate some other/popular piece of software (like OpenSSL).
I only see performance comparisons with NIST P-521? I don’t even see a claim for performance on par with Curve25519.
That's my bad. I was getting blurry after Table 4.
With the industry pivoting towards focussing on post-quantum algorithms, I’d be surprised if yet another elliptic curve gains much traction.
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.
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).
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.
The Eccfrog512ck2 curve can be used for both signatures and key agreement.
Stackexchange is not enthusiastic about the author's skill level.
https://crypto.stackexchange.com/questions/114678/new-custom...
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.
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.
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
[dead]