New requirements for APT repository signing in 24.04

Foundations
1

In Ubuntu 24.04, APT will require repositories to be signed using one of the following public key algorithms:

  • RSA with at least 2048-bit keys
  • Ed25519
  • Ed448

This has been made possible thanks to recent work in GnuPG 2.4 by Werner Koch to allow us to specify a “public key algorithm assertion” in APT when calling the gpgv tool for verifying repositories.

As a first stage, warnings will be enabled for such repositories with apt 2.7.13. In a second stage, once all PPAs have been resigned, we will convert those to errors - protection as a default.

Why is this being done?

Previous releases trusted all algorithms trusted by GnuPG. 1024-bit RSA keys are widely considered unsafe, with government institutions such as NIST requiring the use of at least 2048 bits for at least 5 years now, but GnuPG and by extension APT was still trusting them.

This assertion also affects various additional eliptic curves such as the Brainpool family, secp256k1, and the NIST ECC family. These are already considered “unsafe” by the https://safecurves.cr.yp.to/ project, and we believe that RSA and the Ed family provides plenty of choices to repository owners, including being able to comply with FIPS requirements.

In the future we will extend the list of trusted algorithms as newer ones become available in GnuPG, and/or tighten the security requirements to align with best practice guidelines by NIST and other institutes.

FAQ

A PPA on Launchpad triggers a “weak algorithm” warning, what do I do?

PPAs are currently in the process of being upgraded to a 4096-bit RSA key and we expect that upgrade to be complete by release time. No action is needed (or possible) from PPA owners.

If you are currently using 24.04 before it is released, you will need to refresh the PPA signing keys when the warning becomes an error. We plan to provide easy functionality in add-apt-repository to do so, such that you do not need to remove and re-add the PPAs.

In the meantime, you may chose to ignore the warning or take it as a chance to reconsider which PPAs you have enabled.

A third-party repository triggers the “weak algorithm” warning, what do I do?

As a user, please contact your repository provider for further instructions.

For repository owners, our advice is to generate a new key and start dual-signing your repositories, including previous releases, and to only distribute the new key to users once you have dual signed.

There is no generic way to automatically rotate third-party repository signing keys. If you deliver signing keys in a .deb inside your repository, please generate a new key and update the package to include it before April. Then, remove the previous key from the package once you have started dual signing the repository.

This ensures that users will be able to re-enable your repository after an upgrade to 24.04.

How can I override this?

You can configure a different assertion using the apt.conf option APT::Key::Assert-Pubkey-Algo. The value in there is passed to gpgv --assert-pubkey-algo, consult its paragraph in the gpg(1) manual page for more information on how the string can be composed.

For example, you may want to specify >=rsa2048 to only allow RSA signing keys if your policy does not yet allow Ed25519 and Ed448 keys, or >=rsa2048,>=nistp256 to additionally also allow NIST elliptic curves.

11 Likes
3

Just to be clear, this upgrade does not require any special action from PPA owners, does it? Users, possibly, but do teams have to do anything special to get their PPA key upgraded?

4 Likes
4

Updated the post to clarify that no action is needed (or possible) from PPA owners.

4 Likes
5

Welp, 24.04 has been released, and I’m getting this:

W: https://ppa.launchpadcontent.net/alessandro-strada/ppa/ubuntu/dists/noble/InRelease: Signature by key 9EA4D6FCA5D37A5D1CA9C09AAD5F235DF639B041 uses weak algorithm (rsa1024)

So the upgrades that were supposed to be finished before 24.04 was released maybe weren’t finished?

I tried removing the repository and adding it back with apt-add-repository and that didn’t solve the problem.

1 Like
6

PPA updates are still ongoing, yes. There will be an announcement once all the noble PPAs are resigned and then an automation to migrate PPA keys before we can ship apt 2.8.0 which changes the warning to errors. Stay tuned!

3 Likes
7

Hi,

I have just received an enquiry from a user who has hit this warning / error message about nistp256. Please reconsider the security aspects of this change. Making everyone switch to Ed25519 creates work for people, but doesn’t increase cryptographic strength of the repository.

The warning message being printed by apt implies there’s a security vulnerability in nistp256 but there are no known cryptographic weaknesses in this algorithm. If you know of any, please publish a paper on it so cryptographers can learn something new. The SafeCurves page you link to is not claiming the algorithms are weak in the sense that e.g. SHA-1 was weak, or that these algorithms need to be phased out due to vulnerabilities. That site is authored by djb who also designed the Ed25519 algorithm and that’s why his site recommends Ed25519, but please ask djb (the author of that page) for more information if you disagree, and link him to this thread.

The SafeCurves criteria are about ease of implementation. “Safety” is meant here in the sense of like how Java is “safer” than C++. Newer elliptic curve algorithms are easier for library authors to implement without mistakes, but this doesn’t imply that the existing implementation of nistp256 used by apt actually is incorrect any more than apt being written in C++ implies it’s incorrect, and the SafeCurves criteria are therefore primarily of interest to cryptographers designing new generations of algorithms, not end users running apt. Implementations of nistp256 have to be fixed if they are buggy anyway because it’s widely used in TLS.

The primary thing Ed25519 makes easier for implementors to code correctly is side channel avoidance which doesn’t matter for signature verification at all because there are no secrets involved, so there’s no point in warning end users. The only people who could possibly benefit are people creating repositories, if you assume that maybe GPG has unknown vulnerabilities in it that will be discovered in future. But such hypothetical bugs would be threats to the people signing repositories, it’s not an actionable warning for end users.

2 Likes
8

This seems like a surprisingly large change to make in an LTS release after release, even if I’m largely onboard with trying to finally get rid of our RSA1024 PPA keys.

IMHO we can’t ship the enforcement on-by-default until 24.10. Offering it for interested 24.04 LTS users makes sense.

Thanks

2 Likes
9

The way I see it, RSA 1024 will be considered completely broken by the time Noble is out of (extended) support. And when that happens, a security update will disable RSA 1024. This is something that will happen during Noble lifetime; this simply does it more warning than a security update.

10

@mchearn It seems very few people use P-* curves for APT repository. Could you explain your constraints a bit so that we understand them better?

11

@adrien My company makes software that produces apt repositories. These are signed with P-curves, which is a good choice of algorithm (been around a long time, well supported, secure etc).

Because this is used by a lot of scattered apt repositories, there isn’t one action we can take to make them all use a different algorithm. We’d have to release a new version of our software, get everyone to upgrade and rebuild their repos, etc.

But there’s no need for any of that because the P-curves work fine.

12

Two months into the 24.04 Noble era, still I’m getting this warning for my yktooo PPA:

$ sudo add-apt-repository -P yktooo
Repository: 'Types: deb
URIs: https://ppa.launchpadcontent.net/yktooo/ppa/ubuntu/
Suites: noble
Components: main
[...]
Reading package lists... Done
W: https://ppa.launchpadcontent.net/yktooo/ppa/ubuntu/dists/noble/InRelease: Signature by key 435871A89FE2304D43254F3866EFE2D582CE5D8A uses weak algorithm (rsa1024)

Does anyone have any update on the progress/ETA for the rsa4096 upgrade?

13

The resigning is in progress and we expect to complete it and toggle the warnings to errors after that, before the point release in August.

I’ve asked various people if we should change the approach taken in the prepared update for noble that turns the warnings to errors, I had the idea that we would instead check that we never downgrade your security level (which is a bit involved), and while that would reduce the regression potential (in that repositories that issue warnings will continue to work until they are fixed on both server and client), it is understandable that it was not well received so far because it adds a lot of complexity and undermines our strong position on security.

14

So let’s talk about the NIST curves in this application. There’s two particular problems:

  • NIST curves are widely assumed to have been purposefully constructed in a weak manner. I don’t think that would be news for you? That’s the whole reason everyone went for Ed25519 and why they basically have zero adoption.
  • GnuPG has sloppy code quality. There are a lot of places in the code where security critical bits are not checked (i.e. parameters you give it that specify signing constraints are silently ignored if you don’t happen to use the specific mode you are in, the whole mechanism here would assume ed25519 is stronger than ed448 because it considers any trailing number the key size, etc.).
  • Given the former point, and your acknowledgement that NIST curves are hard to implement correctly, that seems a troublesome combination.

So personally, I don’t think we should weaken our security stance here, and I also can’t validate your claims that you actually make that software or that anyone actually uses it, or how many thousands of users are affected by it.

In the end, a new version of a distribution will always break something for someone, and it’s a matter of weighing whether the advantages justify breaking a small number of users.

In fact, the whole thing is a compromise, I initially planned to also drop RSA below 3072. But it turned out there were too many third parties still using 2048 bit keys, despite (non-US) governments already considering that insecure…

15

The NIST curves are widely adopted and still being adopted today. It isn’t the case that they have basically zero adoption and it’d be interesting to find out what sources are saying that. For example, LetsEncrypt is right now introducing new intermediate and root certificates. They are signed with ECDSA using the P-384 curve which is a NIST curve: https://letsencrypt.org/2024/03/19/new-intermediate-certificates

This is happening because cryptographers don’t accept that the curves are weak. I definitely know why some people think that, and I’ve argued that we should move beyond them in the past myself just in case, but I think you’ll find if you ask professional cryptographers about it they all tell you they disagree. That’s definitely been my experience. They point out that there are no known mathematical weaknesses in the scheme after many decades of research, and no known way anyone could have back-doored them. For that reason I don’t know of any cases where anyone has migrated to Ed25519 due to such beliefs.

Now you could say, OK, well, I don’t agree with the cryptographers and think everyone should use a different curve anyway. That’s fine, but it’s analogous to saying everything should be rewritten in Rust. A perfectly reasonable opinion to hold but you’d need to convince the creators of software, not the users. The users can’t do anything, so showing them a warning because libstdc++ is a dependency of a package is of no use; the warning isn’t actionable and developers would just get annoyed that you’re claiming their software is vulnerable when you have no specific reason to think that.

So if you do want to migrate to a different algorithm then the right place to do that is by changing defaults in how repositories are generated, whilst allowing the client to accept any algorithm that isn’t known to be broken. This lets you shift your views over time without disrupting anyone else in the ecosystem.

W.R.T. validating the claim of making software: take a look at https://www.hydraulic.dev/ - but also, why would I come here and be on this thread if I didn’t?

W.R.T. GPG having bad code - if you don’t trust it by all means migrate apt away from using it. GPG has lots of code that isn’t related to the specific elliptic curve in use. But again that’s not something actionable by your/our users.

16

Regarding the how to deprecate stuff:

Our only way to communicate with repository providers is by adding warnings to the client, such that users can then complain to their repository providers, there aren’t any means for us to contact all of them.

Generally this isn’t a significant concern for stable release users, because people can just fix their repositories before adding support for a new stable series, and it should only affect people running the development series.

This development cycle this was problematic of course, the development release only became testable in late March due to first the time_t transition and second the xz-utils measures. So you had

  • three months to adjust to weak RSA going away if you track ubuntu-devel
  • two months to adjust to all key signing requirements if you track discourse
  • only one month of warnings

Usually this is more ordered and you get warnings in one LTS and errors in a following interim release, but we’re in a bit of a tight spot here with 1024-bit RSA.

Good news is that going forward we are able to at first stuff these warnings behind a --audit flag in a new “audit” level; such that repository providers can validate their repositories ahead of changes landing to users in a development release.

Eventually they will get promoted to higher levels of course, going through possibly stages of notice, warning, error. From an Ubuntu side, the goal usually is to have warnings for one LTS before changing it to errors. So you can image an audit message is added in 25.10, gets promoted to warning in 26.04, and becomes an error in one of the releases between 26.10 and 28.04, inclusive.

Since it’s developed upstream in Debian, the same applies to Debian releases (which would be 1 year apart from LTS), so in practical terms, the example above would become an error by 27.10 to account for Debian freezes in spring-ish.

The concrete time line for when an audit message gets promoted will of course depend on the audit message itself. E.g. if we have guidelines that a key is not safe anymore in 2032, we can add an audit message now, and then promote it to a warning in 2030 (it would be in audit level for 6 years, plenty of time), such that we can have the error by 2032, generally I’d say we’d try to have an audit level for at least 6 months before promoting it.

As always success of that measure will depend on repository owners using it; I can only provide the feature but again, I don’t have a means to actually reach repository owners, they kind of need to figure it out on their own that it exists (exceptions being Google, Microsoft, and Keybase for self-use reasons).

Back on what we trust:

It’s a complicated story we don’t have a good solution for yet. Yesterday I wrote an OpenPGP keyring parser such that we can show you warnings about weak keys rather than weak signatures and strip out weak keys from the keyring we actually pass to gpgv because gpgv-sq from sequioa doesn’t implement the interface for weak signatures.

They tried but gave up because the interface is particularly ill-defined, e.g. >=ed448 matches ed25519, or any new ed<value over 448> people could come up with. Sloppy GnuPG :confused:

Ultimately though I may just resume the gpgv-sq fix too, the only gap left is to just silently ignore key names it doesn’t know about yet, more or less.

And yes we have planned a new signing scheme upstream https://wiki.debian.org/Teams/Apt/Spec/AptSign (it is a bit incomplete, some obfuscation needs to be added (reference primary key by fingerprint, and obfuscate the subkey by xoring it with the primary key ) to make it harder to write a bad implementation and some stuff reordered based on the last round of feedback) to get rid of OpenPGP altogether. It is scoped for apt signing, uses ed25519 and ed448 signatures like minisign/signify, with an additional new inline subkey schem (such that you can have an offline primary key, and rotate the subkey in-band, apt refuses to then go trust lower numbered subkeys in future verifications of the same file). It was blocked on missing smartcard support, but I believe we have both OpenPGP smartcard support and YubiKey support for at least Ed25519 now which would be sufficient to move ahead (we only need YubiKey for the reference implementation, such that Debian can implement it, but of course it’s nice to enable more hardware tokens).

The real big issue is going to be post-quantum signatures however. It’s a bit concerning we don’t yet have a clear standard we can build on.

As for NIST curves we’ll have to see what the agreement is before moving ahead with turning the warning into an error in 24.04.1. We certainly can re-enable them because we don’t want to needlessly break users in a point release.

That said I don’t see this changing upstream, I think this is the right story for Debian to embrace the community elliptic curve, and hence I don’t think there’s much point in keeping that as an Ubuntu-specific extension for 24.10 and later.

17

Thanks for reconsidering. Re-enabling them is the right path forward.

I don’t think there’s anything more community-ish about the Edwards curves than the NIST curves - they’re all the work of a very small number of people and NIST is at least a standards committee (albeit not a great one). They are both fully open to implementation by anyone.

Not fully sure what >=ed448 is meant to mean, but if GPG doesn’t distinguish then that’s probably because there’s no such thing as a weak elliptic curve signature algorithm at this point in time so they’re treated as equivalent. Whilst Ed448 has a higher security level than Ed25519 this is a purely theoretical distinction, as neither are computationally tractable with any currently known mathematics and so there’s no reason to use Ed448 and some reasons not to (longer keys). It’s not like RSA where smaller keys become weaker over time and have to be phased out. That’s one of the big advantages of ECC.

W.R.T. communication with repository owners. It’d be nice if apt collected contact emails from repositories that advertised them and sent them to you so you can communicate with those repo owners about more likely backwards incompatible changes (keyed to popcon or something like that).

The repositories we generate don’t have any stable/unstable distinction. They don’t need it. The binaries shipped are portable enough between distributions that it doesn’t matter.