Reprise du message précédent :
Je pose un drapal et j'ai une question. J'ai un vague souvenir que des scientifiques bossaient sur un cryptage basé sur la "théorie du chaos" et/où les figures fractales. Vous en avez entendu parler?

 
Ouais bah je me comprend j'ai réussi a avoir du clair a partir d'un truc en MD5
 
Edit : Et la fonction crypt() de PHP avec une clef de cryptage de 32 caractères (chiffres & lettres) c'est décryptable ?

 
oué par contre g pas suivi l'evolution du neant  

Tu ne sauras pas quand tu auras le bon code sans connaitre le message.
Si la clé était + courte que le message, tu pourrais avoir des chances d'avoir le bon code en obtenant un message cohérent. Là non, tu as une infinité de possibilités donc tu pourras trouver une infinité de messages cohérents sans savoir lequel est le bon. exactement comme si tu n'avais pas le message crypté, il ne te sert à rien.

Je réexplique :
- on a un fichier vidéo de 100 Mo (bon ok j'ai diminué d'un facteur 10 )
- on créé un algo de hash qui donne une chaine sur 1 Mo
- On récupère le hash de 1 Mo, un bout des bits du vrai fichier (genre le 1er Mo), et un "rang" dans l'ordre de dé-hashage.
- Après avec un logiciel, on procède à l'opération inverse du hashage : on génère tous les fichiers de 100 Mo d'après le hash (je crois que c'est mathématiquement faisable si on connait l'algo).
- On peut limiter le nombre de résultat parce que on connait la taille d'origine de la vidéo, ses premiers bits et on sait que c'est un mpg (donc certaines contraintes du code comme ça été dit)
Ou sinon carrément plus simple :
-- On a donné un "rang" dans avec le hash du fichier... le logiciel qui est chargé de dé-hasher utilise l'algo inverse en utilisant directement le n° donné dans le rang.
 
Ex vous avez un password qui est "z", si on peut donner un n° à chaque combinaison de pass, ce pass recoit la combinaison 26 (étant donné qu'il fait toutes les combinaisons das l'ordre, en allant de "a" vers "zzzz..." ), et ben là on file directement le n°26 et le logiciel teste la combinaison qui corespond au 26, nan ?

nerdz powered

t'attends quoi ? que l'on aprouve ta theorie ? c pas le mode de fonctionnament du 7zip ca

Pour ceux qui en ont parlé dans le topic, le cryptage quantique arrive, et il semblerait inviolable (en tout cas avec nos connaissances actuelles). C'est un système qui ne s'applique qu'à la sécurité des connexion, pas au cryptage des fichiers.
 
En fait, on crypte la communication à l'aide de l'état quantique d'un photon. Chaque photon possède un état quantique mésuré sur deux variables, complètement imprévisibles et non reproductible (entendez par là que on ne peut créer un photon en définissant ses deux variables en même temps). A partir de là, sachant que le simple fait de regarder un photon modifie son état quantique, on peut savoir de manière infaillible si la connexion a été écoutée ou non : le photon n'aura plus le même état quantique.
 
C'est très flou dans ma tête, mais il me semble que les grandes lignes y sont. Si quelqu'un a plus de précisions, qu'il m'explique, ça m'interesse. En espérant ne pas avoir raconté n'importe quoi, mais en tout cas c'est que j'avais compris de cette technique de sécurisation des transactions réseaux.

drapeau

Si j'ai bien compris ça permet de savoir si la connexion a été écoutée.  
Donc ça viendrait en complément du système de Vernam pour transmettre la clé avant de l'utiliser?

à mon avis, il ne doit pas y avoir que cette vérification d'écoute, sinon, on parlerait pas de "cryptage"...

Bah si ça permet d'utiliser vernam comme cryptage c'est déjà pas mal. Sinon la vérification d'écoute, j'en vois pas trop l'intérêt sur autrechose qu'une clé. Si les données sensibles ont été écoutées c'est trop tard. Alors qu'une clé pas encore utilisée, ça permet d'en changer avant de l'utiliser.

oui, non d accord, mais c pas un cryptage basé sur les propriétés quantiques plutôt que sur des mathématiques plus classiques

 
Tu n'a toujours pas compris le principe du truc on dirait
Mais avec un peu de patience ça finira bien par arriver
 

 
 
Maintenant, tu peux essayer toutes les clés que tu veux par force brute si ça te chante, et effectivement tu finira bien au bout d'un certain temps par retrouver le message original; mais puisqu'il y a équiprobabilité des messages décryptés (puisque la clé est aléatoire) il sera enfoui parmi des milliards d'autres messages du genre :
 

 
et apres tu les teste un par un
 
je vois pas ou est le prob, il faudra juste qq's descendance pour y arriver

 
Vu qu'il y en a une infinité, ta chance que ça soit le bon est de 1/x avec x==> infini, proche de 0 donc.
 
Donc oui tu peux trouver le bon code, mais que si tu peux le tester et éliminer au fur et à mesure les solutions. Ce qui n'est pas toujours le cas. Il n'y a pas que les mots de passe dans la vie.
 
Et rien ne te dis que tu trouveras le code un jour
 
 

 
Il ne faut pas perdre de vue que le but du chiffrement est de conserver les données chiffrées suffisament longtemps pour qu'elles soient périmées lorsque l'on arrivera à les déchiffrer  
 
Si ton message "NousAttaquonsParLaGrèce" tu ne l'as que 100 ans plus tard, c'est p-e trop tard

 
le principal c de trouver le code avant implosion du noyau de la terre

Mais arrêter avec vos infinités    
C'est completement limité vu que le message et la clef ont exactement la meme taille et sont limités    
 
Apres oui on dit une infinité quand on depasse un certain seuil, mais la limite etant contenu dans la taille du message, on ne peut pas dire a l'avance si il y aura une infinité de combinaisons    
 
Exemple simple. Mon message crypté fait 5 lettres (c'est un mot), en héxadécimal : 65 01 72 40 D1
Impossible de le décrypter sans connaitre la clef me dirait vous. C'est tout a fait vrai, mais on peut deja eliminé un grand nombre de possibilités vu qu'on sait que c'est un mot donc a-z/A-Z...enfin bref c'est pas ce que je voulais démontrer    
L'important c'est qu'il n'y a pas une infinité de combinaisons possibles mais exactement 2^40 soit 1 099 511 627 776 clefs possibles pour décrypter ce texte, on est donc tres loin de l'infinité    
Dans ce cas c'est plus sécuriser d'utiliser un systeme de chiffrement classique, la clef aura une taille bien supérieur au message (un Blowfish avec une clef de 128 bits suffira) et on ne pourra toujours pas dire par "cohérence" si le contenu décrypter en générant une clef par "bruteforce", est probable ou non. Cela revient exactement au meme tous en augmentant les possibilités des clefs, ce qui garantie une sécurité accrue (mais qui ne sert pas a grand chose vu que de toute facon on ne peut pas retrouver le message original si on ne connait pas la clef)  
 
NB : La clef "random" est 2A 56 3C 05 95  

Raaaah je t'ai pris pour Marc
 
Je me suis dit : tiens, c'est pas son genre habituel de messages ça

 
je suis plus d'accord avec lui quand mm  
 
l'infinité n'existe pas  
 
il y a obligatoirement une fin.....si il y a un debut

athlon soldier > je suis pas d'accord
 
ton mot d'origine est codé sur 8bits par lettre, la ok . Prenons l'exemple de la premiere lettre soit 65 .
tu dois générer un X et un Y pour arriver a X+Y=65.
et la je suis désolé, mais tu as bien une infinité de combinaisons pour arriver a 65
 
le fait que le message d'origine est a 8bits/ caractère ne veut pas dire que le message codé sera sur 8bits/caractere

 
ok, prenons l'ensemble des entiers naturels positifs.
Le début est 0. Donne moi le dernier nombre de l'ensemble.

infini
 
et l'infini ..... c bien une fin en soit  

 
C'est bête mais y'a un truc qui m'échappe là ... Ca voudrait dire que d'ici 11 jours, on sera tous morts

 
aleph0    
lol

http://solutions.journaldunet.com/ [...] ique.shtml

 
Mélanger les maths avec l'informatique ce n'est pas toujours tres bon    
 
X & Y se sont des valeurs infinis (et il y a effectivement une infinité de possibilité pour X & Y qui vérifie l'équation X + Y = 65), mais en informatique, dans ce cas, la limite c'est bien 8 bits, soit 2^8...
De plus ce n'est ABSOLUMENT pas une addition qu'il faut effectuer (c'est bien un truc de matheux ca   ) vu que si tu effectues ca, a un moment donné tu auras un overflow dans le registre et une perte d'information (il va tronqué pour rester sur 8 bits).
L'information sera donc erroné et on ne pourra plus obtenir le message d'origine par soustraction...
Les vrais opérateurs sont XOR (OU Exclusif) et AND (ET).
 
Bref la limite EXISTE et est REEL, arretez avec vos infinis, les maths c'est abstrait  
 
EDIT : La vrai formule mathématique serait plutot :
(M & 255) xor (K & 255) = C
Où M = Message en clair ; K = Clef ; C = Message Crypté

 
tu passes un coup de codage entropique avant le cryptage proprement dit, et je te garantis que le pb est vite réglé  

 
tout ton argumentaire se base sur ce qui est en gras.
Pourquoi la limite serait donc 8 bits ? Je ne suis pas d'accord sur ce fait. Je suis informaticien moi, pas mathématicien, j'ai déja construit un processeur (bon ok, un petit) avec des cellules NAND, je sais comment ca marche. Et je persiste : ton cpu va peut etre découper et faire ses opérations sur des groupes de 8/16/32/64 bits, il en reste pas moins que le résultat final est valide meme s'il est codé sur 256 bits

Peu importe ca ne change pas mon raisonnement vu que ce passage n'etait pas ce que je voulais démontrer  

   
Dans ce cas on obtient un message crypté supérieur en taille à la clef ET au message en clair. MAIS comment tu reobtiens le message en clair dans ce cas ? Tu n'as plus de bloc "marqueur" de 8 bits qui t'indique que tu passes a l'octet suivant.
 
Exemple simple :
Message Clair : 4E 41 57 41 4B
Clef : E3 4F F1 C8 58  
 
Ce qui donne (résultat en little endian)
E3 + 4E = 31 01
41 + 4F = 90
57 + F1 = 48 01
41 + C8 = 09 01
4B + 58 = A3
 
Donc Message Crypté : 31 01 90 48 01 09 01 A3
Et si tu reprends la clef (E3 4F F1 C8 58) tu le décryptes comment le message maintenant ?  

et ou est le probleme a avoir un message crypté plus gros
c'est un probleme de codage ca, il suffit au lieu de coder ton nombre représentable au minimum sur 8 bits de le coder sur 1024 bits avec des 0 partout devant  

Ouais mais la mémoire est pas infini hein  

Question peut-êtreindiscrête ou hors charte :    
 
Vous vous souvenez tous des vieux décodeurs canal+ (avec le systeme de nagravision)...
Comment fonctionne ce systeme de cryptage ? il faut remmettre les ligne à leur place ???
Comment as-t-il été dévérouillé ? il a fallut connaitre l'algorithme ?

De toute façon il est interdit d'utiliser des clefs > 128 bits  

Surement qqun de Canal + qui a vendu les algos de cryptages de base, et tous les mois la clef de cryptage était modifié, il restait plus qu'à trouver la nouvelle

 
Non, faut lire le topic
 
Il faut utiliser un logiciel approuvé, mais ce n'est pas interdit.

Il faut surtout que l'état puisse le decrypter

Non.