Schneller Code - Von Delete und Insert -> Copy -> ???

[nicodex]

Zitat von QuickAndDirty:

Überhaupt hat eine Hochsprache keine Chance gegen einen handoptimierten Assemblercode ,
es ist meist nur einfach unwirtschaftlich.

Das ist schon richtig, aber dazu muss man sich erstmal mit Assembler auskennen.
Versuch mal eine schnellere (generische) System.Move-Variante zu schreiben, als die vom Fastcode-Projekt optimierte Version in der aktuellen Delphi RTL...

[jottkaerr]

Zitat von -Lucky-:

Delphi-Quellcode:

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;

Abgesehen von Deinem Performanzproblem: Kann es sein, dass Du den dritten Parameter von Copy() nicht richtig verwendest? Dieser gibt die Länge des zu kopierenden Bereichs an. Ich habe den Eindruck, dass Du ihn aber für die Position des letzten Zeichen hältst, so dass der Bereich vom 500001. bis zum 519999. Zeichen doppelt im Zielstring landet . Richtig wäre meines Erachtens:

    text2 := copy(text1,20000,500000 - 19999) + copy(text1,1,19999) + copy(text1,500001,length(text1) - 500000); jkr

[shmia]

Delphi-Quellcode:

  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;

Es ist wohl auch nicht die Copy-Funktion, die bremst, sondern das mehrfache zusammenhängen der Strings.
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;

[skyobserver]

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. 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 ).


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"

[-Lucky-]

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:

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;

Allerdings steigt der mir da immer aus. Ich vermute, dass es daran liegen muss:

Delphi-Quellcode:

MoveMemory(@text2[500001], @text1[500001], x);
// und daran:
Move(text1[500001],text2[500001], x);

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.

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?

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

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?

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

[-Lucky-]

Ich muss noch kurz zwei Sachen anmerken:

Zitat:

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?).

-->> Nanu, kann ich da Probleme bekommen? Ich habe bereits etwas geschrieben, was als unknackbar zählt. Man hat mir diesbezüglich schon halbe Droh E-Mails und so etwas wie hier geschrieben. Ich solle doch nix unknackbares entwickeln.

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.


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?

[nicodex]

Zitat von -Lucky-:

Allerdings steigt der mir da immer aus. Ich vermute, dass es daran liegen muss:

Move(text1[500001],text2[500001], x);

Du willst zum Schluß nicht x Bytes kopieren (alles), sondern den "Rest ab 500001" (x - 500001).

[grenzgaenger]

Zitat von skyobserver:

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.

ausserdem muss der schlüssel einmalig sein. das heisst, bei jeder neuen verschlüsselung kommt ein neuer schlüssel zum einsatz

Zitat von skyobserver:

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?).

ausserdem sind kryptographische verfahren in verschiedenen ländern gänzlich verboten. in dennen darf noch nicht mal das passwort verschlüsselt auf die festplatte abgelegt werden.

[grenzgaenger]

Zitat von -Lucky-:

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

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?

wenn es wirklich gut ist, kannst den algo hier ins forum stellen und den quelltext dazu. sonst ist es einfach security by obscurity. und wohl mit das schlechteste was es gib. ausserdem ist es doch nicht schlecht, seinen code auf schwachstellen prüfen zu lassen. zu deinem patent (a) gibts hier in europa keine softwarepatente, (b) um ein patent in den USA anzumelden brauchst nur 'ne idee, 'n biserl papier und das war es schon... also kannst schon mal zum patentamt wackeln

[grenzgaenger]

Zitat von -Lucky-:

Ich muss noch kurz zwei Sachen anmerken:

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.

ziel verfehlt, setzen! wenn du den algo im code ablegst, hastt du schon verlohren. das ist (fast) das leichteste zum knacken was es gibt. ebenfalls kann man prima die logik extrahieren... 'bei einer interpreter anwendung, kann man das ganze gar als hochsprachencode ausgeben...

denke, du solltest noch mal über die bücher!