Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
QUICK-AES-256 Multi Tool Win/Linux x86/x64 &DLL/SO
Kein Mensch legt manuell für jede Datei einen neuen IV an. Das ist sowas von nicht benutzerfreundlich. Das ist wie wenn du beim Auto zum Motor anlassen an einer Kurbel drehen musst, anstatt nur den Schlüssel im Schloss umzudrehen.
Ist der automatische IV für jede Datei anders oder nicht? Das ist die einzig entscheidende Frage.
Der IV muss nicht geheim sein, weil das keinen Sicherheitsvorteil bringt...
Nochmal, der IV ist NICHT geheim in dem Tool, er steht im Temp Ordner.
Wird er jedes mal automatisch generiert, dann kann er nicht im Temp Ordner stehen,
da dies der Platz für den händig eingegebenen ist.
Die Generierung ist einwandfrei, wo ist jetzt das Problem.
Wie du selbst sowas halten willst ist alleine dir überlassen !
Ich lasse dir jetzt das letzte Wort zu diesem Thema !
Warum antwortest du denn nicht auf Valhals Beitrag? Unklar ist mir genau das, die letzte Frage war doch ziemlich konkret, mich würde interessieren wie dein Programm das handhabt.
Ich denke was hier klar werden sollte ist, dass es nicht schlimm ist Fehler zu machen, es wirkt im Gegenteil sehr professionell wenn man sich ihnen gegenüber offen zeigt, sie eingesteht und behebt.
Da es doch in den vorherigen Posts bereits genauestens erklärt ist und es mich weiter nicht interessiert wie er es in seiner eigenen Software machen würde.
Ich hatte ihm eine PN geschickt er soll mich bitte anrufen damit ich seine Fragen beantworten kann.
Er meinte, nein, er kann das selber programmieren, was ich zuerst einmal sehen möchte !
Dann soll er uns doch bitte die Essenz seiner Bemühungen kredenzen.
Es wird im Tool immer ein IV generiert, auch wenn dieser nicht vom Anwender angegeben wird.
Ein Rückgriff auf den Key und die Personalisierung erzeugt so stets verschiedene IV wenn diese Eingaben variieren
Da ich den IV nicht an die Container anhängen will, da so das erstellende Tool ev. identifiziert werden kann, wird er halt intern erzeugt.
Ja, wieso und weshalb nicht, darum nicht, wer es nicht will, soll es nicht nutzen.
Defakto,
ich lege es nicht offen !
Versucht doch mal Schwachstellen in den Containern zu finden, egal in welchen.
Die Grundlegenden Regeln um Schlangenöl zu erkennen besagen in etwa, dass man darauf achten sollte das Aussagen folgende Worte enthalten:
schafft niemand
unmöglich
beste/perfekte Umsetzung
...
Leider erfüllst du diesen Punkt.
Was den IV angeht:
Ein Rückgriff auf den Key und die Personalisierung erzeugt so stets verschiedene IV wenn diese Eingaben variieren.
Sinn und Zweck des IVs ist IMMER, dass dieser komplett zufällig ist und sich unter keinen Umständen wiederholen sollte. Bei dir steht hier aber ein "wenn diese Eingaben variieren". Sprich es gibt bei deiner Umsetzung anscheinend eine Möglichkeit hier die Zufälligkeit zu eliminieren. Auch ohne selbst komplexere Kryptoverfahren umsetzen zu können kann ich sagen, dass das Mist ist!
Da ich den IV nicht an die Container anhängen will, da so das erstellende Tool ev. identifiziert werden kann, wird er halt intern erzeugt.
IV sollte perfekter Zufall sein und zwar immer. Entsprechend lässt sich über den IV (bei ordentlicher Umsetzung) nicht erkennen, welche Software daraus angesetzt wurde. Auch darf das Wissen über die Software und des IVs die Qualität der Verschlüsselung sowieso nicht schwächen. Entsprechend ist es Unsinn hier irgendwelche Maßnahmen zu ergreifen.
Ganz im Gegenteil, hier wird Aufwand ohne Sinn und Verstand auf den Nutzer abgewälzt. Es besteht die Gefahr von Fehlhandhabung des Programms ohne Mehrwert auf Seiten der Krypto.
Anderes Problem: Die Eingabe von Dateien als Passwort (habe ich das richtig verstanden?!) ist eine mittelprächtige Katastrophe! Wenn man weiß, dass eine Datei als Passwort genutzt wurde, heißt das im Umkehrschluss, dass eine Datei auf einem der Systeme des Nutzers das Passwort ist. Die Anzahl an Dateien auf typischen Rechnern ist normalerweise deutlich unter 10⁶ (*) und damit ist auch die Anzahl der möglichen Passwörter irrwitzig klein! Das wird sogar noch schlimmer, da unter verschiedenen Bedingungen die Anzahl an in Frage kommenden Dateien noch weiter reduziert werden können. Mit dem Zugriff auf das Dateisystem fällt damit das ganze Kartenhaus zusammen**.
Hinzu kommen noch div. Möglichkeiten die Auswahl an relevanten Dateien noch weiter stark zu reduzieren.
Wenn man Krypto richtig machen will, darf man KEINEM Nutzer die Möglichkeit geben derart schwache "Passwörter" zu setzen. Selbst mit Salt ist das noch richtig großer Mist!
*das entspricht nicht mal einem 4stelligem alphanumerischem Passwort ohne Sonderzeichen (inkl. Groß/Kleinschreibung!)
**Also auch mit einem nachträglichem Zugriff auf das Dateisystem (Diebstahl, Zugriff von Behörden, ...)
Der IV wird von dir eingegeben, lässt du ihn weg, hast du auf dieses Feature wissentlich verzichtet.
Das Feature eines automatischen IV steht nicht als Option in der Anleitung.
Man kann sich doch nicht beklagen etwas nicht bekommen zu haben was man nicht bestellt hat.
Der Key als beliebige Datei ist der Dual-Key, daher ein zweiter ergänzender Key den du zusätzlich nutzen kannst,
er kann nicht alleine genutzt werden, nur mit dem eigentlichen Key zusammen.
Eine Datei kann ja auch ein beliebiger vom Anwender erzeugter Text sein.
Das ist dann auch nicht statisch, du kannst wie in jedem Passwort Zeichen hinzufügen oder weg nehmen.
Der normale Key akzeptiert Größen bis 100MB interpretierbaren Text, wie du es halt willst !
Nur der Dual-Key akzeptiert auch binäre Dateien, dies kann dann auch zB. ein Bild auf einer Webseite sein, oder sonstwo irgendwas.
Selbst wenn der Dual-Key eine Datei aus deinem Rechner sein sollte, steigt dann die Sicherheit deines vielleicht schwachen Passwortes um den Faktor 10⁶, wie du oben vorgerechnet hast, ergänzt mit dem Umstand das es überhaupt nicht ersichtlich ist welche Art von Key oder wie viele Key´s notwendig sind zum entschlüsslen.
Zudem habe ich geschrieben das es ein Merkmal dieses Tools ist keine Header oder Extender zu haben, man die Container dem Tool nicht zuordnen kann, das ist alles.
Wenn ich Container erzeugen kann bei denen man nicht herausfinden kann um was es sich überhaupt handelt,
wenn man sie den findet, was ist daran schlecht. In diese Aussage Schwächen interpretieren zu wollen ist eine Farce.
Das steht dann aber alles in der Anleitung, die man bestenfalls mal lesen sollte.
Wir können auch gerne einen eigenen IV Thread starten, unter dem Motto, wie kann ich bekommen was ich nicht wollte, wird sicher lustig.
Die Bezeichnung als Schlangenöl muss man sich in der IT-Branche schonmal gefallen lassen, wenn man sein Produkt so bewirbt wie du. Das hat aber nichts mit Fäkalsprache zu tun. Hauptsächlich liegt das an verschiedenen Buzzwords, die du nutzt und auf die manche Menschen eben etwas allergisch reagieren.
Der IV wird von dir eingegeben, lässt du ihn weg, hast du auf dieses Feature wissentlich verzichtet.
Das Feature eines automatischen IV steht nicht als Option in der Anleitung.
Man kann sich doch nicht beklagen etwas nicht bekommen zu haben was man nicht bestellt hat.
[...]
Wir können auch gerne einen eigenen IV Thread starten, unter dem Motto, wie kann ich bekommen was ich nicht wollte, wird sicher lustig.
Ach komm schon jetzt wird es aber wild. Ein IV ist doch kein Feature *kopfschüttel*. Du kannst nicht die Wahl eines guten und echt zufälligen IVs auf den Benutzer abwälzen. Du hast dich dazu entschieden, den CBC-Modus zu benutzen, dann musst DU auch sicherstellen, dass ein vernünftiger IV gewählt wird. Und weil es für dich dann schwierig wird nachzuvollziehen, welcher Datei welcher IV zugeordnet war hängst du ihn eben an die Datei an. Wie schon mehrfach gesagt: Echt Zufall + echt Zufall = echt Zufall. Daraus kann niemand schließen, dass nun gerade dein Tool eingesetzt wurde.
Was eigentlich noch viel schlimmer ist: Du bist recht früh hier im Thread darauf aufmerksam gemacht worden, dass es mit dem IV ein Problem geben könnte und dass du doch mal darstellen wollst, wie du das technisch implementiert hast. Statt von Anfang an zu sagen, dass er nicht für jede Datei zufällig gewählt wird und einfach nachzubessern druckst du herum und kommst erst jetzt mit der Antwort um die Ecke. Das ist etwas, was man von Kryptoanbietern überhaupt nicht sehen möchte. Würdest du deine eigenen Daten einem Programm anvertrauen, dessen Hersteller nicht offen zu dir ist?
Darüber, dass du eine Datei als zweites Passwort nimmst kann man streiten. Ich sehe dadurch kein Problem, da du es nur als zusätzliche Funktion anbietest. Ich sehe aber auch keinen Vorteil dadurch. Du sagst, dass schwache Passwörter dadurch sicherer würden. Statt verschiedene Funktionen an mehreren Stellen einzubauen (Datei als Zweitpasswort, Individualisierung als weiteres Feature, was in den Key einfließt) könntest du auch einfach die Mindestlänge des Nutzerpassworts erhöhen. Andererseits werden die Personen, denen es wichtig ist, viel Sicherheit zu haben wohl auch von sich aus ein stärkeres Passwort wählen, im Umkehrschluss werden unbedarftere Nutzer wohl auch auf die Zusatzdatei und die Personalisierung verzichten.
Noch einmal: Es geht nicht darum, dich oder deine Arbeit persönlich anzugreifen! Wer so etwas Sensibles wie Kryptographie implementiert und es dann auch noch zur Verwendung für die Allgemeinheit zur Verfügung stellt muss sich gefallen lassen, dass man die Software kritisch beäugt. Wenn du dich nicht so vehement wehren würdest, würde man da vermutlich auch nicht so darauf herumhacken sondern dir freundlich helfen (ein paar Ausnahmen gibt es natürlich immer).
Den Rauch, den machst du gerade zu großen Teilen selber...
Selbst wenn man jetzt das IV Thema abhakt, gibt es doch noch tausend andere Fragen. Das Grundproblem ist einfach "Closed-Source", weil man jetzt jedes Detail aus der Nase ziehen muss. Und dann natürlich drauf vertrauen, dass es auch wirklich so ist.
Ja ich könnte so ein Tool ohne Probleme programmieren. Ohne jetzt hier angeben zu wollen. Habe aber momentan keinen Bedarf dafür.
Jedenfalls, wenn du mit so einem Dateiverschlüsselungsprogramm Geld verdienen möchtest. Schau dir das Programm als Vorbild an: https://www.boxcryptor.com/de
Ja, so kommen wir aber weiter.
Ich habe auch kein Problem damit, wo Rauch ist, ist auch Feuer
Wichtig ist, wir diskutieren sachlich und feinden uns nicht an, passt doch.
Wer das nicht kann, hat eventuell eher ein Problem mit sich selbst, als mit anderen.
Das gesteigerte Interesse an der Sache überrascht mich ehrlich gesagt ziemlich.
Der IV ist halt in dem Tool händig einzugeben und es wird auch nicht rum gedruckst.
Wie der IV erzeugt wird steht doch kipp und klar in den vorigen Postings,
Zur weiteren Erklärung :
Das Front-End ist lediglich ein Aufsatz für die primären Funktionen der DLL/SO, die erwarten einen übergebenen IV.
Daher ist das so gemacht, nutzt du die DLL/SO kannst du dies dann alles selbst so machen wie du es gerne hättest.
Du siehst es am Dual-Key, hier wird explizit darauf hingewiesen das dieses Feature nicht kompatibel zur DLL/SO ist.
An sich wollte ich die Dual-Key Option deshalb überhaupt nicht im Frontend anbieten.
Habe mich dann aber entschlossen sie doch optional zuzulassen, was in der GUI bei Verwendung selbiger im Piktogramm
extra mit einem roten Punkt und einer Warnmeldung bedacht wird.
Feature heißt Merkmal, CBC ist ein Merkmal, daher ist dieser Begriff sachlich richtig, nicht mehr und nicht weniger.
Im Download Paket ist Quellcode zur Nutzung der DLL/SO enthalten
Ergänzung ()
Hallo Valhal
Es wird eine kryptogrphische Random Funktion benutzt, Pseudo Zufallszahlen nur dort wo dieses Feature explizit erwünscht ist.
Ist doch kein Problem, es ist mir halt auf die Nerven gegangen.
Hättest anrufen können, alle deine Fragen stellen, dann hätten wir den Thread nicht so aufgebläht mit diesem Gegurke.
Auch für mich wäre das hilfreich gewesen.
Ich stelle ja nicht in Frage was du kannst und was nicht, niemand muss etwas tun was er nicht möchte.
Die Source belegt ca. 7400 Zeilen im Editor, war halt viel Arbeit.
Ich wollte es auch schon ein paar mal entnervt aufgeben.
Dann denkt man, so viel Arbeit, jetzt weg schmeißen, nee und geht nochmal dran.
Es ist auch nicht alles so einfach wie es scheint.
Der Teufel steckt im Detail, versteckte Fehler welche schwierigst zu lokalisieren sind oder nur bei bestimmten Konstellationen auftreten usw.
Es lässt sich ja Bedarfsweise noch dieses oder jenes ändern...
Ich habe nicht deine Arbeit als Mist bezeichnet sondern das Konzept und auf gar keinen Fall habe ich dich persönlich angegriffen .
Dazu muss ich sagen, ich bevorzuge klare An- und Aussagen wenn es um (potentielle) Probleme geht, mit all zu freundlicher, politisch korrekter Sprache werden meiner Meinung nach Probleme oft nur blumig angerissen anstatt mit der hässlichen Seite der Sprache auf hässliche Probleme hinzuweisen. Ich habe auch schon in Diskussionskursen für BWLer / Führungskräften gesessen und mit der in den Kursen propagierten total freundlichen Diskussionskultur ist kein Blumentopf zu gewinnen. Am Ende einer solchen Diskussionsrunde gehen zwar die aller meisten (ich nicht ) mit einem Gefühl raus, jedoch auf Kosten derer, die die Folgen zu tragen haben...
Was den zusätzlichen Key angeht, das bringt nix. Entweder ist das Passwort ausreichend sicher oder nicht. Der zusätzliche Key steigert die Komplexität des Passwortes kaum. Mittlerweile sind Wörterbuchattacken üblich, die 3-5 "zufällige" Zeichen zum Wort aus dem Wörterbuch einfach mit probieren, da der Aufwand recht klein ist. Sowas wie Schweinestall -> 5chwEin3sta!l sieht zwar auf den ersten Blick nicht so schlecht aus, wird bei mittlerweile üblichen Attacken meist mit probiert.
Da die Möglichkeit Dateien als 2nd Key zu nehmen unter normalen Umständen die Komplexität nur in einem Maße erhöht die einem 3-4 stelligem alphanumerischem Passwort entspricht wären entsprechende Angriffe nur leicht zu modifizieren und schon ist dein geglaubter "Sicherheitsgewinn" sehr klein. Im Falle das der Container übermittelt werden soll ist die potentielle Komplexität des Keys sogar noch weit reduzierbar, da man dann nur Dateien/Inhalte prüfen muss, die Empfänger und Sender gleichermaßen haben.
Das ist egal wie man es dreht, dieses "Feature" lässt eine nutzerseitige Schwächung der Kryptografie zu bzw. aus einer anderen Perspektive gesehen vermittelt dieses Feature einen weit größeren Sicherheitsgewinn als wirklich dabei heraus kommt (im Zweifelsfall wird dann das Hauptpasswort zu schwach gewählt...)!
Das der Nutzer die Eingabe auch richtig machen kann zählt dabei nicht, Krypto sollte man als Pessimist erster Klasse angehen also: Der Nutzer kann (lies: "wird") Fehleingaben machen.
Das die Handhabung des IV auf den Nutzer abgewälzt wird (Nutzer = Schwachstelle!) kommt dann noch hinzu. Da wird dir berechtigt Kritik entgegenschlagen bis du das nicht anders löst. Komplexität muss ins Programm und vom Nutzer weg!
Ansonsten: Aus Erfahrung heraus ist Krypto, bei der der "Anbieter" sein Programm mit den Worten und Formulierung beschreibt wie du nicht sicher. Denn Anstatt solche Allgemeinformulierungen wie "sicher, unknackbar, ..." zu bringen wäre seriöse Angaben, unter welchen Bedingungen mit welcher Komplexität der Spaß angreifbar ist. Wobei hier im Thread schon mindestens 2 Dinge genannt wurden die die Komplexität enorm schwächen können (lies: "werden").
Hinzu kommt deine merkwürdigen Konzepte die bisher sichtbar sind. Diese lassen vermuten, dass der closed Source Teil ebenso merkwürdige Umsetzungen enthält und hier wird es dann richtig haarig. Dummerweise gilt es nicht anderherum, wenn die GUI und Dokumentation gut aussehen (stilistisch und inhaltlich), heißt das im Umkehrschluss nicht, dass die Umsetzung des eigentlichen Kryptoteils wirklich gut ist (Kryptopesimissmus!)
Ist doch kein Problem, es ist mir halt auf die Nerven gegangen.
Hättest anrufen können, alle deine Fragen stellen, dann hätten wir den Thread nicht so aufgebläht mit diesem Gegurke.
.
Da hast du meine Absicht komplett missverstanden. Ich denke, dass diese Fragen + Antwort von öffentlichem Interesse sind. Ich möchte dir nicht geheime Fragen stellen. Ich habe ja auch gesagt, dass ich dein Tool niemals benutzen werde. Allein "Closed-Source" reicht für mich als Grund. Der Grund warum ich hier überhaupt poste ist, um andere aufzuklären und um dir Verbesserungsvorschläge zu machen. Verbesserungsvorschläge hast du denke ich genug.
Das Front-End ist lediglich ein Aufsatz für die primären Funktionen der DLL/SO, die erwarten einen übergebenen IV.
Daher ist das so gemacht, nutzt du die DLL/SO kannst du dies dann alles selbst so machen wie du es gerne hättest.
Warum sollte ein Programmierer deine closed source dll/so einsetzen? Kann er das nicht selber implementieren? Ob deine Implementierung besser oder schlechter ist, weiß keine Sau.
Du lebst mit dem Tool in einer Traumwelt. Deine Anwendungsszenarien sind völlig absurd. Kein Mensch wird das Tool in diesem Zustand benutzen. Schau dir Boxcryptor an... da lernst du was heutzutage Benutzerfreundlichkeit bzw. Usability bedeutet. Sowas muss eine Software heute leisten, ansonsten wird sie nicht akzeptiert.
Ja, das heißt aber auch nicht das es automatisch schlecht sein muss
Ich habe auch keine Probleme mit klaren Aussagen, nur sind wir mit "Sau" schon wieder auf dem Bauernhof
Die "kleinen Anmerkungen" zum Key sind übrigens absolut falsch,
bitte einmal belesen wie sowas funktioniert und gemacht wird !
Das Frontend ist erst lange nach der DLL/SO entstanden um die Möglichkeit zu bieten Funktionen der DLL einfach aufrufen zu können, sekundär auch um diese zu testen, es spiegelt die Funktionen der DLL, nicht viel mehr als das und ein paar Zugaben
Daher, bei Nutzung der DLL kannst´e den IV anhängen wo du willst, du kannst ihn auch erzeugen wie du willst.
Die Erkenntnisse aus einem Anruf wären ja auch nicht "geheim" gewesen,
ich denke ein offeneres Angebot kann man doch nicht mehr machen.
Zitat:
"Key´s und IV werden aus tausenden rekursiver SHA-3 Hash Loops generiert, mit Salt und hoch komplex."
Das ist aber als Erklärung noch nicht ausreichend.
Was ist der Input für die Hashes bei automatischer Erzeugung?
Der Zufallsgenerator der CPUs ist evtl. selber kompromittiert, wie man anhand der NSA-Leaks vermuten muss.
Ergänzung ()
walbus schrieb:
Der Teufel steckt im Detail, versteckte Fehler welche schwierigst zu lokalisieren sind oder nur bei bestimmten Konstellationen auftreten usw.
Ich bin immer davon ausgegangen das die Zufallszahlen Generatoren kompromittiert sind.
Ebenso wie es Bestrebungen gab den SHA-3 Algorithmus nachträglich wieder zu schwächen.
Die Zufallszahlen sind nur ein Teil eines Hashes und den SHA-3 kann man nicht mehr aufrollen, auch da der zugrunde liegende Hash für dessen Erzeugung wesentlich größer ist. Intern arbeitet das Tool ausschließlich mit 512Bit Hashes.
Fehler machten sich zu 99% dadurch bemerkbar das sich etwas nicht mehr entschlüsseln ließ,
auch wegen der Unicode Unterstützung, mit/ oder eventuellen Pufferüberläufen schwierigst zu lokalisieren.
Du kommst ja in den Container nicht rein um zu schauen warum es fehl schlug.
Schlägt es fehl, hast du keinerlei Einsicht, da der Container immer noch verschlüsselt ist.
Das hab ich anscheinend überlesen, das tut beim Lesen ja richtig weh!
Hashingalgorithmen sind darauf ausgelegt IMMER reproduzierbare Ergebnisse bei gleicher Eingabe zu liefern. Entsprechend sind diese Algos keine Entropiequelle (Pessimisten würden sogar in Richtung Entropiesenke tendieren...)! Damit bleibt die Eingabe das Einzige, was Entropie enthält und damit der Schwachpunkt. Da ändert das Salzen auch nix mehr. Auch mir zig Wiederholungen eines solchen Algos wird der Rechenaufwand für diesen Teil nur linear gesteigert und bei gleichzeitig halbwegs exponentiell steigender Rechenleistung ist das Käse.
Edit: Ja ich weiß, solche Sachen sind üblich, gut sind die trotzdem nicht.
. Das hat aber nichts mit Fäkalsprache zu tun. Hauptsächlich liegt das an verschiedenen Buzzwords, die du nutzt und auf die manche Menschen eben etwas allergisch reagieren.
) mit einem Gefühl raus, jedoch auf Kosten derer, die die Folgen zu tragen haben...
