1

I wrote an openssh-key-v1 Protocol reader and extracted all fields according to the format definition:

 "openssh-key-v1"0x00    # NULL-terminated "Auth Magic" string
 32-bit length, "none"   # ciphername length and string
 32-bit length, "none"   # kdfname length and string
 32-bit length, nil      # kdf (0 length, no kdf)
 32-bit 0x01             # number of keys, hard-coded to 1 (no length)
 32-bit length, sshpub   # public key in ssh format
     32-bit length, keytype
     32-bit length, pub0
     32-bit length, pub1
 32-bit length for rnd+prv+comment+pad
     64-bit dummy checksum?  # a random 32-bit int, repeated
     32-bit length, keytype  # the private key (including public)
     32-bit length, pub0     # Public Key parts
     32-bit length, pub1
     32-bit length, prv0     # Private Key parts
     ...                     # (number varies by type)
     32-bit length, comment  # comment string
     padding bytes 0x010203  # pad to blocksize

After that is done I stucked with a 64byte uint8 list that somehow needs to be converted into a 32bit 32 byte ed25519 binary private key. I could not find a definition on how to do that.

The only hint I got is that the private key is encoded according to RFC 4253 SSH Public Key format and RSA private keys swap e and n for n and e.

I assume that I have this:

[32-bit length] [RSA exponent or EC type name]
[32-bit length] [RSA modulus or EC x+y pair]

Do I need to calculate the seed on my own now? Is the second 32byte my seed?

Improve this question
3
  • OP, I took the liberty of editing your post, to change *32 bit* ed25519 binary private key to *32 byte* ed25519 binary private key. ed25519 is EC crypto, so the private key should be 256 bits (or 32 bytes). WRT your reference to RFC4253, I'm not sure this applies, because this pertains to RSA keys, and you are dealing with EC keys, which are totally different. RSA private keys contain two large prime numbers, whereas EC keys are just one large random 256-bit number.
    – mti2935
    Feb 19, 2021 at 16:40
  • @mti2935 thanks for editing my error! The problem is that openssh can store ed25519 keys aka EC keys. The file format also has a 64byte for them. This link (coolaj86.com/articles/the-ssh-public-key-format) has a description to the EC key encoding. I just dont understand it.
    – Richard Burkhardt
    Feb 19, 2021 at 17:03
  • Richard: BTW that page you link talks briefly about the point encoding for ECDSA publickey, which was originally defined by ANSI X9.62/63 (and SECG SEC1) and is used and documented many other places such as PKIX certificates (rfc3279 and rfc5480), XMLdsig, PKCS11. However Ed25519 is an instance of EdDSA, which is elliptic-curve signature but NOT ECDSA and uses a different publickey point encoding, defined I believe in some of Bernstein et al's papers but more conveniently available in rfc8032. But the OpenSSH encoding of the privatekey does not follow any standard AFAICT.
    – dave_thompson_085
    Jan 17 at 6:16

1 Answer 1

Reset to default
1

In an OpenSSH 'new format' keyfile (as also in the SSHv2 protocol) the number of values, each with 4-byte length, after the 'type' (formally algorithm-name) in a publickey is (fix!) NOT always 2 but (like the privatekey) it varies depending on algorithm: 2 for RSA and ECDSA, 4 for DSA, 1 for Ed25519.

For Ed25519, the privatekey (after the name) has 2 length-prefixed values: the first is a copy of the publickey (32 bytes), and the second is what is labelled the 'secret' (private) key in the code, but actually is 64 bytes of which the first 32 bytes are the actual private key and the second 32 bytes are yet another copy of the public key!

Compare https://unix.stackexchange.com/questions/466179/show-values-of-an-ed22519-private-key-stored-in-openssh-format .

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.