Packages are signed with RSA 1024 which is considered insecure

[kpcyrd]

Running add-apt-repository ppa:ondrej/php currently imports an 1024 bit RSA key into the apt keyring:

# apt-key list
/etc/apt/trusted.gpg.d/ondrej_ubuntu_php.gpg
--------------------------------------------
pub   rsa1024 2009-01-26 [SC]
      14AA 40EC 0831 7567 56D7  F66C 4F4E A0AA E526 7A6C
uid           [ unknown] Launchpad PPA for Ondřej Surý

/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-archive.gpg
------------------------------------------------------
pub   rsa4096 2012-05-11 [SC]
      790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32
uid           [ unknown] Ubuntu Archive Automatic Signing Key (2012) <[email protected]>

/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg
------------------------------------------------------
pub   rsa4096 2012-05-11 [SC]
      8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092
uid           [ unknown] Ubuntu CD Image Automatic Signing Key (2012) <[email protected]>

/etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg
------------------------------------------------------
pub   rsa4096 2018-09-17 [SC]
      F6EC B376 2474 EDA9 D21B  7022 8719 20D1 991B C93C
uid           [ unknown] Ubuntu Archive Automatic Signing Key (2018) <[email protected]>

# 

This is especially problematic because the ppa is added with an http mirror (without https, which has much higher standards for cryptographic primitives than gpg does), but also because this key is valid for all apt repositories on the system until explicitly removed.

According to the NIST document linked below, RSA 1024 is considered to have a security strength of <= 80 bits (5.6.1.1, page 67), they also state (5.6.1, page 65):

Note that a security strength of 80 bits is no longer considered adequate.

Debian itself prefers 4096 bits for RSA keys, or 2048 bits if constrained by smart card limitations. Please consider updating the key accordingly.

Thanks!

[1]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf [2]: https://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf [3]: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile [4]: https://www.ietf.org/rfc/rfc3766.txt

[oerdnj]

Yes, that's all true, but this is something controlled by Launchpad, see these bugs:

• https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1461834
• https://bugs.launchpad.net/launchpad/+bug/1331914

There's nothing I can do unless I move all the PPAs into a new Launchpad "team" which would disturb a lot of installations.

[C0rn3j]

Does the possible disruption really outweigh the ~~massive~~ security risk this is currently causing?

NIST has disallowed this for nearly a decade now.

https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/announcements/2013-announcements …modulus sizes less than or equal to 80 bits of security are disallowed and SHA1 is disallowed for Digital Signature Generation after 2013…

Would it not be a (albeit convoluted, thanks Canonical) solution(at least for this repo) to maintain two teams and instruct users who happen to bump into the old one to use the new one, and kill the old one after a few months?

[oerdnj]

Maybe, I'll think about it. I'll also poke the Canonical to fix this.

[oerdnj]

So, the question is whether it would be ok to make the repository change automatically by running appropriate commands from the maintainer scripts?