Every object and slab contains an encryption key. For the latter it also serves as a unique identifier. The issue with that approach is the fact that fetching an object for downloading or adding an uploaded object to the bus transmits the secret. For a single node setup that is not a big deal but for cluster setups this is not ideal.
Imagine keeping the bus behind a cache (e.g. Cloudflare). Object metadata is ideal for that. However, you might not want to cache these secrets in a globally distributed caching layer that is out of your hands. This is where "salted encryption keys" become handy.
Implementation
EncryptionKey is a very straightforward type right now. When turned into a string, a key is prefixed with key:.
A salted key should be a drop-in replacement for the current keys, being returned via the same field in the objects/slabs but with a different prefix. e.g. skey (open for better suggestions)
A salted key is still generated the same way but has to be hashed together with a second secret to be turned into the actual key used for encryption. This second secret would live in the worker (e.g. derived from the seed) and never leave it.
That way objects can safely be cached without the transmission of any security.
Compatibility
The worker should continue to support the old type of key for already uploaded object. Not only that, but we also need to consider that third party projects that evolve around file sharing need to be able to share object metadata with the old key type.
To solve this we can add a flag to the bus which allows for fetching objects with the old version of the key which the bus converts on the fly.
Motivation
Every object and slab contains an encryption key. For the latter it also serves as a unique identifier. The issue with that approach is the fact that fetching an object for downloading or adding an uploaded object to the bus transmits the secret. For a single node setup that is not a big deal but for cluster setups this is not ideal.
Imagine keeping the bus behind a cache (e.g. Cloudflare). Object metadata is ideal for that. However, you might not want to cache these secrets in a globally distributed caching layer that is out of your hands. This is where "salted encryption keys" become handy.
Implementation
EncryptionKeyis a very straightforward type right now. When turned into a string, a key is prefixed withkey:. A salted key should be a drop-in replacement for the current keys, being returned via the same field in the objects/slabs but with a different prefix. e.g.skey(open for better suggestions)A salted key is still generated the same way but has to be hashed together with a second secret to be turned into the actual key used for encryption. This second secret would live in the
worker(e.g. derived from the seed) and never leave it.That way objects can safely be cached without the transmission of any security.
Compatibility
The
workershould continue to support the old type of key for already uploaded object. Not only that, but we also need to consider that third party projects that evolve around file sharing need to be able to share object metadata with the old key type.To solve this we can add a flag to the bus which allows for fetching objects with the old version of the key which the bus converts on the fly.