• [^] # Re: Éléments de réponse

    Posté par . En réponse au message ssh et chiffrement symétrique. Évalué à 6.

    c'est une documentation sur SSH, à laquelle j'ai participé d'ailleurs.

    Il me semble que cette partie n’est pas correcte :

    Le client génère une clef secrète et l'envoie au serveur, en chiffrant l'échange avec la clef publique du serveur [...] Une fois la clef secrète échangée, le client et le serveur peuvent alors établir un canal sécurisé grâce à la clef secrète commune

    Cela sous-entend que la paire de clefs asymétriques du serveur est utilisé à la fois pour authentifier le serveur auprès du client, et pour chiffrer la clef de session (symétrique).

    Je ne crois pas que ça se passe ainsi. La paire de clefs asymétriques est utilisé pour l’authentification uniquement. Une fois le serveur authentifié, le serveur et le client procèdent à un échange Diffie-Hellman pour obtenir tous les deux la clef de session symétrique ; cet échange n’implique pas la paire de clefs asymétriques du serveur.

    C’est un détail qui a son importance, car cela implique qu’une éventuelle compromission ultérieure de la clef privée du serveur ne permettra pas de déchiffrer les clefs de session et donc de revenir déchiffrer le traffic enregistré (alors que ce serait possible si les clefs de session étaient directement chiffrées avec la clef publique du serveur).

    En revanche, pendant que tu es connecté par SSH quelque part, elle reste la même. À moins qu'il n'y ait un mécanisme de renégociation, je n'ai pas vérifié.

    Oui, un tel mécanisme existe. Le RFC 4253 suggère une telle re-négociation chaque fois qu’un giga-octets de données a été transféré, ou après chaque heure écoulée. Dans OpenSSH, ça se configure avec l’option RekeyLimit.