When talking about cryptography, its always important to think about what you are keeping secret and who are you keeping it secret from.

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.

Trust isn't an all-or-nothing thing.

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.

If you’re trusting a party for identity verification of a party you’re communicating with, isn’t that implying trust with the correspondence itself? After all, they could just “verify” themselves as the other party of your correspondence.

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.

No.

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.

I believe that you are supposed to use identity providers that aren't involved in the actual transmission of the message.

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.

> After all, they could just “verify” themselves as the other party of your correspondence.

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

but then you have to catch them. wouldn't it be better if they didn't have the ability to do that in the first place?

If that was possible, we wouldn't need Certificate Transparency (whose purpose is to at scale detect Certificate Authorities doing this and other shenanigans).

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.

Why/how would they get caught in the identity-based scheme mentioned in the article? What are you even verifying out of band in this context?

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.

IBE allows two users to communicate without the trusted party being online

I wonder if IBE could be useful for the cloud. If you have thousands of microservices, could IBE remove the need for key exchange for all of these microservices to communicate securely? One microservice could send a message to another microservice based on its identity (hostname?), no need to fetch it's public key first.