|
Schneller Code - Von Delete und Insert -> Copy -> ???
Ich gebe gerade alles um meinen Quellcode so effektiv wie möglich zu machen. Kurz zum Thema, mein Programm führt ein paar Millionen Prozesse aus, was genau tut nix zur Sache.
Vor einiger Zeit bin ich schon dahinter gestiegen, dass Delete und Insert ein großes Problem darstellen. Bei mehreren Tausend aufrufen ist schon spürbar eine lange Zeitdauer erkennbar. Diesbezüglich habe ich Insert und Delete schon entfert und durch andere Prozeduren ersetzt. Durch die Funktion Copy war dies schon eine einfache Lösung, es geht nun um ein x faches schneller, aus mehreren Tagen Arbeitszeit wurden wenige Minuten - lol - Nun wäre es aber optimal, wenn wir Copy auch noch durch etwas anderes in irgendeiner weise ersetzen können. Denn Copy dauert mir auch viel zu lange um es auf den Punkt zu bringen. Aber ich weiß auch, dass man nicht alles im Leben haben kann :zwinker:
Delphi-Quellcode:
-->> Dies dauert knapp 3 Sekunden
procedure TForm1.Button2Click(Sender: TObject);
var text1,text2: string; i: integer; begin ShowMessage('Messung starten'); for i := 1 to 50 do begin text1 := FileToString('abc.xyz'); // datei hat nix zu sagen, dient als temp. Datenquelle text2 := copy(text1,20000,500000) + copy(text1,1,19999) + copy(text1,500001,length(text1)); end; ShowMessage('Fertig'); end; Ein Versuch Copy effektiver zu machen scheiterte jedoch :oops:
Delphi-Quellcode:
Dies dauert nun ca. 62 Minuten, damit habe ich also das Gegenteil erreicht von dem, was ich erreichen wollte.
procedure TForm1.Button3Click(Sender: TObject);
var text1,text2: string; i,j: integer; begin ShowMessage('Messung starten'); for i := 1 to 50 do begin text2 := ''; text1 := FileToString('abc.xyz'); // große Datei als temp. Datenquelle for j := 20000 to 500000 do text2 := text2 + text1[j]; for j := 1 to 19999 do text2 := text2 + text1[j]; for j := 500001 to length(text1) do text2 := text2 + text1[j]; end; ShowMessage('Fertig'); end; Würde man dies oben, statt mit Copy, durch Delete und Insert versuchen zu erreichen, dann würde der ganze Prozess halt auch keine 3 Sekunden mehr dauern, sondern um einiges Länger. Wer mir nicht glaubt, einfach ausprobieren, hab hierfür auch nen Analyseprogramm geschrieben. Nun ist die Frage, ob wir etwas noch effektiveres als Copy finden. Ich weiß, dass Copy im Vergleich zu Delete und Insert sehr, sehr effektiv ist, als schnelle Alternative. Aber könnte man das noch etwas umschreiben dass man hier noch schneller arbeitet? Wenn das Programm einige Milliarde Zeichenketten analysieren soll, dann dauert dies so immer noch zu lange, da bin ich Opa bevor ich das Ergebnis habe :freak: Sollte jedoch insgesammt nicht länger dauern, als dass man zwischendurch nen :cheers: trinken kann. Max. ne Stunde. Falls euch da was schnelleres einfällt, einfach sagen. Der Quellcode oben dient nur zum Zeitmessen, hat also keine Bedeutung. Die Datei ist ca. 12MB groß und besteht aus sinnlosen Daten. |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Die drei extrahierten Strings zu addieren dauert auch seine Zeit.
Du könntest den Zielstring bereits auf die richtige Länge bringen und die Daten per Move kopieren. Schau dann mal im CPU-Fenster nach, ob diverse Compiler-Funktionen aufgerufen werden (UniqueString etc). |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Was ich mit diesem Delete und Insert meine ist folgendes. In diesem Beispiel werden einfach zwei Zeichen in einer in einem beliebigen Text getauscht, habe jetzt mal nur die Prozeduren aufgeführt:
Delphi-Quellcode:
Das Analyseergebnis:
procedure tauschen1(VAR text: string; x,y: integer);
var a,b: char; Begin a := text[x]; b := text[y]; delete(text,x,1); insert(b,text,x); delete(text,y,1); insert(a,text,y); End; procedure tauschen2(VAR text: string; x,y: integer); var b: char; Begin b := text[x]; text[x] := text[y]; text[y] := b; End; Bei Tauschen 1: Zeichen: - Zeit: 1.000 - 7,1 s 1.000.000 - 116 min, 0 s 1.000.000.000 - 80d, 13h, 12min Bei Tauschen 2: Zeichen: - Zeit: 1.000 - <0,1 s 1.000.000 - <0,1 s 1.000.000.000 - 14,6 s Warum die eine Prozedur wesentlich länger braucht ist mir klar, ich kann logisch nachvollziehen wie Delete und Insert funktionieren, und dass dort mehr Schritte nötig sind, als wenn der Text einfach nur überschrieben wird, also dieses eine Zeichen. Kann man irgendwo nachlesen, was bei den einzelnen Funktionen und Prozeduren genau gemacht wird? Weil diese setzen sich sicherlich aus anderen kleineren Bestandteilen zusammen wenn ihr versteht was ich meine. Versteht ihr? :gruebel: |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
|
Re: Schneller Code - Von Delete und Insert -> Copy ->
für 2 Strings:
Delphi-Quellcode:
nja, aber eigentlich macht Delphi intern auch nix anderes und wandelt das etwa in S := LStrCat(s1, s2); um, welches auch sowas macht :stupid:
S := S1 + S2;
>> SetLength(s, Length(s1) + Length(s2)); MoveMemory(@s[1], @s1[1], Length(s1)); MoveMemory(@s[1 + Length(s1)], @s2[1], Length(s2)); aber
Delphi-Quellcode:
Copy würde ja je einen neuen temporären String anlegen.
s := Copy(s1, 10, 20) + Copy(s2, 1, 10);
>> SetLength(s, 30); MoveMemory(@s[1], @s1[10], 20); MoveMemory(@s[21], @s2[1], 10); !! alles ohne Prüfung der Parameter |
Re: Schneller Code - Von Delete und Insert -> Copy ->
sag mal, was willste da kopieren? ist das willkürlich oder gibt es da 'ne logik dahinter? falls logik, könnt man da vielleicht die grossen zeitfresser ausscheiden... :-) . aber so, schichtest du den ganzen speicher 'n paar mal um, und das kostet halt zeit...
<HTH> |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Also erstmal danke @ himitsu, ich werde gleich mal testen, wieviel % das schneller ist als mit der copy Methode, und das Ergebnis hier bekannt geben.
@grenzgaenger, nein, das hat in diesem Fall keine Logik :mrgreen: Aber das Ergebnis kann man logisch verwenden. Es geht um das Thema Kryptologie. Der Quellcode muss so effektiv sein, dass man ihn mit keiner anderen Programmiersprache oder anderen Mitteln nachprogrammieren könnte, und es dann schneller weil der PC taktisch weniger Rechnen muss. Verstehen musst du das nicht. Die großen Zeitfresser habe ich ja schon aussortiert, aber da muss alles raus, was man womöglich mit anderen Mitteln effektiver erreichen kann. Es soll quasi unmöglich sein, den Code so zu schreiben, dass der PC es schneller entschlüsseln kann, als mit diesem Programm. Hierbei ist wirklich jeder Bruchteil einer Sekunde entscheidend. |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Vielleicht solltest du dir
 AQtime ansehen... |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
tja, wenn es keine logik hat, solltest du beim copy bleiben. das ist das beste. falls doch etwas mehr logik... den speicher zuerst ausrechnen und dann gemeinsam dort hin kopieren (himitsu hat den code bereits gequoted). sollte das noch nicht ausreichen kannst du nach der logischen optimeriung noch mit assembler anfangen... wenn die logik passt, dann wirst du da auch nicht mehr das grosse rausholen. denn der move in 'n bestimmten bereich ist schon sehr schnell. Zitat:
<HTH> GG |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Ich weiß nicht aber Delphi Strings sind ja verwaltete Objekte vielleicht macht es sinn nicht mit Strings zu arbeiten,
sondern mit Speicherblöcken und dann mit den Zeichenketten Verarbeitungs Befehlen des Assemblers zu kopieren. Einerseits fällt das bei 12MB Großen Strings auch nicht mehr ins Gewicht andererseits könnte jemand anderes dadurch schneller sein. Überhaupt hat eine Hochsprache keine Chance gegen einen handoptimierten Assemblercode , es ist meist nur einfach unwirtschaftlich. |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
Versuch mal eine schnellere (generische) System.Move-Variante zu schreiben, als die vom Fastcode-Projekt optimierte Version in der aktuellen Delphi RTL... |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
Delphi-Quellcode:
jkr
text2 := copy(text1,20000,500000 - 19999) + copy(text1,1,19999) + copy(text1,500001,length(text1) - 500000);
|
Re: Schneller Code - Von Delete und Insert -> Copy ->
Delphi-Quellcode:
Es ist wohl auch nicht die Copy-Funktion, die bremst, sondern das mehrfache zusammenhängen der Strings.
for i := 1 to 50 do
begin // folgende Zeile sollte unbedingt ausserhalb der Schleife liegen, // ansonsten wird 50 Mal aus einer Datei gelesen, was natürlich viel mehr Zeit braucht, // als die Copy Funktionen text1 := FileToString('abc.xyz'); text2 := copy(text1,20000,500000) + copy(text1,1,19999) + copy(text1,500001,length(text1)); end; Bei D := A + B + C wird ja zuerst A + B gebildet (dazu muss erst Speicher reserviert werden) Dann wird AB + C gebildet (schon wieder muss ein grosser Speicherblock reserviert werden und wieder werden die Datenblöcke im Speicher kopiert) Ansonsten könnte man in diesem Fall auf Copy ganz verzichten und stattdessen das schnelle Move benützen:
Delphi-Quellcode:
text1 := FileToString('abc.xyz');
for i := 1 to 50 do begin SetLength(text2, Length(text1); // Speicher reservieren // text2 := copy(text1,20000,500000) + copy(text1,1,19999) + copy(text1,500001,length(text1)); Move(text1[20000], text2[1], 50000); Move(text1[1], text2[50001], 19999); Move(text1[50001], // hier wird es etwas schwierig, weil ich nicht sicher weiss wie gross length(text1) ist end; |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Die schnellsten Ergebnisse wirst Du bekommen wenn die Verschlüsselung
in hochoptimiertem Assemblercode programmierst (wenn man es kann...) Allerdings ist diese Art der Verschlüsselung die schlechteste Wahl! 1. :( Die schlechteste Art Daten zu verschlüsseln: Die Verschlüsselung besteht aus einer Folge von Aktionen welche die Daten des Originaltextes umstellen (von hinten nach vorn, Blöcke tauschen,...). Wird das Verfahren einmal bekannt, so lassen sich alle jemals codierten Texte sofort entschlüsseln. Da das Verfahren kompliziert ist, muß man es aufschreiben und vergrößert so die Gefahr, das einem Anderem in die Hände fällt. Schreibt man es nicht auf und die wissenden sterben, sind die Daten für immer verloren. Ein solches Verfahren würde in der Öffentlichkeit niemals akzeptiert: Da ich Niemandem sagen kann wie der Originaltext verschlüsselt wird, kann auch Niemand prüfen ob das Verfahren ausreichend sicher ist oder ob der Programmierer sein Wissen nicht missbraucht und die Daten fremder Menschen ausspioniert. 2. :) Eine gute Art Daten zu verschlüsseln (So arbeiten alle modernen Verschlüsselungen): Der Originaltext wird mit Hilfe eines Schlüssels (etwa ein Passwort oder eine Zahl mit einer größe von bis zu 512 oder 1024 Bits) verschlüsselt. Dabei wird der Originaltext Byte für Byte mit dem Schlüssel XOR-Verknüpft. Da der Text länger als der Schlüssel ist, muß man nach dem letzten Byte des Schlüssels wieder mit seinem ersten Anfangen (also den Schlüssel so lange wiederholen/hintereinanderlegen bis man die Länge des Originaltextes hat. Wenn man diesen Vorgang wiederholt wird des Code wieder entschlüsselt. Bei dieser Verschlüsselung muß dem Empfänger bei jeder Botschaft der Schlüssel mitgeteilt werden. Ein solches Verfahren würde von der Öffentlichkeit akzeptiert, weil man Jedem sagen kann, wie die Verschlüsselung arbeitet und Jeder prüfen kann, ob das Verfahren keine Hintertüren enthält. Wenn man für jede Nachricht einen anderen Schlüssel verwendet, kann (wenn der Schlüssel abgefangen würde) immer nur eine Nachricht entschlüsselt werden. Hier läßt sich über ein "Private-/ Public-Key" Verfahren mehr Sicherheit schaffen. Um eine solche Verschlüsselung zu knacken, muß man den Code analysieren. Da der Schlüssel sich ständig wiederholt kann man bei genügend langen Texten Muster finden und über die Entropie (Häufigkeit) der Buchstaben (für jede Sprache anders) lassen sich Rückschlüsse auf den Schlüssel ziehen. Das ist um so einfacher, je einfacher das verwendete Wort ist. Deutsche Soldaten haben im zweiten Weltkrieg teilweise die Namen ihrer Freundinnen als Schlüssel benutzt und diese auch für mehrere Botschaften hintereinander verwendet. Dadurch war es englischen Spezialisten möglich schnell auf den Schlüssel zu kommen. Daher liest man überall "...möglichst Groß-, Kleinbuchstaben, Zahlen und Sonderzeichen verwenden und keine sinnvollen Wörter...). Es gibt Datenbanken in denen die Beliebtesten Passwörter gespeichert sind. Diese werden von Hackern als erstes durchprobiert bevor sie sich mehr Mühe geben müssen. Man erkennt auch, das die Sicherheit mit der Länge des Schlüssels wächst! Das bringt uns zu der perfekten Verschlüsselung...siehe unten... 3. :twisted: Die pefekte Verschlüsselung (klingt komisch...iss aber so...): Wenn man den Schlüssel so lang wie den Originaltext wählt gibt es keine Möglichkeiten Muster zu finden oder sonst irgendwelche Rückschlüsse zu ziehen. Bei hundert Zeichen Text braucht man nur Byte-Weise mit einem hundert Zeichen Schlüssel XOR verknüpfen. Das wiederholen des Vorgangs entschlüsselt den Code wieder. Dieses Verfahren ist absolut sicher! Kein NASA-Computer, FBI, CIA, NSA, andere Vereine... oder Rechengenies sind in der Lage diesen Code zu Knacken! Der Grund ist einfach: die Anzahl der Möglichkeiten ist so groß wie die möglichen Variationen des Originaltextes. Man wüsste beim probieren nicht, ob ein aufgetauchtes (sinnvolles) Wort durch den richtigen Teil des Schlüssels oder nur durch puren Zufall entstanden ist. Oder anders ausgedrückt: Mit dem richtigen Schlüssel kann man aus jedem beliebigen Text jeden beliebigen anderen Text erzeugen (mit gleicher Länge). Schlaue Köpfe werden sagen: "Die perfekte Verschlüsselung gibt es nicht! Sonst würde man das doch überall einsetzen!". Das diese Verschlüsselung nicht verwendet wird liegt an zwei Dingen: 1.Es gibt einen kleinen Haken: Der Schlüssel ist so lang wie der Originaltext und damit in der Regel zu lang um ihn sich merkenzu können. Abtippen möchte ihn auch Niemand. Er muß also in Form einer Diskette, CD/DVD-Rom oder USB-Stick mit jeder ausgetauschten Botschaft weitergegeben werden. Dadurch besteht die Gefahr, das Code und Schlüssel "abgefangen" werden. Sie müssen also auf verschiedenen Wegen transportiert werden. 2.Sämtliche Staaten haben kein Interesse an einer perfekten Verschlüsselung! In einigen Ländern sind starke Verschlüsselungen sogar bei Strafe verboten und/oder fallen unter das Waffengesetz! Man beachte: Verschlüsselungen werden als Waffe angesehen! Die Staaten sind neugierig und wollen überall reinschnüffeln; es macht sie nervös wenn Menschen auf ihre Privatsphäre bestehen und Daten so austauschen, daß man ihnen dabei nicht "über die Schulter blicken" kann. Es kommt noch schlimmer: In den USA sollen (müssen? - so glaube ich jedenfalls) Verschlüsselungen immer über einen Zusätzlichen Key zu entschlüsseln sein, welcher dann der NSA gegeben wird. Die wollen sich nicht (trotz Kenntniss des Verfahrens) die Mühe machen alles auszuprobieren. Dies wurde durch einen einzigartigen Fall bekannt: Als die Microsoft Programmierer das ServicePack3 (oder war's 4?) compilierten, haben Sie vergessen die "Häckchen" für die Debug-Informationen rauszunehmen. In dem ausgeliefertem Code sind nun die Kommentare der Programmierer zu lesen. Im Bereich des Verschlüsselung wurden zusätzliche Keys angelegt welche (unter anderem) mit "NSA" dokumentiert waren! Ein Schlüssel wurde mit einem Fragezeichen dokumentiert und gibt bis Heute Rätsel auf (Wer hat den Wohl bekommen? Hintertürchen eines Programmierers?). Mein Tipp für die perfekte Verschlüsselung: -Generiere mit einem Zufallsgenerator (unbedingt selber bauen! Delphi's interner erzeugt wiederholbare Wertefolgen) eine Datei mit einer Größe von z.B. 8GB. -Datei auf DVD brennen und an deine Freunde schicken (per Post oder noch besser persönlich überreichen). -Wähle eine Startposition in der Datei und verknüpfe den Originaltext Byte für Byte XOR mit den Bytes in der Datei (ab deiner Startposition). -Die Startposition ist eine überschaubare Zahl und kann gemerkt oder per Telefon ausgetauscht werden. -Der Empfänger wiederholt den Vorgang zum Entschlüsseln. Dieses Verfahren ist absolut sicher, solange Niemand Zugriff auf die 8GB-Datei hat. Daher auf einem Rechner entschlüsseln welcher keinen Zugang zu einem Netzwerkzugang hat (weder intern, noch extern) oder die DVD nur zum Entschlüsseln einlegen (Die ist zu groß als das sie Online-Schnüffler vom BKA "mal eben" übertragen könnten :wink: ). Mal nebenbei bemerkt: So schnell dein Code auch sein mag - in ein paar Jahren sind moderne PC's auch mit einem langsamen Code schneller beim Entschlüsseln und der Stellenwert der Geschwindigkeit so nur temporär. Stichworte für Google-Suche: "Private Public Key", "HASH Funktion" |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Ich fass mich kurz. Erst einmal oben, dieser Copy Fehler^^ Ja, Info liegt schon nen weilchen zurück. Habs mitlerweile korrigiert.
Ich habs jetzt mal umgeschrieben:
Delphi-Quellcode:
Allerdings steigt der mir da immer aus. Ich vermute, dass es daran liegen muss:
procedure TForm1.Button5Click(Sender: TObject);
var text1,text2: string; i,x: integer; begin text1 := FileToString('abc.xyz'); // datei hat nix zu sagen, dient als temp. Datenquelle x := length(text1); ShowMessage('Messung starten'); for i := 1 to 50 do begin SetLength(text2, x); // Speicher reservieren Move(text1[20000], text2[1], 500000 - 19999); Move(text1[1], text2[500001 - 20000], 19999); Move(text1[500001],text2[500001], x); end; ShowMessage('Fertig'); end; procedure TForm1.Button7Click(Sender: TObject); var text1,text2: string; i,x: integer; begin text1 := FileToString('abc.xyz'); // datei hat nix zu sagen, dient als temp. Datenquelle x := length(text1); ShowMessage('Messung starten'); for i := 1 to 50 do begin SetLength(text2, x); // Speicher reservieren text2 := copy(text1,20000,500000 - 19999) + copy(text1,1,19999) + copy(text1,500001,length(text1) - 500000); SetLength(text2, x); MoveMemory(@text2[1], @text1[20000], 500000 - 19999); MoveMemory(@text2[500000 -19999 + 1], @text1[1], 19999); MoveMemory(@text2[500001], @text1[500001], x); end; ShowMessage('Fertig'); end;
Delphi-Quellcode:
Hab halt noch nie damit gearbeitet. Aber mein Algorithmus ist so programmiert, dass die Länge IMMER anders ist, auch wenn die Datei immer gleich groß ist.
MoveMemory(@text2[500001], @text1[500001], x);
// und daran: Move(text1[500001],text2[500001], x); Was AQtime angeht, werde ich mir gleich noch reinziehen. Die Zeit opfere ich. Sollte die Optimierung nur minimal sein, so kann man es sein lassen. Was das Verschlüsseln angeht, das was skyobserver geschrieben hat ist mir bekannt und auch korrekt. In ähnlicher Art und Weise habe ich das alles schon ein paar mal gelesen. Mir ist auch klar, dass wenn man einen Schlüssel hat, der so lang ist, wie der zu verschlüsselnde Text, es nicht zu knacken ist. Was würdest du sagen, wenn ich dir sage, dass dies bei mir indirekt der Fall ist? :mrgreen: Ich habe mich ungefähr einen Monat hingesetzt und etwas nahezu, nach meinen Begriffen, unknackbares geschaffen, obwohl der Schlüssel nicht so lang ist. Ich hoffe, dass sich dort jeder die Zähne dran ausbeißen wird, aber bevor ichs veröffentliche will ich noch nen Patent oder so :thumb: Irgendetwas damit niemand auf die Idee kommt das von mir abzukupfern. Und dann können wir darüber streiten, ob man das knacken kann, ok? :zwinker: Mir ist bereits eine Lösung eingefallen, wie man dieses Zeitproblem lösen könnte. Gar nicht! Man macht einfach den Schlüssel ein bisschen länger, dann gleicht sich das aus mit dem, was die "Profis" da programmieren könnten damit es schneller geht. Knacken ist eigentlich unmöglich. Was vielleicht noch zu erwähnen ist... Mein Programm bastelt sich bei jeder Verschlüsselung quasi einen neuen Algorithmus zusammen, soll bedeuten, die Daten werden jeweils mit einem einmaligen Algorithmus verschlüsselt, wie genau das abläuft muss man nicht verstehen. Aber das Entschlüsseln funktioniert ebenfalls :nerd: |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Ich muss noch kurz zwei Sachen anmerken:
Zitat:
Auch habe ich keine Hintertüren eingebaut. Alles bedacht. Hash Funktion ist auch nicht möglich - jedenfalls wird kein Hash Wert des Passwortes gespeichert oder etwas ähnliches. :roll: Aber eine Frage hätte ich noch: Ist es möglich, aus den 1en und 0en in irgendeiner Art und Weise einen Quellcode zu erzeugen? Mein Algorithmus habe ich mit dem eigenen Programm verschlüsselt und wenn ich damit fertig bin bereinige ich die leeren 1en und 0en auf meinem PC. Indem ich sie überschreibe. Das klingt jetzt vielleicht paranoid, aber ich wollte was unknackbares machen. Nen Kumpel von mir meinte, dass er nen Programm hat, wo er sehen kann, wie die Exe Datei immer zwischen den einzelnen Einträgen hin und her hopst. Somit kann man halt einfache sachen wie ne Warteschleife aushebeln. Kann man dadurch irgendwie an den Algorithmus kommen? Wenn ichs mit UPX packe, dann komprimiert er dass ja alles noch ein bisschen. Wird es dann schwerer an den Algorithmus zu kommen? |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
|
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
Zitat:
|
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
|
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
denke, du solltest noch mal über die bücher! |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zum Thema UPX und Co.:
Als Schutz bringt das nichts, da man dieses leicht wieder entpacken/entschlüsseln kann. Abgesehn davon, daß selbst bei gepackter/verschlüsselter EXE der Code(Algo) ungeschützt, ungepackt, unverschlüsselt im RAM liegt, denn sonst könnte Windows ja dein Programm nicht ausführen. :stupid: Und dazu liegt auch noch alles Nötige für die Entschlüsselung und/oder das Entpacken direkt in der EXE (sie muß sich ja selbst entpacken/entschlüsseln können). PS: such mal im Forum nach Beiträgen des Users "negah" (Hagen) ... ist einer der größten Verschlüsselungsexperten ... also gibt's viel guten Stoff zum lesen, aber nach den Beschreibungen hier, würd ich jetzt einfach mal vermuten, daß er deinen Algo in der Luft zerreißt und dirleicht beweißt, daß er unsicher ist ... sind halt, selbst wenn in guter und sicherer Kern dahinterstecken könnte, zuviele Schwachstellen drin, welche das Ganze wieder insgesammt unsicher machen ... jedenfalls scheint es mir so, denn wozu sollte es sonst nötig sein den Algo mit "billigen" Tricks zu verschleiern? |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
Theoretisch könnte ich den Algorithmus ja dann doch ins Forum schreiben. Ich werd drüber nachdenken. Was das copy angeht:
Delphi-Quellcode:
Dauer: 37 Sekunden
procedure TForm1.Button2Click(Sender: TObject);
var text1,text2: string; i,x: integer; begin text1 := FileToString('abc.xyz'); // datei hat nix zu sagen, dient als temp. Datenquelle x := length(text1); ShowMessage('Messung starten'); for i := 1 to 1000 do begin text2 := copy(text1,20000,500000 - 19999) + copy(text1,1,19999) + copy(text1,500001,x - 500000); end; ShowMessage('Fertig'); end;
Delphi-Quellcode:
Dauer: 11 Sekunden
procedure TForm1.Button5Click(Sender: TObject);
var text1,text2: string; i,x: integer; begin text1 := FileToString('abc.xyz'); // datei hat nix zu sagen, dient als temp. Datenquelle x := length(text1); ShowMessage('Messung starten'); for i := 1 to 1000 do begin SetLength(text2, x); // Speicher reservieren Move(text1[20000], text2[1], 500000 - 19999); Move(text1[1], text2[500001 - 20000], 19999); Move(text1[500001],text2[500001], x - 500001); end; ShowMessage('Fertig'); end;
Delphi-Quellcode:
Dauer: 47 Sekunden
procedure TForm1.Button7Click(Sender: TObject);
var text1,text2: string; i,x: integer; begin text1 := FileToString('abc.xyz'); // datei hat nix zu sagen, dient als temp. Datenquelle x := length(text1); ShowMessage('Messung starten'); for i := 1 to 1000 do begin SetLength(text2, x); // Speicher reservieren text2 := copy(text1,20000,500000 - 19999) + copy(text1,1,19999) + copy(text1,500001,length(text1) - 500000); SetLength(text2, x); MoveMemory(@text2[1], @text1[20000], 500000 - 19999); MoveMemory(@text2[500000 -19999 + 1], @text1[1], 19999); MoveMemory(@text2[500001], @text1[500001], x-500001); end; ShowMessage('Fertig'); end; Damit wäre diese Frage auch beantwortet. Mit Move kann man die Meiste Zeit einsparen, dann geht das ganze 3 mal so schnell :wink: Werd dies auch auf alle anderen Stellen übertragen, wo Zeichenketten zusammengefügt werden. Wieder etwas neues dazu gelernt :zwinker: Aber eine Frage habe ich jetzt noch: :gruebel: Wenn ich hier in Deutschland dieses Programm nun kostenlos zur Verfügung stelle, könnte ich dann von den anderen Ländern aus Ärger bekommen? Es liegt ja nahe, dass auch in diesen Ländern das Programm genutzt werden "könnte". Oder ist dann der Anwender schuld, der es benutzt? Ich bin gerade dabei das Programm ins Englische zu übersetzen. Kann ich da Probleme bekommen wenn ich das Online stelle, und auch Englisch unterstützt wird? Weil damit fördere ich ja quasi die Verbreitung auf den anderen Kontinenten. Kennt sich da jemand aus? Zitat:
|
Re: Schneller Code - Von Delete und Insert -> Copy ->
Hallo Lucky,
Ich weiß ja nicht warum Du gerne ein Patent auf deinen Algoritmus haben möchtest, vermute aber Du hast falsche Vorstellungen von den Möglichkeiten eines Patentes. 1) Wie schon oben angemerkt, gibt es in Europa keine Softwarepatente! Wenn es sich allerdings um die Steuerung eines bestimmten Gerätes handelt, sind die Chancen schon größer. 2) Gesetzt der Fall Du hast ein (erteiltes) Patent, dann hast Du zunächst nur ein Stück Papier auf dem Patent steht. Weiterhin wird in diesem Patent die Vorgehensweise Deines Programms veröffentlicht! Jeder kann also Lesen was Du Dir ausgedacht hast, und jeder weiß, da? es sich hierbei um Deine Idee handelt. 3) Geld kannst Du mit dem Patent nur verdienen, wenn Du eine oder mehrere Lizenzen verkaufen kannst. Damit vergist Du an Deine Lizenznehmer das Recht, deine Idee zu nutzen. Die andere Möglichkeit ist es einem Wettbewerber/Konkurrenten nachzuweisen, daß er Dein Patent nutzt, dann kannst Du per Gerichtsbeschluß eine Zwangslizenz oder einen Schadenersatz erzwingen. Du mußt nur nachweisen, daß er Dein Patent nutzt. 4) Mach bitte nicht den Fehler Patent=Idee zu setzen. Letztendlich wird durch das Patent das geschützt was Du beschrieben hast. Im pratischen Beispiel hast Du den Code durch die Verwendung von MOVE optimiert. Wenn ich stattdessen copy nutzen würde, müßte letztendlich ein Gericht entscheiden, ob ich Dein Patent verletze. Und ohne Urteil gibt's kein Geld. 5) Wenn Du denn ein Patent in den USA hättest, dann wäre die Nutzung auch nur in den USA geschützt und überall sonst auf der Welt könnte Dir jeder eine lange Nase drehen. Gruß K-H |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
|
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
aber "Ideen sind wie Zahnpasta, man kann sie nicht wieder in die Tube zurück drücken". (ist leider nicht von mir!) Auf der anderen Seite wenn Du deine Idee nicht veröffentlichst, bekommt auch keiner mit wie gut Du bist! Gruß K-H |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zum Thema Patent...
Kannst Du mathematisch beweisen wieviele Möglichkeiten es braucht um den richtigen Schlüssel zu finden? Kannst Du mathematisch die Warscheinlichkeit des Auftretens von Mustern zur verkürzten Suche berechnen? Ich will dich nicht entmutigen, aber wenn nicht, kannst Du den Gedanken abschreiben das jemals Jemand Interesse an deinem Verfahren hat! "Glauben" ist halt nicht "Wissen" und wer heute hochsensible Daten verschlüsselt (und Gebühren für das Verfahren zahlt) der will halt "Wissen" wie sicher es ist. Schon oft haben sich scheinbar sichere Verfahren als einfach zu knacken herausgestellt, wenn erstmal ein Angriffspunkt gefunden ist. Wenn Du hunderte von Misch- und Umstellverfahren in einer Geheimen Reihenfolge anwendest mußt Du sicherstellen das keine Vereinfachung existiert: x*10/2 und x*5 sind unterschiedliche Operationen die zum gleichen Ergebnis führen. Wenn Du einen Rubik-Würfel verdrehst indem Du immer den gleichen Zug machst kommst Du irgendwann wieder zum Ausgangspunkt zurück, sagen wir mal nach 128 Zügen. Wenn Du jetzt drei verschiedene Züge mit je 128er Zyklus kombinierst (1,2,3,1,2,3,...) erwartest Du sicher einen Gesamt-Zyklus von 128*128*128=2097152 Zügen. Das wird selten der fall sein! Es wird Dir fast immer passieren, daß während dieser 2097152 Züge der Würfel mehrmals die Ausgangsposition durchläuft und in diesen Fällen sinkt die Anzahl der Möglichkeiten dann auf 2097152 geteilt durch die Anzahl der passagen der Ausgangsposition. Das Große Ziel der Kryptologie ist es also ein Verfahren mir einem möglichst großen und vor allem perfekten Zyklus ohne Wiederholungen zu finden. Da kommen die HASH-Funktionen wieder ins Spiel: Eine HASH-Funktion liefert zu einem Wert "A" einem Wert "B". Allerdings können mehrere verschiedene Werte "A" zum gleichen Wert "B" führen (der umgekehrte Weg ist also nicht eindeutig). HASH-Funktionen werden heutzutage von Mathe-Genies und Supercomputern Tag und Nacht analysiert um herauszufinden welche "A"s zum gleichen "B" führen. Es gibt bekannte HASH-Funktionen die lange als sicher galten bis man einen Weg fand mit relativ geringem Rechenaufwand zu einem bestimmten "A" alle Gegenstücke zu finden. Soviel ich weiß gibt es nur wenige HASH-Funktionen bei denen bis zum heutigen Tage keine Pärchen gefunden werden konnten. Ein Verschlüsselungsverfahren wird heute nur noch akzeptiert, wenn das Verfahren bekannt und für Jedermann zugänglich ist. Die Sicherheit darf nur von dem Schlüssel (oder den Schlüsseln) abhängen; nicht aber von dem Verfahren an sich. Darum wird auch bei jeder Verschlüsselung immer der Name angegeben (z.B. PGP). Es ist halt kein Geheimnis wie es funktioniert...das kann man im Internet nachlesen! Da Du uns aber nicht sagen möchtest wie Dein Verfahren funktioniert, folgere ich daraus, daß Niemand den verschlüsselungsvorgang kennen darf, weil er sonst in der Lage wäre deinen Code zu knacken. Daraus ergibt sich ein gewaltiges Sicherheitsloch: Du must dem Anwender ja eine Software geben, damit er die Daten wieder entschlüsseln kann. Ein Hacker wird den Binärcode deiner Software reassemblieren und sehen was dein Programm macht. Dagegen kann man nichts unternehmen. Ein Programm das ein Computer abarbeiten kann, kann auch ein Programmierer interpretieren. Und schon ist das Geheimnis kein Geheimnis mehr. Also wie willst Du mich von der Sicherheit deines Verfahren überzeugen damit ich es kaufe? Du kannst mir ja nicht sagen wie es funktioniert damit ich einschätzen kann ob es sicher ist. Jeder der was verkaufen will erzählt mir doch heute das blaue vom Himmel und sein Produkt sei das beste. Da verlange ich schon ein paar Expertiesen von namhaften Forschungsinstitutionen. Hast Du das Geld eine Solche Expertiese anfertigen zu lassen? Was wenn sich herausstellt, das eine Vereinfachung existiert oder dein Programm analysiert wurde? Die vertraulichen Daten all meiner Kunden können von jedermann im Internet gelesen werden. Meine Kunden verklagen mich auf Schadensersatz und ich bin pleite! Ich wiederum verklage dich auf mehrere Millionen! Wenn Du jetzt nicht nachdenklich geworden bist und Dir immer noch sicher bist dann wünsche ich Dir auf jeden Fall viel Erfolg (vielleicht kannst Du ja wirklich früher mit dem Arbeiten aufhören)! |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
Macht mindestens!!! 256^10 Möglichkeiten = 1208925819614629174706176 Möglichkeiten. Im Durchschnitt braucht man jedoch nur 604462909807314587353088 Versuche. Noch einmal möchte ich anmerken, für den Fall dass das Passwort minimal ist, also 10 Zeichen. Es wird länger sein, darum gibt es nahezu unmöglich viele Möglichkeiten. Gehen wir mal von einem Rechner aus, der knapp 4 mal so schnell wie der schnellste Rechner der Welt ist - also wir denken schon mal in die Zukunft vorraus. das wären 10^15 Befehle die er in einer Sekunde ausführen kann. Grob gerechnet, 1.000.000 mal so schnell wie nen durchschnitts PC. Wenn der Algorithmus exakt 5 Sekunden benötigt, und irgend jemand das irgendwie auf 1 Sekunde reduzieren könnte, dann bräuchte man zum Knacken durchschnittlich 19167393131891000 Jahre auf einem Handelsüblichen PC. Zweiter Fall: Der Super Rechner. Benötigt immer noch 19167393131 Jahre. :cheer: Zitat:
Zitat:
Zitat:
So etwas wie Hash Funktion gibts bei mir gar nicht. Einfach aber Sicher - davon bin ich überzeugt. Als ich mein Projekt im Infounterricht in 90 Minuten präsentiert habe, da hat mein Info Lehrer einfach nur "krass" gesagt, mehr nicht. Dort habe ich das Verfahren auf einfache Art und Weise erklärt. Zitat:
Zitat:
Wie gesagt, da gebe ich dir Recht. Darum werde ich den Algorithmus offen legen, wenn das Programm öffentlich ist. Dies wird anfang November sein. Ich verspreche, dass dieses Forum das erste sein wird, welches den Code einsehen kann. Dann dürft ihrs auseinander schlachten und negative Kritik äußern. Zitat:
Zitat:
Noch mal zu dem Post davor: Zitat:
Wie kann ich das machen? Das Programm ist eine normale Exe Datei. Da wird nichts installiert. Es wird zwar eine Readme.txt erzeugt und geöffnet, aber erst nach dem Programmstart. Wo kann ich eine solche Beschränkung also bekannt geben? Könnte ich so etwas schreiben wie: Falls sie nicht aus Deutschland sind, dann informieren Sie sich bitte, ob das Programm in Ihrem Land zugelassen ist. Es handelt sich hierbei um ein Verschlüsselungsverfahren, welches wohl sehr schwer zu knacken sein wird. Geht das? |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
ausserdem weigerst dich auch behaarlich, den code offen zu legen. spätestens beim wettbewerb werden sie deinen code auseinandernehmen und dir die schwachstellen auflisten. falls es das doch überleben sollte, solltest du vor einer veröffentlichung erst mal deinen quälcode hier prüfen lassen. ansonsten würd ich gleich auf eine veröffnetlichung verzichten. dann hast du das problem nicht, mit den unterschiedlichen rechtsvorschriften ... und schadensersatzforderungen ... für die lizinzfrage, musst du dir vor dem herunterladen und vor dem programmstart bestätigen lassen (am besten mit rückmeldung), dass das programm vom kunden nur im definierten rahmen (z. b. land) eingesetzt werden darf. z.b. über freischaltcode und registrierung. den code könntest dann direkt an die ECHSE ran hängen... dann kann er das progry auch auf 'n USB stick verwenden... |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
Dann hätte man den Spielraum von 0 bis 255. Grüße Klaus |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
guten Programmierer halbwegs gelesen werden. Zurück in einen Hochsprachen-Quelltext (Basic/Delphi/C++) kommt man nicht wirklich (Die meisten Strukturen und Variablennamen gehen beim Compilieren verloren). Zitat:
von uns weiß schließlich wieviel Du über die Mathematik weißt oder wie lange Du Dich schon mit dem Thema beschäftigt hast. Wir wollen nur das Du deinen Code selber kritisch betrachtest ob er unseren Bedenken standhält. Man will hier nur sicherstellen, daß Du kein Träumer bist den man auf dem Boden der Tatsachen zurückholen muß damit er sich nicht eventuell fürchterlich blamiert. Wie oft liest man nicht im Forum: "Ich habe seit gestern Delphi! Wie schreibe ich einen unknackbaren Code?" :stupid: :thumb: Ich drücke Dir jedenfalls die Daumen für den Wettbewerb! :thumb: |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
Was noch einmal die Sicherheit des Codes angeht, selbst an den Zufallsgenerator habe ich gedacht, dass diese ja berechnet werden. Also werden auch diese Werte vom Anwender beeinflusst. Zitat:
|
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
|
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
ist, kann das nicht verifiziert werden und ist somit nicht vertrauenswürdig. Zitat:
zu unterschiedlichen Ergebnissen führt muß in der codierten Datei ein Hinweis gespeichert sein welcher Aufschluss über die Art der Veränderung gibt. Sonst könnte der Empfänger aus einer Millionen Möglichkeiten nicht die richtige herausfinden. Da diese Information ganz zu Anfang beim entschlüsseln benötigt wird, kann sie nicht zusammen mit den eigentlichen Daten verschlüsselt werden. Sie wird in einem definierten Bereich (Header) der Datei stehen. Ich gehe mal stark davon aus, daß Du das Datum+Uhrzeit (zum Zeitpunkt der Codierung) in Millisekunden umrechnest und diesen Wert als Variablen Faktor verwendest. Datum und Uhrzeit müssen aber dann irgendwo schwach oder ganz unverschlüsselt in der Datei stehen. Vielleicht änderst Du auch künstlich die Länge der Datei in dem Du mehr oder Weniger "Zufalls Datenschrott" anhängst. In diesem Fall muß auch irgendwo die Länge der Originaldatei stehen um den Vorgang eindeutig rückgängig zu machen. Zitat:
oder mehr. Durch ein Verfahren namen "Geburtstagsangriff" (siehe Wikipedia) muß man nicht einmal alle Möglichkeiten durchprobieren. Ich habe einen Artikel gelesen, das man kurz davor ist eine 1024(!!!) Bit Verschlüsselung zu knacken: PC-Welt NewsKeine Ahnung wie die das anstellen - die Mathematik dahinter ist mir zu hoch :shock: |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Bei dem Niveau fällt mir
der Crypto Chef ein. :mrgreen: |
Re: Schneller Code - Von Delete und Insert -> Copy ->
Zitat:
*rofl* Das Ding is ja mal geil... Besonders gut find ich Zitat:
|
Re: Schneller Code - Von Delete und Insert -> Copy ->
Neu! Endgenial! Sie können nun auch mit KRYPTOSCHEFF kommunisieren! Datsu müssen Sie einfag das was sie sagen wollen verschlüsselt haben mit KRYPTO, können sie mit einen Hex-Editor die verschlüsselte Datei anschauen und die Hex-Werte VORLESEN. Sie können somit alle Arten von GEHEIM-Informationen auch DIREKT ERZÄHLEN!!!!!1!!11!!!Eins!!!EINS!!ELF!!!
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 13:36 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz