QUICK-AES-256 Multi Tool Win/Linux x86/x64 &DLL/SO

walbus

Cadet 3rd Year
Registriert
Dez. 2014
Beiträge
58
Versions Update verfügbar, siehe Posting Seite 4 - v3.0.00

Liebe Kryptographie Interessierte,
anbei möchte ich euch ein Tool vorstellen welches ich in den letzten Jahren
erstellt habe.

Es ist nun fertig und ich würde mich freuen wenn es gefällt und nützlich ist.

Für nicht kommerzielle Anwender ist es frei verfügbar.
Es benötigt keine Installation, greift nicht auf´s Internet zu,
enthält keine Werbung und keine Installationen irgendwelcher "Geschenke".

Paket Download hier :

QUICK-AES-256.de

Features in soweit :

Sechzehn verschiedene GUI möglich, hier mal zwei zur Ansicht !

Dateien, String und Text Verschlüsselung in AES256 CBC Mode
Base64 Datei und -Text Encoder/Decoder on demand
Bild Steganographie
Datei Steganographie
Unbegrenzte Dateigrößen
Automatische und manuelle Datei und Text Authentifizierung mit SHA3 basierenden Hashes
Automatische und manuelle Hash Generierung
Automatische Generierung von separaten Hash Files auf Wunsch
Beliebige Dateien, Pack Archive und Container mit verschlüsselten Hashes versehen und prüfen
Mehrfach und vielfach Verschlüsselung
Dateien können auch in sich selbst verschlüsselt werden, ohne Erzeugung temporärer Dateien
Personalisierung mit unzähligen Varianten
Erstellung und Verwaltung von Auto-Key´s
Beliebige Dateien als Key
Dual Key Modus
Texteditor, alternativ mit Bildschirmtastatur
Verdeckte Eingabe von Text und Key´s wahlweise
Selbst aktivierende und deaktivierende Buttons
Drag & Drop
Überprüfung der Eingabeparameter auf Korrektheit -auch für DLL/SO
Fehler und Statusmeldungen in Klartext -auch für DLL/SO
Frei positionierbare Progressbar mit Abbruchmöglichkeit für DLL/SO
Vordefinierte File Selektoren auf Wunsch für DLL/SO
Übergabe von IV und Key als Hash für DLL/SO
Übergabe von IV und Key als beliebiger String/Text für DLL(SO

Gruß Werner
 
Zuletzt bearbeitet: (Version Update)
Closed-Source Verschlüsselungssoftware? :rolleyes: Das wird keiner benutzen.

Die GUI: Viel zu komplex, zu viele Buttons die keine Sau versteht.
Die Verschlüsselung selbst: Ich bin mir nicht sicher, aber in deiner Beschreibung fehlen die wichtigen Details zu Verschlüsselung. Ich würde auf Grundlage deines Textes sagen, du hast es falsch implementiert.

SHA3 file integrity checker? Der Standard ist immer noch MD5, SHA-1 und CRC32....
 
Open oder Closed Source, beides hat Vor und Nachteile.

Hast du mal die Anleitung gelesen, welche Buttons verstehste nicht ?

Welche Details zur benutzten Verschlüsselung fehlen ?

Hier wird SHA-3 beschrieben : http://de.wikipedia.org/wiki/SHA-3

Die File Checker Funktion im Tool ist absolut nicht vorgesehen um MD5/SHA-1 Hashes zu verifizieren.

Gerne gebe ich zu allem eine Erklärung.

Gruß Werner
 
Zuletzt bearbeitet:
Kein Problem,
schau doch einfach mal rein und probier was geht und was nicht, was das Tool kann und tut.
Die Buttons sind selbst aktivierend und deaktivierend, man erschrickt zuerst, aber es geht dann alles sehr easy.
Wenn das Tool neu gestartet wird sind nur einige Button´s aktiv.
Es muss zuerst ein Passwort eingegeben werden, dann erst aktivieren sich weitere Buttons.
Es sind immer nur die aktiviert, welche auch benutzt werden können.

Der einzige Button, welcher eher mal suspekt erscheinen kann, ist der IV Button,
dies ist der Initialisierungsvektor, Wikipedia erklärt dies sehr gut :
http://de.wikipedia.org/wiki/Initialisierungsvektor

Die Anleitung von QUICK-AES-256 ist direkt auf der Webseite.

Jeder Kommentar und jede Meinung ist willkommen.

Trotzdem, es ist ein riesen Teil, jedoch mit enormen Möglichkeiten die kein anderes Tool zurzeit hat.

Gruß Werner
 
Zuletzt bearbeitet:
Closed-Source hat nur den Nachteil das du es nicht mehr verkaufen kannst. Für Verschlüsselungssoftware gibt es keine weiteren Nachteile. Da du dich fleißig bei anderen Open-Source Komponenten bedienst, wäre das nur der einzig richtige Schritt.

Offene Fragen bei Verschlüsselung:
Wo IV gespeichert?
Wie Benutzerpasswort -> AES?

Das GUI Design ist einfach altmodisch und schlecht (im Sinne von unübersichtlich). Lösung wäre z. B. Options-Dialog, Tabs, ComboBoxen, ToolTips, etc. Wenn man eine Anleitung lesen muss um die Buttons zu verstehen ist das ein sicheres Zeichen für schlechtes GUI Design.
 
Es sind viele Funktionen im Tool in denen viel "Eigenblut" steckt, ganz erhebliche Mühen und besondere Features.

Gib oben links in der GUI ein Passwort ein, es kann bis 100MB groß sein, eigentlich ist jede beliebige Datei welche interpretiert werden kann nutzbar.

Den IV findest du als Hex Dump einfach im Temp Verzeichnis, so das auch die nativen Funktionen der DLL darauf zugreifen können.
Den IV gibst du im Passwort Fenster ein, exakt wie ein Passwort, dann drückst du den IV Button.
Wenn du ihn löschst, wird er 5 mal überschrieben, du findest dann dort nur noch eine Reihe xxx.

Du musst auch keine Anleitung lesen, gib einfach ein Passwort ein und los gehts.
Die Anleitung erklärt Besonderheiten des Tool´s und Details.
Du kannst zB. eine Datei in unendlich vielen Varianten verschlüsseln, daher die Anleitung um dies und anderes was es nur in diesem Tool gibt transparent zu machen.

Nachtrag :
Die verwendeten Open Source Komponenten sind bis auf den SHA-3 Coder fester Bestandteil von Purebasic,
mit welchem das Tool erstellt wurde.
Es entbehrt jeglicher Logik und Vorstellungskraft dies umgehen oder nicht nutzen zu wollen !
Wieso kann man closed source nicht mehr verkaufen ???
 
Zuletzt bearbeitet:
Wenn ich kein IV eingeben will, wie wird er erzeugt und gespeichert? Du brauchst den wieder zur Entschlüsselung.

Und wie machst du aus einer 100MB Datei ein Key für AES?
 
Du weißt nicht wie man aus einer Datei einen Key für AES macht !!!

Es wird dann ein IV automatisch erzeugt, welcher wiederum vom Passwort und der Personalisierung beeinflußt wird

Daher, er ist immer anders, auch wenn du ihn nicht eingibst, das wird dann erkannt und dieser generierte IV zur Entschlüsselung genutzt.

Key´s und IV werden aus tausenden rekursiver SHA-3 Hash Loops generiert, mit Salt und hoch komplex.
Änderst du nur ein Zeichen bei den Key´s , dem IV oder der Personalisierung, sind die erzeugten Container bis auf Bit Ebene völlig verschieden.

Als Key, nimm zB. eine beliebige PDF Datei, oder probier irgend eine Date, einen Link, oder sonst was. Du bekommst dann oben links angezeigt wie viele Zeichen der gewählten Datei als Passwort genutzt werden. Bei einer PDF zB. kommen da schnell viele MB zusammen.

Alternativ kannst du ein simples Passwort eingeben und als Dual-Key eine .exe, oder irgend etwas, beliebiger Größe, ein Bild, ein Video, egal was, ohne 100MB Limit.
 
Zuletzt bearbeitet:
walbus schrieb:
Es wird dann ein IV automatisch erzeugt, welcher wiederum vom Passwort und der Personalisierung beeinflußt wird.
Nur wie?

walbus schrieb:
Key´s und IV werden aus tausenden rekursiver SHA-3 Hash Loops generiert, mit Salt und hoch komplex.
Hoch komplex? Soso. Solche "Argumente" will man für Crypto-Software nicht hören. Man muß es _richtig_ machen, nicht "hoch komplex". Verschlüsselung _richtig_ zu machen ist nicht trivial.

walbus schrieb:
Das Offenlegen der Source birgt schon Nachteile für die Sicherheit einer solchen Software, aber es ist müssig darüber zu diskutieren.
Uiuiui. Ein wesentliches Grundprinzip ordentlicher Verschlüsselung besagt, dass die Sicherheit einzig und allein vom Schlüssel abhängen muss, nicht von der Geheimhaltung der verwendeten Algorithmen oder der Implementierung. Wenn du daran nichtmal selbst glaubst, ist sowieso schon alles verloren.
 
Eben, siehste, es ist nicht trivial.

Es geht nicht um die Geheimhaltung von Algorithmen,
die sind nur der Kern der Sache und machen noch lange keine leistungsfähige Software.

Hol dir doch den AES Algorithmus aus dem Internet, kein Problem,
dann mach mal was gescheites draus, das ist dann EIN Problem !

Darum, weil unendlich viel Mühe drin steckt wird es halt nicht offen gelegt.

Du gehst, wie es mir scheint pauschal davon aus das Grundprinzipien nicht beachtet wurden
und die Key Generierung Schwächen hat, warum sollte das so sein ?

Nur weil oben steht die Sache sei hoch komplex muss es doch nicht automatisch falsch sein, oder ? :-)

Neue Version1.1g35 ist raus,
 
Zuletzt bearbeitet:
Nur weil viel Arbeit drin steckt, heißt das doch nicht, dass es Closed Source sein muss. Gibt auch Lizenzen, die zwar Einsicht in den Code erlauben, aber das Weiterverwenden des Codes verbieten. Wäre das was für dich?
Von einer Closed Source Verschlüsselungssoftware halte ich persönlich nicht viel...

Gibt es Pläne für Ports auf andere OS?
 
Hallo,
ja, sicher, das ist dann wohl OK.

Die Portierung auf den Mac ist möglich, etwas API und Details, mehr eher nicht, wobei ich leider keinen habe.

Noch ein kleiner Hinweis :
Verschlüsselt doch einfach mal eine Datei mit dem Tool, eine kleine, oder einen ganzen Film.
Dann schaut mal mit einem Hex Mon wie das aussieht.
Es gibt keine Header, keine Extender, keine Hinweise auf die Dateilänge, oder überhaupt was es ist, es gibt einfach nichts was irgendwelche Hinweise liefert.

Versteckt einmal in einem Bild eine Datei, boah, simpel, kann man extrahieren.

Nee, kann man hier eben nicht, es gibt nur ein leichtes Rauschen, man kann nichts extrahieren oder explorieren, niemand auf dieser Welt kann das anzunehmender Weise zurzeit.
Was mit diesem Tool in ein Bild rein gefriemelt wurde holt zurzeit keiner mehr raus, es geht einfach nicht.
Die im Bild verschlüsselten Daten werden Key, IV und Personalisierungs abhängig bis auf Bitebene im Bild stetig verschieden codiert, plus AES.


Zum Versuch verschlüsselte Container zu knacken :
Es ist schon mehr als hilfreich für einen Angreifer zu wissen mit welcher Software eine Datei verschlüsselt wurde.
Wie im betreffenden Programm intern vorgegangen wird, wie die Container strukturiert sind.
Daher wird immer zuerst versucht das erzeugende Tool einem gefundenen Container zuzuordnen.
Anhand des Quellcodes eines Programmes lässt sich der Aufbau der Container ermitteln, Eventuelle Header, Beginn und Ende der eigentlichen Datei, Padding, Größe, usw.
Bekannte Schwachstellen können zugeordnet werden.
Irgendwie logisch !

Dies ist dann eine gute Basis für einen Angriff.

QUICK-AES-256 hat dagegen ein dynamisches Padding, ja, Sachen gibt´s :-)
Und damit erzeugte Container liefern nichts außer einen suspekten massiven Datenblock, welchen man dem Tool nicht zuordnen kann.

Das sind dann die kleinen aber feinen Unterschiede.

Gruss Werner
 
Zuletzt bearbeitet:
Steganographie in Bilder ist doch ein alter Hut: http://www.heise.de/security/dienste/Tarnkappe-kontra-Krypto-Verbot-475025.html

Du widersprichst also dem Herrn Kerckhoffs https://de.wikipedia.org/wiki/Kerckhoffs’_Prinzip und hältst die Geheimhaltung deiner Methoden für einen Sicherheitsgewinn? Wer so denkt wird mit Sicherheitssoftware nie ernst genommen...

Du musst erklären was "personalisiert" bedeutet. Wenn ich auf Rechner A etwas verschlüssle kann ich es dann auch auf Rechner B entschlüsseln? Ist doch ein Witz was du hier postest. https://de.wikipedia.org/wiki/Initialisierungsvektor -> selbst da steht das IV nicht geheim sein muss, aber zufällig und für jede Datei neu...

Ja du bist stolz auf deine Arbeit - zurecht -, aber das artet schon in Arroganz / Überheblichkeit aus...
 
Zuletzt bearbeitet:
Hallo, schön wieder von dir zu hören.

Bildsteganographie ist ein alter Hut, Verschlüsselung an sich ist auch ein alter Hut :-)
Es kommt primär darauf an wie man es macht !

Zu zweitens :
Nochmal, ich will nicht die benutzten Algorithmen geheim halten, sondern das, was in dem Tool diese Algorithmen nutzt.
Die Algorithmen machen das was sie sollen, AES ist doch offen gelegt, kuckst du da !

Hast du die Anleitung schon gelesen, ich denke nein, was nicht böse gemeint ist !

Die Personalisierung :
Du kannst eine Integer Zahl im Dateinamen einfügen, hinter einem Doppelkreuz, so zB. QAES#10000
10000 ist nun DEINE Personalisierung.
Jeder der dann etwas von dir entschlüsseln will muß nun exakt diesen Wert in den Dateinamen seines Tool´s eintragen.
Stell dir vor, zehn deiner Bekannten nutzen das Tool, ihr gebt euch die Personalisierung 1236783.
Jetzt kann der IV oder der Key bekannt sein, ohne die korrekte Personalisierung kann nichts entschlüsselt werden.
In einem 64 Bit System gibt es 9223372036854775807 Varianten der Personalisierung.
Ein Brute Force Angriff auf den Key erfordert also exakt so viele verschiedene Varianten des Angriffes, wie die Personalisierung hergibt.

Nun, das sind dann schon einige mögliche Varianten, bestenfalls ca. 9,2 Trillionen.
Rechne nun mal, wenn ein neuer Super Rechner, den es zurzeit nicht gibt, auch da die gesamten USA nicht soviel Strom erzeugen können wie der benötigte, lediglich 1 Jahr für einen einzigen Angriff bräuchte...

Und der IV ist doch nicht geheim, schau in deinen Temp Ordner, wie schon beschrieben, dort findest du den Hex Dump des IV, wenn du ihn denn angelegt hast.
Das Front-End bietet dir lediglich die Möglichkeit den IV auch als Klartext einzugeben, er wird dann in einen Hex Dump konvertiert, da der IV 16 Bytes umfassen muss.

Ah, nee, ich bin nicht stolz darauf, dazu bin ich zu alt.
Und lass mich doch ein bisschen provozieren, so bin ich halt :evillol:

Trotzdem freue ich mich über dein Interesse
 
Zuletzt bearbeitet:
Vertrauen ist ne feine Sache, aber bei der Art von Software sollte es halt - zumindest für manche - ein wenig mehr sein.

Nicht falsch verstehen: Da steckt gewiss einiges an Arbeit und viel Herzblut drin, aber das ist beides kein Garant für Sicherheit. Wunderbar, wenn die Software läuft und funktioniert, aber das beutet noch lange nicht, dass es keine Patzer bei der Sicherheit gibt. Nur weil man etwa AES verwendet heißt es noch lange nicht, dass es fehlerfrei / ohne Sicherheitslücken implementiert wurde. Tagtäglich wird in allen möglichen Programmes was gefunden, wodurch Sicherheitslücken entstehen und das bei Code, der dann doch i.d.R. schon bei der Programmierung von etlichen Personen genau unter die Lupe genommen wurde.

Ich habe durchaus viel Respekt für Leute, die so etwas selber auf die Beine stellen können (ich könnte es auf jeden Fall nicht), aber deswegen vertraue ich der Software noch lange nicht. Zumal ich ein "sag ich aus Sicherheitsgründen nicht" auch nicht gerade für ein gutes Anzeichen halte.
 
Hallo,
Danke für Deinen Post.

Das ist die genutzte AES Implementation :

Optimised ANSI C code for the Rijndael cipher (now AES)
@authorVincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>
@authorAntoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>
@authorPaulo Barreto <paulo.barreto@terra.com.br>
This code is hereby placed in the public domain.

Mit Sicherheitsgründen hat das nicht offen legen der Source,
wie schon mehrfach erwähnt absolut nichts zu tun.

Die kostenlose zur Verfügung Stellung der Software für private Anwender
beinhaltet nicht das öffnen der Source.

Gruss Werner
 
Zuletzt bearbeitet:
walbus schrieb:
Und der IV ist doch nicht geheim, schau in deinen Temp Ordner, wie schon beschrieben, dort findest du den Hex Dump des IV, wenn du ihn denn angelegt hast.

Muss man den automatisch erzeugten Initialisierungsvektor manuell sichern?
Tools wie CCleaner räumen nämlich den Temp-Ordner auf und dann ist der IV weg.
Wie entschlüsselt man dann den Container, wenn der IV nicht mehr vorhanden ist oder ist der IV zum Entschlüsseln nicht mehr nötig?

Welche Methode benutzt du für die automatische Erzeugung des IV?
 
Zuletzt bearbeitet:
Hallo,
wenn du den IV nicht selbst anlegst wird er intern generiert, er wird dann auch nirgends abgelegt.
Daher du brauchst dich dann nicht weiter darum zu kümmern.
Nur wenn du selbst einen IV in das Key Fenster schreibst und dann unten auf den IV Button klickst wird dieser in den Temp Ordner gelegt.

Wird der IV im Temp Ordner gelöscht, ändert sich der IV Button, daher du kannst dann wieder einen eingeben und auch das Piktogramm oben links in der GUI zeigt an, das etwas verändert wurde.

Der automatische IV wird primär mit einer Random Funktion berechnet. Daraus wird unter Einbeziehung des Key´s und der Personalisierung ein Hash gebildet welcher den IV als Hex Dump abbildet.

Anmerkung, Nachtrag 06.12 :
Der Key hat mit der Generierung des IV nichts zu tun, ein Fehler bei der Text Erstellung der mir nicht auffiel.
Eine genaue Erklärung zur IV und Key Handhabung im Posting vom 8.12.

Dieser aus 16 zweistelligen Hex Zahlen (32 Zeichen) bestehende Dump wird dann in 16 Bytes konvertiert, welche schließendlich den IV bilden.

Gruss Werner
 
Zuletzt bearbeitet:
walbus schrieb:
wenn du den IV nicht selbst anlegst wird er intern generiert, er wird dann auch nirgends abgelegt.
Genau da hast du ja schon deine erste Sicherheitslücke. Der IV muss für jede Datei neu generiert werden. Er sollte nicht vom Key abhängen. Die ideale Lösung wäre, den IV an jede verschlüsselte Datei anzuhängen.
 

Ähnliche Themen

Zurück
Oben