Hi
Gina,
Fragen sind immer gut
Zitat:
1.) Heißt das, der Header wird mit PKCS#5 verschlüsselt?
2.) Und wozu wird SHA1 oder RIPEMD-160 benutzt?
3.) Und dieser Zufallswert (Salt), der in den ersten Bytes abgeöegt ist? Normalerweise würde man doch damit ein Passwort verschlüsseln um es zu speichern.
4.) Das wird doch aber nicht getan. (oder?)
1.) PKCS#5 ist ein Standard, ein technisches Papier das vorschreibt wie man mit welchem Algorithmen was verschlüsseln sollte. (ganz einfach ausgedrückt). Es gibt verschiedene solcher Standards und ich persönlich mag PKCS# nicht besonders weil er alt und amerikanisch ist. Das ist aber eine andere Sache und sagt reingarnichts über dessen Tauglichkeit aus. PKCS#5 ist gut und es ist absolut sinnvoll sich an solche anerkannten Standards zu halten.
Im Falle des Programmes geht es nur darum wie man aus einem Passwort eines Menschens ein technisch sicheres Passwort=Sessionkey erzeugt. Dazu wird ein zufälliger Salt == Zufallsbytes und eine Einweg Hashfunktion benutzt. Der Humankey + der Zufallswert landet in einer KDF=Key Derivation Function=Schlüsselableitungsfunktion um darin mit Hilfe von SHA1/RipeMD als Hashfunktionen einen sicheren Sessionkey zu erzeugen. Diesen Sessionkey kann man nur reproduzieren wenn man den Humankey + Salt + Verfahren kennt. Eine KDF dient also dazu einen zufällig aussehenden und nicht zurückrechenbaren aber reproduzierbaren sicheren Schlüssel zu erzeugen. Die Aufgabe der KDF ist der Schutz des Humankey denn wird durch eine Brute Force Attacke ein Schlüssel gebrochen so ist das nur ein KDF-SessionKey und nicht der reale HumanKey. Will man weitere Nachrichten brechen so muß man wiederholt eine neue Brute Force Attacke durchführen. Hätte man direkt mit dem HumanKey verschlüsselt so hätte man mit der erfolgreichen Attacke auf EINE Datei auch gleichsam ALLE anderen Dateien des Benutzers gebrochen. Ergo: eine KDF mit Zufallssalt schützt den Humankey vor Brute Force oder Dictionary Angriffen. Dictionary=Wörterbuch Angriffe zielen auf die Verwendung von schlechten HumanKeys ab. Zb. "Hagen" als Humankey ist echt unsicher und würde in einem Dictionary eines Angreifers gespeichert sein. Ergo: beschleunigen solche Dictionary Angriffe auf real benutzte Humankeys und somit die Kryptoanalyse. Um sowas zu verhindern dient ebenfalls die KDF und im ganz besonderen der Zufalls-Salt. Dieser macht aus dem zu kurzen und fixiertem HumanKey also bei JEDER Benutzung dieses Keys einen pseudo-zufälligen und nicht direkt rückrechenbaren Sessionkey. Die Hash Funktion verhindert dabei das direkte Rückberechnen des SeesionKeys in den HumanKey. Wie du siehst erst die Anwendung aller drei Merkmale -> HumanKey + Zufallssalt + Hashfunktion innerhalb einer KDF() sichert das ganze System gut ab. Und im PKCS# Standard wird genau beschrieben wie eine solche KDF aussehen könnte !! Es gibt bessere Standards, und denoch ist die Anwendung des PKCS#5 Standards weit weit besser als garkeine KDF zu benutzen.
2.) siehe 1.)
3.) siehe 2.) Wobei zu sagen ist das es ein Unterschied ist ob ich eine Berechnung "rückgängig" machen kann oder ob ich die gleiche Berechnung "wiederholen", also reproduzieren kann. Nun aus einem HumanKey + Zufallssalt + Hashfunktion kann ich zu jeder Zeit den gleichen Ausgangswert re-produzieren. Aber ohne HumanKey und nur mit dem Ausgangsprodukt + Hashfunktion + Zufallswert sollte man niemals in der Lage sein in erträglicher Zeitspanne den HumanKey zu berechnen. Deswegen heisen Hashfunktionen auch besser "secure Oneway Functions".
In dem benannten Program werden aber Salts auch noch an anderen Stellen benutzt. Zb. eben auch als Zufallswert der vor der Verschlüsselung des Headers an den Anfang des Headers gespeichert sind. Schau mal: der Aufbau und die Daten eines Headers sind bekannt, wir wissen das dort als erstes nach den Zufallsbytes das Wort "TRUE" stehen muß. Ohne Zufallsalt verschlüsseln wir also immer den absolut gleichen Header aber mit unterschiedlichen Schlüsseln. Die differentielle Kryptoanalyse macht sich genau dies zunutze. Sie kennt Mittel und Wege aus vielen inhaltlich bekannten aber verschlüsselten Nachrichten den benutzten Schlüssel schneller als eine Brute Force Attack zu berechnen. Und um exakt solche Angriffe zu verhindern wird die eigentliche Nachricht randomisiert. Aus der ursprünglich immer gleichen Nachricht wird durch den vorangestellten Zufallssalt eine komplett andere Nachricht gemacht. Solche Feinheiten sagen mir das die Konstrukteure des Programmes real nachgedacht haben und gutes Fachwissen der Kryptographie besitzen müssen.
4.) nach Aussagen der Programmierer der Software wird niemals, auch kein umgewandeltes Passwort des Benutzers gespeichert. Ob es real so ist kann ich nicht sagen, aber im Zusammenhang mit all den anderen Aussagen würde ich diesen Aussagen vertrauen wollen. Um zu erkennen ob das Passwort=HumanKey und die gewählten Algorithmen richtig sind wird ein verschlüsselter Header zu Testzwecken entschlüsselt. Sollte nach dem Salt das Wort "TRUE" im Plaintext stehen so geht die Software davon aus das alle Parameter korrekt sind. Erst nachdem sie alle verfügbaren Algorithmen mit dem HumanKey auf den verschl. Header angewendet hat, und keinmal das Wort "TRUE" im Plaintext stand wird die Software davon ausgehen das der HumanKey falsch sein muß. Durch diesen Trial&Error Trick wird das Verfahren probalistisch und ist nicht mehr deterministisch. Im grunde muß also selbst die Software eine "Brute Force" Attacke auf seine eigenen Daten durchführen. Aber eben mit wahrscheinlich korrektem HumanKey und somit ist der nötige Suchraum nur auf alle angebotenen Algorithmen beschränkt = 8 Stück. Ein potentieller Angreifer kennt aber weder den HumanKey noch welches der 8 Verfahren benutzt wurde. Ergo: erhöht sich der Aufwand für den Angreifer bei erträglicher Aufwandserhöhung für die Software. Allerdings halte ich persönlich nichts von solchen Konstrukten da sie eben nur minimal mehr Sicherheit bieten. Besser ist es die Sicherheit des Humankeys oder der Stärke der benutzen Algorithmen zu erhöhen. Aber zumindestens reduzieren solche Konstrukte NICHT die reale Sicherheit des Gesamtsystemes sie machen es nur komplizierter, also ist nichts einzuwenden dagegen. Ich stehe eben mehr auf simple=beautifull.
Ganz im Gegensatz dazu steht aber die Mehrfachverschlüsselungen, sprich wie in der Software möglich die Verschlüsselung mit zb. AES + Serpent + DES nacheinander. Bei solchen Konstrukten gibt es bisher fast keine fundierte Forschungsarbeit und überall wo sich die Experten darüber geäußert haben, meinten die Experten das man das tunlichst vermeiden sollte. Eben weil es keine Forschungen darüber gibt. Und eines ist absolut tödlich für jeden Kryptographen -> Unwissen und Glauben und Bauchgefühl. Kryptographen sind Konstrukteure der Mathematik, sie konstruieren sich immer eine beweisbare und vollkommen durchdachte Welt. Und die Mehrfachverschlüsselungen sind eben eine sehr schlechte Idee. Angenommen wir verschlüsseln mit AES eine Nachricht und danach mit DES. Bei einer ganz bestimmten Konstellation könnte aber DES eine Entschlüsselungsfunktion vom AES sein. In diesem Moment wäre die Nachricht wieder entschlüsselt worden und absolut unsicher. Und exakt diese Möglichkeit besteht rein theoretisch, und demnach müsste man AES + DES gemeinsam aus einem komplett neuem Blickwinkel analysieren um solche Konstellationen wissentlich und mathematisch beweisbar ausschließen zu können. Und exakt das hat bisher nich kein Mensch getan, ergo: Mehrfachverschlüsselungen sind als potentiell unsicher einzustufen.
Aber das macht ja nichts im Falle der Software, man muß das als Anwender nur wissen und dann stellt man die Software auf AES als alleinige Verschlüsselung ein, fertig. Somit nur ein Wermutstropfen.
Hoffe ich konnte deine Fragen beantworten.
Gruß Hagen