|
File-Crypter v1.0 [BETA]
Bitte intensiv testen. Danke
Das Programm ermöglicht es Dateien sicher zu ver- und entschlüsseln. Features:
Link:  File-Crypter |
Hi,
hab mir mal dein Prog ein bisschen angeschaut.. das ver- und entschlüsseln funzt bestens, aber - es verschlüsselt mit RSA? Ich hab zwar gesehen, dass die DLL ein paar Funktionen exportiert die anscheinend mit RSA arbeiten (was is das eigentlich für eine DLL?) aber in deinem Prog is nix von public oder private Schlüsseln zu sehen - ist das Absicht? Und sofern es wirklich auf RSA arbeitet.. wie berechnest du von dem kleinen Passwort kollisionsfrei ein mind. 512Bit langes Schlüsselpaar (RSA mit Schlüsseln < 512Bit ist nicht mehr sicher genug..)? |
Liste der Anhänge anzeigen (Anzahl: 1)
Ich rechne da gar nichts. Ich habe eigentlich nur einen Delphi-Wrapper drumrum geschrieben (wenn es soweit ist wird er veröffentlicht, ich dachte nur bevor dann rauzs kommt, dass da was nicht funktioniert, und ich alles in die Tonne treten kann, lasse ich schon mal testen).
Wenn ich die Doku richtig verstanden habe, wird da ein Zufallsschlüssel genommen. Alos wenn man die selbe Datei zweimal verschlüsselt, kommt immer was anderes raus. Wie das dann wieder entschlüsselt werden kann weiß ich nicht. Ihm Moment ist die DLL für mich noch eine Blackbox. Ich muß mich selbst erstmal durch die Doku kämpfen. Mit den fachbegriffen in englisch nicht so einfach. Ich häng mal die Doku der DLL dran. Mit lib-Datei, Header, VB-Modul Datei und Doku im PDF-Format. |
Thx! Ich schaus mir mal an..
|
Kannst dann ja mal erklären wie das funktioniert.
|
Aha!!! RSA!! Das freut mich aber. Frage: Wie speicherst du diese riesigen Zahlenmengen der beiden Schlüssel n und e?
Habe dein Programm getest und mir sind keine Fehler aufgefallen (außer die bereits genannten). |
Ich muß mich selber zitieren:
Zitat:
|
Hi,
gut werde ich mir mal ansehen. Ich habe den RSA auf TP mit einer Spezialunit geschrieben (die großteils nur Probleme machte). Und nun wollte ich den auf Delphi umschreiben. Das Problem sind halt die riesen Zahlen... Chris |
Also nachdem ich mir mal die PDF-Datei teilweise durchgelesen, teilweise überflogen und die Webseite angeschaut habe, muss ich leider sagen, dass ich nicht wirklich von der Sicherheit der DLL überzeugt bin! Es gibt nirgends Anhaltspunkte mit was für Zahlen die Dll arbeitet (ob mit einer arithmetischen Bibliothek für große Zahlen oder den C Standard-Typen) und der Source der Dll ist schließlich nicht öffentlich zugängig (das ist immer ein Punkt, bei dem man bei Krypto-Produkten aufpassen sollte!)
Und die Aussage: "The encryption method is VERY simple, but it is a trap-door for crackers :)" ist für mich endgültig Grund genug diese Dll nicht in sicherheitsrelevanter Software einzusetzen! Ich an deiner Stelle würde mir den Algo selbst implementieren (auch wenn es wesentlich mehr Arbeit ist)! Als Bibliothek zum Rechnen mit großen Zahlen kann ich dir das GNU Projekt GMP empfehlen (Link dazu hab ich schonmal hier im Forum gepostet), welches nach meinem Wissensstand die beste und schnellste Bibliothek ist. Und was den Algorithmus selbst betrifft da gibts ja genug Literatur dazu.. Ich hab eine Fachbereichsarbeit über Public-Key-Kryptographie speziell RSA geschrieben, wen es interessiert hier der Link - http://www.x-spy.net/personal/FBA-V1.0.PDF |
Die GNU(PP)-Prjekte sind zwar sehr sicher, aber der RSA bleibt da doch noch etwas vorraus. Ich weiß zwar nicht wie die DLL aussieht, aber eines kann ich dir sagen: RSA ist sicher!
Chris |
Ich kann dazu leider wenig sagen, ich habe mich damit noch nicht richtig beschäfftigt.
|
Zitat:
Ich hab nie gesagt, dass RSA unsicher ist! Sofern man sich an alle Sicherheitsmaßnahmen hält ist RSA sicher (zumindest bis jetzt)... es kommt allerdings sehr auf die Implementierung des Algorithmus an.. der Algo kann zwar mathematisch vollkommen korrekt sein, aber wenn er nur mit den Standard-C Variablentypen mit max. 64Bit arbeitet, dann ist das definitiv nicht sicher, da 64Bit lange Zahlen sehr schnell faktorisiert werden können! Was das GNU Projekt betrifft das ich erwähnt habe.. das ist eine Bibliothek zum Rechnen mit großen Zahlen - damit kann man sich den RSA Algorithmus selbst implementieren, und schließlich weiß man vom eigenen Code immer noch am besten was er macht! :wink: Zitat:
Ab sofern du mal beabsichtigst den Algorithmus selbst zu implementieren (mit einer OpenSource Bibliothek wie zb GMP) so würd ich mich bei Bedarf gern daran beteiligen! Hatte auch schon vor sowas selbst zu machen... |
Hallo Leute,
ich poste einfach mal zur Information, wie der RSA-Algo ungefähr funktioniert: --- Man erstelle drei zufällig erzeugte (je weniger Pseudo-Zufall, umso besser) Primzahlen z1, z2 und z3, für die gilt: die Schnittmenge von T(z3) und T((z1 -1)(z2 - 1)) ist leer (T() steht für die Teilermenge). Als nächstes bilde man ein Produkt p = z1 * z2. Jetzt kommt die Erstellung des öffentlichen Schlüssels, mit dem nur verschlüsselt werden kann. Der öffentliche Schlüssel besteht aus den Zahlen z3 und p. Für die Klarziffer K und die verschlüsselte Botschaft B gilt nun: B = (K ^ z3) mod p. Der geheime Schlüssel, mit dem entschlüsselt wird, besteht aus z1, z2 (und damit auch p) und z3. es wird nun ein geheimer Exponent g berechnet, für den gilt: G = 1 / z3 mod (z1 - 1)(z2 - 1). Nun kann min die Klarziffer K wie folgt berechnen K = (B ^ g) mod p. Ein Beispiel: Es sei z1 = 13, z2 = 19 und z3 = 5. Daher gilt p = 247. der geheime Exponent g ist g = 0,2 mod 216 = 173. Will man nun die Klarzffer K = 12 verschlüsseln, so erhält man B = (K ^ z3) mod p = (12 ^ 5) mod 247 = 103. Mit dem geheimen Exponenten g ann man nun wieder K berechnen: K = (B ^ g) mod P = (103 ^ 173) mod 247 = 12. --- Normalerweise wird RSA benutzt, um nachrichten zu verschlüsseln. Der Sender besitzt den öffentlichen Schlüssel de Empfängers, verschlüsselt die Nachricht damit und übergibt sie an den Empfänger. Der kann die Nachricht dann mit dem geheimen Schlüssel wieder entschlüsseln. Ein Cracker hat dann z3 und p aus dem öffenlichen schlüssel, braucht aber für den geheimen Exponenten g noch z1 und z2. Also muss er alle Möglichkeiten für z1 und z2 durchprobieren (er kennt schließlich das Produkt der beiden, p). Da diese beiden Zahlen sich normalerweise in der Größenordnung 10^200 aufhalten, dauert das zumindest mit heutigen Systemen Jahrhunderte. Wenn jetzt diese DLL aus ein paar Zeichen Passwort einen Schlüssel generiert, dann kann es passieren, dass mehrere Passwörter den gleichen Schlüssel erzeugen, sehr unpraktisch. Außerdem, und das ist es was Motzi meint, kann man bei Zahlen, die gerade mal 64 Bit groß sind, sich also in der Größenordnung 10^19 befinden, in erheblich kürzerer Zeit als Jahrhunderte faktorisieren, damit tendiert die Sicherheit schon sehr gegen null. Was mich auch verwundert, ist: wo werden die Schlüssel gespeichert? Wenn das in der verschlüsselten Datei selber geschieht, dann liefert man dem Cracker sämtliche Instrumente auf dem Silbertablett, er wird danken. Damit wäre die Sicherheit genau null. MfG, d3g PS. Wenn man den Algorithmus nachbauen will, wird man über die Modulo-Operation mit Fließkommazahlen stolpern. Die Standard-C-Bibliotheken beinhalten eine Funktion fmod(), die das beherrscht, leider habe ich sowas für Pascal noch nicht gesehen :-(. |
Mal zum RSA: Ich kenne das etwas einfacher:
----- Man braucht 2 Primzahlen p und q. Diese Multipliziert man miteinander. Das Produkt ist der "Generalschlüssel" n. Nun braucht man einen öffentlichen und einen privaten Schlüssel: d (decrypt) und e (encrypt). Sie kann man erzeugen durch folgende Regel:
Code:
(Hierbei ist das = ein = mit 3 Strichen)
e * d = 1 mod phi(n)
Dann hat man einen Text, den man als Zahlen darstellt (m). m muss kleiner sein als n. Um einen Text zu verschlüsseln macht man:
Code:
Das ist dann meinetwegen C das ganze dann entschlüsseln mit
m^d (mod n)
Code:
-----
c^e (mod n)
Den Beweis hatte ich auch irgendwann mal. Chris PS: Werde auf meiner Website bald mal eine Doku zum RSA machen... |
Zitat:
Chris |
Hi Luckie!
Ich hab mir dein Programm mal angesehen. Find ich gut. Wie du am anfang schon geschrieben hast, kommt ja noch ein Abbrechen Button und ein Fortschrittszeiger hinzu. Eine Sache ist mir aufgefallen. Wenn man eine Datei verschlüsselt, dann wird quasi eine Kopie vom Original erstellt und diese dann verschlüsselt. Wenn mann dan genau diese Datei wieder entschlüsselt, dann wird nochmals eine Kopie erstellt. Die entschlüsselte Datei muss mann dann immer Umbenennen. Wäre es nicht sinnvoller die Original-Datei zu überschreiben beim Verschlüsseln und auch beim Entschlüsseln, so dass nur 1e Datei existiert? |
Hi Chakotay,
die Modulo-Operation ist definiert als n(mod m) = m * frac(n / m) und kann sehr wohl mit Fließkommazahlen operieren und das ist auch für RSA nötig: Zitat:
MfG, d3g |
Liste der Anhänge anzeigen (Anzahl: 1)
Irgendwie is mein Link zur Fachbereichsarbeit anscheindend nicht wirklich beachtet worden (liegt vielleicht auch daran, dass der Server zur Zeit ein paar Probleme hat).
Jedenfalls.. der Delphi-Operator mod funktioniert nur mit den Delphi-Standard Typen und ist daher für eine Implementation mit Zahlen > 10^200 gänzlich ungeeignet! Außerdem arbeitet RSA mit ganzen Zahlen! Hier die entsprechenden Kapitel aus meiner Arbeit: 5.2 Mathematik Die Sicherheit von RSA beruht auf der Schwierigkeit, große Zahlen zu faktorisieren (siehe auch Abschnitt 3.1.2.2). Öffentlicher und privater Schlüssel hängen von einem Paar großer Primzahlen ab (100 bis 200 Stellen und mehr). Man vermutet, dass die Wiederherstellung des Klartextes aus dem öffentlichen Schlüssel und dem Chiffretext äquivalent zur Faktorisierung des Produkts der beiden Primzahlen ist. 5.2.1 Schlüsselerzeugung Um die beiden Schlüssel zu erzeugen, wählt man zufällig zwei große Primzahlen p und q.(Es gibt einige Kriterien, die bei der Wahl der Zahlen beachtetet werden sollten ? siehe dazu 8.1) Jetzt berechnet man:
Code:
Anschließend wählt man den zufälligen Chiffrierschlüssel e so, dass gilt:
n = p*q
phi = (p-1)*(q-1)
Code:
Mit Hilfe des erweiterten Euklidischen Algorithmus (siehe Anhang 3) berechnet man schließlich den Dechiffrierschlüssel d so, dass gilt:
1 < e < phi
ggT(e, phi) = 1
Code:
Oder anders ausgedrückt:
1 < d < phi
e*d = 1 (mod phi)
Code:
Die beiden Zahlen e und d werden Encryption Exponent bzw. Decryption Exponent genannt, während n den Modulus bildet.
d = e^-1 (mod phi)
Die beiden Paare <n, e> und <n, d> bilden den öffentlichen und den privaten Schlüssel. Das Aussehen der mathematischen Formeln musste leider ein bisschen leiden.. Der Rest wäre zu aufwendig hier in BBCode umzuformatieren, aber wer Lust hat kann sich ja meine FBA zu Gemüte führen.. Edit: ich hab jetzt die FBA im PDF Format an das Posting angehängt... |
@m-werk: Das resultiert noch aus der Testphase, da wollte ich es tunlichst vermeiden original Dateien zu überschreiben, weder beim verschlüsseln, noch beim entschlüsseln. Ich bin noch am überlegen, wie ich das löse. Eventuell mit eine Vorsilbe, dann kann man sie normal öffnen.
Um noch mal auf die Sicherheit zu sprechen zu kommen. Auch wenn die DLL nur mit den standard C Datentypen arbeitet und die ganz ausreizt - wie lange wird es wohl mit einem privat PC dauern, die Verschlüsselung zu knacken? Alles was über 1 bis 3 Wochen liegt, dürfte für Daten, die nicht unbedingt so sicherheitsrelevant, reichen. |
Hi,
@ Motzi: Vielleicht liegt das einfach nur daran, dass keine weiß, wo deine Facharbeit zu finden ist... @ Motzi (2): Das was du da zitierst, ist ja genau das, was ich geschrieben habe...! Chris |
Zitat:
Zitat:
@Luckie: naja, der maximale C-Standard Typ würde 64Bit entsprechen.. wie lang es dauert eine 64Bit Zahl zu faktorisieren weiß ich jetzt nicht, aber ich werd mal schaun ob ich was finde.. |
Hallo Motzi,
Zitat:
Was die einzelnen Algorithmen angeht, bin ich mir ziemlich sicher, dass sie sich gleichen, nur dass "meiner" eine etwas andere Methode hat, die drei Anfangszahlen zu ermitteln. So ist deine Aussage ggT(e, phi) = 1 äquvalent zu meiner, die besagt, dass diese Zahlen keinen gemeinsamen Teiler haben (außer 1 natürlich). MfG, d3g |
Hm.. Irgendwie hab ich das Gefühl wir meinen eh alle dasselbe aber reden (oder schreiben) komplett aneinander vorbei! :wink:
Zum Modulo.. das ganze is einfach nur eine Sache der Umformung (ich verweise wiedermal auf mein Fachbereichsarbeit :wink:) - wer sich meine Arbeit angeschaut hat wird sicher gesehen haben, dass ein Teil der Arbeit eienr Software-Implementierung von RSA in Delphi gewidmet ist (ich darf den Source aber leider aufgrund geltender Copyrights nicht veröffentlichen). Die Software basiert auf der in einem Buch (steht im Literatur-Verzeichnis meiner Arbeit) beschriebenen Bibliothek zum Rechnen mit großen Zahlen. Außerdem ist auch noch der Algorithmus selbst in C/C++ im Buch beschrieben und erklärt.. und die Rechenoperationen der Bibliothek basieren alle auf ganzen Zahlen! |
So die nächste Version ist fertig und wir kommen so langsam aus der Beta-Phase raus.
Was ist neu? - Zielordner ist wählbar - Dateien können per drag and drop auf das Fenster gezogen werden - Fortschrittsanzeige - Abrechen möglich - DLL ist jetzt einkompiliert und wird bei Bedarf extrahiert Downloadlink ist noch gültig: File-Crypter |
Hallo,
ich hab mir das Proggi zwar noch nicht angesehen, aber ich wollte blos mal sagen das für das reine Verschlüsseln mit nem Passwort eine symetrische Verschlüsselung wie 3DES wohl angebrachter ist. Und wenn man nur Datei verschlüsseln will, sollte man wohl eher GnuPG nehmen, als sehr weit verbreitetes Programm halte ich es für sehr sicher. (Zur Funktionsweise von PGP/GnuPG: die Verschlüsseln mit RSA oder ElGamal auch nur ein Schlüssel für eine symetrische Verschlüsselung wie 3DES oder IDEA, weil RSA/DSA einfach zu rechenaufwendig sind). Unter http://triade.studentenweb.org/ findet man einige Implementationen,u.a. auch eine Big-Integer Unit, für Delphi & Co. Thomas PS: RSA unterliegt doch auch Linzenzbestimmungen, oder? |
Zitat:
|
Hi fiasko,
Nein, der Rsa ist frei und darf von jedem beunztzt und verändert werden. Früher hatten mal Rivest, Shamir und Adleman (die Erfinder) mal ein Patent darauf (nebenbei haben sie dadurch sehr viel verdient), jetzt aber gibt es diese Patent nicht mehr! Der Rechenaufwand beim RSA ist zwar groß, der Vorteil ist dadurch aber, dass das Hacken schwierig wird. @ Luckie: Vielleicht wäre es noch eine Möglichkeit die Private-Key auf eine Diskette zu schreiben. Damit wäre das Risiko, dass Hacker was erfahren niedriger... Chris |
Ich weiß über die DLL nur, was in der Doku steht (ich hatte sie mal angehängt). Auf irgend welche Schlüssel habe ich keinen Zugriff.
|
Zitat:
Zitat:
Zitat:
Thomas |
Hallo,
Diskussionen über Verschlüsselungs-Methoden sind immer wieder interessant, aber aus meiner Sicht ist ein Aspekt vernachlässigt worden: Nämlich die Tatsache, dass man nicht für jeden Zweck zwangsläufig die bestmögliche Verschlüsselung benötigt. Ich habe hier zum Test mal ein ZIP-Archiv mit einem Passwort von 8 Zeichen Länge "versiegelt". Selbst wenn ein potentieller Angreifer weiss, dass er "lediglich" alle Passworte mit 8 Zeichen zu versuchen hat, so hat er etwas mehr als 2 * 10^14 Kombinationen zu prüfen, wenn er sich auf Klein- und Großbuchstaben sowie Ziffern beschränkt. Mein AMD mit 1,3 GHz schafft etwa 800.000 Kombinationen pro Sekunde. Demnach würde ich eine seeeeehr große Tasse Kaffee trinken können, bis er fertig ist. Zudem könnte ich meinen Rechner anderweitig nicht sinnvoll nutzen, da dieser ja zu tun hat. Es wird für den Angreifer entsprechend länger dauern, wenn er nichts über die Länge des Schlüssels weiss oder der Zeichensatz um einige Sonderzeichen erweitert wird. Ich denke also schon, dass die von Luckie genutze DLL für den Hausgebrauch wirkungsvoll ihren Dienst verrichten wird. Für viele Zwecke wird der benötigte Aufwand vom "Cracken" nicht im Verhältnis zum zu erwarteten Ergebnis stehen. Wer interessiert sich schon so sehr für meine Haushaltsabrechnung? :wink: (Luckie muss sein Programm ja nicht gleich an BND, CIA oder das FBI verscherbeln....) |
So sehe ich das auch.
http://www.luckie-online.de/_pics/dafuer.gif |
hey ich lese mir gerade mal eure beiträge durch aber meint ihr wirklich dass verschlüsselung so lebenswichtig ist? ich meine wer braucht schon eine 64bit verschlüsselung, gibts bei euch so wichtige daten??
würde mich nur mal so interessieren. aber trotzdem, nettes programm. respekt!! |
Zitat:
Zitat:
Zitat:
Code:
Da der Source der Dll allerdings nicht vorliegt gibt es keine Einsicht wie diese Umformung stattfindet und alleine das sollte schon Grund zur Vorsicht sein!
zwei Passwörter p, q aus der Passwort-Menge P (|P| = 255^256)
für jedes Passwort p wird ein Schlüsselpaar <e, d> mit e, d Element aus der Menge der natürlichen Zahlen erzeugt jetzt muss für alle p <> q gelten - e(von p) <> e(von q) und d(von p) <> d(von q) Zitat:
|
|
Hey, da is ja noch alles mögliche dazu gekommen während ich den Monsterbeitrag von vorher geschrieben hab..
Zitat:
|
Ich bin gerade mit dem Programmierer in Verbindung getreten. Und habe ihm meinen Delphi-Wrapper für seine HP angeboten. Bei Gelegenheit werde ich ihn mal Fragen wie er das verschlüsselt.
|
Moin Motzi,
wobei eine simple XOR Verschlüsselung nicht knackbar ist, wenn man sie als OTP implementiert, und die Schlüssellänge der Nachrichtenlänge entspricht. Das hierbei natürlich das unangenehme Problem besteht den Schlüssel sicher zu übertragen steht auf einem anderen Blatt ;-) @Daniel: Wenn Du davon ausgehst, dass jemand "Brute Force" versucht das ZIP PW zu knacken könntest Du recht haben, aber wer's drauf anlegt, wird sich wohl auch damit auseinandersetzten, wie die Verschlüsselung vonstatten geht, und den Algorithmus daraufhin anpassen, so dass die Anzahl der Erforderlichen Versuche drastisch sinkt. |
Zitat:
Zitat:
Zitat:
|
@Christian:
Ich hatte vor einiger Zeit einmal massives Interesse daran, an den Inhalt (m)eines ZIP-Archives zu gelangen. Zu diesem Zweck habe ich verschiedene Tools ausprobiert, um das Passwort zu erhalten. Sobald aber eine gewisse Unsicherheit über den Aufbau des Passwortes im Spiel ist, kamen alle Tools bei Brute-Force an... Möglichkeiten, dieses Prozess unter den o.g. Rahmenbedingungen zu optimieren, kenne ich nicht - lasse mich aber sehr gerne eines Besseren belehren (wenngleich eine solche Diskussion per PM geführt werden sollte :wink:). |
Warum nimmt man zum verschlüsseln per RSA eigentlich Primzahlen?
Dadurch schrumpft doch die Menge der zu faktorisierenden Zahlen ganz extrem. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 14:09 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz