Seald's U.S. Shutdown: Migration Options

Comparing Seald’s Offering to IronCore’s Zero-Trust, Scalable End-to-End Encryption Approach

When Seald customers started calling us to say their E2EE service was being shut down with almost no notice, we were surprised. In the 10 years that IronCore has been in business, we’ve seen many encryption companies come and go, but this seemed different.

Seald was recently acquired by a much bigger company, OVH, a French infrastructure provider akin to AWS. The press release seemed to say that OVH was going to continue the service. Yet several Seald customers told us that their service was being shut down and they needed a replacement fast. As it happens, we have a product that fills the gap well (and, critically, one that supports E2EE with groups).

The first of these calls came in a few weeks ago, but Seald only communicated publicly about what was going on a few days ago. The same day, in fact, that they sent us a threatening letter which said in part, “we formally demand you to immediately cease poaching our customers.” Which is a rich threat, considering they’re dropping some of their customers and stopping support for others.

Normally we refrain from saying bad things about other startups’ products. It’s hard enough to be a startup without dealing with that. But these guys aren’t a startup anymore, and their product deserves some scrutiny.

We’ll start by looking at the changes impacting their customers.

Seald’s service changes

With their newest blog (their first since 2023), they explained that they are shutting down the service, but only for their U.S. customers: “Seald’s US operations have been discontinued during this transition period” (note: until we saw the blog, we were unaware they were only stopping service for some of their customers). They didn’t really explain the reasoning, only making a vague reference to regulatory requirements that doesn’t make sense.

So their U.S. customers are left in the lurch, but what about their European ones? First, it seems likely that the new OVH version of the service will require that customers use OVHcloud, which may not be a welcome change for customers that already use a different infrastructure provider. Second, and more importantly, OVH has parked the service in their innovation labs and labeled it as an “alpha” service, which means there is no support, there are no SLAs, and the service is in a “nascent stage” that may not ever graduate to a “true OVHcloud offering.”

For many, this is shaky ground to bet production-grade software on.

Seald’s architecture

Seald has taken down 70% of their website since the acquisition, including their technology explainer page, but we’ve used the still visible documentation to put together a comparative analysis with IronCore Labs’ E2EE product that shines a light on the major issues with Seald’s approach.

Seald has several products, including an email plugin and desktop app, both of which presumably use the same tech as their developer offering. IronCore only offers services for developers, so this is where we’ll focus our comparison.

Seald’s encryption service can be used in one of three modes:

1. “Authenticated encryption mode,” which allows sharing of a file to a user without an account. To make this work, Seald holds and can see the symmetric key used to unlock the file. Here’s their disclaimer from the docs: “Seald secures emails and documents only with symmetric encryption, and Seald servers become trusted third parties.”
2. “End-to-end encryption mode” without the “2-man rule” feature. Uses encryption and signing keys derived from a user’s password.
3. “End-to-end encryption mode” with the “2-man rule” feature, which uses a split-trust scheme that isn’t really end-to-end encryption (by their own admission, see below), making it somewhat misleading to call this an end-to-end encryption mode.

So while their home page claims to be zero-trust (“no server is inherently trusted”), we can see right away that isn’t always the case.

Also, when they talk about modes, they talk about their end-to-end encryption mode as a single option, ignoring the “2-man rule,” but when that feature is added in, their statements about this mode (“private key…never passes through our servers”) are undermined.

Seald encryption scaling issues

When a user is first initialized, they give a password that is used to derive, via scrypt, their RSA signing and encryption keys. These represent the user’s identity. Then, on each device, they create per-device RSA keys that they call “sub-identities.” When the “2-man rule” is off, these private keys are only ever on the client devices (good).

Importantly though, the keys are only as strong as the user’s password, which is a first problem.

But in order to use these per-device keys, everything encrypted to the user must get encrypted to each of the user’s devices. Going forward, anything encrypted to the user will be encrypted to all of their keys (main identity plus all sub-identities/devices). Consequently, on a new browser or device login, the user must enter their password to unlock the main identity, generate new keys, download encrypted keys for all documents encrypted to them, decrypt with the master key, re-encrypt to the new key, and re-upload the newly encrypted data.

No big deal if a user only has access to 10 files, perhaps, but a very big deal if a user has 100 or 1,000 or more things encrypted to them. The more data encrypted to the user, the longer the new device process will take, the more data that needs to be transferred, the more battery and CPU that is used, and so on.

Additionally, every sub-identity slows down encryptions to the user because every new document must be encrypted to each public key associated with the user. Because of these issues, Seald recommends just sharing the main key derived from the password across devices, which means you can’t revoke access from devices that are lost or stolen:

Seald recommends sharing the main key across devices, which means you can’t revoke access from devices that are lost or stolen.

Seald encryption groups: scaling and revocation problems

Another feature of Seald is the ability for data to be encrypted to groups. This is also a major feature of IronCore’s Data Control Platform, which works very differently (explained below).

Seald doesn’t explain how their groups work, but we’ve drawn some conclusions from hints in the docs that we’re pretty confident are right. For example they say encrypting to a group is a single cryptographic operation, which leads us to assume there’s a single public key per group. They also say that when you add a member to a group, the member is instantly able to decrypt all messages previously encrypted to the group, which leads us to assume the private key is shared with each user (likely encrypted to their user keys and sent to them as needed).

The problem with sharing a private key across group members comes when you want to remove a member from the group. The user could have captured and saved the private group key, which would allow continued decryption of all past and future documents encrypted to the group. When a member is removed, the key needs to be considered compromised and should be rotated. They don’t explain this, but they do give a nod to it when they recommend “renewing” the key after removing a member of the group:

Conversely, when a member is removed from the group, they can no longer decrypt the data encrypted for that group. In this case, and for more security, it is advisable to renew the group keys.

This tip will likely slide by most people since it isn’t explained, but it confirms what we’re saying. To keep encrypted documents secure after a user is removed from a group, a new group key must be created. This process is similar in concept to creating a new sub-identity. Everything encrypted to the group must be downloaded to the client, decrypted, and then encrypted again to the new group key. This is a potentially very slow operation depending on how many documents are shared with the group. It fundamentally limits how much can or should be encrypted.

[on removal of a group member] everything encrypted to the group must be downloaded to the client, decrypted, and then encrypted again to the new group key

Seald’s “2-man rule” security compromises

(still going? really? 😰 unfortunately, there are more major issues that contradict their marketing claims)

As an alternative to deriving keys from a user’s password, and to allow for recovery of keys and accounts, Seald offers an option that they call the “2-man rule.” It works like this: Seald stores the encrypted private keys of the user (so, yes, user keys do get sent to the server, though they are encrypted) while Seald’s customer, the software vendor, stores a per-user encryption key in plaintext that unlocks the key held by Seald. The idea is for the encrypted key and the one that protects it to come together in the client only when both Seald and the software vendor independently authenticate the user (Seald via sending a code to the user’s email).

This is a split-trust model (read more on trust models), which means that data can be unlocked if the service provider and another party collude. This is a valid model that can be an appropriate choice in certain situations, though this is a fairly weak implementation of this trust model (a better scheme would use Shamir’s secret sharing or secure multi-party computation).

Their docs expressly say they securely split the secret, but that’s not accurate. They separate the key from the data (in this case the user’s key is the data).

However it’s done, the issue here is that the “end-to-end encrypted” data can be recovered by the service provider, which they also acknowledge:

The “2-man rule” is also used for groups, so that group private keys can be recreated by collusion between Seald and the software vendor.

IronCore’s improved approach with the Data Control Platform

IronCore’s Data Control Platform (DCP) is a stable, battle-tested, lasting, and powerful end-to-end encryption solution with strong security guarantees. It isn’t alpha, it’s fast, scalable, and IronCore is always zero-trust with respect to confidentiality.

Like Seald, DCP also offers support for groups. Unlike with Seald, DCP performance doesn’t change with the size of groups and there are no modes that require trusting IronCore. IronCore accomplishes this with a technique called “proxy re-encryption” or “transform cryptography” which lets you encrypt to a public key, and then delegate decryption rights to specific users, each of whom have their own public/private key pair. No one ever sees the private keys of the group.

DCP: revocation done right

Among the very cool things this allows is the ability to confidently revoke access by removing someone from a group and knowing they won’t be able to decrypt anything encrypted to the group – past, present, or future. It also means that the service provider (IronCore) can never access data or even grant data access to anyone. It’s not in our power because we don’t have access to the private keys required to do so. Only the data owner can do that.

The software vendor (IronCore’s customer) can decrypt data if and only if they are explicitly granted access by encrypting data to a user they control or to a group that includes one of their users. This is a cryptographically secure scheme that cannot be bypassed even with collusion.

This is true zero-trust end-to-end encryption, with provable revocation.

DCP: works at any scale

Another benefit of IronCore’s technology is scalability. The cost of revocation is independent of how many documents are encrypted to a user or group. It doesn’t matter how many people are in a group, either. Users can have as many devices as they like without penalty, and each can be individually revoked if lost or stolen. Encryption, decryption, adding users, adding devices, changing group membership: all take the same amount of time at any scale of data and users. There are no secret performance or security gotchas.

Trust but verify: transparency makes good security

Good security requires sunshine. Obscuring security breeds flaws. Trying to understand what Seald is actually doing has been tricky. They detail some aspects in depth, but others, like how groups work, are not spelled out.

They did publish some information on their use of crypto algorithms, like AES in CBC mode (why not GCM?) and RSA with SHA-1 (oof! SHA-1 has been broken since 2005 and formally deprecated by NIST since 2011, and although it probably doesn’t hurt their security in the way they’re using it, it’s still a bad choice).

IronCore, on the other hand, believes strongly in the power of transparency. We’ve published full academic papers, open sourced our code, had it audited for cryptographic security, and much more. There’s nothing up our sleeves that we are trying to hide.

Good security requires sunshine. Obscuring security breeds flaws.

Summary of key differences

Get started migrating to IronCore

If you’re evaluating E2EE solutions, whether you’re migrating off Seald or starting fresh, the Data Control Platform is built for advanced data security use cases including end-to-end encryption with groups. We offer strong, provably secure cryptographic access controls and the kind of stability that comes from a decade in the business.

Reach out to us to talk about your specific use case, or follow the quick start guide to kick the tires yourself.