Algorithmus für Verschlüsselung von Texten
Algorithmus für Verschlüsselung von Texten
Also ich hatte mal vor Jahren nen Algo der bestimmte Buchstaben in bestimmte andere Buchstaben verwandeln konnte. Daher z.B. aus A wird y, aus H wird 7, Die zeichen welche bestimmte ersetzen sollen bleiben immer gleich. Und sind nicht auf ein Benutzerfesgelegt über einzelne Konstanten. Sondern irgendwie über dem das bestimmten Buchstaben eine bestimmte Nummer gegeben wurde und diese multipliziert.
Aber ich weiß nicht mehr genau wie das ging. Wie kann man den schnell wieder irgendwelche Texte verschlüsseln, hat dafür jemand nen Algo?
John
Aber ich weiß nicht mehr genau wie das ging. Wie kann man den schnell wieder irgendwelche Texte verschlüsseln, hat dafür jemand nen Algo?
John
-
- Lazarusforum e. V.
- Beiträge: 2809
- Registriert: Sa 9. Sep 2006, 18:05
- OS, Lazarus, FPC: Linux (L trunk FPC trunk)
- CPU-Target: 64Bit
- Wohnort: Dresden
- Kontaktdaten:
könntest du mit XOR-Verschlüsselung erledigen...
ist aber wirklich nur, um mal eben ein schnelles lesen zu verhindern
Code: Alles auswählen
function Xor_Crypt(s: string; passzahl: Integer; decode: Boolean):string;
var
i, c, x: Integer;
begin
if decode then
x := -1
else
x := 1;
RandSeed := passzahl;
Result := '';
for i := 1 to length(s) do
begin
c := ord(s[i]);
if c in [32..122] then
begin
c := c+(x*Random(90));
if (c<32) or (c>122) then c := c-(x*90);
end;
Result := Result + chr(c);
end;
end;
Johannes
-
- Lazarusforum e. V.
- Beiträge: 7192
- Registriert: So 19. Nov 2006, 12:06
- OS, Lazarus, FPC: Linux Mint 19.3
- CPU-Target: AMD
- Wohnort: Oldenburg(Oldenburg)
in meinem Aktuellen Projekt verwende ich AES. In der DP gibt es eine unit in der Code-Lib:
http://www.delphipraxis.net/topic30830_ ... hlight=rcx" onclick="window.open(this.href);return false;
http://www.delphipraxis.net/topic30830_ ... hlight=rcx" onclick="window.open(this.href);return false;
MFG
Michael Springwald
Michael Springwald
-
- Lazarusforum e. V.
- Beiträge: 2809
- Registriert: Sa 9. Sep 2006, 18:05
- OS, Lazarus, FPC: Linux (L trunk FPC trunk)
- CPU-Target: 64Bit
- Wohnort: Dresden
- Kontaktdaten:
Das ist eine lange Geschichte.
Ich hab mich vor einiger Zeit mal damit beschäftigt und ein Buch drüber gelesen.
Prinzipiell musst du zwischen drei Dingen unterscheiden, wie du deine Informationen tarnen kannst/willlst:
Zum einen kannst du natürlich versuchen zu verbergen, das überhaupt wertvolle Informationen da sind. Da dürfte das gebräuchliste sein, die Dinge in einem Bild zu verstecken. Angenohmen du hast 24Bit Farbtiefe, so hast du pro Pixel ja 3 Byte. Dabei fehlt es dem Menschlichen Auge nichtmal auf, wenn du bei einigen Pixeln die letzten drei bis vier Bits veränderst - selbst wenn die Fläche einfarbig ist. So kannst du also einfach immer das 8. Bit auf 0 setzen und deinen Text Bitweise Pixel für Pixel aufteilen. Da sich das allerdings recht leicht entdecken lässt, benötigst du ein Bild mit einem theoretisch optimalen Rauschen (was es nicht gibt) um dort nach einem nur dir bekannten Algorythmus eine bestimmte Bitsequenz in den Pixeln aufzuteilen.
Das lebt davon, das ein potentieller Angreifer überhaupt keinen verdacht schöpft.
Ansonsten wenn du 'richtig' verschlüsseln und nicht nur verschleiern willst, gibts ja letztlich zwei Kernanwendungen. Zum einen nur mal eben ein schnelles Nachlesen zu verhindern und zum anderen Informationen wirklich sicher zu verschlüsseln.
Ich hab beispielsweise mal ein Galgenraten mit Textfile als Wortliste erstellt, damit keiner nur mal schnell die Datei öffnet und die Wörter nachliest, hab ich sie mit XOR (siehe oben) verschlüsselt. Dabei werden ja nur einfache Bits vertauscht, was sich innerhalb von Sekunden knacken lässt, man müsste oben j selbst bei Bruteforce nur die passzahl hochzählen und relativ schnell hätte man es. Ähnlich ist beispielsweise Rot13, indem einfach die ersten 13 Buchstaben mit den letzten 13 gegenüber gestellt werden und entsprechend vertauscht. Genauso kann man beliebig anders vertauschen. Ist aber alles ebenfalls witzlos.
Um dies zu knacken gibt es Häufigkeitstabellen. Da steht drin, mit welcher Häufigkeit welcher Buchstabe in einer Sprache vorkommt. Fürs Deutsche beispielsweise des E, Bei solchen einfachen ersetzungen musst du also nur Schauen, welcher Buchstabe am meisten vorkommt und der steht fürs e usw.
Komplizierter wird es mit Passwörtern/Passphrasen, allerdings sind wir immer noch bei den einfachen verschlüsselungen. Dabei kannst du Beispielsweise jedes Byte des zu Verschlüsselnden Texttes mit jedem Byte des Schlüssels gegenübers setzen und mit XOR verknüpfen, ist der Schlüssel zu ende, wird von vorne wieder begohnen. Problematisch ist allerdings die periodische Wiederhohlung, da der Schlüssel ja im Normalfall wesentlich kürzer as der zu verschlüsselnde Text ist.
Eine recht gute Wirkung erziekt dabei allerdings ein Schlüsseltext mit identischer Länge zum original. Dadurch, das die Buchstabenkombinationen welche Ddabei aufeinadertreffen unterschiedlich ist, entstehehn auch unterschiedliche Resultate und Häufigkeiten u.ä. lassen sich nicht mehr nahverfolgen. Dies seztt natürlich vorraus, das der Schlüsseltext absolut zufällig gewählt und keiner einen Verdacht hat, dann ein Durchaus brauchbares Verfahren, was für einfache Mittel und sogar für aufwendigere Verfahren eine verhältnismäßig hohe Sicherheit bei einnfacher Anwendung bietet.
Natürlich sollte der Text keine Beziehungen zum Autor u.ä. haben, beispielsweise nicht gerade das Lieblingsbuch
An komplizierteren und sichereren Verfahren gibts verschiedene. Viele basieren darauf, aus dem Passwort/Passphrase einen Schlüssel einer festen Bitlänge zu erstellen. Und da liegt auch schon teilweise ein Problem. Viele verfahren haben feste Schlüssellängen, beispielsweise ssl mit 256Bit. Allerdings wird genau diese Bitlänge von kurzen Passwörtern ebenso wenig ausgeschöpft. Um solch einen Shlüssel zu erstellen wird oftmals eine bestimmte Länge der Passphrase benötigt, ist diese kürzer, so wird sie mehrfach verwendet, was die effektive theoretische Sicherheit bei weitem herabsetzt.
Verfahren wie Blowfish, DES, AES, und andere besitzen mehrerer Teilschritte um Informationen zu dekodieren.
Ganz grob läuft das wie folgt ab:
> Es wird aus dem Passwort/Passphrase ein Schlüssel erstellt, aus welchem Datenblöcke bestimmter Längen bzw. variabler Längen erstelt werden (optimaler Weise mit Zufallsdaten)
> Mit diesen Blöcken werden die eigentlichen Daten Blockweise verschlüsselt
> diese Verschlüsselung wird je nach Verfahren mehrfach wiederholt, Blowfish beispielsweise 16 mal, so das immer wieder die bereits verschlüsselnden Informationen erneut verschlüsselt werden um den Zufall zu erhöhen
Es zielt alles darauf ab, eine Datenmenge zu generieren, die eine vollständige Zufallverteilung der Informationen ermöglicht und so eine Entschlüsselung über Musteranalysen unmöglich macht. Klar dürfte sein, das es genau dieses perfekte Chaos nicht gibt, allerdings sind bestimmte Verfahren schon sehr gut.
Gerade bei der Schlüsselerstellung spielt die Primfaktorzerlegung großer Primzahlen oftmals eine entscheidende Rolle. Durch die komplexität dieser Aufgabe ist es so nicht möglich, innerhalb einer entsprechenden Zeit, das Passwort zu knacken. Wäre es daher möglich große Primzahlen (und da sind nicht 10 oder 20Stellen gemeint
) schnell zu zerlegen, wären viele Verschlüsselungsverfahren unbrauchbar.
Doch gerade diese Zeitrechnung macht ein Verfahren sicher oder nicht. Es ist weniger das Problem der möglichkeiten der Verschlüsselung, sondern vielmehr das Problem der verfügbaren Rechnerkapazität im Verhältnis zur Zeit. Nicht umsonst sind bestimmte Verfahren, beispielsweise DES mit der Entwicklung leistungsfähiger Computer durch bessere Verfahren ersetzt worden.
All das zielt darauf ab, das es bei Verfügbarer Rechenkapazität in einer bestimmten Zeitspanne nicht möglich ist, durch Bruteforce den Algorythmus zu kanacken, da man Jahre damit beschäftigt wäre. Unter dem optimalen Fall, das ein Schlüssel nur einmal Verwendet und keinem bekannt ist, sind diese Verfahren also theoretisch ausreichend sicher. Wobei man klar sagen muss, ausreichend, da jedes Verfahren, dessen Algorythmus bekannt ist durch die Unendlichkeit der Zeit auch theoretisch geknackt werden kann.
Fakt ist aber, das bei solcehn Verfahren der Hauptunsicherheitsfaktor der Mensch ist. Weil entweder normale/einfache Wörter verwendet werden. Oder er sich selbst verrät, Schlüssel ausspioniert werden usw.
Natürlich sind beliebige Kombinationen verschiedener Verfahren oder der selben (siehe Triple-DES) zur erhöhung der Sicherheit möglich. Genauso gut kann eine Verschlüsselte Information auch zusätzlich Verschleiert werden, und fällt so nebenbei durch die optimaler Weise Zufallsähnliche Struktur nicht auf, aber der unsichere Mensch als Mitwisser bleibt immer...oder abgefangene Informationen noch vor Schlüsselerstellung.
So, das war mal nen grober Einblick, falls es jemand liest
Ich hab mich vor einiger Zeit mal damit beschäftigt und ein Buch drüber gelesen.
Prinzipiell musst du zwischen drei Dingen unterscheiden, wie du deine Informationen tarnen kannst/willlst:
Zum einen kannst du natürlich versuchen zu verbergen, das überhaupt wertvolle Informationen da sind. Da dürfte das gebräuchliste sein, die Dinge in einem Bild zu verstecken. Angenohmen du hast 24Bit Farbtiefe, so hast du pro Pixel ja 3 Byte. Dabei fehlt es dem Menschlichen Auge nichtmal auf, wenn du bei einigen Pixeln die letzten drei bis vier Bits veränderst - selbst wenn die Fläche einfarbig ist. So kannst du also einfach immer das 8. Bit auf 0 setzen und deinen Text Bitweise Pixel für Pixel aufteilen. Da sich das allerdings recht leicht entdecken lässt, benötigst du ein Bild mit einem theoretisch optimalen Rauschen (was es nicht gibt) um dort nach einem nur dir bekannten Algorythmus eine bestimmte Bitsequenz in den Pixeln aufzuteilen.
Das lebt davon, das ein potentieller Angreifer überhaupt keinen verdacht schöpft.
Ansonsten wenn du 'richtig' verschlüsseln und nicht nur verschleiern willst, gibts ja letztlich zwei Kernanwendungen. Zum einen nur mal eben ein schnelles Nachlesen zu verhindern und zum anderen Informationen wirklich sicher zu verschlüsseln.
Ich hab beispielsweise mal ein Galgenraten mit Textfile als Wortliste erstellt, damit keiner nur mal schnell die Datei öffnet und die Wörter nachliest, hab ich sie mit XOR (siehe oben) verschlüsselt. Dabei werden ja nur einfache Bits vertauscht, was sich innerhalb von Sekunden knacken lässt, man müsste oben j selbst bei Bruteforce nur die passzahl hochzählen und relativ schnell hätte man es. Ähnlich ist beispielsweise Rot13, indem einfach die ersten 13 Buchstaben mit den letzten 13 gegenüber gestellt werden und entsprechend vertauscht. Genauso kann man beliebig anders vertauschen. Ist aber alles ebenfalls witzlos.
Um dies zu knacken gibt es Häufigkeitstabellen. Da steht drin, mit welcher Häufigkeit welcher Buchstabe in einer Sprache vorkommt. Fürs Deutsche beispielsweise des E, Bei solchen einfachen ersetzungen musst du also nur Schauen, welcher Buchstabe am meisten vorkommt und der steht fürs e usw.
Komplizierter wird es mit Passwörtern/Passphrasen, allerdings sind wir immer noch bei den einfachen verschlüsselungen. Dabei kannst du Beispielsweise jedes Byte des zu Verschlüsselnden Texttes mit jedem Byte des Schlüssels gegenübers setzen und mit XOR verknüpfen, ist der Schlüssel zu ende, wird von vorne wieder begohnen. Problematisch ist allerdings die periodische Wiederhohlung, da der Schlüssel ja im Normalfall wesentlich kürzer as der zu verschlüsselnde Text ist.
Eine recht gute Wirkung erziekt dabei allerdings ein Schlüsseltext mit identischer Länge zum original. Dadurch, das die Buchstabenkombinationen welche Ddabei aufeinadertreffen unterschiedlich ist, entstehehn auch unterschiedliche Resultate und Häufigkeiten u.ä. lassen sich nicht mehr nahverfolgen. Dies seztt natürlich vorraus, das der Schlüsseltext absolut zufällig gewählt und keiner einen Verdacht hat, dann ein Durchaus brauchbares Verfahren, was für einfache Mittel und sogar für aufwendigere Verfahren eine verhältnismäßig hohe Sicherheit bei einnfacher Anwendung bietet.
Natürlich sollte der Text keine Beziehungen zum Autor u.ä. haben, beispielsweise nicht gerade das Lieblingsbuch

An komplizierteren und sichereren Verfahren gibts verschiedene. Viele basieren darauf, aus dem Passwort/Passphrase einen Schlüssel einer festen Bitlänge zu erstellen. Und da liegt auch schon teilweise ein Problem. Viele verfahren haben feste Schlüssellängen, beispielsweise ssl mit 256Bit. Allerdings wird genau diese Bitlänge von kurzen Passwörtern ebenso wenig ausgeschöpft. Um solch einen Shlüssel zu erstellen wird oftmals eine bestimmte Länge der Passphrase benötigt, ist diese kürzer, so wird sie mehrfach verwendet, was die effektive theoretische Sicherheit bei weitem herabsetzt.
Verfahren wie Blowfish, DES, AES, und andere besitzen mehrerer Teilschritte um Informationen zu dekodieren.
Ganz grob läuft das wie folgt ab:
> Es wird aus dem Passwort/Passphrase ein Schlüssel erstellt, aus welchem Datenblöcke bestimmter Längen bzw. variabler Längen erstelt werden (optimaler Weise mit Zufallsdaten)
> Mit diesen Blöcken werden die eigentlichen Daten Blockweise verschlüsselt
> diese Verschlüsselung wird je nach Verfahren mehrfach wiederholt, Blowfish beispielsweise 16 mal, so das immer wieder die bereits verschlüsselnden Informationen erneut verschlüsselt werden um den Zufall zu erhöhen
Es zielt alles darauf ab, eine Datenmenge zu generieren, die eine vollständige Zufallverteilung der Informationen ermöglicht und so eine Entschlüsselung über Musteranalysen unmöglich macht. Klar dürfte sein, das es genau dieses perfekte Chaos nicht gibt, allerdings sind bestimmte Verfahren schon sehr gut.
Gerade bei der Schlüsselerstellung spielt die Primfaktorzerlegung großer Primzahlen oftmals eine entscheidende Rolle. Durch die komplexität dieser Aufgabe ist es so nicht möglich, innerhalb einer entsprechenden Zeit, das Passwort zu knacken. Wäre es daher möglich große Primzahlen (und da sind nicht 10 oder 20Stellen gemeint

Doch gerade diese Zeitrechnung macht ein Verfahren sicher oder nicht. Es ist weniger das Problem der möglichkeiten der Verschlüsselung, sondern vielmehr das Problem der verfügbaren Rechnerkapazität im Verhältnis zur Zeit. Nicht umsonst sind bestimmte Verfahren, beispielsweise DES mit der Entwicklung leistungsfähiger Computer durch bessere Verfahren ersetzt worden.
All das zielt darauf ab, das es bei Verfügbarer Rechenkapazität in einer bestimmten Zeitspanne nicht möglich ist, durch Bruteforce den Algorythmus zu kanacken, da man Jahre damit beschäftigt wäre. Unter dem optimalen Fall, das ein Schlüssel nur einmal Verwendet und keinem bekannt ist, sind diese Verfahren also theoretisch ausreichend sicher. Wobei man klar sagen muss, ausreichend, da jedes Verfahren, dessen Algorythmus bekannt ist durch die Unendlichkeit der Zeit auch theoretisch geknackt werden kann.
Fakt ist aber, das bei solcehn Verfahren der Hauptunsicherheitsfaktor der Mensch ist. Weil entweder normale/einfache Wörter verwendet werden. Oder er sich selbst verrät, Schlüssel ausspioniert werden usw.
Natürlich sind beliebige Kombinationen verschiedener Verfahren oder der selben (siehe Triple-DES) zur erhöhung der Sicherheit möglich. Genauso gut kann eine Verschlüsselte Information auch zusätzlich Verschleiert werden, und fällt so nebenbei durch die optimaler Weise Zufallsähnliche Struktur nicht auf, aber der unsichere Mensch als Mitwisser bleibt immer...oder abgefangene Informationen noch vor Schlüsselerstellung.
So, das war mal nen grober Einblick, falls es jemand liest

Johannes
-
- Lazarusforum e. V.
- Beiträge: 2808
- Registriert: Fr 22. Sep 2006, 10:38
- OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
- Wohnort: Hessen
- Kontaktdaten:
Finde den Einblick sehr gut, monta! In deinen paar Sätzen steckt die Weisheit von Bänden.monta hat geschrieben:So, das war mal nen grober Einblick, falls es jemand liest
Eine Sache fehlte mir: Das es sich bei dem Primzahlverfahren vor allem um "Public-Key"-Verfahren handelt:
Man sucht Zahlen, die Produkt von genau zwei Primzahlen sind. Mit diesen Zahlen lassen sich Schlüssel erstellen, mit denen sich Texte zwar verschlüsseln - jedoch nicht wieder entschlüsseln lassen können.
Entschlüsseln kann man die Texte nur durch die Kenntnis der Primfaktoren - d.h. mit der Kenntnis der beiden Primzahlen, deren Produkt die zum Verschlüsseln verwendete Zahl ist.
Wie Monta schon sagte: Zum Knacken ist eine Promfaktorzerlegung notwendig.
Vorteil: Man kann den Schlüsel allen Menschen zeigen. Alle können einen verschlüsselte Botschaften schreiben. Doch obwohl JEDER den Schlüssel zum verschlüsseln hat, kann nur derjenige die Botschaft entschlüssel, der die Zerlegung kennt.

Um gleich ein wenig Werbung zu machen: Sowohl die Berechnung sehr großer Primzahlen, als auch die Primfaktorzerlegungen großer Zahlen wird Lexart bald beherrschen. Da arbeite ich zur Zeit dran, wird aber wohl noch ne Weile dauern. Da kann man also mal probieren, einen 256-bit-Schlüssel in einigen Jahren Rechenzeit zu knacken

-
- Lazarusforum e. V.
- Beiträge: 2809
- Registriert: Sa 9. Sep 2006, 18:05
- OS, Lazarus, FPC: Linux (L trunk FPC trunk)
- CPU-Target: 64Bit
- Wohnort: Dresden
- Kontaktdaten:
Was wiederum darauf hinaus läuft, das der Schwachpunkt in Wahrheit die zweite Schlüsselhälfte ist. Und wer trägt sein PGP-Keyfile schon im Kopf mit sich rum. Also ist es wesentlich einfacher gleich den Rechner zu attakieren, wo die Infos unverschlüsselt vorliegen, bzw. der Schlüssel zu finden ist.Euklid hat geschrieben:Vorteil: Man kann den Schlüsel allen Menschen zeigen. Alle können einen verschlüsselte Botschaften schreiben. Doch obwohl JEDER den Schlüssel zum verschlüsseln hat, kann nur derjenige die Botschaft entschlüssel, der die Zerlegung kennt.
Nebenbei kann man dann einige Jahre seinen Rechner für andere Dinge nutzen als in mit Lexart zu quälen, man könnte beispielsweise schöne Graphen natürlich mit Lexart zeichnen lassen

Johannes
-
- Lazarusforum e. V.
- Beiträge: 2808
- Registriert: Fr 22. Sep 2006, 10:38
- OS, Lazarus, FPC: Lazarus v2.0.10, FPC 3.2.0
- Wohnort: Hessen
- Kontaktdaten:
Eine sehr gute Anleitung zum RSA-Algotithmus (public key) gibt es im wiki:
http://de.wikipedia.org/wiki/RSA-Krypto ... C3.BCssels" onclick="window.open(this.href);return false;

Ist ohne Zweifel eines der brisantesten Teilbereiche der Mathematik.
http://de.wikipedia.org/wiki/RSA-Krypto ... C3.BCssels" onclick="window.open(this.href);return false;
Ich spekuliere gerade mit dem Gedanken, ob wir vielleicht Lexart mit Verschlüsselungstechniken bestückenmonta hat geschrieben:man könnte beispielsweise schöne Graphen natürlich mit Lexart zeichnen lassen

Ist ohne Zweifel eines der brisantesten Teilbereiche der Mathematik.
-
- Lazarusforum e. V.
- Beiträge: 2809
- Registriert: Sa 9. Sep 2006, 18:05
- OS, Lazarus, FPC: Linux (L trunk FPC trunk)
- CPU-Target: 64Bit
- Wohnort: Dresden
- Kontaktdaten:
ja, zur Erklärung:
s ... ist der zu Ver- bzw. Entschlüsselnde Text
passzahl ... varriiert das Resultat, muss allerdings beim Ver und Entschlüsseln identisch sein
decode: gibt an ob Verschlüsselt oder eben entschlüsselt wird
Passwort musst du also keins angeben, sondern nur die richtige Passzahl.
s ... ist der zu Ver- bzw. Entschlüsselnde Text
passzahl ... varriiert das Resultat, muss allerdings beim Ver und Entschlüsseln identisch sein
decode: gibt an ob Verschlüsselt oder eben entschlüsselt wird
Passwort musst du also keins angeben, sondern nur die richtige Passzahl.
Code: Alles auswählen
//Verschlüsseln:
string := XOR_Crypt(F[j], 16, true);
//Entschlüsseln:
string := XOR_Crypt(F[j], 16, false);
Code: Alles auswählen
Resultat:
Steinbruch
Halde
Stollen
wird zu:
&YHL4`*FOo
uFOG+
&YRO2c&
Johannes
-
- Lazarusforum e. V.
- Beiträge: 7192
- Registriert: So 19. Nov 2006, 12:06
- OS, Lazarus, FPC: Linux Mint 19.3
- CPU-Target: AMD
- Wohnort: Oldenburg(Oldenburg)
in meinem Aktuellen Projekt wollte zwei Zufalls schlüssel erzeugen.
Die genau so lang sind wie das Password. Diese schlüssel wollte ich jetzt vorne und hinten an das Password setzten.
Das heißt, Das Password muss jetzt aufjedenfall stimmen. Beim entschlüsseln wird jetzt einfach, wenn das richtige Password eingeben wurde(also die länge stimmt) die Zufallst schlüssel vorne und hinten abgeschnitten bzw. rauß kopiert. Ich denke das wäre doch mit Sicherheit eine stufe sicherer oder ?
Die genau so lang sind wie das Password. Diese schlüssel wollte ich jetzt vorne und hinten an das Password setzten.
Das heißt, Das Password muss jetzt aufjedenfall stimmen. Beim entschlüsseln wird jetzt einfach, wenn das richtige Password eingeben wurde(also die länge stimmt) die Zufallst schlüssel vorne und hinten abgeschnitten bzw. rauß kopiert. Ich denke das wäre doch mit Sicherheit eine stufe sicherer oder ?
MFG
Michael Springwald
Michael Springwald
-
- Lazarusforum e. V.
- Beiträge: 2809
- Registriert: Sa 9. Sep 2006, 18:05
- OS, Lazarus, FPC: Linux (L trunk FPC trunk)
- CPU-Target: 64Bit
- Wohnort: Dresden
- Kontaktdaten:
Pluto...das ist ein Witz oder?
Nur mit nem rauskopieren und verlängern erreichst du keinerlei zusätzliche Sicherheit. Im Gegenteil, was für ein Verfahren hast du denn, das ene falsche Länge des Passwortes nicht ohnehin zu einem falsch entschlüsselten Text führt?
Wenn du mich fragst ist das Krampf, aber keine Sicherheit.
Nur mit nem rauskopieren und verlängern erreichst du keinerlei zusätzliche Sicherheit. Im Gegenteil, was für ein Verfahren hast du denn, das ene falsche Länge des Passwortes nicht ohnehin zu einem falsch entschlüsselten Text führt?
Wenn du mich fragst ist das Krampf, aber keine Sicherheit.
Johannes
-
- Lazarusforum e. V.
- Beiträge: 2809
- Registriert: Sa 9. Sep 2006, 18:05
- OS, Lazarus, FPC: Linux (L trunk FPC trunk)
- CPU-Target: 64Bit
- Wohnort: Dresden
- Kontaktdaten:
Achso...ja, sorry, war nur ein schnell kopiertes Beispiel von einer Verwendung.
F ist ne stringlist und j der entsprechende Zeilenindes, also letztlich nur nen String. Ich hab damit eben fürs Galgenraten ne Wortliste verschlüsselt und die Wörter waren in ner Stringliste organisiert, daher kommt auch das Beispiel der drei Wörter.
Der Vollständigkeit wegen:
Die passzahl ist im Beispiel 16 
F ist ne stringlist und j der entsprechende Zeilenindes, also letztlich nur nen String. Ich hab damit eben fürs Galgenraten ne Wortliste verschlüsselt und die Wörter waren in ner Stringliste organisiert, daher kommt auch das Beispiel der drei Wörter.
Der Vollständigkeit wegen:
Code: Alles auswählen
//Verschlüsseln:
string := XOR_Crypt('zu verschlüsselnder String', 16, true);
//Entschlüsseln:
string := XOR_Crypt('zu entschlüsselnder string', 16, false);

Johannes