2. cnp3-ebook
3. protocols/ssh
4. English
5. Zen

33 ../../protocols/ssh.rst:246
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Authenticating messages with HMAC 33/10000 · 33
34 ../../protocols/ssh.rst:248
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `ssh` is one example of a protocol that uses Message Authentication Codes (MAC) to authenticates the messages that are sent. A naive implementation of such a MAC would be to simply use a hash function like SHA-1. However, such a construction would not be safe from a security viewpoint. Internet protocols usually rely on the HMAC construction defined in :rfc:`2104`. It works with any hash function (`H`) and a key (`K`). As an example, let us consider HMAC with the SHA-1 hash function. SHA-1 uses 20 bytes blocks and the block size will play an important role in the operation of HMAC. We first require the key to be as long as the block size. Since this key is the output of the key generation algorithm, this is one parameter of this algorithm. 749/10000 · 749
35 ../../protocols/ssh.rst:260
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — HMAC uses two padding strings : `ipad` (resp. `opad`) which is a string containing 20 times byte ``0x36`` (resp. byte ``0x5C``). The HMAC is then computed as :math:`H[K \oplus opad, H(K \oplus ipad, data) ]` where :math:`\oplus` denotes the bitwise XOR operation. This computation has been shown to be stronger than the naive :math:`H(K,data)` against some types of cryptographic attacks. 389/10000 · 389
36 ../../protocols/ssh.rst:269
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Among the various features of the ``ssh`` protocol, it is interesting to mention how users are authenticated by the server. The ``ssh`` protocol supports the classical username/password authentication (but both the username and the password are transmitted over the secure encrypted channel). In addition, ``ssh`` supports two authentication mechanisms that rely on public keys. To use the first one, each user needs to generate his/her own public/private key pair and store the public key on the server. To be authenticated, the user needs to sign a message containing his/her public key by using his/her private key. The server can easily verify the validity of the signature since it already knows the user's public key. The second authentication scheme is designed for hosts that trust each other. Each host has a public/private key pair and stores the public keys of the other hosts that it trusts. This is typically used in environments such as university labs where each user could access any of the available computers. If Alice has logged on ``computer1`` and wants to execute a command on ``computer2``, she can create an ``ssh`` session on this computer and type (again) her password. With the host-based authentication scheme, ``computer1`` signs a message with its private key to confirm that it has already authenticated Alice. ``computer2`` would then accept Alice's session without asking her credentials. 1421/10000 · 1421
37 ../../protocols/ssh.rst:290
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``ssh`` protocol includes other features that are beyond the scope of this book. Additional details may be found in [BS2005]_. 130/10000 · 130
38 ../../protocols/ssh.rst:295
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
39 ../../protocols/ssh.rst:296
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — For some of the algorithms, it is possible to negotiate the utilization of no algorithm. This happens frequently for the compression algorithm that is not always used. For this, both the client and the server must announce ``null`` in their ordered list of supported algorithms. 278/10000 · 278
40 ../../protocols/ssh.rst:302
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — For example, :rfc:`4255` describes a DNS record that can be used to associate an ``ssh`` fingerprint to a DNS name. 115/10000 · 115
41 ../../protocols/ssh.rst:305
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The exact algorithms used for the computation of these keys are defined in :rfc:`4253` 86/10000 · 86
The translation has come to an end.