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