Suche Hilfe für Jugendforschtprojekt - C++

Thu Mar 31 18:15:31 CEST 2011

On Thu, 2011-03-31 17:34:29 +0200, Stefan Hegselmann <stefanhegselmann at gmx.de> wrote:
> > Die Frage ist also: Wer hat Lust, mal einen Stapel Patches zu
> > schreiben, damit die Software läuft und vielleicht (GUI) auch für
> > einen Anwender entspannt zu nutzen ist?
> Es ist keine Rede von einem "Stapel Patches". Das Programm und die
> GUI funktionieren. Vielleicht zum Verständnis was ich meine: Z.B.
> hätte ein erfahrener C++ Programmierer gesehen, dass man srand()
> anstatt von einem einfachen rand() verwenden sollte, wenn man
> zumindest einigermaßen zufällige Werte braucht. Ich glaube, dass
> sich von solchen "Flüchtigkeitsfehlern", die garnicht so stark
> auffallen, unter Umständen noch weiter im Sourcecode befinden.

Naja, läuft auf 'nen Code Review hinaus :)  Zufallszahlen würd' ich
optimalerweise allerdings nicht aus der libc nehmen, sondern eher die
libgcrype zulinken.

> > Hilfreich wär' es, wenn Du dazu erstmal das
> > SVN/SVN/GIT/hg/...-Repo irgendwo öffentlich hinstellen würdest.
> > Helfen kann man wohl nur, wenn die Sourcen auf dem Tisch liegen.
> > Und vielleicht etwas mehr Detail-Infos, als man von der Webseite
> > bekommt.
> Ich wüsste gerne wer unseren Sourcecode hat. Also wer interesse hat
> melden, dann bekommt er/sie eine Einladung zu unserem SVN-Server.
> 
> Also nochmal: Keiner soll hier mein Prorgamm schreiben bzw.
> überhaupt was daran ändern. Vielleicht gibt es ja garnichts zu
> verbessern. Nur würde ich mich sicherer damit fühlen, wenn jemand
> Erfahrenes mit mir den Code nochmal durchgehen könnte.

Na dann mal los. Allerdings vermute ich, daß Du mehr Reviewer findest,
wenn die Sourcen zugänglich sind. Denn letztlich ist das
Arbeitsleistung, die entweer der Öffentlichkeit zugänglich sein
sollte, oder als Leistung einem Projekt gegenüber erbracht wird. Dann
kostet das :)

> Der scheinbar hundertprozentige Schutz, wie er z.T. von Anbietern
> von Webservern und lokaler Datenverschlüsselung suggeriert wird,
> hält dem ambitionierten Hacker und erst recht dem bösartigen Cracker
> in der Regel nicht lange stand.  Woran liegt das? Als das zugrunde
> liegende Problem erachten wir, dass alle aktuellen Lösungen zur
> Verschlüsselung von Daten eine Passworteingabe durch den Benutzer
> voraussetzen.Zudem fällt es vielen Menschen im Alltagsleben schwer,
> sich ein sicheres Passwort auszudenken und zu merken.  Aufgrund
> dieser Tatsachen konnten Angriﬀsmethoden stark spezialisiert werden.
> So sind über die Jahre mehrere ausgefeilte Techniken wie z.B. ein
> Wortlistenangriﬀ oder Keylogger entstanden, die sogar den besten
> Schutz unbrauchbar machen, da letztere noch vor der Kodierung das
> Passwort mitschreiben. Wir wollen einen Ansatz der Datensicherung
> entwickeln, der gegen derartige passwortspezialisierte Angriﬀe immun
> ist. Die Grundidee besteht darin, die zu schützende Datei mit Hilfe
> sich nicht ändernder Daten, wie z.B. Video-, Musik- und
> Fotobibliotheken, zu verschleiern.  Von Daten solchen stabilen Typs,
> für die eine derartige Anwendung in Frage käme, beﬁnden sich 300
> Gigabyte allein auf unserem Arbeitscomputer, von externen Inhalten
> einmal abgesehen.  Im Folgenden wird für die zu versteckende
> Quelldatei der Name „Savedatei“, für die Daten des stabilen Typs,
> die zum Verschlüsseln benötigt werden, der Name „Buﬀerdateien“ und
> für die verschlüsselte Form der Savedatei der Name „Keydatei“
> benutzt. Identische Bytesequenzen in Saveund Buﬀerdatei heißen
> „Cluster“.  Unser Ansatz sieht vor, dass wir in der Save- und
> Buﬀerdatei nach allen bestehenden Clustern suchen. Indem die Cluster
> in der Savedatei durch ihre Adressen in der Buﬀerdatei ersetzt
> werden, wird die Keydatei gebildet. Diese beinhaltet statt des
> ursprünglichen Inhalts Adressen. Ohne das genaue Wissen um die
> „richtige“ Buﬀerdatei sind keine Rückschlüsse auf den ehemaligen
> Inhalt zu ziehen. Damit realisiert man eine Datensicherung ohne
> Passwort. So ist es z.B. möglich, sensible Daten mit Hilfe der
> Urlaubsfotos zu verstecken.

Informatiktechnisch gesprochen wollt Ihr also den Klartext
_komprimieren_, indem Ihr statt eines gängigen huffman coding
Fragmente vorhandener Date(ie)n nutzt.

Das Wissen von "Password" wird durch das Wissen von "Dateiname",
"Dateinamen" oder "Basis-Verzeichnis für Date(ie)n" ersetzt.

Beispiel:
=========
Zu verschlüsselnder Text ("Save"): "Hallo Welt"
Verschleierungsdatei A ("Buffer"): "...und er rief: "Hallo Leute!""
                                                     ~~~~~~
Verschleierungsdatei B ("Buffer)": "Neues Weltkulturerbe eingeweiht"
                                          ~~~~
Verschlüsseltes Ergebnis ("Key"):  "A18-23,B7-10"

Hab' ich das richtig verstanden?

Das impliziert ersteinmal, daß man von den Positionsangaben die
Mindest-Dateigröße ableiten kann; wenn man die "Key"-Datei hat, kann
man für jede "Buffer"-Komponente, die man vorfindet, eine
Mindest-Dateigröße ermitteln, da jeder "Buffer" ja vermutlich mehrfach
genutzt wird.

Außerdem muß ja letztlich eine sinnvolle Datei (Text, Bild, ...) dabei
herauskommen, heißt also, daß man insbesondere typischerweise mit den
ersten (wenigen) Clustern einen Datei-Anfang zusammengebaut bekommen
muß, der die magic bytes des Datei-Anfangs eines gängigen Datei-Typs
entsprechen sollte--oder plain text ist.

Aus den Angaben der "Key"-Datei erhält man zudem bytegenau die Größe
der "Save"-Datei. Ein potentieller Angreifer bekommt damit schon eine
ganze Menge an Informationen an die Hand gegeben.

Habt Ihr eine Risiko-Abschätzung gemacht, um das Verfahren mit
alteingesessener Verschlüsselung zu vergleichen? Letztlich scheint es
ja darauf hinauszulaufen, daß das Password, was die Key-Generierung
bei einer Verschlüsselung befüttern würde, durch das Wissen um einen
Dateinamen ersetzt wird. Was, wenn (im schlechtesten Fall) der
"Save"-Text vollständig in einem Buffer enthalten ist und in der
"Key"-Datei somit nur ein "Cluster" steht? (Beispiel: Viele
Raw-Dateien von Digital-Kameras enthalten ein brauchbares JPEG, das
man speichern kann. Sollte das gespeicherte JPEG verschlüsselt werden,
würde vielleicht das JPEG in der RAW-Datei gefunden werden, sodaß der
Angreifer damit erfährt, daß das Geheimnis irgendwo ___im Klartext___
auf dem Rechnerliegt.)

> Rein mathematisch ist die Chance, Cluster zu ﬁnden, extrem gering,
> was gegen eine praktische Anwendung spricht. Bei unseren
> anfänglichen Tests stellten wir jedoch im Gegensatz zur Theorie
> fest, dass identische Datensequenzen relativ erfolgreich gefunden
> werden können. Durch diese ersten Ergebnisse motiviert, haben wir
> das Programm „Puzzlr“ entwickelt, welches wir im Folgenden weiter
> erläutern werden.

Gering? Im schlechtesten Fall kannst Du mit einer 256 Bytes großen
Datei, die alle Bytes von 0x00 bis 0xff enthält, _alles_ auf dem
skizzierten Weg verschüsseln. Die Cluster sind dann zwar ggf. nur
jeweils ein Byte lang, aber hey, es würd' gehen :)  Auf die Nase fiele
man maximal, wenn dummerweise ein Byte im Savetext auftaucht, daß sich
_nirgends_ in den Buffer-Daten findet.

> Zum jetzigen Zeitpunkt liegt eine größtenteils funktionsfähige
> Ausführung des Programms vor, die seit dem Einreichen dieser Arbeit
> zur Regionalrunde um folgende Funktionen ergänzt wurde:
> Sprungtabellen zum schnelleren Suchen von Clustern, Verschleiern der

Zu erschlagen mit Rainbow-Tabellen.

> Adressen um Rückschlüsse auf die Buﬀerdateien zu minimieren und ein
> verbesserter Algorithmus zum Wählen der besten Kombination von
> Clustern.Bei der Präsentation wurden uns neue, vor allem schnellere

Wie werden die Adressen "verschleiert"? Und: eine "optimale"
Cluster-Nutzung kann (wie oben anhand des Raw-Datei-Beispiels) das
Gegenteil dessen sein, was man möchte :)

> Möglichkeiten aufgezeigt gleiche Fragmente zu ﬁnden, welche wir bis
> zum Landeswettbewerb implementieren wollen. Weiterhin soll die
> Stabilität des Programms – einschließlich der graﬁschen Version –
> soweit verbessert werden, dass wir unsere
> Verschlüsselungsmöglichkeit einem breiten Spektrum von
> Computernutzern zugänglich machen können, um so auch in Zukunft ein
> hohes Maß an Sicherheit zu gewährleisten.

Hier solltet Ihr, wenn möglich, auf jeden Fall nochmal tüchtig in die
Mathematik gehen und durchrechnen, wie die Angriffsmöglichkeiten
aussehen.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of:               Träume nicht von Dein Leben: Lebe Deinen Traum!
the second  :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20110331/505cb02f/attachment.sig>