You could look into something called identity based encryption. For your purposes it might work.
If I got you right, IBE could help generate public keys from IDs. That's really cool, because the public key comes to live before the receiver(in blockchain terms) actually generates the private key to receive the ownership. But IBE has this inherent key escrow. The Private Key Generator needs to be trusted. So I've checked the variants that eliminate this trust:
- certificate-based encryption (needs to distribute a public key)
- secure key issuing cryptography (multiple third parties, requires trust they don't cooperate)
- certificateless cryptography (cool, but needs to distribute a user-generated public key)
So IBE and the second variants introduce a trust issue, while first and third variant defeat the purpose of what IBE solves in term of public key distribution.
I had an idea where I would still use WebFinger to distribute the pubkey in 3rd variant, but then instead of just using the ID like email or phone number I would attach a timestamp of the transaction. By this still dealing with the distribution problem, but solving the issue that the address should be fresh each time.
So here is CL-PKC(variant 3) with my use-case:
- KGC chooses master public key mpk and master secret msk.
- Bob generates a secret value xID(Bob) and a corresponding public key pkID(Bob)
- Alice takes ID(Bob), pkID(Bob) and mpk, combines it into a new public key, and uses it to publish at transaction on the blockchain.
- Bob asks KGC for partial private key dID(Bob), which KGC computes from ID(Bob) and msk, and delivers it securely to Bob.
- Bob combines dID(Bob) and xID(Bob) to produce the full private key skID(Bob) and now can spend the coins on the blockchain.
Unfortunately it turns out that pkID(Bob) which Bobs needs to publish derives from xID(Bob). So I can not modify ID to generate new addresses every time.
Or did I apply IBE for the wrong use-case all together?