Verschlüsselung erkennen

[Luckie]

Mein FileCrypter arbeitet zur Zeit noch mit einer mir unbekannten RSA Verschlüsselung. Durch Hagen bekomme ich da ein immer unguteres Gefühl bei.

In der nächsten Version soll der Crypter in seinen Features noch weiter aufgepeppt werden: Mehrer Dateien gleichzeitig, Verschlüsselung von reinen Zeichenketten, verschiedene Verfahren zur Auswahl, ...

Jetzt fgände ich es sehr komfortable, wenn man eine Datei läd, dass das Programmm automatisch erkennt mit was es verschlüssel wurde, um dann gleich die passenden Entschlüsselung anzubieten. Einen eigenen header will ich nicht schreiben, damit man auch mit anderen Programme wieder entschlüssel kann.
Jetzt meine Frage: Ist es möglich zu erkennen mit was für einen Algorithmus eine datei verschlüsselt wurde?

[negaH]

Nein, allerhöchsten kann man den Typ der Verschlüsselung erahnen. Also zb. nicht verschlüsselt <> verschlüsselt, oder Stromverschlüsselungen = wie Zufallswerte, Blockverschlüsselungen ohne Zufalls InitVector hat da mehr Muster zu erkennen.

D.h. durch statistische Analyse kann man ermitteln wie stark die datei zufällig erscheint. Eine Stromverschlüsselung wie RC4 usw. wird immer stark nach Zufall aussehen und sich nur minimal komprimieren lassen, ca. 1-2%. Eine Blockverschlüsselung ohne Zufalls-IV wird das mehr Muster haben, und lässt sich ca. 10-15% komprimieren. D.h. aber nicht das eine Blockverschlüsselung weniger stakr als Stromverschlüsselungen sind, eher das Gegenteil.

Da du aber erwähntest das du KEINEN Header zur datei anlegst sage ich dir jetzt schon das dein Crypter unsicher ist :)
Attacken auf Dateien mit bekanntem Inhalt und gleichem Paswort sollten per Differentieller Kryptoanalyse beim Crypter möglich sein. Willst du es sicher machen dann musst du immer noch zusaätzliche Daten zur Datei speichern, sprich einen Header. Dieser Header enthält z.b. auch verschölüsselte Zufallsdaten damit man eben keine Known Plaintext Attacken mehr machen kann. Zusätzlich kommen noch einige andere Werte hinzu.

Achso, wenn du wie du sagts per RSA arbeitest dann frage ich mich wie das überhaupt geht, Daten zu verschlüsseln ohne den zufälligen Sessionkey mit dem die Daten verschlüsselt wurden, zu speichern ??


Gruß Hagen

[Chewie]

Du kannst ja den Header auch in eine seperate Datei speichern, um kompatibel zu bleiben.

[Luckie]

Dann hat sich das erledigt. Und ich werde wohl einen eigenen Header schreiben nur hab eich keinen Plan, wie ich das praktisch in Delphi umsetzten soll. Mal sehen.

Zitat:

Zitat von negaH

Achso, wenn du wie du sagts per RSA arbeitest dann frage ich mich wie das überhaupt geht, Daten zu verschlüsseln ohne den zufälligen Sessionkey mit dem die Daten verschlüsselt wurden, zu speichern ??

Das wird die DLL erledigen. Ich habe die von einem russischen Mathematikprofessor. Ich habe dazu nur die C-Header übersetzt. Source usw. ist unbekannt, wie ich schon sagte. Mittlerweile hat er sie auch wieder von seiner Seite genommen. :?

[negaH]

Kannst du mir erkären wie dein Verfahren gearbeitet hat ?
Ich nehme mal an als erstes musste man einen RSA Schlüsselpaar erzeugen. Dieses wird irgendwo gespeichert, wobei zum Schutz ein Passwort abgefragt wurde. Will man nun eine Datei verschlüsseln so musste dieser RSA Schlüssel ausgewählt werden und die Datei wurde verschlüsselt. Um sie wieder zu entschlüsseln musste das Passwort zum passenden RSA Schlüssel eingegeben werden und dann konnte die datei entschlüsselt werden. Stimmt das in etwa so ??
Oder musstest du zur Verschlüsselung ein Passwort eingeben, das zur Entschlüsselung wiederum eingegeben werden musste ??

Um Dateien zu ver/entschlüsseln braucht man normalerweise keine public Key Verfahren. Diese sind immer nur dann sinnvoll wenn man entweder Daten verschicken möchte die nur durch den Empfänger lesbar sein sollen ohne das man das Passwort des Empfängers kennen muß. Oder aber man will Daten vor Verfälschungen sichern, also eine digitale Unterschrift über die Daten erzeugen. Oder man will eine sichere Datenverbindung mit Verschlüsselung initieren. Dies sind die drei wichtigsten Einsatzgebiete von asymmetrischer Verschlüsselung. Es gäbe noch das Aufteilen von Geheimissen = secret sharing, aber das wird selten angewendet.

[Luckie]

Zitat:

Zitat von negaH

Oder musstest du zur Verschlüsselung ein Passwort eingeben, das zur Entschlüsselung wiederum eingegeben werden musste ??

So ist es. Falls du mehr wissen willst, lad dir von miner HP den CrypterWrapper runter, da ist alles bei, was ich von der DLL haben und was der Professor preisgegeben hatte.

[negaH]

Deutet darauf hin das überhaupt nicht per RSA verschlüsselt wurde, sondern ein symmetrisches Verfahren benutzt wurde.

Ich schau mir mal deine HP an.

Gruß Hagen

[negaH]

Diese DLL hast du benutzt ?? Also ich will ja nicht kritsieren aber der Autor der DLL sagt nichts darüber aus wie groß eigentlich die Schlüsselgröße des verwendetet RSA Algorithmus ist. Im Gegensatz, er meint das 16000 verschiedene vorberechnete RSA Schlüssel eine gute Idee sind, das ist ja idiotisch.

Damit RSA sicher ist MÜSSEN per Zufall 2 Primzahlen erzeugt werden die mindestens 512 Bit groß sind, d.h. die beiden Zahlen liegen im Wertebereich 2^512. Im Gegensatz zu 16.000 vorgefertigten festen RSA Schlüsseln benötigt man mit solchen richtigen RSA Schlüsseln weit über 2^512 Versuche um den EINEN richtigen zu knacken.
Das "langwierige" bei RSA ist die Schlüsselerzeugung. Mit meiner Library dauert das im Durchschitt 500 Millisekunden.
Man benötigt nun keine Beschleunigung mehr da im Durchschitt das Verschlüsseln einer normalen Nachricht ca. 5 Millisekunden dauert. Man nutzt nämlich RSA als hybrides System. Indem man einen Zufalls-Sessionkey erzeugt. Mit diesem und einer guten Verschlüsselungsfunktion wie AES-Rijndael, Blowfish, Twofish, IDEA etc.pp wird die Datei verschlüsselt. Man sollte ca. 16Mb pro Sekunde damit lässig schaffen. So, nun wird mit RSA der ca. 256 Bit lange Zufalls-Sessionkey verschlüsselt, das geht fix. Dieser Wert wird als Header an die verschlüsselte Datei rangehangen. D.h. will man eine Datei mit einem PK Verfahren verschlüsseln benötigt man KEINE Passwortabfrage mehr. denn man verschlüsselt mit dem öffentlichen RSA Schlüssel den Zufallssessionkey. Erst zur Entschlüsselung benötigt man den privaten RSA Schlüssel der natürlich passwortgeschützt seine sollte (kann aber auch auf'ner SmartCard liegen).

Die ganzen netten Tricks die dieser Mathe Professor beschreibt sind absolut unnötig und nicht sehr vertrauens erweckend. Ich habe mit Gespanntheit das PDF durchgeackert weil ich wissen wollte wo und wie der Russe beschreibt mit welchen Datengrößen er denn nun arbeitet. Einige math. Beispiele wurden aufgezeigt die im Integerbereich = 2^32 lagen, was aber lächerlich unsicher für echtes RSA wäre.

Sorry, Luckie, da biste aber jemandem auf den Leim gegangen :)

Es geht aber noch weiter. Wie zum Teufel soll nun das verwendete Passwort übers Netz sicher übertragen werden ? Jeder Lauscher hat somit leichtes Spiel, da die Methode der DLL die Vorteile der public Key Verschlüsselung vernichtet und ein simples symmetrisches Verfahren daraus macht. Ich habe ja schon viel gesehen... aber man lernt nie aus.

Angenommen er nutzt sicheren RSA mit 16.000 fertigen Schlüsseln dann hätten wir (2*512Bit + 32Bit) * 16.000 / 8 = 2.112.000 Bytes ~ 2 Mb an Schlüsseltabellen nötig. Das passt ja garnicht in dessen DLL rein, huch :) Sie sollten nämlich per Zufall erzeugt worden sein, und sowas ließe sich sehr schlecht komprimieren, es sei denn er hat auch gleich noch eine perfekte verlustfreie Komprimierung erfunden die mit 3000% Komprimierungsrate von Zufallsdaten aufwarten kann.

Meine Vermutung ist er nutzt 32 oder 64 Bit RSA was absolut lächerlich wäre. Man hat mittlerweile 512Bit RSA geknackt, ok nicht massenhaft aber 512Bit ist ne riesige Menge mehr an Holz als 64Bit.


Gruß Hagen

[Luckie]

Zitat:

Zitat von negaH

Sorry, Luckie, da biste aber jemandem auf den Leim gegangen :)

Öhm, ja. Hättest du das nicht etwas leiser sagen können? :?

Wo kann ich das DEC runterladen für D6 und ist es Freeware für Freeware-Programme? Ich habe nur die Version 3.0 für D5 bei www.vclcomponents.com gefunden.

[Motzi]

@Luckie: ich kenn mich zwar bei weitem nicht so gut aus wie Hagen, aber ich hab damals bei deiner ersten Veröffentlichung auch große Bedenken an dieser Dll geäußert..! :roll: ;)

[Assarbad]

Jetzt aber still, Motzi ;)

Ganz leise ...

Hab ihm auch vorher gesagt, daß ich in Sachen Kryptographie nur auf erprobte OpenSource Implementationen vertrauen würde - als er mir den Wrapper zeigte. Aber ich sagte auch, daß es für Zwecke wo man nicht den Geheimdienst fürchten muß sicher reicht. Sehe ich immernoch so!

... ist aber unschön das von Hagen jetzt so detailliert auf die Stulle geschmiert zu kriegen ;)

:mrgreen: :mrgreen: :mrgreen: :mrgreen: :mrgreen: :mrgreen: :mrgreen: :mrgreen: :mrgreen: :mrgreen:

[negaH]

DEC Part I gibts nur als diese Version 3.0, die aber mit nur 3 Änderungen auch auf D6,D7 läuft. Einfach in Unit DECReg.pas in der Uses Klausel "DsgnIntf" ändern "DesignIntf, DesignEditors". Den zweiten Fehler in Checksum.pas (falls vorhanden) kannste selber ändern, Borland's inline Assembler ist nun pingeliker.

Aber das nützt dir alles nichts, da dieser Part keine asymmetrische/Public Key Verschlüsselungen enthält.
Ich habe leider nicht mehr die großen Zeitfetzen um alles am DEC komplett fertigzustellen. Meine derzeitige Idee ist es eine DLL zu entwicklen die Elliptische Kurven + RSA Algorithmen enthält. Also ein absolut guter Ersatz für RSA. Hier fängt aber das Problem so richtig an, denn jede vernünftige PKC muss auch ein vernünftiges Schlüssel-/Signature Management enthalten. Also 1000mal mehr Überbau über den eigentlichen mathematischen Code, bäh und das hasse ich :)

Gruß Hagen

[negaH]

Sorry, das war echt gemein von mir, oh Achtung da kommt ein Kartoon :=)

Ich könnte hier zaghaft einen leisen Pieep machen und anbieten gemeinsam eine eigene DLL zu entwicklen. Man soll ja nicht anderen ihre Arbeit kritisieren wenn man's nicht besser kann. Den kompletten math./kryptographischen Teil würde ich dann beisteueren. Wie gesagt das Keýmanagement IST das eigentliche problem.

Gruß hagen

[Luckie]

Ich bin jetzt erstmal auf BlowFish, DEC und Rijndael zur Auswahl umgestiegen. Benutzen tue ich diese Komponenten: www.crypto-central.com Was hältst du davon? Recht einfach zu Handhaben, was mir nur fehlt ist das Ereignis OnProgress. Ich hätte nämlich gerne eine Rückmelung an den Benutzer, wenn es mal wieder länger dauert. :wink:

[negaH]

DCPCrypt ist nach dem DEC die dritt-beste freie Cryptolib für delphi :) was soll ich anderes sagen ?? Die zweitbeste Lib ist das DEC und die allerbeste Library für Delphi ist mein inoffizielles DEC.

Ich will ehrlich zu dir sein, extrahiere den reinen Algorithmus und wende diesen an. Beim DEC Part I zB. hat mich am meisten gestört das es eine enorm umfangreiche Bibliothek ist, einfach zuviel des Guten. Meine eigene version vom DEC integriert nur eine CRC unit, eine Unit mit SHA1 und MD4 als Hash's und AES-Rindael + Polymorph PMC + SCOP als verschlüsselungen, und einen sicheren Zufallsgeenrator und meine Mini-LZH Komprimierung. Meistens nutze ich nur SHA1 + AES Rijndael + LZH.

Natürlich bin ich der Meinung das DEC's Klassenkonzept echt elegant ist :):):):):)

Aber am wichtigsten ist es zu wissen WAS man tut. Da du gerade am basteln deines Headers bist, der entscheidend verantwortlich für die spätere Sicherheit ist, biete ich dir an ein paar Tipps&Tricks zu veraten.

Gruß Hagen

[Luckie]

Zitat:

Zitat von negaH

Aber am wichtigsten ist es zu wissen WAS man tut. Da du gerade am basteln deines Headers bist, der entscheidend verantwortlich für die spätere Sicherheit ist, biete ich dir an ein paar Tipps&Tricks zu veraten.

Na dann mal los...

[negaH]

Ok ich versuche mal einen kurzen Abriß zu geben.

Was benötigen wir:
1.) eine Hashfunktion wie SHA1
2.) einen symmetrischen Cipher wie AES Rijndael
3.) einen Zufallsgenerator wie YARROW
4.) einen Komprimierungsalgo. eventuell

Man will eine Datei verschlüsseln, hat das Passwort und einen Dateisourcestream und Outputstream.

Zuerst erzeugen wir mir dem Randomgenerator YARROW einen Salt. Dieser Salt dient dazu das Password zu sichern und es zufällig zu machen. Desweiteren dient er zu randomisierung des Verschlüsselungsprozesses.
Nachfolgend NUR ein Pseudocode um besser den Algo. zu zeigen.

Delphi-Quellcode:

type
  THeader = packed record
    Ident: Cardinal; // identifiziert das Dateiformat
    Salt: array[0..19] of Byte; // randomisiert das Passwort
    SessionKey: array[0..19] of Byte; // zur überprüfung des Passwortes
  end;

procedure Encrypt(const Source,Dest: TStream; const Password: String);
var
  Header: THeader;
begin
// initialisiere Header
  Header.Ident := $12345678;

// erzeuge Salt, ein "Zufallswert" der NICHT zurückberechnenbar ist
  RunYarrow(Header.Salt, SizeOf(Header.Salt));

// erzeuge Sessionkey
  Header.SessionKey := RunSHA1(Header.Salt + Password);
  
  InitEncrypt(Header.SessionKey);
  EncryptCBC(Header.SessionKey);
  Dest.Write(Header);
  EncryptCBC(Source, Dest);  
  EncryptCBCDone(Dest);

{ man erzeugt Zufallsdaten, diese + Password werden durch eine
  Hashfunktion in ein SessionKey umgewandelt mit dem Verschlüsselt wird.
  Der SessionKey wird mit sich selber verschlüsselt.
  Der Header wird in Dest geschrieben.
  Die Source wird nach Dest verschlüsselt. 
  WICHTIG! dabei ist das Encrypt(SessionKey) + Encrypt(Source, Dest)
  keine voneinander getrennten Verschlüsselungen sind. Es werden also
  SessionKey + Source als ein zusammengehöriger Datenstrom behandelt.
  
  D.h. Man kann SessionKey nur entschlüsseln wenn man den korrekten
  Sessionkey kennt. Wird entschlüsselt muß aus dem gespeichert Salt +
  Password der gleiche SessionKey erzeugt werden, dann wird
  Header.SessionKey entschlüsselt und mit dem aktuellen Schlüssel
  verglichen. Sollten sie ungleich sein so ist das Entschlüsselungs-
  passwort falsch. Da der Salt aus dem Passwort einen Zufäligen SessionKey
  erzeugt MUSS demzufolge die Verschlüsselung auch zufällig sein.
  Da der Header.SessionKey als erster Block verschlüsselt wird wird
  auch der Schlüsselstrom zufällig.
}
end;

So das ertmal zum Prinizp. Jetzt stellst du erstmal mehr Fragen und dann sehen wir mal ob ich eine kleine Unit baue :)

Gruß Hagen