Seite 3 von 3

Verfasst: Samstag 22. September 2007, 20:31
von lunar
veers hat geschrieben:Du bist also dagegen die Grundlegenden Algorithmen zugänglich zu machen weil du den Benutzern nicht zumutest diese richtig Anzuwenden? :?
Nein. Ich bin dagegen, auf Teufel komm raus Algorithmen in die Standardbibliothek zu schmeißen, und dann dem Anwendungs-Programmierer den Rest zu überlassen. Das ist kontraproduktiv, vernünftige Programmierer würden sowieso Bindings zu bereits existierenden Implementierungen von Protokollen (z.B. openssl) nehmen, und diejenigen, die Protokolle mit den Algorithmen selbst implementieren, schreiben höchstwahrscheinlich Mist zusammen. Die Algorithmen wären also von vernünftigen Programmierern ungenützt, oder von unvernünftigen Programmierern in schlechter Software eingebaut...

Ich bin allerdings dafür, die Standardprotokolle in der Standardbibliothek zu implementieren. Dabei fallen die Algorithmen sowieso an (SSH kommt in der Regel nicht ohne AES aus), also kann man auch ein Paket mit Algorithmen zur Verfügung stellen. Dann könnten Programmierer auf die Implementierungen der Protokolle zurückgreifen, und die Algorithmen müssten nur genutzt werden, wenn es wirklich erforderlich ist, eigene Protokolle zu entwerfen.
Und wie soll jemand zum Beispiel SSH implementieren ohne auf die zu Grundeliegenden kryptographischen Funktionen zur Verfügung zu haben?
Gar nicht, weil SSH natürlich bereits in den Standardbibliothek implementiert ist, und man das ssh-Modul direkt benutzen kann. Das ist zum einen wesentlich sicherer, zum anderen wesentlich bequemer für den Programmierer.
Für mich ist es wichtiger das die stdlib die Grundsätzlichen Funktionen zur Verfügung stellt. Insbesondere wenn diese in C geschrieben sein müssen.
Damit sich jeder seinen eigenen Mist zusammenbasteln kann?
BTW: SSL richtig anzuwenden ist vermutlich schwieriger als einen String vernünftig mit einem Blockcipher zu verschlüsseln. :wink:
Das kannst du nicht vergleichen. SSL ist ein komplexes Protokoll. Ein String zu verschlüsseln höchstens ein kleiner Teil eines Protokolls. Das Problem ist, dass viele mangels Zugriff auf Standardprotokolle ihre eigenen Pseudoprotokolle entwickeln, die meistens auf sehr miesem Sicherheitsniveau liegen.

Als Beispiel kann man das sichere Speichern von Dateien nehmen:
Man kann alles selbst implementieren: Das Signieren, das Entschlüsseln, das Abfragen des Passworts, Erzeugung und Austausch des Schlüssels, etc. Das Ergebnis ist, gerade wenn der Programmierer wenig Ahnung hat, höchstwahrscheinlich unsicher und dazu noch anwendungsgebunden.

Oder man kann gnupg die Auswahl des Schlüssels, die Abfrage des Passworts, das Signieren der Datei, das Verschlüsseln der Datei, etc. überlassen. Im besten Fall reduziert sich der Prozess für den Anwendungsprogrammierer auf ein simples gpg.encrypt(data). Gpg könnte dann anhand der UID den passenden Schlüssel auswählen, und die Verschlüsselung vollziehen. Dieses Programm ist nun höchstwahrscheinlich ziemlich sicher, und noch dazu können die Dateien mit gpg selbst entschlüsselt werden und sind so nicht abhängig von der Anwendung.

Zudem sind solche Protokolle nicht interoperabel, was dazu führt, dass keine andere Anwendung derart verschlüsselte Daten lesen kann.