Data encryption & caching with the @protocol

By Tyler Trott, Muralidharan Padmanaban, Sitaram Kalluri

Context: The @protocol supports end-to-end encryption for all the data handled through it. This is difficult to do, especially for information that is shared with a large number of people and very frequently, so we had to come up with a clever mechanism to make the technology work. In this document, we will discuss the details behind how we went about accomplishing data encryption on the @protocol.

End-to-End Encryption on the @protocol

Let’s describe a simple use case: @alice wishes to share her phone number with her friend @bob. To do this, @alice, who is on her own device, prompts her own secondary server to direct phone@alice at her friend @bob’s secondary server. From here, a shared key is generated for @bob (@bob:shared_key@alice).

This shared key uses the same encryption process as the Symmetric Key Encryption, which is called AES (Advanced Encryption Standard) and involves three block ciphers: AES-128, AES-192 and AES-256. The numbers that follow the AES acronym define the length of the bit key which is used to encrypt/decrypt a block of information. As more bits are used, the more difficult it becomes to break the cipher created. The following diagram below foundationally explains how AES works:

(Tutorials Point)

Imagine that the beginning “Block of plaintext” displayed is @bob’s generated shared key. After the AES process, the original, “legible” information of the key is then outputted as a ciphered version of itself.

After this encryption process is completed, from @alice’s device, the public lookup function (plookup:publickey@bob) occurs to locate @bob’s public key. This public key is retrieved from @bob’s server, and is then used to encrypt the already encrypted shared key that just went through the AES algorithm. The RSA (Rivest–Shamir–Adleman) encryption algorithm is used to encrypt the shared key with @bob’s public key. Because the RSA algorithm is an Asymmetric Key Encryption method, a public and private key are generated.

Once this has been completed, @alice’s device stores the encrypted shared key and @alice’s server updates the newly encrypted shared key of @bob’s server. From here, @alice is finally able to encrypt and store @bob’s phone number on her device (@bob:phone@alice)! If you’re a visual learner, you may find this diagram helpful:

(Vanguri 1)

The @ Company also utilizes the AES algorithm during the authentication process of an @sign (a necessary function for signing in to an @protocol application). This process is fairly straightforward in comparison to sharing keys from one @sign to another. When a person creates their @sign, an accompanying AES Key and a QR Code are generated as well. The key pair generated for PKAM (Public Key Authentication Method) are encrypted with the AES Key and saved on the device. (Offline storage is the most secure backup mechanism. If you want to retrieve the backup in the case that your device is lost/reset, The @ Company recommends storing this encrypted key pair on a secure cloud server.)

Data Caching in the @protocol

Time To Mechanisms (Attributes of Metadata)

Time To Refresh

If the CCD value is set as true when the sender deletes their original key, the cached key gets deleted on both the sender’s server and the recipient’s server. Correspondingly, if the CCD value is false when the sender deletes their original key, the cached key gets deleted on only the sender’s server and remains cached on the recipient’s server. But why is this useful? CCD is used to avoid unnecessary network calls. As an example: if @alice is in need of @bob’s phone number, she does not need to make a request from her server to @bob’s server to find it, but rather needs only to search locally on her device to find the phone number.

Let’s consider a similar example: @alice shares her phone number with her friends @bob and @john. A few months later, however, @alice purchases a new phone plan, resulting in a new phone number. If @alice has her @sign’s TTR variable set to true, once she updates her old phone number to match her new one, this updated value will also be reflected on @bob and @john’s devices. @alice also has the ability to set a specific time, in seconds, for when the new phone number will be cascaded on shared servers (this is TTB, which is described later). This can be 10 minutes, a day, or whatever specific amount of time she defines.

This function can be quite handy, especially if someone is constantly updating values on their server. This prevents a high density of calls and requests whenever someone wishes to see what new values exist on a shared server.

Time To Live

To really take advantage of a mechanism like this, developers can combine it with other Time To commands to make life for themselves and those they share their information with easier. Say for instance Alice lives in sunny San Francisco, and owns a vacation home in Spain. With mechanisms such as Time To Refresh and Time To Live, Alice has the ability of travelling to her vacation home for several weeks, uploading her current location as Spain, and setting that information to live on her server for the several weeks that she will be staying at that location.

Time To Birth

For example, if @alice wishes to upload a web URL of her personal website after she has completed it, she can simply specify that the URL value can be uploaded to her secondary in exactly 1 days’ time. Until the value is updated a day later, @bob can only see that her website URL is ‘null’.

Works Cited

Tutorials Point. “Block Cipher.” Block Cipher — TutorialsPoint, NDA, https://www.tutorialspoint.com/cryptography/block_cipher.htm. Accessed 6 January 2021.

Authors

Murali Dharan (murali@atsign.com) is a Backend Developer for The @ Company

Sitaram Kalluri (sitaram@atsign.com) is a Software Developer for The @ Company

The @ Company, creator of an Open-standard, P2P internet protocol that enables developers and enterprises to handle personal data based on trust and permissions. Learn more about us from our GitHub repo.

Now for some Internet Optimism

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store