AllCrypter : utilisation gratuite jusqu'en 2006

Erwann ABALEA

27/11/2004 à 03:10

On Fri, 26 Nov 2004, Raymond H. wrote:

Qu'en pensez-vous?

Chiffrer et déchiffrer. C'est ce qu'on utilise.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Vous faites chier avec vos annonces à la con ! Ou sont les modérateurs
????? Ca se dégrade cheza Oléane, ca se dégrade ...Ah ouais j'avais
oublié , y'a du Farce Télécom derrière, ca doit être ça ...
-+- PP in: Guide du Neuneu d'Usenet - Tout, faut tout modérer -+-

Raymond H.

27/11/2004 à 03:43

"Sylvain" a écrit dans le message de news:
41a7d3ef$0$16356$

"Raymond H." a écrit

Déjà, quand tu vois ses raisonnements sur les fichiers temporaires dans
Windows... Si tu penses que c'est pas un grand cryptographe, moi
j'ajoute

qu'il est limité en prog Windows.

Concernant les fichiers temporaires que Windows génère, je dis que
lorsque c'est une vidéo d'une grande taille qu'AllCrypter décrypte il
génère

temporairement un fichier (qu'il nettoie et supprime par la suite) afin
d'en

faire la lecture à partir de ce fichier et que Windows n'envoie pas
l'ensemble de ces données (cette vidéo) dans un fichier swap
(temporaire).
Faites-en le test et vous verrez.

ce point étant récurrent, je voudrais recadrer sur ce qui (me) parait
insatisfaisant.

tout d'abord, il n'est aucun "test de windows" à faire car "windows" ne
lit
pas des vidéos, au contraire différents "players" (dont un Windows Media
Player) qui ont chacun leurs règles (codages) utilisent différents codecs
(modules transformant un flux de données en image animées) qui également
ont
leurs règles (codages) propres.

si vous présentez votre logiciel comme permettant de visualiser des vidéos
chiffrées en les déchiffrant à la volée, la question n'est absolument pas
de
savoir comment se comporte tel ou tel sous OCX ou sous codec, mais
uniquement de savoir si vous satisfaisez à votre proposition initiale; il
apparait que ce n'est pas le cas puisque vous créez des copies claires
temporaires et que vous ne donnez aucune garantie sur l'effacement de ces
copies (effacement électro-magnétique s'entend).

Bonjour,

le but n'étant pas la protection absolue du disque contre toutes exécutions
de matériels informatiques sosphistiqués je me limite à un nettoyage normal
et courrant des fichiers temporaires générés par AllCrypter. Sinon, il me
faudrait aussi prévoir l'effacement électro-magnétique du fichier clair qui
sera crypté. Ce fichier original non crypté peut quand même laisser des
traces même en enregistrant le crytogramme par dessus si on considère qu'une
détection sophistiqué électro-magnétique peut discerner jusqu'à 3 couches de
données ou plus. Dans ce cas on entre dans une sphère plus de grande
d'entreprise que du simple Internaute ayant un ordinateur personnel chez
lui. Pourquoi, les autorités apliqueraient se genre de détection sur un
ordinateur d'un simple particulier. Or, AllCrypter se range pour une
population faisant des usages normals, et non pas gouvernemental où tout
doit être fermé aux srcutements externes, d'espionnages gouvernementales
étrangers, car autrement AllCrypter devrait être plus sophistiqué et se
vendrait beaucoup plus cher; je pousse un peu fort mais c'est pour mieux
démontrer le but normal de l'utilisation d'AllCrypter pour le commun du
peuple.

nous (re)répondre que votre "soft n'est pas un firewall" ou nous mettre au
"défit de trouver un film dans un swap système" est tout à fait hors sujet
et ne change rien à ces erreurs fonctionelles, il montre plutôt un
entêtement à ne pas réfléchir à un système cohérent, acceptable et utile
pour l'utilisateur.

un tel système devrait inclure:
- l'option de visualiser un contenu maintenu chiffré sur disque,

Il le fait concernant le fichier source crypté mais pas au niveau des
données décryptées mis en mémoire temporaire pour la lecture qui par la
suite est de toute façon nettoyé puis supprimer pour une protection normale
de ces données. Car de toutes manières, comme déjà mentionné, une image, du
texte ou du son peut être capturé à l'écran... par des logiciels peut
importe quel éditeur affiche cette image ou ce texte, ou en fait la lecture
du son.

- l'option de déchiffrer une fois pour toute ce contenu

dans le premier cas, vous imposez à l'utilisateur un temps d'attente
(création du temp.) non justifié.

Si on parle de fichiers courrament utilisés comme par exemple des MP3
alors le délai d'attente est quand même acceptable à mon avis. Si on écoute
un wav de 1024 ko (1Mo) dans ce cas le délai de décrypage avant la lecture
est de quelques secondes seulement (dépendant des ordinateurs).

dans les deux cas, vous ne pouvez traiter un fichier que si l'espace
disque
libre et au moins égal à sa taille - si l'utilisateur sature son disque il
n'a plus accès à ces documents chiffrés.

Ce n'est pas dans tout les cas que des données décryptés sont mis en
mémoire temporaire d'un fichier par AllCrypter. Dépendant du traitement le
chargement peut se faire en mémoire vive (RAM). Mais ici on parle plus de
données traitées au sein de certaines fenêtres d'AllCrypter qui
habituellement n'ont pas une taille considérable lorsqu'on les traites.

ces limitations aussi évidentes qu'inacceptables ne trouvent peut être pas
de solution dans le fait de glisser un OCX dans un container, en effet,
mais
programmer ne se réalise pas toujours du bout de la souris.

Aussi, je ne prétend pas être un grand cryptographe. Il y a des gens
dont la connaissance en la matière est très élevée et en les lisant
j'essais

d'en tirer leçon. Je dois donc peser les pour et les contres. Ainsi en
est-il en programmation, je ne prétend pas être un super AS de la
programmation.

la question suivante est alors: quelle est votre valeur/compétence ?

Je pense que tout se juge d'après les oeuvres, le résultat. Et le temps
parle par lui-même. Mais comme tous programmeurs si j'en juge pertinent je
suis prêt à l'amélioration de mes produits dans la mesure de mes
compétences.

vous avez, à tout le moins, identifier des usages pouvant être utile aux
utilisateurs; peut être voudrez-vous proposer une plate-forme de
visualisation de contenu multimédia transmis chiffré afin de préserver la
vie privée - les échanges de photos numériques par mail peuvent mériter un
tel traitement - mais vous devrez alors admettre que vous devrez utiliser
des algos crypto. connus et fiables (et libre de droit dans beaucoup de
cas).

Ca serait vraiment chose intéressante à produire.

Cordialement.
r.h.

... à moins qu'il ne s'agisse d' "écouter du MP3" que "les autorités
policières [ne peuvent] décrypter" ... c'est heureusement aussi hors sujet
que fantaisiste donc je stoppe là.

Sylvain.

"Sylvain" <mail@noSpam.net> a écrit dans le message de news:
41a7d3ef$0$16356$8fcfb975@news.wanadoo.fr...

"Raymond H." <divers_rh@hotmail.com> a écrit

Déjà, quand tu vois ses raisonnements sur les fichiers temporaires dans
Windows... Si tu penses que c'est pas un grand cryptographe, moi
j'ajoute

qu'il est limité en prog Windows.

Concernant les fichiers temporaires que Windows génère, je dis que
lorsque c'est une vidéo d'une grande taille qu'AllCrypter décrypte il
génère

temporairement un fichier (qu'il nettoie et supprime par la suite) afin
d'en

faire la lecture à partir de ce fichier et que Windows n'envoie pas
l'ensemble de ces données (cette vidéo) dans un fichier swap
(temporaire).
Faites-en le test et vous verrez.

ce point étant récurrent, je voudrais recadrer sur ce qui (me) parait
insatisfaisant.

tout d'abord, il n'est aucun "test de windows" à faire car "windows" ne
lit
pas des vidéos, au contraire différents "players" (dont un Windows Media
Player) qui ont chacun leurs règles (codages) utilisent différents codecs
(modules transformant un flux de données en image animées) qui également
ont
leurs règles (codages) propres.

si vous présentez votre logiciel comme permettant de visualiser des vidéos
chiffrées en les déchiffrant à la volée, la question n'est absolument pas
de
savoir comment se comporte tel ou tel sous OCX ou sous codec, mais
uniquement de savoir si vous satisfaisez à votre proposition initiale; il
apparait que ce n'est pas le cas puisque vous créez des copies claires
temporaires et que vous ne donnez aucune garantie sur l'effacement de ces
copies (effacement électro-magnétique s'entend).

Bonjour,

le but n'étant pas la protection absolue du disque contre toutes exécutions
de matériels informatiques sosphistiqués je me limite à un nettoyage normal
et courrant des fichiers temporaires générés par AllCrypter. Sinon, il me
faudrait aussi prévoir l'effacement électro-magnétique du fichier clair qui
sera crypté. Ce fichier original non crypté peut quand même laisser des
traces même en enregistrant le crytogramme par dessus si on considère qu'une
détection sophistiqué électro-magnétique peut discerner jusqu'à 3 couches de
données ou plus. Dans ce cas on entre dans une sphère plus de grande
d'entreprise que du simple Internaute ayant un ordinateur personnel chez
lui. Pourquoi, les autorités apliqueraient se genre de détection sur un
ordinateur d'un simple particulier. Or, AllCrypter se range pour une
population faisant des usages normals, et non pas gouvernemental où tout
doit être fermé aux srcutements externes, d'espionnages gouvernementales
étrangers, car autrement AllCrypter devrait être plus sophistiqué et se
vendrait beaucoup plus cher; je pousse un peu fort mais c'est pour mieux
démontrer le but normal de l'utilisation d'AllCrypter pour le commun du
peuple.

nous (re)répondre que votre "soft n'est pas un firewall" ou nous mettre au
"défit de trouver un film dans un swap système" est tout à fait hors sujet
et ne change rien à ces erreurs fonctionelles, il montre plutôt un
entêtement à ne pas réfléchir à un système cohérent, acceptable et utile
pour l'utilisateur.

un tel système devrait inclure:
- l'option de visualiser un contenu maintenu chiffré sur disque,

Il le fait concernant le fichier source crypté mais pas au niveau des
données décryptées mis en mémoire temporaire pour la lecture qui par la
suite est de toute façon nettoyé puis supprimer pour une protection normale
de ces données. Car de toutes manières, comme déjà mentionné, une image, du
texte ou du son peut être capturé à l'écran... par des logiciels peut
importe quel éditeur affiche cette image ou ce texte, ou en fait la lecture
du son.

- l'option de déchiffrer une fois pour toute ce contenu

dans le premier cas, vous imposez à l'utilisateur un temps d'attente
(création du temp.) non justifié.

Si on parle de fichiers courrament utilisés comme par exemple des MP3
alors le délai d'attente est quand même acceptable à mon avis. Si on écoute
un wav de 1024 ko (1Mo) dans ce cas le délai de décrypage avant la lecture
est de quelques secondes seulement (dépendant des ordinateurs).

dans les deux cas, vous ne pouvez traiter un fichier que si l'espace
disque
libre et au moins égal à sa taille - si l'utilisateur sature son disque il
n'a plus accès à ces documents chiffrés.

Ce n'est pas dans tout les cas que des données décryptés sont mis en
mémoire temporaire d'un fichier par AllCrypter. Dépendant du traitement le
chargement peut se faire en mémoire vive (RAM). Mais ici on parle plus de
données traitées au sein de certaines fenêtres d'AllCrypter qui
habituellement n'ont pas une taille considérable lorsqu'on les traites.

ces limitations aussi évidentes qu'inacceptables ne trouvent peut être pas
de solution dans le fait de glisser un OCX dans un container, en effet,
mais
programmer ne se réalise pas toujours du bout de la souris.

Aussi, je ne prétend pas être un grand cryptographe. Il y a des gens
dont la connaissance en la matière est très élevée et en les lisant
j'essais

d'en tirer leçon. Je dois donc peser les pour et les contres. Ainsi en
est-il en programmation, je ne prétend pas être un super AS de la
programmation.

la question suivante est alors: quelle est votre valeur/compétence ?

Je pense que tout se juge d'après les oeuvres, le résultat. Et le temps
parle par lui-même. Mais comme tous programmeurs si j'en juge pertinent je
suis prêt à l'amélioration de mes produits dans la mesure de mes
compétences.

vous avez, à tout le moins, identifier des usages pouvant être utile aux
utilisateurs; peut être voudrez-vous proposer une plate-forme de
visualisation de contenu multimédia transmis chiffré afin de préserver la
vie privée - les échanges de photos numériques par mail peuvent mériter un
tel traitement - mais vous devrez alors admettre que vous devrez utiliser
des algos crypto. connus et fiables (et libre de droit dans beaucoup de
cas).

Ca serait vraiment chose intéressante à produire.

Cordialement.
r.h.

... à moins qu'il ne s'agisse d' "écouter du MP3" que "les autorités
policières [ne peuvent] décrypter" ... c'est heureusement aussi hors sujet
que fantaisiste donc je stoppe là.

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

"Sylvain" a écrit dans le message de news:
41a7d3ef$0$16356$

"Raymond H." a écrit

Déjà, quand tu vois ses raisonnements sur les fichiers temporaires dans
Windows... Si tu penses que c'est pas un grand cryptographe, moi
j'ajoute

qu'il est limité en prog Windows.

Concernant les fichiers temporaires que Windows génère, je dis que
lorsque c'est une vidéo d'une grande taille qu'AllCrypter décrypte il
génère

temporairement un fichier (qu'il nettoie et supprime par la suite) afin
d'en

faire la lecture à partir de ce fichier et que Windows n'envoie pas
l'ensemble de ces données (cette vidéo) dans un fichier swap
(temporaire).
Faites-en le test et vous verrez.

ce point étant récurrent, je voudrais recadrer sur ce qui (me) parait
insatisfaisant.

tout d'abord, il n'est aucun "test de windows" à faire car "windows" ne
lit
pas des vidéos, au contraire différents "players" (dont un Windows Media
Player) qui ont chacun leurs règles (codages) utilisent différents codecs
(modules transformant un flux de données en image animées) qui également
ont
leurs règles (codages) propres.

si vous présentez votre logiciel comme permettant de visualiser des vidéos
chiffrées en les déchiffrant à la volée, la question n'est absolument pas
de
savoir comment se comporte tel ou tel sous OCX ou sous codec, mais
uniquement de savoir si vous satisfaisez à votre proposition initiale; il
apparait que ce n'est pas le cas puisque vous créez des copies claires
temporaires et que vous ne donnez aucune garantie sur l'effacement de ces
copies (effacement électro-magnétique s'entend).

Bonjour,

le but n'étant pas la protection absolue du disque contre toutes exécutions
de matériels informatiques sosphistiqués je me limite à un nettoyage normal
et courrant des fichiers temporaires générés par AllCrypter. Sinon, il me
faudrait aussi prévoir l'effacement électro-magnétique du fichier clair qui
sera crypté. Ce fichier original non crypté peut quand même laisser des
traces même en enregistrant le crytogramme par dessus si on considère qu'une
détection sophistiqué électro-magnétique peut discerner jusqu'à 3 couches de
données ou plus. Dans ce cas on entre dans une sphère plus de grande
d'entreprise que du simple Internaute ayant un ordinateur personnel chez
lui. Pourquoi, les autorités apliqueraient se genre de détection sur un
ordinateur d'un simple particulier. Or, AllCrypter se range pour une
population faisant des usages normals, et non pas gouvernemental où tout
doit être fermé aux srcutements externes, d'espionnages gouvernementales
étrangers, car autrement AllCrypter devrait être plus sophistiqué et se
vendrait beaucoup plus cher; je pousse un peu fort mais c'est pour mieux
démontrer le but normal de l'utilisation d'AllCrypter pour le commun du
peuple.

nous (re)répondre que votre "soft n'est pas un firewall" ou nous mettre au
"défit de trouver un film dans un swap système" est tout à fait hors sujet
et ne change rien à ces erreurs fonctionelles, il montre plutôt un
entêtement à ne pas réfléchir à un système cohérent, acceptable et utile
pour l'utilisateur.

un tel système devrait inclure:
- l'option de visualiser un contenu maintenu chiffré sur disque,

Il le fait concernant le fichier source crypté mais pas au niveau des
données décryptées mis en mémoire temporaire pour la lecture qui par la
suite est de toute façon nettoyé puis supprimer pour une protection normale
de ces données. Car de toutes manières, comme déjà mentionné, une image, du
texte ou du son peut être capturé à l'écran... par des logiciels peut
importe quel éditeur affiche cette image ou ce texte, ou en fait la lecture
du son.

- l'option de déchiffrer une fois pour toute ce contenu

dans le premier cas, vous imposez à l'utilisateur un temps d'attente
(création du temp.) non justifié.

Si on parle de fichiers courrament utilisés comme par exemple des MP3
alors le délai d'attente est quand même acceptable à mon avis. Si on écoute
un wav de 1024 ko (1Mo) dans ce cas le délai de décrypage avant la lecture
est de quelques secondes seulement (dépendant des ordinateurs).

dans les deux cas, vous ne pouvez traiter un fichier que si l'espace
disque
libre et au moins égal à sa taille - si l'utilisateur sature son disque il
n'a plus accès à ces documents chiffrés.

Ce n'est pas dans tout les cas que des données décryptés sont mis en
mémoire temporaire d'un fichier par AllCrypter. Dépendant du traitement le
chargement peut se faire en mémoire vive (RAM). Mais ici on parle plus de
données traitées au sein de certaines fenêtres d'AllCrypter qui
habituellement n'ont pas une taille considérable lorsqu'on les traites.

ces limitations aussi évidentes qu'inacceptables ne trouvent peut être pas
de solution dans le fait de glisser un OCX dans un container, en effet,
mais
programmer ne se réalise pas toujours du bout de la souris.

Aussi, je ne prétend pas être un grand cryptographe. Il y a des gens
dont la connaissance en la matière est très élevée et en les lisant
j'essais

d'en tirer leçon. Je dois donc peser les pour et les contres. Ainsi en
est-il en programmation, je ne prétend pas être un super AS de la
programmation.

la question suivante est alors: quelle est votre valeur/compétence ?

Je pense que tout se juge d'après les oeuvres, le résultat. Et le temps
parle par lui-même. Mais comme tous programmeurs si j'en juge pertinent je
suis prêt à l'amélioration de mes produits dans la mesure de mes
compétences.

vous avez, à tout le moins, identifier des usages pouvant être utile aux
utilisateurs; peut être voudrez-vous proposer une plate-forme de
visualisation de contenu multimédia transmis chiffré afin de préserver la
vie privée - les échanges de photos numériques par mail peuvent mériter un
tel traitement - mais vous devrez alors admettre que vous devrez utiliser
des algos crypto. connus et fiables (et libre de droit dans beaucoup de
cas).

Ca serait vraiment chose intéressante à produire.

Cordialement.
r.h.

... à moins qu'il ne s'agisse d' "écouter du MP3" que "les autorités
policières [ne peuvent] décrypter" ... c'est heureusement aussi hors sujet
que fantaisiste donc je stoppe là.

Sylvain.

AMcD®

27/11/2004 à 04:13

Raymond H. wrote:

J'utilise aussi ces mots car ils sont très largement
employés par la population Internaute.

En français ? Jamais vu ça, ou alors, chez des neuneus frangloïdes
peut-être...

Les termes convenus courants sont :

Texte original de départ -> Texte clair
Procédé utilisé pour rendre inintelligible ton texte clair -> Chiffrement
Texte inintelligible obtenu -> Texte chiffré
Science du chiffrement -> Cryptographie
Adeptes de la Cryptographie -> Cryptographes

Procédé utilisé pour rendre intelligible ton texte chiffré -> Déchiffrement
Texte intelligible obtenu -> ben texte clair :-)
Science du déchiffrement -> Cryptanalyse
Adeptes de la Cryptanalyse -> Cryptanalystes

Science qui regroupe la Cryptographie et la Cryptanalyse -> Cryptologie
Adeptes de la Cryptologie -> Cryptologues

Note que si tu ne connais pas le mécanisme de chiffrement, en théorie tu ne
parleras pas de déchiffrement mais de Décryptage ou Décryptement. Pour ma
part je n'ai que rarement vu utilisé décryptement, mais bon...

Enfin, d'aucuns appelent Cryptage le chiffrement et le texte chiffré est
parfois désigné sous le vocable de Cryptogramme.

Il existe un terme très difficile à te définir en peu de termes, le
Cédépégramme, mais bon, il se fait tard :-).

--
AMcD®

http://arnold.mcdonald.free.fr/

Erwann ABALEA

27/11/2004 à 05:07

On Fri, 26 Nov 2004, Jacques Caron wrote:

On Fri, 26 Nov 2004 07:11:55 -0500, Guillermito
wrote:

Oui, l'algorithme n'utilise apparemment pas tous les bits de la clef
(elle-même déjà limitée puisque ASCII), que les 5 bits de poids faible.
On a le même résultat avec "àààà".

Attention, la version encodée de la clef ne dit rien de l'utilisation qui
est en faite dans l'encodage du texte: on peut avoir deux clefs qui

La clé utilisée n'est pas celle stockée. Les 8 bits de chaque octet sont
utilisés (on ne peut pas saisir d'octet à 00, j'ai joué avec des octets
0xff, 0xfe, 0xfd).

Ce qui me surprend un peu, mais à la limite ça prouve qu'il n'y a vraiment
aucune logique, c'est qu'a priori la version encodée de la clef fait 2 x
la longueur de la clef - 1 octet, alors que le texte encodé fait la
longueur du texte + 1

Après la signature 'LogiciPC_AllCrypter', il y a un CRLF, puis 2
caractères: le premier prend les valeurs '0' ou '1' pour indiquer si la
clé est stockée dans le chiffré pour vérification (auquel cas elle fait
partie du clair et rentre dans le processus de chiffrement), et le
deuxième prend les valeurs '1', '2' ou '3' selon le "niveau" de
chiffrement.

J'ai fait mes tests sans stocker la clé, en mode 1.

Ceci dit, a priori je table pour:
- quelques permutations de bits pas forcément futées
- des soustractioins ou des XORs entre octets de la clef qui sont ensuite
permutées et mélangées avec le reste

Je pense qu'il n'y a pas de permutation, du moins pas au niveau des octets
traités.
Il semblerait que les octets du clair soient traités l'un après l'autre,
indifféremment des autres. Si on change le premier octet du clair, ça ne
change que le premier octet du chiffré, par exemple. Et si on change un
octet de la clé, le nombre d'octets du chiffré qui change dépend de
l'octet changé (j'ai testé sur des clés de 8 octets, le premier octet
impacte les octets de rang 15 mod 16, le dernier octet impacte les octets
1 et 14 mod 16).
Avec une clé de n octets, on retrouve dans le chiffré des patterns de
taille de 2n octets, et le chiffré dépend aussi du rang du "pattern". Par
exemple, avec une clé de n octets, un clair de 2 fois 2n octets identiques
donnera un chiffré de 2 fois 2n octets dont la valeur sera augmentée de 2n
dans le second. (un chiffré en 1ère position aura pour valeurs 0x81
dans le premier bloc et 0x91 dans le second, avec n=8).

Et enfin il semble que la transformation clair->chiffré ne soit pas très
complexe. En testant différents clairs avec la même clé, j'ai remarqué que
quand j'incrémentais un clair, j'incrémentais d'autant le chiffré
(0x30->0x11, 0x31->0x12, 0x32->0x13, par exemple), mais pas toujours.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
JE SUIS TOTALEMENT DE TON AVIS !!
Ton argumentation reflète EXACTEMENT ce que je pense.
Il fallait que je le dise même si ça ne fait pas avancé le scmilblick
-+- Tigrou yodèle in GNU - AOL hi hi, la la la itou -+-

On Fri, 26 Nov 2004, Jacques Caron wrote:

On Fri, 26 Nov 2004 07:11:55 -0500, Guillermito <guillermito@pipo.com>
wrote:

Oui, l'algorithme n'utilise apparemment pas tous les bits de la clef
(elle-même déjà limitée puisque ASCII), que les 5 bits de poids faible.
On a le même résultat avec "àààà".

Attention, la version encodée de la clef ne dit rien de l'utilisation qui
est en faite dans l'encodage du texte: on peut avoir deux clefs qui

La clé utilisée n'est pas celle stockée. Les 8 bits de chaque octet sont
utilisés (on ne peut pas saisir d'octet à 00, j'ai joué avec des octets
0xff, 0xfe, 0xfd).

Ce qui me surprend un peu, mais à la limite ça prouve qu'il n'y a vraiment
aucune logique, c'est qu'a priori la version encodée de la clef fait 2 x
la longueur de la clef - 1 octet, alors que le texte encodé fait la
longueur du texte + 1

Après la signature 'LogiciPC_AllCrypter', il y a un CRLF, puis 2
caractères: le premier prend les valeurs '0' ou '1' pour indiquer si la
clé est stockée dans le chiffré pour vérification (auquel cas elle fait
partie du clair et rentre dans le processus de chiffrement), et le
deuxième prend les valeurs '1', '2' ou '3' selon le "niveau" de
chiffrement.

J'ai fait mes tests sans stocker la clé, en mode 1.

Ceci dit, a priori je table pour:
- quelques permutations de bits pas forcément futées
- des soustractioins ou des XORs entre octets de la clef qui sont ensuite
permutées et mélangées avec le reste

Je pense qu'il n'y a pas de permutation, du moins pas au niveau des octets
traités.
Il semblerait que les octets du clair soient traités l'un après l'autre,
indifféremment des autres. Si on change le premier octet du clair, ça ne
change que le premier octet du chiffré, par exemple. Et si on change un
octet de la clé, le nombre d'octets du chiffré qui change dépend de
l'octet changé (j'ai testé sur des clés de 8 octets, le premier octet
impacte les octets de rang 15 mod 16, le dernier octet impacte les octets
1 et 14 mod 16).
Avec une clé de n octets, on retrouve dans le chiffré des patterns de
taille de 2n octets, et le chiffré dépend aussi du rang du "pattern". Par
exemple, avec une clé de n octets, un clair de 2 fois 2n octets identiques
donnera un chiffré de 2 fois 2n octets dont la valeur sera augmentée de 2n
dans le second. (un chiffré en 1ère position aura pour valeurs 0x81
dans le premier bloc et 0x91 dans le second, avec n=8).

Et enfin il semble que la transformation clair->chiffré ne soit pas très
complexe. En testant différents clairs avec la même clé, j'ai remarqué que
quand j'incrémentais un clair, j'incrémentais d'autant le chiffré
(0x30->0x11, 0x31->0x12, 0x32->0x13, par exemple), mais pas toujours.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
JE SUIS TOTALEMENT DE TON AVIS !!
Ton argumentation reflète EXACTEMENT ce que je pense.
Il fallait que je le dise même si ça ne fait pas avancé le scmilblick
-+- Tigrou yodèle in GNU - AOL hi hi, la la la itou -+-

Vous avez filtré cet utilisateur ! Consultez son message

On Fri, 26 Nov 2004, Jacques Caron wrote:

On Fri, 26 Nov 2004 07:11:55 -0500, Guillermito
wrote:

Oui, l'algorithme n'utilise apparemment pas tous les bits de la clef
(elle-même déjà limitée puisque ASCII), que les 5 bits de poids faible.
On a le même résultat avec "àààà".

Attention, la version encodée de la clef ne dit rien de l'utilisation qui
est en faite dans l'encodage du texte: on peut avoir deux clefs qui

La clé utilisée n'est pas celle stockée. Les 8 bits de chaque octet sont
utilisés (on ne peut pas saisir d'octet à 00, j'ai joué avec des octets
0xff, 0xfe, 0xfd).

Ce qui me surprend un peu, mais à la limite ça prouve qu'il n'y a vraiment
aucune logique, c'est qu'a priori la version encodée de la clef fait 2 x
la longueur de la clef - 1 octet, alors que le texte encodé fait la
longueur du texte + 1

Après la signature 'LogiciPC_AllCrypter', il y a un CRLF, puis 2
caractères: le premier prend les valeurs '0' ou '1' pour indiquer si la
clé est stockée dans le chiffré pour vérification (auquel cas elle fait
partie du clair et rentre dans le processus de chiffrement), et le
deuxième prend les valeurs '1', '2' ou '3' selon le "niveau" de
chiffrement.

J'ai fait mes tests sans stocker la clé, en mode 1.

Ceci dit, a priori je table pour:
- quelques permutations de bits pas forcément futées
- des soustractioins ou des XORs entre octets de la clef qui sont ensuite
permutées et mélangées avec le reste

Je pense qu'il n'y a pas de permutation, du moins pas au niveau des octets
traités.
Il semblerait que les octets du clair soient traités l'un après l'autre,
indifféremment des autres. Si on change le premier octet du clair, ça ne
change que le premier octet du chiffré, par exemple. Et si on change un
octet de la clé, le nombre d'octets du chiffré qui change dépend de
l'octet changé (j'ai testé sur des clés de 8 octets, le premier octet
impacte les octets de rang 15 mod 16, le dernier octet impacte les octets
1 et 14 mod 16).
Avec une clé de n octets, on retrouve dans le chiffré des patterns de
taille de 2n octets, et le chiffré dépend aussi du rang du "pattern". Par
exemple, avec une clé de n octets, un clair de 2 fois 2n octets identiques
donnera un chiffré de 2 fois 2n octets dont la valeur sera augmentée de 2n
dans le second. (un chiffré en 1ère position aura pour valeurs 0x81
dans le premier bloc et 0x91 dans le second, avec n=8).

Et enfin il semble que la transformation clair->chiffré ne soit pas très
complexe. En testant différents clairs avec la même clé, j'ai remarqué que
quand j'incrémentais un clair, j'incrémentais d'autant le chiffré
(0x30->0x11, 0x31->0x12, 0x32->0x13, par exemple), mais pas toujours.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
JE SUIS TOTALEMENT DE TON AVIS !!
Ton argumentation reflète EXACTEMENT ce que je pense.
Il fallait que je le dise même si ça ne fait pas avancé le scmilblick
-+- Tigrou yodèle in GNU - AOL hi hi, la la la itou -+-

Raymond H.

27/11/2004 à 07:00

"AMcD®" a écrit dans le message de news:
41a7f0ed$0$17076$

Raymond H. wrote:

J'utilise aussi ces mots car ils sont très largement
employés par la population Internaute.

En français ? Jamais vu ça, ou alors, chez des neuneus frangloïdes
peut-être...

Les termes convenus courants sont :

Texte original de départ -> Texte clair
Procédé utilisé pour rendre inintelligible ton texte clair -> Chiffrement
Texte inintelligible obtenu -> Texte chiffré
Science du chiffrement -> Cryptographie
Adeptes de la Cryptographie -> Cryptographes

Procédé utilisé pour rendre intelligible ton texte chiffré ->
Déchiffrement
Texte intelligible obtenu -> ben texte clair :-)
Science du déchiffrement -> Cryptanalyse
Adeptes de la Cryptanalyse -> Cryptanalystes

Science qui regroupe la Cryptographie et la Cryptanalyse -> Cryptologie
Adeptes de la Cryptologie -> Cryptologues

Note que si tu ne connais pas le mécanisme de chiffrement, en théorie tu
ne parleras pas de déchiffrement mais de Décryptage ou Décryptement. Pour
ma part je n'ai que rarement vu utilisé décryptement, mais bon...

Enfin, d'aucuns appelent Cryptage le chiffrement et le texte chiffré est
parfois désigné sous le vocable de Cryptogramme.

Il existe un terme très difficile à te définir en peu de termes, le
Cédépégramme, mais bon, il se fait tard :-).

--
AMcD®

http://arnold.mcdonald.free.fr/
Pourriez-vous me dire où vous prenez ces définitions? J'aimerais bien

vérifier ce que dit votre bouquin (ou autre) au sujet des mots de la même
famille que 'coder' et 'cryptage'...
Merci pour ces définitions
r.h.

Erwann ABALEA

27/11/2004 à 09:01

On Sat, 27 Nov 2004, Raymond H. wrote:

[... plein de bons mots ...]

Pourriez-vous me dire où vous prenez ces définitions? J'aimerais bien
vérifier ce que dit votre bouquin (ou autre) au sujet des mots de la même
famille que 'coder' et 'cryptage'...

Attention, coder et chiffrer ne sont pas synonymes, et je ne pense pas que
le petit Robert ou le Larousse vous donne une définition de ces termes
assez précise pour comprendre cela.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Je propose que chacun de nous expose le problème (et dénoncent les
fufeurs, cf liste des votants, ceux qui ont voté NNO sont les fufeurs)
à son FAI.
-+- Rocou In GNU - Comment tu écris Kommandantur ? -+-

Raymond H.

27/11/2004 à 09:32

"Erwann ABALEA" a écrit dans le message de news:

On Sat, 27 Nov 2004, Raymond H. wrote:

[... plein de bons mots ...]

Pourriez-vous me dire où vous prenez ces définitions? J'aimerais bien
vérifier ce que dit votre bouquin (ou autre) au sujet des mots de la même
famille que 'coder' et 'cryptage'...

Attention, coder et chiffrer ne sont pas synonymes, et je ne pense pas que
le petit Robert ou le Larousse vous donne une définition de ces termes
assez précise pour comprendre cela.

Quelqu'un pourrait-il en donner la différence? Mais que serait le contraire
de 'Crypter'? Puisque 'Décrypter' a une définition qui dit que c'est
déchiffrer des données sans posséder la clef.
r.h.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Je propose que chacun de nous expose le problème (et dénoncent les
fufeurs, cf liste des votants, ceux qui ont voté NNO sont les fufeurs)
à son FAI.
-+- Rocou In GNU - Comment tu écris Kommandantur ? -+-

Erwann ABALEA

27/11/2004 à 10:30

On Sat, 27 Nov 2004, Raymond H. wrote:

"Erwann ABALEA" a écrit dans le message de news:

On Sat, 27 Nov 2004, Raymond H. wrote:

[... plein de bons mots ...]

Pourriez-vous me dire où vous prenez ces définitions? J'aimerais bien
vérifier ce que dit votre bouquin (ou autre) au sujet des mots de la même
famille que 'coder' et 'cryptage'...

Attention, coder et chiffrer ne sont pas synonymes, et je ne pense pas que
le petit Robert ou le Larousse vous donne une définition de ces termes
assez précise pour comprendre cela.

Quelqu'un pourrait-il en donner la différence? Mais que serait le contraire

Coder, c'est changer la représentation de l'information, sans la masquer
par une clé. Par exemple l'encodage Base64, ou la transformation Binaire
-> dump hexa. C'est un processus réversible, complètement connu, qui
n'apporte aucune sécurité (puisqu'il n'est fait appel à aucun élément
secret).

de 'Crypter'? Puisque 'Décrypter' a une définition qui dit que c'est
déchiffrer des données sans posséder la clef.

On n'utilise pas crypter, mais chiffrer, et son contraire est déchiffrer.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Demande éclaircissements: - que signifie "Suivi-à positionné sur fuad"?
"quoter" je présume voulant dire, raccourcir? "gâchi des ressources"
comment ça? C'est qui, quoi, Usenet.abus ? et vous-même qui êtes vous ?
-+- AH in: Guide du Neuneu d'Usenet - Questions pour un champion -+-

AMcD®

27/11/2004 à 12:53

Raymond H. wrote:

Pourriez-vous me dire où vous prenez ces définitions? J'aimerais bien
vérifier ce que dit votre bouquin (ou autre) au sujet des mots de la
même famille que 'coder' et 'cryptage'...

Pour coder/encoder et décoder/désencoder, que j'ai oublié, tu peux te baser
sur ce que dit E. ABALEA.

Pour l'origine des termes, dans X bouquins sérieux. Il te faut parfois
panacher entre plusieurs titres, vu que tous ne donnent pas la liste
complète des termes. Au hasard (j'ai la flemme de me lever jusqu'à ma
bibliothèque, je tire à vue ;-) ) :

Jacques Stern - La Science du Secret ;
Alfred Menezes - Applied Cryptography ;
William Stallings - Cryptography and Network Security ;
Bruce Schneier - Applied Cryptography ;
Douglas Stinson - Cryptographie : Théorie et Pratique.

Parcours les introductions, les premiers chapitres ou les index :-).

Merci pour ces définitions

De rien. Au passage je lis plus bas dans une de tes réponses :

Puisque 'Décrypter' a une définition qui dit que c'est
déchiffrer des données sans posséder la clef.

Decrypter ce n'est pas déchiffrer sans connaître la clé, c'est déchiffrer
sans rien connaître du tout à priori, ni l'algorithme de chiffrement, ni la
clé, ni la langue, rien.

--
AMcD®

http://arnold.mcdonald.free.fr/

Patrick 'Zener' Brunet

27/11/2004 à 15:39

Bonjour.

"Thomas Pornin" a écrit dans le message de news:
co7mcc$1apo$

According to Patrick 'Zener' Brunet <http://zener131.free.fr/ContactMe>:
De toute manière, l'objectif lui-même est un peu théorique, puisque si
l'on

décode de la vidéo (ou du son ou quoique ce soit d'autre) pour
l'injecter

dans un stream, même s'il est possible de le faire à la volée sans créer
une

version en clair de l'ensemble, il sera toujours possible de recapturer
le

signal au niveau du stream (voire de la sortie écran ou audio) pour le
réenregistrer en clair (ce qui au passage fout en l'air le principe même
de

la protection de CD ou de DVD, à moins qu'on n'ait plus le droit de même
les

visionner !!!!).

Soyons précis : le modèle n'est pas le même. Il est vrai que lorsqu'une
donnée doit être traitée par la machine, elle est fatalement disponible
en clair dans la mémoire de cette machine à un moment donné(*), et donc
si la machine est compromise à ce moment, c'est mort.

Existante en clair ne veut pas forcément dire disponible (Gnark²), c'était
le sens des astuces anti-cracking que j'évoquais.

Ce que je voulais dire, c'est que l'hypothèse même que le logiciel puisse
prendre des précautions par rapport à son utilisateur sous-entend que
celui-ci puisse être un usurpateur ou veuille outrepasser les droits qui lui
ont été donnés. Il y a donc un contexte commun qui est celui du piratage,
qu'il soit commis par un tiers sur une machine volée ou par l'utilisateur
prévu qui cherche à outrepasser sa licence.

Je citerai comme exemple (assez pitoyable) le streaming audio ou vidéo sur
Internet, qui est supposé permettre de jouer un clip sans pouvoir le
conserver. Je crois que c'est surtout le problème de débit insuffisant qui a
motivé les développeurs d'utilitaires de capture.

Mais donc dès lors qu'il y a une forme de sortie de l'information en clair,
selon moi cet objectif même de défiance du logiciel envers son utilisateur
est aussi approprié qu'un accès top secret avec identification renforcée
pour atteindre un site web public.
Par contre si le logiciel reste une boîte noire sans face vitrée, on peut
l'envisager avec des précautions adéquates. La carte à puce utilisée
intelligemment est un bon exemple (mais matériel). Avec du soft, c'est plus
difficile, mais ... seulement difficile.

[...]

Finalement c'est cet aspect jeu d'échecs qui rend la crypto
passionnante, non ?

Jusqu'à un certain point. La cryptographie moderne essaye de plus en
plus de faire des preuves de sécurité, afin de sortir du modèle où le
système est sûr parce que le concepteur serait plus "malin" ou "rusé"
que l'attaquant. On préfère des systèmes sûrs parce qu'ils reposent sur
une structure mathématiquement justifiée.

Ben justement, depuis que j'étudie et mène moi-même des recherches dans ce
domaine, je n'ai trouvé que le Chiffrement de Vernam qui soit prouvé
définitivement robuste.
Mais il ne fait en fait que transposer le problème du message à une clé de
même longueur.

Les registres à décalage pourraient dans une certaine mesure permettre de
réduire la longueur de la clé sans perte de sécurité (et encore je n'ai pas
trouvé de garantie formelle, diverses attaques existent).

Tout le reste repose sur des problèmes "difficiles", des tiers "de
confiance", des conditions technologiques "actuellement inaccessibles", ou
des éléments "physiques"(*). Je ne vois précisément rien là-dedans de
"mathématiquement justifié", qui permette de s'engager formellement pour un
avenir de seulement quelques années.

(*) qui autorisent un scénario d'attaque du medium, forçant le repli sur un
système d'échange plus vulnérable (Internet avait été conçu précisément pour
éviter ça).

Donc les scénarios à la Jim Phelps resteront bien d'actualité je crois, tant
que quelque génie n'aura pas trouvé un substitut à l'échange de
Diffie-Hellman (ou équivalents) reposant sur un problème définitivement
indéterminé, et assorti d'une parade sans tiers de confiance à l'attaque par
usurpation.

Je me demande même s'il n'est pas possible de prouver mathématiquement qu'un
tel système ne peut pas exister, c'est à dire qu'aucune preuve "Zero
Knowledge" ne puisse être fondée sur un tel problème. Mes compétences en
épistémologie ne sont pas suffisantes, et je n'arrive pas à trouver des
sources abordables (je suis en fait cybernéticien, et un peu rouillé en
maths, malgré un très bon niveau autrefois).

J'ai déjà lancé des threads sur ce thème ici et sur le forum des maths, sans
succès.

Si vous connaissez de telles sources, ça m'intéresse énormément, merci
d'avance.

Cordialement,

PS: Savez-vous comment faire de cette ramification un nouveau thread, là ça
va se perdre dans le débat presque clos sur AllCrypter ?

--

/**************************************************************
* Patrick BRUNET @ ZenerTopia
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************************/
<8#--X--< filtré par Avast! 4 Home

Bonjour.

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

According to Patrick 'Zener' Brunet <http://zener131.free.fr/ContactMe>:

De toute manière, l'objectif lui-même est un peu théorique, puisque si
l'on

décode de la vidéo (ou du son ou quoique ce soit d'autre) pour
l'injecter

dans un stream, même s'il est possible de le faire à la volée sans créer
une

version en clair de l'ensemble, il sera toujours possible de recapturer
le

signal au niveau du stream (voire de la sortie écran ou audio) pour le
réenregistrer en clair (ce qui au passage fout en l'air le principe même
de

la protection de CD ou de DVD, à moins qu'on n'ait plus le droit de même
les

visionner !!!!).

Soyons précis : le modèle n'est pas le même. Il est vrai que lorsqu'une
donnée doit être traitée par la machine, elle est fatalement disponible
en clair dans la mémoire de cette machine à un moment donné(*), et donc
si la machine est compromise à ce moment, c'est mort.

Existante en clair ne veut pas forcément dire disponible (Gnark²), c'était
le sens des astuces anti-cracking que j'évoquais.

Ce que je voulais dire, c'est que l'hypothèse même que le logiciel puisse
prendre des précautions par rapport à son utilisateur sous-entend que
celui-ci puisse être un usurpateur ou veuille outrepasser les droits qui lui
ont été donnés. Il y a donc un contexte commun qui est celui du piratage,
qu'il soit commis par un tiers sur une machine volée ou par l'utilisateur
prévu qui cherche à outrepasser sa licence.

Je citerai comme exemple (assez pitoyable) le streaming audio ou vidéo sur
Internet, qui est supposé permettre de jouer un clip sans pouvoir le
conserver. Je crois que c'est surtout le problème de débit insuffisant qui a
motivé les développeurs d'utilitaires de capture.

Mais donc dès lors qu'il y a une forme de sortie de l'information en clair,
selon moi cet objectif même de défiance du logiciel envers son utilisateur
est aussi approprié qu'un accès top secret avec identification renforcée
pour atteindre un site web public.
Par contre si le logiciel reste une boîte noire sans face vitrée, on peut
l'envisager avec des précautions adéquates. La carte à puce utilisée
intelligemment est un bon exemple (mais matériel). Avec du soft, c'est plus
difficile, mais ... seulement difficile.

[...]

Finalement c'est cet aspect jeu d'échecs qui rend la crypto
passionnante, non ?

Jusqu'à un certain point. La cryptographie moderne essaye de plus en
plus de faire des preuves de sécurité, afin de sortir du modèle où le
système est sûr parce que le concepteur serait plus "malin" ou "rusé"
que l'attaquant. On préfère des systèmes sûrs parce qu'ils reposent sur
une structure mathématiquement justifiée.

Ben justement, depuis que j'étudie et mène moi-même des recherches dans ce
domaine, je n'ai trouvé que le Chiffrement de Vernam qui soit prouvé
définitivement robuste.
Mais il ne fait en fait que transposer le problème du message à une clé de
même longueur.

Les registres à décalage pourraient dans une certaine mesure permettre de
réduire la longueur de la clé sans perte de sécurité (et encore je n'ai pas
trouvé de garantie formelle, diverses attaques existent).

Tout le reste repose sur des problèmes "difficiles", des tiers "de
confiance", des conditions technologiques "actuellement inaccessibles", ou
des éléments "physiques"(*). Je ne vois précisément rien là-dedans de
"mathématiquement justifié", qui permette de s'engager formellement pour un
avenir de seulement quelques années.

(*) qui autorisent un scénario d'attaque du medium, forçant le repli sur un
système d'échange plus vulnérable (Internet avait été conçu précisément pour
éviter ça).

Donc les scénarios à la Jim Phelps resteront bien d'actualité je crois, tant
que quelque génie n'aura pas trouvé un substitut à l'échange de
Diffie-Hellman (ou équivalents) reposant sur un problème définitivement
indéterminé, et assorti d'une parade sans tiers de confiance à l'attaque par
usurpation.

Je me demande même s'il n'est pas possible de prouver mathématiquement qu'un
tel système ne peut pas exister, c'est à dire qu'aucune preuve "Zero
Knowledge" ne puisse être fondée sur un tel problème. Mes compétences en
épistémologie ne sont pas suffisantes, et je n'arrive pas à trouver des
sources abordables (je suis en fait cybernéticien, et un peu rouillé en
maths, malgré un très bon niveau autrefois).

J'ai déjà lancé des threads sur ce thème ici et sur le forum des maths, sans
succès.

Si vous connaissez de telles sources, ça m'intéresse énormément, merci
d'avance.

Cordialement,

PS: Savez-vous comment faire de cette ramification un nouveau thread, là ça
va se perdre dans le débat presque clos sur AllCrypter ?

--

/**************************************************************
* Patrick BRUNET @ ZenerTopia
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************************/
<8#--X--< filtré par Avast! 4 Home

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour.

"Thomas Pornin" a écrit dans le message de news:
co7mcc$1apo$

According to Patrick 'Zener' Brunet <http://zener131.free.fr/ContactMe>:
De toute manière, l'objectif lui-même est un peu théorique, puisque si
l'on

décode de la vidéo (ou du son ou quoique ce soit d'autre) pour
l'injecter

dans un stream, même s'il est possible de le faire à la volée sans créer
une

version en clair de l'ensemble, il sera toujours possible de recapturer
le

signal au niveau du stream (voire de la sortie écran ou audio) pour le
réenregistrer en clair (ce qui au passage fout en l'air le principe même
de

la protection de CD ou de DVD, à moins qu'on n'ait plus le droit de même
les

visionner !!!!).

Soyons précis : le modèle n'est pas le même. Il est vrai que lorsqu'une
donnée doit être traitée par la machine, elle est fatalement disponible
en clair dans la mémoire de cette machine à un moment donné(*), et donc
si la machine est compromise à ce moment, c'est mort.

Existante en clair ne veut pas forcément dire disponible (Gnark²), c'était
le sens des astuces anti-cracking que j'évoquais.

Ce que je voulais dire, c'est que l'hypothèse même que le logiciel puisse
prendre des précautions par rapport à son utilisateur sous-entend que
celui-ci puisse être un usurpateur ou veuille outrepasser les droits qui lui
ont été donnés. Il y a donc un contexte commun qui est celui du piratage,
qu'il soit commis par un tiers sur une machine volée ou par l'utilisateur
prévu qui cherche à outrepasser sa licence.

Je citerai comme exemple (assez pitoyable) le streaming audio ou vidéo sur
Internet, qui est supposé permettre de jouer un clip sans pouvoir le
conserver. Je crois que c'est surtout le problème de débit insuffisant qui a
motivé les développeurs d'utilitaires de capture.

Mais donc dès lors qu'il y a une forme de sortie de l'information en clair,
selon moi cet objectif même de défiance du logiciel envers son utilisateur
est aussi approprié qu'un accès top secret avec identification renforcée
pour atteindre un site web public.
Par contre si le logiciel reste une boîte noire sans face vitrée, on peut
l'envisager avec des précautions adéquates. La carte à puce utilisée
intelligemment est un bon exemple (mais matériel). Avec du soft, c'est plus
difficile, mais ... seulement difficile.

[...]

Finalement c'est cet aspect jeu d'échecs qui rend la crypto
passionnante, non ?

Jusqu'à un certain point. La cryptographie moderne essaye de plus en
plus de faire des preuves de sécurité, afin de sortir du modèle où le
système est sûr parce que le concepteur serait plus "malin" ou "rusé"
que l'attaquant. On préfère des systèmes sûrs parce qu'ils reposent sur
une structure mathématiquement justifiée.

Ben justement, depuis que j'étudie et mène moi-même des recherches dans ce
domaine, je n'ai trouvé que le Chiffrement de Vernam qui soit prouvé
définitivement robuste.
Mais il ne fait en fait que transposer le problème du message à une clé de
même longueur.

Les registres à décalage pourraient dans une certaine mesure permettre de
réduire la longueur de la clé sans perte de sécurité (et encore je n'ai pas
trouvé de garantie formelle, diverses attaques existent).

Tout le reste repose sur des problèmes "difficiles", des tiers "de
confiance", des conditions technologiques "actuellement inaccessibles", ou
des éléments "physiques"(*). Je ne vois précisément rien là-dedans de
"mathématiquement justifié", qui permette de s'engager formellement pour un
avenir de seulement quelques années.

(*) qui autorisent un scénario d'attaque du medium, forçant le repli sur un
système d'échange plus vulnérable (Internet avait été conçu précisément pour
éviter ça).

Donc les scénarios à la Jim Phelps resteront bien d'actualité je crois, tant
que quelque génie n'aura pas trouvé un substitut à l'échange de
Diffie-Hellman (ou équivalents) reposant sur un problème définitivement
indéterminé, et assorti d'une parade sans tiers de confiance à l'attaque par
usurpation.

Je me demande même s'il n'est pas possible de prouver mathématiquement qu'un
tel système ne peut pas exister, c'est à dire qu'aucune preuve "Zero
Knowledge" ne puisse être fondée sur un tel problème. Mes compétences en
épistémologie ne sont pas suffisantes, et je n'arrive pas à trouver des
sources abordables (je suis en fait cybernéticien, et un peu rouillé en
maths, malgré un très bon niveau autrefois).

J'ai déjà lancé des threads sur ce thème ici et sur le forum des maths, sans
succès.

Si vous connaissez de telles sources, ça m'intéresse énormément, merci
d'avance.

Cordialement,

PS: Savez-vous comment faire de cette ramification un nouveau thread, là ça
va se perdre dans le débat presque clos sur AllCrypter ?

--

/**************************************************************
* Patrick BRUNET @ ZenerTopia
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************************/
<8#--X--< filtré par Avast! 4 Home

AllCrypter : utilisation gratuite jusqu'en 2006

10 réponses

Veuillez sélectionner un problème