Hello.
From latest release notes: An extra layer of encryption in the form of a new encryption key generated for each individual vault item has been added.
But what is the benefit of using cipher key? according to this article, cipher key is encrypted with user symmetric key. Cipher text and cipher key are stored at the same table in DB, so what is the difference (by security pov) between encrypting text or encrypting key that encrypt text?
Individual item keys are more secure in some very rare scenarios, but more importantly, it enables implementing sharing of item without having to re-encrypt the item and attachments during the sharing process.
1 Like
With this new design, will unlocking the vault still cause the entire vault to be decrypted in process memory, or is it now possible to dynamically decrypt only the subset of the vault that is being actively used?
This new design does not change the state around how decryption occurs, but bitwarden methods to decrypt selectively to improve security and performance in our SDK.
If you have time, I would be very interested in hearing more about new/planned abilities to decrypt selectively, and the corresponding implications for security.
Nothing to report right now, but keep an eye on the Android and iOS repositories to see progress in-flight. And, as always, Bitwarden will update the security whitepaper to reflect changes to the security model.
The information concerning the “Cipher keys” in the whitepaper is very limited. Can someone please clarify
- Why there is a need for yet another level of key(s)? What purpose do they serve?
- Are these item-level keys or a vault-level key(s)? Is there a vault-level cipher key?
- What is the chain of custody of those keys? Where these keys are kept (except bundled in the vault) ?
Thank you.
@Kerr_Avon Welcome to the forum!
I just moved your post into another thread about similar questions on the same topic.
Here a screenshot of the Release Notes 2024.7.1 from back then (mentioned in OP):
(the link – to the Security Whitepaper – is still the same as @ivulit provided in the OP)
PS: I expanded the title from Vault item keys to Vault item keys, cipher keys etc.
Thank you, but that tread only answers Q No.2 - Cipher keys are item-level keys. But how they are implemented? Are these used for exchanging items between users on the server side?
And why “64-byte”/512 bits keys - AES does not support keys longer than 256 bits.
I find it surprising so little is explained in the whitepaper about security implementation of these keys, esp in an open source product.
So each individual item is encrypted now with new encryption key - but still the “ask master password re-entry” does not alter this encryption key in any way? So it is still not possible to further protect individual items of folders in the database by putting a different (additional) password onto them?
That’s accurate. However, IMO, the infrastructure that has been built may allow for such features to be implemented in the future. I would recommend trying to be patient for now, and seeing where developments take us.
It doesn’t add any new information (as it’s essentially the same as @Micah_Edelblut wrote back then) - but just to add another location/topic where “item-level encryption” was also mentioned here on the forum: Vault Item Sharing (different from the current Org/Collections implementation) - #205 by gtran