Algorithmus für Verschlüsselung von Texten

[John]

lustige geschichte, hab ich getestet, als passzahl einfach mal 99977799 eingegeben, als test 123, und was kam als wort raus? Faszisinierent, stochastisch zumindestens.Ihr könnt auch noch wann eingeben Ein Omen? Kann es in der Informatik Schicksal geben xD

John

[pluto]

naja ich meinte eigentlich weniger das Password. Am verschlüsselten Text werden zwei zufallst Strings von der länge das Passwortes erzeugt.

Ob das nun sicher ist weiß ich nicht. Ich kenne mich auf diesem Gebiet nicht so gut aus.

[monta]

nein macht keinen -unterschied, da bei falscher Länge eh nicht entschlüsselt wird

[Ullman]

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

Hallo monte,

ich habe mir dein Beispiel mal angesehen und ich denke ich kann es im wesentlichen nach vollziehen.
Was ich allerdings nicht verstehe ist, warum, obwohl du ja tatsächlich bei chr (32) = SPACE beginnst, ein entspr. SPACE beim entschlüsseln verschluckt wird.
Ich kann's mir nicht erklären.
Hast du eine Erklärung?

LG Ullman

[MitjaStachowiak]

Nun, ich habe auch mal ein System geschrieben, das mit RSA gearbeitet hat. Ich habe es damals nach umfangreicher Recherche einfach nicht geschafft, eine Library dafür zu verwenden. Ja, der Wiki-Artikel zu RSA ist durchaus empfehlenswert. Die Herausforderung dabei besteht darin, zwei große Primzahlen zu finden, die modular Inverse und die schnelle modulare Exponentation zu berechnen. Aber in vielen Bibliotheken zum Rechnen mit großen Zahlen sind Funktionen dafür schon drinn'.

Zu symmetrischen Verschlüsselungen habe ich damals viel weniger brauchbares gefunden, obwohl die Anforderung eigentlich geringer ist. Im Prinzip benutzt man als Grundlage immer einen einfachen Algorithmus zum "mischen" von Informationen. Also XOR, oder eine Cäsar-erschiebung, also man verschiebt jeden Buchstaben um einen gegebenen Abstand im Alphabet. Wenn die verwendeten Abstände jedes Mal andere (zufällige) sind, ist es unmöglich, das zu knacken. Aber der Schlüssel muss dafür, wie schon mehrfach hier erklärt, genau so lang sein, wie der zu verschlüsselnde Text.

Alternativ kann man auch einen Pseudo-Zufallsgenerator verwenden, um aus einem kurzen Passwort einen beliebig langen Schlüssel zu berechnen. Aber um einiger Maßen unvorhersagbare Zufallszahlen zu berechnen, braucht man wieder große Primzahlen und modulare Operationen... Deswegen verschlüsseln Verfahren, wie AES, immer mehrmals, damit es auch, wenn man ein Stück des Geheimtextes kennt, möglichst schwer ist, das nächste Stück zu berechnen.

Aber mal im Ernst: Nach allem, was ich mit openSSL erlebt habe, seit ich das verwende, frage ich mich schon manchmal, ob ein selbst ausgedachter Algorithmus nicht doch sicherer ist. Immerhin hat ein Hacker dann kein fertigen Baukasten voll Tools, die alle möglichen Sicherheitslücken abtasten und wehe, man hat einen Fehler gemacht... Vielleicht kann ein Experte auf dem Gebiet die Verschlüsselung knacken, aber so ein Experte ist teuer und es muss sich schon lohnen, die Verschlüsselung zu brechen.

[carli]

Aber mal im Ernst: Nach allem, was ich mit openSSL erlebt habe, seit ich das verwende, frage ich mich schon manchmal, ob ein selbst ausgedachter Algorithmus nicht doch sicherer ist. Immerhin hat ein Hacker dann kein fertigen Baukasten voll Tools, die alle möglichen Sicherheitslücken abtasten und wehe, man hat einen Fehler gemacht... Vielleicht kann ein Experte auf dem Gebiet die Verschlüsselung knacken, aber so ein Experte ist teuer und es muss sich schon lohnen, die Verschlüsselung zu brechen.

Eine eigene Verschlüsselung geheim zu halten, ist das dümmste, was du tun kannst. Was ist, wenn du irgendwelche Operationen in der Verschlüsselung verwendest, für die es einen alternativen Weg gibt, den Text zu entschlüsseln? Wenn du weißt, dass niemand jemals deine verschlüsselten Texte sehen wird, kannst du ruhig deine eigene Verschlüsselung erfinden. Damit kann man den Klartext aber lediglich verschleiern. Solltest du tatsächlich Geheimnisse haben, solltest du lieber auf das Wissen von hunderten Kryptographen weltweit setzen und einen der standardisierten Algorithmen (AES, ECDSA etc.) umsetzen. Diese sind geprüft, begutachtet und selbst Banktransfers laufen damit ab und es hat noch niemand geknackt.

Wenn du nicht das Zeug hast, AES selbst zu implementieren, kannst du auch OpenSSL benutzen, da ist es bereits fehlerfrei implementiert. Wenn du allerdings deine eigene Verschlüsselung implementierst, weil du nicht in der Lage bist, AES korrekt zu implementieren, wirst du wohl kaum in der Lage sein, deine selbst erfundene Verschlüsselung analysieren zu können.

[MitjaStachowiak]

Nun, Hartblead beweist, dass auch OpenSSL nicht unfehlbar ist. Vor allem gibt es gewisse Fettnäpfchen, in die man da tappen kann. Zumindest bei den asymetrischen Verschlüsselungen. Identitätsprüfung des Zertifikates vergessen? Zertifikat abgelaufen? Private-Key bei einem Angriff auf den Server durch eine Sicherheitslücke in einer anderen Software gestohlen? Zufallsgenerator für Erstellen des Zertifikates korrumpiert?

Wenn man sich aber wirklich selber Gedanken um die Verschlüsselung macht, fallen einem viele Möglichkeiten für einen Angriff auf. Dann muss man entscheiden, ob man eine Lösung dafür einprogrammiert, oder ob die Daten doch nicht so geheim sind, als dass sich das lohnen würde. Aber wenn man mögliche Sicherheitslücken seiner Software kennt, wird man auch nicht leichtsinnig beliebig vertrauliche Informationen damit übertragen...

Natürlich setze ich mal vorraus, dass man für die eigene Verschlüsselung auch einen sicheren Zufallsgenerator verwendet, so, wie ich das oben beschrieben habe.

[Christian]

Meine Erfahrung zeigt das man in dem Bereich oft Betriebsblind ist. Du fühlst dich extrem sicher weil du aus deiner sicht ne supertolle Verschlüsselung gebaut hast. Und aushebeln kann man das ganze dann weil du vergessen hast auf irgend ne API deine Verschlüsselung anzuwenden. Da gibts so viel was man falschmachen kann. Bewirf dein Programm doch einafch mal mit Zuffalsdaten in dei Eingabefelder. Allein das brint schon 95% aller Programme zum aufgeben. Obwohl das eines der ersten Dinge ist die man beim Programmieren lernt.

Es ist definitiv ne gute idee Code so offen wie möglich zu halten. Das heisst nicht das nicht alle die sich das anschaun betriebsblind sind. Die Warscheinlichkeit das man aber als einzelner bei Closed Source was übersieht ist um ein vielfaches größer.

[MitjaStachowiak]

Naja, aber wenn die Struktur des Programmes nicht sicher ist, weil ich die Vertschlüsselung gar nicht auf alles angewendet wird, dann hilft auch eine Profi-Krypto-Komponente nicht.

Und offene Codes sind durchaus ein Risiko. Dann kann ein Angreifer ja in aller Ruhe meinen Code auf Fehler untersuchen. Ich habe seit ich programmiere noch NIE ein Bugreport erhalten. Und ich würde nicht sagen, dass meine Programme immer bugfrei sind Die einzigen, die von offenen Codes profitieren, sind meiner Meinung nach die Hacker. Deswegen veröffentliche ich den sicherheitsrelevanten Kern meiner Codes nicht mehr.

[Christian]

Naja bist ja nun auch nicht der grösste OSS Author
Bei Programmen mit Relevanz schauen schon ab und an mal Leute in den Code. Bei Delphi hätt ich nie die Möglichkeit. Bei Lazarus fällt zwar von meiner Siete auch nur ein patch pro Jahr raus aber ...

Ich weiss nicht wie ich das am anschaulichten erklären soll. Es ist oft erstaunlich einfach Systeme zu brechen. Und das wird umso einfacher umso weniger Leute sich gedanken drum gemacht haben. Nimm mal Fenster. Geh einfach mal zur Polizei und lass dir zeigen wie einfach es ist ein Standrdfenster aufzumachen. Mit Schlössern das selbe. Sicherheitsmaßnahmen können nur gut sein wenn möglichst viele Leute sie geprüft haben. Bei Kryptografie wird genau das gemacht. Jeder aktuelle Verschlüsselungsalgorythmus der etas relevanz hat ist offen.
Wenn an deiner Aussage irgendwas sinnvolles wäre, würden nicht alle aber auch alle Sicherheitsforscher das selbe machen und ihre algorythmen breit streuen.

[MitjaStachowiak]

Bei Projekten ab einer gewissen Größe ist es sicher weise, die Codes zu veröffentlichen.

Bei meinem aktuellen Projekt geht es auch weniger um die Verschlüsselung selbst - denn das ist online und wenn es verschlüsselt sein soll, bleibt mir nichts anderes übrig, als HTTPS zu verwenden, aber das erzeugt laufende Unkosten bei meinen Kunden. Deswegen beobachtet man selbst bei Webauftritten mit professionellen CMSs oft ein Login über normales HTTP. Und die Benutzer davon haben keine Ahnung von dieser Sicherheitslücke und loggen sich auch mal auswärts über offene WLAN ein und schon isses gehackt

Jedenfalls ist mein Projekt nicht groß genug, als dass ich mit sicherheitsrelevanten Bugreports rechnen könnte. Daher lieber "geheime" Codes.

[Christian]

Ne genau deswegen sollte man einfach gut abgehangene Algorythmen zur Verschlüsselung benutzen. Was für Umkosten soll den HTTPS erzeugen ? Und um welches projekt gehts ?

[MitjaStachowiak]

Nun, ich arbeite aktuell an meinem eigenen CMS (http://www.mitjastachowiak.de/?/Projects/Backend/). Ist im Moment ohne Lazarus. Aber wenn man auf einer Website einen halbwegs sicheren Login will, muss man HTTPS benutzen. Okok, inzwischen kann man auch mit JavaScript RSA-Verschlüsselung betreiben, aber ... nee, das ist echt ätzend. Vor allem, weil das JS ja vorher vom Server geladen wird - zumindest wer den Datenverkehr manipulieren kann, kann so ganz leicht ein korrumpiertes Script einschleusen. Da gibt es wie gesagt nur HTTPS.

Und ein Zertifikat kostet nun mal mindestens 1€/Monat. Meine Kunden zahlen ganz bestimmt kein Hostingangebot, wo ein Wildcard-Zertifikat dabei ist oder man ein eigenes Zertifikat benutzen kann

Die Sicherheit dieses Systems hängt bei mir von ... naja, vielleicht 400 Zeilen Perl-Code ab. Es gibt dann noch die Möglichkeit, den verschiedenen Benutzern unterschiedliche Berechtigungen zu geben. Ob diese umgangen werden können, ist noch mal eine andere Frage.

[Christian]

Zertifikate kosten nix, nur wenn man unbedingt ne ca braucht kostets was. Und CAś haben sich in der Vergangenheit nicht unbedingt als Sicherheitsvorteil erwiesen.

[mschnell]

Und ein Zertifikat kostet nun mal mindestens 1€/Monat. Meine Kunden zahlen ganz bestimmt kein Hostingangebot, wo ein Wildcard-Zertifikat dabei ist oder man ein eigenes Zertifikat benutzen kann

Du brauchst doch nicht unbedingt einen externen Zertifizierungs-Server-Dienst.

Ich verwende z.B. "Dirvish" (also im End-Effekt den Standard-Linux-Befehl "rsync"), um täglich ein differenzielles Backup der Daten auf einem gemieteten Server auf meinen lokalen Server zu ziehen. Dazu macht mein Server Script-gesteuert automatisch ein SSH-Login (unter Verwendung der Verschlüsselung als "Passwort") und baut eine verschlüsselte Verbindung auf. Über diesen SSH-Tunnel läuft dann der Daten-Transfer.

Dazu musste ich nur mit ssh-keygen ein Schlüssel-Paar erzeugen und den "public"- und "privat" Key an den richtigen Stellen auf den beiden Rechnern ablegen. Das ist im Linux Standard. (-> z.B. http://www.schlittermann.de/doc/ssh.html )

Vermutlich kannst Du auch einen (kostenlosen) Zertifizierungs-Dienst auf einem eigenen Server anbieten. Ich vermute die Software dazu ist für Linux auch frei verfügbar.

-Michael