Multi-device handling in C3RES (early ideas)

Requirements:

• ability to add and remove devices on-the-fly
  • new devices will have to be able to read existing shards
  • removed devices should no longer have access
• the above should be enabled by the key encryption scheme (if possible...)
  • want to avoid relying on server access controls: the shard received via other means should just as well be unreadable for removed devices
• also avoid sharing a "master key" with all devices: the root identity key should be kept somewhere where it's as secure as possible
  • how does a non-master device then access shards made by others and made available for me using my public key from the identity?
  • one could see the identity key as a kind of a CA root: it's only used to sign other keys that are used for actual access control...
  • ... but that would also be a hell of a hassle in case such a child access key would have to be revoked

Some ideas:

• use "two factor" system for the master key:
  • only save a randomly generated seed on devices
  • XOR that with a hash of a password given by the user
  • use the result as a seed for the pub+priv key generation (should be possible according to libsodium docs)
  • thus a device compromise wouldn't leak the key
  • need to make sure that brute-forcing the key from a leaked random seed isn't feasible (e.g. use a password hash that is computationally expensive)
• a big problem is having both, instant access to old shards by a new device and instant revokation of access for a lost one
  • this is probably simply not possible without either dynamic server support or changing all shards (their metadata) to contain a new or drop an obsolete access key
  • thus this has to be supported by some server logic, not just clever shard data scheme
  • ... in which case it might be easiest to just use a shared symmetric "device access" key that gets used by each device to encrypt the shard keys
  • to avoid the need for authentication, the symmetric shard keys encrypted by such a shared device key would then need to be once more encrypted by the server using the device public key. Something like this (and if the device were to be revoked, the second request would simply get the first response as well):

Normal request by someone:
-> GET /xyz123...
<- {metadata with standard encrypted access capabilities} + {shard data itself}

Request by an owner device:
-> GET /xyz123...?device=<dev-pub-key>
<- [[shard-stream-key^shared-device-key]^device-pub-key]{... the rest as above ...}

• multiple users should also be possible on a single server, but this has to be strictly separated concept from multiple devices