Encryption in Bit Chest

Bit Chest contains strong encryption as one of the core features of the storage API, because we know that the data stored in Bit Chest will oftentimes be personal and very dear to you. After a lot of research and deliberation, we have settled on using AES-256 in EAX mode, with a key that can either be randomly generated, entered by the user or derived from the user’s password with bcrypt. What does all of that mean?


Encryption is done using the well-known Advanced Encryption Standard (AES), with a key length of 256 bits. This is the strongest standardized encryption known, there are no known attacks against the algorithm, and we expect it to be secure for the foreseeable future. Since we expect to store data for a very long time, it’s of utmost importance to choose an algorithm that is known to be secure and is expected to stay so for a long time, even if that algorithm may be slow or memory-intensive. So that’s why we went with AES.

But pure encryption is, unfortunately not enough. What we need additionally is authentication.


Authentication means that any data you decrypt can be verified to be from the source that you think it is from, and that the data has not been tampered with during transmission and storage. This is important because otherwise, an attacker could try to plant some data in your stream that you would accept as “real” without knowing that there was tampering.┬áIn asymmetric cryptosystems authentication this is usually called “signing”. In asymmetric cryptosystems, it’s rather easy to sign, because there, encryption and decryption use two different keys. Simply swap the keys, and you turn an encryption scheme into a signing scheme. In symmetric cryptosystems, such as AES is, this cannot be done since there is just one key. So we need another thing.

We chose to go with EAX, a standardized encryption and authentication scheme using AES as its main building block. There are several great things about EAX, next to the encryption and authentication business, and the best of these is that there is a proof of security available for the scheme. This means that using EAX does not pose any security disadvantages as compared to using plain AES. Any security problems with EAX encryption stem solely from security problems in AES. Since we’re pretty confident in the security of AES, that security guarantee is awesome.

So now we have encryption and authentication, so we’re pretty safe that the data we decrypted is the same as the one that we sent to storage, and that no one did read or tamper with the data. However, all of that security now rests on two things: AES and the key we use for encryption.

The Key

The last component in our cryptographic system is the key, and that one is also the most complicated. We have two requirements that we want to impose on our keys: They must be as close to indistinguishable from randomly generated keys as possible, and we must be able to reliably store them for later decryption of the stored data. The second point here is very, very important: if you lose the keys to the data that you’ve stored, there is no way to retrieve them, and the stored data becomes lost. Since there are degrees of safety, we offer three ways of generating the key:

You generate one randomly

This is the simplest way of handling the key from our perspective, because all of the responsibility falls on you: You are responsible for creating a secure key, for entering that key into all of your client computers for encryption and decryption and you are responsible for not losing the key. However, it is also the most secure way, since you have all the confidence over your data: no one sees your key, the key never leaves your computer and you can make sure it is as close to random as you want to be.

If you are very security-minded, we advise you to take this route and handle the key yourself. But be warned: if you lose the key, you lose the data.

Your key is generated from your password

Here’s a neat little trick: There is already a piece of secret information that we use for authentication: your password. Since we don’t store your password on our servers (only a hash, which cannot be used to retrieve the password), we (Bit Chest) cannot use the password for anything else than authentication. But you can! Using the well-known bcrypt algorithm, you can use your password for deriving an encryption key for your data. This way, only you can derive your encryption key, it’s easy to set up even on multiple computers and the key is reasonably safe. However, should you lose your password, you will also lose your encryption key and with that also your data.

We generate one randomly for you

The third way of managing keys we offer for you is the simplest from a user perspective: We generate a key for you, store it on our servers and make it available to you through your password. This means that you have all the features available in an automated cryptographic system: automatic and secure key generation, easy setup and quick access, and no risk of losing your password. As long as you have access to your email, you will have access to your data. However, that comfort comes with a trade-off in security: Since we know your key, we might be using it for nefarious purposes, we might lose it or it might be stolen (which we work hard not to let it happen, of course) or we might be impelled to hand it over to law-enforcement.

Since the normal user will expect all of these comfort functions in a modern web service, this mode, where we generate and hold the key for you, is the standard way of operation for Bit Chest.

The choice is yours

And there you have it: A trade-off between security and comfort. At one end of the spectrum you have total security but also all of the responsibility, at the other end you have all the normal comfort functions and little responsibility but also a somewhat lower security. Of course, we will assist you in your choice and present the options, their properties and tools to help you with each one of them.

It’s yours to choose, but don’t worry: Your data is safe and protected in any case!