🚧 Work in Progress

⚠️ This article is still in development

Paralino uses end-to-end encryption backed by Libsodium to protect your data before it leaves your device.
Here, you can find out how all that magic works.

Summary

Authentication Flow
   Account creation
   User Keys
      Key Generation
      User Key Payload
   Login Flow
      Login Process Overview
      Decrypting User Keys
App Session Keys
Paralino.ID
   Pre-Keys
   Managing Paralino.IDs

Authentication Flow

Our authentication system is designed with a multi-layered security approach to enhance the protection of user credentials and data. Users can access Paralino through two primary methods:

• Email & Password Login: Standard signup and login using an email address and password. This method allows users to log in on multiple devices.
• Guest Login: Account details, including the password, are generated on the device, allowing users to use Paralino without the need for an email or password. However, this is restricted to a single device.

Account Creation

Upon selecting the preferred login method, users proceed with account creation. For guest accounts, credentials are generated directly on the device.

A Random 256-bit Salt is generated for each user. This unique salt enhances security by adding randomness to the password during key derivation, making it more resistant to attacks.

The user’s password and the generated salt are combined and processed using the Argon2id key derivation function (64 MB with 3 rounds).
This process yields the Master Auth Key, a cryptographic key securely derived from the user’s password, which acts as a “seed password” for subsequent operations.

The Master Auth Key is further hashed using the BLAKE2b algorithm to produce a 256-bit Login Password.

Along with the email address, this Login Password is used as the user’s account/authentication credentials. The Login Password is then processed server-side using Argon2id (64 MB with 4 rounds) for added security before being stored.

The server creates the user account, registering the user’s email and assigning a unique user ID.

User Keys

The next step is to generate cryptographic keys that will be used to encrypt and decrypt user data.

Using the user’s unique ID as a new salt, the device derives the Master Data Key from the Master Auth Key using Argon2id (128 MB with 5 rounds).

The Master Data Key is hashed using BLAKE2b to generate a 256-bit Key Encryption Key, which is then used to encrypt the Master Key.

Key Generation

The user’s device generates the following keys:

• Master Key : A Random 256-bit Master Key used to encrypt the user’s data and identity keys.
• Identity Keys : A pair of Private and Public Keys used for user authentication and secure key exchange with other users.

The Master Key is encrypted using the Key Encryption Key with the XChaCha20-Poly1305 encryption algorithm, ensuring confidentiality and integrity.

Similarly, the Identity Keys are encrypted using the Master Key, also with XChaCha20-Poly1305, to ensure secure storage.

User Key Payload

The User Key Payload is securely stored on the server and contains:

• Encrypted Master Key
• Encrypted Identity Keys
• Plain Text Public Key: The unencrypted public key for identification purposes.
• Login Algorithm Details: Argon2id parameters used during key derivation for login credentials.
• Data Algorithm Details: Argon2id parameters used during key derivation for cryptographic keys.
• Login Salt: The original salt used in deriving the Master Auth Key.

Here is the full user account creation flow:

By following this authentication flow, the system ensures that user credentials and data are protected at every step, utilizing industry-standard cryptographic practices to safeguard against unauthorized access.

Login Flow

Email & Password Login: Enables users to securely log in on multiple devices with their registered credentials.
Guest Login: Credentials are stored only on the device, thus guest users are not able to log in on multiple devices.

Login Process Overview

When users provide their login details (email and password), the system follows these steps to authenticate the user:

• Validating Login Details:
  The entered email is sent to the server, which checks if the account exists.
  If the account exists: The server retrieves the corresponding login algorithm details, including the salt.
  If the account does not exist: Dummy details are returned for specific input to ensure no information about account existence is provided.

• Recreating the Login Password:
  The user’s password and the retrieved salt are processed with the retrieved login algorithm details. This produces the Master Auth Key, which acts as the “seed password.” The Master Auth Key is hashed again using BLAKE2b to produce the Login Password.

• Verifying Credentials on the Server:
  The Login Password, along with the user email, represents the login credentials which are transmitted to the server.
  If the credentials match, the server authenticates the user and provides the necessary data for further operations.

Decrypting User Keys

After successful authentication, the encrypted user keys are retrieved and decrypted on the device.

• Retrieving the Encrypted Key Payload:
  The User Key Payload, stored on the server, is sent to the device.
  This includes: Encrypted Master Key, encrypted Identity Keys, data algorithm details, and other key parameters.

• Decrypting User Keys:
  The Master Auth Key, derived during the login process, along with the salt in the form of UserID and data algorithm details, is used to derive the Key Encryption Key.
  The Key Encryption Key decrypts the Master Key using XChaCha20-Poly1305.
  The decrypted Master Key is used to decrypt the Identity Keys with the same algorithm.
  These keys are stored locally in secure storage for subsequent use in communication and encryption.

Here is the full user login flow:

App Session Keys

On every user login or account creation, a new symmetric key (Session Key) is generated. This key is used to encrypt the Master Key and Identity Keys before saving them locally on the device.

The Session Key is stored securely on the user’s device along with the encrypted Master Key and Identity Keys:

• Android: Stored in EncryptedSharedPreferences.
• iOS: Stored in Keychain.

Using an extra session key to encrypt other keys not only provides an additional layer of encryption and security but also enables features like locking the app with a PIN or biometrics.
This also ensures that your actual keys are always stored in an encrypted form and are only decrypted when needed.

Paralino.ID

The Paralino.ID is an 8-character code that serves as the user’s unique identifier within the Paralino ecosystem. It is used for connecting with other users and facilitating secure communication while ensuring anonymity and privacy.

Paralino.ID is generated using cryptographically secure methods and is not known to the server.
It is not considered very secret since, in the end, it is meant to be shared with others, but we have still gone through the process of engineering it in a way that limits what information the server knows.

A Secure Random Generator creates a unique 8-character Paralino.ID for each user.

The Paralino.ID is input into key derivation functions to generate two different secure keys:

• ID Auth Key: Derived using Argon2id (32 MB with 2 rounds) and hashed once again with BLAKE2b, serving as the Paralino.ID identifier.
• ID Encryption Key: Derived using Argon2id (32 MB with 2 rounds) with salt in the form of User ID, used to encrypt payloads during communication.

This ensures that the only way to get info about the user (user name and image, plus user exchange keys) is to know both the User ID and the Paralino.ID.

Paralino.ID is encrypted with the user’s Master Key to ensure it is only readable to the user.

The user’s unique details, such as User ID, Public Identity Key, and User Name/Image, are included in the Paralino.ID code Payload.
This payload is encrypted using the ID Encryption Key and the XChaCha20-Poly1305 algorithm, ensuring data confidentiality.

Besides the server returning the user’s public key (which is stored in plain text), the encrypted Paralino.ID payload also contains your public key, added directly from your device.
This way, the end user verifies and can be sure that the code actually belongs to you.
Combined with the fact that the server does not know the user’s Paralino.ID, it cannot easily pretend to be another user nor can it give you false information.
Your device verifies all this information locally; you just need to make sure that the Paralino.ID you entered matches the Paralino.ID on your friend’s device.

This is not a replacement for manual contact verification (e.g., with safety numbers in Signal) since the Paralino.ID code is too short (8 characters), but it is a quick and easy assurance you are in contact with the correct person.

We plan to add actual contact verification at a later point. This will allow you to manually check and compare public key signatures, ensuring better confidentiality.

The encrypted Paralino.ID code Payload is securely transmitted to and stored on the server, along with the ID Auth Key, Pre-Keys, and encrypted Paralino.ID.

Pre-Keys

Each Paralino.ID has multiple Pre-Keys assigned to it. The number varies and is replenished from your device if they are running low. Pre-Keys in this case work similarly to Pre-Keys in Signal.

• A pair of Pre-Key Pairs (random private and public keys) is generated for data exchange.
• These keys are then encrypted with the user’s Master Key, allowing access to the private key only to the Paralino.ID owner.
• The public Pre-Key is signed using the user’s private signature key to authenticate the key exchange process.
• Pre-Key Key ID is derived with a BLAKE2b hash and serves as an internal Pre-Key identifier.
• The Pre-Key payload contains the Paralino.ID, Key ID, and signed Pre-Key public key. That is then encrypted with the ID Encryption Key.

Whenever someone tries to add you to a group or reads your Paralino.ID, one Pre-Key is fetched and invalidated.
A Pre-Key can only be read and used once, and it contains keys necessary for adding you to a group and for a first-time data exchange.

Managing Paralino.IDs

You can disable your Paralino.ID at any time directly in the app. Doing so will invalidate all Pre-Keys and remove the Paralino.ID code Payload.

You will then not be able to join any new group, and no one will be able to read your info with Paralino.ID.
You can at any point enable your Paralino.ID if you wish to join another group.
Paralino.ID cannot be deleted. If you delete your account, the ID Auth Key (hash of your Paralino.ID) is stored on the server, ensuring no other user can ever have the same Paralino.ID.

You can have multiple Paralino.IDs, allowing you to have multiple different codes to share with different people. Consider them as different identities.

At the moment, only one Paralino.ID is active at a time, but we will soon enable support for multiple simultaneously active Paralino.IDs.

This will also allow you to have different names and images in different groups and attach different data to different Paralino.IDs.

Multiple Paralino.IDs are a premium feature, and to create more Paralino.IDs you need to have a premium plan.
You can then enable/disable preferred Paralino.IDs as you see fit.