You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We currently support one single type of public-private encryption keypair (RSA). We need to support ECC and likely others in the future
We currently encrypt symmetric keys in one way only, by using RSA asymmetric keys. We need to explicitly store some metadata about the asymmetric key that was used to encrypt the symmetric key, along with the encrypted key itself
We currently support one single type of symmetric key - AES-256. We need to support others.
We currently support one single type of encryption - AES-256 using the CTR cipher mode. We need to support others.
We currently support having only one public-private encryption keypair. We need to support having more than one - for migration purposes if nothing else.
We currently support @alice having only one single shared symmetric encryption key for sharing data with @bob, and @bob likewise having only one single shared symmetric encryption key for sharing data with @alice. We need to support each atSign sharing as many symmetric encryption keys as they like with another atSign, and choosing to encrypt data with any of those shared symmetric encryption keys they wish
Describe the solution you'd like
We currently support one single type of public-private encryption keypair (RSA). We need to support ECC and likely others in the future
We currently encrypt symmetric keys in one way only, by using RSA asymmetric keys. We need to explicitly store some metadata about the asymmetric key that was used to encrypt the symmetric key, and the specific encryption algorithm used (e.g. there are multiple different ECC algorithms and curves), along with the encrypted key itself
We currently support one single type of symmetric key - AES-256. We need to support others.
We currently support one single type of encryption - AES-256 using the CTR cipher mode. We need to support others.
We currently support having only one public-private encryption keypair. We need to support having more than one - for migration purposes if nothing else.
We currently support @alice having only one single shared symmetric encryption key for sharing data with @bob, and @bob likewise having only one single shared symmetric encryption key for sharing data with @alice. We need to support each atSign sharing as many symmetric encryption keys as they like with another atSign, and choosing to encrypt data with any of those shared symmetric encryption keys they wish
The content you are editing has changed. Please copy your edits and refresh the page.
XavierChanth
changed the title
(Tracker) Future-proof our encryption and encryption key management
[Tracker] Future-proof our encryption and encryption key management
Jun 14, 2023
Is your feature request related to a problem? Please describe.
@alice
having only one single shared symmetric encryption key for sharing data with@bob
, and@bob
likewise having only one single shared symmetric encryption key for sharing data with@alice
. We need to support each atSign sharing as many symmetric encryption keys as they like with another atSign, and choosing to encrypt data with any of those shared symmetric encryption keys they wishDescribe the solution you'd like
@alice
having only one single shared symmetric encryption key for sharing data with@bob
, and@bob
likewise having only one single shared symmetric encryption key for sharing data with@alice
. We need to support each atSign sharing as many symmetric encryption keys as they like with another atSign, and choosing to encrypt data with any of those shared symmetric encryption keys they wishHigh-level tasks (please add additional tasks here!)
The text was updated successfully, but these errors were encountered: