Question about architecture

[ringofstorms]

I’ve recently read through all of Security Architecture — Cryptomator 1.6.0 documentation and had some lingering questions about why certain choices were made that are not explained. I am not sure if it is just common sense stuff when it comes to encrypting files, if it is maybe some links to external resources could be useful as well if this is the first place someone (like me) is learning and digging into the details of this sort of thing.

Primarily I am wondering if there is a full explanation of why the file content encryption is done the way it is:

• Why is is done in chunks rather than over an entire file?
• What was the determining factor of said chunk size?
• Maybe some more info on the purpose of HMAC’s and how they are used.

I also wanted to know more about the inverse of everything in the architecture section. It covers in depth how things are encrypted, but it does not cover reading the files back out and what guarantees cryptomator does to ensure files are durable. I assume the hmac’s on each chunk are to ensure content of any chunk is not edited, but this requires the software decrypting the files to verify these. It would be great to see pseudo code examples of how cryptomator reads the files back. Some simple versions of this process like what is there currently for the encryption process would go a long way in understanding imo.

I assume many of these choices were made to make it possible to read a file partially in order to stream files and get partial bits of a file, but this is just a guess after reading and understanding more of the cryptomator offering. The docs could have a section on the mobile implementations too explaining how those work (I assume they are not downloading the entire vault to the mobile device, but rather get them as needed.

[tobihagemann]

@ringofstorms

• Why is is done in chunks rather than over an entire file?

[…]

I assume many of these choices were made to make it possible to read a file partially in order to stream files and get partial bits of a file, but this is just a guess after reading and understanding more of the cryptomator offering.

Your assumption is correct. Chunks are great for random access (and therefore streaming).

@ringofstorms

• What was the determining factor of said chunk size?

We made a lot of performance and stress tests of our own back then and we determined this value empirically. It was probably nothing out of a textbook.

@ringofstorms

• Maybe some more info on the purpose of HMAC’s and how they are used.

[…]

I assume the hmac’s on each chunk are to ensure content of any chunk is not edited, but this requires the software decrypting the files to verify these.

Your assumption is correct. This is called “authenticated encryption”, in this case “Encrypt-then-MAC”. The HMAC is basically making sure that the encrypted chunk is authentic to ensure integrity. And it’s true that the software has to explicitly verify the MAC and stop decrypting the file any further, which makes it an implementation detail.

@ringofstorms

I also wanted to know more about the inverse of everything in the architecture section. It covers in depth how things are encrypted, but it does not cover reading the files back out and what guarantees cryptomator does to ensure files are durable.

I don’t think that we need to duplicate the documentation for “decryption” but you’re right that there could be some further documentation on decryption details that aren’t obvious. We’ll have a look at it from the “decryption” perspective.

@ringofstorms

The docs could have a section on the mobile implementations too explaining how those work (I assume they are not downloading the entire vault to the mobile device, but rather get them as needed.

Good point. While designing the encryption scheme, we always had the mobile implementations in mind. Some of the decisions that were made were absolutely because of that.

[ringofstorms]

Awesome, thanks for replying in detail to each of my points and confirming things. I’ll do some more of my own research into the “authenticated encryption”/"Encrypt-then-MAC”, thanks for the names of those.