# Overview

The objective of the Seald technology is to protect data in an application by assuming that the application's servers can become malicious.

# Weakness of encryption in transit & at rest

Generally speaking, when an application is developed, it is used to intermediate data between several users.

A classical methodology to integrate an encryption policy in such an application is to add encryption in transit and at rest (possibly with an off-site key management in a KMS) as described in the diagram below.

uml diagram

Using only encryption in transit and at rest introduces a structural weakness: the back-end has the data in clear text (at least during execution).


If the back-end is compromised, all the data to which that back-end has access may be compromised.

# Defensive attitude towards the hosting provider

What Seald proposes is to adopt a defensive attitude towards the hosting provider and consider that it can be compromised.

For more information on the motivations behind this seemingly radical attitude, please refer to our white paper (opens new window).

# Client-side encryption

The only way to ensure that a hosting provider (which is considered malicious) cannot read the data is to not allow it to read the data it manipulates by using "end-to-end" encryption that is performed on the client side.

uml diagram

Seald provides a turnkey solution for implementing client-side encryption in web, mobile and desktop applications.

# Diagram

In a simplified way, here is how the Seald-SDK integrates:

uml diagram

Data is encrypted using the Seald-SDK from the front-end of the application (web, mobile, desktop).

To perform encryption, the Seald-SDK uses the user's identity which is generated when the account is created and can be retrieved using one of three methods:

The Seald-SDK distributes keys to recipients through the Seald API, which allows to:

  • retrieve the public identities of other users;
  • create a new key and distribute it encrypted end-to-end to other users;
  • authorize, revoke other users or groups to access previously encrypted data;
  • get a key encrypted for yourself to decrypt encrypted data.

For more information, see the specification of the cryptographic algorithms used, as well as the specification of the encryption protocols