Encrypted public contact discovery
One of the main challenges of building people-friendly federated messaging is contact discovery. In early years of Internet people manually build there contact lists and it was fun: asking friends, sharing contacts and starting messaging somewhere. In 2015+ there are too many contacts and it is not that fun to build another contact-list and bring people there. Now we need to build contact lists automatically by importing there’s phone numbers and emails to service provider, finding matches and building contact lists. And there goes one big problem. Also we need to notify people when someone started to use network (or at least add contact to contact list).
People much easier understand numbers than text. Numbers are language independent, they are easy to pronounce, easy to write, read and share. There are cases entrepreneurs use there phone numbers as email address for easier explaining them to customers. For example, in english letter “S” and Russian letter “С” sounds the same and you always need to say something like “S as $” or “С as See”.
Another part of a problem is that different countries, different entities want to have there own messaging solution and don’t want to share messages to some service providers. Jabber is still alive in enterprise world because of this. Many teams still use Jabber-compatable sowftware for this.
In this article I want to propose peer discovery that is heavily encrypted and protected, but still remain in public that everyone can do contact discovery. I describe phone number-based contact discovery, but it can work with emails or other indentifiers as well.
Structure of public encrypted catalog
Public catalog is a file that is distributed in any way: Torrent’s DHT, Bitcon’s Blockchain or just hosted on some server. We don’t need to trust file storage itself as it’s content is encrypted and signed, the only thing that you can do with this is hide some records from public catalog, but this is manageable thing as network will become big.
Catalog consists of two sections:
* Authentication Providers with certificates
* Registered Contacts
Because of phonebook-based catalog we need somehow authenticate people by there’s phone numbers before adding them to public catalog. That’s why there is Authentication Providers section. When someone authenticate in the network, we validate his phone number, creating new record for catalog and sign it with certificate of Authentication Provider. When some service decide to do peer discovery it first of all chose which authentication providers it can trust and work with records that are signed with certificates from this provider only.
Second part big array of contacts. Each contact consist of:
* PDKDF2-like-hashed phone number in full international format.
* AES-Encrypted Contact Name — name that people provide to catalog.
* AES-Encrypted Server endpoint
Phone number is hashed with PDKDF2 function with parameters that takes a lot of time to compute a single hash. This will protect from any kind of bruteforcing of catalog. When match was found service can use phone number to generate AES-key with PDKDF2 with different parameters for decrypting contact name and server endpoint to establish connection.
If we protect passwords with hashes then why we can’t protect identity information the same way?
Last question is what enctypted parameters it is needed to build this network and i hope people from community will be interested in solving this problem. If you think that you can help, you can write me to steve@actor.im
