_________________________________________________
Avec le logiciel AllCrypter (version 2 ou +), que vous pouvez utiliser
gratuitement jusqu'en l'an 2006 ( www.logicipc.com ), décryptez le message
ci-dessous en utilisant cette clef de 4 mots:
>>>>> Ceci est la clef <<<<<
Voici le message secret que vous devez coller dans AllCrypter, dans la
fenêtre du 3e onglet en mode 'Texte', puis décryptez-le en cliquant sur la
ligne de commande 'Décrypter le texte venant d'un courriel' :
>>>BeginAllCrypter>>>4C6F6769636950435F416C6C437279707465720D0A3131309A99999EB8AB5891D8A5ADDED3999FF5EBDCE1B17AADF2C3DADCC5CDD0B24A5BC2C6D67F4475BA555B927AF6EE041913867B15F1F1168F17A97A69F81012C9A0E6A194D7A8ACE76979F3E10BB8D87769201426CD70C4FBE8222910C8CF22E9CE0F867FC2B4>>>EndAllCrypter>>>
_________________________________________________
On Fri, 26 Nov 2004 12:28:17 +0100, Jacques Caron wrote:
On notera au passage que la version encodée (je dis bien encodée et pas "cryptée" ou chiffrée) de la clef stockée dans le fichier présente des collisions. Les clefs " " (4 espaces) et "````" donnent le même résultat (81 83 85 87 89 8B 8D). Pour un encodage qui prend presque deux fois plus de place que l'original, c'est quand même pas terrible!
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 "àààà".
" " = 00100000 "`" = 01100000 "à" = 11100000
Ce qui, par ailleurs, rend faux tous les calculs présentés à propos de la vraie taille en bits de la clef. Une clef de 1 caractère n'est pas une clef de 8 bits, mais de 5 bits.
On note aussi que si tous les caractères sont identiques on a un +2 d'octet en octet, a priori quelque soit le caractère en question (j'ai pas vérifié in extenso).
Exact. La clef aaaa donnait 85 87 89 8B 8D 8F 91. Quand je disais que ça me faisait penser à CDP :)
-- Guillermito http://www.guillermito2.net
On Fri, 26 Nov 2004 12:28:17 +0100, Jacques Caron wrote:
On notera au passage que la version encodée (je dis bien encodée et pas
"cryptée" ou chiffrée) de la clef stockée dans le fichier présente des
collisions. Les clefs " " (4 espaces) et "````" donnent le même
résultat (81 83 85 87 89 8B 8D). Pour un encodage qui prend presque deux
fois plus de place que l'original, c'est quand même pas terrible!
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 "àààà".
" " = 00100000
"`" = 01100000
"à" = 11100000
Ce qui, par ailleurs, rend faux tous les calculs présentés à propos de
la vraie taille en bits de la clef. Une clef de 1 caractère n'est pas
une clef de 8 bits, mais de 5 bits.
On note aussi que si tous les caractères sont identiques on a un +2
d'octet en octet, a priori quelque soit le caractère en question (j'ai pas
vérifié in extenso).
Exact. La clef aaaa donnait 85 87 89 8B 8D 8F 91. Quand je disais que ça
me faisait penser à CDP :)
On Fri, 26 Nov 2004 12:28:17 +0100, Jacques Caron wrote:
On notera au passage que la version encodée (je dis bien encodée et pas "cryptée" ou chiffrée) de la clef stockée dans le fichier présente des collisions. Les clefs " " (4 espaces) et "````" donnent le même résultat (81 83 85 87 89 8B 8D). Pour un encodage qui prend presque deux fois plus de place que l'original, c'est quand même pas terrible!
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 "àààà".
" " = 00100000 "`" = 01100000 "à" = 11100000
Ce qui, par ailleurs, rend faux tous les calculs présentés à propos de la vraie taille en bits de la clef. Une clef de 1 caractère n'est pas une clef de 8 bits, mais de 5 bits.
On note aussi que si tous les caractères sont identiques on a un +2 d'octet en octet, a priori quelque soit le caractère en question (j'ai pas vérifié in extenso).
Exact. La clef aaaa donnait 85 87 89 8B 8D 8F 91. Quand je disais que ça me faisait penser à CDP :)
-- Guillermito http://www.guillermito2.net
Guillermito
On Thu, 25 Nov 2004 16:08:13 -0500, Raymond H. wrote:
Vous faites toute une affirmation ici :-) Moi même avec mes codes devant mes yeux je n'arriva pas à déchiffrer une clef.
Sans vouloir vous vexer (chacun a ses propres champs de connaissance, et je suis extrèmement incompétent dans une foule de domaines), ça en dit peut-être plus sur vos compétences en cryptographie que sur la solidité de votre algorithme.
Et si tout le monde 'peut' (comme vous le dites) déchiffrer le message si une clef est incluse alors je vous met au défit de le faire comme tout le monde 'peut' (comme vous le dites) le faire.
Vous allez perdre. Je vous ai déjà plus ou moins indiqué comment retrouver la clef. Il serait plus pédagogique que vous-même tentiez de casser votre propre algorithme. Là, présentement, je n'ai pas les quelques heures nécessaires pour finir l'analyse de votre machin et pour coder un outil pour reconstruire la clef. Peut-être plus tard.
Cela dit, vous vendez votre logiciel. Vous faites ça dans une optique commerciale. Même si ça m'amuse beaucoup de relever ce genre de défi, je me sens moyennement enclin à aider des gens qui ne partagent pas.
Et puis on a une certaine habitude dans ce groupe. Vous allez faire une nouvelle version avec une permutation de plus, et revenir lancer un défi. On n'en finit jamais. Ce qu'il faut, c'est que vous compreniez *pourquoi* votre algorithme est extrèmement faible et cassable. Sinon, ça ne sert à rien.
Si je dis que votre réponse me fait sourire, c'est que ca me fait plaisir de voir que des gens comme vous essais de décortiquer le résultat crypté en rapport avec votre clef, etc. C'est quand même interressant de voir la façon de vous raisonnez là-dessus.
Vous pouvez voir que plusieurs personnes ont fait le même genre de test rapide, et en ont tiré les mêmes conclusions. A vous maintenant de comprendre comment nous en sommes venu à soupçonner en quelques tests que votre logiciel est très faible, cryptographiquement parlant.
-- Guillermito http://www.guillermito2.net
On Thu, 25 Nov 2004 16:08:13 -0500, Raymond H. wrote:
Vous faites toute une affirmation ici :-) Moi même avec mes codes
devant mes yeux je n'arriva pas à déchiffrer une clef.
Sans vouloir vous vexer (chacun a ses propres champs de connaissance, et
je suis extrèmement incompétent dans une foule de domaines), ça en dit
peut-être plus sur vos compétences en cryptographie que sur la solidité
de votre algorithme.
Et si tout le monde
'peut' (comme vous le dites) déchiffrer le message si une clef est incluse
alors je vous met au défit de le faire comme tout le monde 'peut' (comme
vous le dites) le faire.
Vous allez perdre. Je vous ai déjà plus ou moins indiqué comment
retrouver la clef. Il serait plus pédagogique que vous-même tentiez de
casser votre propre algorithme. Là, présentement, je n'ai pas les
quelques heures nécessaires pour finir l'analyse de votre machin et pour
coder un outil pour reconstruire la clef. Peut-être plus tard.
Cela dit, vous vendez votre logiciel. Vous faites ça dans une optique
commerciale. Même si ça m'amuse beaucoup de relever ce genre de défi, je
me sens moyennement enclin à aider des gens qui ne partagent pas.
Et puis on a une certaine habitude dans ce groupe. Vous allez faire une
nouvelle version avec une permutation de plus, et revenir lancer un
défi. On n'en finit jamais. Ce qu'il faut, c'est que vous compreniez
*pourquoi* votre algorithme est extrèmement faible et cassable. Sinon,
ça ne sert à rien.
Si je dis que votre réponse me fait sourire, c'est que ca me fait
plaisir de voir que des gens comme vous essais de décortiquer le résultat
crypté en rapport avec votre clef, etc. C'est quand même interressant de
voir la façon de vous raisonnez là-dessus.
Vous pouvez voir que plusieurs personnes ont fait le même genre de test
rapide, et en ont tiré les mêmes conclusions. A vous maintenant de
comprendre comment nous en sommes venu à soupçonner en quelques tests
que votre logiciel est très faible, cryptographiquement parlant.
On Thu, 25 Nov 2004 16:08:13 -0500, Raymond H. wrote:
Vous faites toute une affirmation ici :-) Moi même avec mes codes devant mes yeux je n'arriva pas à déchiffrer une clef.
Sans vouloir vous vexer (chacun a ses propres champs de connaissance, et je suis extrèmement incompétent dans une foule de domaines), ça en dit peut-être plus sur vos compétences en cryptographie que sur la solidité de votre algorithme.
Et si tout le monde 'peut' (comme vous le dites) déchiffrer le message si une clef est incluse alors je vous met au défit de le faire comme tout le monde 'peut' (comme vous le dites) le faire.
Vous allez perdre. Je vous ai déjà plus ou moins indiqué comment retrouver la clef. Il serait plus pédagogique que vous-même tentiez de casser votre propre algorithme. Là, présentement, je n'ai pas les quelques heures nécessaires pour finir l'analyse de votre machin et pour coder un outil pour reconstruire la clef. Peut-être plus tard.
Cela dit, vous vendez votre logiciel. Vous faites ça dans une optique commerciale. Même si ça m'amuse beaucoup de relever ce genre de défi, je me sens moyennement enclin à aider des gens qui ne partagent pas.
Et puis on a une certaine habitude dans ce groupe. Vous allez faire une nouvelle version avec une permutation de plus, et revenir lancer un défi. On n'en finit jamais. Ce qu'il faut, c'est que vous compreniez *pourquoi* votre algorithme est extrèmement faible et cassable. Sinon, ça ne sert à rien.
Si je dis que votre réponse me fait sourire, c'est que ca me fait plaisir de voir que des gens comme vous essais de décortiquer le résultat crypté en rapport avec votre clef, etc. C'est quand même interressant de voir la façon de vous raisonnez là-dessus.
Vous pouvez voir que plusieurs personnes ont fait le même genre de test rapide, et en ont tiré les mêmes conclusions. A vous maintenant de comprendre comment nous en sommes venu à soupçonner en quelques tests que votre logiciel est très faible, cryptographiquement parlant.
-- Guillermito http://www.guillermito2.net
Jacques Caron
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 donnent la même version "encodée" et qui donnent des résultats différents au niveau de l'encodage du texte. Par exemple 4 espaces et 4 ` donnent la même version encodée de la clef, mais pas la même version encodée du texte (donc si le stockage de la clef encodée dans le "chiffré" est là pour permettre la vérification de la dite clef, c'est raté). Mais inversement, comme tu l'as déjà fait remarquer, certaines clefs différentes donnent des parties du texte encodé identiques (et donc sur des textes courts des chiffrés identiques).
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 (à moins qu'il y ait systématiquement un zero ou un LF final? Il aurait fallu que j'essaie avec un fichier plutôt qu'avec la saisie dans l'interface, mais maintenant j'ai désinstallé la chose).
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
En fait, heureusement qu'il n'y a pas une API, une librairie ou une version ligne de commande, sinon ce serait très très vite cassé, là où on perd du temps c'est avec les manipulations fastidieuses à cliquer partout pour arriver à quelque chose ;->
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
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
donnent la même version "encodée" et qui donnent des résultats différents
au niveau de l'encodage du texte. Par exemple 4 espaces et 4 ` donnent la
même version encodée de la clef, mais pas la même version encodée du texte
(donc si le stockage de la clef encodée dans le "chiffré" est là pour
permettre la vérification de la dite clef, c'est raté). Mais inversement,
comme tu l'as déjà fait remarquer, certaines clefs différentes donnent des
parties du texte encodé identiques (et donc sur des textes courts des
chiffrés identiques).
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 (à moins qu'il y ait systématiquement un zero ou un
LF final? Il aurait fallu que j'essaie avec un fichier plutôt qu'avec la
saisie dans l'interface, mais maintenant j'ai désinstallé la chose).
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
En fait, heureusement qu'il n'y a pas une API, une librairie ou une
version ligne de commande, sinon ce serait très très vite cassé, là où on
perd du temps c'est avec les manipulations fastidieuses à cliquer partout
pour arriver à quelque chose ;->
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
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 donnent la même version "encodée" et qui donnent des résultats différents au niveau de l'encodage du texte. Par exemple 4 espaces et 4 ` donnent la même version encodée de la clef, mais pas la même version encodée du texte (donc si le stockage de la clef encodée dans le "chiffré" est là pour permettre la vérification de la dite clef, c'est raté). Mais inversement, comme tu l'as déjà fait remarquer, certaines clefs différentes donnent des parties du texte encodé identiques (et donc sur des textes courts des chiffrés identiques).
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 (à moins qu'il y ait systématiquement un zero ou un LF final? Il aurait fallu que j'essaie avec un fichier plutôt qu'avec la saisie dans l'interface, mais maintenant j'ai désinstallé la chose).
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
En fait, heureusement qu'il n'y a pas une API, une librairie ou une version ligne de commande, sinon ce serait très très vite cassé, là où on perd du temps c'est avec les manipulations fastidieuses à cliquer partout pour arriver à quelque chose ;->
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Patrick 'Zener' Brunet
Bonjour.
"Sylvain" a écrit dans le message de news: 41a65a44$0$25127$
On Thu, 25 Nov 2004 03:41:07 -0500, Raymond H. wrote:
Vous pouvez même décrypter les données d'un fichier sans même décrypter le fichier lui-même
"Guillermito" a écrit Je ne comprends pas cette phrase. Ou alors elle ne veut rien dire.
"Patrick 'Zener' Brunet" a écrit
D'un point de vue impartial, ... j'ai cru comprendre qu'il s'agit de déchiffrer à la volée ou en bloc,
mais en tout cas en mémoire pure, sans générer de fichier en clair. Donc en
l'absence d'un debugger ou autre outil permettant d'analyser la mémoire, il
n'y aurait pas de fichier en clair (même fugitif et/ou caché) qui puisse être subrepticement copié au passage par un outil quelconque.
c'est également ce que j'avais interprété - au défaut de le lire.
hélas cette infirmation est gratuite et erronée; Windows swappe comme la plupart des OS et ne pas faire soi-même de fopen ne garantit nullement qu'aucune copie disque n'est réalisée.
et pratiquement de telles copies disque seront créées si 1) l'OS est mis en
veille prolongée alors que le soft s'exécute, 2) si un process de plus haute
priorité s'accapare toute la mémoire dispo et au dela (forcant la réallocation de mémoire virtuelle), 3) si un vilain process (kernel?) dumpe
toute la mémoire.
Je soupçonne pour justifier l'usage de fichiers temporaires en clair, que le but soit de pouvoir les faire lire par des players standards qui sont faits soit pour lire un fichier local, soit pour lire un stream depuis Internet, et qu'il est difficile de brancher sur un stream local généré par un soft de déchiffrement... A mon avis un player spécial intégrant les contraintes cryptologiques serait plus adapté dans ce cas. D'autant que ces players étant téléchargeables "innocemment" par l'utilisateur, ils constituent une nouvelle faille de sécurité idéale.
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 !!!!).
Mais donc en supposant, il est clair aussi que ça ne peut pas se faire en programmation classique, c'est ce que je voulais dire dans mon trait sur les programmeurs qui s'engagent à la légère dans des trucs qui les dépassent.
Par exemple, dans le magazine Misc, on trouve régulièrement des cours de hacking/cracking, et il y a des challenges dans ce domaine, le but étant de mettre en lumière toutes les techniques permettant à un code d'être le plus résistant possible à l'analyse dynamique (ie: avec un debugger système au besoin).
Un bon usage des sections critiques, du ping pong entre threads, des options de pagination et autres fonctionnalités système peut permettre de revendiquer un haut niveau de sécurité, mais évidemment le programmeur doit maîtriser des trucs pareils, et avoir une culture de bâtisseur de labyrinthes piégés doublé d'un champion d'échecs. Le développeur standard qui maîtrise seulement fopen et malloc n'a aucune chance.
Finalement c'est cet aspect jeu d'échecs qui rend la crypto passionnante, non ? Les scénarios audacieux, dès que l'enjeu le justifie, qui me rappellent les séries TV que j'adorais : Mission Impossible, Banacek, Opération Vol...
Mais là je pense plutôt à Gaston Lagaffe : bons sentiments mais détails négligés qui changent tout.
M'enfin, c'est déjà bien d'essayer avec motivation, positivons !
Cordialement,
--
/************************************************************** * Patrick BRUNET @ ZenerTopia * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************************/ <8#--X--< filtré par Avast! 4 Home
Bonjour.
"Sylvain" <mail@noSpam.net> a écrit dans le message de news:
41a65a44$0$25127$8fcfb975@news.wanadoo.fr...
On Thu, 25 Nov 2004 03:41:07 -0500, Raymond H. wrote:
Vous pouvez même décrypter
les données d'un fichier sans même décrypter le fichier lui-même
"Guillermito" <guillermito@pipo.com> a écrit
Je ne comprends pas cette phrase. Ou alors elle ne veut rien dire.
"Patrick 'Zener' Brunet" <invalid-use.link@web.page> a écrit
D'un point de vue impartial,
... j'ai cru comprendre qu'il s'agit de déchiffrer à la volée ou en
bloc,
mais en tout cas en mémoire pure, sans générer de fichier en clair. Donc
en
l'absence d'un debugger ou autre outil permettant d'analyser la mémoire,
il
n'y aurait pas de fichier en clair (même fugitif et/ou caché) qui puisse
être subrepticement copié au passage par un outil quelconque.
c'est également ce que j'avais interprété - au défaut de le lire.
hélas cette infirmation est gratuite et erronée; Windows swappe comme la
plupart des OS et ne pas faire soi-même de fopen ne garantit nullement
qu'aucune copie disque n'est réalisée.
et pratiquement de telles copies disque seront créées si 1) l'OS est mis
en
veille prolongée alors que le soft s'exécute, 2) si un process de plus
haute
priorité s'accapare toute la mémoire dispo et au dela (forcant la
réallocation de mémoire virtuelle), 3) si un vilain process (kernel?)
dumpe
toute la mémoire.
Je soupçonne pour justifier l'usage de fichiers temporaires en clair, que le
but soit de pouvoir les faire lire par des players standards qui sont faits
soit pour lire un fichier local, soit pour lire un stream depuis Internet,
et qu'il est difficile de brancher sur un stream local généré par un soft de
déchiffrement... A mon avis un player spécial intégrant les contraintes
cryptologiques serait plus adapté dans ce cas. D'autant que ces players
étant téléchargeables "innocemment" par l'utilisateur, ils constituent une
nouvelle faille de sécurité idéale.
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 !!!!).
Mais donc en supposant, il est clair aussi que ça ne peut pas se faire en
programmation classique, c'est ce que je voulais dire dans mon trait sur les
programmeurs qui s'engagent à la légère dans des trucs qui les dépassent.
Par exemple, dans le magazine Misc, on trouve régulièrement des cours de
hacking/cracking, et il y a des challenges dans ce domaine, le but étant de
mettre en lumière toutes les techniques permettant à un code d'être le plus
résistant possible à l'analyse dynamique (ie: avec un debugger système au
besoin).
Un bon usage des sections critiques, du ping pong entre threads, des options
de pagination et autres fonctionnalités système peut permettre de
revendiquer un haut niveau de sécurité, mais évidemment le programmeur doit
maîtriser des trucs pareils, et avoir une culture de bâtisseur de
labyrinthes piégés doublé d'un champion d'échecs. Le développeur standard
qui maîtrise seulement fopen et malloc n'a aucune chance.
Finalement c'est cet aspect jeu d'échecs qui rend la crypto passionnante,
non ? Les scénarios audacieux, dès que l'enjeu le justifie, qui me
rappellent les séries TV que j'adorais : Mission Impossible, Banacek,
Opération Vol...
Mais là je pense plutôt à Gaston Lagaffe : bons sentiments mais détails
négligés qui changent tout.
M'enfin, c'est déjà bien d'essayer avec motivation, positivons !
Cordialement,
--
/**************************************************************
* Patrick BRUNET @ ZenerTopia
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************************/
<8#--X--< filtré par Avast! 4 Home
"Sylvain" a écrit dans le message de news: 41a65a44$0$25127$
On Thu, 25 Nov 2004 03:41:07 -0500, Raymond H. wrote:
Vous pouvez même décrypter les données d'un fichier sans même décrypter le fichier lui-même
"Guillermito" a écrit Je ne comprends pas cette phrase. Ou alors elle ne veut rien dire.
"Patrick 'Zener' Brunet" a écrit
D'un point de vue impartial, ... j'ai cru comprendre qu'il s'agit de déchiffrer à la volée ou en bloc,
mais en tout cas en mémoire pure, sans générer de fichier en clair. Donc en
l'absence d'un debugger ou autre outil permettant d'analyser la mémoire, il
n'y aurait pas de fichier en clair (même fugitif et/ou caché) qui puisse être subrepticement copié au passage par un outil quelconque.
c'est également ce que j'avais interprété - au défaut de le lire.
hélas cette infirmation est gratuite et erronée; Windows swappe comme la plupart des OS et ne pas faire soi-même de fopen ne garantit nullement qu'aucune copie disque n'est réalisée.
et pratiquement de telles copies disque seront créées si 1) l'OS est mis en
veille prolongée alors que le soft s'exécute, 2) si un process de plus haute
priorité s'accapare toute la mémoire dispo et au dela (forcant la réallocation de mémoire virtuelle), 3) si un vilain process (kernel?) dumpe
toute la mémoire.
Je soupçonne pour justifier l'usage de fichiers temporaires en clair, que le but soit de pouvoir les faire lire par des players standards qui sont faits soit pour lire un fichier local, soit pour lire un stream depuis Internet, et qu'il est difficile de brancher sur un stream local généré par un soft de déchiffrement... A mon avis un player spécial intégrant les contraintes cryptologiques serait plus adapté dans ce cas. D'autant que ces players étant téléchargeables "innocemment" par l'utilisateur, ils constituent une nouvelle faille de sécurité idéale.
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 !!!!).
Mais donc en supposant, il est clair aussi que ça ne peut pas se faire en programmation classique, c'est ce que je voulais dire dans mon trait sur les programmeurs qui s'engagent à la légère dans des trucs qui les dépassent.
Par exemple, dans le magazine Misc, on trouve régulièrement des cours de hacking/cracking, et il y a des challenges dans ce domaine, le but étant de mettre en lumière toutes les techniques permettant à un code d'être le plus résistant possible à l'analyse dynamique (ie: avec un debugger système au besoin).
Un bon usage des sections critiques, du ping pong entre threads, des options de pagination et autres fonctionnalités système peut permettre de revendiquer un haut niveau de sécurité, mais évidemment le programmeur doit maîtriser des trucs pareils, et avoir une culture de bâtisseur de labyrinthes piégés doublé d'un champion d'échecs. Le développeur standard qui maîtrise seulement fopen et malloc n'a aucune chance.
Finalement c'est cet aspect jeu d'échecs qui rend la crypto passionnante, non ? Les scénarios audacieux, dès que l'enjeu le justifie, qui me rappellent les séries TV que j'adorais : Mission Impossible, Banacek, Opération Vol...
Mais là je pense plutôt à Gaston Lagaffe : bons sentiments mais détails négligés qui changent tout.
M'enfin, c'est déjà bien d'essayer avec motivation, positivons !
Cordialement,
--
/************************************************************** * Patrick BRUNET @ ZenerTopia * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************************/ <8#--X--< filtré par Avast! 4 Home
Guillermito
On Fri, 26 Nov 2004 15:01:17 +0100, AMcD® wrote:
J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile non ?
C'est interdit par la licence d'utilisation. Et tu sais combien je suis respectueux de ce genre de chose. Hmm. En plus, c'est du Visual Basic, et c'est une horreur de regarder ça avec un désassembleur.
-- Guillermito http://www.guillermito2.net
On Fri, 26 Nov 2004 15:01:17 +0100, AMcD® wrote:
J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile
non ?
C'est interdit par la licence d'utilisation. Et tu sais combien je suis
respectueux de ce genre de chose. Hmm. En plus, c'est du Visual Basic,
et c'est une horreur de regarder ça avec un désassembleur.
J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile non ?
C'est interdit par la licence d'utilisation. Et tu sais combien je suis respectueux de ce genre de chose. Hmm. En plus, c'est du Visual Basic, et c'est une horreur de regarder ça avec un désassembleur.
-- Guillermito http://www.guillermito2.net
AMcD®
Guillermito wrote:
[...]
Laisse-tomber. Le gars va modifier son truc sans cesse et comme personne n'aura le temps ou l'envie de le lui démonter, ou bien se lassera, il répondra "ben vas-y, casse-le mon algo ! J'ai proposé de le casser personne n'y est arrivé, donc, c'est le meilleur, incassable, blabla."
Tu sais très bien comment ça va finir.
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. Et puis bon, le gars qui te dit "moi, j'arrive pas à le casser, alors...", ben tu peux passer en mode "Lol" direct...
En crypto, le gars qui file pas ses algorithmes, il se discrédite lui-même, tout seul.
Enfin, puisque c'est à but commercial, pourquoi des "amateurs" devraient se soucier de son cas ? S'il veut en tirer bénéfice, ben à lui d'en assurer une étude professionnelle, avec tout ce que ce terme sous-entend.
J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile non ?
-- AMcD®
http://arnold.mcdonald.free.fr/
Guillermito wrote:
[...]
Laisse-tomber. Le gars va modifier son truc sans cesse et comme personne
n'aura le temps ou l'envie de le lui démonter, ou bien se lassera, il
répondra "ben vas-y, casse-le mon algo ! J'ai proposé de le casser personne
n'y est arrivé, donc, c'est le meilleur, incassable, blabla."
Tu sais très bien comment ça va finir.
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. Et puis bon, le gars qui te dit "moi,
j'arrive pas à le casser, alors...", ben tu peux passer en mode "Lol"
direct...
En crypto, le gars qui file pas ses algorithmes, il se discrédite lui-même,
tout seul.
Enfin, puisque c'est à but commercial, pourquoi des "amateurs" devraient se
soucier de son cas ? S'il veut en tirer bénéfice, ben à lui d'en assurer une
étude professionnelle, avec tout ce que ce terme sous-entend.
J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile
non ?
Laisse-tomber. Le gars va modifier son truc sans cesse et comme personne n'aura le temps ou l'envie de le lui démonter, ou bien se lassera, il répondra "ben vas-y, casse-le mon algo ! J'ai proposé de le casser personne n'y est arrivé, donc, c'est le meilleur, incassable, blabla."
Tu sais très bien comment ça va finir.
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. Et puis bon, le gars qui te dit "moi, j'arrive pas à le casser, alors...", ben tu peux passer en mode "Lol" direct...
En crypto, le gars qui file pas ses algorithmes, il se discrédite lui-même, tout seul.
Enfin, puisque c'est à but commercial, pourquoi des "amateurs" devraient se soucier de son cas ? S'il veut en tirer bénéfice, ben à lui d'en assurer une étude professionnelle, avec tout ce que ce terme sous-entend.
J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile non ?
-- AMcD®
http://arnold.mcdonald.free.fr/
Xavier Roche
AMcD® wrote:
J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile non ?
Argh. T'as déja vu la geule du code VB compilé désassemblé ?
AMcD® wrote:
J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile
non ?
Argh. T'as déja vu la geule du code VB compilé désassemblé ?
On voit qu'il n'y a que le premier et le dernier octet qui changent. Le dernier octet (le plus à droite) contient exactement les trois derniers bits de la première lettre de la clef.
Autre chose de remarquable pour les bits 5 a 8 du chiffre' :
On voit qu'il n'y a que le premier et le dernier octet qui changent. Le
dernier octet (le plus à droite) contient exactement les trois derniers
bits de la première lettre de la clef.
Autre chose de remarquable pour les bits 5 a 8 du chiffre' :
On voit qu'il n'y a que le premier et le dernier octet qui changent. Le dernier octet (le plus à droite) contient exactement les trois derniers bits de la première lettre de la clef.
Autre chose de remarquable pour les bits 5 a 8 du chiffre' :
C'est peut-etre pas significatif, mais au vu du reste, je ne serais pas surpris que ca le soit.
-- Tweakie
-- Posté via http://www.webatou.net/ Usenet dans votre navigateur ! Complaints-To:
AMcD®
Xavier Roche wrote:
Hum, comme t'as titillé mon esprit vif, j'ai d/l le truc (j'ai pris le fichier .zip, présisons).
Je lance le setup et j'obtiens un beau :
"There is not enough free disk space on one or more drives." "Space Available -1776952 K" <- note bien le signe moins... "Space Needded 1784463 K"
Déjà, j'admire la detection d'espace libre sur mon disque (qui, le pauvre n'a que 13,2 Go de libre). Ensuite, moi, un soft qui a besoin de 1.7 Go pour s'installer, ben je clique sur "Annuler" et je retourne à des choses plus passionantes.
Voilà, voilà.
-- AMcD®
http://arnold.mcdonald.free.fr/
Xavier Roche wrote:
Hum, comme t'as titillé mon esprit vif, j'ai d/l le truc (j'ai pris le
fichier .zip, présisons).
Je lance le setup et j'obtiens un beau :
"There is not enough free disk space on one or more drives."
"Space Available -1776952 K" <- note bien le signe moins...
"Space Needded 1784463 K"
Déjà, j'admire la detection d'espace libre sur mon disque (qui, le pauvre
n'a que 13,2 Go de libre). Ensuite, moi, un soft qui a besoin de 1.7 Go pour
s'installer, ben je clique sur "Annuler" et je retourne à des choses plus
passionantes.
Hum, comme t'as titillé mon esprit vif, j'ai d/l le truc (j'ai pris le fichier .zip, présisons).
Je lance le setup et j'obtiens un beau :
"There is not enough free disk space on one or more drives." "Space Available -1776952 K" <- note bien le signe moins... "Space Needded 1784463 K"
Déjà, j'admire la detection d'espace libre sur mon disque (qui, le pauvre n'a que 13,2 Go de libre). Ensuite, moi, un soft qui a besoin de 1.7 Go pour s'installer, ben je clique sur "Annuler" et je retourne à des choses plus passionantes.
