[messaging] Zero-metadata object store
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