Using the debian package, I’m trying to switch my users keys from RSA to ECC (I suppose it will improve response time).
But I’m a little bit lost in how to do that.
How can I manage environment variables (PASSBOLT_PLUGINS_USER_KEY_POLICIES_PREFERRED_KEY_CURVE) in the standard debian configuration file passbolt.php ?
Then, am I supposed to create new users (with same email ?), migrate all the encrypted stuff, have the users switch profiles on all devices, then delete the older ones crossing my fingers everything was migrated well ?
The tooltip “you can only manage one key for the moment” in the user panel looked promising, but the moment is a long one
I’m trying to have my company adopt passbolt, but I struggle a little with the (good) question of my CISO asking how we’ll manage users keys rotation when compromised, and on the long term for an evergreen system (RSA to ECC to the next gen…).
I fear it will be a show stopper if the actual solution is the one above
In the Debian package, you can set PASSBOLT_PLUGINS_USER_KEY_POLICIES_PREFERRED_KEY_CURVE in the passbolt.php config or via systemd environment overrides, but this only affects new user key generation. Existing RSA keys cannot be rotated automatically to ECC — the current workaround is to create new user profiles, migrate secrets, and retire the old accounts. This limitation makes large‑scale rotation difficult, and while ECC is supported for new users, there’s no native assisted migration yet. For now, documenting the manual process is the only option until Passbolt introduces proper key rotation support.
For new users, since last summer ECC keys are already the default type.
for the passbolt.php inside
return [
// ... rest of the conf
'passbolt' => [
// ... rest of the conf
'plugins' => [
'userKeyPolicies' => [
'enabled' => true,
'preferred_key_type' => 'curve',
'preferred_key_curve' => 'p384',
],
// ... rest of the plugins
],
],
As for the user key rotation, this is something that we want to do but there is a lot of hedge cases to take into consideration since you need to re-encrypt all the secret with the new key, plenty of things can go wrong during that time so it needs proper analysis. The current big focus of the team is toward the offline mode that gonna come.
Potential (tedious) workaround is indeed to:
mark all the groups the user has access
share with a temp account or group user’s private passwords