diff options
author | Ian Jackson <ijackson@chiark.greenend.org.uk> | 2023-11-15 22:38:38 +0000 |
---|---|---|
committer | Ian Jackson <ijackson@chiark.greenend.org.uk> | 2023-11-15 22:55:44 +0000 |
commit | eb2c1296df4bfed89cef83aefdf67d8d86fe7aa7 (patch) | |
tree | dbac1a0b27cd4793827b4fcfb367491bb3675b17 /spec | |
parent | 47f0aeb42f63108efdbee3f942e4fd13bfdcb9a5 (diff) | |
download | torspec-eb2c1296df4bfed89cef83aefdf67d8d86fe7aa7.tar.gz torspec-eb2c1296df4bfed89cef83aefdf67d8d86fe7aa7.zip |
ssh-protocols: Write what we discovered about upstream key formats
Diffstat (limited to 'spec')
-rw-r--r-- | spec/ssh-protocols.md | 32 |
1 files changed, 29 insertions, 3 deletions
diff --git a/spec/ssh-protocols.md b/spec/ssh-protocols.md index 0f06d09..d1268cb 100644 --- a/spec/ssh-protocols.md +++ b/spec/ssh-protocols.md @@ -103,6 +103,17 @@ as per [RFC4253 6.6](https://datatracker.ietf.org/doc/html/rfc4253#section-6.6) (under "Certificates and public keys are encoded as follows"). +So the overall format of this part of the file is: + +``` + uint32 number of keys, N + string publickey1, where the contained binary data is: + string public key algorithm name (RFC4250 table 4.11.3) + byte[] public key data (algorithm-specific) + ... keys 2 to N-1 inclusive, each as for publickey1 ... + string publickeyN (as for publickey1) +``` + ### Encoding of the private key data OpenSSH `PROTOCOL.key` defines @@ -120,11 +131,26 @@ So we document our understanding here. The contents of each `privatekey1`/`privatekey2`/`privatekeyN` is: ``` -string Public key algorithm (RFC4250 4.11.3) -string Public key data (algorithm-specific encoding) -string Private key data (algorithm-specific encoding) + string public key algorithm name (RFC4250 table 4.11.3) + byte[] public key data (algorithm-specific) + byte[] private key data (algorithm-specific) ``` +> Note that this depends on the reader knowing the public key algorithm. +> The public key data must be self-delimiting, +> since the file format doesn't provide a separate length field. +> Although here we discuss only algorithms whose +> public key data, and private key data, +> are each a single `string`, that is not always the case: +> for example, +> the `ssh-rsa` algorithm's key data formats are sequences of `mpint`s +> without any surrounding overall length. +> +> Note also that the encrypted section does not separately state +> the number of keys or their total length. +> The reader must keep reading until it encounters either the end, +> or something that looks like padding (starting with a byte 0x01). + ### `x25519@spec.torproject.org` These refer to keys for |