HashMask 512 -Terminé les problème de clé

Le mardi 31 juillet 2012 00:09:06 UTC+2, (inconnu) a écrit :

Le lundi 30 juillet 2012 19:03:37 UTC+2, Philippe Lheureux a écrit :

> <la seul chose que je dit est _démontre_ bicause les collisions

>

> <et exhibe voir fichier de mesure s'est que ton masque n'est pas

>

> <aléatoire

>

>

>

> Une collision n'aurait aucun effet sur la sécurité de HMK-512 , car même si

>

> tu retrouves le même Hash avec une autre clé ... le hash suivant ne sera pas

>

> bon car il te manque la vrai clé.

>

>

>

> <entre une formule du style

>

>

>

> <http://fr.wikipedia.org/wiki/Blum_Blum_Shub

>

>

>

> <et ton machin de qualité douteuse il faut être complètement a la ramasse

>

> <pour choisir ton option

>

>

>

> <et je ne parle même pas des temps d’exécution

>

>

>

> En C et compilé ça va beaucoup plus vite qu'en PHP !

>

>

>

> <maintenant je sais tu ne vas pas être d'accord

>

> <mais cela ne changeras rien

>

>

>

> <fin du débats pour moi

>

>

>

> <remy



http://cjoint.com/?BGFadp1vRfT



Voila un exemple entest sur un masque de 1Mo généré en C# : donc do nnées binaires (disons plutôt "brutes") en entrée et sortie.



Je crois qu'on est plutôt pas mal : y a tout, dans des proportions pas mal non plus.



Après, niveau rapidité ... y a encore du taf. Mais ca va le faire :)

Ha, et pour préciser : il y a effectivement des tests de compression qui ont été réalisés, qui si je ne me trompe pas se base entre autres s ur l'entropie et sur la répétition des données.

Verdict : en compressant via 7zip / zip / rar, on prends PLUS de place, hea ders de compression oblige.

Sinon, en se basant sur un chunk à 4Ko avec de l'aléatoire, ça roule plutôt bien. Et effectivement, même en cas de collision, très peu de risques : ok, tu as une collision sur un masque, il te faudra de toute fa çon la clé originale ou une collision de cette clé pour régén' le hash de base. Qui lui reste inconnu, sauf erreur, ou sauf arriver à remo nter à travers une centaine de rounds SHA512.

Peu crédible, sauf puissance machine monumentale.

Eeeeeet pour compléter un poil la réponse précédente, en se basant sur un chunk de 4Ko, on ne prends pas trop de place en plus : un cluster es t en général de 4Ko, et l'on se sert des zones caves pour y stocker des données internes au fonctionnement.

Bref, selon taille de fichier :
1 octet = prends un cluster = prends 4 Ko (4096o). Taille crypté: 409 6o. Pile. Va deviner la taille du fichier de base.
4040 octets = 1 cluster => zone cave utilisée car assez grande, donc en sortie : 4 Ko.
4090 octets = prends un cluster = prends 4Ko / 4096o. Zone cave trop pe tite, 1 chunk ajouté => taille sur le disque : 8Ko. En cryptanalysant, tu as donc une taille de fichier potentielle en [4080-8100]o (à la louche ).

Les résultats pour chaque octet à 0 étant différent, dur de deviner la fin des datas, et donc le début du padding.

Sur le papier, ça sonne bien. A voir si c'est résistant.

Après, loin de moi l'ambition d'en faire un chiffrement utilisé par le DOD ...

ttp://cjoint.com/?BGFadp1vRfT

Voila un exemple entest sur un masque de 1Mo généré en C# : donc données
binaires (disons plutôt "brutes") en entrée et sortie.

Je crois qu'on est plutôt pas mal : y a tout, dans des proportions pas mal
non plus.

Après, niveau rapidité ... y a encore du taf. Mais ca va le faire :)


LP> faudrait peut être essayer sur un masque de 20 méga et comparer les
résultats avec ceux de 1 méga pour voir s'il y a un changement significatif
quelque part !

Le 31/07/2012 10:43, Philippe Lheureux a écrit :

ttp://cjoint.com/?BGFadp1vRfT

Voila un exemple entest sur un masque de 1Mo généré en C# : donc données
binaires (disons plutôt "brutes") en entrée et sortie.

Je crois qu'on est plutôt pas mal : y a tout, dans des proportions pa s
mal non plus.

Après, niveau rapidité ... y a encore du taf. Mais ca va le faire : )


LP> faudrait peut être essayer sur un masque de 20 méga et comparer les
résultats avec ceux de 1 méga pour voir s'il y a un changement
significatif quelque part !

remy@remy:~$ cd ./Bureau/
remy@remy:~/Bureau$ javac SHA512.java
remy@remy:~/Bureau$ time java SHA512 10000 ./clef

real 7m12.573s
user 6m59.694s
sys 0m13.405s
remy@remy:~/Bureau$ ls -la clef
-rw-rw-r-- 1 remy remy 1280025 juil. 31 10:51 clef
remy@remy:~/Bureau$


donc quantité de boucle + non du fichier

algo principale

while (i!=max)
{
i++;
sumSHA512=sha512(monFichier);
ecritureFichier(monFichier,sumSHA512);
}

le code source

http://cjoint.com/12ju/BGFlieJIMEF.htm

compilation
javac SHA512.java
exécution du prg
java SHA512 10000 ./clef

http://cjoint.com/12ju/BGFlkGNBi2A.htm
et cela merde toujours

http://cjoint.com/12ju/BGFllyFUkuY.htm

remy





--
http://remyaumeunier.chez-alice.fr/

pour archivage parce que je ne vais pas garde le code


import java.io.FileInputStream;
import java.security.MessageDigest;
import java.io.*;

public class SHA512
{
public static void main(String[] args)throws Exception
{
String monFichier=args[1];
String sumSHA512=null;
int i=0;
int max= Integer.parseInt(args[0]);
while (i!=max)
{
i++;
sumSHA512=sha512(monFichier);
ecritureFichier(monFichier,sumSHA512);
}

}
public static String sha512(String file)throws Exception
{
MessageDigest md = MessageDigest.getInstance("SHA-512");
FileInputStream fis = new FileInputStream(file);

byte[] dataBytes = new byte[1024];
int nread = 0;
while ((nread = fis.read(dataBytes)) != -1) {
md.update(dataBytes, 0, nread);
};
byte[] mdbytes = md.digest();


StringBuffer sb = new StringBuffer();
for (int i = 0; i < mdbytes.length; i++) {
sb.append(Integer.toString((mdbytes[i] & 0xff) +
0x100,16).substring(1));
}
return sb.toString();
}

public static void ecritureFichier(String file,String texte)throws
Exception
{
FileWriter writer = null;
try{
writer = new FileWriter(file, true);
writer.write(texte,0,texte.length());
writer.close();
}catch(IOException ex){
ex.printStackTrace();
}
}
}


remy

Le 31/07/2012 11:16, remy a écrit :

pour archivage parce que je ne vais pas garde le code


import java.io.FileInputStream;
import java.security.MessageDigest;
import java.io.*;

public class SHA512
{
public static void main(String[] args)throws Exception
{
String monFichier=args[1];
String sumSHA512=null;
int i=0;
int max= Integer.parseInt(args[0]);
while (i!=max)
{
i++;
sumSHA512=sha512(monFichier);
ecritureFichier(monFichier,sumSHA512);
}

}
public static String sha512(String file)throws Exception
{
MessageDigest md = MessageDigest.getInstance("SHA-512");
FileInputStream fis = new FileInputStream(file);

byte[] dataBytes = new byte[1024];
int nread = 0;
while ((nread = fis.read(dataBytes)) != -1) {
md.update(dataBytes, 0, nread);
};
byte[] mdbytes = md.digest();

fis.close(); //oops

StringBuffer sb = new StringBuffer();
for (int i = 0; i < mdbytes.length; i++) {
sb.append(Integer.toString((mdbytes[i] & 0xff) +
0x100,16).substring(1));
}
return sb.toString();
}

public static void ecritureFichier(String file,String texte)throws
Exception
{
FileWriter writer = null;
try{
writer = new FileWriter(file, true);
writer.write(texte,0,texte.length());
writer.close();
}catch(IOException ex){
ex.printStackTrace();
}
}
}


remy

--
http://remyaumeunier.chez-alice.fr/

A mon avis Remy , tu serais plus utile en réalisant une version JAVA
complète et opérationnelle de HMK-512. Au moins comme ça , on aurait tout
loisir pour la tester et l'utiliser.

Le 31/07/2012 12:21, Philippe Lheureux a écrit :

A mon avis Remy , tu serais plus utile en réalisant une version JAVA
complète et opérationnelle de HMK-512. Au moins comme ça , on aur ait
tout loisir pour la tester et l'utiliser.

inutile d'aller plus loin ton masque n'est pas aléatoire


remy

--
http://remyaumeunier.chez-alice.fr/

Il s'agit bien ici d'un masque pseudo-aléatoire étant donné qu'il est basé sur un vecteur d'initialisation propre à chaque masque, soit prop re à chaque chiffrement (même d'un même fichier).

Maintenant, obtenir les collisions nécessaires pour remonter jusqu'au fam eux vecteur d'initialisation va s'avérer difficile même avec les capaci tés actuelles des machines... cependant on ne sait pas de quoi demain ser a fait, il est tout à fait possible que SHA-512 soit "cassable" plus ou m oins rapidement, en attendant il semble qu'aujourd'hui tenter une brute for ce sur la clé soit plus envisageable que d'espérer provoquer une collis ion sur le nombre de hashes nécessaires...

A moins que ? ?

Le 31/07/2012 15:17, dimitri.mestdagh.dm@gmail.com a écrit :

Il s'agit bien ici d'un masque pseudo-aléatoire étant donné qu'il est basé sur un vecteur d'initialisation propre à chaque masque, soi t propre à chaque chiffrement (même d'un même fichier).

Maintenant, obtenir les collisions nécessaires pour remonter jusqu'au fameux vecteur d'initialisation va s'avérer difficile même avec les capacités actuelles des machines... cependant on ne sait pas de quoi de main sera fait, il est tout à fait possible que SHA-512 soit "cassable" plus ou moins rapidement, en attendant il semble qu'aujourd'hui tenter u ne brute force sur la clé soit plus envisageable que d'espérer provoq uer une collision sur le nombre de hashes nécessaires...

A moins que ? ?

Le problème ne se pause pas ne s'est thermes
mais plutôt pourquoi choisir cette solution sachant
que cette méthode et incorrecte voir imparfaite
tout en étant parfaitement conscient qu'il existe d'autre solution ou
générateur de masque nettement plus robuste et plus rapide

remy





--
http://remyaumeunier.chez-alice.fr/