Bringt Multiprozessorfähiger Code etwas bei excessivem Festplattenzugriff?

.filmor

Dann lad dir die Datei halt in den Speicher (oder lad dir handliche Stücke). Wie ~fricky schon sagte, du brauchst doch bestimmt nicht die ganze Zeit wahlfreien Zugriff auf die gesamte Datei (was aber bei entsprechender Größe auch irrelevant wäre) …

hustbaer

MPCPU schrieb:

Ich sag es mal so, er muß via Bruteforce eine Datei entschlüsseln und
auf die Kerne kann ich also nur das Schlüssel erzeugen auslagern,
die Datei entschlüsseln macht IMO nur auf einen Kern Sinn, wegen der Festplatte die auf die DAtei zugreift.

Eine Datei Brute-Force entschlüsseln indem du für jeden Schlüssel-Kandidaten versuchst die ganze Datei zu entschlüsseln. Die so gross ist dass sie nichtmal ganz in den Speicher passt. OMG, denk mal drüber nach

hustbaer schrieb:

MPCPU schrieb:

Ich sag es mal so, er muß via Bruteforce eine Datei entschlüsseln und
auf die Kerne kann ich also nur das Schlüssel erzeugen auslagern,
die Datei entschlüsseln macht IMO nur auf einen Kern Sinn, wegen der Festplatte die auf die DAtei zugreift.

Eine Datei Brute-Force entschlüsseln indem du für jeden Schlüssel-Kandidaten versuchst die ganze Datei zu entschlüsseln. Die so gross ist dass sie nichtmal ganz in den Speicher passt. OMG, denk mal drüber nach

Hab ich.
Glücklicherweise ist die Anzahl der möglichen Schlüssel stark eingeschränkt.

Ben04

Wenn deine Berechnungen langsamer sind als die Plattenzugriffe, dann könnte es etwas bringen.

:xmas2: nimm einen profiler und schau was zeit braucht immer das gleiche :xmas2:

Du könntest die Datei auf mehrere Platten aufteilen und auch teile in den RAM laden und dann alles auf der GPU berechnen. Bringts! Bin auch gerade dabei sowas zu machen!

rapso

versuche die daten mit mehreren schluesseln zu entschluesseln.

fopen(..)
for(blockcount)
{
data=readblock();
DecodeKey(Key0,data);
DecodeKey(Key1,data);
DecodeKey(Key2,data);
DecodeKey(Key3,data);
...
}

wenn du es weiter optimieren willst, mach einen thread der die daten fuer den naechsten schleifendurchlauf liest, waehrend du die anderen kerne schon fuer diesen datenblock entschluesseln laesst. da daten oft per dma gelesen werden, lohnt es sich selbst bei einem single-core system noch 2threads laufen zu lassen.

rapso schrieb:

wenn du es weiter optimieren willst, mach einen thread der die daten fuer den naechsten schleifendurchlauf liest, waehrend du die anderen kerne schon fuer diesen datenblock entschluesseln laesst. da daten oft per dma gelesen werden, lohnt es sich selbst bei einem single-core system noch 2threads laufen zu lassen.

Dazu müßte ich wissen, wie so ein Truecrypt Volume aufgebaut ist
und wie man es genau entschlüsselt.

D.h. momentan ist das so gelöst, das mein Code den Volumenamen und das Passwort über einen Systemaufruf an Truecrypt gibt.

Also in etwa so:
system("truecrypt ....");

MPCPU schrieb:

hustbaer schrieb:

MPCPU schrieb:

Ich sag es mal so, er muß via Bruteforce eine Datei entschlüsseln und
auf die Kerne kann ich also nur das Schlüssel erzeugen auslagern,
die Datei entschlüsseln macht IMO nur auf einen Kern Sinn, wegen der Festplatte die auf die DAtei zugreift.

Eine Datei Brute-Force entschlüsseln indem du für jeden Schlüssel-Kandidaten versuchst die ganze Datei zu entschlüsseln. Die so gross ist dass sie nichtmal ganz in den Speicher passt. OMG, denk mal drüber nach

Hab ich.
Glücklicherweise ist die Anzahl der möglichen Schlüssel stark eingeschränkt.

So, mein Bruteforce Passwortherausfind Programm ist jetzt seit Mittwoch fertig und ich konnte meine beiden Truecrypt Volumes, bei denen ich das Passwort vergessen hatte, wieder öffnen.

Der Rechner hat jeweils ca. 6000-8000 Versuche gebraucht, dann hatte er das Passwort.

Truecrypt ist dadurch natürlich nicht unsicher geworden, sondern mein Bruteforce Programm war sehr spezifisch was die möglichen Schlüssel betrifft.

Ohne Kenntnis wie die Passwörter erstellt wurden, würde man die Passwörter übrigens als sehr sicher einstufen. Denn es sind Sonderzeichen, Gruß- und Kleinbuchstaben als auch Zahlen enthalten.
Außerdem war die Schlüssellänge ca. 16-34 Zeichen lang.

Auf jedenfall hat sich die Mühe gelohnt, ich komme endlich wieder an meine Daten.