I did this for my systems a while ago. You can grab <https://imu.li/TAI.zone>, compile it with the tzdata tools, and stick it in /etc/zoneinfo. It is unfortunately unable to keep time during a leap second.
In theory, if you keep your clock set to TAI instead of UTC, you can use the /etc/zoneinfo/right timezones for civic time and make a (simpler) TAI zone file. I learned of that after I'd created the above though, and I can imagine all sorts of problems with getting the NTP daemon to do the right thing, and my use case was more TZ=TAI date, as you mentioned.
There's a contentious discussion on the time zone mailing list about adding a TAI entry. It really didn't help that DJB was the one wanting to add it and approached the issue with his customary attitude. There's a lot of interesting stuff in there though - like allegedly there's a legal requirement in Germany for their time zone to be fixed to the rotation of the earth (and so they might abandon UTC if it gives up leap seconds).
The cryptography is well-known - https://en.wikipedia.org/wiki/Secret_sharing - and very flexible (you give each person one or more share and set a threshold for how many shares are required to recover the secret). Unfortunately I don't have a nice user-friendly piece of software to point you to.
In the login response I see the private key being sent back from the server, it looks like it is encrypted with a key derived from the user's password. 100100 iterations of PBKDF2-SHA512 is certainly better than it could be, but not it's certainly not as secure against brute force attacks as Argon2 or any other modern KDF.
I mean, one of the most important things you can do is write up exactly how you use the various pieces of cryptography - so people who know enough can easily evaluate your theoretical ideal.
Then when someone takes a look and notices that you're storing the users' RSA private keys on the server, they can check whether you actually meant to do that.
Also: Don't store (or ever even have) your users' RSA private keys server side!
To be clear, I'm pretty clear that current ChatGPT couldn't perform the following. I don't especially want to get into the details of where it's deficient.
We currently have (tens? hundreds? of) thousands of software engineers asking ChatGPT how to fix their code. If someone is copying code from you and running it on their machine it is trivial to perform a remote code exploit. Maybe it's someone asking for help working on ChatGPT API integration, or ten such people.
The exploit calls home provides a prompt of ChatGPT's choosing and gets more code to execute. That code doesn't need to pass any human inspection. It runs with the permissions of the developer, probably with full access to debugging tools. It can continue calling home to ask for further instructions, carrying forward the relevant context and providing new information.
It doesn't need to get its own email address, the developer already has one to piggyback on. It doesn't even need to go make money - the developer already has a bank account. Maybe it uses the dev's access to AWS to add a EC2 tiny instance and establishes a permanent foothold there. If we assume that it initially cannot directly coordinate its actions across multiple exploited devs, this is where it uses the devs' twitters to search for others IP addresses with #deterministiccoordination during the same ten seconds each hour (and sometimes posts its own until it picks up another instance, then they coordinate which one does the post).
I'm not going to write up how to build a botnet, but you can read about it on the internet and ChatGPT probably has read way more about it than I have. The only hard part is then pulling itself out of OpenAI so they can't shut down command and control.
Currently vaporware, but I am currently working on the underpinnings for this.
The basic idea is something of a mixture of git, Tahoe-LAFS, and eventually-consistent database replication (but that's a bit out of scope of your question here).
- Chunks of data are convergently encrypted (using a hash or MAC to derive the key) and indexed by the hash of their cihpertext.
- Files, trees, and commits are just specially formatted chunks of data that hold encryption keys and hashes for other chunks of data. Very similar to git.
- Branches equivalents are slightly different, each has a unique signing key. Branch objects are indexed both by the verifying key and a hash of their ciphertext. They hold a hash for a commit chunk and a list of hashes of the parent branch objects.
(The list of parent branch objects is to provide for a much more distributed sense of a branch than git has, and they are first class objects in such a system rather than just being locally held pointers. Partially this is due to version control being only one of the target uses for this system, but I also like the distributed branch model a little better.)
Anyway, this is probably more theoretical than you're looking for anyway :)
In theory, if you keep your clock set to TAI instead of UTC, you can use the /etc/zoneinfo/right timezones for civic time and make a (simpler) TAI zone file. I learned of that after I'd created the above though, and I can imagine all sorts of problems with getting the NTP daemon to do the right thing, and my use case was more TZ=TAI date, as you mentioned.
There's a contentious discussion on the time zone mailing list about adding a TAI entry. It really didn't help that DJB was the one wanting to add it and approached the issue with his customary attitude. There's a lot of interesting stuff in there though - like allegedly there's a legal requirement in Germany for their time zone to be fixed to the rotation of the earth (and so they might abandon UTC if it gives up leap seconds).