AMcD® : méthode de cryptage.

"AMcD®" <arnold.mcdonald@free.fr> a écrit dans le message de news:
41b84d6b$0$18055$636a15ce@news.free.fr...

Raymond H. wrote:

Désolé de passer en coup de vent, je suis TRÉS occuppé jusqu'à vendredi.

Disons que c'est quand même assez limité et je parlais de n'importe
quel clef dans AllCrypter mais bon,

Non, ce n'est pas limité. Tu ne comprends rien à rien. J'ai choisi
l'ensemble {a,z} pour simplifier les propos. Je n'ai pas que ça à faire.
Je te rappelle que tout ceci est fait gratuitement qui plus est.

J'ai pris 80 bits parce que je connais peu de personnes qui choisissent
des pass de plus de 10 caractères. Et puis, 80 bits, tu ne peux plus
m'accuser de les essayer une par une. De même, j'ai étudié, par commodité,
le cas des clés multiples de 16 bits, mais il ne fait aucun doute que cela
marcherait également pour les clés multiples de 8 bits.

Je n'ai pas le temps de faire un programme qui retrouve toutes les clés.
Avec ce que j'ai expliqué, il ne devrait pas y avoir de gros problème pour
le faire.

voici un texte crypté avec une
clef de 80 bits avec des caractères minuscule de a à z comme vous
dîtes:

BeginAllCrypter>>>4C6F6769636950435F416C6C437279707465720D0A3131E9D6AED79EBCADD4AD97A1C6D9B6CCBFF4CC0DBF7FD1CDE0A5C6B8DDCBCE>>>EndAllCrypter>>>

D'après ma méthode, la clé est : zebdiatozz
Le texte décrypté est : *Lzpacfiik

Comme tu le vois, ça marche, puisque ton logiciel dit que la clé est bonne
et déchiffre le texte.

Bonjour,

si le logiciel dit que la clef est la bonne c'est qu'elle est la bonne.
Bien que votre soft est limité aux caractères minuscules de a à z seulement
et d'un certain nombre de bits, je tiens quand même à vous féliciter
personnellement pour vos efforts que vous avez mis à vous rendre jusqu'à ce
point. J'avoue que je ne m'attendais pas à ce que vous alliez jusqu'à ce
point même si votre soft ne peut pas décrypter toutes les clefs
d'AllCrypter. Il faut reconnaître que vous êtes quand même assez doué :)

De plus, comme j'ai déjà dis auparavant, vos exposés mis en pdf ont une
belle apparence et bien lisible, surtout avec les couleurs aidant à mieux
distinguer les caractères.

Comme lu à quelque part via ce forum, j'aurais quand même dû ne pas débuter
le chiffré par la clef elle-même, car si seulement un caractère l'aurait
précédé la clef chiffrée aurait été différente en tout point. Mais bon...
on apprend. Je peux donc dire qu'en lisant plusieurs personnes dans ce
forum et en réfléchissant sur l'amélioration d'AllCrypter j'ai réalisé
certaines choses qui devraient être un peu différentes dans mon soft.

Même si votre soft ne décortique pas tout, j'ai quand même décidé de
rendre inopérable la fonction qui insère la clef avec le chiffré. Comme
déjà mentionné auparavant, à la version 3.0 ce ne sera pas la clef qui sera
intégrée mais seulement un code de reconnaissance de la clef. Une valeur de
calcul sera aussi ajouté dans le calcul du cryptage: je pourrais vous
l'expliquer un coup fait. Mais pour l'instant je suis assez occupé et
j'espère mettre assez de temps dans ces jours-ci pour que cette version 3.0
soit prête le plus tôt possible. Je devrai du même coup faire quelques
changements dans mes explications web.

Si ça vous intéresse, je peux vous faire connaître les calculs effectués
dans la version 3.0 lorsqu'il sera prêt afin que vous en donniez votre
point de vue. Car je suis présentement en train d'étudier le calcul pour
les transformations de la clef en code d'identification, et le moyen de
faire qu'aucune répétition ne se répète pour un texte à crypter dont
l'utilisateur aurait tapé un même caractère se trouvant des milliers de fois
de suite. Je veux faire cela le plus simple possible.

Encore une fois mes félicitations pour vos efforts.

Passez une bonne journée :)

r.h.

Maintenant, de deux choses l'une :

a) Ton logiciel a un gros bug puisqu'il indique que la clé est bonne alors
qu'elle ne l'est pas vu la gueule du texte déchiffré.
b) Tu es vraiment un très mauvais perdant si le texte réel est bien :
*Lzpacfiik. Si c'est le cas, tu te ridiculises encore plus.

Dans tous les cas, ma méthode sert au moins à créer des clés reconnues
valides. Si elles ne le sont pas, c'est que ton soft est vraiment bancal.

Au fait, je parcours rapidement les réponses là, je m'aperçois que tu n'as
pas donné la réponse. C'est quoi la clé de ton chiffré ci-dessus, et quel
est le texte ? Je suis curieux d'avoir ta réponse...

Enfin, il faut bien que tu comprennes 3 choses :

- Du moment qu'on a trouvé une faille, un truc bizarre, ton logiciel est
invendable en l'état puisque non fiable ;
- Ce n'est pas en rajoutant et modifiant des trucs sans cesse que tu
arrangeras les choses, il faut tout repenser ;
- Si tu dis qu'on ne peut pas retrouver les clés et que tu supprimes la
possibilité de sauvegarder la clé avec le chiffré avec les prochaines
versions, tu te contredis un peu non ?

Alors, clé/texte ?

--
AMcD®

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

Vous avez justement l'attitude de gens dont je parle qui n'est pas
vraiment agréable. Et cela vous fait du bien à vous aussi de dénigrer de la
sorte?

Si un fait est un dénigrement oui je dénigre.

C'est de cela que je n'aime pas et vous semblez ne pas le voir comme
d'autres ne semblent pas le voir non plus, puisque vous vous attardez sur le
côté technique pour vous monter contre moi par vos insultes, tandis que moi

Dont acte, je reconnais que le psy était un peu fort de café (ne vous
connaissant pas je ne peux ou n'ai à juger), mais quand on provoque
(invocation biblique dans un forum technique) on assume...

c'est des attitudes comme les vôtes dont je parle que je n'aime pas.
Pourquoi ne comprenez-vous pas cela? Il y a moyen de communiquer de façon
meilleure il me semble. En plus vous allez contre les règles du forum (vous
et d'autres). C'est quand même assez spécial, chacun dans votre état
d'esprit semble vouloir y mettre un peu de leur pollution morale. Passons...
car ca ne semble rien donner, même après plusieurs de mes interventions sur
ce genre d'attitude, puisqu'il y a toujours quelqu'un pour mettre son grain
de pollution morale sans se rendre compte (il semble) que c'est ça le
problème principal sur ce forum depuis quelques temps. J'ai bien beau en
parler mais il y en a toujours un qui prend la relève. Faudrait que ce
forum soit modéré.
r.h.

Et ça vous ennuyrait de *répondre* sur le fond plutôt que de jouer les
vierges effarouchées sur la forme? C'est une réaction pour le moins puérile.

Il est certains qu'en continuant de cette façon (ne pas répondre au
questions soulevées) et en restant sur le "vous dites des faussetés" (de
façon amusante votre locution est d'ailleurs une fausseté" puisque vous
êtes dans l'erreur prétendez l'inverse) vous poussez le débat sur un
terrain personnel, au mépris d'ailleurs des règles que vous mettez vous
même en avant.

Si vous vous positionnez sur un terrain technique et que vous acceptez
de répondre c'est tout à fait en charte. Si maintenant vous venez faire
votre pub (je vous renvois à votre premier post) et vous contentez de
"c'est pas vrai, vous êtes méchant"-like il est clair que ça va moins
bien se passer.

Pour en revenir au _factuel_ :

- Avez vous testé le code présenté? Quel résultat? Vos conclusions?

- Comprenez vous pourquoi le fait qu'une variation mineure du clair
n'entraine qu'une variation mineure du chiffré est "mal"? (même si le
clair est une sucession d'octets identiques)

- Si vous estimez que ce n'est pas "mal" pouvez vous expliquer pourquoi?

- Avez vous consulté les liens que je vous ai fourni? Qu'en pensez vous?

Il me semble que si vous répondez sans ambiguïté à ces question *en
argumentant* de manière objective vous pourrez soit faire taire vos
détracteurs soit reconnaitre qu'il y a un problème dans votre application.

Puisque, comme vous le faite remarquer, on trouve trace des groupes sur
le web, j'ose espérer que vous prouverez à vos clients que vous pouvez
passer du "mode affectif" au "mode technique".

La balle est dans votre camp.

Eric.

Arm7 wrote:

Pas sur que ca parte du même principe...

Moi si. Je cite :

<copie>
DYNAMIC TRANSPOSITION

A Dynamic Transposition cipher is conceptually simple:

(1) Collect plaintext data in bit-balanced (or almost
bit-balanced) blocks; and

(2) Shuffle the bits in those blocks under the
control of a keyed pseudorandom sequence.
</copie>

Le 1), c'est votre XOR initial (il a pour but d'egaliser
le nombre de 1 et de 0). Le 2) c'est l'ensemble des
permutations.

mais bon, où est la faiblesse du systeme présenté plus haut ?

Pour resumer, la robustesse de ce systeme est directement
liee a celle du generateur psudo-aleatoire utilise'. Je
reprends donc a mon compte une remarque interessante d'un
des contributeurs de sci.crypt :

En quoi cette methode est-elle plus robuste qu'un simple
XOR effectue' entre le message a chiffrer et un ensemble
de valeurs generees par un generateur psudo-aleatoire
qui utilise la clef comme graine ?

--
Tweakie


--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To: abuse@webatou.net

Ostie Raymond, tu ne peux pas répondre à cette simple question de AMcD®,
tabarnak ?
Histoire de fermer définitivement le couvercle du cercueil de allcrypter ?

Au fait, je parcours rapidement les réponses là, je m'aperçois que tu
n'as pas donné la réponse. C'est quoi la clé de ton chiffré ci-dessus, et
quel est le texte ? Je suis curieux d'avoir ta réponse...

arm7 wrote:

lui-même, et sur un Windows NT et suivants ce n'est pas non plus un
émulateur MS-DOS mais un shell 32 bits nommé cmd.exe .

Bon, je crois qu'on a fait le tour de la question et qu'on s'éloigne
vraiment de la charte de fr.misc.cryptologie . Si tu veux continuer
positionne au moins un FU2 sur fr.misc.je.ne.sais.pas.de.quoi.je.parle .

Vous avez perdu tous les deux.

Je ne vois pas grand chose à critiquer aux explications d'arm7, bien
plus aux tiennes.

Depuis l'apparition de EMM386, donc surement sour dos 4.0, et bien avant
windows 95, possède une partie émulation, nottamment une "émulation" des
adresses mémoire, afin de dépasser la limite de 640Ko.

J'aimerais bien savoir quel est le sujet du verbe "possède" dans cette
phrase ?

On parlait d'un "émulateur MS-DOS" au départ, pas d'autre chose.

Si tu considéres qu'un processeur 80386 ou plus qui tourne en mode
protégé/virtuel au lieu du mode réel est une forme d'émulation, cela
revient à dire que MS-DOS 4.0 lui même est une émulation avec EMM386
chargé, et cela sort complètement du sujet.

Dans Windows 3.1, le système avait besoin du DOS en dessous pour gérer
tous les appels systèmes hors de l'interface graphique, et était obligé
de passer constamment en mode virtuel pour cela.

Sous Win9x, ce n'est pas le cas, mais il y a des vrais petits morceaux
de code MS-DOS à l'intérieur (comme pour les yaourts), pour permettre
une compatibilité quasi-totale avec le chargement de drivers DOS et de
code TSR au lancement du système.

Le résultat final est très hybride, Win9x exécutant normalement
entièrement en 32 bits la plupart des choses, mais étant capable aussi
s'il détecte qu'il le faut de passer la main à du code 16 bits type
MS-DOS. Dans l'ensemble, l'exécution des programmes MS-DOS sous 9x
repose plus sur de l'émulation d'API DOS que sur l'exécution de vrai
code MS-DOS.

Sous WinNT et +, pour le shell, je trouve cmd.exe qui est un fichier
format PE, c'est à dire un vrai programme 32 bits qui parle directement
aux API win32, mais *aussi* je peux lancer command.com (qui aura du mal
à être un programme 32 bits avec l'extension ".com" ;-) ), qui reste
donc un pur programme 16 bits, et si je peux l'exécuter, c'est bien bien
qu'une vraie couche complète d'émulation de l'API DOS est encore présente.

Il faut dire que la nostalgie se porte très bien dans les systèmes
Microsoft qui continuent à me fournir l'éditeur EDLIN.EXE (lui aussi pur
.exe au format DOS sans extensions) même sous Windows XP Home.
L'informatique de 1981 n'est pas morte ! Il faut dire qu'à 13 Ko, c'est
pas cela qui va beaucoup encombrer.

Toute ceci n'empèche que le programme à l'origine de la discussion était
bien un programme 32 bits, utilisant l'API Win32, qu'il serait
totalement impossible d'exécuter avec un DOS, et qui ne met pas en
oeuvre la couche d'émulation DOS dans son exécution s'il faut le redire.

"Jean-Marc Desperrier" <jmdesp@alussinan.org> a écrit dans le message de
news:cp9tdm$9hc$1@reader1.imaginet.fr...
(...)

Toute ceci n'empèche que le programme à l'origine de la discussion était
bien un programme 32 bits, utilisant l'API Win32, qu'il serait
totalement impossible d'exécuter avec un DOS, et qui ne met pas en
oeuvre la couche d'émulation DOS dans son exécution s'il faut le redire.

Merci, ça me rassure sur mes capacités à ne pas perdre le fil dans ce genre
de discussions plus ou moins creuses (plutôt plus, d'ailleurs)...

--
J.D.

J'ai déjà répondu ailleurs.

"mif" <mif@mif.com> a écrit dans le message de news:
Dr_td.4960$Fg2.2042147@newshog.newsread.com...

Ostie Raymond, tu ne peux pas répondre à cette simple question de AMcD®,
tabarnak ?
Histoire de fermer définitivement le couvercle du cercueil de allcrypter ?

Au fait, je parcours rapidement les réponses là, je m'aperçois que tu
n'as pas donné la réponse. C'est quoi la clé de ton chiffré ci-dessus,
et quel est le texte ? Je suis curieux d'avoir ta réponse...

Le Thu, 09 Dec 2004 12:20:21 +0100, arm7 a écrit :

Alors "vrai" ou "faux" DOS, hein....

cmd.exe n'est pas un DOS (émulé ou non). C'est une ligne de commande
(pourrie) qui s'exécute en 32bits et permet de lancer des vrais outils
32bits.

L'émulation DOS, c'est autre chose, qui permet de lancer les vieux
programmes 16 bits du genre command.com ou le gestionnaire de fichiers de
Win3.1 (dont je ne me rappelle plus le nom).


--
Je vais mettre Mouse Office pour voir combien de kilomètres je parcours
entre 2 changements de scotch et nettoyage de boule. Même dans le
domaine du petit bricolage, il faut savoir rester rigoureux. :-)
-+- CH in Guide du Macounet Pervers : Bien bricoler sa souris -+-

Bonjour, même si vous vous frustrez après moi,

je ne suis pas toujours devant mon ordinateur, il me faut dormir
quelquefois pour récupérer, alors patience, je ne demeure pas en France non
plus.

Ailleurs, j'ai déjà félicité l'auteur du soft pour son travail pour tenter
de décrypter certaines clefs, même si son soft est limité. Il a un zèle pour
ce genre de chose et ca aide à prendre conscience de certaines choses.

Et en plus j'avais déjà expliqué cela dans un autre message concernant
le temps d'exécution d'une procédure ne faisant des calculs que pour une
clef ayant un minimum de caractères et en minuscule de a à z. On pourrait
comparer par ce moyen les clefs d'à peu près n'importe lequel des softs de
cryptage en autant qu'on ait quelques calculs pour le faire. J'ose espérer
que vous y connaissiez quelque chose et que vous parlez pas seulement
d'après ce que d'autres vous disent! Cela peut prendre d'une fraction de
seconde à quelques secondes pour trouver ces quelques clefs via un soft créé
à cet effet avec une limitation de quelques caractères seulement. Il y a
quand même une différence avec une clef de 1024 qui ne se limite pas à des
minuscule de a à z. Et comme j'ai dis auparavant, pour trouver une clef
dans AllCrypter il faut, en plus des calculs, faire des comparaisons dans
une boucle pour trouver une clef dans AllCrypter sinon c'est impossible sans
la clef (en clair) elle-même. La comparaison doit se faire soit avec des
mots d'un dictionnaire, soit à vu d'oeil (à exclure ici) ou soit avec le
texte qui a été chiffré avec le logiciel de cryptage lui-même (c'est plutôt
cette dernière). Je sais de quoi je parle puisque c'est moi qui ai fait les
codes d'AllCrypter, on ne peut pas arriver directement à trouver une clef
sans faire des comparaisons au hasard jusqu'à ce qu'on arrive dessus. On
pourrait faire ainsi avec presque n'importe lequel des logiciels de cryptage
en autant de posséder suffisamment de calculs pour le faire.



Et c'est là que le soft du AMcD donne un enseignement: c'est-à-dire qu'il
faut être très prudent dans le fait d'intégrer une clef au sein du
cryptogramme et éviter de l'intégrer au début du cryptogramme et je dirait
même de ne pas l'intégrer du tout mais y intégrer, si désiré, un code qui
l'identifie plutôt, mais pas au début du cryptogramme afin que les numéros
ascii du chiffrement soit moins évident. C'est une leçon à en tirer. Car
ce même début du cryptogramme peut être utilisé (comme il le fait dans son
soft) aussi pour fin de comparaison avec des clefs différentes. Mais comme
j'ai dit, il y a une différence entre des minuscule de a à z et presque tous
les caractères de la table des caractères et en plus en 1024. Mais bon! On
doit avancer et se perfectionner dans nos algos si cela est nécessaire (je
parle pour moi-même).

r.h.



"mif" <mif@mif.com> a écrit dans le message de news:
Dr_td.4960$Fg2.2042147@newshog.newsread.com...

Ostie Raymond, tu ne peux pas répondre à cette simple question de AMcD®,
tabarnak ?
Histoire de fermer définitivement le couvercle du cercueil de allcrypter ?

Au fait, je parcours rapidement les réponses là, je m'aperçois que tu
n'as pas donné la réponse. C'est quoi la clé de ton chiffré ci-dessus,
et quel est le texte ? Je suis curieux d'avoir ta réponse...

Toute ceci n'empèche que le programme à l'origine de la discussion était
bien un programme 32 bits, utilisant l'API Win32, qu'il serait totalement
impossible d'exécuter avec un DOS, et qui ne met pas en oeuvre la couche
d'émulation DOS dans son exécution s'il faut le redire.

Mais faut reconnaître que la fenêtre que le soft utilise est une fenêtre
DOS.
r.h.