I recently found that the latest release of a major Linux distribution (MX Linux) uses DSA-1024 in /etc/apt/trusted.gpg and in /etc/apt/trusted.gpg.d/*.gpg

It also probably uses SHA-1 as the signature algorithm (which is the most common one used with DSA-1024)

Is using DSA-1024 safe, especially considering the fact that APT delivers packages & release files by plain HTTP and then verifies it with these signatures ?

What are the reasons and justifications for its security / insecurity ?

These are the keys :

$ sudo apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
pub   dsa1024 2005-10-29 [SC] [expired: 2011-01-22]
      1F5C 2E81 5EC2 9445 3B15  233C D3F9 85C5 1A77 B3E9
uid           [ expired] Warren Woodford (MEPIS Maintainers) <[email protected]>

pub   dsa1024 2004-09-12 [SC]
      6302 39CC 130E 1A7F D81A  27B1 4097 6EAF 437D 05B5
uid           [ unknown] Ubuntu Archive Automatic Signing Key <[email protected]>
sub   elg2048 2004-09-12 [E]

pub   dsa1024 2006-11-23 [SC]
      64D1 5ADA FA81 B2C5 619B  3297 2EBC 26B6 0C5A 2783
uid           [ unknown] The Medibuntu Team <[email protected]>
sub   elg2048 2006-11-23 [E]

pub   dsa1024 2004-12-30 [SC]
      C598 6B4F 1257 FFA8 6632  CBA7 4618 1433 FBB7 5451
uid           [ unknown] Ubuntu CD Image Automatic Signing Key <[email protected]>

pub   dsa1024 1999-10-03 [SC]
      1D7F C53F 80F8 52C1 88F4  ED0B 07DC 563D 1F41 B907
uid           [ unknown] Christian Marillat <[email protected]>
uid           [ unknown] Christian Marillat <[email protected]>
sub   elg1536 1999-10-03 [E]
sub   dsa1024 2002-08-26 [SCA]

pub   dsa1024 2007-02-07 [SC]
      64C3 6120 DA8D 91E7 378B  E79F 3916 C431 F809 94F6
uid           [ unknown] Stefan Lippers-Hollmann (sidux.com) <[email protected]>
sub   elg4096 2007-02-07 [E]

pub   dsa1024 2006-09-26 [SC] [expired: 2009-09-25]
      CD5A 9776 9F6E F4D9 EBCD  8F92 0334 3153 6A42 3791
uid           [ expired] Opera Software Archive Automatic Signing Key <[email protected]>

pub   dsa1024 2007-06-04 [SC]
      6947 BD50 026A E8C8 9AC4  09FD 390E C3FF 927C CC73
uid           [ unknown] innotek GmbH (archive signing key) <[email protected]>
sub   elg2048 2007-06-04 [E]

pub   dsa1024 2008-09-13 [SCA]
      B80B CDE3 19EE 84E0 A353  E7CF FEC8 20F4 B8C0 755A
uid           [ unknown] Adam Blackburn <[email protected]>
sub   elg2048 2008-09-13 [E]

pub   dsa1024 2008-07-14 [SC]
      AF45 1228 01DA D613 29EF  9570 DCF9 F87B 6DFB CBAE
uid           [ unknown] Sun Microsystems, Inc. (xVM VirtualBox archive signing key) <[email protected]>
sub   elg2048 2008-07-14 [E]

pub   dsa1024 2008-09-14 [SC] [expired: 2010-09-14]
      A949 B28F 7A96 8063 6CA3  36DE 81D4 980F A170 4726
uid           [ expired] Hendrik Rittich <[email protected]>

pub   dsa1024 2009-05-11 [SC]
      70C4 F178 C4AC 36D2 9A3B  52F0 3EFF 4F27 2FB2 CD80
uid           [ unknown] Steven Barrett <[email protected]>
sub   elg2048 2009-05-11 [E]

pub   dsa1024 2010-05-18 [SC]
      7B0F AB3A 13B9 0743 5925  D9C9 5442 2A4B 98AB 5139
uid           [ unknown] Oracle Corporation (VirtualBox archive signing key) <[email protected]>
sub   elg2048 2010-05-18 [E]

pub   dsa1024 2009-08-31 [SC] [expired: 2011-01-23]
      8526 E45F AF83 DE2F 634C  1909 F9A2 F76A 9D1A 0061
uid           [ expired] Opera Software Archive Automatic Signing Key 2010 <[email protected]>

pub   dsa1024 2011-01-22 [SC]
      565F 67CD 02BA 29CF 4F5D  5405 E6AD 81A8 B9FB E3CE
uid           [ unknown] Warren Woodford (MEPIS Maintainers) <[email protected]>
sub   elg1024 2011-01-22 [E]

pub   dsa1024 2010-11-08 [SCA]
      EA29 BBBE 6A41 95E6 EF3C  E709 A40E 385D 15B0 B570
uid           [ unknown] aurelien (Be Free!) <[email protected]>
sub   elg2048 2010-11-08 [E]

pub   dsa1024 2010-12-08 [SC] [expired: 2012-12-07]
      DB3D FC6C 82D3 D79B 4590  F276 0393 B863 8C00 FC18
uid           [ expired] Hendrik Rittich <[email protected]>

pub   rsa2048 2010-03-31 [SC]
      5929 601B 7779 956E 0117  749A 515F 1784 FFF0 6A93
uid           [ unknown] Dedinčanov archív balíkov (Debian APT repositary) <[email protected]>

pub   rsa1024 2012-03-11 [SC] [expired: 2013-03-11]
      255F 0237 51CF AA0F 3B78  F548 F4EA 6AF9 3465 FC9B
uid           [ expired] David deJong (Dave) <[email protected]>

pub   rsa2048 2012-04-14 [SC]
      48A9 B686 96FF FD91 ED9C  5AD8 8982 541D FD08 FE04
uid           [ unknown] antiX (this is for the antix repo) <[email protected]>
sub   rsa2048 2012-04-14 [E]

pub   dsa1024 2011-11-08 [SC] [expired: 2013-01-11]
      5C68 6B8F D30F A0E6 AB7E  6DAE AAFF 4A5B 3360 64B5
uid           [ expired] Opera Software Archive Automatic Signing Key 2012 <[email protected]>

pub   dsa1024 2009-12-11 [SCA]
      3289 E2A9 7822 F308 E660  30F0 7DCA C92F 09F8 ECEF
uid           [ unknown] aurele (Free your Gnu !) <[email protected]>
sub   elg2048 2009-12-11 [E]

pub   dsa2048 2013-05-25 [SC]
      D95E 9BC9 3D63 42FA 4843  805E 0CA3 2171 3B07 EE13
uid           [ unknown] MEPIS Community Repository (CR Signing key) <[email protected]>
sub   elg2048 2013-05-25 [E]

pub   dsa1024 2010-09-20 [SC] [expired: 2015-02-06]
      2920 868D C0F8 016A A35A  A0F8 E429 CCF8 6CE3 3D20
uid           [ expired] home:gottcode OBS Project <home:[email protected]>

pub   dsa2048 2014-01-21 [SCA] [expired: 2019-01-20]
      C8CF 3513 60C3 7394 5178  8AE5 81E7 7EAF 14E2 25A0
uid           [ expired] MX Community Repository <[email protected]>

pub   rsa2048 2013-03-13 [SC] [expires: 2024-04-25]
      ED57 48AC 0E57 5DD2 49A5  6B84 DB36 CDF3 452F 0C20
uid           [ unknown] antiX Linux repo <[email protected]>
sub   rsa2048 2013-03-13 [E] [expires: 2024-04-25]

pub   rsa4096 2021-01-17 [SC] [expires: 2029-01-15]
      1F89 983E 0081 FDE0 18F3  CC96 73A4 F27B 8DD4 7936
uid           [ unknown] Debian Archive Automatic Signing Key (11/bullseye) <[email protected]>
sub   rsa4096 2021-01-17 [S] [expires: 2029-01-15]

pub   rsa4096 2021-01-17 [SC] [expires: 2029-01-15]
      AC53 0D52 0F2F 3269 F5E9  8313 A484 4904 4AAD 5C5D
uid           [ unknown] Debian Security Archive Automatic Signing Key (11/bullseye) <[email protected]>
sub   rsa4096 2021-01-17 [S] [expires: 2029-01-15]

pub   rsa4096 2021-02-13 [SC] [expires: 2029-02-11]
      A428 5295 FC7B 1A81 6000  62A9 605C 66F0 0D6C 9793
uid           [ unknown] Debian Stable Release Key (11/bullseye) <[email protected]>

pub   rsa4096 2019-04-14 [SC] [expires: 2027-04-12]
      80D1 5823 B7FD 1561 F9F7  BCDD DC30 D7C2 3CBB ABEE
uid           [ unknown] Debian Archive Automatic Signing Key (10/buster) <[email protected]>
sub   rsa4096 2019-04-14 [S] [expires: 2027-04-12]

pub   rsa4096 2019-04-14 [SC] [expires: 2027-04-12]
      5E61 B217 265D A980 7A23  C5FF 4DFA B270 CAA9 6DFA
uid           [ unknown] Debian Security Archive Automatic Signing Key (10/buster) <[email protected]>
sub   rsa4096 2019-04-14 [S] [expires: 2027-04-12]

pub   rsa4096 2019-02-05 [SC] [expires: 2027-02-03]
      6D33 866E DD8F FA41 C014  3AED DCC9 EFBF 77E1 1517
uid           [ unknown] Debian Stable Release Key (10/buster) <[email protected]>

pub   rsa4096 2017-05-22 [SC] [expires: 2025-05-20]
      E1CF 20DD FFE4 B89E 8026  58F1 E0B1 1894 F66A EC98
uid           [ unknown] Debian Archive Automatic Signing Key (9/stretch) <[email protected]>
sub   rsa4096 2017-05-22 [S] [expires: 2025-05-20]

pub   rsa4096 2017-05-22 [SC] [expires: 2025-05-20]
      6ED6 F5CB 5FA6 FB2F 460A  E88E EDA0 D238 8AE2 2BA9
uid           [ unknown] Debian Security Archive Automatic Signing Key (9/stretch) <[email protected]>
sub   rsa4096 2017-05-22 [S] [expires: 2025-05-20]

pub   rsa4096 2017-05-20 [SC] [expires: 2025-05-18]
      067E 3C45 6BAE 240A CEE8  8F6F EF0F 382A 1A7B 6500
uid           [ unknown] Debian Stable Release Key (9/stretch) <[email protected]>

pub   rsa2048 2021-02-06 [SC]
      7854 EF6B F0E8 CC66 5736  4CF8 F942 E0D4 E1C7 26CD
uid           [ unknown] MX-21 Repository <[email protected]>
sub   rsa2048 2021-02-06 [E]

I found anther question regarding the safety of DSA ( Is the use of DSA keys a security risk? ) , but that one was from 8 years back. Computational power has grown a lot after that question was asked and so have security concerns and practices.

I had also pointed this out on the distro's forums, and no action was taken / planned to be taken. https://forum.mxlinux.org/viewtopic.php?f=6&t=66528

FYI: Ubuntu has removed DSA-1024 keys in 2016, as given in https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1363482


1 Answer 1


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.

Responsible parties either have already moved away from SHA-1 and DSA or are actively doing so. The alternatives are already well supported and have good performance characteristics, so there's really no excuse not to.

  • Can sufficiently funded malicious actors validly sign Release files and successfully deliver it to an MX Linux user ? If so, how can we convince the MX Team of this grave security vulnerability ? Commented Sep 26, 2021 at 4:24
  • Collisions allow a party to create multiple colliding messages. To create a message that is the same as an existing message you don't control, you need a preimage attack, which is not considered feasible. However, one should still not use SHA-1. As for the key size, it's probably small enough to be attacked by a dedicated and well-funded actor, in which case a government actor could forge messages.
    – bk2204
    Commented Sep 26, 2021 at 16:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .