added proposal for metadata and drive#2412
Conversation
|
We built an encrypted drive on the same primitives (Blossom blobs + Nostr metadata events), so here's where our design differs from this proposal and what each choice cost. The proposal stores a per-file encryption key inside each file's metadata event. We don't store file keys at all — we derive them: root key → folder key → file key, HKDF each step. A file's key is HKDF(folderKey, fileId). The reason is sharing. Share a folder and you hand over one folder key; the other side derives every file key under it. With per-file keys in metadata, sharing a folder means re-sharing N keys. The cost lands on the other end. Revoking access to a single file is the expensive case for us: the key is derived, so we can't just swap it in metadata. We mint a new file id, download, decrypt, re-encrypt, re-upload, republish. Rotating a whole folder or the root is cheap by comparison — we re-wrap the key tree and leave the blobs alone. Two smaller choices, in case they're useful for the spec: we use XChaCha20-Poly1305, not AES-GCM, and we chunk into one container with per-chunk nonces derived from a base nonce rather than listing each chunk's hash. Happy to write up either. |
|
Hi @theLockesmith would you mind explaining your idea in detail? I could not get the derivation of keys part or derivation of chunk hashes part. Sometimes, the AI comments are too confusing to understand 😄 . Also, here is an updated NIP: https://nips.pollerama.fun/nip/naddr1qvzqqqrcvypzpg3dheg783ce4k9jehp7fl7zzahjqdelxqnmv7sacmrwjahme4kcqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqqpnwd9cz6ennddmu2k |
|
Haha yeah, those responses can be a bit convoluted. Lesson learned. We don't store file keys, we recompute on the fly. So when you share a file or folder, you're handing over a file/folder key. Revoking a file share is straight forward, that file just gets re-keyed. Revoking a share of a single file from a folder requires the folder key to be rotated otherwise the new file key can just be re-derived because the user has the folder key and can read the new file ID from the folder listing. Then they'd just have to run the same HKDF and get the new key. I think we got some wires crossed with the derivation of "chunk hashes" though; hashes are just sha256(ciphertext), nothing is derived here. The nonce per chunk is derived from a base nonce, but there is no chunk derivation. |
|
Ahh interesting approach we solved sharing by adding a folder metadata event which is essentially a list which contains references to child items(which can be a folder or a file). its not in the proposal yet, but its a work in progress |
2 participants
Proposal for implementing private encrypted drive on nostr. This builds upon the idea proposed here #1647.