voila bon jme presente... je sui etudiant en 2eme annee de MASS mais je fais aussi de la programmation JAVA, hier soir je sais pa ski mes passé par la tete  mais j'ai décidé de faire un peu de cryto   lol .
ok voila je vous mets le code source la mais je sens ke ca va etre un peu basique pr vous alors riez pas trop    
 
 
 
/*
 * Encript.java
 *
 * Created on 21 mars 2007, 22:56
 *
 * To change this template, choose Tools | Options and locate the template under
 * the Source Creation and Management node. Right-click the template and choose
 * Open. You can then make changes to the template in the Source Editor.
 */
 
package encrypt;
 
/**
 *
 * @author XXX
 */
public class Encrypt {
    static char[] alphabet;
    static char[] newAlphabet;
    static int[] newAlphabet2;
    /** Creates a new instance of Encript */
    public Encrypt(int i,char[] texte){
        create(i);
        int pos;
        for (int j = 0 ; j<texte.length;j++){
            pos=indexOf(texte[j],alphabet);
            texte[j]=newAlphabet[pos];
        }
    }
    public void decrypt(char[] texte){
        int pos;
        for(int i=0;i<texte.length;i++){
            pos=indexOf(texte[i],newAlphabet);
            texte[i]=alphabet[pos];
        }
}
    public int indexOf(char c,char[] t){
        for(int i = 0 ; i<t.length ; i++)
            if(t[i]==c)
                return i;
        return -1;
    }
    public void create(int k){
        //alphabet
        String liste = "abcdefghijklmnopqrstuvwxyz1234567890 -éABCDEFGHIJKLMNOPQRSTUVWXYZ&²~#'{}()[]|è`_ç^à@°$£¤^¨<>,?;./:!§ù%*µ";
        alphabet = new char[liste.length()];
        for(int i = 0 ; i<liste.length();i++)
            alphabet[i]=liste.charAt(i);
        //new alphabet
        newAlphabet = new char[liste.length()];
        for(int i = 0 ; i<newAlphabet.length;i++)
            newAlphabet[(i+k)%alphabet.length]=alphabet[i];
        //new alphabet2
        newAlphabet2 = new int[liste.length()];
        for(int i = 0 ; i<newAlphabet2.length;i++)
            newAlphabet2[i]=newAlphabet[i];
    }
    public static char[] toCharArray(String s){
        char[] c =new char[s.length()];
        for(int i = 0 ; i<s.length() ; i++){
            c[i]=s.charAt(i);
        }
        return c;
    }
    public static void main(String[] args) {
        int p=33;
        String s = "trop choutte on dirait un vrai code lol"+" "+p;
        char[] r=toCharArray(s);
        Encrypt e=new Encrypt(p,r);
        System.out.println(alphabet.length);
        /*for(int i = 0 ; i<alphabet.length;i++)
            System.out.print(alphabet[i]);
        System.out.println();
        for(int i = 0 ; i<alphabet.length;i++)
            System.out.print(newAlphabet[i]);
        System.out.println();
        for(int i = 0 ; i<alphabet.length;i++)
            System.out.print(newAlphabet2[i]+" " );
        */
        for(int i = 0 ; i<r.length;i++)
            System.out.print(r[i]);
        System.out.println();
        System.out.println("p="+p);
        e.decrypt(r);
        for(int i = 0 ; i<r.length;i++)
            System.out.print(r[i]);
    }
}
 
 
 
 
ce que j'ai fait est tres con... j'ai juste crée une liste avec tous les caracteres possibles, je l'ai "translaté" d'une valeur p que je choisis et qui sera ma clé et ensuite j'ai utilisé cette nouvelle liste "translatée" pour coder ma chaine de caracteres.
 
je voudrais savoir ce ke vs en pensez tt dabord et ensuite quelles sont d'après vous les modifications ou les amelioration a apporter    

personne pr m'aider? :-(

utilise les balises deja  
 
comme ca :  

he ben heuresement que les procédés de crypto ne sont pas aussi banales  !  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

bah c'est basique, mais c'est déjà pas mal
 
une autre solution que je m'étais amusé à faire, toute aussi banale, c'était encrypter avec mot de passe, en additionnant le code asci de chaque lettres du mot de passe une à une avec le texte... pas clair
 

 
=> j'ajoute 'a' à 't' => ça donne le premier caractère
=> j'ajoute 'z' à 'o' => ça me donne le second
=> et ainsi de suite. lorsque j'ai fini toutes les lettres du mot de passe, je reprend la séquence des lettres du mot de passe depuis 0
 
=> l'intérêt, c'est que ça prends un millième de secondes de plus à cracker
 
ensuite, un système classique consiste à reprendre une approche que je trouve similaire à celle de huffman (compression) mais en l'inversant, et, au contraire, en gonflant la taille du fichier :
 
par exemple, pour une encryption sur 128 bits
 
"bonjour"
 
=> je compte chaque caractère différent
b = 1
o = 2
n = 1
j = 1
u = 1
r = 1
 
Je prends réparti de façon homongène mes caractères sur l'ensemble des valeurs possible de 0 à 2^127
 
=> ensuite, je remplace aléatoirement les caractères de mon texte par des membres de chaque plage correspondant à chaque caractère
 
la clé c'est juste la liste des indices de tes caractères trouvés.
 
en l'améliorant un peu, ce système est déjà bien plus difficile à cracker, puisqu'un même caractère peut avoir un (très) grand nombre de représentations différentes possibles. et vu que le choix de ses représenations est en fonction du nombre d'occurences, ça te donne un fichier en résultat totalement homogène : impossible de détecter les caractères qui sont souvent présents dans le code.
 
avec ce système par exemple, on sait qu'un fichier HTML commence (normalement) toujours par "<!DOCTYPE " => on sait donc, avec ton système retrouver toutes les occurences de ces lettres en un clin d'oeil. en réfléchissant un peu, on trouve que c'est un bête offset et le tour est joué. avec mon premier système, "azerty" est plus cours que "<!DOCTYPE " donc à nouveau, l'algo est trouvé en un pouillème de secondes.
 
avec le second système par contre, c'est un "miracle" si j'arrive à retrouver d'autres occurences de mes valeurs de remplacement dans le fichier. à partir de là, ça va devenir bonbon ne serait-ce que pour savoir quel algo a été utilisé. quant au brute force... idem, ça commence à devenir chocolat... par contre, si t'as bien suivit, ça multiplie la taille du fichier par 4
en reprenant toujours le système d'huffman, on peut s'amuser à construire une table de huffman qui monte jusqu'à 128 bits, et répartir toujours de façon proprotionnelle les caractères dedans. là, très franchement, ça commence à devenir très complexe pour le craquer : on doit recréer une table de huffman, et tester un peu toutes les combinaisons de ranges possible. pour un fichier ANSI, no souci, grace au 8° bit de poids fort dans le fichier original, on se rends compte immédiatement des erreurs... mais pour un document binaire...
 
après, je me suis jamais posé la question d'aller plus loin. à la base, y'a des fonctions 3DES et autres dans tous les langages ou presque, donc autant ne pas réinventer la roue

Pour le fun, je me suis amusé à mettre en place le système, avec une encryption sur 32 bits, et sans utiliser l'arbre de huffman inversé (trop chiant à coder, même si ça doit rendre le code infiniment moins crackable).
 
Le code :
 

 
Comme tu vois, c'est pas très compliqué, et ne plus, ça marche.
Je viens d'essayer d'encrypter un exécutable puis le décrypter, il marche toujours
 
Et clairement, vu la tronche du truc encrypté, tu peux courrir pour le décrypter, même si, parceque mes valeurs de remplacement respectent l'ordre de mes bytes, ça reste "relativement aisément" crackable.
 
=> en effet, si les bits de poids fort sont faibles, alors que sais que la valeur du caractère original est proche de 0, et si elle est élevée, je sais qu'elle est proche de 255. Ensuite, un peu de brute force permet de retrouver petit à petit les valeurs des bounds.
 
Par exemple, dans un EXE sous Windows, on a toujours le message "This program can not run in MS DOS mode...". Il est toujours au même endroit. Ca aide bien déjà
 
=> A noter aussi que cet exemple est à titre d'exemple uniquement. Faire du ReadAllBytes sans vérifier avant que le fichier ne fait pas 100 Go c'est mal Dans l'absolu, on utilisera des buffers, et pourquoi pas des threads pour gérer en // la lecture sur le disque, l'écriture, et l'encryption.
 
J'oubliais : à noter aussi que mon exemple est buggé : il ne fait pas ce qu'il est cencé faire : utilise un range de 0 à filesize caractères au lieu de 0 à 2^32 - 1

Le même débugé (génération des caractères de remplacement sur l'ensemble UInt32.Min, UInt32.Max) :
 

L'intérêt de ce truc, c'est qu'on génère "à chaque fois" un fichier différent, pour une même clé. Idéal donc pour un échange réseau : même si on envoies plusieurs fois la même information, on oblige un éventuel intru à décortiquer l'info à chaque fois, ce qui rends la tâche d'autant plus hardue : il suffit de noyer l'information importante dans un spam de données redondantes.

je drapalise