Son idée de départ repose sur un postulat simple concernant la confidentialité des échanges sur internet. Nous savons qu'il est très simple (et très tentant pour les états) d'intercepter les données. La solution classique, le chiffrement, ne satisfait pas Eric Filiol, pour plusieurs raisons:
- Le chiffrement se détecte trop facilement, et de fait pose un doute légitime sur l'émetteur du flux pour celui qui détecte le chiffrement.
- Le chiffrement n'est donc pas TRANSEC. Transec impose une probabilité faible de détection.
- Les états peuvent avoir une raison légitime de pouvoir lire les échanges réseaux, la cryptographie les en empêche. [Note: je ne suis pas forcément d'accord sur ce point :-) ]
- L'absence de chiffrement, émettre en clair, n'est évidemment pas acceptable.
Cette bibliothèque permet donc:
- De modifier les données afin qu'un filtre statique ne détecte pas des motifs comme des mots-clés.
- De faire en sorte que le flux ressemble à un autre type de flux; ainsi une image jpeg "chiffrée" (camouflée?) par Perseus peut avoir une signature le faisant ressemble à un pdf ou du HTML, ceci afin de contourner les filtres automatiques. Bien entendu ceci est rendu possible en ajoutant du "bruit" maîtrisé dans le message.
- D'être facilement cassable, qu'il suffise de quelques jours/semaines afin qu'une personne motivée (un état, donc) puisse décoder et lire les échanges. L'exemple pris est celui d'un journaliste qui poste ses messages depuis un pays dictatorial qui ne sera capable de lire ses messages qu'une fois le journaliste rentré chez lui.
Ceci posé, je ne suis absolument pas convaincu par la lib Perseus pour plusieurs raisons.
La première concerne son essence même. C'est du chiffrement sans en être. D'un côté c'en est puisque le message est camouflé, mais d'un autre ce n'en est pas puisque les états ont 'librement' accès aux données. Statut pour le moins curieux. Statut pour moi ennuyeux, car promouvoir le fait que ce n'est pas du chiffrement démotivera sans doute des peer reviews à étudier le protocole. Un challenge (bancal) a été lancé, mais ce challenge ne prouvera pas la solidité du concept.
Enfin, la techno a un an, ce qui est très jeune. Pour exemple, une techno comme le SHA3 est étudiée depuis bien plus longtemps, et les concepteurs eux-mêmes déconseillent actuellement son usage.
La seconde concerne l'aspect TRANSEC. Je ne vois pas en quoi c'est un problème. Il est attendu et normal selon moi que des échanges chiffrés aient lieu entre différents points du réseau. Un filtre automatique se fera sans doute leurrer par perseus mais une personne surveillée sera détectée sans problème. Il est indiqué qu'il faut augmenter la taille des données pour pouvoir le camoufler en autre chose. Certes. Toutefois, libre à moi de chiffrer en AES, puis de le passer en base64. L'entropie ne sera plus celle de l'AES! Une seconde méthode, plus simple serait de choisir 256 sujet, 256 verbes et 256 compléments. Chaque triplet d'octet serait transformé en sujet-verbe-complément. Les filtres auto se feront leurrer. Je peux aussi faire un système balise ouvrante, mot, balise fermante pour faire ressembler mon AES à du HTML, etc etc.. Dire que TRANSEC est un prérequis peut s'accomplir facilement si on prend en compte le grossissement du fichier d'origine.
Enfin, la troisième concerne le projet. Dire qu'on utilise un système 'vaguement chiffrant' qui laisse par construction aux états le moyen de connaître le contenu ne m'inspire pas confiance.
Je vais donc continuer à utiliser de la crypto, ssh, SSL/TLS, GPG etc.. et ne pas installer Perseus car je n'y vois pas les avantages, ni comprend la finalité.
EDIT: quelques liens ajoutés et précisions.
De plus, qu'est ce qui différencie un état "gentils" d'un état "voyou", voire d'une dictature ? En quoi une mafia possède moins de moyen technologique qu'un état, à l'heure où des gamins de 14 ans peuvent avoir des botnets à leurs ordres ?
RépondreSupprimerEn effet, le concept même de Perseus est bancal ; aucun intérêt de perdre du temps là dessus.
Concernant l'aspect "faible mais pas trop" du chiffrement, je doute fortement.
RépondreSupprimerS'il est possible avec certains moyens de casser le chiffrement en quelques semaines, en mettant 7 fois plus de moyens il est possible de le casser en quelques jours, non?
(P.S: marche pas, OpenID, ici?)
Peut être un jour la communauté comprendra que Éric Filiol est plus dans le domaine du marketing et du buzz que de la sécurité (une petite recherche sur Google permet de se faire une bonne idée du personnage).
RépondreSupprimerLa communauté l'a compris depuis un moment, maintenant reste à convaincre les journalistes...
RépondreSupprimermais ça c'est pas vraiment possible, sinon ça ferrait un moment que des "trucs" comme Zataz n'existeraient plus, ou que des arnaqueurs comme Riguidel ne seraient plus nommés expert auprès du gouvernement.
@Anonyme1&2: Je suis d'accord, vouloir un chiffrement "faible" ne semble pas une bonne idée. A ce sujet, si on veut du chiffrement faible, pourquoi ne pas chiffrer en AES avec une partie de clé connue?
RépondreSupprimer@Anonyme2: Pourtant google blogger supporte openID (?)
@Anonyme3: no comment :)
@Anonyme4: Pas de dénigrement SVP ;) restons technique.
RépondreSupprimereh les gars ayez au moins le courage d'enlever votre masque pour qu'on vérifie vos compétences...
RépondreSupprimerEn attendant, moi aussi je joue comme vous : j'avance masqué
C'est vrai que sur Google tout ce qu'on trouve est plus parlant que la personne elle même. Personne ne s'est jamais fait une mauvaise réputation à cause de google basé sur des théories aussi bien fondée que la zone 51...
RépondreSupprimerFiliol à été mon prof d'Info et de master sécurité système et réseau. Autant vous dire que je suis bien placé. Je mets au défi chacun d'entre vous, voir tous à la fois de le piéger sur une question de ses domaines d'expertises !
C'est vrai que pour vous il est facile de dénigrer lorsque vous ne pouvez rien prouvez. Essayez d'en faire autant que lui. Quand vous aurez sa carrière, on en reparlera... J'en doute qu'on en reparlera en fait !