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
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.
https://crypto.stackexchange.com/questions/114678/new-custom...
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.
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.
* 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
commandersaki•9mo ago
geocar•9mo ago
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).
commandersaki•9mo ago
geocar•9mo ago