The docs explicitly recommend to not use the DSACryptoServiceProvider as there are
Newer asymmetric algorithms are available. Consider using the RSACryptoServiceProvider class instead of the DSACryptoServiceProvider class. Use DSACryptoServiceProvider only for compatibility with legacy applications and data.
What is wrong with DSA? Is it just the key size of 1024 and the SHA-1 hashing algorithm that for some reason cannot be exchanged in this specific implementation or is there some general constent that DSA should no longer be used? Why? I guess the discrete logarithm problem has not been solved efficiently, is it?
Is it just the key size of 1024 and the SHA-1 hashing algorithm that for some reason cannot be exchanged in this specific implementation
Sort of. There are two competing algorithms with the name DSA (or DSS if you prefer).
The first, described in FIPS 186-1 and FIPS 186-2 works on keys from 512 to 1024 bits with a step size of 64 bits and requires SHA-1.
The second, described in FIPS 186-3 and newer, works on keys of size 1024, 2048, and 3072 bits with “An approved hash function” (which basically means a SHA-2 function).
DSACryptoServiceProvider uses Windows CAPI, which only speaks the older version of DSA. DSACng uses Windows CNG, which speaks both versions. So DSACryptoServiceProvider cannot be upgraded (in .NET, because Windows says CAPI is maintenance-only and deprecated).
DSA in general has fallen out of favor. It’s slower than RSA and ECDSA, it has more “perfect or broken” states than RSA, and its key generation is several orders of magnitude slower than RSA and ECDSA.
Windows has decided that they do not, and “will not”, support X.509 certificates signed with a FIPS 186-3 DSA... the crypto libraries only have it for people who are forced to use it, effectively. (Apple Security.framework won’t allow DSA key generation, and can not validate FIPS 186-3 signatures, and Apple doesn’t do DSA certificates).