@gkc spiked this in PR59 and will create a pull request during PR60 to make this feature available as @experimental i.e. API not finalized
Is your feature request related to a problem? Please describe.
Currently the AtClient does not enable apps to easily choose to use different symmetric encryption keys for different data when sharing with some other atSign - we rely on a single default symmetric key e.g. @bob:shared_key@alice which is created under-the-hood when first needed, and used thereafter.
Describe the solution you'd like
AtClient should allow apps to explicitly create new symmetric keys and use them in put requests. Similarly, AtClient should see (from the encKeyName field in the metadata) when symmetric keys other than the default have been used, fetch that key, decrypt it, and use it to decrypt the data which was shared.
Thus for example an AtClient could create a symmetric key called 12345.__symmetric_keys.namespace@alice. As with the current default shared symmetric key, this symmetric key would be encrypted with @alice's public encryption key for storage so that @alice can retrieve it later. @alice should then be able to use this symmetric key when sharing data with @bob by creating @bob:12345.__symmetric_keys.namespace@alice, encrypting it with @bob's public encryption key as with current default shared symmetric keys, and should also be able to use the same key when sharing data with @charlie if they wish by creating @charlie:12345.__symmetric_keys.namespace@alice
The name of the shared key used should be placed in the encKeyName metadata field so that recipients can know that they need to fetch that symmetric key and use it to decrypt. Note that the encKeyName in this example would be 12345.__symmetric_keys.namespace and must not include either the sharedWith atSign nor the sharedBy atSign since they will be the same as the key for the record being shared (e.g. from @bob:some_data.namespace@alice we can see that sharedWith is @bob and sharedBy is @alice.
Additional context
Giving apps direct control over creation of additional symmetric keys enables app developers to use the atPlatform to cut new encryption keys, and share them using the existing platform key exchange mechanisms, for any purposes they wish - including encryption / decryption of data outside of the atServer - for example streaming, encryption of files for many recipients, storing encrypted data in other datastores, and generally, enabling use of atPlatform for key management and key exchange alongside other platform ecosystems.
More briefly: app developers can add end-to-end encryption into their existing applications without requiring them to completely adopt the atPlatform
gkc
commented
1 year ago
Note:
@gkc spiked this in PR59 and will create a pull request during PR60 to make this feature available as
@experimentali.e. API not finalizedIs your feature request related to a problem? Please describe.
Currently the AtClient does not enable apps to easily choose to use different symmetric encryption keys for different data when sharing with some other atSign - we rely on a single default symmetric key e.g.
@bob:shared_key@alicewhich is created under-the-hood when first needed, and used thereafter.Describe the solution you'd like
AtClient should allow apps to explicitly create new symmetric keys and use them in
putrequests. Similarly, AtClient should see (from theencKeyNamefield in the metadata) when symmetric keys other than the default have been used, fetch that key, decrypt it, and use it to decrypt the data which was shared.Thus for example an AtClient could create a symmetric key called
12345.__symmetric_keys.namespace@alice. As with the current default shared symmetric key, this symmetric key would be encrypted with@alice's public encryption key for storage so that@alicecan retrieve it later.@aliceshould then be able to use this symmetric key when sharing data with@bobby creating@bob:12345.__symmetric_keys.namespace@alice, encrypting it with@bob's public encryption key as with current default shared symmetric keys, and should also be able to use the same key when sharing data with@charlieif they wish by creating@charlie:12345.__symmetric_keys.namespace@aliceThe name of the shared key used should be placed in the
encKeyNamemetadata field so that recipients can know that they need to fetch that symmetric key and use it to decrypt. Note that the encKeyName in this example would be12345.__symmetric_keys.namespaceand must not include either thesharedWithatSign nor thesharedByatSign since they will be the same as the key for the record being shared (e.g. from@bob:some_data.namespace@alicewe can see thatsharedWithis@bobandsharedByis@alice.Additional context
Giving apps direct control over creation of additional symmetric keys enables app developers to use the atPlatform to cut new encryption keys, and share them using the existing platform key exchange mechanisms, for any purposes they wish - including encryption / decryption of data outside of the atServer - for example streaming, encryption of files for many recipients, storing encrypted data in other datastores, and generally, enabling use of atPlatform for key management and key exchange alongside other platform ecosystems.
More briefly: app developers can add end-to-end encryption into their existing applications without requiring them to completely adopt the atPlatform