Storage of communication keys

As noted above, to gain access to the communication key, we need two components:

• Ylide password created by the user;

• “fixed string + ylide password” signed by his wallet (in the data signing request).

Surely, asking for each operation inside the application to enter two passwords (Ylide and signing request) creates a weak User Experience.

Therefore, in the standard scheme, immediately after generating a communication key, Ylide SDK encrypts it using the same password, and stores it in the user’s local storage.

Good to know: For storing keys Ylide uses advanced xsalsa20-poly1305 encryption algorithm. For details read Cryptographic primitives

Then to confirm any message, it is enough for the user to specify only one password. It’s more comfortable but still not the best.

Therefore, the Ylide SDK provides several scenarios with different levels of security, so that users can choose the most suitable option.

1. Storing communication key in memory in clear text (for one session), and in local storage - in encrypted form

When prompted for a Ylide password, the user is provided with an option to “remember for this session”. As a result, the user’s password will be stored in the RAM until the end of the session. The communication key will be encrypted and stored in the local storage.

This will allow the user to read (decrypt) emails without entering any passwords. To send a letter, the user will only need to confirm transaction to broadcast the message to the blockchain.

To steal and decrypt the communication key, an attacker would need to hijack the user’s device or browser and gain access to RAM, which is very difficult and has a low probability of attack.

2. Storing communication key in the local storage in clear text (for several days)

The user can choose “remember for 5 days” option. The user’s password will be stored in the local storage, and even if the user closes the application or browser, he will not have to specify the password the next time he logs in. After a few days, the Ylide SDK will remove this password from storage and ask you to enter it again.

As in the previous version, this will allow you to read letters without passwords, and send them only with a wallet confirmation.

Similarly, to steal and decrypt the communication key, an attacker would need to access the memory of the user’s device, and this is extremely high complexity and low probability of attack.

3. Storing communication key in the local storage in encrypted form

The communication key will be stored in local storage, but encrypted with the Ylide password.

In this case, the user will have to additionally enter the Ylide password to read and send every email.

To steal and decrypt the communication key, an attacker will need to gain access to the device’s memory to get the encrypted communication key and then to the RAM to intercept the Ylide password. This is an extremely high difficulty and a very low chance of being attacked.

4. Paranoid mode: don’t store the communication key at all

Despite ultimate safety this approach makes your application really hard to use.

For each read and send, the user will have to enter both the Ylide password and his wallet’s password. The key will appear in the RAM only for a moment necessary to proceed with the message. After it is immediately erased from the RAM.

In this case, to steal and decrypt the communication key, an attacker will need to gain access to the device’s RAM and intercept both the encrypted communication key and Ylide password in the key derivation process at the right time. This is a phenomenally high difficulty and an extremely low attack probability.