cryptography
cryptography copied to clipboard
pyca
Support loading Ed448 public keys in OpenSSH format
The 'ssh-ed448' key type is documented along with 'ssh-ed25519' in [1], but has never been supported by any as-yet-released version of OpenSSH.
However, LANcom router devices (which appear to be primarily used in Germany, see [2] for examples on the public Internet) appear to support these keys, so this library can and should support loading them.
Ed448 private keys are not yet implemented here, because OpenSSH itself does not yet support them, and it is the de facto authority for private key formats. However, PuTTY has already implemented support for generating and using Ed448 keys, and the PuTTY developers note in [3] that the OpenSSH developers are in agreement with them as to the correct Ed448 private key format:
I checked with them [OpenSSH developers], and they agreed that there's an obviously right format for Ed448 keys, which is to do them exactly like Ed25519 except that you have a 57-byte string everywhere Ed25519 had a 32-byte string. So I've done that.
See also [4] in which I extended ssh-audit to allow it to scan and discover host keys of type 'ssh-ed488'.
[1] https://datatracker.ietf.org/doc/html/rfc8709#name-public-key-format [2] https://www.shodan.io/search?query=ssh+%22ed448%22 [3] https://github.com/github/putty/commit/a085acbadf829ac5b426323ca98058d6aa4048ba [4] https://github.com/jtesta/ssh-audit/pull/277
Are ed448 keys documented by OpenSSH? ssh-keygen -ted448 doesn't appear to work.
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 type … has never been supported by any as-yet-released version of OpenSSH.
But their public key format is documented in RFC8709, alongside the very similar format for ssh-ed25519 keys which OpenSSH does support.
Although OpenSSH doesn't support Ed448 keys, other SSHv2-compatible software apparently does. (Including the widely-used Putty client, v0.75+)
The flake8 failure here 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?
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 like this, woah 😵 https://github.com/PyCQA/isort/issues/1732#issuecomment-846350228
I'm comfortable with merging public key parsing support (let's wait on private until we see user demand or it lands in a prominent server implementation). At the moment there are some missing lines of coverage though. You can see a visual report by downloading the html-report from the artifacts here: https://github.com/pyca/cryptography/actions/runs/9981453975?pr=11249
I am not sure this is safe at all, I tried doing so manually via openssl and ssh-keygen, it requires of OpenSC.
Were you interested in continuing to work on this? We're happy to review once tests are passing.
Closing due to lack of activity, but please reopen if you decide to rebase and finish this!