That is my response because your responses to critiques of the service are incredibly irrational and seem financially motivated. You would need to pay me to be as motivated to defend a random company as you seem to be.
But I literally just agreed with someone up above about saying maybe if they used Bitwarden then that it was understandable why they wouldnât use this:
Then I ended it as yeah it was a reputable point yours isnât. Just fud.
I literally linked to their documentation in my critique, how do you think I know enough to make that critique if I havenât read their documentation? If I am wrong on the facts, counter my claims.
from the documentation that you provided:
Passbolt encrypts metadata using OpenPGP keys. There are two options:
Personal key: The userâs own OpenPGP private key encrypts metadata. Only that user can decrypt it. The server cannot access this metadata.
Shared metadata key: One OpenPGP key pair exists for the organisation. Its private key is encrypted separately for each user using their public key. All users who have been given a copy can decrypt metadata encrypted with this key.
Why both exist:
Shared resources require a shared key. When multiple users access a resource, they need to decrypt the same metadata. Each user decrypts their copy of the shared private key, then uses it to decrypt the resource metadata.
Personal resources can use either. You can allow personal (non-shared) resources to use the userâs own key for maximum privacy, or enforce the shared key for all resources so administrators can audit metadata.
This page configures:
- Which key is used for personal resources
- How the shared key is distributed to users
Zero-Knowledge Key Distribution
Controls how the shared metadata key is distributed to users.
Navigate to Organisation settings > Content types > Metadata key to configure.
User-Friendly Mode (Default)
The API has access to the shared metadata key and distributes it automatically when users complete setup.
Security:
- Protects metadata if the database is compromised
- An attacker with full API access can access the shared metadata key
- Passwords remain encrypted with user personal keys
Zero-Knowledge Mode
The API does not have access to the shared metadata key. Administrators must share it manually with each user after setup.
Security:
- Protects metadata if the database or API is compromised
- Passwords remain encrypted with user personal keys
Operational requirements:
- Administrators must share the key with each new user
- Users cannot create or share resources until they receive the key
- Key rotation recommended when switching to this mode
Thanks for quoting it, now how does that contradict anything I said?
This
Explain the difference, please. Iâm begging you.
2 Likes
One key is for their personal metadata. The other key is the organization key which is to share metadata. The organization private key is encrypted separately with each users public key so they can decrypt metadata with the key that is shared to them. These keys can be rotated in the future.
Another key is used for the userâs passwords and other contents outside of meta data.
Personal key: The userâs own OpenPGP private key encrypts metadata. Only that user can decrypt it. The server cannot access this metadata.
Shared metadata key: One OpenPGP key pair exists for the organisation. Its private key is encrypted separately for each user using their public key. All users who have been given a copy can decrypt metadata encrypted with this key.
Why both exist:
Shared resources require a shared key. When multiple users access a resource, they need to decrypt the same metadata. Each user decrypts their copy of the shared private key, then uses it to decrypt the resource metadata.
Personal resources can use either. You can allow personal (non-shared) resources to use the userâs own key for maximum privacy, or enforce the shared key for all resources so administrators can audit metadata.
That is why they also thought of this:
1:1 encryption
Passbolt encrypts each password individually for granular, containerised data privacy, ensuring that the compromise of one password does not affect others.
Yeah, now youâre repeating what I said. I fail to see what you think is factually wrong with my statement. You seem to just be upset that I view this design as a negative.
Although youâre also missing the point. The issue isnât that there are two keys. Bitwarden also uses a shared/individual key scheme for their sharing. Itâs that theyâre shoehorning PGP into it in ways that just donât make any sense. Why does the shared key need to be asymmetric? If every user who works with the data has a copy of the private key why is it not just a symmetric key?
I mean, OK? This is like a water is wet statement, youâd have to go out of your way to try and make a single blob of all the password data before encryption, instead of just encrypting any individual entry. This is the easy path, it didnât take them extra work to do this.
Now you are spamming marketing materials for no apparent purpose.
Stop spamming the Passbolt whitepaper, a link is perfectly sufficient.
If you cannot manage to remain civil then this topic will be closed to new comments and you will be suspended. This is your only warning.
This applies to everyone.
4 Likes
Here Iâll explain it for you. It is designed purposely this way:
Passbolt is built on OpenPGP from the ground up, with a hybrid model. Each secret, such as a password, is encrypted with a random symmetric session key (AES). This session key is then encrypted with each recipientâs public key (RSA/ECC), ensuring that only their private key can decrypt it. For shared resources, instead of a single shared symmetric key, each userâs public key encrypts the session key, maintaining end-to-end encryption. Also, Passbolt supports a shared metadata key (an OpenPGP key pair) for encrypting resource metadata, such as folder names and descriptions. This shared key is distributed securely by encrypting it with each userâs public key, centrally managed by admins for auditability, and rotatable for security maintenance.
So, for more context:
So, rather relying on a single shared symmetric key (which could compromise security if leaked), Passbolt encrypts a separate instance of the session key for each userâs public key. This preserves individual end-to-end encryption while allowing multiple users to access the same resource.
For much more context:
For resource metadata (folder names, descriptions, usernames, URIs), Passbolt supports a dedicated OpenPGP key pair as the shared metadata key. This key encrypts the metadata symmetrically (again, via a session key wrapped in the asymmetric layer). The privat key is securely distributed by encrypting it individually with each authorized userâs public key. Administratrs centrally manage this key for auditability (in âserver knowledgeâ mode), and it can be rotated to revoke access or enhance security.
That is the concern.
Itâs not really from the ground up if theyâre using OpenPGP (though being built from the ground up is not usually a good thing in cryptography!), but my whole point is OpenPGP is the wrong tool for this job.
That is just how OpenPGP works, that is not something Passbolt have created.
My point in regard to the metadata key is why is it not just a shared symmetric key? There is no practical benefit to distributing a PGP keypair for this and that makes me question the reasoning behind the design. When a design is unusual and there is not a benefit behind the deviation from standard practice, it is usually not a good thing.
If a secret key is leaked it doesnât matter if itâs used for symmetric or asymmetric cryptography. Using PGP in this way doesnât help protect against this risk at all.
It does not, because the encryption is still ultimately protected with a shared key that everyone involved has access to. The only difference here over just using a shared symmetric key is more complexity by using PGP for things it isnât designed for.
I donât know why you think because I take issue with their design decisions I must not understand them. I fully understand, and that is why I am raising concerns. Please stop trying to condescend to people and just engage in the discussion if you want to have one.
2 Likes
Which they can rotate for security.
Itâs securely designed you just donât like the way it is designed for and are nitpicking at straws.
There is no difference in this regard between an asymmetric key as they have set up and a symmetric key like I described.
In terms of auditability, the ability to log, trace, and verify actions without compromising confidentiality, there is a difference between symmetric and asymmetric in PGP.
Symmetric keys (a shared AES key): Auditability is harder because the key must be distributed secrely to all parties upfront. If compromised, it affects everyone, and revocation requires full key rotation (reencrypting all data). Logging access is possible, but verifying who accessed what relies on external logs rather than cryptographic proof. This can lead to scenarios where auditing one userâs actions risks exposing others.
Asymmetric keys (per-user public/private pairs): Auditability is stronger due to inherent properties like non-repudiation (via signatures) and granular revocation. Each user has their own private key, so actions (creating or modifying a secret) can be cryptographically signed and verified independently. Revoking access is simple: just delete the recipientâs encrypted copy no rotation needed. This enables fine-grained logs of who did what without decrypting the data itself.
Asymmetric keys enable better audit trails because signatures provide verifiable proof of origin, and the hybrid design allows selective decryption for audits.
Well this seems like a fundamental design issue. That is not something i would trust to be âfixedâ the architecture from start is definitely not on par.
What do you mean by the architecture is not on par. Can you explain in detail, please, and provide evidence of why itâs not on par.
The whole idea of doing this with pgpâŚ
1 Like
You also still havenât provided proof from the audits and the whitepaper that what they are doing is wrong or insecure.
Their PGP implementation is not insecure so, I donât understand the backlash.
Lol. That should be up to them to proof that they are secure
1 Like