Beyond Public Key Encryption
blog.cryptographyengineering.com
blog.cryptographyengineering.com
Afaict identity based cryptography requires a trusted third party. If you already have a trusted third party, might as well skip all this complexity and just communicate through them.
After all communicating through twitter DMs is pretty secure & convinent, if you take it as a given that twitter is trutworthy.
I trust the local bank teller to not steal my money, but I wouldn't trust them with access to my text messages. I trust my dentist with my dental health, but I wouldn't let them have access to my firesafe.
If I trust someone to verify someone else's identity, it doesn't mean I trust them to have access to my correspondence with that person.
It’s the same principle as user permission management—if someone has the ability to grant permissions then they are a superuser, because they can grant any additional permission to themselves.
Just because I trust you to recommend a therapist doesn't mean I'll trust you to listen to my therapy session and keep it private. Or that you wouldn't try to decode messages.
For example suppose I want to send you an encrypted message. Your email address is in your HN profile. I ask an identity provider for a public key for that email address, encrypt my message using that key, and send it to that email address.
Identity provider shenanigans might result in me encrypting that message with a public key whose private key might be known by the identity provider or other third parties, but unless they can intercept my mail in transit or gain access to it in your mailbox they can't make much use of that.
They can't do this at any real scale, because they will be caught. (Because they can't use the same key as the real key--since they don't have the private portion, if designed sanely--so anyone verifying it manually out of band will see that the trust has been violated. Also they will have to continuously modify future communications, which can be difficult, which is another way to get caught.)
Also "being able to catch them" is strictly better than "basically not able to catch them", which is the case for Twitter DMs (and most common DM systems), which was mentioned up-thread.
Like all that you wrote is true of webPKI that we use on the internet for TLS, but the article is talking about an alternative that is not PKI, and does not work the same way.