Bug 1199184 - switch Tumbleweed to a 4096bit RSA signing key
switch Tumbleweed to a 4096bit RSA signing key
Status: IN_PROGRESS
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P3 - Medium : Normal (vote)
: ---
Assigned To: Dominique Leuenberger
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-05-04 08:45 UTC by Marcus Meissner
Modified: 2022-08-10 11:40 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
openSUSE RSA 4096 key (1.65 KB, text/plain)
2022-08-10 09:16 UTC, Dirk Mueller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2022-05-04 08:45:26 UTC
We currently still use a 2048 bit key for signing.

It would be better to switch to a 4096 RSA key.
Comment 1 Fabian Vogt 2022-05-04 08:53:33 UTC
AFAIK 2048 bit RSA is still considered secure. What about switching to something like ECDSA/EdDSA?
Comment 2 Marcus Meissner 2022-05-04 08:57:08 UTC
Is still considered secure, but other distros use longer keys and e.g. Dirk Mueller already argues on why openSUSE does not switch.

I am not yet familar how much could break with switching to elliptic curves though.
Comment 3 Dirk Mueller 2022-05-04 09:14:35 UTC
(In reply to Marcus Meissner from comment #2)
> Is still considered secure, but other distros use longer keys and e.g. Dirk
> Mueller already argues on why openSUSE does not switch.

I'm not arguing, I was asking what needs to be done to implement a longer key for ALP. 

Based on factory first we should try to roll it out in openSUSE first and see the downsides before doing anything on SLE. 

From a brief look at  https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf 

it appears that RSA2048 is the acceptable minimum, and other distributions are chosing larger keys. 

I don't really care which cryptographic method we chose, so elliptic curve is totally fine by me as well. I don't know the implications of that very thorughly though, more expertise is needed.
Comment 4 Fabian Vogt 2022-05-04 09:55:20 UTC
Looks like EdDSA support landed in RPM in 2020 and it works on TW (with sha256 only, https://github.com/rpm-software-management/rpm/issues/1877 is missing). It doesn't work on Leap though, so either that would have to be backported (https://github.com/rpm-software-management/rpm/pull/1202 at least) or we'd have to deal with RSA a bit longer.

IMO it's better to keep RSA 2048 for a a bit longer and then switch to ECC directly instead of switching to RSA 4096 now (and maybe switch to ECC in the future).
Comment 5 Marcus Meissner 2022-05-04 13:16:27 UTC
I filed an OBS ticket to make signing keytypes configurable via api calls, as currently OBS API would only creating 2048bit RSA keys.

https://jira.suse.com/browse/OBS-193
Comment 6 Stefan Seyfried 2022-06-09 05:33:17 UTC
Is there also a github issue or such that I could watch for the OBS implementation discussion?
(I want to change to a longer key in a private OBS instance and would hope that this discussion helps me achieve that seamlessly ;-))
Comment 8 Adrian Schröter 2022-08-10 08:37:40 UTC
just for the record, the pull request is for changing OBS defaults, but for tumbleweed it is a config setting we can do at any time.
Comment 9 Dirk Mueller 2022-08-10 09:16:57 UTC
Created attachment 860726 [details]
openSUSE RSA 4096 key

This is the new key that was created a few weeks back by Ruediger Oertel. Rudi can you confirm that this is the right key and that we have established backups etc?
Comment 10 Ludwig Nussel 2022-08-10 09:26:06 UTC
Only one? While we are at it there would be the chance to have a second one that only exists offline and is stored away in a safe for emergencies. So far the SLE key serves as fallback which is a) odd and b) also seems to be only rsa2048.
Comment 11 Ruediger Oertel 2022-08-10 10:25:00 UTC
> Rudi can you confirm that this is the right key and that we have established backups etc?

yes, 35A2F86E29B700A4 is the key created 20220620 and this is also in the encrypted backup and in the safe.

If a reserve key for openSUSE is needed we can of course create that, but maybe
it makes sense to wait a few more weeks until we have the needed infrastructure
working for ECC based keys (almost there but still fighting with a few performance issues when switching to current gpg versions).
Comment 12 Dirk Mueller 2022-08-10 11:40:17 UTC
pubkey update on its way to factory.