• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

[Netzwelt] Servereinbruch bei Lastpass

Bei der Online-Passwortverwaltung Lastpass wurde in die Server eingebrochen. Dies hat das Unternehmen auf seinem Blog bekannt gegeben. Es gibt Hinweise dass sich Dritte Zugang zu diversen E-Mail-Adressen, den Passworthinweisen sowie den Authentifizierungshashes vieler Nutzer verschaffen konnten. Ein ähnlicher Einbruch fand bereits 2011 statt.

Lastpass versichert, dass die Authentifizierungshashes jeweils mit einem zufälligem Salt versehen und serverseitig 100.000 Iterationen von PBKDF2-SHA256 bearbeitet wurden. Somit seien die Hashes nur mit einem sehr großen Aufwand zu knacken. Das Unternehmen wird dennoch die Nutzer anschreiben und sie auffordern dass sogenannte Masterpasswort zu ändern. Neu hinzugefügte Geräte müssen zudem per E-Mail bestätigt werden. Alternativ ist die Nutzung einer Zwei-Faktor-Authentifizierung möglich.

Quelle: Golem.de
 

Ungesund

Feiner Herr

Registriert
15 Juli 2013
Beiträge
1.923
Ort
Achterbahn
@Metal_Warrior:
Hast du dir den iMobileSitter mal angesehen? Ich will jetzt heir keine unbezahlte Werbung für die machen aber zumindestens erläutern wie ich zu dem "Brute-Force-immun" komme:
Zumindest bei einem versuchten Angriff über die app ist das besondere dass jedes eingegebene Master-Passwort akzeptiert wird, aber nur bei Eingabe des richtigen Master-passworts die gespeicherten Passwörter die richtigen, und nicht zufällig generierter Unfug sind. Erkennen lässt sich das nur durch ein grafisches Icon, dass anhand des eingegebenen Master-Passworts generiert wird. Gebe ich dieses richtig ein, erscheint das richtige icon und ich persönlich weiß dass ich mich nicht vertippt habe. Jemand anderes erhält keine erkennbare Rückmeldung ob er mit seiner Master-Passwort Eingabe richtig lag, und die ausgegebenen Daten richtig sind.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.831
Ort
/dev/mapper/home
@Ungesund:
Das erfordert nur einen extra Prüfschritt (d. h. mehr Zeit) und macht die App keinesfalls immun gegenüber Bruteforce, zumal solche Methoden selten die API der App verwenden, sondern vielmehr die Datei direkt mit dem Verschlüsselungsalgorithmus angreifen (um die Berechnung effektiver zu machen).
 

Togijak

Mensch

Registriert
18 Juli 2013
Beiträge
206
ein guter Zeitpunkt an dem man über einen Wechsel zu

pws.jpg

nachdenken kann, denn

Start your safe and simplified digital life
Free open source software
Installation in minutes on Windows XP, Vista, 7 and 8
Designed by renowned security technologist Bruce Schneier
Over 4 million downloads

more Info
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
Password Safe ist dasselbe in grün, da ebenso nicht open source und nicht für OS X und Linux verfügbar.

KeePassX ist der einzig wahre Cross Platform Manager. Ohne X geht auch gerade noch so.
KeePassX is an application for people with extremly high demands on secure personal data management. It has a light interface, is cross platform and published under the terms of the GNU General Public License.
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
@Ungesund:
Kleine Korrektur: Gegen Brute Force ist nichts immun - BF ist der einzige Angriff auf ein Kryptographieverfahren, der IMMER funktionieren wird. Der einzige Schutz dagegen ist die Komplexität der eingesetzten Passwörter und die daraus resultierenden großen Zeiträume, die für die Methode in Anspruch genommen werden müssen. Bei AES sind wir da derzeit mit 128bit im Bereich von "Alter des Universums mal X" etc.

Schon mal bruteforce auf OTP versucht? Bis auf die Länge des Cyphers bzw. Klartexts hast du keine Information. Praktisch "entschlüsselt" bei OTP jeder beliebige Key den Cypher zu irgendeinem Text. Du hast allerdings keine Möglichkeit zu prüfen, ob es sich dabei um den Ausgangstext handelt oder nicht.

Cypher: ADGADFGHJKAMSJDNAKSAJSLDJE0
Dann bruteforce mal schön darauf.
Ich gebe dir sogar ein paar mögliche Lösungen vor:

Lass uns heute Essen gehen!
Wie wäre es heute mit Kino?
Wo ist das Auto abgestellt?
Du stinkst unausstehlich!!!
Ich hasse dich, du Penner!!
Ich habe dich sehr lieb. <3
Was steht denn hier tolles?
Diese Texte sind alternativ


Da du ja mit Bruteforce die Verschlüsselung knacken kannst, kannst du mir ja auch sicher sagen, welche die richtige ist, oder?

Nein, OTP kannst du auch nicht mit bruteforce knacken, da es auf hinreichend lange Texte hinreichend viele Keys gibt, die den Cypher zu einem sinnvoll klingenden Klartext übersetzen, ohne dass du eine Aussage darüber treffen kannst, ob es der Klartext ist, der ursprünglich verschlüsselt wurde, oder nicht.


Bei anderen Verschlüsselungen verlässt man sich aber, wie du schon richtig angedeutet hast, darauf, dass eine Entschlüsselung nicht in hinnehmbarer Zeit möglich ist. Wenn du in 22374 Jahren die Zugangsdaten zu meinem Computer gebruteforced hast, dürfte mich das kaum noch interessieren, egal wie gesund ich mich ernähre. ;)
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.831
Ort
/dev/mapper/home
Schon mal bruteforce auf OTP versucht?

Ich revidiere meine Aussage von vorhin - den Algorithmus kannte ich nicht (also zumindest nicht als tatsächlich verwendet - eben aufgrund der Schlüssellänge und dem Problem, dass dieser nicht wiederverwendet werden darf, also sich nicht für Dateien etc. größeren Ausmaßes eignet). Ich glaube nur kaum, dass dieser Algorithmus als Verschlüsselungsverfahren für Passwortsafes sinnvoll eingesetzt werden kann, da der User immer eine Datei als Schlüssel vorhalten muss, wodurch Brute Force wieder möglich wird (man erkennt ja die interne Struktur der Daten unabhängig vom Wert, und diese Struktur muss ja irgendwo protokolliert sein - stimmt die Struktur, hat man die richtige Datei verwendet).
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
Okay, dann nehmen wir einfach mal eine csv:

Cypher:
0101010221211201210101012313213526515216546512305478512065468574432

Ich gebe dir sogar noch eine ganze Reihe an Hinweisen: Die Struktur ist die einer csv Datei, ; werden als Seperator verwendet, alle Passwörter sind aus [a-zA-Z0-9], es sind 7 Passwörter enthalten. Jetzt kannst du mir ja sicher sagen, welches die korrekte Entschlüsselung zu obigem Cypher ist:

TollesPasswort;Passwort123;GeheimesPasswort;Passwort;Liebe;Sex;Gott
TollesPasswort;Passwort;123;Geheimes;Passwort;Passwort;LiebeSexGott


Je größer die Datei wird, desto mehr potentiell korrekte Entschlüsselungen kann ich generieren.

Übrigens ginge das ebenfalls mit JSON und sogar mit xml als Struktur.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.831
Ort
/dev/mapper/home
@virtus:
Da hast du mich jetzt nicht verstanden. Du musst dir den Schlüssel merken. Aufgrund der Tatsache, dass du dir wohl kaum einen 20 KB großen Schlüssel merken kannst, dieser zudem pseudozufällg sein muss (du kannst also nicht sexsexsex... verwenden), brauchst du eine Datei, die den Schlüssel enthält. Ist sie auf dem Device mit der so verschlüsselten Containerdatei (was mindestens beim Entschlüsseln der Fall sein muss), kann ich einfach jede Datei deines Devices (und damit auch die Schlüsseldatei) auf die Containerdatei loslassen und nachprüfen, wann die CSV-Struktur sinnvoll generiert wird*. Damit schmelze ich die Anzahl der potentiellen Schlüsseldateien auf eine Handvoll ein, und kann die potentiell als Klartext vorliegenden Passwörter direkt via BruteForce auf die jeweiligen Dienste anwenden - hab ich einen Login geknackt, kenne ich im Rückschlussverfahren die Schlüsseldatei und damit den Schlüssel.

Es wird komplexer, das gebe ich gerne zu, aber das Verfahren hat Grenzen, und die sind leider mit steigender Dateigröße sehr schnell erreicht (weil das Gehirn als einzig sicherer Aufbewahrungsort des Keys die Grenze der sicheren Reproduktionsfähigkeit erreicht). Daher entsteht das - vom Algorithmus prinzipiell unabhängige - Problem des zweiten Angriffswegs, nämlich den auf den Keystore. Und der ist gering (es sei denn, du verschlüsseltst die Schlüsseldatei wieder mit einem anderen Algorithmus, bei dem die Forderung des mindestens gleich großen Schlüssels nicht gilt und der Schlüssel von deinem Gehirn sicher reproduziert werden kann).

War das verständlich?

* Das Verfahren wird sicherer bei größeren Dateien, da du mit mehreren hundert Passwörtern nicht einfach nur eines nach dem anderen reihen kannst, sondern Zusatzinformationen wie URLs, Kommentare etc. mit abspeichern wirst, Blöcke bilden etc., die bei der Strukturprüfung stark hilfreich sind. Habe ich zum Beispiel irgendwo in deiner Datei http://www.google.de/login gefunden, ist die Wahrscheinlichkeit groß, dass ich die richtige Schlüsseldatei zur Dechiffrierung verwendet habe.
 
Zuletzt bearbeitet:

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
Normalerweise merkst du dir nicht den vollständigen Schlüssel, sondern du hast ein (wiederum verschlüsseltes) Keyfile.

Ich bin kein Cryptoexperte, allerdings reicht es meines Wissens nach sogar einen pseudo random Generator zu verwenden, der dir für einen fixen Seed einen bestimmten x-bit String zurück liefert. Quasi eine Funktion f: x -> f(x) wobei x z.B. die Länge 10 hat und f(x) die Länge 1000.
Wobei x = y => f(x) = f(y), aber nicht zwangsweise f(x) = f(y) => x = y gelten muss.
Dann kannst du dir dein 10-stelliges Passwort merken, hast aber einen 1000-stelligen Key, um damit zu verschlüsseln.
Das tut dem Problem keinen Abbruch, dass man mit jedem beliebigen Input einen möglichen Schlüsselkandidaten erhält, allerdings nicht sagen kann, ob dieser Schlüssel der korrekte ist, um den OTP verschlüsselten Cypher zu knacken.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.831
Ort
/dev/mapper/home
Das tut dem Problem keinen Abbruch, dass man mit jedem beliebigen Input einen möglichen Schlüsselkandidaten erhält, allerdings nicht sagen kann, ob dieser Schlüssel der korrekte ist, um den OTP verschlüsselten Cypher zu knacken.

Genau das, was ich gesagt habe: Der Key zur File muss irgendwie anders gesichert sein - letztendlich gibt AES auch für jeden beliebigen Schlüssel Werte zurück, auch wenn sie völliger Unsinn sind. AFAIK sagt nur eine CRC-Prüfung am Ende, ob das Entschlüsselte auch einen Sinn macht oder nicht. Ignorierst du die Prüfung, bist du fast so weit wie bei OTP. Allerdings natürlich aufgrund der Bockgröße trotzdem eingeschränkt, weil ja nur maximal 256bit verwendet werden.

Letztlich hast du an der Stelle recht, dass OTP nicht direkt erbrütet werden kann. Der Angriff auf den Key jedoch ist nach wie vor möglich, weil er irgendwo liegen muss, ob verschlüsselt oder nicht. Letztlich ist OTP am Ende eine Fleißaufgabe, weil wenn der Key, der durch Rjindael oder Blowfish etc. gesichert wurde, erbrütet werden konnte, ist OTP auch geknackt. Es steht und fällt mit der Sicherheit des Keys. Da hilft dir auch ein Pseudo-RandomNumber Generator nicht, weil er letztlich nur die Fleißaufgabe ist, aus einem Seed einen aufgeblasenen Seed zu machen - die Schlüssellänge wird dadurch nicht größer, nur "gefühlt" größer, weil es zwar theoretisch unendlich viele PseudoRN-Folgen gibt, aber nur einige wenige eindeutig durch einen Seed definiert sind (vgl. y=sin(x), mit y => Seed und x => PseudoRN-Folge - die Umkehrung am Taschenrechner gibt dir immer nur Werte aus dem Bereich von minus Pi bis Pi aus). Der wirklich kritische Schritt ist bei OTP nicht der Algorithmus selbst (der ja eine Stromchiffre darstellt), sondern die Sicherung des Keys, da er im Gegensatz zu AES aufgrund der Größe innerhalb eines maschinenlesbaren Systems gespeichert werden muss. Und damit haben wir wieder eine Sicherheit, die von einem Blockchiffre wie AES abhängt. Die Prüfung des Ausgangsstroms nach Logik ist bei komplexeren Sytemen (was die meisten Dateien ja darstellen) mit an Sicherheit grenzender Wahrscheinlichkeit maschinell ohne False Positives möglich. Je komplexer das System, desto sicherer.

Warum wir uns an der Stelle überhaupt streiten liegt in unserer Betrachtungsweise: Ich bin Praktiker, habe nie hochtheoretische Informatik gelernt. Wenn ich etwas auf Sicherheit untersuche, gehe ich auf die praktische Implementierung ein, und suche mir dort bekannte Angriffswege. Du betrachtest das Ganze eher theoretisch; wenn der Cipher sicher ist, ist das System sicher. Das ist leider nicht der Fall.
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
Der Angriff auf den Key jedoch ist nach wie vor möglich, weil er irgendwo liegen muss, ob verschlüsselt oder nicht. Letztlich ist OTP am Ende eine Fleißaufgabe, weil wenn der Key, der durch Rjindael oder Blowfish etc. gesichert wurde, erbrütet werden konnte, ist OTP auch geknackt.
Nein, der Key muss dazu nirgends liegen.

Es steht und fällt mit der Sicherheit des Keys. Da hilft dir auch ein Pseudo-RandomNumber Generator nicht, weil er letztlich nur die Fleißaufgabe ist, aus einem Seed einen aufgeblasenen Seed zu machen - die Schlüssellänge wird dadurch nicht größer, nur "gefühlt" größer, weil es zwar theoretisch unendlich viele PseudoRN-Folgen gibt, aber nur einige wenige eindeutig durch einen Seed definiert sind (vgl. y=sin(x), mit y => Seed und x => PseudoRN-Folge - die Umkehrung am Taschenrechner gibt dir immer nur Werte aus dem Bereich von minus Pi bis Pi aus).
Du vergisst, dass nicht für jede Funktion injektiv und schon gar nicht bijektiv sein muss. Das heißt es gibt nicht immer eine Umkehrfunktion.

Warum wir uns an der Stelle überhaupt streiten liegt in unserer Betrachtungsweise: Ich bin Praktiker, habe nie hochtheoretische Informatik gelernt. Wenn ich etwas auf Sicherheit untersuche, gehe ich auf die praktische Implementierung ein, und suche mir dort bekannte Angriffswege. Du betrachtest das Ganze eher theoretisch; wenn der Cipher sicher ist, ist das System sicher. Das ist leider nicht der Fall.
Natürlich ist ein falsch implementierter Algorithmus nichts wert. Das ist allerdings nicht dem Algorithmus anzulasten, sondern dem Depp, der ihn falsch implementiert hat.
Deshalb gibt es auch gute Gründe, warum man durchschnittlichen Entwicklern auch immer wieder davon abrät, selbst Crypto zu implementieren. Dem Thema widmet sich nicht umsonst eine eigene ganz spezielle Schiene der Informatik/ Mathematik.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.831
Ort
/dev/mapper/home
Nein, der Key muss dazu nirgends liegen.
D. h. du willst niemals entschlüsseln? Vergiss nicht, ich rede hier von Dateiverschlüsselung, nicht die Crypto einer kurzen Nachricht, bei der das Eingeben und Merken des Keys noch funktioniert.

Nein. Du übersiehst, dass es ein Beispiel war, um zu verdeutlichen, dass Seed A immer auf PRN-Funktion B abgebildet wird und damit der eigentliche Angriffspunkt Seed A ist, auch wenn mit B verschlüsselt wird. Die Länge von B ist unerheblich, weil nicht für jedes beliebige B ein A existiert. Es ist und bleibt eine Bruteforce-Aufgabe.

Das ist allerdings nicht dem Algorithmus anzulasten, sondern dem Depp, der ihn falsch implementiert hat.
...oder dem Algorithmus, der eine derartige Implementierung erzwingt. Ohne Key kein Sinn, und der ist bei OTP nunmal mindestens so lang wie die zu verschlüsselnde Datei, also mindestens genauso groß.

Letztlich ist das Problem (über einen kleinen Umweg) ein Bruteforce-Problem:
Datei X (20 GB, ZIP) wird mit Datenstrom Y (30 GB) verschlüsselt, der durch einen Seed von 20bit erzeugt wird. Dann erstelle ich mir den Raum aller möglichen Seeds, wende auf jeden die PRN-Funktion an und beginne dann mit jedem Ergebnis die Entschlüsselung. Eine Sinnprüfung nach logischem Dateiheader wird mir letztlich 2 oder 3 Dateien ausspucken, die "Sinn" machen, eine weiterführende CRC-Prüfung beim Entpacken führt zu einer einzigen logischen Datei. QED.
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
Letztlich ist das Problem (über einen kleinen Umweg) ein Bruteforce-Problem:
Datei X (20 GB, ZIP) wird mit Datenstrom Y (30 GB) verschlüsselt, der durch einen Seed von 20bit erzeugt wird. Dann erstelle ich mir den Raum aller möglichen Seeds, wende auf jeden die PRN-Funktion an und beginne dann mit jedem Ergebnis die Entschlüsselung. Eine Sinnprüfung nach logischem Dateiheader wird mir letztlich 2 oder 3 Dateien ausspucken, die "Sinn" machen, eine weiterführende CRC-Prüfung beim Entpacken führt zu einer einzigen logischen Datei. QED.
Ich mache dir einen Vorschlag: Veröffentliche deine Arbeit in einem Paper und reiche es ein. Wenn du OTP unter Voraussetzung einer korrekten Implementierung gebrochen hast, dann kannst du dir demnächst den Arsch vergolden lassen und dein Name wird bis zum Ende der Zeit der erste sein, denn man hört, wenn es um Crypto geht. (Lies dir mal den Artikel zu OTP durch.)
Aber davon ab, wer spricht davon, dass die Datei einen korrekten Header haben muss?
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.831
Ort
/dev/mapper/home
Ich mache dir einen Vorschlag
...der völliger Unsinn ist, weil der von mir soeben vorgeschlagene Angriffsweg in jedem Hacking-for-Dummies-Buch als warnendes Beispiel für falsch verstandene Sicherheit bzw. kreative Lösungsstrategie auf Angreiferseite steht. Möglicherweise nicht direkt mit diesem Algorithmus, aber der Algorithmus wird ja auch nicht direkt angegriffen, sondern lediglich deine Methode der Implementation, bei der du im weiteren Verlauf nur noch gegen eine weitere Regel verstößt: Die Sicherheit einer Verschlüsselung darf nicht von der Geheimhaltung der Methode, sondern NUR von der Geheimhaltung des Schlüssels abhängen. Ob das nun der primäre Schlüssel oder der sekundäre, tertiäre, quartäre... ist, spielt keine Rolle.

Und ich hab den Artikel nur überflogen, weil er allgemeiner und angriffstechnisch tiefschürfender in jedem Server-Security-Buch in meinem Schrank steht, insbesondere in der mitp Hackerbible. Ich kenne die Methode, sie ist eine Codierung mit sich verändernder Codetabelle, gar nicht unähnlich der Enigma. Mit dem Unterschied, dass die Codetabelle nicht determiniert verändert wird, sofern du deinen Vorschlag mit dem Seed nicht einbaust - dann hast du nämlich die Enigma, nur mit größeren Schlüsselräumen. Und wie wurde die geknackt? Genau, man hat nach "Heil Hitler" am Ende geschaut. Effektiv die gleiche Methode, wie ich nach dem Dateiheader schaue. Merkst du was? Der Angriff ist über 80 Jahre alt. Bisschen spät für ein Paper.

Aber davon ab, wer spricht davon, dass die Datei einen korrekten Header haben muss?
Die Nutzbarkeit, ganz einfach. Eine theoretische Cryptomethode, die praktisch mit jeder notwendigen Implementierung oder der einfachen Nutzung unsicher wird, ist keine nutzbare Methode. Warum glaubst du haben wir AES und verschlüsseln nicht alle mit OTP? Weil Bruce Schneider, Whitfield Diffie, Martin Hellman, Ralph Merkle, Vincent Rijmen, Joan Daemen und all die anderen Vollidioten sind?
 

Rakorium-M

NGBler

Registriert
14 Juli 2013
Beiträge
413
@virtus:
Die von dir vorgeschlagene Konstruktion (OTP+PRG) nennt sich "Stream Cipher". Dabei wird, wie du korrekt beschrieben hast, ein Zufallszahlen-Generator (Pseudorandom Generator = PRG [oder PRNG]) verwendet, dessen Ausgabe mit den eigentlichen Daten ver-xor-t wird (analog zum One-Time-Pad). "Schlüssel" ist dabei der Seed des PRG, also die Zahlenfolge, mit der der Generator initialisiert wird. Bei gleicher Initialisierung gibt der Generator immer die gleichen Zufallszahlen zurück.

In der Praxis werden Stream-Cipher nicht mehr oft verwendet, da sie eben nicht die Sicherheit bieten, die ein (korrekt eingesetzter) Blockcipher bietet. RC4 ist ein Beispiel für einen ehemals populären Streamcipher, der bspw. in der WEP / WPA1-Verschlüsselung für WLANs eingesetzt wurde. Auch wenn die Konstruktion auf dem OTP basiert, bietet sie durch den PRG eben nicht die gleiche Sicherheit.

Das Hauptproblem einer Konstruktion wie oben beschrieben ist, dass jeder Schlüssel nur ein einziges Mal benutzt werden sollte. Außerdem kann ein Mitleser Abhängigkeiten zwischen den einzelnen Nachrichten feststellen (damit gilt der Algorithmus schon als "gebrochen"), und je nach Zweck auch Nachrichten direkt entschlüsseln (damit ist der Algorithmus auch praktisch gebrochen). Das wurde in der Praxis umgangen, indem man einen Initialisierungsvektor (IV) eingeführt hat, der bei jeder Benutzung zufällig gewählt und mit übertragen wurde. Geht aber spätestens dann in die Hose, wenn man einen durchschnittlichen Programmierer das implementieren lässt.




Stream Cipher bieten gegenüber Brute-Force jedoch nicht mehr Sicherheit, als die gängigen Blockcipher. Die Fachliteratur unterscheidet da zwischen "computational security" (=sicher unter der Annahme, dass die Rechenleistung realistisch bleibt) und "information-theoretical security" (=sicher unabhängig von der Rechenleistung eines Angreifers).
Den Grund, warum die Konstruktion mit PRG durch Brute-Force angreifbar ist, hat Metal_Warrior schon beschrieben.

Beispiel:
Crypto-Algorithmen betrachtet man immer unter Worst-Case-Bedingungen, da sie ja auch für jeden Anwendungszweck funktionieren müssen. Der schlimmste Fall ist wohl: Es gibt nur zwei mögliche Nachrichten (m1 und m2), ein Angreifer muss also nur zwischen beiden unterscheiden. Beispiel: Die Antwort ist entweder "Ja" oder "Nein". [*]
Unser Beispiel-PRG ist RC4 und nimmt 48bit-Seeds als Eingabe, unsere Nachrichten sind 256 bit lang.

OTP:
Im OTP ist auch jeder mögliche Schlüssel genau 256 bits lang. Sieht ein Angreifer nun eine verschlüsselte Nachricht c, dann weiß er:
  • m1 wäre eine mögliche Nachricht, dann wäre der Schlüssel k = c xor m1 .
  • m2 wäre eine mögliche Nachricht, dann wäre der Schlüssel k = c xor m2 . Der Ciphertext kann also zu beiden Nachrichten gehören, selbst durch Ausprobieren aller Schlüssel kann der Angreifer nichts Näheres dazu sagen (da es eben für jede andere mögliche Nachricht einen möglichen Schlüssel gibt). Unabhängig vom Rechenpower wäre die Konstruktion in dieser Situation also sicher.

OTP + PRG
Angenommen die Nachricht ist m1. Der Angreifer bekommt also c = m1 xor RC4(k) . Anstatt (wie beim OTP) alle möglichen Ausgaben von RC4() auszuprobieren, kann der Angreifer jetzt direkt alle Schlüssel durchprobieren.
  • Dabei wird er sicher auf k stoßen, sodass c xor RC4(k) = m1. Er weiß also, dass m1 möglich ist.
  • RC4() hat 2^48 mögliche Eingaben, nämlich alle 48-bit-Folgen. Daher gibt es auch nur 2^48 mögliche Ausgaben, die aber jeweils 256 bits lang sind. D.h. die Mehrheit der möglichen Zufallsfolgen kann von dem Generator gar nicht generiert worden sein (so viele verschiedene Eingaben gibt es nicht). In diesem Fall besteht die Wahrscheinlichkeit von 2^48 / 2^256 = 1 / 2^208 , dass das System zu m2 entschlüsselt (also die richtige Zufallsfolge dafür getroffen wird). Das ist verdammt unwahrscheinlich.
Genug Rechenpower vorausgesetzt, kann eine solche Stream-Cipher-Verschlüsselung also geknackt werden. Nur unter der Annahme, dass nicht genug Leistung zur Verfügung steht, kann das System als sicher gelten.


Tatsächlich gibt es dazu auch einen Satz, der besagt, dass eine Verschlüsselung nur dann sicher gegen Brute-force sein kann (=information-theoretical secure), wenn |K| >= |M|, es also mindestens so viele mögliche Schlüssel wie mögliche Nachrichten gibt. Daraus folgt, das ein Schlüssel auch mindestens so lang sein muss, wie die entsprechende Nachricht. Für einen Beweis verweise ich an entsprechende Literatur.


Gruß
Rakorium




[*] Tatsächlich nimmt man meist noch viel härtere Annahmen (z.B. eine "Choosen Plaintext Attack"). Dabei macht auch das OTP keine gute Figur mehr.
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
...der völliger Unsinn ist, weil der von mir soeben vorgeschlagene Angriffsweg in jedem Hacking-for-Dummies-Buch als warnendes Beispiel für falsch verstandene Sicherheit bzw. kreative Lösungsstrategie auf Angreiferseite steht. Möglicherweise nicht direkt mit diesem Algorithmus, aber der Algorithmus wird ja auch nicht direkt angegriffen, sondern lediglich deine Methode der Implementation, bei der du im weiteren Verlauf nur noch gegen eine weitere Regel verstößt: Die Sicherheit einer Verschlüsselung darf nicht von der Geheimhaltung der Methode, sondern NUR von der Geheimhaltung des Schlüssels abhängen. Ob das nun der primäre Schlüssel oder der sekundäre, tertiäre, quartäre... ist, spielt keine Rolle.
Ich habe an keiner Stelle von einem geheimen Verfahren geschrieben.

@Rakorium-M: Wobei wir wieder bei schlecht implementierter Crypto sind.

Und ich hab den Artikel nur überflogen, weil er allgemeiner und angriffstechnisch tiefschürfender in jedem Server-Security-Buch in meinem Schrank steht, insbesondere in der mitp Hackerbible. Ich kenne die Methode, sie ist eine Codierung mit sich verändernder Codetabelle, gar nicht unähnlich der Enigma. Mit dem Unterschied, dass die Codetabelle nicht determiniert verändert wird, sofern du deinen Vorschlag mit dem Seed nicht einbaust - dann hast du nämlich die Enigma, nur mit größeren Schlüsselräumen. Und wie wurde die geknackt? Genau, man hat nach "Heil Hitler" am Ende geschaut. Effektiv die gleiche Methode, wie ich nach dem Dateiheader schaue.

Bei Enigma hattest du eine Abhängigkeit vom ersten zum letzten Zeichen einer Nachricht.
Wenn du also am Ende einer Zeichenkette ein Schlüsselbit x hattest, konntest du bis zum Anfang zurück rechnen.
Bei OTP hast du genau das nicht, sage ich dir also, dass der Cypher: 1010101010100110101010101011010101010101010101011001011010101
als 101010101010011010101010101101010101010101010101100 || 1011010101 aufgetrennt werden kann und die letzten 10 bit mit BöserMann! übersetzt werden können, also 101010101010011010101010101101010101010101010101100 || BöserMann!, dann kannst du nicht den ersten Teil des Schlüssels daraus zurück berechnen.

Wie gesagt, bei Enigma konntest du anhand des "letzten" Schlüsselbits die jeweils voraus gegangenen berechnen.
OTP lässt das nicht zu, weil jedes einzelne bit des Schlüssels zufällig gesetzt ist und in keiner Verbindung zu einem anderen bit im Schlüssel stellt.


@Metal_Warrior: Weil der Schlüsselaustausch sich bei OTP schwerer gestaltet. ;)


@Rakorium-M: Wie willst du Abhängigkeiten zwischen den Nachrichten feststellen?
Beim Hochladen des Cyphers auf einen Server hast du etwa: 1001010101001010101101010110101010110101
Beim Abrufen hast du jedes mal die gleiche bit-Folge: 1001010101001010101101010110101010110101
Zumindest solange, bis du einen neuen Klartext und ein neues Pad verwendest: 1111011101010101001010101010110101011010101010101010110101010111

Welche Abhängigkeiten siehst du denn da? Solange du nicht (a) das gleiche Pad mit einem neuen (gleich langen!) Klartext verwendest oder (b) den gleichen Klartext mit einem neuen Pad verwendest, gibt es keine Abhängigkeiten.

Aber davon ab, wer spricht davon, dass die Datei einen korrekten Header haben muss?
Die Nutzbarkeit, ganz einfach.

Okay, stell dir vor du rufst eine bit-Folge Daten aus einer Datenbank ab, etwa einen String: 1001010101001010101101010110101010110101
Da brauchst du keinen Header, der sich auf die Daten bezieht, trotzdem kannst du die Daten nutzen. Es gibt höchstens einen Header, der sich auf den Container bezieht, welcher die Daten beinhaltet. Das lässt aber in der Regel keine Rückschlüsse auf die Daten selbst zu.

--- [2015-06-24 01:59 CEST] Automatisch zusammengeführter Beitrag ---

OTP + PRG
Angenommen die Nachricht ist m1. Der Angreifer bekommt also c = m1 xor RC4(k) . Anstatt (wie beim OTP) alle möglichen Ausgaben von RC4() auszuprobieren, kann der Angreifer jetzt direkt alle Schlüssel durchprobieren.
  • Dabei wird er sicher auf k stoßen, sodass c xor RC4(k) = m1. Er weiß also, dass m1 möglich ist.
  • RC4() hat 2^48 mögliche Eingaben, nämlich alle 48-bit-Folgen. Daher gibt es auch nur 2^48 mögliche Ausgaben, die aber jeweils 256 bits lang sind. D.h. die Mehrheit der möglichen Zufallsfolgen kann von dem Generator gar nicht generiert worden sein (so viele verschiedene Eingaben gibt es nicht). In diesem Fall besteht die Wahrscheinlichkeit von 2^48 / 2^256 = 1 / 2^208 , dass das System zu m2 entschlüsselt (also die richtige Zufallsfolge dafür getroffen wird). Das ist verdammt unwahrscheinlich.
Genug Rechenpower vorausgesetzt, kann eine solche Stream-Cipher-Verschlüsselung also geknackt werden. Nur unter der Annahme, dass nicht genug Leistung zur Verfügung steht, kann das System als sicher gelten.


Tatsächlich gibt es dazu auch einen Satz, der besagt, dass eine Verschlüsselung nur dann sicher gegen Brute-force sein kann (=information-theoretical secure), wenn |K| >= |M|, es also mindestens so viele mögliche Schlüssel wie mögliche Nachrichten gibt. Daraus folgt, das ein Schlüssel auch mindestens so lang sein muss, wie die entsprechende Nachricht. Für einen Beweis verweise ich an entsprechende Literatur.

Ich bin so tief nicht mehr in der Thematik drin, ich würde allerdings auch kaum auf die Idee kommen selbst Crypto zu designen. ;)
Trotzdem kannst du für so einen Fall nur raten, welches der korrekte Inhalt der Datei ist. Da du den Klartext nicht kennst und jeder beliebige entschlüsselte "Klartext", möglich und gleich wahrscheinlich ist.... oder?!
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.831
Ort
/dev/mapper/home
@virtus:
Ich machs kurz, weil du offensichtlich einer der Typen bist, die sich so stark auf Einzelheiten und Zahlen versteifen, dass sie das Gesamtbild nicht mehr sehen.

OTP für kurze Nachrichten, für deren Länge man sich einen ZUFALLS-Schlüssel MERKEN kann: Sicher und unangreifbar.

OTP für Dateien, für die man einen gespeicherten Zufalls-Schlüssel vorrätig haben muss: Angreifbar, sogar sehr leicht, via BruteForce und Prüflogik.

OTP für Dateien, für die man einen verschlüsselten gespeicherten Zufalls-Schlüssel vorrätig haben muss: Angreifbar via BruteForce und Prüflogik; die Sicherheit ist durch den verwendeten Schlüssel-Cryptoalgorithmus definiert; OTP ist nur noch ein einziger weiterer Rechenschritt.

OTP für Dateien, für die man einen PRNG mit Seed verwendet: Angreifbar durch BruteForce und Prüflogik -> Enigma-Problem, da der PRNG für jeden Seed deterministische Zeichenfolgen ausgibt, wie es auch die Enigma tat.

Kurzum: Es liegt nie an OTP. Es liegt immer am Schlüssel, und der ist das Angriffsziel. Das ist und war schon von Anfang an mein Punkt. Es sind die Anforderungen an den Schlüssel, welche den Algorithmus in der Verwendbarkeit auf nahe Null einschränken.
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
OTP für kurze Nachrichten, für deren Länge man sich einen ZUFALLS-Schlüssel MERKEN kann: Sicher und unangreifbar.
OTP für Dateien, für die man einen gespeicherten Zufalls-Schlüssel vorrätig haben muss: Angreifbar, sogar sehr leicht, via BruteForce und Prüflogik.

Eine Datei ist nichts anderes als eine Nachricht. Ob sie kurz oder lang ist spielt dabei keine Rolle. Deine Behauptung ist also, dass OTP für eine kurze Nachricht sicher ist, für eine lange allerdings nicht, weil du auf lange Nachrichten den Key BruteForcen kannst. Das ergibt keinen Sinn.

OTP für Dateien, für die man einen verschlüsselten gespeicherten Zufalls-Schlüssel vorrätig haben muss: Angreifbar via BruteForce und Prüflogik; die Sicherheit ist durch den verwendeten Schlüssel-Cryptoalgorithmus definiert; OTP ist nur noch ein einziger weiterer Rechenschritt.

Du sagst also dadurch, dass man sich den Schlüssel nicht mehr manuell merken kann, wird er bruteforcebar. Sprich: Mit längerem Schlüssel, wird die Komplexität gesenkt. - Bullshit.
Gehen wir mal nicht davon aus, dass der Schlüssel geklaut wird, was auch kein BruteForce-Angriff ist und ein generelles Problem bei jeder Crypto ist!
Dann hieße das, dass du einen 10 Zeichen Key nicht bruteforcen kannst, aber einen 10^2000 Key durchaus.
Wobei das Problem bei OTP nicht daran liegt, dass du einen möglichen Schlüssel erstellen willst, sondern daran, dass du nicht sagen kannst, ob eine Entschlüsselung dem ursprünglichen Klartext entspricht.
Auch wenn du einen Cypher mit irgendeinem Key "entschlüsselt" hast, hast du keine Chance zu bestimmen, ob das der ursprüngliche Klartext war. Jeder Klartext mit gleicher Länge kann mit gleicher Wahrscheinlichkeit der korrekte Klartext sein.

Deine "Prüflogik" kannst du nur anwenden, wenn du Annahmen über die darin enthaltenen Daten anstellen kannst. Du kannst bei einem beliebigen Cypher allerdings keine Annahmen über die enthaltenen Daten machen. Insbesondere nicht, was für Daten vorliegen. Du kannst nicht annehmen, ein Datum enthielte einen bestimmten Header, schlicht weil das nicht für alle Daten nötig ist. Wie gesagt, ein einfacher String als Rückgabe einer Funktion/ eines Datenbank-Querys enhält per se keine Header-Information. Das Argument "ich bruteforce auf 2^n und dann fallen 0 bis 2 eindeutige Ergebnisse heraus, von denen man 1 mit 100%iger Sicherheit ausschließen kann" ist nicht.

Das Argument mit dem PRNG sehe ich ein, wie gesagt, ich bin kein Crypto-Experte. Das zieht aber bei obigen Ausführungen nicht.
 
Oben