[pbs-devel] [PATCH proxmox-backup 12/12] auth: us ec keys as auth keys

Stefan Sterz s.sterz at proxmox.com
Fri Feb 23 10:26:39 CET 2024


On Mon Feb 19, 2024 at 8:10 PM CET, Max Carrara wrote:
> On 2/15/24 16:20, Stefan Sterz wrote:
> > this commit moves new installations from our default rsa keys toward
> > smaller and more efficient ec keys. this uses the `PrivateKey` and
> > `PublicKey` structs from proxmox-auth-api to handle generating the
> > keys.
> >
> > this means we can move aways from using openssl directly in the
> > auth_helpers and instead rely on the implementation in
> > `proxmox-auth-api`. thus, further unifying key handling in
> > `proxmox-auth-api`. this should make it easier to switch keys in the
> > future if necessary.
> >
> > Signed-off-by: Stefan Sterz <s.sterz at proxmox.com>
> > ---
> > note that this breaks the following scenario:
> >
> > - a user installs pbs from a version after this patch was packaged
> > - proxmox-backup then creates a new ed25519 authkey
> > - the user manually forces a downgrade
> >
> > proxmox-backup-api and proxmox-backup-proxy will now fail to start as
> > they cannot read the, from their perspective, malformed authkey.
>
> Can we not ensure we remain forward-compatible here, too? I acknowledge
> that we probably shouldn't support this kind of scenario, but if we
> were to add support for ed25519 keys now (while continuing to use RSA)
> we wouldn't ever run into problems in that regard.
>
> Not sure if it actually makes sense to remain forward-compatible here,
> though.
>

well yeah we could do something like this, but where to we draw the
boundary? we don't support downgrades so which version should introduce
being able to load and handle ed25519 keys and which version should then
start generating such keys?

i can separate out the loading and generating part in the next version
of this series though, than we can apply them as we see fit.

also two notes:

1) such a downgrade scenario can easily be fixed by the admin by removing
   the authkey. proxmox-backup-api will then just generate a new one next
   time it is started with the old rsa format.

2) existing installations aren't impacted at all, as no new authkey will
   generated if one already exists. there is no mechanism that checks if
   the key is old/insecure/in-efficient or should be upgrade for other
   reasons. as long as a key exists, no new key is generated. pbs also
   lacks key-roll-over/key-rotation afaict, so yeah, once and authkey is
   generated, it is never modified by pbs itself.

-- >8 snip 8< --




More information about the pbs-devel mailing list