[PM-115] Cipher key encryption update

[fedemkr]

Type of change

• Bug fix
• New feature development
• Tech debt (refactoring, code cleanup, dependency upgrades, etc)
• Build/deploy pipeline (DevOps)
• Other

Objective

The cipher will now have its own Key to encrypt/decrypt its content which will be encrypted using the master password or organization key.

This needs server changes to work and clients changes to have the key assigned (given that for now the mobile client won't create the cipher key):

• Server: [SG-966] [SG-967] Add new cipher properties, update DB objects and create migrations server#2681
• Clients: [PM-1086] Cipher key encryption and decryption update clients#5114

Code changes

• Cipher: Added new properties for the key. Added logic to decrypt using the new Key if available, passing such key to the different item types. And updated it to not use hardcoded strings and use nameof().

• CipherService: Updated logic to encrypt the Cipher using the new Key.
  Note: for now the logic of the new Key gets applied only if the Key already exists on the Cipher. The creation of such Key locally will be enabled on a later release to avoid conflicts between clients.

• CipherData: Added new properties for the key.

• CipherRequest, CipherResponse, CipherView: Added new properties for the key.

• Attachment: Updated it to not use hardcoded strings and use nameof() and also added the key as a parameter to support the new approach.

• Card, Field, Identity, Login, LoginUri, PasswordHistory, SecureNote: Added the key as a parameter to support the new approach.

Before you submit

• Please check for formatting errors (dotnet format --verify-no-changes) (required)
• Please add unit tests where it makes sense to do so (encouraged but not required)
• If this change requires a documentation update - notify the documentation team
• If this change has particular deployment requirements - notify the DevOps team

[mpbw2]

How is performance when flinging through the cipher list?

[fedemkr]

As far as I see, the entire cipher list gets decrypted before shown to the user so the performance while flinging is the same as before. But yes, we should have a little bit more overhead while decrypting the whole vault ciphers.

[mpbw2]

Ah ok, I was thinking this could provide some performance insight to adapter-driven content if/when we take that step.

[fedemkr]

I think we can measure that and see how it would impact in such situation. However, if we take that route we should probably cache more things in order to have the smoothest UI/UX and refactor the code accordingly. I believe that if we paginate or lazy decrypt the ciphers as they appear it would have a really fast load time of the page but we need to think it carefully a preload/predecrypt ciphers so that flinging through the list doesn't get much affected by it

[bitwarden-bot]

Checkmarx One – Scan Summary & Details – 055f33bf-7ed7-4c7b-adf6-543b892a415b

No New Or Fixed Issues Found