Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Sécurité Sécurité Cryptologie Algo RH: exposés complétés et codes

Algo RH: exposés complétés et codes

18 réponses
Avatar
Raymond H.
Bonjour,
Je viens de terminer mon exposé sur la création des clefs de sessions;
j'ai ai mis aussi les codes pour le comprendre d'une autre façon.
À partir de ce lien on a accès aux autres liens dans le haut de la page web
(les liens sur le chiffrement des données et des clefs de session, ainsi que
le code):
http://www.allcrypter.com/allcrypter/algorh2a.html
ou
http://logicipc.no-ip.com/allcrypter/algorh2a.html

Je poserais une question aux habitués de ce groupe. À votre avis, à
vue de nez (ou avec une lecture) dans mes exposés, pensez-vous qu'il serait
difficile de casser cet algo? Et si non, en combien de temps un habitué de
ce groupe penserait-il le faire?

Bonne journée
Raymond H.
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
remy


Mes premières constatations :
- Ta "génération de hasard" possède des biais multiples.


je luis aurai bien proposer quelque chose mais je me suis fait jeter
sûrement à juste titre

http://remyaumeunier.chez-alice.fr/alea.html
voir fin de page

remy

Avatar
Raymond H.
"remy" a écrit dans le message de news:
eq9kpi$5sc$


Mes premières constatations :
- Ta "génération de hasard" possède des biais multiples.



Bonjour,
Je ne vois aucun problème dans ma génération de hasard. Ce pourrait-il
que vous ne compreniez pas bien l'explication que j'y ai donnée? De plus, le
but est de produire du vrai hasard; or, mon ensemble générant des valeurs
produit du vrai hasard via les mouvements de la souris (ou des moments où
une touche est pressée et relâchée), puisqu'ils ne sont pas fondés que sur
des calculs mathématiques. Alors quoi demander de plus? Si quelqu'un pense
qu'il y a des biais dans ma génération de hasard je l'inviterais à les
définir et en donner la raison.

je luis aurai bien proposer quelque chose mais je me suis fait jeter
sûrement à juste titre

http://remyaumeunier.chez-alice.fr/alea.html
voir fin de page


J'ai lu la page en question
http://remyaumeunier.chez-alice.fr/alea.html , et d'après ma compréhension
ce générateur n'est fondé que sur des calculs mathématiques. Tout
débuterait avec ce qui est nommé 'la graine'; à partir de la graine je ne
vois que des calculs mathématiques. Sûrement que l'inverse des calculs ne
peut se faire; mais néanmoins, il suffirait de trouver la graine et refaire
les mêmes calculs pour tout casser; je ne vois donc aucun hasard là. De
même, un générateur pseudo-aléatoire qui utilise des calculs mathématiques à
partir d'une valeur basée sur le nombre de secondes écoulées après minuit
n'est pas du hasard s'il est utilisé seul; car il suffirait de connaître le
moment précis où le calcul a débuté afin de connaître la valeur de départ,
et refaire à partir de cette valeur les mêmes calculs pour arriver au même
résultat.

a+
Raymond


Avatar
Mister Jack
Bonjour,
Je ne vois aucun problème dans ma génération de hasard. [...] Si quelqu'un pense
qu'il y a des biais dans ma génération de hasard je l'inviterais à les
définir et en donner la raison.


Je ne m'aventurerai pas dans ta génération de hasard proprement dite.
Pour moi il est clair qu'elle n'est pas correcte, mais ça serait la
galère à démontrer.
Je me propose donc de te montrer que les premières opérations effectuées
sur ton "hasard", vont tout casser.

On supposera donc que ta génération de hasard est parfaite. Donc que
chaque bit de ta sortie a une probabilité de 50% d'être à zéro.

On supposera aussi que ta première transformation est parfaite. (même si
ajouter des valeurs pseudo-aléatoires à tes valeurs va plutôt dans le
sens contraire, puisque tu dis toi-même que la génération
pseudo-aléatoire est merdique).

On en arrive à ça :

For Rép3 = 1 To VarNombCaraK
VarCaraC1 = Val(Asc(Mid(VarCaraAle2, Rép3, 1)))
VarCaraC2 = Val(Asc(Mid(VarCaraAle2, Rép3 + VarNombCaraK, 1)))
VarCaraC3 = Val(Asc(Mid(V3, Rép3, 1)))
VarChifDroitAsc = Val(Right(Str(Asc(Mid(V3, Rép3, 1))), 1))
Randomize (Timer + VarCaraC1 + (Rép3 * VarChifDroitAsc))
V1 = V1 & Chr(((VarCaraC1 * VarChifDroitAsc) + Rép3 +
Int((VarCaraC2 * Rnd) + VarCaraC3) + Int((256 * Rnd) + 0)) Mod 256)
'-V2 = 2e clef de session.
V2 = V2 & Chr(((VarCaraC2 * VarChifDroitAsc) + (Rép3 * VarCaraC3)
+ VarCaraC1 + VarCaraC4 + Int((256 * Rnd) + 0)) Mod 256)
Next Rép3



Supposons Rep3 variant de 1 à 64.
on trouve VarCaraC1 qui est comprit entre 0 et 255
pareil pour VarCaraC2
raison : on a aussi supposé VarCaraAle2 comme issu d'un hasard parfait
On dira pareil pour VarCaraC3 même s'il me semble que V3 est toujours
vide. Enfin bref...

VarChifDroitAsc ne peut valoir que 0 à 9 de manière non équiprobable :
- 10.156% pour 0 à 5, et 9.766% pour 6 à 9
Donc pour chaque bit la probabilité d'être à zéro :
- bit0 : 1
- bit1 : 1
- bit2 : 1
- bit3 : 1
- bit4 : 0.195
- bit5 : 0.602
- bit6 : 0.602
- bit7 : 0.5

Et en continuant comme ça pour l'ensemble de ton calcul tu trouveras
sûrement que chaque bit que tu sors n'a pas la probabilité 1/2 d'être à
zéro : tu as baisé ton algo en rajoutant des étapes bizarres et étranges.

Vala,

Et si tu veux j'irai plus loin, mais j'ai un petit soft à écrire
d'abord, et j'ai po le temps.

--
Mister Jack (MJ)
"Plus tu pédales moins vite, moins tu avances plus lentement ? Non. Ah."

Avatar
Mister Jack
Et en continuant comme ça pour l'ensemble de ton calcul tu trouveras
sûrement que chaque bit que tu sors n'a pas la probabilité 1/2 d'être à
zéro : tu as baisé ton algo en rajoutant des étapes bizarres et étranges.


Euh... J'ai voulu dire "biaisé"... J'ai glissé chef.
Ca reste tout de même compréhensible :D

--
Mister Jack (MJ)
"Aurélie : Je ne suis pas cruelle, je suis tendre comme un agneau. Je
suis chaste, pute et innocente. PURE ! R ! bordel :/"

Avatar
Raymond H.
"Mister Jack" a écrit dans le message de news:
45c8dc25$0$23944$
Bonjour,
Je ne vois aucun problème dans ma génération de hasard. [...] Si
quelqu'un pense qu'il y a des biais dans ma génération de hasard je
l'inviterais à les définir et en donner la raison.


Je ne m'aventurerai pas dans ta génération de hasard proprement dite. Pour
moi il est clair qu'elle n'est pas correcte, mais ça serait la galère à
démontrer.
Je me propose donc de te montrer que les premières opérations effectuées
sur ton "hasard", vont tout casser.

On supposera donc que ta génération de hasard est parfaite. Donc que
chaque bit de ta sortie a une probabilité de 50% d'être à zéro.

On supposera aussi que ta première transformation est parfaite. (même si
ajouter des valeurs pseudo-aléatoires à tes valeurs va plutôt dans le sens
contraire, puisque tu dis toi-même que la génération pseudo-aléatoire est
merdique).


Mais lorsque le pseudo-aléatoire n'est pas utilisé seul mais avec des
valeurs déjà issues du hasard, alors là c'est différent.

On en arrive à ça :

For Rép3 = 1 To VarNombCaraK
VarCaraC1 = Val(Asc(Mid(VarCaraAle2, Rép3, 1)))
VarCaraC2 = Val(Asc(Mid(VarCaraAle2, Rép3 + VarNombCaraK, 1)))
VarCaraC3 = Val(Asc(Mid(V3, Rép3, 1)))
VarChifDroitAsc = Val(Right(Str(Asc(Mid(V3, Rép3, 1))), 1))
Randomize (Timer + VarCaraC1 + (Rép3 * VarChifDroitAsc))
V1 = V1 & Chr(((VarCaraC1 * VarChifDroitAsc) + Rép3 +
Int((VarCaraC2 * Rnd) + VarCaraC3) + Int((256 * Rnd) + 0)) Mod 256)
'-V2 = 2e clef de session.
V2 = V2 & Chr(((VarCaraC2 * VarChifDroitAsc) + (Rép3 * VarCaraC3)
+ VarCaraC1 + VarCaraC4 + Int((256 * Rnd) + 0)) Mod 256)
Next Rép3



Supposons Rep3 variant de 1 à 64.


Donc, ici il y aurait un mélange de 64 caractères issus du hasard en
mémoire (supposant que la clef personnelle a 16 caractères), 4 fois plus
qu'il en faut pour former une clef de session.

on trouve VarCaraC1 qui est comprit entre 0 et 255
pareil pour VarCaraC2
raison : on a aussi supposé VarCaraAle2 comme issu d'un hasard parfait
On dira pareil pour VarCaraC3 même s'il me semble que V3 est toujours
vide. Enfin bref...


V3 n'est jamais vide, et il renferme toujours des valeurs non connues,
et on voie qu'elles ne sont pas nécessairement le résultat d'un calcul
mathématique produisant des caractères pseudo-aléatoires. Elle servent au
mélange de valeurs déjà générées du hasard (il y a toujours 4 fois plus de
valeur générées du hasard qu'il en faut pour créer une clef de session
servant au chiffrement). À chaque chiffrement ce ne sont jamais les 2 mêmes
clefs de session qui sont générées.

VarChifDroitAsc ne peut valoir que 0 à 9 de manière non équiprobable :
- 10.156% pour 0 à 5, et 9.766% pour 6 à 9
Donc pour chaque bit la probabilité d'être à zéro :
- bit0 : 1
- bit1 : 1
- bit2 : 1
- bit3 : 1
- bit4 : 0.195
- bit5 : 0.602
- bit6 : 0.602
- bit7 : 0.5

Et en continuant comme ça pour l'ensemble de ton calcul tu trouveras
sûrement que chaque bit que tu sors n'a pas la probabilité 1/2 d'être à
zéro : tu as baisé ton algo en rajoutant des étapes bizarres et étranges.

Vala,


Pour faire simple, prenons une valeur issus du hasard, de mon cerveau:
'213'. Si je décide de choisir un nombre entre 1 et 3 (supposons que c'est
pseudo-aléatoire) pour additionner à la valeur 213 et que j'utilise le
modulo 256 pour rester dans la plage des 256 caractères qui existent. J'ai
donc 3 choix de valeurs comme résultat de ma transformation: 214, 215 ou
216. On me dira peut-être que j'ai une chance sur 3 de trouver la valeur
(une probabilité de 33%) puisque je n'ai que 3 choix. La réponse est non;
je n'ai pas trois chances mais j'ai 256 choix; donc, tous les caractères
sont possibles car la valeur de départ (213) n'était pas connue car elle
vient du hasard. C'aurait pu être 143, 8, 65, 214, 2, etc. Ce qui fait
qu'on ne sait pas quelle est la valeur entre 0 et 255 qui a été générée. Et
n'oublions pas que nos valeurs utilisées pour être transformées ne sont pas
toujours les mêmes, et en plus il y en a quatre fois plus de généré que
nécessaire pour produire une clef de session, et le pseudo-aléatoire est
utilisé pour faire le choix parmi ces caractères issus du hasard dont la
quantité est quatre fois plus qu'une clef de session à produire, et en plus
il les retransforme.
Donc, même si ces caractères ne sont pas retransformés par le bout de
code que vous avez collé ci-haut, ce sont déjà des caractères issus du
hasard. Autrement dit, même si en plus, je n'utilise pas le bout de code
(ci-haut) les caractères sont toujours issus du hasard et non
mathématiquement. Si ce n'est pas la mathématique qui a produit ces
nombres, alors comment utiliseriez-vous des calculs mathématiques pour
essayer de trouver ces nombres ? En plus, chaque chiffrement utilise 2
clefs de sessions en parallèle, et jamais les mêmes d'un chiffrement à
l'autre. Et si une personne vous dit les 2 clefs de session utilisées pour
avoir chiffrer son cryptogramme, il ne faut pas oublier que ces 2 clefs de
session ne sont pas utilisées de nouveau même si on procède au chiffrement
des mêmes données via la même clef personnelle secrète. Aussi, lorsqu'on
parle des valeurs générées du hasard avant chaque chiffrement, elle sont en
mémoire temporaire (en mémoire vive; en RAM) et non en mémoire sur le
disque; je dis ceci car ces valeurs disparaissent et à chaque démarrage du
logiciel, obligatoirement de nouvelles valeurs sont générées du hasard,
valeurs modifiées par la suite dont le quart est nécessaire pour la
génération d'une clef de session.

Et si tu veux j'irai plus loin, mais j'ai un petit soft à écrire d'abord,
et j'ai po le temps.


Disons qu'en restant dans la thérorie je ne crois pas que cela mène à
grand chose. Le concret prouvera les dires.
Si vous le voulez, pour vous facilité les choses, je pourrais même vous
donner des exemples de paires de clefs de session générées par ma
'génération de hasard', et vous pourriez (via les codes à
http://www.allcrypter.com/allcrypter/algorh1b.html ) essayer de trouver soit
les caractères de départ issus du hasard, soit la clef personnelle secrète
(car elle a aussi une influence sur la modification des caractères déjà
issus du hasard). Ainsi, si à partir de clefs de session que je vous fais
connaître vous ne pouvez pas trouver les valeurs générées au hasard, alors
comment feriez-vous pour trouver ces mêmes valeurs sans que vous connaissiez
les clefs de sessions? Et comment feriez-vous pour trouver les clefs de
sessions sans connaître ces valeurs de départ générées au hasard? :-)

a+
Raymond


Avatar
Raymond H.
"Mister Jack" a écrit dans le message de news:
45c8e503$0$30629$
Et en continuant comme ça pour l'ensemble de ton calcul tu trouveras
sûrement que chaque bit que tu sors n'a pas la probabilité 1/2 d'être à
zéro : tu as baisé ton algo en rajoutant des étapes bizarres et étranges.


Euh... J'ai voulu dire "biaisé"... J'ai glissé chef.
Ca reste tout de même compréhensible :D


:-)
r.h.


Avatar
Raymond H.
disque; je dis ceci car ces valeurs disparaissent et à chaque démarrage du
logiciel, obligatoirement de nouvelles valeurs sont générées du hasard,
valeurs modifiées par la suite dont le quart est nécessaire pour la
génération d'une clef de session.



Ici, j'aurais dû mettre un point-virgule:

"...disque; je dis ceci car ces valeurs disparaissent; et à chaque démarrage
du
logiciel, obligatoirement de nouvelles valeurs sont générées du hasard,
valeurs modifiées par la suite dont le quart est nécessaire pour la
génération d'une clef de session."

r.h.

Avatar
Mister Jack
Yo !

Pour faire simple, prenons une valeur issus du hasard, de mon cerveau:
'213'. Si je décide de choisir un nombre entre 1 et 3 (supposons que c'est
pseudo-aléatoire) pour additionner à la valeur 213 et que j'utilise le
modulo 256 pour rester dans la plage des 256 caractères qui existent. J'ai
donc 3 choix de valeurs comme résultat de ma transformation: 214, 215 ou
216. On me dira peut-être que j'ai une chance sur 3 de trouver la valeur
(une probabilité de 33%) puisque je n'ai que 3 choix. La réponse est non;
je n'ai pas trois chances mais j'ai 256 choix; donc, tous les caractères
sont possibles car la valeur de départ (213) n'était pas connue car elle
vient du hasard.


Pfffiouuu...
L'exemple que tu donne va filer une proba d'environ 0.3906% de sortir à
tous les nombres de 0 à 255 (merci le modulo 256). Le résultat est
équiprobable donc sympa.

Dans le bout de code que tu as filé précédemment on trouve par contre
(sauf erreur de ma part) :
- 000 : 0.3910 %
- 001 : 0.3907 %
- 002 : 0.3910 %
- 003 : 0.3904 %
...
- 255 : 0.3699 %

Globalement on voit que la probabilité d'une valeur paire (50.048%) est
légèrement plus élevée que pour une valeur impaire (49.952%). La valeur
255 est la moins courante (0.3699%)
Ce biais pourrait être exploité pour retrouver de manière statistique
quels étaient certains éléments du chiffrement.

--
Mister Jack (MJ)
"Demain matin j'suis en RTT. Juste pour pouvoir me reposer après t'avoir
parlé."

1 2