Sauf que si j'en crois le journal, c'est pas seulement on first use
On dirait. Si je comprends bien la section Updating Autocrypt Peer State, l’apparition d’une nouvelle clef dans un entête Autocrypt (différente de celle déjà vue auparavant pour le même interlocuteur) est silencieuse : le client compatible Autocrypt met à jour sa base de données avec la nouvelle clef comme si de rien n’était.
Ce n’est pas du TOFU au sens où on l’entend habituellement, et tel qu’il est pratiqué avec SSH ou avec le modèle tofu de GnuPG — dans ces modèles, l’apparition subite d’une nouvelle clef produit un avertissement.
Je trouve ça personnellement regrettable mais c’est un choix cohérent avec les principes énoncés clairement dans le document :
Autocrypt ne cherche explicitement pas à protéger contre les attaques actives (Autocrypt Level 1 only defends against passive data collection attacks) ;
Autocrypt doit être le plus transparent possible vis-à-vis des utilisateurs (Ideally, Autocrypt users see very little UI).
[^] # Re: Totalement broken sans authentification de clé
Posté par gouttegd . En réponse au journal Autocrypt. Évalué à 7.
On dirait. Si je comprends bien la section Updating Autocrypt Peer State, l’apparition d’une nouvelle clef dans un entête
Autocrypt(différente de celle déjà vue auparavant pour le même interlocuteur) est silencieuse : le client compatible Autocrypt met à jour sa base de données avec la nouvelle clef comme si de rien n’était.Ce n’est pas du TOFU au sens où on l’entend habituellement, et tel qu’il est pratiqué avec SSH ou avec le modèle
tofude GnuPG — dans ces modèles, l’apparition subite d’une nouvelle clef produit un avertissement.Je trouve ça personnellement regrettable mais c’est un choix cohérent avec les principes énoncés clairement dans le document :