Daniel Lenski

> Can you share a bit more about what you're trying to accomplish? I'm writing an application for auditing different kinds of keys, so it really wants to be able...

> Generally speaking, the approach we'd suggest for this is to use the key interfaces to check key types: > https://cryptography.io/en/latest/hazmat/primitives/asymmetric/serialization/#module-cryptography.hazmat.primitives.serialization Perhaps I'm missing something, but the key dumping methods...

> The relevant point there is the example that uses the interface to test key types. I imagine that many developers, like me, use pyca/cryptography to load asymmetric keys of...

The way that `HostKeyTest` is written currently, it will only test for key types in its own internal allowlist (`HostKeyTest.HOST_KEY_TYPES`): https://github.com/jtesta/ssh-audit/blob/574a53d88ef81a47fe41911acbe8557ef4e35612/src/ssh_audit/hostkeytest.py#L118-L129 A more universal and future-proof way to handle this...

@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.

> Are ed448 keys documented by OpenSSH? ssh-keygen -ted448 doesn't appear to work. @alex, they are not supported by OpenSSH, as I write in the commit message: `The 'ssh-ed448' key...

The [flake8 failure here](https://github.com/pyca/cryptography/actions/runs/9951346163/job/27490679803?pr=11249#step:14:65) seems to be due to it objecting to the preexisting sort order of an `import` block. 🤷🏻‍♂️

> Are you sure you don’t just need to put ed448 before ed25519 in the imports? Apparently so. I had no idea that numeric substrings in module names get sorted...

In addition to aligning the docs with the code, this fix is needed to be able to construct a `CertStreamClient` object with an error handler that actually has access to...