summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--PROTOCOL6
-rw-r--r--PROTOCOL.chacha20poly13054
-rw-r--r--PROTOCOL.u2f4
3 files changed, 7 insertions, 7 deletions
diff --git a/PROTOCOL b/PROTOCOL
index f75c1c0ae..c702fca45 100644
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -194,7 +194,7 @@ layer 2 frames or layer 3 packets. It may take one of the following values:
194 SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */ 194 SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */
195 195
196The "tunnel unit number" specifies the remote interface number, or may 196The "tunnel unit number" specifies the remote interface number, or may
197be 0x7fffffff to allow the server to automatically chose an interface. A 197be 0x7fffffff to allow the server to automatically choose an interface. A
198server that is not willing to open a client-specified unit should refuse 198server that is not willing to open a client-specified unit should refuse
199the request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful 199the request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful
200open, the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS. 200open, the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS.
@@ -298,7 +298,7 @@ Upon receiving this message, a client should check which of the
298supplied host keys are present in known_hosts. 298supplied host keys are present in known_hosts.
299 299
300Note that the server may send key types that the client does not 300Note that the server may send key types that the client does not
301support. The client should disgregard such keys if they are received. 301support. The client should disregard such keys if they are received.
302 302
303If the client identifies any keys that are not present for the host, 303If the client identifies any keys that are not present for the host,
304it should send a "hostkeys-prove@openssh.com" message to request the 304it should send a "hostkeys-prove@openssh.com" message to request the
@@ -496,4 +496,4 @@ OpenSSH's connection multiplexing uses messages as described in
496PROTOCOL.mux over a Unix domain socket for communications between a 496PROTOCOL.mux over a Unix domain socket for communications between a
497master instance and later clients. 497master instance and later clients.
498 498
499$OpenBSD: PROTOCOL,v 1.36 2018/10/02 12:51:58 djm Exp $ 499$OpenBSD: PROTOCOL,v 1.37 2020/02/21 00:04:43 dtucker Exp $
diff --git a/PROTOCOL.chacha20poly1305 b/PROTOCOL.chacha20poly1305
index 9ce2a1e3a..0bfff28d7 100644
--- a/PROTOCOL.chacha20poly1305
+++ b/PROTOCOL.chacha20poly1305
@@ -34,7 +34,7 @@ Detailed Construction
34The chacha20-poly1305@openssh.com cipher requires 512 bits of key 34The chacha20-poly1305@openssh.com cipher requires 512 bits of key
35material as output from the SSH key exchange. This forms two 256 bit 35material as output from the SSH key exchange. This forms two 256 bit
36keys (K_1 and K_2), used by two separate instances of chacha20. 36keys (K_1 and K_2), used by two separate instances of chacha20.
37The first 256 bits consitute K_2 and the second 256 bits become 37The first 256 bits constitute K_2 and the second 256 bits become
38K_1. 38K_1.
39 39
40The instance keyed by K_1 is a stream cipher that is used only 40The instance keyed by K_1 is a stream cipher that is used only
@@ -103,5 +103,5 @@ References
103[3] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley 103[3] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley
104 http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03 104 http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
105 105
106$OpenBSD: PROTOCOL.chacha20poly1305,v 1.4 2018/04/10 00:10:49 djm Exp $ 106$OpenBSD: PROTOCOL.chacha20poly1305,v 1.5 2020/02/21 00:04:43 dtucker Exp $
107 107
diff --git a/PROTOCOL.u2f b/PROTOCOL.u2f
index 748111d56..459958701 100644
--- a/PROTOCOL.u2f
+++ b/PROTOCOL.u2f
@@ -142,7 +142,7 @@ choose not to include this information in the public key or save it by
142default. 142default.
143 143
144Attestation information is useful for out-of-band key and certificate 144Attestation information is useful for out-of-band key and certificate
145registration worksflows, e.g. proving to a CA that a key is backed 145registration workflows, e.g. proving to a CA that a key is backed
146by trusted hardware before it will issue a certificate. To support this 146by trusted hardware before it will issue a certificate. To support this
147case, OpenSSH optionally allows retaining the attestation information 147case, OpenSSH optionally allows retaining the attestation information
148at the time of key generation. It will take the following format: 148at the time of key generation. It will take the following format:
@@ -169,7 +169,7 @@ is signed over a blob that consists of:
169 byte[] extensions 169 byte[] extensions
170 byte[32] SHA256(message) 170 byte[32] SHA256(message)
171 171
172No extensons are yet defined for SSH use. If any are defined in the future, 172No extensions are yet defined for SSH use. If any are defined in the future,
173it will be possible to infer their presence from the contents of the "flags" 173it will be possible to infer their presence from the contents of the "flags"
174value. 174value.
175 175