search

Icinga / icinga-packaging

Packaging documentation and issues for the official Icinga repository
https://packages.icinga.com
44 stars 15 forks source link

Signature uses weak algorithm (dsa1024) #302

Closed jgraichen closed 3 months ago

jgraichen commented 4 months ago

Newer APT started warning about packages.icinga.com being signed with a DSA-1024 key:

W: https://packages.icinga.com/ubuntu/dists/icinga-noble/InRelease: 
   Signature by key F51A91A5EE001AA5D77D53C4C6E319C334410682 uses weak algorithm (dsa1024)

Using a DSA-1024 key for package signing might not be state of the art anymore. Maybe it is time to rotate to a newer signing key, such as ED25519.

Neither 1024-bit DSA nor SHA-1 are considered acceptable algorithms to provide an adequate level of security nowadays. 1024-bit DSA has a security strength of about 80 bits, and SHA-1 collisions can be created for USD 45,000. That means crafting a collision is within the realm of possibility of a reasonably well-paid software engineer, in addition to most companies and governments.

The present minimum level of security in most contexts is approximately 128 bits. To achieve that, you need a 256-bit elliptic curve key or a 3072-bit RSA or DSA key, and a 256-bit or longer hash should be used as well (in OpenPGP, that's SHA-2 or, soon, SHA-3).

DSA and ECDSA also have the downside that they require a random value for every signature, and if this value is ever reused for a different message, the entire private key is leaked. Most implementations use the technique described in RFC 6979 to avoid this, but these attacks are part of the reason why RSA and EdDSA are often used instead.

Note that GitHub is dropping support for DSA keys and new SHA-1 signatures in SSH, which is a different protocol, but with similar characteristics, as is OpenSSH. Debian no longer allows DSA keys or SHA-1 signatures for OpenPGP and APT will not accept SHA-1 hashes or signatures.

-- https://security.stackexchange.com/a/255562

Al2Klimov commented 4 months ago

Notes

So I'd go with RSA4096.

Al2Klimov commented 4 months ago

According to @dgoetz:

Al2Klimov commented 4 months ago

Notes

  • RHEL7 and SLES12.5's GPGs can generate up to RSA4096
  • The Debian 12 key is RSA4096

So I'd go with RSA4096.

... or! We "wait" 1/2 year while informing our users and pre-distributing the new key. Then the above distros will be EOL and we could use ED25519. Unless we wanna be nice to existing legacy infrastructures.

jgraichen commented 4 months ago

while informing our users and pre-distributing the new key.

Would this be a good chance to introduce an icinga-keyring package that installs a GPG keyring to /usr/share/keyrings/icinga-archive-keyring.gpg?

This could enable you to rotate keys without requiring user interaction, assuming they at least install package updates. A new key would first be distributed with the icinga-keyring package and later the repository signing key can be rotated.

Installing the repository as a user could be just downloading and installing the package instead of wget -O- ... | sudo gpg --dearmor -o .... The repo definition would always need to refer to /usr/share/keyrings/icinga-archive-keyring.gpg.

Examples:

  • RHEL7 and SLES12.5's GPGs can generate up to RSA4096
  • The Debian 12 key is RSA4096

Do you need support for ed25519 key generation or only verifying?

we could use ED25519.

:+1:

I do not know about RHEL or SLES, but I've been using ed25519 for APT repository signatures since Ubuntu 18.04 and Debian 9 or 10, as far as I remember.

jgraichen commented 4 months ago

One can't sign a package/index with >1 key

I've just learned that at least APT repositories can be signed with multiple keys, as is Debian doing:

root@debian:~# gpg --keyring /usr/share/keyrings/debian-archive-keyring.gpg \
                   --verify /var/lib/apt/lists/deb.debian.org_debian_dists_bookworm_InRelease 
gpg: Signature made Sat Feb 10 12:08:11 2024 CET
gpg:                using RSA key A7236886F3CCCAAD148A27F80E98404D386FA1D9
gpg: Good signature from "Debian Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org>" [unknown]
Primary key fingerprint: 1F89 983E 0081 FDE0 18F3  CC96 73A4 F27B 8DD4 7936
     Subkey fingerprint: A723 6886 F3CC CAAD 148A  27F8 0E98 404D 386F A1D9
gpg: Signature made Sat Feb 10 12:08:12 2024 CET
gpg:                using RSA key 4CB50190207B4758A3F73A796ED0E7B82643E131
gpg: Good signature from "Debian Archive Automatic Signing Key (12/bookworm) <ftpmaster@debian.org>" [unknown]
Primary key fingerprint: B8B8 0B5B 623E AB6A D877  5C45 B7C5 D7D6 3509 47F8
     Subkey fingerprint: 4CB5 0190 207B 4758 A3F7  3A79 6ED0 E7B8 2643 E131
gpg: Signature made Sat Feb 10 12:09:22 2024 CET
gpg:                using EDDSA key 4D64FEC119C2029067D6E791F8D2585B8783D481
gpg:                issuer "debian-release@lists.debian.org"
gpg: Good signature from "Debian Stable Release Key (12/bookworm) <debian-release@lists.debian.org>" [unknown]
Primary key fingerprint: 4D64 FEC1 19C2 0290 67D6  E791 F8D2 585B 8783 D481
Al2Klimov commented 4 months ago

Thank you for your input! Luckily, if you've added our repo like told on packages.icinga.com now, you're safe. The key is only referenced by our repo which uses HTTPS.

But yes, that warning by itself is pretty cowing.

Al2Klimov commented 4 months ago

Duplicate of #91