Plusieurs possibilités de chiffrage ?

"evadila" <evadila@yahoo.fr> wrote:

1: Blowfish (128-bit)
2: DES (56-bit)
3: Triple DES (158-bit)
4: Rijndael - AES (128-bit)
5: Rijndael - AES (256-bit)

Le quel de c'est 5 choix, vous choisirais ?

Mon avis d'amateur: n'importe lequel procure un niveau de sécurité
très élevé, sauf le DES, qui est vraiment trop faible.

Attention, juste pour pinailler, l'algorithme, ce n'est qu'une partie
de la sécurité. Des erreurs d'implémentations peuvent soudainement
ramener le niveau de protection à zéro, malgré un excellent algo. Il
faudrait jeter un oeil sérieux sur le programme utilisé, mais en ce
moment, personnellement, je ne préfère pas :) [private joke]

--
Guillermito
http://www.guillermito2.net

According to evadila <evadila@yahoo.fr>:

1: Blowfish (128-bit)
2: DES (56-bit)
3: Triple DES (168-bit)
4: Rijndael - AES (128-bit)
5: Rijndael - AES (256-bit)

Les fichiers à chiffrer sont confidentiels ... sans plus

Si les fichiers sont confidentiels "sans plus", alors le choix de
l'algorithme n'a pas vraiment d'importance. Ces 5 algorithmes
résistent à des investigations de moyenne ampleur.

Pour être précis, DES (56-bit) est attaquable par force brute : il
faut une machine spécialisée, dont le coût de construction est estimé
à environ cent mille dollars, et qui fait le boulot en trois jours
(en fait, une a été construite en 1997 pour deux cent cinquante mille
dollars, mais ça inclut le coût de développement ; l'évolution technique
aidant, je suppose qu'on devrait pouvoir faire encore moins cher
que cent mille dollars aujourd'hui, mais ça reste une construction
spécifique, pas un PC "de chez Auchan").

Les quatre autres sont hors de portée de la technologie terrienne pour
le moment, et probablement pour les trente prochaines années aussi.
Ils sont donc "incomparables" de ce point de vue. On peut néanmoins
dire que l'AES 256-bit devrait tenir _au moins aussi longtemps_ que
l'AES 128-bit, parce que c'en est une extension. Mais pour être plus
précis, il faut faire des prospectives hasardeuses sur l'évolution de la
technologie au-delà de l'an 2035, et je ne m'y risquerai pas.


Votre choix devra donc être guidé par d'autres critères. Par exemple,
est-ce qu'il y a des problèmes d'interopérabilité avec d'autres
logiciels, qui restreignent votre choix ? De toutes façons, pour ce qui
est de la sécurité, le choix de l'algorithme est rarement critique. Dans
votre cas, je suppose que la clé de chiffrement est un mot de passe,
tapé sur un clavier, retenu dans la tête d'un humain, éventuellement
écrit sur un post-it collé sous le clavier. C'est dans ce mot de passe
(et surtout dans l'humain qui l'a choisi) qu'est le trou de sécurité
le plus béant. On peut aussi se demander si le logiciel utilise
correctement l'algorithme de chiffrement (c'est sensible, ces petites
bêtes, et ça se manipule avec précaution).


--Thomas Pornin

"Thomas Pornin" <pornin@nerim.net> a écrit dans le message

According to evadila <evadila@yahoo.fr>:

1: Blowfish (128-bit)
2: DES (56-bit)
3: Triple DES (168-bit)
4: Rijndael - AES (128-bit)
5: Rijndael - AES (256-bit)

Les fichiers à chiffrer sont confidentiels ... sans plus

Si les fichiers sont confidentiels "sans plus", alors le choix de
l'algorithme n'a pas vraiment d'importance. Ces 5 algorithmes
résistent à des investigations de moyenne ampleur.

Votre choix devra donc être guidé par d'autres critères. Par exemple,
est-ce qu'il y a des problèmes d'interopérabilité avec d'autres
logiciels, qui restreignent votre choix ?

Bonsoir

Non je ne suis pas gêné par des problemes d'interopérabilité avec d'autres
logiciels , mais j'utilise celui ci,
il me convient .
Il a beaucoup de fonctions, mais ma question principale était bien sur le
chiffrage.
Votre réponse me convient bien , si j'ai bien compris les algorithmes
utilisés
se valent à " peu-près " tous dans les possibilites actuelles , sauf pour
le DES (56-bit)

De toutes façons, pour ce qui
est de la sécurité, le choix de l'algorithme est rarement critique. Dans
votre cas, je suppose que la clé de chiffrement est un mot de passe,
tapé sur un clavier, retenu dans la tête d'un humain, éventuellement
écrit sur un post-it collé sous le clavier. C'est dans ce mot de passe

Oui c'est bien un mot de passe.
Mais pas caché sous le clavier : -)
Y a t'il d'autres moyens que les mots de passe ?

(et surtout dans l'humain qui l'a choisi) qu'est le trou de sécurité
le plus béant. On peut aussi se demander si le logiciel utilise
correctement l'algorithme de chiffrement (c'est sensible, ces petites
bêtes, et ça se manipule avec précaution).

Votre réponse me paraît tres interessante au sujet de : si le logiciel
utilise
correctement l'algorithme de chiffrement .

Je ne le sais pas...

A votre connaissance , existe t'il des programmes test pour verifier si le
logiciel
utilise bien l'algo de chiffrement ?

Je m'explique un peu :
Exemple
le logiciel A chiffre avec l'algo DES (56-bit).

le logiciel B déchiffre avec l'algo DES (56-bit).

Ca devrait fonctionner ? , ou je m'égare .

Merci de vos réponses

Eva

According to evadila <evadila@yahoo.fr>:

Oui c'est bien un mot de passe.
Mais pas caché sous le clavier : -)
Y a t'il d'autres moyens que les mots de passe ?

Le chiffrement symétrique, c'est comment mélanger des données avec
une "clé", c'est-à-dire une convention secrète, de telle façon qu'il
faille connaître cette convention secrète pour démêler les choses.

Un algorithme tel que DES utilise des clés qui sont des suites d'un
certain nombre de bits. DES lui-même est attaquable parce que comme
sa clé ne fait que 56 bits, il n'y a que 72057594037927936 clés
possibles (toutes les combinaisons de 56 bits), qui peuvent toutes être
essayées une par une (pas en 5 minutes tout de même). L'algorithme
AES, avec une clé de 128 bits, possède beaucoup trop de clés possibles
(340282366920938463463374607431768211456) pour qu'une telle attaque
(dite recherche exhaustive) soit possible.

Le problème de tout ça, c'est qu'une suite de 128 bits (valant 0 ou 1),
c'est dur de s'en rappeler, surtout que ça doit être exact (un bit de
faux, et c'est tout le déchiffrement qui échoue -- dans les films, quand
ils ont presque déchiffré un message, on a juste un affichage "flou",
mais c'est du pur pipeau ; dans le monde réel, c'est la clé exacte,
ou rien du tout). Les humains, ce qu'il peuvent retenir, ce sont des
suites de lettres formant des mots. On appelle ça des mots de passe, ou
"phrases de passe" quand on veut insister sur la possibilité de mettre
plusieurs mots à la suite.

L'utilisation de mots de passe pose deux problèmes principaux :

-- Le mot de passe doit être transformé en une clé qui rentre dans
l'algorithme de chiffrement (ça se règle souvent avec une fonction de
hachage, mais il y a moyen de mal le faire et d'introduire des
faiblesses).

-- 20% des utilisateurs choisissent comme mot de passe leur nom, leur
prénom, l'anniversaire de leur femme ou le nom de l'attaquant de leur
équipe de football préférée. Cela peut se deviner en quelques essais
(on appelle ça l'attaque "par dictionnaire"). Et, plus généralement,
si le mot de passe est mémorisable, il est probablement "devinable".

Le deuxième point ne peut se régler que par une formation rigoureuse
des gens qui sont amenés à choisir les mots de passe.

Votre réponse me paraît tres interessante au sujet de : si le logiciel
utilise correctement l'algorithme de chiffrement.

Je ne le sais pas...

A votre connaissance , existe t'il des programmes test pour verifier
si le logiciel utilise bien l'algo de chiffrement ?

C'est plus compliqué que ça.

L'algorithme DES (par exemple) est défini ainsi : il prend en entrée un
bloc de 8 octets, le mélange (en "injectant" la clé), et fournit une
sortie sur 8 octets. 8 octets, ce n'est pas beaucoup. Aussi, quand on
veut chiffrer un fichier, il faut le "découper" en blocs de 8 octets,
chiffrer chaque bloc, et recombiner le tout. On appelle ça le chaînage.

Il y a de nombreuses manières de faire ce chaînage et ces
recombinaisons, et les manières les plus simples sont aussi les
moins solides. Ça ne s'improvise pas. C'est en général dans le choix
de ces méthodes que les logiciels qui n'ont pas été conçus par des
cryptographes chevronnés échouent (même si les algorithmes eux-mêmes
sont corrects -- comme on dit, ce n'est pas la taille de la clé qui
compte, mais la manière de s'en servir).


Ça pose aussi des problèmes d'interopérabilité : si un logiciel A
chiffre en DES avec un certain chaînage, et qu'un logiciel B utilise lui
aussi DES mais avec un autre chaînage, alors ça ne va pas marcher du
tout.

Le mieux, dans ces conditions, est d'avoir un logiciel qui chiffre selon
des algorithmes _et chaînages_ standardisés. Par exemple, PGP fait ça :
les messages qu'il produit suivent le format "OpenPGP" (format publié
dans la RFC 2440 : http://www.faqs.org/rfcs/rfc2440.html ) qui décrit
comment tout se passe précisément. Ça permet à plusieurs logiciels
différents de se parler entre eux, et ça permet aussi à des cryptographes
de regarder le format (indépendamment des logiciels) et de dire ce
qu'ils en pensent. En l'occurrence, le format OpenPGP semble solide
(ce format couvre aussi la transformation d'un mot de passe en clé de
chiffrement, et il le fait plutôt bien).

Même ainsi, il faut encore que le logiciel utilisé ne fasse pas
n'importe quoi : par exemple, il faut que le logiciel choisisse
certaines valeurs aléatoirement, et la "qualité" de cet aléa (son
aspect vraiment aléatoire et imprédictible) est souvent cruciale pour
la solidité du résultat. Pour savoir si un logiciel est correct, il
n'y a qu'une méthode : analyse du code source par des spécialistes.
C'est un gros boulot, et c'est cher. Et il faut que le code source soit
disponible.



Évidemment, si c'est pour des documents confidentiels "mais sans
plus", on devrait pouvoir utiliser n'importe quel logiciel qui a une
réputation pas trop pourrie. C'est une question de modèle d'attaque : si
l'attaquant n'est pas extrêmement motivé ou doué, on n'a pas besoin de
l'artillerie lourde.


--Thomas Pornin

pornin@nerim.net (Thomas Pornin) writes:

Pour être précis, DES (56-bit) est attaquable par force brute : il
faut une machine spécialisée, dont le coût de construction est estimé
à environ cent mille dollars, et qui fait le boulot en trois jours
(en fait, une a été construite en 1997 pour deux cent cinquante mille
dollars, mais ça inclut le coût de développement ; l'évolution technique
aidant, je suppose qu'on devrait pouvoir faire encore moins cher
que cent mille dollars aujourd'hui, mais ça reste une construction
spécifique, pas un PC "de chez Auchan").

Bonjour,

Je me pose une question sur ces machines/méthodes de recherche force
brute : ça s'arrête comment ? C'est bien joli de tester beaucoup de
clés à la seconde, mais comment on sait qu'on a la bonne ?

A part avoir des infos au préalable sur le clair, genre c'est une
image GIF donc le fichier commence par la chaine "GIF8" je vois pas
trop comment ça marche.

--
"Never ascribe to malice what can be explained by human stupidity"
R. A. Heinlein

I love cats <catipole@bigfoot.com> wrote:

Je me pose une question sur ces machines/méthodes de recherche force
brute : ça s'arrête comment ? C'est bien joli de tester beaucoup de
clés à la seconde, mais comment on sait qu'on a la bonne ?

A part avoir des infos au préalable sur le clair, genre c'est une
image GIF donc le fichier commence par la chaine "GIF8" je vois pas
trop comment ça marche.

On peut aussi utiliser le spectre du fichier en clair. C'est à dire la
distribution statistiques des octets, qui est souvent très
reconnaissable. Voilà un exemple de spectre d'un texte, que j'avais
utilisé pour un article:

http://www.guillermito2.net/stegano/inplainview/if_original.gif

Il s'agit du poème "If" de Rudyard Kipling, en trois langues:

http://www.guillermito2.net/stegano/inplainview/if.txt

Sans même lire les mots, on devine qu'il s'agit de texte. On peut voir
les octets 10 et 13 (retour à la ligne sous DOS) présents avec la même
fréquence, puis une immense barre à 32 (espace), quelques rares
caractères de 65 à 90 (majuscules), une majorité de 97 à 122
(minuscules), quelques rares autres vers la fin (minuscules
accentuées). Si le texte est suffisamment long, on peut même en
déduire la langue dans laquelle il est écrit (ici c'est un mélange).

D'autres fichiers ont aussi une signature très reconnaissable, sans
même parler des en-têtes ou de la structure. Par exemple, les fichiers
WAV ont un spectre qui saute aux yeux.

Par contre, si le fichier est doublement crypté et donc ressemble à
une chaine aléatoire, j'avoue que je ne sais pas comment on fait.
Peut-être que justement, ça devient reconnaissable *parce que* c'est
aléatoire.

--
Guillermito
http://www.guillermito2.net

Bonjour;

Je prends cette conversation en marche, et je n'ai pas trouvé le post
précédent de Catipole. Mais votre réponse réveille une interrogation liée à
mes propres recherches:

Comme vous le dites, la cryptanalyse d'un chiffré à clair inconnu et
algorithme connu peut se faire sur la base du spectre attendu de ce clair.
Et en effet, s'il y a un second niveau de cryptage, alors ça devient très
complexe en l'absence d'un tel spectre.

Précisément, le critère d'une compression *efficace* est de tendre vers une
entropie maximale au niveau du compressé, et alors il n'y a "plus rien à
voir". On se trouve donc sensiblement dans la même situation avec un clair
compressé puis crypté et un clair crypté deux fois (à la taille près).

J'en viens même à me demander si, pour une compression optimale, le simple
fait de perturber seulement quelques bits répartis de manière secrète et
pseudo-aléatoire dans la forme cryptée ne peut pas suffire à la rendre
indécryptable.

Pour cela, il faut bien entendu que l'algorithme de compression ne produise
pas lui-même une forme "réparable" (checksums), ni découpée en segments
autonomes (ex: G31D des fax), ni formée de patterns caractéristiques où il
soit aisé de repérer les erreurs (genre code de Huffman fixe).

Auriez-vous des références sur des études portant sur cette immunité des
formes de compression aux perturbations, qualité qui en l'inversant peut
devenir un défaut intéressant en cryptologie ?

Merci d'avance.

Cordialement,

PZB


"Guillermito" <guillermito@pipo.com> a écrit dans le message de
news:9fb480trnu5p1i0i3683phpnj0krd2m1ph@zobi...

I love cats <catipole@bigfoot.com> wrote:

Je me pose une question sur ces machines/méthodes de recherche force
brute : ça s'arrête comment ? C'est bien joli de tester beaucoup de
clés à la seconde, mais comment on sait qu'on a la bonne ?

A part avoir des infos au préalable sur le clair, genre c'est une
image GIF donc le fichier commence par la chaine "GIF8" je vois pas
trop comment ça marche.

On peut aussi utiliser le spectre du fichier en clair. C'est à dire la
distribution statistiques des octets, qui est souvent très
reconnaissable. Voilà un exemple de spectre d'un texte, que j'avais
utilisé pour un article:

http://www.guillermito2.net/stegano/inplainview/if_original.gif

Il s'agit du poème "If" de Rudyard Kipling, en trois langues:

http://www.guillermito2.net/stegano/inplainview/if.txt

Sans même lire les mots, on devine qu'il s'agit de texte. On peut voir
les octets 10 et 13 (retour à la ligne sous DOS) présents avec la même
fréquence, puis une immense barre à 32 (espace), quelques rares
caractères de 65 à 90 (majuscules), une majorité de 97 à 122
(minuscules), quelques rares autres vers la fin (minuscules
accentuées). Si le texte est suffisamment long, on peut même en
déduire la langue dans laquelle il est écrit (ici c'est un mélange).

D'autres fichiers ont aussi une signature très reconnaissable, sans
même parler des en-têtes ou de la structure. Par exemple, les fichiers
WAV ont un spectre qui saute aux yeux.

Par contre, si le fichier est doublement crypté et donc ressemble à
une chaine aléatoire, j'avoue que je ne sais pas comment on fait.
Peut-être que justement, ça devient reconnaissable *parce que* c'est
aléatoire.

--
Guillermito
http://www.guillermito2.net

"Patrick "Zener" Brunet" <http://zener131.free.fr/ContactMe> a écrit dans le
message de news:4083d6cb$0$5092$626a14ce@news.free.fr...


Je voulais dire en fait:

... quelques bits répartis de manière secrète et
pseudo-aléatoire dans la forme COMPRESSEE

sorry !

"Patrick "Zener" Brunet" <http://zener131.free.fr/ContactMe> wrote:

Comme vous le dites, la cryptanalyse d'un chiffré à clair inconnu et
algorithme connu peut se faire sur la base du spectre attendu de ce clair.
Et en effet, s'il y a un second niveau de cryptage, alors ça devient très
complexe en l'absence d'un tel spectre.

En fait, c'est une question que je me pose souvent, et sans doute
seuls les connaisseurs ici pourront y répondre. Ou c'est peut-être
juste le décalage habituel entre théorie et pratique que j'ai du mal à
discerner.

J'ai lu mille fois sous la plume de divers spécialistes que,
théoriquement, utiliser deux cryptages successifs n'améliore en rien
la sécurité - qui reste en fait égale à celle de l'algorithme le plus
sûr des deux. Et que si on utilise le même algo deux fois avec deux
mots de passe différents, la sécurité est la même que si on ne
l'utilise qu'une fois. Je pense que je comprends intuitivement cela.
En théorie. Mais je suis persuadé aussi que dans la pratique, par
exemple quand quelqu'un essaie de vraiment décrypter, par force brute
ou autre, le message que j'ai fait passer à ma petite soeur, faire un
double cryptage (ou compresser puis crypter) renforce la sécurité,
notamment parce qu'il n'y a plus d'analyse de spectre possible.

Précisément, le critère d'une compression *efficace* est de tendre vers une
entropie maximale au niveau du compressé, et alors il n'y a "plus rien à
voir". On se trouve donc sensiblement dans la même situation avec un clair
compressé puis crypté et un clair crypté deux fois (à la taille près).

Voilà. Ou, encore une fois, ce qui est détectable c'est que justement,
on sort avec la clef X une suite de bits qui semble aléatoire, ce qui
est rare (en fait, des données vraiment aléatoires, c'est extrèmement
rare sur un disque dur - donc suspect).

J'en viens même à me demander si, pour une compression optimale, le simple
fait de perturber seulement quelques bits répartis de manière secrète et
pseudo-aléatoire dans la forme cryptée ne peut pas suffire à la rendre
indécryptable.

Ca me rappelle ce que je faisais il y a très longtemps, quand j'étais
un peu paranoïaque, et que je ne voulais pas que les gens tombent sur
mes lettres d'amour enflammées à la voisine: je cryptais, et puis, à
la main, avec un éditeur hexa, j'inversais toujours le neuf cent
trente troisième octet.

Ce qui me rappelle aussi que j'avais un projet à un moment donné (un
des innombrables projets jamais réalisés) de créer un logiciel
combinant stéganographie et cryptographie, qui aurait permis de cacher
deux (ou plusieurs) fichiers. Par la suite, si on rentre le mot de
passe X, le programme extrait le fichier numéro 1 (une photo osée, par
exemple, qui sert de leurre), et si on rentre le mot de passe Y, on
obtient le vrai fichier caché important (le numéro de téléphone de la
voisine). Le tout de façon à faire croire que l'on collabore avec les
autorités (le mari énervé de la voisine, par exemple), alors qu'en
fait on est plus malin qu'eux. En d'autres termes, pouvoir nier de
manière convaincante la présence du fichier caché important, même si
la stéganographie est détectable.

Auriez-vous des références sur des études portant sur cette immunité des
formes de compression aux perturbations, qualité qui en l'inversant peut
devenir un défaut intéressant en cryptologie ?

Houla non, je ne suis qu'un simple amateur réticent aux règles
mathématiques les plus simples. Mais ça doit se trouver. Je laisse la
parole aux gens qui savent.

--
Guillermito
http://www.guillermito2.net

According to Guillermito <guillermito@pipo.com>:

En théorie. Mais je suis persuadé aussi que dans la pratique, par
exemple quand quelqu'un essaie de vraiment décrypter, par force brute
ou autre, le message que j'ai fait passer à ma petite soeur, faire un
double cryptage (ou compresser puis crypter) renforce la sécurité,
notamment parce qu'il n'y a plus d'analyse de spectre possible.

En fait, le défenseur et l'attaquant sont dans deux mondes différents.
L'attaquant a un problème concret sous la main ; dans le cas d'une
recherche exhaustive (force brute sur la clé, dictionnaire sur un
mot de passe...), l'attaquant a besoin d'un "test d'arrêt". Souvent,
cela est fourni par le format de chiffrement lui-même (un checksum,
par exemple). Parfois non. L'attaquant peut avoir beaucoup de mal à
se débrouiller avec des chiffrements en cascade et diverses autres
magouilles (l'inversion du 933ème octet, par exemple).

Mais ces magouilles ne sont pas décemment chiffrables et ne devraient
donc pas intéresser le défenseur. En effet, celui qui chiffre les
données veut deux choses :
-- il veut que ses données restent confidentielles ;
-- il veut en être persuadé _a priori_.

Stricto sensu, il ne veut pas un système inattaquable, il veut un
système inattaqué, et, si possible, que le coût de l'attaque soit
chiffrable précisément. Dans une logique industrielle, un système
à sécurité mesurable, c'est un système pour lequel on peut faire
de la prévision de risques, et donc pour lequel on peut prendre
une assurance. Les assureurs ont horreur des cryptanalystes qui
disent "c'est incassable" parce que cette notion d'incassabilité est
mathématique au lieu d'être comptable. C'est en dehors du monde sur
lequel ils savent faire leur travail.

Cette notion s'étend aux magouilles dont je parle plus haut : oui,
elles compliquent la vie de l'attaquant, mais non, on ne sait pas dire
à quel point. C'est comme le fait de conserver l'algorithme secret :
ça n'arrange pas l'attaquant, qui va devoir se taper le travail de
reverse-engineering. Mais il est très difficile de savoir si l'attaquant
va réussir ledit reverse-engineering, et à quel coût (en temps et en
argent). Donc une politique de sécurité bien sentie ne doit pas se
fonder sur ce genre de choses.


Bizarrement, l'utilisateur moyen, même bien informé, à plus confiance
en ses gadgets personnels (le 933ème octet inversé, remplacer les noms
par des anagrammes, ...) qu'en l'algorithme principal, pourtant étudié
et analysé par des hordes de cryptographes dont c'est le métier. On
pourrait dire que ces amusements sont bels et bons, s'ils permettent
à l'utilisateur de dormir sur ses deux oreilles, mais ils fournissent
un sentiment de fausse sécurité qui pousse l'usager à négliger, à
terme, les précautions qui sont le vrai fondement de la sécurité de ses
données. C'est donc, dans l'ensemble, nuisible.

Par ailleurs, et là c'est avéré, prouvable et incontestable, les
modifications personnelles perdent du temps à tout le monde. L'inversion
du 933ème octet, c'est un ensemble de manipulations qui peuvent être
plus ou moins automatisées, mais qui sont tout de même gonflantes pour
l'utilisateur final.

Auriez-vous des références sur des études portant sur cette immunité des
formes de compression aux perturbations, qualité qui en l'inversant peut
devenir un défaut intéressant en cryptologie ?

Houla non, je ne suis qu'un simple amateur réticent aux règles
mathématiques les plus simples. Mais ça doit se trouver. Je laisse la
parole aux gens qui savent.

Dans l'ensemble, les cryptographes préfèrent ne pas se reposer sur
l'aspect aléatoire d'un système de compression, quand on en est à
faire de la sécurité, parce que ce n'est pas mesurable décemment. Ils
préfèrent avoir des systèmes de chiffrement, qui chiffrent, et des
systèmes de compression, qui compressent.


--Thomas Pornin