Über Hash und Datenlänge Dateien bilden...

RobthaR

Die Idee ist so :
Der MD5 Hash einer Datei und die Länge der Datei in Bytes werden gespeichert
Wenn man die Datei wieder in lesbarem Format haben will werden alle Möglichkeiten durchgegangen und der Hashwert berechnet, bis die Hashsums übereinstimmen

Die Fragen :
- Dauert es zu lange Dateien zu "generieren" / Wie lange braucht die Hashberechnung
- Wann ist die Hashberechnung am Wirkungsvollsten/ Sichersten

Knuddlbaer

Wenn man die Datei wieder in lesbarem Format haben will werden alle Möglichkeiten durchgegangen und der Hashwert berechnet, bis die Hashsums übereinstimmen

Naja, ne Bruteforce von nem kleine Passwort kann schon Monate dauern. Wie lange soll denn da die Bruteforcevairante einer Datei dauern ? Ich glaube nicht, das Deine Anwender so lange warten möchten.

C++ Forumbot

Dieser Thread wurde von Moderator/in Jochen Kalmbach aus dem Forum C++/CLI mit .NET in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

rüdiger

Selbst wenn es schnell dauern würde, bis du N Daten erhälst, die dem Hash entsprechen, heißt das nicht das es sich um die Ausgangsdaten handelt.

Aus Hackfleisch ne Kuh zu machen ist kaum möglich.

RobthaR

Kannst aber Lauter Kühe machen und aus denen dann Hackfleisch bis ein Hackfleisch so aussieht wie das Hackfleisch das du haben willst

Der Hashcode ist doch "einzigartig" und die warscheinlichkeit, dass der Hash nicht der Richtige ist, ist sicherlich gering, wenn nicht dann kann man ja immer noch Kontrollieren
"Hash Gefunden -> Datei.txt -> User sagt, ist nicht die richtige -> Weiter gehts bis zum nächsten mal"

Außerdem ist Md5 ja dafür da, um Dateien eindeutig zu identifizieren

rüdiger

http://de.wikipedia.org/wiki/Kollisionsfreiheit

Bashar

RobthaR schrieb:

Der Hashcode ist doch "einzigartig"

Nein, das sagen einem schon einfachste informationstheoretische Überlegungen.

thordk

RobthaR schrieb:

Der Hashcode ist doch "einzigartig"

ist er eben nicht, die abbildung ist nicht bijektiv. einem beliebigen hashcode entsprechen unendlich viele ursprungsdaten. wenn es auf eine bestimmte länge dieser daten beschränkt ist, dann wird die menge zumindest endlich, aber noch lange nicht eindeutig.

aus nem hash die ursprungdaten zurückzugewinnen ist unmöglich.

RobthaR

Vielleicht verringert sich die Anzahl der Möglichkeiten, wenn man kleinere Teile einer Datei nimmt, auf ein handhabbares Max.

Es würde sich ja bei großen dateien rentieren 17 Byte durch einen 16 Byte Hash Code zu ersetzen, da sich ja alles hochrechnet, aber 17 ist keine schöne Zahl^^

Bashar

Dann gäbe es immer noch je Hash 256 verschiedene Dateien, die diesen Hashwert haben.

RobthaR

Das versteh ich jetzt net

Michael E.

Dein Hash kann (216 = 2^128 verschiedene Werte annehmen. Die 17 Originalbyte können (217 = 2^136 verschiedene Werte annehmen. Nun willst du diese 2^136 Möglichkeiten auf nur 2^128 Möglichkeiten abbilden, d. h. du musst 2^136 / 2^128 = 2^8 = 256 verschiedene Möglichkeiten auf einer einzigen abbilden 256-fache Mehrdeutigkeit.

RobthaR

Zum austesten, wie viele Hashs mit einem Hash übereinstimmen, hab ich ein Programm geschreiben

delegate void GotHash(array<Byte>^);
delegate void LoopNum(Byte,Byte,Byte,Byte,Byte,Byte,Byte,Byte,Byte,Byte,Byte,Byte,Byte,Byte,Byte,Byte,Byte,__int64);

void Hashing17Ex16(array<Byte>^	in,GotHash^	gh,LoopNum^	l){
	MD5 ^ Md = MD5::Create();
	array<Byte> ^ b;
	__int64	agi = 0;

	for(Byte a0	= 0; a0 < 256 ; )	{
	for(Byte a1	= 0; a1 < 256 ; )	{
	for(Byte a2	= 0; a2 < 256 ; )	{
	for(Byte a3	= 0; a3 < 256 ; )	{
	for(Byte a4	= 0; a4 < 256 ; )	{
	for(Byte a5	= 0; a5 < 256 ; )	{
	for(Byte a6	= 0; a6 < 256 ; )	{
	for(Byte a7	= 0; a7 < 256 ; )	{
	for(Byte a8	= 0; a8 < 256 ; )	{
	for(Byte a9	= 0; a9 < 256 ; )	{
	for(Byte a10= 0; a10< 256 ; )	{
	for(Byte a11= 0; a11< 256 ; )	{
	for(Byte a12= 0; a12< 256 ; )	{
	for(Byte a13= 0; a13< 256 ; )	{
	for(Byte a14= 0; a14< 256 ; )	{
	for(Byte a15= 0; a15< 256 ; )	{
	for(Byte a16= 0; a16< 256 ; )	{
		agi = agi + 1;
		l(a0,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10,a11,a12,a13,a14,a15,a16,agi);
		b = Md->ComputeHash(gcnew array<Byte>{a0,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10,a11,a12,a13,a14,a15,a16});
		if(BACompare(b,in))gh(gcnew array<Byte>{a0,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10,a11,a12,a13,a14,a15,a16});
	a16+=1;}
	a15+=1;}
	a14+=1;}
	a13+=1;}
	a12+=1;}
	a11+=1;}
	a10+=1;}
	a9+=1;}
	a8+=1;}
	a7+=1;}
	a6+=1;}
	a5+=1;}
	a4+=1;}
	a3+=1;}
	a2+=1;}
	a1+=1;}
	a0+=1;}
}

Aber irgendwas stimmt mit den for loops nicht...
Siehe http://lhtech.lh.funpic.de/downloads/hasharraygeterror.gif
Die größeren A's bleiben 0 und das andere ist bei 400irgendwas ( bei einem Byte!!! )

hustbaer

@RobthaR: Wen willst du hier eigentlich verarschen?
1-2-viele oder wie, hm?

RobthaR

hustbaer schrieb:

@RobthaR: Wen willst du hier eigentlich verarschen?
1-2-viele oder wie, hm?

Spast!! Wenn du nur rumflamen willst, geh wo anders hin :p

TomasRiker

Tipp:
Deine for-Schleifen sind Endlosschleifen.
Die Laufvariable ist immer < 256, da Bytes nur max. den Wert 255 annehmen können. Danach gibt's einen Überlauf, und es fängt wieder bei 0 an.

Aber das bringt doch eh nix.
Denk lieber mal in Ruhe drüber nach, dann kannst du dir das Programm sparen.

RobthaR

Das Problem ist, das ich nur weiss was Hashes bringen, aber nicht genau und sonst hab ich auch keine Ahnung.

Aber ich wollte mal austesten, ob das geht, wie das halt mit so Ideeen ist
Ich müsste also ans Ende aller Schleifen

if(aIrgendwas==255)break;

machen

RobthaR

Hat aber keinen sinn, es dauert viel zu lange, jedenfalls wie ichs mache, vllt probier ichs später nochma, war trotzdem sehr lehrreich

Ausser hustebaer, der war einfach nur am unproduktiv rumflamen

Gerard

ich hatte mal vor einer weile so eine idee

man nähme 4 bytes hashe sie,
dann probiert man per bruteforce aus wie viele koliesionen man überspringen muss um zu orginal wert zu kommen
abspeichern tut man dann den hash und die anzahl der kolisionen

das problem dabei ist wenn der hash 1 byte groß ist, gibt es 0xFFF mögliche kolisonen d.h. man spart damit kein speicher platz ein

die idee ist "verlustbehafte text komprimierung", man speicher nur den hash und der algo am ende findet von alleine heraus welcher text es sein sollte, anhand rechtschreibung und gramatik, wenn dabei was schief wirds unterm tisch fallen gelassen

der komprimierer kann aber auch schon mal ein dekomprimieren durchspielen und dann extra informationen einbauen wo er merkt das es beim dekomprimieren unsicherheiten geben wird

thordk

ich behaupte mal ganz dreist, dass jedes andere "echte" kompressionsverfahren besser sein wird