ElGamal..

Not endorsing or suggesting just noting for whoever that Tor has been updating a lot of its former crypto, here's one example... https://gitweb.torproject.org/torspec.git/tree/proposals/270-newhope-hybrid-... Indeed a lot of projects have been and are updating their crypto for various reasons... brokenness, modularity, performance, simplicity, maintenance, quantum... the list goes on. https://neopg.io/ https://boringssl.googlesource.com/boringssl/ ... innumerable examples elided... It's always good to look around and see what's the latest going on in other projects. Many are perfectly good for their use cases, and relatively future proof, thus having no need to update. Others are a public shambles needing wholesale rewrite, fork, abandoned.

...

Bad: I2P uses old cryptography, specially 2048 bit ElGamal using non standard primes. The use of ElGamal is so pervasive throughout the I2P protocol stack that it exists at every level of it. Removing it is a massive task that is taking a long LONG time.

To the extent the below applies to any project... Projects should not hesitate to utilize flag days where useful. Many projects focus way too much on making seamless transitions. Users are part of projects too, and have responsibilities therein. Let them know this, and they will understand. Cryptocurrencies have been able to make rapid advances, in part because their very first announcements and ongoing processes make very clear that there will be flag days, required software updates, and things users have to do. Setting those expectations, enabling users to take part and pride in playing that role, can allow you to swiftly adapt and update as needed. Much faster than any other project, or adversary, on the market. Instead of being mired in "no changes, no downtime", legacy codebases, lacking features, whatever holds you back, etc.