Cela signifie donc que TLS, IPsec et la plupart des protocoles de sécurité ne sont pas sûr, c'est bien ça ?
Tout à fait. C’est même pour ça qu’on a inventé PFS et qu’on demande de faire TRÈS attention à ses configurations IPSec.
Et encore, même en version de base non PFS de TLS, la clef privée ne sert qu’à s’assurer de l’identité de la machine, une clef de session unique est négociée lors du handshake et est utilisée par la suite lors du chiffrement.
PFS a justement fait en plus en sorte que cette clef de session ne soit pas chiffrée par la clef privée mais par une nouvelle clef de session unique négociée de manière fiable par un protocole à 0 knowledge (DHE ou ECDHE).
Où ai-je dis l'inverse ? Par définition il est publique puisqu'il est nécessaire pour déchiffrer. Il doit donc être transmis sur la ligne avec le message (dans le cas général, ici il n'y a pas de ligne puisque l'on protège des mots de passe).
Pas nécessaire de le transmettre. Il peut être recalculé au déchiffrement, par exemple par une dérivation PBKDF2.
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . En réponse au journal Passprotect - Gestionnaire de mot de passe. Évalué à 2. Dernière modification le 03 octobre 2016 à 21:49.
Tout à fait. C’est même pour ça qu’on a inventé PFS et qu’on demande de faire TRÈS attention à ses configurations IPSec.
Et encore, même en version de base non PFS de TLS, la clef privée ne sert qu’à s’assurer de l’identité de la machine, une clef de session unique est négociée lors du handshake et est utilisée par la suite lors du chiffrement.
PFS a justement fait en plus en sorte que cette clef de session ne soit pas chiffrée par la clef privée mais par une nouvelle clef de session unique négociée de manière fiable par un protocole à 0 knowledge (DHE ou ECDHE).
Pas nécessaire de le transmettre. Il peut être recalculé au déchiffrement, par exemple par une dérivation PBKDF2.