One of the important elements of the scheme described above is the register of public communication keys of users. Since to send a message the sender needs to know the recipients’ communication public key - this register (or registry) is necessary for communication. At the same time, the fact that the user’s public key is available to everyone does not bear any risks. The public key is precisely called “public” because it can be transferred to an unlimited circle of people. It is impossible to restore a private key based on a public one.
As part of the Ylide Smart Contracts, we provide a different version of the ledger smart contract for each blockchain. However, they all perform the same functions:
store the “wallet address” ⇒ “communication public key” link (or pair).
store the “communication public key” ⇒ “wallet address” link (or pair).
The second link is not necessary but allows to verify the wallets’ old emails if for some reason they had to change the communication private key (for example, in case of losing a password).
Important to note that the communication public key is passed to the transaction in an explicit (decrypted) form. Therefore, an attacker can substitute any other information instead of a real public key.
However, the wallet address in the smart contract is read from the transaction itself so the attacker will not be able to substitute your address in any way (unless he has access to your wallet). This guarantees security in the link “wallet address” ⇒ “communication public key” - only the real owner of the wallet will be able to derive the public communication key for his address.
In the “communication public key” ⇒ “wallet address” link, an attacker can write his address to someone else’s public communication key. However, this will not lead to any result. The attacker won’t be able to:
read your messages - he has no communication private key;
write letters on your behalf - he has no wallet private key.
The only scenario in which this will cause inconvenience: if a user has lost his old Ylide password and created a new one (and, accordingly, a new private communication key). Then next to the old messages from this user, recipients will see a “This message is encrypted with a key, which does not match the current or previous sender keys. Be careful”.
In future versions, we plan to add a mechanism for checking the public key on upload to the “communication public key” ⇒ “wallet address” link (or pair), which will remove the drawback described above. However, even now it does not bear any risks.