[messaging] Zero-metadata object store

Mikalai Birukou mb at 3nsoft.com
Sun Dec 1 15:54:13 PST 2019

> My project is not strictly messaging-related, but I think this is still the most fitting forum.

Your gut feeling is right, this is an appropriate place. Secure 
messaging starts from users using some key material. As a modern user I 
have several devices. I want my stuff to be synced, and I should be able 
to loose my devices. End-to-end encrypted storage that is safe to sync 
to some server is immensely useful for keeping these key material.

> Zerostash stores all data in 4MiB blobs that look random from the outside. I use Argon2 and libsodium’s key derivation APIs to make all of this addressable through a user password, and lz4 inside ChaCha-Poly for encrypting the blobs.

Do metadata objects contain file tree information?

Is file tree continuously packed into mobjects, i.e. many folders' data 
is placed into every mobject? Or, is it a one mobject per folder structure?

Suppose that I sync objects onto server. Suppose also that one of the 
files there is big, like GBs BIG. What will happen if I change some 100 
bytes in the middle? What objects change? Are there new objects create? 
What should be send to server for sync?

Is it correct that for reading a small section of a multi-GB file, I'll 
have to download from server and to decrypt all 4MB of some dobject?

> I’ve uploaded the specification and code to https://github.com/rsdy/zerostash, and would be grateful for some feedback.

Is it possible to give object ids and some keys as a way of sharing only 
part of the file tree, without giving out key material for other parts 
of the tree? Cause https://github.com/rsdy/zerostash#key-management 
reads like there's one data key (derived subkey).

Quote from https://github.com/rsdy/zerostash#data-objects """The key to 
encrypt each chunk is Blake2s(plaintext) XOR Argon2(user key)""" Is it a 
plaintext of content? When decrypting, I don't know content, hence, key 
must be in some mobject. Why can't it be a randomly generated key, 
stored in mobject, providing the same claimed feature: """therefore 
compromising a user key in itself does not necessarily result in full 
data compromise without access to indexing metadata.""'

How are nonces generated?


More information about the Messaging mailing list