Communication keys

In classical key generation schemes, the private key is generated as a random set of bytes, and the public key is calculated based on the private key. This method is great for generating wallet keys but it is inconvenient for communication keys since:

• if the communication keys are completely independent and separate from the wallet, then the user needs to monitor two pairs of keys at once, take care of their security, and also manually transfer them to new devices from which she wants to communicate through the protocol Ylide;

• the wallet key cannot always be used for end-to-end encryption of messages;

• the wallet key is strictly private information that the user should never give access to external applications;

• most of the current non-custodial digital wallet doesn’t support the operation of encryption;

• some users use hardware wallets (ledgers), in this case, it is physically impossible to get access to the private key of the wallet.

However, absolutely all wallet key formats, even in the most diverse and non-standard blockchains and cryptographic schemes, can sign data. This is their main property - the key to a blockchain wallet must be able to sign transactions - therefore, signing data is included in the arsenal of the capabilities of any wallet.

Data signing can only be done by the owner of the private key. At the same time, it is impossible to calculate the private key from the signature.

Hence the scheme of the derivation of the private communication key from the private key of the user’s wallet was born.

The scheme is simple: we take a fixed string, request the signature of this string from the user’s wallet, and get a unique and unknown (secret) signature. From this signature, we can calculate the hash (which will also be known to anyone) and use it as a communication private key.

However, it creates security risks - since the string is fixed and known in advance, an attacker could ask the user to sign this string on any other website with their wallet. The user, not noticing the catch, could confirm such an operation. In this case, the attacker would take possession of this secret signature and would gain access to the communication private key.

Therefore, to make such an attack impossible, we decided to make the string dynamic rather than fixed. To do this, we introduce the concept of “Ylide password” - this is a password (random string) that the user himself comes up with and remembers. And now, instead of a fixed string, we use a dynamic one: “fixed string + user password” from which the signature and the communication private key are created.

Now to steal your communication key, an attacker will have to first ask you to enter your Ylide password, and only then ask you for a signature. This drastically reduces the risk of an attack - when on an unfamiliar website you are suddenly asked to give your Ylide password - you will pay attention to this, think about it, and prevent the fraud.