Updating Crypto and Software, Users Role, Flag Days (re: Cryptocurrency, ex: ElGamal)

grarpamp grarpamp at gmail.com
Tue Apr 2 16:34:06 PDT 2019

> ElGamal..

Not endorsing or suggesting just noting for whoever
that Tor has been updating a lot of its former crypto,
here's one example...


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.

... 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.

More information about the cypherpunks mailing list