j'aime bien la nouvelle interface de llama.cpp

Ah ouais t'as raison c'est beaucoup plus simple. perplexe
non je ne parlais pas du client mais de la fuite de clés
mais pour moi les clefs quittent jamais le client de toute façon
fin en fait je vois pas trop dans quel cas de figure ce setup sauve d'une attaque
ben justement c'est équivalent à deux chaînes
oui
oui en soit jouer sur la parité ça revient juste à remplacer la kdf par son carré et partir de deux clefs différentes
il faudra seulement faire attention à ce qu'on ne puisse pas voler l'état courant permettant de produire la prochaine clé paire
il faut réinjecter de l'entropie inconnue à un moment
mais voila yoneda pour moi, l'état courant il est jamais partagé
donc aucun risque de vol
ok, si j'ai compris un cas d'usage
si un attaquant sauvegarde toutes communications, et plus tard réussi à récupérer l'état n en compromettant un client
ça empêche que l'attaquant puisse déchiffrer tout l'historique qu'il a sauvegardé
chaque fois je pense pas qu'un acteur peut sauvegarder des données chiffrées dans l'espoir de les déchiffrer plus tard
ok mais pourquoi ne pas aller jusqu'au bout comme signal ?
ah bon ?
je sais pas ce qu'ils font
de ce que je comprends, ils génèrent de nouvelles clés DH qu'ils mélangent ensuite à l'état courant pour produire de nouvelles chaînes
ils rajoutent de l'entropie pour récupérer un état potentiellement compromis
Inscrivez-vous ou connectez-vous pour envoyer un message
Inscription ou connexion