Data encryption & caching with the atProtocol

End-to-End Encryption on the atProtocol

Combinations of both Asymmetric Key Encryption and Symmetric Key Encryption is a common practice for information security. Asymmetric Key Encryption is used to exchange keys (commonly both private and public keys) and can be used to encrypt communication. To effectively and properly encrypt the public and private keys a strong algorithm with a large bit key (described later) should be utilized. Once a key exchange is performed (typically after having done an Asymmetric Key Encryption method), another encryption algorithm that is faster and uses a smaller key is then implemented. This could be another Asymmetric Key Encryption algorithm or even a Symmetric Key Encryption algorithm. Asymmetric Key Encryption can be used with Symmetric Key Encryption to protect a generated public key. To protect the symmetric key, it is encrypted using an Asymmetric Key Encryption public key.

Data Caching in the atProtocol

From the previous example above for Data Encryption, we stated that @alice wished to share her phone number with her friend @bob. To do this, the atProtocol goes through two layers of encryption to ensure that @alice’s communication with her friend is completely secure and strictly between the two. But once @alice has sent her phone number, that information still has to be stored somewhere.

Time To Mechanisms (Attributes of Metadata)

Any data that is shared between atSigns can go through several mechanisms. Some of these mechanisms include TTR (Time To Refresh), TTL (Time To Live), and TTB (Time To Birth).

Time To Refresh

TTR, which is an attribute of the metadata of a shared key, accepts an integer value which represents seconds. The subsequent refresh happens based on the given value: for example, if the set TTR value is 86400, then the refresh happens once in a day (there are 86,400 seconds in a day). Another very important attribute of the metadata is CCD (Cascade Delete), which is a boolean variable (a variable that accepts true or false values). For those who are well versed in SQL and database management, you will already have some understanding of what CCD does and how it functions.

Time To Live

TTL (Time To Live) is quite self-explanatory: it defines how long data will live on a server. Anyone with an atSign has the ability to upload information on their server and define how long it stays on the server before it is automatically deleted. If @alice wishes to share her summer vacation getaway location as her current location, she has the option to share that summer vacation location for as long as she plans on being there!

Time To Birth

Another Time To mechanism that is utilized within the atProtocol is the Time To Birth mechanism. This mechanism allows individuals to upload information to their secondary server and have it become activated after a specified amount of time, in seconds. During the time that the data is not ‘active’, any recipients of this information will see the ‘null’ value in place until the activation has occurred.

Works Cited

Dharan, Murali. “atProtocol Data Encryption.” atProtocol Data Encryption, vol. 1, no. 1, 2020, p. 1. Atsign Google Drive.


Tyler Trott ( is a Student Ambassador and Student @ppathon Coordinator for Atsign.



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