Algorithmus für Verschlüsselung von Texten

Für alles, was in den übrigen Lazarusthemen keinen Platz, aber mit Lazarus zutun hat.
John
Beiträge: 273
Registriert: Mo 30. Jul 2007, 19:55

Algorithmus für Verschlüsselung von Texten

Beitrag von John »

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

monta
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:

Beitrag von monta »

könntest du mit XOR-Verschlüsselung erledigen...

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;


ist aber wirklich nur, um mal eben ein schnelles lesen zu verhindern
Johannes

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Beitrag von pluto »

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
MFG
Michael Springwald

monta
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:

Beitrag von monta »

Nur der Korrektheit wegen RC4 ist etwas deutlich anderes als AES ;)
Johannes

John
Beiträge: 273
Registriert: Mo 30. Jul 2007, 19:55

Beitrag von John »

Kennt da jemand die generellen unterschiede? Und welcher der beste istß
bzw. wo die unterschiede liegen, da mich das thema interressiert.

John

monta
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:

Beitrag von monta »

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 :lol:


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 ;)
Johannes

Euklid
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:

Beitrag von Euklid »

monta hat geschrieben:So, das war mal nen grober Einblick, falls es jemand liest ;)


Finde den Einblick sehr gut, monta! In deinen paar Sätzen steckt die Weisheit von Bänden.

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

monta
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:

Beitrag von monta »

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


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.

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

Euklid
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:

Beitrag von Euklid »

Eine sehr gute Anleitung zum RSA-Algotithmus (public key) gibt es im wiki:

http://de.wikipedia.org/wiki/RSA-Krypto ... C3.BCssels

monta hat geschrieben:man könnte beispielsweise schöne Graphen natürlich mit Lexart zeichnen lassen


Ich spekuliere gerade mit dem Gedanken, ob wir vielleicht Lexart mit Verschlüsselungstechniken bestücken ;)

Ist ohne Zweifel eines der brisantesten Teilbereiche der Mathematik.

John
Beiträge: 273
Registriert: Mo 30. Jul 2007, 19:55

Beitrag von John »

Für oben, die variable in die man sozusagen den zu verschlüsselnden Text eingibt ist ?!? Also auf den ersten algo von Monta.


John

monta
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:

Beitrag von monta »

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.

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

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Beitrag von pluto »

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 ?
MFG
Michael Springwald

monta
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:

Beitrag von monta »

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

John
Beiträge: 273
Registriert: Mo 30. Jul 2007, 19:55

Beitrag von John »

Die einzige frage, die ich jetzt noch habe ist, was ist F und j? Naja ich würde imho sagen die passzahl und decode?!?aber wie könnte man die jetzt darauf anwenden?!?

John

monta
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:

Beitrag von monta »

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:

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


Die passzahl ist im Beispiel 16 ;)
Johannes

Antworten