diff options
| -rw-r--r-- | PROTOCOL | 6 | ||||
| -rw-r--r-- | PROTOCOL.chacha20poly1305 | 4 | ||||
| -rw-r--r-- | PROTOCOL.u2f | 4 |
3 files changed, 7 insertions, 7 deletions
@@ -194,7 +194,7 @@ layer 2 frames or layer 3 packets. It may take one of the following values: SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */ The "tunnel unit number" specifies the remote interface number, or may -be 0x7fffffff to allow the server to automatically chose an interface. A +be 0x7fffffff to allow the server to automatically choose an interface. A server that is not willing to open a client-specified unit should refuse the request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful open, 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 supplied host keys are present in known_hosts. Note that the server may send key types that the client does not -support. The client should disgregard such keys if they are received. +support. The client should disregard such keys if they are received. If the client identifies any keys that are not present for the host, it should send a "hostkeys-prove@openssh.com" message to request the @@ -496,4 +496,4 @@ OpenSSH's connection multiplexing uses messages as described in PROTOCOL.mux over a Unix domain socket for communications between a master instance and later clients. -$OpenBSD: PROTOCOL,v 1.36 2018/10/02 12:51:58 djm Exp $ +$OpenBSD: PROTOCOL,v 1.37 2020/02/21 00:04:43 dtucker Exp $ diff --git a/PROTOCOL.chacha20poly1305 b/PROTOCOL.chacha20poly1305 index 9ce2a1e3..0bfff28d 100644 --- a/PROTOCOL.chacha20poly1305 +++ b/PROTOCOL.chacha20poly1305 @@ -34,7 +34,7 @@ Detailed Construction The chacha20-poly1305@openssh.com cipher requires 512 bits of key material as output from the SSH key exchange. This forms two 256 bit keys (K_1 and K_2), used by two separate instances of chacha20. -The first 256 bits consitute K_2 and the second 256 bits become +The first 256 bits constitute K_2 and the second 256 bits become K_1. The instance keyed by K_1 is a stream cipher that is used only @@ -103,5 +103,5 @@ References [3] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03 -$OpenBSD: PROTOCOL.chacha20poly1305,v 1.4 2018/04/10 00:10:49 djm Exp $ +$OpenBSD: PROTOCOL.chacha20poly1305,v 1.5 2020/02/21 00:04:43 dtucker Exp $ diff --git a/PROTOCOL.u2f b/PROTOCOL.u2f index 748111d5..45995870 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 default. Attestation information is useful for out-of-band key and certificate -registration worksflows, e.g. proving to a CA that a key is backed +registration workflows, e.g. proving to a CA that a key is backed by trusted hardware before it will issue a certificate. To support this case, OpenSSH optionally allows retaining the attestation information at the time of key generation. It will take the following format: @@ -169,7 +169,7 @@ is signed over a blob that consists of: byte[] extensions byte[32] SHA256(message) -No extensons are yet defined for SSH use. If any are defined in the future, +No extensions are yet defined for SSH use. If any are defined in the future, it will be possible to infer their presence from the contents of the "flags" value. |