English French Actions
a key used by the client (resp. server) to encrypt the data that it sends
a key used by the client (resp. server) to authenticate the data that it sends
a key used by the client (resp. server) to initialize the negotiated encryption scheme (if required by this scheme)
It is common practice among designers of security protocols to never use the same key for different purposes. For example, allowing the client and the server to use the same key to encrypt data could enable an attacker to launch a replay attack by sending to the client data that it has itself encrypted.
At this point, all the messages sent over the TCP connection will be encrypted with the negotiated keys. The ``ssh`` protocol uses messages that are encoded according to the Binary Packet Protocol defined in :rfc:`4253`. Each of these messages contains the following information :
``length`` : this is the length of the message in bytes, excluding the MAC and length fields
``padding length`` : this is the number of random bytes that have been added at the end of the message.
``payload`` : the data (after optional compression) passed by the user
``padding`` : random bytes added in each message (at least four) to ensure that the message length is a multiple of the block size used by the negotiated encryption algorithm
``MAC`` : this field is present if a Message Authentication Code has been negotiated for the session (in practice, using ``ssh`` without authentication is risky and this field should always be present). Note that to compute the MAC, an ``ssh`` implementation must maintain a message counter. This counter is incremented by one every time a message is sent and the MAC is computed with the negotiated authentication algorithm using the MAC key over the concatenation of the message counter and the cleartext message. The message counter is not transmitted, but the recipient can easily recover its value. The ``MAC`` is computed as :math:`mac = MAC(key, sequence\_number || unencrypted\_message)` where the key is the negotiated authentication key.
Authenticating messages with HMAC
`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.
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.
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.
The ``ssh`` protocol includes other features that are beyond the scope of this book. Additional details may be found in [BS2005]_.
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.
For example, :rfc:`4255` describes a DNS record that can be used to associate an ``ssh`` fingerprint to a DNS name.
The exact algorithms used for the computation of these keys are defined in :rfc:`4253`

Showing only subset of the strings as there were too many matches.

Component Translation Difference to current string
The following strings have the same context and source.
Propagated Translated cnp3-ebook/exercises/sockets Notes de pied de page
Propagated Translated cnp3-ebook/exercises/transport Notes de pied de page
Propagated Translated cnp3-ebook/principles/naming Notes de pied de page
Propagated Translated cnp3-ebook/principles/network Notes de pied de page
Propagated Translated cnp3-ebook/principles/referencemodels Notes de pied de page
Propagated Translated cnp3-ebook/protocols/dns Notes de pied de page
Propagated Translated cnp3-ebook/principles/security Notes de pied de page
Propagated Translated cnp3-ebook/exercises/dns Notes de pied de page
Propagated Translated cnp3-ebook/exercises/email Notes de pied de page
Propagated Translated cnp3-ebook/exercises/http Notes de pied de page
Propagated Translated cnp3-ebook/exercises/tcp-2 Notes de pied de page
Propagated Translated cnp3-ebook/exercises/tcp Notes de pied de page
Propagated Translated cnp3-ebook/exercises/tls Notes de pied de page
Propagated Empty cnp3-ebook/protocols/bgp
Propagated Empty cnp3-ebook/protocols/congestion
Propagated Empty cnp3-ebook/protocols/dnssec
Propagated Empty cnp3-ebook/protocols/email
Propagated Empty cnp3-ebook/protocols/ethernet
Propagated Empty cnp3-ebook/protocols/http
Propagated Empty cnp3-ebook/protocols/http2


User avatar None

New source string

cnp3-ebook / protocols/sshFrench

New source string a year ago
Browse all component changes

Things to check


This string has more than one translation in this project or is untranslated in some components.



English French
No related strings found in the glossary.

String information

Source string location
String age
a year ago
Source string age
a year ago
Translation file
locale/fr/LC_MESSAGES/protocols/ssh.po, string 38