The Fynlink Application Encryption Architecture

We use a similar encryption architecture which is battle tested & used widely in many end-to-end encrypted applications currently.

Your link data including short URL, target URL, tags, title & notes are end-to-end encrypted with Fynlink. Meaning, they are encrypted on your device before being sent to our servers. This ensures that only you can access your data. We can't read your data, even if we wanted to.

Encryption Fundamentals

• Master Key: When you sign up for Fynlink, your browser client will generate a masterKey for you. This never leaves your device unencrypted.
• Key encryption key: A keyEncryptionKey is derived from your password and this will never leave your device.

Application Flow

• Registration: During registration, your masterKey is encrypted with your keyEncryptionKey and the resultant encryptedMasterKey is sent to our servers.
• Login: During login, when you enter the password, the keyEncryptionKey is derived from it. After successful login, our servers give you back the encryptedMasterKey. The masterKey will be derived by decrypting the encryptedMasterKey with the keyEncryptionKey.

Only you can derive the keyEncryptionKey as only you know the password. Since only you can derive the keyEncryptionKey, only you have access to the masterKey.

Link Encryption Fundamentals

Key pairs are generated for User & Team. This generates a publicKey and privateKey pair. The publicKey can be used to encrypt, while you will need the privateKey for decryption.

• User Key pairs: A key pair is generated for you when you register. The userPublicKey is stored on our servers as plain text and the userPrivateKey never leaves your device unencrypted. The userPrivateKey is encrypted with the masterKey and stored in our servers.
• Team Key pairs: When you create a team, a key pair is generated for your team. The teamPrivateKey is encrypted with your userPublicKey and stored in our servers. The teamPublicKey is stored as plain text on our servers.
• Link key: A random linkKey is generated for each link you create. This key is used to encrypt the link data. It never leaves your device unencrypted, and is encrypted with the teamPublicKey and is sent to our servers.

Link Creation Flow

• When you create a link, the short URL, target URL, tags, title & notes are encrypted with a randomly generated linkKey.
• The linkKey is then encrypted with the teamPublicKey of the team.
• We will also create a hash (non-reversible) of the short URL & the target URL will be encrypted with a key derived from the actual short URL itself. These values are further encrypted with a searchable field-level database encryption system for further security.
• All the above-encrypted data is then pushed to our server for storage.

Viewing A Link

• When you view a link in the application, the encrypted link data along withencryptedLinkKey is fetched from our servers.
• The encryptedUserPrivateKey and encryptedTeamPrivateKey are also fetched from our servers.
• The userPrivateKey is obtained by decrypting encryptedUserPrivateKey with the masterKey.
• The teamPrivateKey is obtained by decrypting encryptedTeamPrivateKey with the userPrivateKey.
• The linkKey is obtained by decrypting encryptedLinkKey with the teamPrivateKey.
• Finally, the link data is decrypted with the linkKey and displayed to you.

Redirection Of Short URL

• When someone clicks on the short URL, our redirection service will search for the hash of the short URL in the database. (Remember, the hash field is already encrypted in the database, so a direct search is not possible. This is where the searchable field-level encryption system comes into play)
• If a match is found, the encrypted targetURL is fetched from the database along with its metadata.
• The metadata is mainly different ids like linkId, teamId,userId etc.
• An decryptionKey will be derived from the actual shortURL and will decrypt the targetURL.
• If metrics is enabled for the link, all the header information will be passed to the metrics service, through a queue.
• The metrics queue will aggregate all the data for a short period (upto 20 sec), which can have multiple link clicks data across a wide range of links and send to metrics service, process it, & store the absolute essential data like country code, browser, referral host, device type along with metadata. We do not store user IP address, nor the user agent string. All the click metrics from the aggregated queue will have exactly same timestamp, this is by purpose. The timestamp can be anywhere +/- 20 sec from the actual click time.
• The shortURL hash & encrypted targetURL will be cached in a key value store for a short duration (minimum 6 hours, or for the expiry time set, whichever is lesser) for faster access next time.
• The user will be redirected to the target URL.

Implementation Details

We mainly depends on the high level APIs exposed by the awesome libsodium library. We also use searchable field-level database encryption for several fields with the help of Ciphersweet. Any personally identifiable information or other sensitive information's stored in the database are encrypted using the AES-256-CBC algorithm. This is apart from the standard encryption available at rest (EAR) and during transit (EIT) for the data.

Key Generation

crypto_secretbox_keygen is used for generating all random keys within the Fynlink application.masterKey, recoveryKey, linkKey are all 256-bit keys generated with this API.

Salt & Nonce Generation

randombytes_buf is used to generate a new salt or nonce every time data needs to be encrypted.

Key Pair Generation

crypto_box_keypair is used for generating key pairs. The key pairs userPublicKey, userPrivateKey and teamPublicKey, teamPrivateKey are generated using this API.

Key Derivation

crypto_pwhash is used to derive the keyEncryptionKey from your password. Under the hood it uses Argon2id, which is considered as one of the best hashing algorithms available currently.

Symmetric Key Encryption

crypto_secretbox_easy is used for encrypting your masterKey and recoveryKey. Internally this uses XSalsa20 cipher with Poly1305 MAC for authentication.

Asymmetric Key Encryption

crypto_box_seal is used for all encryption's using a publicKey. The linkKey and teamPrivateKey are encrypted using this API with teamPublicKey and userPublicKey respectively. Internally this uses X25519 for key exchange, XSalsa20 cipher for encryption and Poly1305 MAC for authentication.

Hashing & Other Encryption Used

We use crypto_hash_sha256 for hashing. A copy of short URL is stored as hash in our servers. A copy of the target URL is encrypted using AES-256-CBC algorithm from a key derived from the actual short URL using HKDF as key derivation algorithm. We use Subtle Encrypt for implementation.

Both the short URL hash & encrypted target URL are further encrypted with Ciphersweet which enables searchable field-level database encryption.