Je pense tout de même que le problème est que dans des cas de sécurité sur de longue période comme cela, il faudrait prévoir le maintiens de la sécurité. Comme on doit maintenir des sauvegarde (s'assurer que les disque de sauvegarde ne sont pas mort, qu'ils restent lisibles,...), il faut maintenir encore plus activement la sécurité. Ici l'absence de procédure mise en place correctement nuit gravement à la sécurité de ses données.
Sauf que si tu essaies d’expliquer ça à un utilisateur qui demande seulement à pouvoir continuer à valider ses signatures MD-5, tu vas te prendre un retour de bâton du genre « ah, voilà bien la réponse typique d’un développeur de logiciels libres enfermé dans sa tour d’ivoire et sourd aux attentes des utilisateurs : "explique-moi quel est ton besoin, je t’expliquerai comment t’en passer" ».
C’est d’autant plus contre-productif que dans l’exemple en question, les utilisateurs en question savent bien que leur solution n’est pas sans problèmes. Ils n’ont juste pas le choix : ils ne contrôlent pas tout (comme dans beaucoup de situation, les décisions techniques ne sont pas forcément prises par ceux qui maîtrisent la technique...) et ils doivent juste faire du mieux qu’ils peuvent — alors ce n’est pas en venant leur faire des leçons que tu vas les aider.
Je pense que c'est compliqué.
Je n’ai pas dit le contraire.
Je connais mal OpenPGP, mais il doit être possible d'avoir un certain niveau par défaut et de réactiver des algo sur demande (c'est peut être ce qui est fait) ou de modulariser et d'avoir des paquets -ugly comme le fait gstreamer ou encore de n'accepter que de lire ces algo.
C’est un peu tout ça à la fois qui est fait.
Au niveau du standard (en cours de refonte actuellement, même si c’est beaucoup plus long que tout le monde le souhaiterait), il est par exemple INTERDIT (MUST NOT) de générer de nouveaux messages avec MD-5, mais il est POSSIBLE (MAY) de continuer à supporter MD-5 en lecture uniquement. C’est ce qui arrivera à SHA-1 dans la prochaine version du standard.
Au niveau des implémentations, dans le cas de GnuPG :
Les trucs vraiment trop vieux sont relégués à GnuPG 1.x, dont c’est la seule raison d’être aujourd’hui ;
Dans la branche principale, les trucs qui marchent encore mais qu’on n’aime plus trop sont toujours supportés en lecture, mais utilisés en écriture seulement à la demande explicite de l’utilisateur.
Par exemple, seul GnuPG 1.x aujourd’hui peut utiliser des signatures MD-5, GnuPG 2.2 les refuse complètement, même en lecture. Dans le cas de SHA-1, jusqu’à ces derniers mois il n’était plus utilisé par défaut (depuis 2009) mais était toujours utilisable sur demande, et accepté en lecture sauf demande contraire (option --weak-digest-algo SHA1) ; depuis la publication de cette attaque, il n’est plus accepté même en lecture.
[^] # Re: Je suis étonné d'être surpris...
Posté par gouttegd . En réponse à la dépêche SHA-mbles : une collision à préfixes choisis sur SHA-1. Évalué à 7.
Sauf que si tu essaies d’expliquer ça à un utilisateur qui demande seulement à pouvoir continuer à valider ses signatures MD-5, tu vas te prendre un retour de bâton du genre « ah, voilà bien la réponse typique d’un développeur de logiciels libres enfermé dans sa tour d’ivoire et sourd aux attentes des utilisateurs : "explique-moi quel est ton besoin, je t’expliquerai comment t’en passer" ».
C’est d’autant plus contre-productif que dans l’exemple en question, les utilisateurs en question savent bien que leur solution n’est pas sans problèmes. Ils n’ont juste pas le choix : ils ne contrôlent pas tout (comme dans beaucoup de situation, les décisions techniques ne sont pas forcément prises par ceux qui maîtrisent la technique...) et ils doivent juste faire du mieux qu’ils peuvent — alors ce n’est pas en venant leur faire des leçons que tu vas les aider.
Je n’ai pas dit le contraire.
C’est un peu tout ça à la fois qui est fait.
Au niveau du standard (en cours de refonte actuellement, même si c’est beaucoup plus long que tout le monde le souhaiterait), il est par exemple INTERDIT (MUST NOT) de générer de nouveaux messages avec MD-5, mais il est POSSIBLE (MAY) de continuer à supporter MD-5 en lecture uniquement. C’est ce qui arrivera à SHA-1 dans la prochaine version du standard.
Au niveau des implémentations, dans le cas de GnuPG :
Les trucs vraiment trop vieux sont relégués à GnuPG 1.x, dont c’est la seule raison d’être aujourd’hui ;
Dans la branche principale, les trucs qui marchent encore mais qu’on n’aime plus trop sont toujours supportés en lecture, mais utilisés en écriture seulement à la demande explicite de l’utilisateur.
Par exemple, seul GnuPG 1.x aujourd’hui peut utiliser des signatures MD-5, GnuPG 2.2 les refuse complètement, même en lecture. Dans le cas de SHA-1, jusqu’à ces derniers mois il n’était plus utilisé par défaut (depuis 2009) mais était toujours utilisable sur demande, et accepté en lecture sauf demande contraire (option
--weak-digest-algo SHA1) ; depuis la publication de cette attaque, il n’est plus accepté même en lecture.