Einfache Erklärung: Ich hatte die Idee, dass es ganz praktisch wäre, Streams, die Beispielsweise über das Netzwerk gehen zu verschlüsseln, dass nicht jeder mitlesen kann. Dabei braucht man aber entweder komplizierte Algorithmen, muss mit Passwörtern hantieren, oder eigene Streams erstellen. OTFCrypt umgeht das, indem es eine Klasse bereitstellt, die sich einfach auf jeden Stream anwenden lässt.
Ein Beispiel:
Wie man sieht, wird die Verschlüssellung einfach zwischen die Streams geschaltet, ohne das man sonst etwas machen müsste. Der Algorithmus basiert dann darauf, dass das aktuelle Byte so verschlüsselt wird:
Bn = Bn xor Bn-1
Dadurch muss man um das aktuelle Byte zu entschlüsseln das Vorhergehende kennen und so weiter. Am Anfang, wenn es kein vorhergehendes Byte gibt, wird eine Zufallszahl genommen, die ebenfalls übermittelt wird. Der Vorteil an dieser Sache ist, dass es nahezu unmöglich ist, einen Netzwerkstream vom ersten Byte an mitzuschreiben. Daher wird man sofort "abgehängt" und hat mit jedem übermittelten Byte eine 256-fache geringere Wahrscheinlichkeit, doch noch alles so weit zu entschlüsseln, dass man den Stream wieder mitlesen kann.
Beim Entwurf der Bibliothek spielte noch ein weiterer Faktor eine Rolle: Da die Verschlüsselung direkt im Stream on the fly, also während die Daten durchgehen, stattfindet sollte es möglichst effizient sein. Bei einem Versuch auf einem relativ durchschnittlichen Computer bekam ich diese Werte:
Lesen und Schreiben ein Prozessorkern:
x86: 2,564 GBit/s
x64: 2,547 GBit/s
Lesen und Schreiben vier Prozessorkerne:
x86: 8,840 GBit/s
x64: 9,678 GBit/s
Das übersteigt die Bandbreite der meisten Verbindungen, also kann man die Funktionen auch in Anwendungen benutzen, die möglichst schnelle Netzwerkstreams brauchen.
Wenns verwendet wird wär ne Nennung im About-Dialog (falls vorhanden) ganz nett.
Zu dekompilieren gibts eh nix was ich net schon gesagt hätte also macht euch die Mühe gar nicht erst.
Ein Beispiel:
VB.NET-Quellcode
- ' Ohne Verschlüsselung:
- Dim MeinStream As New IO.MemoryStream(1024)
- Dim TextSchreiber As New IO.StreamWriter(MeinStream)
- TextSchreiber.Write("Hello World")
- TextSchreiber.Close()
- MeinStream.Close()
- ' Mit Verschlüsselung:
- Dim MeinStream As New IO.MemoryStream(1024)
- Dim OTFCrypt As New OTFCryptedStream(MeinStream)
- Dim TextSchreiber As New IO.StreamWriter(OTFCrypt)
- TextSchreiber.Write("Hello World")
- TextSchreiber.Close()
- OTFCrypt.Close()
- MeinStream.Close()
Wie man sieht, wird die Verschlüssellung einfach zwischen die Streams geschaltet, ohne das man sonst etwas machen müsste. Der Algorithmus basiert dann darauf, dass das aktuelle Byte so verschlüsselt wird:
Bn = Bn xor Bn-1
Dadurch muss man um das aktuelle Byte zu entschlüsseln das Vorhergehende kennen und so weiter. Am Anfang, wenn es kein vorhergehendes Byte gibt, wird eine Zufallszahl genommen, die ebenfalls übermittelt wird. Der Vorteil an dieser Sache ist, dass es nahezu unmöglich ist, einen Netzwerkstream vom ersten Byte an mitzuschreiben. Daher wird man sofort "abgehängt" und hat mit jedem übermittelten Byte eine 256-fache geringere Wahrscheinlichkeit, doch noch alles so weit zu entschlüsseln, dass man den Stream wieder mitlesen kann.
Beim Entwurf der Bibliothek spielte noch ein weiterer Faktor eine Rolle: Da die Verschlüsselung direkt im Stream on the fly, also während die Daten durchgehen, stattfindet sollte es möglichst effizient sein. Bei einem Versuch auf einem relativ durchschnittlichen Computer bekam ich diese Werte:
Lesen und Schreiben ein Prozessorkern:
x86: 2,564 GBit/s
x64: 2,547 GBit/s
Lesen und Schreiben vier Prozessorkerne:
x86: 8,840 GBit/s
x64: 9,678 GBit/s
Das übersteigt die Bandbreite der meisten Verbindungen, also kann man die Funktionen auch in Anwendungen benutzen, die möglichst schnelle Netzwerkstreams brauchen.
Wenns verwendet wird wär ne Nennung im About-Dialog (falls vorhanden) ganz nett.
Zu dekompilieren gibts eh nix was ich net schon gesagt hätte also macht euch die Mühe gar nicht erst.
Er kann ja einmal den Stream zuende sniffen lassen und dann ausprobieren. Dafür muss er nicht schneller sein als der Stream.
