As the title says, new users are greeted with greyed-out boxes during registration on the advanced options for key type and key legnth. Ultimately, I’d like to allow user choices for the dropdowns, but would settle for allowing 4096 to appease ther the really paranoid types.
Centos7, Nginx 1.16.1, mariadb 5.5.64, php 7.3 - not docker.
Is key length and typ set during server install? Can I change it?
If its referred to here: https://help.passbolt.com/configure/environment/reference.html as passbolt_key_length pr passbolt_subkey_length, I’m unsure where to actually set that.
I was unable to find any reference to key_type.
Thanks,
Community support
People can vote for this idea to show traction:
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)
It is not possible at the moment to allow changing this option. The default choice is optimized to balance security and performance.
For the really paranoid types, it is possible to create an OpenPGP from another software and import it. Please notes that other algorithm than RSA (ECC, etc.) are not supported by the API (there is the possibility to implement your own GPG backend, but well, it’s not trivial).
The PASSBOLT_KEY_LENGTH variables and others refers to the length of the server key (not the end user one).
Sorry to resurrect this thread. Hoping to see if there has been any progress or further consideration given to this idea.
I get that RSA is the default and “acceptable” but it is quickly becoming less and less of a standard and the general technology community seems to be coming to a consensus that ed25519 is the current best key type for both performance and security. Unfortunately most of the material I can find on the subject is usually pertaining to SSH specifically but I see no reason to believe the benefits would not extend to gpg.
Sources (I was going to include more but I’m a n00b and can only share 2 links): gitlab google result
Also, what happens if RSA is suddenly declared insecure or pgp changes it’s official recommendation, passbolt would suddenly become a sub-optimal product. It would be nice to see passbolt support the latest security tools proactively.
Between this post and the one remy links above there’s almost 1k views and it would probably have more votes if there was actually a poll on the other topic which still appears in many google search results (as you can tell from the views).
Hopefully there’s been some progress happening anyway but wanted to bump this if not.
There are some clear advantages as you mentioned, like speed and decreased key / message size that would really benefits to all passbolt users. Some of the libraries we use, such as OpenPGP.js supports it (and even makes it the default now afaik), so in theory it should be possible to add support. Products like mailvelope enable ed25519/ cv25519 as “experimental” flag, so we could potentially do this.
However there are some disadvantages to consider:
If the OpenPGP proposal changes last minute, we will be in a messy situation.
Even with experimental flag on, the users will expect supports, upgrade path, etc. creating overhead for the team.
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)