cassé ou pas ?

"UzEB" <uzeb@tiscali.fr> a écrit dans le message de
news:bmu947$j3u$1@news.tiscali.fr...

Bonjour,

Une question me turlupine :
Pourquoi peut-t'on dire qu'une méthode de cryptage à été cassée même s'il
n'est pas possible de le vérifier dans des conditions réel ? (pas possible
du fait que cela necessiterai du materiel encore inexistant par exemple)

Il y a une différence entre matériel inexistant car "impossible" à fabriquer
[1] et matériel difficile à construire ou coûteux (au début du DES une
machine pour casser ça en force brute -en temps raisonnable bien sur-) était
peu probable, maintenant c'est sans soucis).
Ensuite le fait qu'une attaque soit difficile à appliquer en pratique (par
exemple grand nombre de clairs choisis) importe assez peu. On sait que la
méthode de cryptage est vulnérable et il serait, amha, un peu ridicule de
continuer à l'utiliser alors qu'il en existe d'autres "mieux".

Quand a dire qu'elle *est* cassée est simplement un fondamental de la
crypto. Ca a longtemps été une méthode de défense de Philippe que de dire
"oui mais non car en pratique bonjour pour mettre la méthode en oeuvre". Si
un algo ne resiste pas à la cryptanalyse différentielle, une attaque en
clair choisi, une attaque en clair connu etc. etc. l'algo est troué.
Il y a néanmoins un minimum de bon sens à garder : si tu m'indique que tu
casse une méthode de chiffrage avec une attaque en 10^130 clair choisis je
continue de dormir tranquille (quoique!).

Exemple trollesque :

Jette un oeil sur :
http://perso.wanadoo.fr/antmonni/cdpsid
puis sur l'historique de ce groupe concernant CDP.

Même si CDPSID n'est pas exactement CDP ne crois-tu pas qu'il vaut mieux un
triple-DES[2] éprouvé qu'un CDP dont les tentatives (fautes de specs
réelles) d'implémentation ont montrées un système fondamentalement troué?

Le côté positif par contre, est l'avancée mathématique majeure concernant
les composées de permutations :-)

je veux dire, le fait qu'il ne soit pas possible réellement de déchiffrer
un

message crypter d'une certaine méthode ne suffit t'il pas à dire que cette
méthode est incassable ? (au moins dans l'état actuel des chose)

Ce paragraphe manque un peu de "formalisme". Si la méthode est démontrée
attaquable avec succès, même si l'attaque par elle même n'a pas été menée,
la méthode est trouée.

Ensuite si je te démontre qu'en cas d'étincelle à tel endroit (possible,
même si très peu probable, à cause d'un contact électrique à proximité) ton
véhicule explose, mais qu'aucun véhicule de ce type n'a explosé jusqu'à
présent que fais-tu? Rien ou essaye tu de corriger le défaut ou de changer
de véhicule?

Eric.

[1] où qu'on ne sait pas s'il existera un jour. Par exemple si un ordi
"quantique" pouvait se fabriquer il existe déjà un algo de factorisation et
donc à priori adieu RSA par exemple. Mais en attendant RSA n'est pas
"cassé".

[2] et ce n'est pas un troll, même si en version 112 bits ça peut commencer
à chauffer.

"Eric Razny" <trash2@razny.net> a écrit dans le message de news:
3f92e55b$0$245$626a54ce@news.free.fr...

Il y a une différence entre matériel inexistant car "impossible" à
fabriquer

[1] et matériel difficile à construire ou coûteux (au début du DES une
machine pour casser ça en force brute -en temps raisonnable bien sur-)
était

peu probable, maintenant c'est sans soucis).
Ensuite le fait qu'une attaque soit difficile à appliquer en pratique (par
exemple grand nombre de clairs choisis) importe assez peu. On sait que la
méthode de cryptage est vulnérable et il serait, amha, un peu ridicule de
continuer à l'utiliser alors qu'il en existe d'autres "mieux".

Merci beaucoup pour ta réponse on ne peut plus clair (pour un néophyte comme
moi).
on peut donc dire qu'une méthode de cryptage ne sera jamais incassable qu'un
certain temps.

Quand a dire qu'elle *est* cassée est simplement un fondamental de la
crypto. Ca a longtemps été une méthode de défense de Philippe que de dire
"oui mais non car en pratique bonjour pour mettre la méthode en oeuvre".
Si

quelque part ça peut se comprendre car si en pratique c'est super compliqué
voir impossible à mettre en oeuvre, on peut dire que la methode de cryptage
offre une certaine sécurité (il faudrait une echelle de sécurité)

Exemple trollesque :

Jette un oeil sur :
http://perso.wanadoo.fr/antmonni/cdpsid
puis sur l'historique de ce groupe concernant CDP.

oui je suis déjà allé voir ce site et j'ai lu une grande partie de
l'ensemble des messages du newsgroup.

Même si CDPSID n'est pas exactement CDP ne crois-tu pas qu'il vaut mieux
un

triple-DES[2] éprouvé qu'un CDP dont les tentatives (fautes de specs
réelles) d'implémentation ont montrées un système fondamentalement troué?

tout à fait. je précise quand même que ma question était d'ordre général et
je ne visais pas CDP en particulier.

Le côté positif par contre, est l'avancée mathématique majeure concernant
les composées de permutations :-)

c'est d'ailleurs une chose qui m'a frappé au fil des messages a propos de
CDP, toute l'énergie déployée pour démontrer qu'il n'est pas fiable n'aurait
t'elle pas pu servir à monter un projet capable de rivaliser avec les ténors
comme PGP ? pas forcément à partir de CDP puisque j'ai cru comprendre
d'après certains messages (je n'ai pas les connaissances pour en juger
moi-même) que c'était une mauvaise base, un mauvais départ...bon c'est sur
moi je débarque comme ça, je n'ai pas tout suivi depuis le départ, je parle
un peu comme dans un livre...mais si tout le monde poussait la charette dans
le même sens...

Ensuite si je te démontre qu'en cas d'étincelle à tel endroit (possible,
même si très peu probable, à cause d'un contact électrique à proximité)
ton

véhicule explose, mais qu'aucun véhicule de ce type n'a explosé jusqu'à
présent que fais-tu? Rien ou essaye tu de corriger le défaut ou de changer
de véhicule?

j'essayerais de corriger le defaut avant de changer de véhicule mais dans
ton exemple on sait pour l'avoir déjà testé physiquement qu'une étincelle
peut enflammer de l'essence et faire exploser un véhicule. Par contre si on
ne sait pas qu'une étincelle peut enflammer de l'essence, même si on sait
qu'il peut y avoir une étincelle à tel endroit, on ne fera rien :) (jusqu'au
jours ou...)

mais bon c'est pour chipoter :) j'ai compris ou tu veux en venir.

Eric.

--
UzEB

"UzEB" <uzeb@tiscali.fr> a écrit dans le message de
news:bmvbeu$qu6$1@news.tiscali.fr...

Le côté positif par contre, est l'avancée mathématique majeure
concernant

les composées de permutations :-)

c'est d'ailleurs une chose qui m'a frappé au fil des messages a propos de
CDP, toute l'énergie déployée pour démontrer qu'il n'est pas fiable
n'aurait

t'elle pas pu servir à monter un projet capable de rivaliser avec les
ténors

comme PGP ? pas forcément à partir de CDP puisque j'ai cru comprendre
d'après certains messages (je n'ai pas les connaissances pour en juger
moi-même) que c'était une mauvaise base, un mauvais départ...bon c'est sur
moi je débarque comme ça, je n'ai pas tout suivi depuis le départ, je
parle

un peu comme dans un livre...mais si tout le monde poussait la charette
dans

le même sens...

A mon avis l'énergie déployée pour implémenter CDPSID a au contraire été
bien dépensée. Elle permet aux gens même peu versés dans la crypto de suivre
de la conception (hum!) au cassage l'histoire d'un système de cryptage, et
ceci sans avoir besoin d'un très haut niveau en math. C'est je pense
éducatif à plus d'un titre et permet aux gens d'apprendre à ce méfier des
grands discours qui *semblent* basés sur des évidences sans rien démontrer
en fait.

Dire "c'est une mauvaise base etc." sans le (dé)montrer ne fait pas non plus
avancer les choses. Ici c'est fait et je ne peux que remercier ceux qui ont
effectivement passé pas mal de temps dessus -surtout pour definir CDP en
quelque chose(sic) -

Eric.

According to UzEB <uzeb@tiscali.fr>:

Pourquoi peut-t'on dire qu'une méthode de cryptage à été cassée même s'il
n'est pas possible de le vérifier dans des conditions réel ?

C'est une question de "contrat de confiance". Il existe relativement peu
d'experts en cryptographie, et le commun des mortels, ultimement, peut
avoir confiance en un algorithme ou un protocole quand le concepteur
démontre sa qualité d'expert et le talent qu'il a mis dans la conception
de l'algorithme. Pour cela, le concepteur s'engage moralement lorsqu'il
propose son algorithme ; il dit : "regardez, je suis un expert, et pour
le prouver, mon algorithme résiste même aux attaques académiques, ces
attaques complètement irréalistes qui sont juste vaguement meilleures
sur le papier que la recherche exhaustive, elle aussi complètement
irréaliste parce que j'ai choisi d'utiliser des clés énoooormes.".

Donc, si on trouve par exemple une attaque en 2^250 sur un algorithme
qui a une clé de 256 bits (donc un coût de la recherche exhaustive en
2^255), ça veut dire que le concepteur n'est pas aussi fort qu'il le
prétend, et qu'il vaut mieux se méfier de sa création.

je veux dire, le fait qu'il ne soit pas possible réellement de
déchiffrer un message crypter d'une certaine méthode ne suffit t'il
pas à dire que cette méthode est incassable ? (au moins dans l'état
actuel des chose)

En termes de sécurité, on veut non seulement qu'il soit impossible de
casser le système en l'état actuel des connaissances, mais on veut aussi
pouvoir en être persuadé a priori. Autrement dit, on veut pouvoir dormir
tranquille. Il faut créer la confiance.


--Thomas Pornin

According to UzEB <uzeb@tiscali.fr>:

on peut donc dire qu'une méthode de cryptage ne sera jamais incassable
qu'un certain temps.

Je ne pense pas qu'on puisse dire ça. Tout dépend de l'évolution de
la technologie, et personne ne sait prédire cela avec un quelconque
degré de fiabilité au-delà de, disons, l'an 2050. On sait faire de la
cryptographie qui résiste jusqu'à cette date sans problème et même
selon une vision très optimiste du progrès technique (un AES avec une
clé de 192 bits fait l'affaire). Au-delà, on est dans le flou total et
il est vain d'annoncer a priori que la méthode deviendra cassable, ou
pas. Mieux vaut ne rien dire du tout. Par ailleurs, en 2050 je serai
à la retraite et ces histoires de cryptographie seront le problème de
quelqu'un d'autre.

c'est d'ailleurs une chose qui m'a frappé au fil des messages a propos
de CDP, toute l'énergie déployée pour démontrer qu'il n'est pas fiable
n'aurait t'elle pas pu servir à monter un projet capable de rivaliser
avec les ténors comme PGP ?

Bof. Le logiciel CDP, à ma connaissance, est un système utilisant un
algorithme de chiffrement symétrique (peu ou pas spécifié), et rien
d'autre. Le problème du chiffrement symétrique est essentiellement
résolu (par exemple avec l'AES, et HMAC+SHA1 pour le contrôle
d'intégrité) et il y a beaucoup plus que cela dans un système tel que
PGP. Ce que PGP tente de faire, c'est de résoudre le problème de la
PKI, ou, schématiquement, comment faire pour échanger des informations
secrètes avec quelqu'un qu'on a jamais rencontré physiquement. Le
chiffrement symétrique suppose qu'on a un "secret" commun avec le
destinataire du message. Les systèmes d'échanges de clé apportent une
réponse qui déplace le problème sur le suivant : comment faire pour
assurer qu'un objet mathématique donné (une "clé publique"), publiée
dans un annuaire, soit bien la propriété d'une personne physique donnée ?

C'est toute l'histoire des certificats et des signatures de clés,
et c'est un problème autrement plus complexe que les joujoux de
Philippe. Des gens y travaillent (moi, par exemple) et, il faut bien
le reconnaître, fr.misc.cryptologie n'est pas un outil de travail très
efficace pour les cryptographes.


--Thomas Pornin

"Thomas Pornin" <pornin@nerim.net> a écrit dans le message de news:
bn14eg$men$1@biggoron.nerim.net...
[...]

et bien un grand merci pour tes réponses à mes messages, elles complètes ce
qui m'a déjà été dit et répondent même a d'autres questions que je
m'appretais à poser à propos de PGP. Que demande le peuble :)
(des sous probablement :) )

--Thomas Pornin

--
UzEB

Thomas Pornin wrote:

[...] On sait faire de la
cryptographie qui résiste jusqu'à cette date sans problème

De la crypto *symétrique* qui résiste à la *force brute* jusqu'à cette
date sans problème.

Thomas Pornin wrote:

Donc, si on trouve par exemple une attaque en 2^250 sur un algorithme
qui a une clé de 256 bits (donc un coût de la recherche exhaustive en
2^255), ça veut dire que le concepteur n'est pas aussi fort qu'il le
prétend, et qu'il vaut mieux se méfier de sa création.

Pourtant, le fait qu'il existe une attaque en 2^112 contre le triple-DES
(longueur de clé 168) n'a pas restreint son utilisation.

According to Jean-Marc Desperrier <jmdesp@alussinan.org>:

Pourtant, le fait qu'il existe une attaque en 2^112 contre le triple-DES
(longueur de clé 168) n'a pas restreint son utilisation.

La "règle de confiance" est à appliquer pour les choix présents. Dans
le cas de DES ou 3DES, on les utilise pour être interopérables avec
les architectures déployées existantes, donc en application de choix
faits dans un passé plus ou moins lointain.

De fait, 3DES n'est pas recommandé pour les nouveaux protocoles ; c'est
pour cela que le gouvernement américain a voulu un nouveau standard
de chiffrement symétrique (AES). L'utilisation de 3DES devrait se
restreindre au fur et à mesure de la diffusion des versions logicielles
capables de gérer l'AES. Dès à présent, un client SSL et un serveur SSL
peuvent négocier d'utiliser l'AES plutôt que 3DES, et, dans la pratique,
c'est ce qu'ils font si les deux le supportent.


--Thomas Pornin

"Thomas Pornin" <pornin@nerim.net> a écrit dans le message de news:
bn14eg$men$1@biggoron.nerim.net...

Par ailleurs, en 2050 je serai
à la retraite et ces histoires de cryptographie seront le problème de
quelqu'un d'autre.

Je suis à la retraite depuis plus de 15 ans et je m'intéresse toujours à la
cryptographie, c'est une vraie passion. Malheureusement, je ne puis plus
courir les symposiums ou autres congrès comme Eurocrypt que j'ai connu il y
a vingt ans. Mais à l'époque, je n'avais pas encore inventé l'algorithme
SED.

C'est toute l'histoire des certificats et des signatures de clés,
et c'est un problème autrement plus complexe que les joujoux de
Philippe. Des gens y travaillent (moi, par exemple) et, il faut bien
le reconnaître, fr.misc.cryptologie n'est pas un outil de travail très
efficace pour les cryptographes.

Même si fr.misc.cryptologie n'est pas l'outil par excellence pour les
cryptographes, il n'empêche que, en ce qui me concerne, le dialogue avec
des experts de haut niveau peut m'apporter bien des choses utiles.

Le système classicsys qui a pour but de montrer la faisabilité de
l'utilisation préférentielle de l'algorithme SED, algorithme en quelque
sorte asymétrique mais à clef privée, est toujours dans la phase
expérimentale et les ajouts se succèdent. La prochaine version,
vraisemblablement pour la fin de l'année, aura l'avantage d'effectuer le
transfert de la clef privée de l'Organisme de Confiance (TA Trust Authority)
à l'affilié en utilisant le processus de Diffie-Hellman avec une clef
secrète de 768 ou 1024 bits et la mise en chantier d'un système de
certification d'une signature sera pour l'année prochaine et s'effectuera
de la manière suivante:

Alice prend une affiliation au système Classicsys en donnant son
identité dans un logiciel téléchargé et retransmis au TA. Pour confirmer son
identité, elle effectuera un transfert financier au gestionnaire du TA où
elle devra introduire le pin de sa carte bancaire (home banking, selfbank à
un terminal...). Le versement d'un euro est largement suffisant pour qu'à la
réception du transfert, il soit possible de vérifier que l'identité
introduite à l'affiliation correspond à l'identité du détendeur de la carte
bancaire pour laquelle on a introduit le pin. De ce fait, Alice devient une
affiliée enregistrée par le TA. Tout chiffrement (128 bits) à l'aide de la
clef privée (128 bits) pourra donner lieu à une signature (128 bits).

Supposons que Bob désire vérifier un document émis par Alice. Par une
méthode de hachage (hachage avec l'algorithme SED), le texte d'Alice sera
réduit à un vecteur abrégé de 128 bits, lequel sera chiffré à l'aide de la
clef privée d'Alice. Bob reçoit de celle-ci: le texte à certifier, l'abrégé
de texte et la signature. Le logiciel de Bob vérifie que l'abrégé correspond
bien au texte. Pour vérifier la signature, Bob envoie au TA l'abrégé de
texte, la signature et les adresses d'Alice et de Bob. Le TA, qui a
connaissance de toutes les clefs privées de ses affiliés, encrypte l'abrégé
de texte avec la clef privée d'Alice et décrypte la signature avec la clef
de déchiffrement correspondante. Le vecteur (somme modulo-2) des deux
vecteurs et du moment présent (date et heure) est déchiffré à l'aide de la
clef inverse de la clef privée de Bob et lui est transmis. Celui-ci encrypte
le vecteur reçu avec sa clef privée. Le vecteur résultat du chiffrement est
additionné (modulo-2) avec l'abrégé de texte et la signature correspondante
communiquée par Alice.Si la signature est exacte, Bob retrouve le moment de
la vérification de la signature par le TA. Dans le cas contraire, le vecteur
résultat n'a aucune signification et n'a même pas la structure du vecteur du
moment présent qui devrait apparaître.

La procédure de la vérification de la signature peut être implémentée
dans un logiciel pour effectuer un é-mail recommandé d'Alice à Bob. A la fin
du message encrypté avec la clef de session, le logiciel introduit un
vecteur de séparation et inscrit sept vecteurs de 128 bits:
- le vecteur 1 comprend le statut opérationnel et les adresses
d'Alice et Bob;
- le vecteur 2 constitue l'abrégé du texte clair d'Alice à Bob;
- le vecteur 3 donne la signature du vecteur 2 avec la clef privée
d'Alice;
- le vecteur 4 correspond à l'abrégé des vecteurs 1, 2 et 3;
- le vecteur 5 représente la signature du vecteur 4;
- le vecteur 6 donne le moment de la certification du vecteur 3 par
le TA;
- le vecteur 7 donne le moment de la certification du vecteur 4.

Les cinq premiers vecteurs sont transmis au TA et ce dernier retourne
les deux vecteurs qui serviront au calcul des vecteurs 6 et 7. Les moments
indiqués par les vecteurs 6 et 7 doivent être égaux à quelques millisecondes
près. Le TA, qui connaît également la clef privée de Bob, calcule les deux
vecteurs correspondants aux vecteurs 6 et 7 et les transmet à Bob.

A la réception de l'é-mail, le logiciel de Bob décrypte avec la clef de
session inversée et calcule l'abrégé du texte clair décrypté lequel doit
être égal à l'abrégé calculé par Alice (vecteur 2). D'une manière similaire,
le logiciel de Bob calcule les sept vecteurs correspondants aux sept
vecteurs d'Alice et les lui transmet.

Les deux correspondants, Alice et Bob, sont à même de vérifier toutes
les signatures, mais incapables d'effectuer une fausse signature. En
cliquant sur le bouton "é-mail recommandé", le logiciel de chaque
correspondant prend en charge tous les chiffrements ainsi que la gestion des
clefs, le dialogue avec le TA et l'établissement des informations
nécessaires pour d'éventuels post-mortem.

Ce projet est en cours d'élaboration et comme c'est un peu votre
domaine, vos remarques me seront certainement utiles.

Bonnes cogitations

Emile