Encryption

Encryption is the process of converting readable data into an unreadable, scrambled format so that only someone with the correct key can convert it back to its original form. It's a foundational tool for protecting digital information, such as messages, files, passwords, or entire databases, from being accessed by unauthorised parties.

How It Works

Data (plaintext) is run through an encryption algorithm along with a key, producing scrambled data (ciphertext). Anyone intercepting the ciphertext without the key sees something meaningless. Only those who obtain the correct decryption key can reverse the process.

Types of Encryption

1. Symmetric Encryption

The same key is used to both encrypt and decrypt data. It's fast and efficient, which makes it ideal for encrypting large amounts of data.

Common algorithm: AES-256 (Advanced Encryption Standard)

Use case: Encrypting data at rest — e.g., a database of user records stored on a server.

Trade-off: The key must be shared or stored securely between all parties, which creates risk if it's exposed.

2. Asymmetric Encryption

Uses a pair of mathematically linked keys: a public key (used to encrypt) and a private key (used to decrypt). Anyone can encrypt with the public key, but only the private key holder can decrypt.

Common algorithm: RSA, Elliptic Curve Cryptography (ECC)

Use case: Securely exchanging a symmetric key at the start of a connection (this is how TLS/SSL establishes a secure session), or digital signatures.

Trade-off: Slower than symmetric encryption, so it's typically used to set up a connection rather than encrypt bulk data.

3. Encryption in Transit

Protects data as it moves across a network, for example, between a user's device and a server. Uses protocols like TLS/SSL (a combination of asymmetric encryption to start the session, then symmetric encryption for the actual data transfer).

Use case: Every time you see "https://" in a URL, encryption in transit is active, protecting login credentials, form submissions, and browsing activity from eavesdroppers on the network.

Limitation: Once data reaches the server, it's decrypted, and the server itself can read it.

4. Encryption at Rest

Protects data while it's stored on a server, database, or hard drive, so that even if the storage is breached or stolen, the data itself remains unreadable without the key.

Common algorithm: AES-256

Use case: A company database storing customer emails, chat logs, or payment details, encrypted so that a server breach or misconfigured backup doesn't expose raw customer data.

Note: Keys are typically stored separately from the encrypted data itself (often via a key management service) so that access to storage alone isn't enough to decrypt it.

5. End-to-End Encryption (E2EE)

The strictest form when data is encrypted on the sender's device and only decrypted on the recipient's device. Not even the platform relaying the message can read it, since it never holds the private key.

Common examples: Signal, WhatsApp, iMessage

Use case: Private one-to-one or small-group messaging where maximum confidentiality is the priority.

Trade-off: Because the platform can't read the content, it also can't run server-side content moderation, spam filtering, or abuse detection on that data.

Comparison at a Glance

TypeWho can decryptSpeedTypical use
SymmetricAnyone with the shared keyFastEncrypting stored data (databases, files)
AsymmetricOnly the private key holderSlowerKey exchange, digital signatures
In Transit (TLS/SSL)Server (after arrival)Fast (session-based)Securing data moving over a network
At RestAnyone with the storage decryption keyFastProtecting stored/archived data
End-to-End (E2EE)Only sender & recipientFastPrivate messaging apps

Why It Matters

Most real-world systems don't rely on just one type, but combine them. For example, a typical secure platform might use TLS to protect data in transit, then AES-256 to protect that same data once it's stored, with keys managed and rotated separately from the data itself. 

This layered approach is also what compliance frameworks like SOC 2, ISO/IEC 27001, and GDPR generally expect to see, since it reduces the risk of exposure at multiple points — interception, breach, or internal misuse — without necessarily requiring full E2EE, which would block the ability to process content server-side.

How Watchers Uses Encryption

Watchers secures data using a layered approach, which allows the platform to combine strong encryption in transit and at rest with active content moderation. All traffic between customer apps and Watchers is encrypted in transit using TLS 1.2 or higher, and customer data is encrypted at rest with AES-256.

Encryption keys are managed through Google Cloud KMS, rotated regularly, and stored separately from the encrypted data itself which reduces the risk that a single point of compromise could expose both the data and the means to decrypt it. This approach aligns with Watchers' compliance controls, which are mapped to ISO/IEC 27001 and SOC 2 frameworks and reviewed annually.

Visit the Trust Centre and learn more about how Watchers protect data 

Boost your platform with

Watchers embedded tools for ultimate engagement