Quelques problèmes de cryptage à résoudre.

Partagez votre expérience de PureBasic avec les autres utilisateurs.
PAPIPP
Messages : 534
Inscription : sam. 23/févr./2008 17:58

Quelques problèmes de cryptage à résoudre.

Message par PAPIPP »

Bonjour à tous

En Pb nous avons de quoi réaliser tous les cryptages que l’on désire mais voici 2 problèmes
Qui ne peuvent être réalisés qu’en définissant un protocole ou un processus avec PB
Remarques : Il est possible que vous trouviez une méthode qui comporte une chaine de caractères avec chr(0)+chr(0) en ASCII ou en Unicode
cela fait aussi partie des problèmes à résoudre.

Voici les 4 petits pb à résoudre pour le fun

1) Vous avez un coffre qui contient de l’argent et des bijoux et celui-ci s’ouvre avec une clé secrète (code) que vous désirez transmettre à 2 personnes
de façon que chacune d’entre-elles ne puissent accéder à l’ouverture du code sans l’aide de l’autre.
Il faut que les deux personnes soient d’accord et présentes
La méthode pour retrouver le code leur a été fourni, elle fait partie du problème.
Pour garder le plus de robustesse vous ne coupez pas le code en deux mais vous envoyez à chacune d’elle un texte crypté qui contient le code entier cryptée donc non lisible.
Comment faites-vous ?

2) On peut généraliser la méthode que vous aurez trouvée à n personnes.
Comment faites-vous pour distribuer un code crypté à n personnes
sachant qu' il est nécessaire que toutes ces personnes soient présentes pour trouver le code ?

3) Vous désirez passer un texte à une autre personne sans que l’on puisse lire le texte
et vous ne pouvez en aucun cas lui passer une clé de décryptage en claire (donc pas de clé publique)
La seule possibilité est de lui transmettre un texte crypté.
La solution n’est pas dans l’utilisation du RSA ou d’un autre algo à clé publique
et aucune clé ni aucune information autre que le texte crypté ne peuvent être transmises.
Comment faites-vous pour que cette autre personne puisse lire le texte?

4) Voici une chaine cryptée sans mot de passe avec des algorithmes que l'on dit faibles. Pouvez-vous la découvrir?"
Cette chaine a été placée dans une datasection car elle peut contenir des chr(0)+chr(0)

Code : Tout sélectionner

longueur=?fin_donne-?donne_num
ITER=longueur/8-1
structure DATA_NUM 
  structureunion 
    tab.Q[0]
    chaine.s{32000}
  EndStructureUnion 
endstructure  
define don.DATA_NUM
for i=0 to ITER
 read.q  don\tab[i]
next
debug "Cette chaine a été cryptée sans mot de passe avec des algorithmes que l'on dit faibles. Pouvez-vous la découvrir?" 
ShowMemoryViewer(@don\chaine,longueur)
end
DataSection
donne_num:
Data.q 30962741359412482,27022104572657708,34903068917301365,29837331087097898,12948055093608574,14918397112090737
Data.q 16044314194280562,29273917276553274,23925677971079246,27303373388841031,21392476192702530,3659578429276239
Data.q 19421842117361757,2815093370585174,20829251361439831,8163087862988826,27303231660163102,28429178809745506
Data.q 10414827544772643,17733224183037990,17733189828411502,13511060877213734,12385405788749887,35184599730159679
Data.q 18296148367638573,3377991781449806,7318658632318981,21674144437698598,1407452193619968,23925441740341270
Data.q 3096310645194777,3096289170227215,48133187386277915,66147323916910760,64458491234156771,71214238569463978
Data.q 68680929415987431,68680929419657394,69806855088832723,66992088149852411,59391769854279922,56577217656717521
Data.q 62769869007356076,70932295435616455,60236559857090702,41940407199072450,62206841744195734,60799445386920090
Data.q 48414404677533904,45036975537783016,39970189733986474,47851759664038051,51792091512373419,68962129515839654
Data.q 48414490579370220,50666243144614141,37718235301937406,39407145288007819,37436760326078667,36873900567232736
Data.q 37155590288048282,43911006910021880,61080735676104866,62206596927193306,104991454813618393,102458407669989731
Data.q 106961762484814197,99643709443277163,107806548192592132,106680553791291767,88103269756633457,104710284789940585
Data.q 95139671723802942,73466347627807052,98236197113364803,93451174056624401,76844150426763593,97110353046012247
Data.q 106680442120765779,98517697864532315,81629001689530747,86695607106863393,84443841652064553,84443863127818532
Data.q 79940534082863393,104991497772269877,106117672556822843,88384414015160623,93169591698719039,90636097865056588
Data.q 73466184414920978,76280938476732757,85569505333412103,76562404864819460,97110013739139330,77688261821989132
Data.q 120191825118626075,121317780869087712,119628952488116723,137361850250822142,140176690208768508,142428524387303803
Data.q 124132625126719968,118784609159414248,139332063413469674,126384257438777806,128917493573484939,134265500948562393
Data.q 112873183677907364,131732329238954455,134828553980543447,132857958564823450,122724958187684225,119910182646120867
Data.q 137643080414134698,135109904408707513,125539716541841839,141020823081320887,120754607582806463,119347215515058607
Data.q 109214215137788347,108088091893498257,108088091890286984,114842941574480267,116532422795198914,79940903461126610
Data.q 113717647260451237,110339947538285018,153406198795534732,171139465940566636,144961983867912780,177894835316064867
Data.q 179864915336430187,163539383872258684,161569076213514866,176206024107819536,166635720284963447,165509803190452816
Data.q 164102136253252102,168605984991150660,166635788997427805,163821026345681474,176768587515691611,169169141098021402
Data.q 159598734198047322,157628327751647779,161006079011652202,161569295253897758,159880149041349163,160161671266107959
Data.q 161006147732177465,156221004412813865,145806327190061694,150028460429214223,144117391428223562,149746942502371936
Data.q 153969028499243588,145243360055853589,149747152965206530,150872812348834313,3238440010251
fin_donne:
EndDataSection
PS : Si vous réussissez à découvrir ce dernier problème vous êtes sur la bonne voie pour résoudre les 2 premiers.

A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
Avatar de l’utilisateur
Zorro
Messages : 2185
Inscription : mar. 31/mai/2016 9:06

Re: Quelques problèmes de cryptage à résoudre.

Message par Zorro »

PAPIPP a écrit : 1) Vous avez un coffre qui contient de l’argent et des bijoux et celui-ci s’ouvre avec une clé secrète (code) que vous désirez transmettre à 2 personnes
de façon que chacune d’entre-elles ne puissent accéder à l’ouverture du code sans l’aide de l’autre.
Il faut que les deux personnes soient d’accord et présentes
La méthode pour retrouver le code leur a été fourni, elle fait partie du problème.
Pour garder le plus de robustesse vous ne coupez pas le code en deux mais vous envoyez à chacune d’elle un texte crypté qui contient le code entier cryptée donc non lisible.
Comment faites-vous ?
c'est vaste ,
par exemple si la clef est le nom d'un monument comme "tour eiffel"
tu peux envoyer a l'un un poeme sur les jeux d'echecs qui parlera de "tour"

et a l'autre un message parlant de Mr Bonickhausen .....

et seul la réunion des deux personnes avec leur indices respectif auront de quoi reconstituer "tour Eiffel" ....
bon c'est trivial, mais le principe y est :)

2) On peut généraliser la méthode que vous aurez trouvée à n personnes.
Comment faites-vous pour distribuer un code crypté à n personnes
sachant qu' il est nécessaire que toutes ces personnes soient présentes pour trouver le code ?
meme principe que ci dessus , avec une énigme a resoudre a plusieurs ....
chacuns des participants, ayant une partie de la "carte au trésors"

d'ailleurs ça peut aussi etre une portion de photos pour chacun, une fois réuni donne l'aperçut d'un monument celebre
qui est la clef ....
3) Vous désirez passer un texte à une autre personne sans que l’on puisse lire le texte
et vous ne pouvez en aucun cas lui passer une clé de décryptage en claire (donc pas de clé publique)
La seule possibilité est de lui transmettre un texte crypté.
La solution n’est pas dans l’utilisation du RSA ou d’un autre algo à clé publique
et aucune clé ni aucune information autre que le texte crypté ne peuvent être transmises.
Comment faites-vous pour que cette autre personne puisse lire le texte?

ça depends, si par exemple les deux personnes se connaissent depuis longtemps
un fait commun, un mot souvent dit, ou une anecdote résumé en un mot ou une phrase peut servir de clef ..

autre solution , la clef de decryptage est en fait un principe de décryptage
comme Cesar a son epoque, il suffisait de décaler les lettres de l'alphabet du message crypté reçut
pour le lire en clair
il existe plein d'autre systeme qui permettent de crypter/decrypter un texte sans clef

une lettre sur deux, ou bien la suite de PI pour le choix de la lettre a decoder ...
ou la suite de Fibonacci, les nombres premiers etc ....


on peut meme employé ces suites pour lire des mots se trouvant dans un Text, un livre, un discours etc...


un qui est connu et qui est tout simple , c'est d'utiliser une police de caracteres symbolique
un symbole remplace une lettre ... il suffit de savoir la table de dechifrage
ou bien ,d'utiliser simplement une police de caractere fourni par windows
exemple
Bonjour
deviens en fonte "BookShelf Symbole 7" ceci : Image



autre solution, c'est que le Pass soit la personne (son nom, son pseudo, le nom de son chien, de sa mere , ou dieu sait quoi ... :lol: )
pas besoin de le transmettre du coup ... seul la transmission d'un indice suffirai , pour mettre sur la voie du pass employé...

un prg peut tres bien encoder/decoder un text, si les deux participants ont le meme prg , pas de probleme
chaqu'un des prg etant capable d'encoder un message pour l'autre , et de decoder le message reçut de l'autre
du coup ;; les codages peuvent meme etre different pour l'un et pour l'autre
Image
Image
Site: http://michel.dobro.free.fr/
Devise :"dis moi ce dont tu as besoin, je t'expliquerai comment t'en passer"
PAPIPP
Messages : 534
Inscription : sam. 23/févr./2008 17:58

Re: Quelques problèmes de cryptage à résoudre.

Message par PAPIPP »

@zorro

Merci de tes réponses ;

Quand je compare ce que j’ai écrit et ce que tu as compris.
Je remarque que j’ai manqué de précision.

Voici les éléments qui manquent dans les propositions

Pour les 2 premiers problèmes
1) l’expéditeur envoie à chaque personne éloignée une chaine cryptée soit avec un mot de passe soit avec une clé générée aléatoirement et qui sert de mot de passe ou de chaine cryptée.
2) Les chaines cryptées et les clés sont de même longueur que le code du coffre.
3) Les seuls endroits sécurisés sont le lieu d’expédition et chaque lieu de réception.

Pour le 3em problème tous les messages échangés sont cryptés avec un mot de passe inconnu de l’autre personne éloignée.
Comme dans les précédents problèmes seuls le lieu d’expédition et le lieu de réception sont sécurisés.
Ce dernier pb est adapté au numérique en provenance du pb suivant :
Bernard est fiancé à Alice mais cette dernière vit à plusieurs centaines de kilomètres de Bernard.
Pour son anniversaire Bernard lui envoie par la poste ou par un autre moyen un coffret (petit coffre) contenant des bijoux et muni d’un cadenas appartenant à Bernard.
Quand Alice reçoit le coffret muni du cadenas de Bernard dont elle n’a pas la clé elle ne peut l’ouvrir alors qu’elle sait par l’adresse sur le colis qu’il a été envoyé par Bernard , adresse qu’elle connait depuis leur première rencontre.

Que fait Alice pour lui permettre d’ouvrir le coffret ?
Inutile de téléphoner la clé du cadenas ne pourra pas suivre. Et pour plus de sécurité Bernard n’enverra jamais à Alice la clé de son cadenas.
Ps: dans le 3em pb les prg de l'expéditeur et du récepteur ne sont pas forcément les mêmes mais il ont une caractéristique identique qui fait partie du problème.

A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
Avatar de l’utilisateur
Kwai chang caine
Messages : 6962
Inscription : sam. 23/sept./2006 18:32
Localisation : Isere

Re: Quelques problèmes de cryptage à résoudre.

Message par Kwai chang caine »

Zorro a écrit :autre solution, c'est que le Pass soit la personne (son nom, son pseudo, le nom de son chien, de sa mere , ou dieu sait quoi
Une autre idée qui m'a traversé l'esprit en te lisant..oui des fois ya autre chose que des courants d'air qui me traverse :mrgreen:
On pourrait utiliser l'adresse mac ou l'ip de la carte.
Comme ça même pas besoin d'entrer le nom d'utilisateur, ou autre infos persos... c'est ton pc qui le fait à ta place...
Et ca permet en plus de sélectionner ce qu'on veut décrypter selon la machine avec le même texte crypté 8)
ImageLe bonheur est une route...
Pas une destination

PureBasic Forum Officiel - Site PureBasic
PAPIPP
Messages : 534
Inscription : sam. 23/févr./2008 17:58

Re: Quelques problèmes de cryptage à résoudre.

Message par PAPIPP »

Bonjour à tous

Voici comment Bernard et Alice ont résolu leur problème.

1) Bernard envoie à sa fiancée Alice un coffret de bijoux muni de son propre cadenas.
2) Alice reçoit le coffret avec le cadenas de Bernard et place son propre cadenas sur le coffret.
3) Elle renvoie le coffret muni des 2 cadenas à Bernard.
4) Bernard reçoit le coffret avec son cadenas et celui d’Alice.
5) Il retire son cadenas et renvoie le coffret muni du cadenas d’Alice à celle-ci.
6) Alice reçoit le coffret avec son propre cadenas l’enlève et accède aux bijoux que lui a envoyé Bernard.

Je ne sais si cela peut vous aider à résoudre les 3 problèmes, mais si l’on imagine que placer un cadenas est un cryptage
et que l’enlever est un décryptage vous pouvez imaginer le processus pour résoudre le 3em problème.

Avant de me donner la solution essayez votre algorithme.
Si Mo est le message à faire passer et crypt1 et decrypt1 les processus de Bernard.
Avec crypt2 et decrypt2 les processus d’Alice.

Alors vérifier que ( Mo crypt1) suivi de Crypt2 et de decrypt1 et enfin decrypt2 = Mo
Ce qui revient à vérifier que Mo crypt1 crypt2 decrypt1 = Mo crypt2.
Pour ma part je ne connais qu’un seul algorithme capable de réaliser cela mais peut être en existe-t-il au moins un autre.

A+
Dernière modification par PAPIPP le ven. 24/nov./2017 12:54, modifié 1 fois.
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
Avatar de l’utilisateur
Zorro
Messages : 2185
Inscription : mar. 31/mai/2016 9:06

Re: Quelques problèmes de cryptage à résoudre.

Message par Zorro »

PAPIPP a écrit : Alors vérifier que ( Mo crypt1) suivi de Crypt2 et de decrypt1 et enfin decrypt2 = Mo
Ce qui revient à vérifier que Mo crypt1 crypt2 decrypt1 = Mo crypt2.
Pour ma part je ne connais qu’un seul algorithme capable de réaliser cela mais peut être en existe-t-il au moins un autre.

A+
ça s'appelle du sur-chifrage
et il existe pletore de façons de sur-chiffrer ..

exemple :
Clair+Xor+clef= crypt (Premier chifrage)
crypt +Xor+Clef2=Cryptx2 (on peut ainsi Sur-encrypter autant de cryptage qu'on veux)

mais cela aurai aussi put etre :
Clair+Xor+Clef=Crypt (premier chiffrage)
Crypt+Vigenere+Clef2=Cryptx2
on peut ainsi Sur-encrypter autant de Cryptage et de type d'encryptage qu'on veux)
cependant il faut impérativement, décrypter dans le sens inverse du cryptage
si on encrypte en Xor , puis en vigenere , il faudra d'abord décrypter en vegenere , puis en Xor

pareil , si on encrypte avec XOR + Clef1 puis Xor+Clef2 , il faudra decrypter d'abord en Xor+Clef2 puis Xor+Clef1

ici pour l'exemple j'ai utilisé Xor et/ou vigenere , mais on aurai pu utiliser Cesars , ou tout type d'embrouillage

par exemple , un texte a crypter

tu mets les caracteres un par un, dans une list() (ou tableau) avec leur position
chaque caractere a ainsi son identité et sa position dans le text, qu'on note
Z=1
O=2
R=3
R=4
O=5

on melange le tableau ou la list()
ça nous sort par exemple (bien sur ce serai le code ASCII et pas les lettres en clair )
R,3,O,5,O,2,Z,1,R,4
(ici R,3 signifie que la lettre 'R' va a la troisieme place dans le text etc...)

on sauve le nouvel ordre dans un fichier texte (donc ce fichier text contient notre text avec les lettres toutes mélangées ET leur Ordre dans le Texte)

d'une certaine façon le cryptage est inclu dans le text
pour decrypter il suffit de mettre en tableau (ou en list()) les caracteres lues dans le fichier
on se retrouverai alors avec une liste du type :
R 3
O 5
O 2
Z 1
R 4

il n'y aurai plus qu'a remettre en ordre en se servant de la position
donc on commence par la plus petite '1'
1=Z
2=O
3=R
4=R
5=O

voila décodé !

juste pour dire qu'il y a des centaines de façon d'encoder un text et sans mot de pass
seulement par une methode , c'est ce que j'appelle de l'encodage Rubicks Cub !!

toutes les couleurs sont mélangées , il suffit d'avoir la methode pour reconstituer le cub (le text) en clair :)
ça peut etre un numero d'ordre comme l'exemple que je cites
ou bien simplement une methode de melange (un peut comme pour faire une tresse de cheveux) un mouvement (deplacement ou meme un Swap)
des caracteres qui soit régulier .... un truc qui puisse se refaire a l'inverse en "détricotant" :)

désolé, je n'ai pas le temps en ce moment de me pencher sur ton algo de cryptage ...
soucis perso + bricolages a la maison ... je ne passe sur le forum que pour lire :)
Image
Image
Site: http://michel.dobro.free.fr/
Devise :"dis moi ce dont tu as besoin, je t'expliquerai comment t'en passer"
PAPIPP
Messages : 534
Inscription : sam. 23/févr./2008 17:58

Re: Quelques problèmes de cryptage à résoudre.

Message par PAPIPP »

Bonjour à tous

Voici le prg qui a permis de crypter le 4e pb

Le poème de rimbaud «’ le dormeur du val n’est pas le texte du pb »

Ce prg devrait vous faciliter la tâche pour créer un prg de décryptage et ainsi trouver le texte du 4em pb.

Code : Tout sélectionner

Structure S_X_cr ; S comme structure X comme dimension inconnue et cr comme crochet []
	StructureUnion
		VA.a[0]   ; ascii
		VB.b[0]   ; byte
		VC.c[0]   ; character
		VS.s{1}[0]; String 1 Byte
		VS2.s{2}[0]; String 2 Bytes
		VS3.s{3}[0]; String 3 Bytes
		VS4.s{4}[0]; String 4 Bytes
		VS8.s{8}[0]; String 8 Bytes
		VS16.s{16}[0]; String 16 Bytes
		VS32.s{32}[0]; String 32 Bytes
		VS64.s{64}[0]; String 64 Bytes
		VS128.s{128}[0]; String 128 Bytes
		VS256.s{256}[0]; String 256 Bytes
		VS512.s{512}[0]; String 512 Bytes
 		VS1024.s{1024}[0]; String 1024 Bytes
 		VS2048.s{2048}[0]; String 2048 Bytes
    Vu.u[0]   ; unicode
		Vw.w[0]   ; word
		Vl.l[0]   ; long
		Vi.i[0]   ; integer
		Vq.q[0]   ; quad
		Vf.f[0]   ; float
		Vd.d[0]   ; double
	EndStructureUnion
EndStructure
Structure BSTR
  Long.l
  chaine.S_X_cr
EndStructure 
Structure SORTIE 
  LONG.l
  POURC.F
EndStructure 
Structure SORTIEC 
  StructureUnion 
    COMPLEX.Q
    STAT.SORTIE
  EndStructureUnion
EndStructure
; Procedure.l STRINGtoBSTR(String$)
 Procedure.l ASCIItoBSTR(String$)
 Protected Result = 0
;   Static Result = 0
  CompilerIf #PB_Compiler_Unicode
    Result = SysAllocString_(@String$)
  CompilerElse
    Protected *buff = AllocateMemory(Len(String$)*2 + 4)
    If *buff
      PokeS(*buff, String$, -1, #PB_Unicode)
      Result = SysAllocString_(*buff)
      FreeMemory(*buff)
    EndIf
  CompilerEndIf
  ProcedureReturn Result
EndProcedure

; Procedure.l ASCIItoBSTR(asciiString$)
; ;   shared FLAG_BSTR
;   Static res0,res1,res2,res3,res4,res5,res6,res7,res8,res9
;   Macro ALLOCBUFF (_num)
;     CompilerIf #PB_Compiler_Unicode
;         long2BSTR=Len(asciiString$)
;         Res#_num = SysAllocString_(@asciiString$)
;         nb_car_unicode=Len(asciiString$)
;         nb_car_ASCII=PeekL(Res#_num-4)
; ;        debug _n(nb_car_unicode)+_n(nb_car_ascii)
;  CompilerElse
;         Protected *buff = AllocateMemory(Len(asciiString$)*2 + 2)
;         If *buff
; ;            debug "2 "+_nl+_n(FLAG_BSTR)
;           PokeS(*buff, asciiString$, -1, #PB_Unicode)
;           Res#_num = SysAllocString_(*buff)
;           FreeMemory(*buff)
;         EndIf
;       CompilerEndIf
;       FLAG_BSTR+1
; ;       debug "3 "+_nl+_n(FLAG_BSTR)
; ;       debug "3 "+str(peekl(Res#_num-4))
;      ProcedureReturn Res#_num
;   EndMacro  
;   Select FLAG_BSTR 
;     Case 0 
;       ALLOCBUFF(0)
;     Case 1 
;       ALLOCBUFF(1)
;     Case 2 
;       ALLOCBUFF(2)
;     Case 3 
;       ALLOCBUFF(3)
;     Case 4
;       ALLOCBUFF(4)
;     Case 5 
;        ALLOCBUFF(5)
;    Case 6
;        ALLOCBUFF(6)
;    Case 7
;        ALLOCBUFF(7)
;    Case 8  
;        ALLOCBUFF(8)
;    Case 9 
;        ALLOCBUFF(9)
;      Default
;        MessageRequester(" ATTENTION !! ","Impossible de dépasser sans risque les 10 appels",#PB_MessageRequester_Ok ) 
;        End
;   EndSelect   
; EndProcedure
HISTOIRE.S="Le Dormeur du Val"+#LF$
HISTOIRE+""+#LF$
HISTOIRE+"C'est un trou de verdure où chante une rivière"+#LF$
HISTOIRE+"Accrochant follement aux herbes des haillons"+#LF$
HISTOIRE+"D'argent ; où le soleil, de la montagne fière,"+#LF$
HISTOIRE+"Luit : c'est un petit val qui mousse de rayons."+#LF$
HISTOIRE+""+#LF$
HISTOIRE+"Un soldat jeune, bouche ouverte, tête nue,"+#LF$
HISTOIRE+"Et la nuque baignant dans le frais cresson bleu,"+#LF$
HISTOIRE+"Dort ; il est étendu dans l'herbe sous la nue,"+#LF$
HISTOIRE+"Pâle dans son lit vert où la lumière pleut."+#LF$
HISTOIRE+""+#LF$
HISTOIRE+"Les pieds dans les glaïeuls, il dort. Souriant comme"+#LF$
HISTOIRE+"Sourirait un enfant malade, il fait un somme :"+#LF$
HISTOIRE+"Nature, berce-le chaudement : il a froid."+#LF$
HISTOIRE+""+#LF$
HISTOIRE+"Les parfums ne font pas frissonner sa narine ;"+#LF$
HISTOIRE+"Il dort dans le soleil, la main sur sa poitrine"+#LF$
HISTOIRE+"Tranquille. Il a deux trous rouges au côté droit."+#LF$
HISTOIRE+""+#LF$
HISTOIRE+"Arthur Rimbaud"

; 
*hist2.S_X_cr=AllocateMemory(Len(histoire)*2+12)
*hist3.S_X_cr=AllocateMemory(Len(histoire)*2+12)
*hist4.S_X_cr=AllocateMemory(Len(histoire)*4+12)
*hist.S_X_cr=ASCIITOBSTR(Histoire)
LENGTH=Len(Histoire)
ligne1$=""
ligne2$=""
ligne3$=""
LIGNE4$=""
Dim tab.c(length-1)
For i=0 To length-1
  tab(i)=i 
Next 
Debug "*******************************************************************"
 RandomSeed(length) 
 RandomizeArray(Tab())
 For j=0 To length-1
   JJ=tab(j)
   *hist2\VC[jj]=*hist\VC[j] ! jj
 Next 
; Debug mp_h(*hist2,32,222)
;  Debug PeekS(*hist2,length*2)
 igne10$=""
ligne20$=""
ligne30$=""
ligne40$=""
Debug "*******************************************************************"
 
  For j=0 To length-1
    JJ=tab(j)
    *hist3\VC[j]= *hist2\VC[jj] ! jj
 Next
 Debug PeekS(*hist3)
 PokeL(*hist2-4,PeekL(*hist-4))
   ;;;************************************************************************************************
   ;;; mise en data.q pour présenter au forum
  NBdata.q=PeekL(*hist2-4)/8
 nbdat+1
numf_out=CreateFile(#PB_Any,"C:\CRYPT_dataq.pb") :; ceci ecrit le fichier pb (txt) pour etre charge dans l'editeur !!
WriteStringN(numf_out,"DataSection")             ; commence la section des data
WriteStringN(numf_out,"donne_num:")
For i=0 To nbdata
  dataq$+Str(PeekQ(*Hist2-4+(i*8))); +"  "+_n(*MemoryID+(i*8))+" "+_h(*MemoryID+(i*8))
  nb_l+1
  If nb_l=6
    WriteStringN(numf_out,"Data.q "+dataq$)
    nb_l=0
    dataq$=""
  Else
    If i<>nbdata
      dataq$+","
    EndIf
  EndIf
Next
If Len(dataq$)>0
  WriteStringN(numf_out,"Data.q "+dataq$)
EndIf
WriteStringN(numf_out,"fin_donne:")
WriteStringN(numf_out,"EndDataSection") :            ; commence la section des data

CloseFile(numf_out)
; freememory(*hist2)
; freememory(*hist3)
; freememory(*hist4)

;  
End 
A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
PAPIPP
Messages : 534
Inscription : sam. 23/févr./2008 17:58

Re: Quelques problèmes de cryptage à résoudre.

Message par PAPIPP »

Bonjour à tous

Voici pour le 4em pb une autre façon de crypter qui n’est pas celle utilisée dans le 4em pb

En effet ici il ya sur-cryptage puisque l’on ne travaille que sur un seul texte

Le swap entre 2 éléments du même texte engendre un sur-cryptage dont voici l’explication.

La boucle va du caractère 0 jusqu’au dernier caractère au pas d’incrémentation de 1.

Or lorsque l’on commence la boucle sur le caractère 0 dans la table indice 0 on trouve par exemple 56 dans la table de mélange et nous allons échanger le caractère 0 avec le caractère 56
Mais la boucle continue à explorer caractère après caractère 1 2 3 …56. avec des échanges à chaque caractère qui seront d’un niveau supérieur ou inférieur à l’indice 1 2 3 ….55
mais à 56 nous avons déjà échangé et c’est le caractère 0 de l’original qui se trouve ici.
Alors ici la table de mélange nous donne un numéro supérieur ou inférieur à 56 et ces 2 caractères vont à nouveaux être échangés

Il en sera de même d’autres caractères placés avant et après 56.

La différence de cryptage lorsque nous avons 2 chaines dont l’une est vide c’est de prendre le caractère 0 et de le placer en position 56 dans la chaine vide mais celui-ci ne sera plus jamais touché.
Nous aurons donc un mélange simple. Ce qui n’est pas le cas lorsque l’on échange les caractères dans la même chaine.

Bien qu’apparemment identiques le cryptage et le décryptage des 2 méthodes sont donc différents.

Code : Tout sélectionner

Structure S_X_cr ; S comme structure X comme dimension inconnue et cr comme crochet []
	StructureUnion
		VA.a[0]   ; ascii
		VB.b[0]   ; byte
		VC.c[0]   ; character
		VS.s{1}[0]; String 1 Byte
		VS2.s{2}[0]; String 2 Bytes
		VS3.s{3}[0]; String 3 Bytes
		VS4.s{4}[0]; String 4 Bytes
		VS8.s{8}[0]; String 8 Bytes
		VS16.s{16}[0]; String 16 Bytes
		VS32.s{32}[0]; String 32 Bytes
		VS64.s{64}[0]; String 64 Bytes
		VS128.s{128}[0]; String 128 Bytes
		VS256.s{256}[0]; String 256 Bytes
		VS512.s{512}[0]; String 512 Bytes
 		VS1024.s{1024}[0]; String 1024 Bytes
 		VS2048.s{2048}[0]; String 2048 Bytes
    Vu.u[0]   ; unicode
		Vw.w[0]   ; word
		Vl.l[0]   ; long
		Vi.i[0]   ; integer
		Vq.q[0]   ; quad
		Vf.f[0]   ; float
		Vd.d[0]   ; double
	EndStructureUnion
EndStructure
Structure BSTR
  Long.l
  chaine.S_X_cr
EndStructure 
STRUCTURE SORTIE 
  LONG.l
  POURC.F
EndStructure 
STRUCTURE SORTIEC 
  StructureUnion 
    COMPLEX.Q
    STAT.SORTIE
  EndStructureUnion
ENDSTRUCTURE  
Procedure.l STRINGtoBSTR(String$)
  Protected Result = 0
;   Static Result = 0
  CompilerIf #PB_Compiler_Unicode
    Result = SysAllocString_(@String$)
  CompilerElse
    Protected *buff = AllocateMemory(Len(String$)*2 + 4)
    If *buff
      PokeS(*buff, String$, -1, #PB_Unicode)
      Result = SysAllocString_(*buff)
      FreeMemory(*buff)
    EndIf
  CompilerEndIf
  ProcedureReturn Result
EndProcedure
procedure MELANGEUR(*CENT.S_X_cr,DEB_RANDOM,XORN=0)
;   ;Shared ou Global (voir aussi: Protected et Static).
  protected LONG=peekl(*cent-4)
  protected Result;;,Cpass.s=space(200)
Dim tab.U(long/2-1)
For i=0 To lONG/2-1
  tab(i)=i
Next
RandomSeed(DEB_RANDOM)
RandomizeArray(Tab())
For j=0 To lONG/2-1
  JJ=tab(j)
  swap *cent\VC[jj],*Cent\VC[j] 
  if XORN>0
     *Cent\VC[j] ! (j+XORN)
  endif  
  Next
endprocedure 
procedure ORDONNE(*CENT.S_X_cr,DEB_RANDOM,XORN=0)
;   ;Shared ou Global (voir aussi: Protected et Static).
  protected LONG=peekl(*cent-4)
  protected Result;;,Cpass.s=space(200)
Dim tab.U(long/2-1)
For i=0 To long/2-1
  tab(i)=i
Next
RandomSeed(DEB_RANDOM)
RandomizeArray(Tab())
For j=LONG/2-1 To 0 step -1;; il faut inverser l'ordre d'incrémentation en décrémentation pour obtenir l'original
;  ;;                         donc crypte et décrypte ne sont pas tout à fait les mêmes algorithmes
  JJ=tab(j)
  swap *cent\VC[jj],*Cent\VC[j] 
  if XORN >0
     *Cent\VC[jj] ! (j+XORN)
   endif 
  Next
endprocedure 

HISTOIRE.S="Les Voleurs et l'Âne"+#LF$
HISTOIRE+""+#LF$
HISTOIRE+"Pour un Âne enlevé deux voleurs se battaient :"+#LF$
HISTOIRE+"L'un voulait le garder ; l'autre le voulait vendre."+#LF$
HISTOIRE+"Tandis que coups de poing trottaient,"+#LF$
HISTOIRE+"Et que nos champions songeaient à se défendre."+#LF$
HISTOIRE+"Arrive un troisième larron,"+#LF$
HISTOIRE+"Qui saisit Maître Aliboron."+#LF$
HISTOIRE+"L'Âne c'est quelquefois une pauvre Province."+#LF$
HISTOIRE+"Les Voleurs sont tel et tel Prince ;"+#LF$
HISTOIRE+"Comme le Transylvain, le Turc, et le Hongrois."+#LF$
HISTOIRE+"Au lieu de deux j'en ai rencontré trois."+#LF$
HISTOIRE+"Il est assez de cette marchandise,"+#LF$
HISTOIRE+"De nul d'eux n'est souvent la Province conquise."+#LF$
HISTOIRE+"Un quart Voleur survient qui les accorde net,"+#LF$
HISTOIRE+"En se saisissant du Baudet."+#LF$
HISTOIRE+""+#LF$
HISTOIRE+"Jean de la Fontaine"
*HISTBSTR.S_X_cr=STRINGtoBSTR(HISTOIRE)
LONG=peekl(*HISTBSTR-4)
MELANGEUR(*HISTBSTR,12345)
    
DEBUG _N(long)
debug peeks(*HISTBSTR)
debug "****************************************************"
ordonne(*HISTBSTR,12345)
 debug peeks(*HISTBSTR)


PS : le chiffre permettant le Randomseed et celui qui permet le XORN peuvent être considéré comme mots de passe.
A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
PAPIPP
Messages : 534
Inscription : sam. 23/févr./2008 17:58

Re: Quelques problèmes de cryptage à résoudre.

Message par PAPIPP »

Bonjour à tous

Voici le solution du pb N° 1.

1) Vous avez un coffre qui contient de l’argent et des bijoux et celui-ci s’ouvre avec une clé secrète (code numérique ou alpha-nu) que vous désirez transmettre à 2 personnes
de façon que chacune d’entre-elles ne puissent accéder à l’ouverture du code sans l’aide de l’autre.
Il faut que les deux personnes soient d’accord et présentes.
La méthode pour retrouver le code leur a été fourni, elle fait partie du problème.
Pour garder le plus de robustesse vous ne coupez pas le code en deux mais vous envoyez à chacune d’elle un texte crypté qui contient le code entier cryptée donc non lisible.
Comment faites-vous ?

La solution numérique est simple et c’est aussi une excellente approche pour aborder la codification ALPHA-NUMERIQUE qui pose quelques pb.

Code : Tout sélectionner

Macro _q_t_
"
EndMacro
Macro _n (__n)
_q_t_#__n#=_q_t_+Str(__n)+" "
EndMacro
;;Chez A M_A message M_A.Q=123456789 
;;et A envoie à B la clé  CLE_A.Q=$EDCA98701 
;;         et à C le résultat de M_A ! CLE_A= A_
M_A.Q=123456789
; CLE_A.Q=$EDCA98701;;; il n'est pas nécessaire d'imposer une clé 
; randomseed($7FFFFFFF) ;;;; pour générer le même nombre aléatoire cette instruction n'est pas nécessaire pour ceproblème.
CLE_A.Q=random($7FFFFFFF) ;;; A peut par sécurité conserver la clé CLE_A chez A mais cela n'est pas nécessaire.
A_CRYPTE.Q=M_A ! CLE_A
debug "***  Chez A M_A message M_A.Q=123456789 "
debug "et A envoie à B la clé  CLE_A.Q  "+_n(CLE_A)
debug "         et à C le résultat de M_A ! CLE_A= A_CRYPTE.Q"
Debug _N(M_A)+_n(CLE_A)+_n(A_CRYPTE)
debug ""
DEBUG "** Donc B reçoit "+_n(CLE_A)
debug "**   et C reçoit "+_n(A_CRYPTE)


Debug "*** il suffit maintenant que B et C soit d'accord devant un tiers pour prouver leur accord et  pour retrouver le code d'origine "

code_origine.q=A_crypte ! CLE_A 
debug _n(A_CRYPTE)+_n(CLE_A)+"="+_n(A_CRYPTE ! CLE_A)

debug " *** On retrouve le code d'origine  "+_n(CODE_ORIGINE)+" Elémentaire mon cher Watson !!!! "
debug "                                                        Oui bien sûr mais quant est-il avec un code alpha-numérique ????"

Attention la solution numérique cache un gros problème en alpha-numérique.
En numérique n ! n = 0 ce qui ne pose aucun pb puisque 0 est un élément du nombre,
mais en alpha-nu c’est la même chose carx ! carx =0 or le risque de collision de 2 caractères devient non négligeable en alpha-numérique.
Un caractère chr(0) Ascii ou Unicode en PB est la limite de la chaine pour les instruction sur les chaines de caractères comme :
Asc,Ascii,Bin,Chr,CountString,EscapeString,FindString,FormatNumber,Hex,InsertString,LCase,LSet;LTrim,Left,Len
Mid,RSe,RTrim,RemoveString,ReplaceString,ReverseString,Right,Space,Str,StrD,StrF,StrU,StringByteLength,StringField
Trim,UCase,UTF8,UnescapeString,Val,ValD,ValF
Donc ces instructions ne doivent pas être utilisées en alpha-nu avec cet algo car les collisions qui donnerons chr(0) risquent un dysfonctionnement.

Une analyse de texte en français par exemple donne :

Blanc séparation de 2 mots 27%
Les lettres majuscules sont peu employées
Pourcentage d’utilisation des voyelles dans un texte français blanc compris :
a 4.63620981%, e 8.73096447%, i 4.06091371%, o 3.67174281%, u 4.61364918%, y 0.10152284%

Pourcentage d’utilisation des consonnes dans un texte français :

b 0.66553864%,c 1.59052453%,d 1.97405527%,f 0.81218274%,g 0.66553864%,h 0.53017484%,j 0.27072758%
l 3.16412860%,m 1.43260011%,n 4.41060350%,o 3.67174281%,p 1.73716864%,q 0.63169769%,r 4.06091371%
s 4.52904681%,t 4.59672871%,u 4.61364918%,v 1.06034969%,x 0.24252679%,y 0.10152284%,z 0.20304569%

Ces statistiques sont réalisées avec les 256 possibilités d'un alphabet ASCII.

Une étude plus approfondie donne suivant le type d'alphabet utilisé des probabilités de collision non négligeables.
Autres remarques de cette étude :

1) Éviter d'utiliser, dans l'alphabet qui permettra de générer une clé, de placer des caractère ayant une probabilité élevée
Comme le blanc qui représente 27% d'un texte ne doit si possible pas être utilisé dans l'alphabet de référence.
car il y a un risque de collision importante.

2) C'est l'alphabet de référence le plus long en nombre de caractères qui donne la probabilité de collision la plus faible.


PS : Vous êtes sur une bonne piste pour réaliser

1) le même pb avec un code ou un message en alpha_nu.
2) le 2em pb qui généralise le processus à N personnes.



A+
Dernière modification par PAPIPP le mer. 29/nov./2017 11:16, modifié 1 fois.
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
Avatar de l’utilisateur
Zorro
Messages : 2185
Inscription : mar. 31/mai/2016 9:06

Re: Quelques problèmes de cryptage à résoudre.

Message par Zorro »

c'est du Xor , on a pleins de code Xor sur le forum ;)

pour eviter le collision , il suffit de tester avant et utiliser un caractere "Flag" convenu d'avance
pour signaler le probleme :)
Image
Image
Site: http://michel.dobro.free.fr/
Devise :"dis moi ce dont tu as besoin, je t'expliquerai comment t'en passer"
PAPIPP
Messages : 534
Inscription : sam. 23/févr./2008 17:58

Re: Quelques problèmes de cryptage à résoudre.

Message par PAPIPP »

@Zorro

Oui bien sûr c’est xor et je sais qu’il existe de nombreux codes sur le forum.
Mais la plupart des problèmes posés ont des solutions que la plupart des personnes connaissent mais qu’elles ne voient pas.
Ici le processus est de crypter le code et d’envoyer à B la clé de cryptage par exemple et à C le résultat par XOR
Ce qui se réalise assez rarement car envoyer la clé de cryptage est surprenant non. On a plutôt envie de la conserver précieusement.

Il reste toutefois 2 problèmes à résoudre

1) Le pb est résolu pour 2 personnes il ne l’est toujours pas pour N personnes
2) Le pb n’est toujours pas résolu pour un code en alpha-nu surtout si ce code est très long >20Koctets Et que la clé est tirée au hasard. Si l’on automatise le tout il n’est pas question de reconnaitre l’endroit ou les endroits où on lieu les collisions on doit les contourner automatiquement..


A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
PAPIPP
Messages : 534
Inscription : sam. 23/févr./2008 17:58

Re: Quelques problèmes de cryptage à résoudre.

Message par PAPIPP »

Bonjour à tous

Voici une solution pour résoudre le XOR en Alphanumérique

Le risque de collision entre deux chaines dans un texte français n’est pas négligeable.

Suivant l’alphabet de référence que l’on prend et le choix de certains caractères à haute probabilité d’apparaitre comme l'espace avec 28% et e avec plus de 8%
Le risque de collision c'est-à-dire Car1 XOR Car2 = 0 est proche de 1/2000 c'est-à-dire que l’on à un risque de collision tous les 2000 caractères.

Dans ce cas il est impossible d’utiliser les instructions sur les strings qui considèrent le 0 comme une fin de chaine.

Il nous faut une structure permettant à une chaine d’avoir des valeurs nulles donc de connaître sa longueur et de pouvoir manipuler la chaine sans risque de perdre l’une ou plusieurs de ses parties
La structure que j’ai choisie est la structure BSTR de Microsoft bien connu des utilisateurs de Visual-Basic.

Structure BSTR
Long.l
chaine.S ;;; en Unicode
EndStructure

Les instructions de manipulation de ces chaines seront des instructions de bas niveau soit
des PEEKx
des POKEx
des instructions ASM
Des instructions PB mais proches de la machine COPYMEMORY ALLOCATEMEMORY
Et l’API SysAllocString_ permettant de convertir une chaine (ASCII ou Unicode en BSTR( voir Freak)

Il nous faut donc 3 fonctions au minimum
1) XORALPHA Un XOR alphanumérique qui fonctionne sur 2 structures BSTR (même longueur)
2) KEYGEN un générateur de clé aléatoire qui crée des clés au format BSTR
3) STRINGtoBSTR qui converti toute chaine ASCII ou Unicode en structure BSTR

Remarques :
1) seul le programme XORALPHA peut produire des chaines avec des collisions donc avec des caractères Nul.
2) Dans la convention BSTR d’adresse donnée pointe toujours sur le premier octet de la chaine Unicode et non sur la longueur qui se situe à adresse-4

Code : Tout sélectionner

Macro _q_t_
"
EndMacro
Macro _n (__n)
_q_t_#__n#=_q_t_+Str(__n)+" "
EndMacro
Macro _s (__S)
_q_t_#__S#=_q_t_+__S+" "
EndMacro
Structure BSTR
  Long.l
  chaine.S
EndStructure 

Procedure.l STRINGtoBSTR(String$)
  EnableExplicit
  Protected Result = 0
  CompilerIf #PB_Compiler_Unicode
    Result = SysAllocString_(@String$)
  CompilerElse
    Protected *buff = AllocateMemory(Len(String$)*2 + 4);; modif PAPIPP pour ^étre conforme au BSTR
    If *buff
      PokeS(*buff, String$, -1, #PB_Unicode)
      Result = SysAllocString_(*buff)
      FreeMemory(*buff)
    EndIf
  CompilerEndIf
  ProcedureReturn Result
  DisableExplicit
EndProcedure


Procedure.s KEYGEN(LONG_CAR, DEB_RANDOM, deb_car,fin_car) 
  EnableExplicit
  ; Générateur de clé aléatoire :
  ; Long_car longueur de la clé si possible de même longueur que le message à crypter
  ; DEN_RANDOM SI zero pas de randomseed 
  ;            SI <>0 randomseed car RandomSeed() n'est utile que lorsque l'objectif est de générer des nombres aléatoires 
  ;              dans le même ordre à chaque fois que le programme est exécuté.
  ; deb_car N° ASCII du début de table des caractère ASCII de 0 à 255 mais 0 est dans tous les cas éléliminé et remplacé par 1
  ; fin_car N° ASCII de la fin de la table exemple pour être sûr d'avoir des caractère visibles et éditable deb_car =32 et fin_car=126
  ;                    pour les valeurs numériques 1234567890  donnez  deb_car = 48 et fin_car =57 
  ; sortie en UNICODE pour générer par la suite une clé avec une structure BSTR car XOR peut générer chr(0)
  ;                   et donc rendre toutes les instructions PB sur string pratiquement inutilisables.
   Define i,  length , cle$ ,nb
  CompilerIf #PB_Compiler_Unicode
    ;;;; univers UNICODE
  CompilerElse 
    ;;;;; Univers NON UNICODE
    MessageRequester("ATTENTION", " Vous devez Compiler en mode UNICODE")
    End
  CompilerEndIf     
  Static FLAG_KEYGEN=0
  If FLAG_KEYGEN=0
    ;;;********* On peut retiter le blanc qui a une probabilité de 27% donc avec des risques de collision ****************
  Static alphabet$="abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789,;:!<>?./§&é'(-è_çà)=~#{[|`\@]}+°%ù*µ^$£²"+Chr(34)
  For i=160 To 255 
    alphabet$+Chr(I)
  Next 
  FLAG_KEYGEN+1
  EndIf
  If deb_car<1
    deb_car=1
  EndIf 
  If fin_car>255 
    fin_car=255
  EndIf
  If deb_car>fin_car 
    deb_car=fin_car
  EndIf  
If fin_car=0
  length=Len(alphabet$ )
  Dim tab.c(length-1)
  For i=0 To length-1
    tab(i)=PeekC(@alphabet$+i*2) ;;;; Peekc définit l'adresse en octets alors que chaque élément de tab.c() est sur 2 octets
  Next
;   SortArray(tab(),#PB_Sort_Ascending ) ;;; pour mise au point et  vérifier qu'il n'y a pas de doublon 
 fin_car=length-1
 deb_car=0

Else
  Dim tab.c(fin_car-deb_car)
;   Debug _NL+_n(deb_car)+_n(fin_car)
  For i=0 To fin_car-deb_car
    tab(i)=I+deb_car
  Next
EndIf

If DEB_RANDOM<>0
RandomSeed(DEB_RANDOM)
EndIf

RandomizeArray(tab())
cle$=""
For i=1 To LONG_CAR 
  nb=Random(fin_car,deb_car)
  CLE$+Chr(tab(nb-deb_car))
Next  
ProcedureReturn cle$
DisableExplicit
EndProcedure

procedure.l KEYGEN_BSTR(LONG_CAR, DEB_RANDOM, deb_car,fin_car)
  ;   ; sortie en BSTR pour générer une clè  BSTR car XOR peut générer chr(0) (Collision)
  ;   ;                 ces collisions peuvent rendre toutes les instructions PB sur string pratiquement inutilisables 
  ;;;;;         donc utilisation de la structure BSTR
  ProcedureReturn  STRINGtoBSTR(KEYGEN( LONG_CAR, DEB_RANDOM, deb_car,fin_car))
endprocedure  
Procedure.l XORALPHA(*CENT.string,*CPAW.string)
  EnableExplicit
;   ;Shared ou Global (voir aussi: Protected et Static).
  Protected LONG=PeekL(*cent-4)
  Protected Result,*ASORT.string=AllocateMemory(LONG+8);;,Cpass.s=space(200)
  if peekl(*cent-4)<>peekl(*CPAW-4)
    messagerequester("ATTENTION"," Pour le moment les 2 chaines doivent avoir la même longueur")
    end
  endif  
  PokeS(*asort+4,Space(long/2))
  Result = SysAllocString_(*ASORT+4)
  CopyMemory(*CPAW-4,result-4,LONG+4);;; Pour convention BSTR l'adresse pointe sur la chaine et la longueur est à l'adresse -4
  FreeMemory(*ASORT)
 LONG=(LONG/4)+1
 EnableASM
  MOV esi, *CENT
  MOV edi , Result
  MOV ecx, LONG
  !lab1:
  MOV eax, [esi]
  XOR [edi], eax 
  ADD esi,4 
  ADD edi,4
  LOOP lab1
  DisableASM
  ProcedureReturn result
  DisableExplicit
EndProcedure 


Codecoffre$="2a 1b 1e C1" ;; 4 roues 
Debug Codecoffre$
long_car=Len(codecoffre$)
*codecoffre=STRINGtoBSTR(codecoffre$)
Debug _n(long_car)+_n(PeekL(*codecoffre-4))+_s(PeekS(*codecoffre))
;;***********************************************************************************************************************************************************
;; ***** Si vous utilisez KEYGEN qui génére une clé en Unicode il faut pour être compatible avec XORALPHA convertir la chaine en BSTR ou utilisez KEYGEN_BSTR
; clealea$=keygen(long_car,0,33,126);;; génèrer une clé en Unicode
; *clealea=STRINGtoBSTR(clealea$);;;    Convertir la chaine Unicode en BSTR
;;***********************************************************************************************************************************************************
; *clealea=keygen_BSTR(long_car,0,33,126)
*clealea=keygen_BSTR(long_car,0,33,126);;; ici KEYGEN_BSTR offre une clé en structure BSTR  adresse de la longueur *clealea-4 ou peekl(*clealea-4)
*M1=XORALPHA(*codecoffre,*clealea) ;;; Il est nécessaire que les 2 chaines soit en BSTR et de même longueur
;;Chez A  Codecoffre$="2a 1b 1e C1" ;; 4 roues 
;;et A envoie à B la clé  peeks(*clealea) en Unicode
;;         et à C le résultat de XORALPHA(*codecoffre, *clealea)  =  *M1  => peeks(*M1) en Unicode 

;**** Si vous désirez voir la chaine *clealea et *M1 supprimer les commentaires des 3 lignes suivantes  et (F7 pour continuer)
; ShowMemoryViewer(*clealea-4, 32)
; CallDebugger                     
; ShowMemoryViewer(*M1-4, 32)


debug "***  Chez A codecoffre =  2a 1b 1e C1"
debug "et A envoie à B la clé   "+peeks(*clealea)
debug "         et à C le résultat de XORALPHA(*codecoffre, *clealea) = *M1"
debug ""
DEBUG "** Donc B reçoit  *clealea  chaine="+peeks(*clealea)
debug "**   et C reçoit *M1 chaine pouvant être tronquée= "+peeks(*M1)


Debug "*** il suffit maintenant que B et C soit d'accord devant un tiers pour prouver leur accord et  pour retrouver le code d'origine "

*MO=xoralpha(*M1,*clealea)
Debug _n(PeekL(*Mo-4))+_s(PeekS(*Mo))+"   ******  C. Q. F. D."

A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
Avatar de l’utilisateur
Zorro
Messages : 2185
Inscription : mar. 31/mai/2016 9:06

Re: Quelques problèmes de cryptage à résoudre.

Message par Zorro »

bien trop compliqué ton truc :)

voici un exemple simple de codage XOR sans risque de collision de caracteres ....
ici j'utilise "titi" en mot de pass , et la chaine commence par "toto"
donc deja le premier caractere a un risque de "collision" ..

seulement voila, j'utilise un Flag = le caratactere 255 sert de Flag
et lorsqu'on le rencontre, ben on prends le caractere du mot de pass ...comme caractere en clair

en gros, lorsqu'un caractere du mot de pass = caractere de la chaine , on ecrit 255
et si on rencontre 255 on prends le caractere du mot de pass comme caractere en clair

pour compliquer la tache d'un decodeur eventuel
le pass exemple :"titi" est repeté tout le long de la chaine a encoder !!
avec XOR lorsque le pass est aussi long que la chaine a encoder, ben c'est tout simplement impossible a decoder !!
meme avec les stats de frequence des lettres, puisque aucune lettre identique n'aura le meme "code" ... :)

pour info , j'ai fait un encodage perso , qui en plus du XOR encode la position de chaque caractere , et utilise le RandomSeed :)


voici le code XOR sans collision possible :

Code : Tout sélectionner

;***********************************************
;Titre  :*codage XOR sans "collision " possible
;Auteur  : Zorro
;Date  :01/12/2017
;Heure  :13:52:02
;Version Purebasic :  PureBasic 5.60 (Windows - x86)
;Version de l'editeur :EPB V2.68
; Libairies necessaire : Aucune 
;***********************************************


Declare.s encodage_xor(chaine.s,pass.s,mode)

chaine.s="toto de la Lune"+chr(10)+"a la ligne"
pass.s="titi"

debug "la chaine en clair= "+chaine.s
debug "le password= "+pass.s
Debug ""
Debug ""


; on encode la chaine avec le mot de pass
encod.s=encodage_xor(chaine.s,pass.s,#true)
debug "le resultat encodé= "+encod.s
Debug ""
;on decode la chaine crypté avec le mot de pass 
decod.s=encodage_xor(encod.s,pass.s,#False)
debug "le resultat décodé= "+decod.s


Procedure.s Encodage_XOR(chaine.s,Pass.s,Mode)
		; By Zorro
		; ENCODAGE XOR  
		For i=1 to len(chaine.s)
				pos=pos+1
				if pos>Len(pass.s):Pos=1:Endif
				
				cclair=asc(mid(chaine.s,i,1))
				cpass=asc(mid(pass.s,pos,1))
				Select Mode						
						Case #true ; encodage XOR						
						cencode=cclair!(cpass) 
						If cencode=0 ; Cas ou le pass et le clair soit pareil , ou le le code soit plus petit que "l'espace"
								cencode=255   ; recodage si pareil en fait on creer un Flag "255" signifiera qu'on utilisera le meme caractere que le pass donc on encode pas vraiment
						Endif						
						encode.s=encode.s+chr(cencode)
						Case #False ; decodage XOR
						If cclair=255 ; si le code analysé et encodé est 255 alors cela signifie que 
								cdecod= cpass ;le caractere est le meme que le pass ....
						Else
								cdecod=cclair!(cpass) 
						Endif
						decode.s=decode.s+chr(cdecod)
				Endselect
		Next i
		If Mode=#true
				ProcedureReturn encode.s
		Else
				ProcedureReturn decode.s
		Endif
		
EndProcedure
Image
Image
Site: http://michel.dobro.free.fr/
Devise :"dis moi ce dont tu as besoin, je t'expliquerai comment t'en passer"
PAPIPP
Messages : 534
Inscription : sam. 23/févr./2008 17:58

Re: Quelques problèmes de cryptage à résoudre.

Message par PAPIPP »

Bonjour à tous.
@Dobro ou Zorro pour sa politesse à me répondre.

Le prg semble élégant mais qu’en est-il de sa fiabilité et de sa robustesse.

Le prg utilise 2 algorithmes différents pour crypter et décrypter.

1) il ne faut pas se tromper pour savoir s’il faut crypter ou décrypter ( la solution du 3em pb nous le montrera) (Difficulté minime)

2) Le fait de prendre $FF pour flag quand on a une collision n’exclut en aucun cas tous les autres cas ou $FF peut être obtenu. En effet on a 256 possibilités d’obtenir $FF en croisant avec XOR le caractère $ff et l'un des 256 autres caractères.
exemple :

Code : Tout sélectionner

FF=$FF
For i=0 to  $ff 
  r1=ff ! i 
  debug "r1="+hex(r1,#PB_Byte )+"  i="+hex(i, #PB_Byte)+" i="+str(i)+" chr(i)="+CHR(i)+" chr(r1)="+CHR(r1)
Next  
 
On élimine $FF ! 0 =$FF option qui est prise par le prg.
Théoriquement ce qui veut dire que si l’on prend un caractère parmi les 255 on a 1 cas sur 255 d’obtenir $FF parmi les 255 caractères restant.(Il y a symétrie entre les 2 caractères).
Ceci n’est pas négligeable et ici je ne tiens pas compte de la probabilité d’apparition de tel ou tel caractère. En prenant pour 1/255 la probabilité d’apparition d’un caractère (Alphabet 1-255 attention si vous réduisez l’alphabet de référence la proba peut augmenter) pratiquement cela peut arriver dans 4 cas sur 1020 caractères.
Donc attention dans l’utilisation de ce prg il y a des risques de ne pas retrouver le code d’origine.

3) Ici je vais comparer xor numérique avec le prg de Zorro et en même temps donner la solution pour le 2em pb.
Dans le 2em pb pour partager le code parmi N personnes on envoie N clés aux N personnes
Les n-1 premières clés sont générées aléatoirement avec :
 opérateur XOR numérique ou alphanumérique
Mo Message d’origine
On crée N-1 clés aléatoires K2 K3 ….. Kn
K1=Mo  K2  K3  K4  K5 ………………  Kn
Et on envoie K1 K2 K3 K4 K5 …. Kn aux n personnes
Qui pour retrouver le code réaliseront
Mo= K1  K2  K3  K4  K5 ………………  Kn
en numérique nous n’avons aucun pb puisque 0 fait partie du nombre.
Voici un exemple de clé en numérique pour 4 personnes ;

Code : Tout sélectionner

Macro _q_t_
"
EndMacro
Macro _n (__n)
_q_t_#__n#=_q_t_+Str(__n)+" "
EndMacro
;;Maintanant on à 4 personnes qui doivent partager le code  A propriétaire du code B, C, D, E les 4 personnes qui reçoivent une partie du code
;;Chez A M_A message M_A.Q=123456789
; Il faut générer un nombre de clés aléatoires correspondant aux nombre de personnes -1
;; donc avec 4 personnes nous allons générer 3 clé aléatoires

M_A.Q=123456789
; CLE_A.Q=$EDCA98701;;; il n'est pas nécessaire d'imposer une clé
; randomseed($7FFFFFFF) ;;;; pour générer le même nombre aléatoire cette instruction n'est pas nécessaire pour ce problème.
CLE_B.Q=random($7FFFFFFF) ;;; A peut par sécurité conserver la clé CLE_B chez A mais cela n'est pas nécessaire.
CLE_C.Q=random($7FFFFFFF) ;;; A peut par sécurité conserver la clé CLE_C chez A mais cela n'est pas nécessaire.
CLE_D.Q=random($7FFFFFFF) ;;; A peut par sécurité conserver la clé CLE_D chez A mais cela n'est pas nécessaire.

; A va avec ces 3 clés générer la clé  qui permettra de code le message ou le code

CLE_K=(CLE_B ! CLE_C) ! CLE_D
CLE_E.Q=M_A ! CLE_K 



;;Chez A M_A message M_A.Q=123456789
;;et A envoie à B la clé  CLE_B.Q
;;         et à C la clé  CLE_C.q
;;         et à D la cle  CLE_D.q
;;  A réalise CLE_K=(CLE_B ! CLE_C) ! CLE_D qui va permettre de coder le message
;;  A envoie a E le resultat du codage CLE_E

debug "***  Chez A M_A message M_A.Q=123456789 "
debug "Il faut générer un nombre de clés aléatoires correspondant aux nombre de personnes -1"
debug " donc avec 4 personnes nous allons générer 3 clé aléatoires"

debug "et A envoie à B la clé  CLE_B.Q  "+_n(CLE_B)
debug "         et à C la clé  CLE_C.q  "+_n(CLE_C)
debug "         et à D la clé  CLE_D.q  "+_n(CLE_D)
debug "A va avec ces 3 clés générer la clé  qui permettra de code le message ou le code"
debug  " CLE_K=(CLE_B ! CLE_C) ! CLE_D  ="+_n(CLE_K)
debug  " CLE_E.Q=M_A ! CLE_K  " +_n(CLE_E)
debug "A envoie  à E la clé  CLE_E.q  "+_n(CLE_E)+"  clé qui est le cryptage de M_A avec les autres clés"
; 
debug "" 
Debug "*** il suffit maintenant que B C D et E  soient d'accord devant un tiers pour prouver leur accord et  pour retrouver le code d'origine "
debug " CODE_ORIGINE.Q=(CLE_E ! CLE_B) ! CLE_C ! CLE_D "

CODE_ORIGINE.Q=(CLE_E ! CLE_B) ! CLE_C ! CLE_D


; 
; 
debug " *** On retrouve le code d'origine  "+_n(CODE_ORIGINE)+" Elémentaire mon cher Watson !!!! "
debug "                                                        Oui bien sûr mais quant est-il avec un code alpha-numérique ????"
debug _n(M_A)+_n(CODE_ORIGINE)

Mais en alphanumérique il faut que XORALPHA ait les mêmes caractéristiques que xor numérique.
Voyons le pb soulevé par le prg de Zorro
Imaginons que dans la première opération Mo  K2 il y a plusieurs collisions
le caractère $FF sera donc placé pour remplacer 0 mais le 2em crytage
(Mo  K2)  K3 va écraser avec une probabilité de 100% c'est-à-dire avec certitude le flag $FF qui ne pourra être retrouvé dans ce pb que dans 1 cas que nous allons voir.

Si l’on prend le même ordre de décryptage que celui qui a été utilisé pour crypter nous ne pourrons jamais retrouver le code ou le message d’origine.
Il faut pour retrouver l’original opérer le décryptage dans l’ordre inverse.
en effet si l’on enregistre à chaque opération le résultat du cryptage nous obtenons
K1=((((Mo  K2=R2)  K3=R3)  K4=R4)  K5 =R5)………………  Kn=K1
Pour obtenir les résultats inverses il faut décrypter de la façon suivante prenons le cas de 5 personnes.
((K1  K5 =R4)  K4 = R3 )  K3 = R2)  K2= Mo CQFD
Si vous n’observez pas cet ordre vous ne pourrez pas retrouvez le message d’origine
Or nous ignorons l’ordre des clés dans lequel A a crypté K1 d’ailleurs nous ne savons même pas quel est la clé K1 parmi le 5
Ce qui fait de ce prg une difficulté pratiquement insoluble si N est grand (Factoriel N essais)
Pour résoudre le 3em pb nous verrons que le prg de Zorro ne peut être utilisé.

programme de Zorro dans 2 cas de décodage avec 3 personnes donc 2 clés à créer ici toto et pierre.

Code : Tout sélectionner

;***********************************************
;Titre  :*codage XOR sans "collision " possible
;Auteur  : Zorro
;Date  :01/12/2017
;Heure  :13:52:02
;Version Purebasic :  PureBasic 5.60 (Windows - x86)
;Version de l'editeur :EPB V2.68
; Libairies necessaire : Aucune
;***********************************************
Declare.s encodage_xor(chaine.s,pass.s,mode)


;;;Pb avec 3 personnes
;; générer 2 clé TOTO et Pierre
Declare.s encodage_xor(chaine.s,pass.s,mode)

chaine.s="toto de la Lune"+chr(10)+"a la ligne"
K2.s="toto"
K3.s="pierre"

debug "la chaine en clair= "+chaine.s
debug "le password= "+K2.s
Debug ""
Debug ""

; on encode la chaine avec le mot de K2
R2.s=encodage_xor(chaine.s,K2.s,#true)
debug "le resultat encodé= "+R2.s
Debug ""
K1.s=Encodage_XOR(R2,K3,#true)

;;; A envoie K1 et K2 et K3 au 3 personnes

;;; décodage dans un ordre permettant de retrouver le message d'origine
;on decode la chaine crypté avec le mot de pass
;;; ***** décodage impossible mauvais ordre de decodage
R2b.s=encodage_xor(K2.s,K3.s,#False)
debug "le resultat décodé= "+R2b.s
R1b.s=encodage_xor(R2b.s,K1.s,#False)
debug "**** mauvais résultat ordre de décodage pas OK *****"
debug r1b

;;; Bon ordre de décodage résultat OK
R2b.s=encodage_xor(K1.s,K3.s,#False)
debug "le resultat décodé= "+R2b.s
R1b.s=encodage_xor(R2b.s,K2.s,#False)
debug "**** Bon résultat ordre de décodage OK *****"

debug r1b

Procedure.s Encodage_XOR(chaine.s,Pass.s,Mode)
      ; By Zorro
      ; ENCODAGE XOR 
      For i=1 to len(chaine.s)
            pos=pos+1
            if pos>Len(pass.s):Pos=1:Endif
            
            cclair=asc(mid(chaine.s,i,1))
            cpass=asc(mid(pass.s,pos,1))
            Select Mode                  
                  Case #true ; encodage XOR                  
                  cencode=cclair!(cpass)
                  If cencode=0 ; Cas ou le pass et le clair soit pareil , ou le le code soit plus petit que "l'espace"
                        cencode=255   ; recodage si pareil en fait on creer un Flag "255" signifiera qu'on utilisera le meme caractere que le pass donc on encode pas vraiment
                  Endif                  
                  encode.s=encode.s+chr(cencode)
                  Case #False ; decodage XOR
                  If cclair=255 ; si le code analysé et encodé est 255 alors cela signifie que
                        cdecod= cpass ;le caractere est le meme que le pass ....
                  Else
                        cdecod=cclair!(cpass)
                  Endif
                  decode.s=decode.s+chr(cdecod)
            Endselect
      Next i
      If Mode=#true
            ProcedureReturn encode.s
      Else
            ProcedureReturn decode.s
      Endif
      
EndProcedure

Ps : Il reste encore le 3em et 4 em pb à résoudre.

A+
Il est fort peu probable que les mêmes causes ne produisent pas les mêmes effets.(Einstein)
Et en logique positive cela donne.
Il est très fortement probable que les mêmes causes produisent les mêmes effets.
Avatar de l’utilisateur
Ar-S
Messages : 9472
Inscription : dim. 09/oct./2005 16:51
Contact :

Re: Quelques problèmes de cryptage à résoudre.

Message par Ar-S »

Je suis ce topic d'assez loin mais j'avoue ne pas avoir le temps et probablement pas le savoir faire de me plonger dedans.
~~~~Règles du forum ~~~~
⋅.˳˳.⋅ॱ˙˙ॱ⋅.˳Ar-S ˳.⋅ॱ˙˙ॱ⋅.˳˳.⋅
W11x64 PB 6.x
Section HORS SUJET : ICI
LDV MULTIMEDIA : Dépannage informatique & mes Logiciels PB
UPLOAD D'IMAGES : Uploader des images de vos logiciels
Répondre