"Curve25519 was designed to be as fast as possible, with no security compromise. This is both a strength and a potential weakness:
a strength because it gives a valid argument that no trapdoor was introduced in the design,
a potential weakness because Curve25519 uses a very specific prime field. As of now, no attack exploiting this specificity is known.
For applications where speed is paramount, Curve25519 is probably the best option. But for most applications, where losing a little on the efficiency side is "not a big deal", Million Dollar Curve is probably the safest choice."
Sorry, no. Many more eyeballs have been on Curve25519 and DJB reputation, both of which gives me _more_ confidence in that than any new alternative.
Secondly, the implementation is as important as the design. Again, Curve25519 have vetted implementations, something which takes time.
Finally, the notion that speed is a liability is ludicrous. The lack of speed is a major liability.
I always was curious about about one thing with DJB. Even DJB must to admire that focusing almost everything in modern crypto world around DJB is not _secure_. Curve25519 became default in OpenSSH, used in Signal in Axolotl Ratchet (and our project - actor.im too) and so on. It is going to be everywhere. And all lines came to one specific person.
So? Curve25519 provides secure parameters for ECC, why not use it everywhere? How's that not secure? Is RSA secure? Is it because there were 3 people involved?
Good Point.RSA security depends mostly on how you build your private keys and ECC security depends on what parameters and what curve was chosen.
Russians cryptoexperts doesn't fully trust DJB they found that at the last iteration of picking parameters by DJB for Curve25519 was a bit questionable. Changes was done for "better performance" but no one found what exactly was speeded up. I don't know details, but when curve parameters was tried to be being compromised by NSA was almost always was about adding such "performance optimizations".
> Russians cryptoexperts doesn't fully trust DJB they found that at the last iteration of picking parameters by DJB for Curve25519 was a bit questionable.
Tell them to publish their findings and propose a better solution.
> Changes was done for "better performance" but no one found what exactly was speeded up.
What "changes" exactly? The word "changes" implies there was an early draft with vastly different parameters.
> I don't know details, but when curve parameters was tried to be being compromised by NSA was almost always was about adding such "performance optimizations".
If you don't know the details, try doing some research. Knowledge is healthy.
Sorry, you sound like those crypto nuts from various cryptography mailing lists. Curve25519 has been discussed to death during CFRG selection process (see https://news.ycombinator.com/item?id=11161315). If you (or these "Russian cryptoexperts") have legitimate concerns, please publish them and save the world!
What's the other curve work they've done that makes you say that?
I agree with the implication that an appeal to Bernstein isn't dispositive. But Curve25519 isn't just credible because of Bernstein; it's also been scrutinized intensively by lots of other research groups.
> We, at CryptoExperts, actually use Curve25519 and recommend it to our partners. Yet, we think that people should not rely on the same few safe curves that are currently out. Our methodology allows to easily produce safe alternatives.
Also it's called "Crypto Experts," which in this particular field somehow pegs my contrarian indicator button.
If they'd claimed to have designed a modern alternative to SSL using modern crypto primitives that's one thing. That's hard and requires solid crypto and coding knowledge and I wouldn't trust it without a lot of peer review, but it's something a competent crypto-understanding developer could pull off. Ordinary mortals can do things like combine a cipher with an authentication algorithm correctly if they take the time to study the state of the art and avoid previously understood pitfalls.
That's using crypto as a developer. But this is making crypto.
Creating a new cryptographic primitive is serious deep ninja-god black magic voodoo stuff that is beyond mere mortals... and this is coming from someone who is very anti-elitist when it comes to most things like this. There's not a huge pool of people I'd trust to attempt it, and even if it came from someone like DJB I still wouldn't use it until it's been in publication for at least a few years and attacked by many Ph.D's and others. Salsa and ChaCha are some of the newest ciphers in common use and those are now... what... a decade old? And they've been beat up pretty badly by researchers too, so they've passed enough of a gauntlet to be trusted with something.
So even if they did this new curve, I wouldn't use it for at least 5-10 years.
Edit:
The other thing I really don't get is why a new venture like this would start off by trying to push an entire new curve. Unless there is some good reason not to trust C25519, there are many other more pressing concerns in the crypto world that could be tackled. We could really use good end-user crypto software that is solidly engineered and offers good UX. That would be of immensely more value than yet another ECC curve with no clear benefit over existing curves. (Other than maybe NIST but that's another matter.)
I think the attitude that rolling your own crypto "is serious deep ninja-god black magic voodoo stuff that is beyond mere mortals" has a lot to do with why we've been blythly taking NSA's deliberately broken crap.
While I know it's hard, very hard, we shouldn't be discouraging people from making up new stuff, let a thousand flowers bloom around the NSA's walled garden .... what we should be doing is getting rigorous about testing and verification of new crypto be it from the NSA or the good guys
I don't think anyone wants to discourage people from learning about, playing with, and trying to invent new crypto.
The usual problem here is that people new to crypto frequently don't treat their whizzy new supercool algorithm as a toy that has almost certainly been done, cracked, improved, cracked and eventually abandoned. For whatever reason, it is entirely too easy for people new to crypto to convince themselves they've made a really cool discovery. There's even a cliche for this: "Anyone can create an crypto algorithm that they themselves cannot crack."
Absolutely, learn, play, and try to make something great. But keep perspective. You wouldn't invite your loved ones to be the first to test your first attempt at a home-brew parachute; similarly, don't use your home-brew crypto to protect important things.
We should put this part of the thread to bed, because CryptoExperts is the real deal, and it's kind of silly to debate "homebrew crypto" on a thread about their research.
Cryptoexperts must be one of the most impressive research and consulting private company that I know of (in Cryptography). Antoine Joux and Pascal Paillier are there...
If I have a very large setup that does a lot of crypto, is there not a chance that this can save me a shit ton in cpu cycles?
One of the main reasons that admins didn't turn on crypto by default until the snowden leaks was because of the CPU overhead on the servers. (I don't know in google's case but that's when they turned it on)
It's not hard to imagine that if I was doing a lot of crypto (or a lot of connections) that strong efficient crypto would be on my list of things to keep track of.
Sorry, no. Many more eyeballs have been on Curve25519 and DJB reputation, both of which gives me _more_ confidence in that than any new alternative.
Secondly, the implementation is as important as the design. Again, Curve25519 have vetted implementations, something which takes time.
Finally, the notion that speed is a liability is ludicrous. The lack of speed is a major liability.
Move along, nothing to see here.