Support loading Ed448 public keys in OpenSSH format

[dlenskiSB]

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] github/putty@a085acb
[4] jtesta/ssh-audit#277

[dlenskiSB]

I think it's quite likely that Ed448 private keys for OpenSSH would (will?) have a format very similar to Ed25519 private keys (e.g.

cryptography/tests/hazmat/primitives/test_ssh.py

Lines 520 to 530 in d3eda71

	sk = b"x" * 32
	pk1 = b"y" * 32
	pk2 = b"z" * 32
	data = self.make_file(
	pub_type=b"ssh-ed25519",
	pub_fields=(pk1,),
	priv_fields=(
	pk1,
	sk + pk2,
	),
	)

), but since I haven't seen any real-world examples of private keys in OpenSSH format, and since the Ed25519 format is weirdly redundant in terms of its repetition of private and public key parts… I'm reluctant to make any assumptions about it here.

[dlenskiSB]

On the other hand, from github/putty@a085acb …

since the OpenSSH agent protocol is the de facto
standard … OpenSSH themselves get to
say what the format for a key should or shouldn't be. So if they don't
support a particular key method, what do you do?

I checked with them, 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.

So we could follow suit and support an OpenSSH-like Ed448 private key format just as Putty does.

[alex]

Are ed448 keys documented by OpenSSH? ssh-keygen -ted448 doesn't appear to work.

[dlenskiSB]

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+)

[dlenskiSB]

The flake8 failure here seems to be due to it objecting to the preexisting sort order of an import block. 🤷🏻‍♂️

[reaperhulk]

Are you sure you don’t just need to put ed448 before ed25519 in the imports?

[dlenskiSB]

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 😵
PyCQA/isort#1732 (comment)

[reaperhulk]

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

[alex]

Were you interested in continuing to work on this? We're happy to review once tests are passing.