Identity System
Over my career in software I've repeatedly had to deal with issues of identity. Another way to refer to identity is usernames. The most pervasive identity system in use is email, although it is quickly being supplanted by cell phone number.Almost every user of the internet has an email address. This makes it a convient base identity system. When you sign up for accounts, you nearly always have to provide an email address, and that email address is used as a way to recover your account in case you forget your password or lose access to your 2-factor. This is, though, a huge security risk. If email access trumps all other forms of verifying your identity, then once someone gains access to your email they can gain access to everything.
Because of that, the new primary identity is becoming cell phone number. The idea is that every adult in the modern world has a cell phone, and that they keep that cell phone either on them at all times or at least nearby. This is a problematic assumption, as not every does have a cell phone, and even those who do may not want to constantly have the thing nearby. Additionally, you can only retain your cell phone number if you are constantly paying for it. If you ever stop for a period you will lose that number. Worse that number will then pass on to a different random individual, who would then potentially be granted access to any system you used your cell phone number as identity for.
Email is not without flaws of loss of access either. Your email provider could go out of business and vanish. If you use a custom domain for your email, the registrar of the domain could fail to renew the domain registration and lose access to that. If someone else registers the domain then, they potentially gain access to all systems that used an email at that domain for identity.
Going back to cell number as an identity solution it is problematic for systems to use it to verify identity because there is a cost associated with either sending a text message to a cell number or making an automated call to one. This cost is extremely high considering the extremely low difficulty of sending the very small amount of data as a text message.
Email and cell phone number are bad long term identities due to all of these things. Weirdly we've had a better solution to identity for decades. That solution is a cryptographic key.
Your core identity should always be a cryptographic key that you have hardcopy of in multiple locations. By doing so you can then recover any and all downstream identities easily and eternally. I say hardcopy because electronic devices can and will fail over time, and should not be trusted as a root identity. Making such hardcopy does mean that anyone who has physical access to the hardcopy then has access to your identity, but that is no different from having physical access to an electronic device containing the identity.
There is a slight difference I'll admit. An electronic device could have your identity locked behind as many other verifications as you wish, such as:
- Password ( bad because they can be forgotten )
- PII ( Personally Identifiable Information such as birthday, name, etc )
- Random personal history ( pet names, family names, etc )
- Biometric information ( note fingerprints, in my experience, cease to work over time )
Harcopy can be locked to any of these things as well though, in that whatever a digitial system stores to use as verification of these things could also be printed out and then read back in to a digital system to then unlock the actual key.
So why then, if cryptographic keys are so great, are they rarely accepted as a sufficient form of initial identity for any system?
It is because most systems want to use email or cell phone as identity not because it is good for you, the user, but because it is good for them, the system, in that by requiring such they can reduce spam registrations. The high cost/difficulty of obtaining an email or cell phone number is why.
This is not really true for email these days, as making any number of bogus emails is extremely low cost. It is though true of cell phone numbers, and is why many systems are beginning to require a cell phone number to make an account.
Even if cell phone number is required for that purpose, I still think it is hugely inappropriate to lock core identity verification to a cell phone number. All systems globally should transition to using a universal set of tiered keys as core identity. The reason is to reduce identity costs, and also to reduce loss-of-access situations.
I've personally believed this should happen for decades, and it remains dumbfounding to me that it hasn't.
Take this a step further and consider cell phone numbers themselves and their horrible inconvenience. Why is it that you lose your "cell phone number" if you ever cease paying for it for a time? This is not good, and can be easily solved.
How could that be solved you may ask? This is how:
- Have cell phone companies use a globally decided cooperative cryptographic system such as I suggest.
- Have cell phone "numbers" be issued and locked to that core identity.
- Never reuse any cell phone "number" for anyone.
- If an identifying number local to a region is required, put it behind the global numberic "cell phone number", so that it can be looked up based on the global number.
I'm not suggesting a singular root key be shared out to all systems. I've said a tiered system above for an important reason. That reason is that if you use the root crucial key giving it out to everyone, it becomes a global identifier by which you can be known and access to multiple systems correlated together to you as the owner. That is generally thought of as bad and invasive. The risk of having the private core identity key stolen is easily solved by not using the core identity directly and instead using sub identities, as many as one desires to do.
The question then becomes, how does one ensure that you don't lose access to any sub-identity? The keys for those should be saved in an encrypted form that can only be descrypted by the core identity. Those encrypted backups can then be replicated in multiple places in the world safely.
Note that this is two types of encryption. Identity can be solved with digital signatures, but encrypting data is "encryption." Some types of encryption allow the same keypair to be used for both signatures and encryption, but generally you need to use two different keypair sets to do this.
In regard to digital signatures, my current suggestion is ed25519. It is not quantum safe, but it has a short easy-to-share public key, short signature length, and there are reliable implementations of it available in most programming languages. For encryption, the equivalent is x25519 using curve25519. In the case described that would not be needed and it may make more sense to use symmetric encryption for cheap / easy storage of private keypairs. It may be reasonable also to just store backups of all identities with the private key of the core identity.
The difference with encrypting and private keys to be recoverable by the core identity is that the hard copy backups could be left alone if public key encryption is used. This is why it does make sense to save copies public key encrypted to the core identity.
It is likely best to not attempt to address having non-correlatable identities when attempting to solve the identity problem. Identity works best when you have a way to associate a memorable and globally referencable identifier instead of just having a public key and nothing else.
You'll note that there is already a fully non-correlatable auth system in development and available for many systems, and that is webauthn / passkeys. What I'm describing could be used for authorization, but is broader than what passkeys are addressing. Passkeys don't need public key encryption. They can be done with symmetric encryption. The downfall of using symmetric encryption is that the system being authorized to could leak the symmetric key or anyone with access to that system could impersonate the user because they can obtain the symmetric key. Some passkey systems support using ed25519.
Because ed25519 and x25519 are not quantum safe, this is an interim suggestion for efficiency. Currently the optimal quantum safe signature algorithm seems to be falcon512. Both the keys and signature size are much larger than ed25519. The additional data needed for falcon512 would be significant for signing of small messages such as comments. The additional size would also make it more unreasonably difficult to enter signatures from an air gapped device. If one wants to air-gap the device with the key, and additionally not use any wireless protocol, then the only option left would be to use camera based data transfer, such as bidirectional data transfer using QR codes.
It is easy to scan a QR code from a disconnected old phone, but it is less trivial to do so from a PC, as the PC needs to be equipped with a camera. This isn't a blocking issue though, as both cellphones and laptops generally come equipped with a camera. It is easy as well to purchase a USB camera for a desktop computer.
Since ed25519 is potentially insecure, it may make sense to use a hybrid approach at this time using falcon512 for authentication, and ed25519 for signing of messages that are not crucially important ( such as social media comments ).