Challenger 2.1.5 - Verschlüsselungssoftware

@thepoc: an dem Thema bin ich momentan auch dran und daher interessiert welche Software preboot authentication unterstützt. Idealerweise würde die auch im Multiboot mit Linux funktionieren.

@balu: Ich könnte Dir nur bei Windows weiterhelfen (Safeguard/Drivecrypt/compusec)

@thepoc: danke, ich werd mir das mal anschauen.

@thepoc: DriveCrypt ist ganz nett, aber sehr langsam!

@dragonslayer: danke hört sich auch gut an und PGP9 hat ja auch einen guten Namen. Wenn ich das richtig sehe kann man compusec aber kostenlos nutzen (sogar dienstlich) .. lediglich für Support verlangen die Geld. Muß ich mir alles mal anschauen .. weißt Du wann pgp9 kommen soll?

@dragonslayer: Vorsicht mit PGP! Diese Software kann und wird durch einen Generatorangriff seitens des Betriebssystems ausgehebelt!

Mit Verlauch, aber das ist Hannebücher Unsinn.

Dann hast du PGP nicht verstanden. Und du hast nicht verstanden, daß das eindueitg ein Argument gegen die hier vorgestellte Software ist.

Das habe ich nicht verstanden. Was meint denn nur immer Rika. Kann er auch in zusammenhängende Sätze Aussagen treffen?

PGP implementiert Mechanismen zur sicheren Erzeugung, Verwaltung und Entfernung von Schlüsseln. Sicher in Bezug auf kryptographische Sicherheit, Verwaltung, Verteilung und Sicherung. Dieser Challenger-Mist hat einen denkbar unsicheren Generator, denkbar unsichere Verschlüsselung, die Funktionsbeschreibung und Pseudo-Technikgequassel und die Verlustsicherheit von Megabyte-großen Schlüsseln ist praktisch null. Im Vergleich zu diesem Müll ist ja sogar noch das originale PGP extrem vertrauenswürdig, mit GnuPG erst recht kein Vergleich.

@Rika: Jetzt gibt es schon ein originales PGP - wie lustig. Gibt es auch ein Sicheres? Übrigens, stimmt das nicht mit Megabyte-großen Schlüsseln. Die 256 Bit Challenger-Schlüssel werden unter anderem aus drei MB Zufallszahlen erzeugt. Jeder der sich mit Kryptografie beschäftigt, kann bestätigen, dass aus viel weniger Zufallszahlen unendlich viele erzeugt werden können. Die bekannten Mechanismen sind jedoch viel zu langsam.

Ja, es gibt ein originales PGP, das von Phil Zimmermann entwickelt wurde und als PGPi in als kostenlose Version von der PGP Corporation vertrieben wird, aber selbst auch eine kommerzieller Version pflegt. Übrigens: Jeder, der sich nur minimal mit Kryptographie beschäftigt, weiß, daß keine algorithmische Tranformation die Entropie einer gegebenen Eingabe vergrößern kann, und somit aus Zufallszahlen keine neuen Zufallszahlen generieren kann - nur Pseudozufallszahlen. Die bisherigen Mechanismen sind übrigens verdammt schnellt und vor allem sicher, ganz im Gegensatz zu der hier vorgestellten Software: muss ich jetzt auch noch die von mir gemachte erste kleine Kryptoanalyse dieses Programmes nochmal posten?

Aha, die PGP Corp. pflegt auch eine kommerzielle Version. Also ist die Aussage mit dem "Kostenlosen" schon einmal relativiert. Entropie: Natürlich gibt es Mechanismen, die genau die Eigenschaft haben, die Entropie zu verbessern. Nur haben diese Mechanismen etwas mit Chaos zu tun und können mathematisch nicht zurückgerechnet werden.

Die Entropie erhöht sich durch eine Verbesserung der statistischen Eigenschaften nicht. Und erfordert, daß das Verfahren kryptographisch sicher ist.

Das ist ja wohl klar, dass das kryptografisch sichere Verfahren sein müssen, wenn die Entropie verbessert werden soll. Eine verbesserte Statistik, verbessert auch immer die Entropie. Natürlich darf die Statistik nicht zyklisch werden. Aber dann ist ja auch die Entropie schlecht.

Es wird keine Entropie verbessert, das ist wissenschaftlicher Schwachsinn. Auch interessiert sich Entropie keinen Deut für die Statistik. Der Begriff einer zyklischen Statistik ergibt keinen Sinn. Und aus Entropieerhalt folgert genau gar nichts. Entweder beschätftigst du dich mal ernsthaft mt den Grundlagen der Kryptographie oder hörst auf, hier solchen Müll zu posten.

@Rika: Sind denn die PGP-Hintertüren seriös?

Bislang waren da wahrscheinlich kein Hintertüren. Außerdem gibt es GnuPG.

@Rika: Huh... jetzt gibt es noch ein anderes PGP - GnuPG. Ist ja wirklich lustig. Immer wenn ein Programm doch nicht mehr sicher ist, kommt ein Schwesterprogramm.

@pferdekuh: Ja klar! Erst ist alles kostenlos. Dann gibt es doch eine kommerzielle Version. Erst heißt es PGP. Dann gibt es doch noch ein sicheres Programm. Soviel vorgeschobene Pseudokritik habe ich auch noch nicht erlebt. Immer nur bei Verschlüsselungssoftware.

@pferdekuh: GnuPG wurde entwickelt, um die Patentierung des IDEA-Algorithmus zu umgehen. Verwendet wird es aber primär deshalb, weil der Quellcode offenliegt und die sehr gute Qualität der Implementierung zeigt. Oder hegst du nun etwa auch noch Kritik an den kryptographischen Verfahren, die (Open-)PGP verwendet?

@Rika: Aha... Mich stört es, dass Du ständig die Programme wechselst... Immer wenn gerade das eine besser ist, dann bringst Du eben dieses Programm ins Spiel. Du springst hin und her. Wie es Dir gerade in den Sinn kommt. Mal ist es eben das originale PGP, dann wieder Open-PGP. Was ist mit den Privatanwender holt der sich immer den Quelltext und compiliert sich das Programm selbst. Na dann hoffentlich ohne Compilerviren.

Dann mal Klartext: Selbst das kommerzielle PGP mit eventuell von der US-Regierung angeordneten Hintertürchen ist vertrauenswürdiger als dieser Challenger-Mist, der nun wirklich fast jeden Punkt der SnakeOil-FAQ erfüllt und alle kryptographische Vertrauensgrundsätze verlässt, von fehlender wissenschaftlicher Qualifikation mal ganz zu schweigen. Ferner glaube ich, daß der offene PGP-Quelltext wirklich dem Original-Binary entspricht, allerdings sind mir manche neuere Machenschaften der PGP Corpration nicht so ganz geheuer. GnuPG als reines Binary ist IMHO sogar Authentifizierung der GPG-Signatur, ja sogar ohne Prüfung der SHA1-Prüfsummen i.A. als hinreichend vertrauenswürdig zu betrachten - von soclhen Sachen wie der Selbstkompilierung oder Erhalt des Binaries vom Maintainer Werner Koch in persona unter direkter Verifizierung seines Keys bei einer Keysigning-Party mal ganz zu schweigen...

@Rika: Wieso verniedlichst Du das Wort Hintertür? Ist es auch noch eine kleine (kaum wahrnehmbare) Hintertür? Würde Dir besser stehen, das Thema Hintertüren in PGP zu publizieren, als hier völlig zu Verwirrung beizutragen. Welcher normale User weis denn schon, ob er ein PGP hat, welches ohne Hintertüren arbeitet? Welcher normale User kann das, was Werner Koch kann? Ist doch alles totaler Quatsch mit dem OpenSource. Mal ganz zu schweigen vom Betriebssystem. Wer kontrolliert eigentlich das Betriebssystem. Wenn Du ein Programm einmal debuggst, wirst Du sehen das Dein schönes OpenSource-Produkt nur zu 1% aktiv ist. Da helfen Deine Signaturen garnichts mein Lieber Rika. Die machen Signaturen von Binaries. Ahahahahah.

GnuPG-User wissen das. Und kein User muss ein Werner Koch sein. Vertrauenswürdigkeit in der Kryptographie durch OpenSource ist ebenfalls kein Quatsch, du solltest dir mal Bruce Schneiers Anmerkungen zu dem Thema anschauen. Und das Betriebssystem ist eine Vertrauensfrage, an der die Verschlüsselungssoftware nichts ändern kann, ist hir also genau gar kein Argument. Und du redest wirr.

@Rika: Ja, die Millionen-Schlucker wissen das, wie ihr Programm funktioniert. http://www.heise.de/newsticker/result.xhtml?url=/news ticker/meldung/32446&words=GnuPG

Bitte lesen lernen.

@Rika: Die OpenSourcer haben davon kräftig profitiert. Ihre Software hat als Vorlage für Deutschland-weite Projekte gedient!

Du bist vo Keyloggern nicht sicher, da diese meist Teil von Trojanischen Pferden sind - allein schon deshalb ist das Programm untauglich, weil es mindestens 2 der vier unabhängigen Kanäle zur Schlüsselgenerierung ignoriert. Und die Verschlüsselung selber ist auch total unsicher. Die Bedienbarkeit ist beispielsweise bei dem wirklich sicheren AxCrypt genauso gegeben, von daher kein wirkliches Argument.

@Rika: In Firmen werden mehr oder weniger Keylogger eingesetzt, um die Mitarbeiter überwachen zu können. In England ist dies sogar schon gängige Praxis. - Davor bist Du mit Challenger sicher. Außerdem bist Du mit Challenger vor Hardware-Keylogger sicher. Hardware-Keylogger könnten ganz einfach am Büro-PC angeschlossen werden. Was hat das alles mit trojanischen Pferden zu tun? Selbst ein trojanisches Pferd kann wenig mit einem ausspioniertem Passwort anfangen. Was meintest Du mit "min. 2 der 4 unabhängigen Kanäle zur Schlüsselgenerierung"?

@pferdekuh: Was Rika wahrscheinlich noch nicht verstanden hatte, dass die 3 MB Zufallszahlen und eine Phrase notwendig für eine Chiffrierung ist.

1. Wenn der Key als File irgendwo rumliegt, kann man dieses erst recht auslesen - drum verwendet jedes Programm eine Kombination aus Schlüsselverwaltung und Passwort, wobei mit dem Passwort erst der Schlüssel zuggänglich wird. Vertrauen muss man dem System, wo man das Kryptoverfahren verwendet, vertrauen, ansonsten hat man verloren - das ist bei dieser Spinnersoftware auch nicht anders. Warum glaubst du, daß das nicht so wäre? 2. Den Schlüssel generiert man aus a) einer vom Hersteller des Programmes gewählten Eingabe, meist im Programm fest definiert b) aus dem Computersystem generierten Zufallsdaten c) von Benutzereingaben abgeleitete Zufallsdaten d) das vom Benutzer gewählte Passwort. Nimmt man nur 2 davon (Herstellereingabe, Computersystem-Benutzerdaten), so kann man gegen die Schlüsselgenerierung offensichtlich einen Angriff fahren.

@Rika: 1. Bei Wiki sind Keylogger folgendermaßen definiert: Ein Keylogger ist eine Hard- oder Software, die dazu verwendet wird, die Eingaben des Benutzers an einem Computer mitzuprotokollieren und dadurch zu überwachen oder zu rekonstruieren. Keylogger werden beispielsweise von Hackern bzw. Crackern verwendet, um an vertrauliche Daten – etwa Kennworte – zu gelangen. Wobei ich ergänzen müßte, dass zunehmend Firmen ihre eigenen Mitarbeiter überwachen! Keylogger sind also nicht nur Instrumente für Hacker in dem o.g. Sinn. Nach der o.g. Definition bist Du mit Challenger sicher, da es noch kein Keylogger gibt der die 3 MB "klaut". Und wenn es ein Keylogger gäbe, der Challenger angreift, brauchen wir auch nicht mehr von Keylogger sprechen. 2. a) Eine vom Hersteller gewählte Eingabe ist völliger Blötsinn, da dies öffentlich ist! Fällt also weg. c) und d) sind gleichzusetzen! Das Quellpasswort und alle daraus abgeleiteten Schlüssel ergeben keine doppelte Sicherheit.

1. Arg, merkst du's noch? Bei PGP musst du das Keyfile klauen und das Passwort mitloggen, bei Challenger musst du nur das Keyfile klauen, das ist wesentlich einfacher. Und das soll ein Argument sein, keine Passwörter zu verwenden? Einfach nur Schwachsinn. 2. a) Nein, ist macht trotzdem Sinn, wenn der Hersteller für jede Version seiner Software eine neue Eingabe generiert. c+d) Nein. Benutzereingaben sind Mausbewegungen, Tastaturanschläge, über Soundkarte aufgenommenes Rauschen... das Passwort hingegen ist etwas, daß der Benutzer ganz gezielt in seinem Verstand generiert und ihn gegenüber seinen zufälligen Eingaben personalisiert. Zudem geht es hier um Angriffe gegen die Schlüsselgenerierung, die auf der Vorhersage der Eingaben basieren - wenn der Hersteller alle Eingaben wählt oder beispielsweise das Computersystem modelliert wird (Tipp: DJ Bernstein hat aus feinen Zeitschwankungen beim Netzwerktransfer aus einer Remote-Anwendung einen 256bittigen Schlüssel bei AES extrahiert.), dann hast du eine geweitete Analöffnung.

@Rika: 1. Bei Challenger musst Du nun aber auch das Keyfile und das Passwort klauen. Du musst also die 3 MB Zufallszahlen klauen und das Passwort mitloggen. Es genügt natürlich nicht nur das Keyfile zu klauen. Ich habe nie gegen Passwörter etwas gesagt. 2. a) Das macht keinen Sinn, da eine Herstellereingabe nur wie ein zweites Keyfile wirkt. Mehrere unterschiedliche Schlüssel ergeben NUR eine höhere Sicherheit, wenn die Schlüssel wirklich sicher aufbewahrt sind. Zwei Keyfiles sind nicht sicherer wie ein Keyfile. c+d) Dann hatte ich dich falsch verstanden. Aber c+d ist doch in Challenger enthalten. Dann fällt eben b) noch weg, weil aus dem Computersystem generierte Zufallsdaten eben nicht zufälliger sind, wie echtes Eigenrauschen der Soundkarte. Warum sollten starke Zufallszahlen stärker werden, wenn man plötzlich Computer abhängige Zahlen mit verwendet.

1. Ach nein? Ich denke Challenger soll immun gegen Keylogger schützen. 2. a) Es geht um die Schlüsselgenerierung. b) c+d ist nicht im Challenger enthalten, wenn du, wie für $ONU empfohlen, ein vorgegebenes PAD-File vom Hersteller verwendest. c) Das Eigenrauschen des Soundkarte ist de fakto weniger zufällig als diverse Systemparameter eines Computers. Außerdem gilt noch das Problem von b. d) Was soll das ganze nun überhaupt noch mit Challenger zu tun haben? Warum willst du 3MB nicht mal sonderlich zufällige Zufallsdaten verwenden, durch einen Verschlechterungsalgorithmus jagen und mit einem total unsicheren, von Dummquasselern geschriebenen Algorithmus jagen, anstatt AES/256+RSA/1024 mit einem quelloffenen Programm, geschrieben von Leuten, die Ahnung haben?

@Rika: Mir ist Faden gerissen. Könntest Du freundlicher Weise klarstellen, was Du meinst. a) Es ist egal, ob Du eine Herstellereingabe meinst oder eine Schlüsselgenerierung. Aber sag noch mal, was Deiner Meinung nach (a bis d) sein soll und was in Challenger davon fehlt. Das vorgegebene PAD-File ist freundlicher Weise dazu da, dass man erst einmal die Software testen kann. Wenn Du das Eigenrauschen der Soundkarte nimmst, werden unter Umständen ideale Zufallszahlen erzeugt. Es wird nur das niederwertigste Bit genommen. Die Aufnahme wird anschließend auf ein Mindestmaß an statistischen Eigenschaften geprüft und eventuell abgelehnt. Danach wird die Aufnahme noch mit einer Einweghashfunktion aufbereitet. So erhälst Du die besten Rauschzahlen, die es gibt! Ansonsten habe ich eine interessante OpenPGP Meldung. http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/56350&words=GnuPG

1. Das Eigenrauschen der Soundkarte ist mitnichten ideal. 2. Die Tranformation, nur das niederwertigste Bit zu nehmen, istb denkbar unsinnig. 3. Warum soll man eine Hashfunktion um mehr als das 1.5fache überladen? 4. Du verwechselst Implementierug und Algorithmus. 5. Was soll das daran ändern, daß das Challenger-Verfahren absolut unsicher ist?

@Rika: Also Rika jetzt ist aber mal halt! Du bist ja noch dümmer als ich dachte. Das Null-te Bit rauscht immer! Sogar bei den besten und rauschärmsten Soundkarten wird das Eigenrauschen nicht verhindert. Natürlich darf man nur die Datenbytes verwenden. Du kannst es ja einmal ausprobieren. Es müsste gerade Dich doch interessieren. Das Rausch-Verhalten wird auch in der Steganografie ausgenutzt. Das Gleiche trifft zu, wenn Du Bilder im umkomprimierten TIFF-Format direkt vom Scanner erzeugst. Dort wird auch das Null-te Bit rauschen. Natürlich kann Brummen überlagert sein. Aber Brummen fällt statistisch auf. Jetzt höre mal auf, hier an grundlegend physikalische Gesetze zu rütteln! Echtes Rauschen tritt in der Natur häufig auf und ist in vielen technischen Geräten oft ein Ärgernis. Oft wird auch Rauschen verwendet, um ein technisches Problem zu lösen.

Ich fürchte, du hast weder in Physik noch in Kryptographie aufgepasst. Eine Soundkarte erzeugt ein modifiziertes Transistor Shot Noise, das ist selbst auf dem niederwertigstens Bit bei 16 Bit Sampletiefe mitnichten statistisch gut verteilt. Insbesondere ist dei Transformation, alles bis auf das niederwertigste Bit zu verwerfen, einfach nur schwachsinnig, weil du damit möglicherweise ein Großteil der Entropie verwirfst - die denkbar beste Transformation ist eine kryptogrpahische Hashfunktion, in die füttert man einfach die vollen Samples. Und wenn du am Ende ohnehin nur eine kleine feste Bitlänge als Hash über dem gesamten Pad brauchst, dann reicht das 2.5fache der Hashlänge und damit allein schon der Computer selbst als Entropiequelle aus.

@Rika: Also, Rika. Ich habe in alten News recherchiert. Du hattest selbst einmal gesagt, dass man nur das niedrigste Bit eines Datenbytes einer WAV-Aufnahme nehmen muss/kann. Acht dieser Bits zusammengenommen ergeben jeweils ein Zufallsbyte. Ich selbst hatte damit einmal "gespielt" und könnte Dir ein Tool senden, welches eine Aufnahme durchführt und die niedrigsten Bits in eine Datei sammelt. Wenn Du diese Datei nach allen Regeln der Kryptoanalyse scannst, wirst Du feststellen, dass ein hervorragendes Rauschen vorliegt. Selbstverständlich trifft das Selbe zu, wenn Du mehrere Datei quercheckst. Das gleiche trifft für unkomprimierte TIFF-Dateien zu, die durch Bildscanner erzeugt werden. Wenn Du mein Toolchen haben willst, könnte ich es einmal herauskramen und zur Verfügung stellen.

@pferdekuh: Sag ich doch. Das sind teilweise grosse Spinner die OpenSource-Verfechter. Auf der einen Seite erhalten die Geld und auf der anderen Seite sagen alle die nichts damit zu tun haben, dass die Software kostenlos sei. Dabei hat der Steuerzahler hier bereits gezahlt. Auf der anderen Seite sagen die immer der Quellcode ist das Wichtigste. Das ist genau so ein Dummsinn, weil man auch noch das Betriebssystem kontrollieren müßte. Weil ja irgendwo die Stelle kommt, an der der Verschlüsselungsgenerator angesprungen wird. Der Generator könnte jedoch einfach durch einen tatsächlich geheimgehaltenen Generator ausgetauscht werden.

@bwd: Und wenn man dann mal etwas über extra eingebaute Hintertüren wissen will, dann scheint keiner zu wissen, wie diese Türen verschlossen werden können. Keiner will es ernsthaft wissen, wie sicher PGP&Co. ist. Nur kostenlos muss es sein... Alles Volksverdummung. Und dann gibt es auch noch Leute die kostenlos Partei ergreifen.

@bwd: Wie willst du den Generator geheimhalten, wenn du du ihn veröffentlichst? @pferdekuh: Ich verstehe deine Argumentation nicht. Weil es Leute gibt, die mit ordentlicher Kryptosoftware nicht umgehen können, sollen sie stattdessen eine unsichere und zudem nicht vertrauenswürdige Kryptosoftware verwenden, mit der sie nicht umgehen können? Du bist einfach nur wirr.

@Rika: bwd hatte davon gesprochen, dass im Betriebssystem ein Generator existieren könnte, der nicht öffentlich ist/wäre. Derjenige, der das Betriebssystem baut, könnte doch einfach die Verschlüsselungsmechanismen aushebeln. Ich würde sogar noch einen Schritt weitergehen. Die Aushebelungsmechanismus könnte (könnte und ich sage nicht das es schon so ist) im Prozessor selbst eingebaut sein. Immer wenn eine bestimmte Sequenz im Programmstack des Prozessors entdeckt wird, wird diese Sequenz einfach ausgetauscht. Wer einmal Mikrocontrollerprogramme geschrieben hat, weiss, dass die Implementation denkbar einfach ist. Auf Grund dessen und aufgrund dessen, dass Menschen alles tun was machbar ist, muss davon ausgegangen werden, dass alle öffentlichen Algorithmen hardwarebasierend ausgehebelt werden. Hier schließt sich eine rhetorische Frage an: Wie schön wäre es und wie viel Geld liese sich in Zukunft (oder vieleicht auch schon heute) damit verdienen, wenn im Bedarfsfall verschlüsselte Informationen entschlüsselt werden können?

Ähm... kleiner Tipp: Wenn das System manipuliert, dann kann es auch an der Soundkarte manipulieren. Von daher ist die Argumentation haltlos.

@Rika: Nein eine Soundkarte oder ein sonstiges Gerät - könnte zwar - würde aber nicht angegriffen werden, da es aufwendiger und auffälliger wäre. Es müßten die unterschiedlichsten Geräte berücksichtigt werden. Es wird wenn, dann immer der zentralste Punkt angreifen.