Closed dlenskiSB closed 2 months ago
The way that HostKeyTest
is written currently, it will only test for key types in its own internal allowlist (HostKeyTest.HOST_KEY_TYPES
):
A more universal and future-proof way to handle this would be to simply test for every key type that the server claims to support (for host_key_type in server_kex.key_algorithms:
), rather than maintaining this allowlist. The special cases (currently to prevent unnecessary re-querying for repeated RSA keys, could be extended to ECDSA as well) could still be kept in the loop:
@jtesta would you be receptive to such a change?
As with RSA, it is possible for DSA keys to be of variable length (not just 1024 bits)
The DSA algorithm can indeed use variable moduli, though the DSS standard is defined at exactly 1024 bits only. So using, say, a 3072-bit modulus would be possible, but wouldn't be considered DSS anymore. That said, I've seen a non-standard algorithm out in the wild called dsa2048
...
A more universal and future-proof way to handle this would be to [...] @jtesta would you be receptive to such a change?
Sure.
Thanks for this PR!
Btw, aren't DSA keys currently discouraged?
@perkelix wrote:
Btw, aren't DSA keys currently discouraged?
Yes, indeed. Which is exactly why a tool for finding and cataloging them should be able to extract them.
Their certificate-embedded counterparts are enabled as well.
As with RSA, it is possible for DSA keys to be of variable length (not just 1024 bits), so I've added
{'variable_key_len': True}
to the relevantHOST_KEY_TYPES
entries, although this key-value pair is otherwise unused.