Das Märchen von der langfristig sicheren Kryptographie
Warum ich die von Leuten der Technischen Universität (TU) Darmstadt und der Gesellschaft für Informatik (GI) zur langfristigen Sicherheit von Kryptographie vertretene Auffassung nicht nur für falsch, sondern sogar für unseriös und nicht vertretbar halte.
Ich war heute auf einer Fachveranstaltung, in der es um Kryptonormen als Zukunftssicherung ging und in der vor allem die GI und ein Professor der TU Darmstadt dafür warben, sich an der Normung von Kryptographie und Begleittechniken (Verfahren, Datenformate, Protokolle usw.) zu beteiligen.
Was ich grundsätzlich für eine sehr gute Idee halte, sowas wäre sehr wichtig. Ein Hauptgrund dafür, dass Kryptographie bei uns nicht in dem notwendigen Maß eingesetzt wird ist, dass deren Anwendung zu kompliziert, undurchsichtig, instabil, fehleranfällig ist. Insofern ein sehr gutes und sehr wichtiges Thema.
Heftiges Stirnrunzeln bekam ich aber, als der Darmstädter Professor rügte, dass es keine brauchbare, zuverlässige und robuste CA gäbe, und meinte, dass die akademische Welt sich darum kümmern wolle. Denn zu meiner Universitätszeit – und nach dem, was ich so beobachte, hat sich daran nicht wesentlich was geändert – hat diese „akademische Welt” alles als unwissenschaftlich und wertlos verteufelt, was über die rein mathematischen Aspekte hinausging. Wissenschaft hatte da zu enden, wo die Formel an der Tafel steht. Alles, was mit praktischer Umsetzung zu tun hat(te), war verboten oder zumindest wertlos. Also ist die „akademische Welt” die Ursache und nicht die Lösung des Problems, sie ist die Krankheit, nicht die Medizin.
Und auch die Informatik-Ausbildung deutscher Universitäten und deren Forschungsausrichtung sind lausig, was die Sicherheit angeht. Ich kenne kein einziges Institut aus dem Dunstkreis Softwaretechnik und Programmieren, an dem Sicherheit bei der Programmierung gelehrt oder bei der Entwicklung von Programmiersprachen usw. berücksichtigt würde. Wahnsinnsfördergelder hat man etwa für die Programmiersprache Scala verpulvert und damit faktisch ein temporäres Fördermittelmonopol für die Entwicklung einer Programmiersprache aufgebaut, bei der Sicherheit überhaupt nicht betrachtet oder berücksichtigt wurde, und die so weit fortgeschritten ist, dass man das ohne Aufgabe der Rückwärtskompatiblität auch nicht mehr reinbekommt – sofern das auf der Java Virtual Machine überhaupt im nötigen Maß möglich wäre. Auch herrscht an vielen Fakultäten und Lehrstühlen die idiotisch-ideologisch-scheuklappenartige Festlegung auf Funktionales Programmieren als seligmachendes Allheilmittel, einfach weil’s das Lehren damit stark vereinfacht und verbilligt. Dass funktionales Programmieren aber mit Sicherheitsanforderungen unvereinbar ist (etwa wegen der notorischen Seiteneffektfreiheit, Sicherheit kommt nicht ohne Seiteneffekte aus) und deren zu sehr von der Maschine abstrahierter (berufsnaiver) Sichtweise Sicherheit ebenfalls verhindert, interessiert da keinen. Und einen die Sicherheit einschließenden allgemein anerkannten Algorithmenbegriff gibt es (meines Wissens) bis heute auch nicht. Und das hat die »akademische Welt« verbockt. Schon daher ist es fragwürdig, wenn nun diese akademische Welt als der Retter dessen ausgegeben wird, was sie in den letzten 25 Jahren komplett versaut hat.
Viel mehr hat mich aber ein anderer Punkt geärgert. Unter dem Schlagwort der Zukunftssicherung ging es auch darum, dass kryptographisch erzeugte Sicherheit ja so 20 oder 30 Jahre lang halten solle und deshalb präzise technische Normen notwendig wären.
Dem habe ich widersprochen.
Denn technische Normen dienen zunächst mal nur der Interoperabilität. Die Schraube passt zur Mutter eines anderen Herstellers, der Wasserhahn in das Waschbecken eines anderen und so weiter. Eine technische Norm erzeugt keine Sicherheit, etwas wird nicht dadurch sicherer, dass man es in einer Norm festgeschrieben hat. (Es kann freilich Sicherheitsvorteile bringen, wenn in der Norm wichtige Schritte stehen, an die man sich sonst nicht gehalten hätte, und die Norm besser als home brewn ist.)
Meiner Auffassung nach gibt es zwei Sorten von Kryptographie. Die Sorte, die ihr Sicherheitsziel selbst auf technischer Ebene erreicht, etwa eine Verschlüsselung. Da kommt es nicht drauf an, ob jemand anderes, etwa ein Richter, glaubt, dass die Verschlüsselung gut ist. Wenn die Verschlüsselung gut ist, kann er es auch dann nicht lesen, wenn er es nicht glaubt und es lesen will. Und die andere Sorte, die ihr Sicherheitsziel erst erreicht, wenn jemand anderes von deren Richtigkeit und Sicherheit überzeugt ist, etwa alles, was in den Bereich kryptographischer Beweise gehört. Der beste kryptographische Beweis nutzt gar nichts, wenn man damit vor Gericht nicht durchkommt.
Und da liegt die Krux. Deutsche Gerichte sind eine Tombola, man weiß nie, zu welchem Ergebnis die kommen. Meist wird irgendwie willkürlich und nach Laune oder Zeitgeist entschieden, ohne technische Aspekte zu berücksichtigen. (Wie ich schon so oft festgestellt habe, treiben die meisten Juristen keine Rechts- sondern nur Begründungsfindung.) Dazu kommt, dass die Politik wechselt und seltsame Dinge tut, etwa per Gesetz festzulegen, was kryptographisch sicher sein solle und was nicht. In der Gesellschaft entwickelt sich eine ebenso starke wie kompetenzarme, auf Ideologie basierende Technikfeindlichkeit, und schon bei von der Leyens Kinderpornosperre hat man ja gesehen, dass die, die die Macht hatten, Null Kompetenz hatten und sich aggressiv über die Kompetenz anderer hinweggesetzt haben. Wie will man unter diesen Voraussetzungen Kryptographie schaffen, auf die man sich in 20 oder 30 Jahren noch verlassen können soll? Woher will man wissen, wie in 20 oder 30 Jahren Gesellschaft, Politik und Recht aussehen? Vielleicht kann man die heutige Kryptographie bis dahin nicht knacken, aber vielleicht interessiert das bis dahin keinen mehr.
Er hielt mir entgegen, dass man dann eben Sachverständige aus den Universitäten brauche, die den Richtern erklären, was sicher und was richtig ist.
Das ist ein ziemlicher Hammer. Die Beweiskraft von kryptographischer Sicherheit soll davon abhängen, dass man von deutschen Universitäten aussagewillige befähigte und ehrliche Sachverständige bekommt – aber 20 oder 30 Jahre lang halten.
Leser meinens Blogs oder von Adele wissen ja, dass ich genau das in den letzten Jahren durchexerziert habe und in der Situation war, die Richtigkeit und Sicherheit kryptographischer Aussagen vor Gericht beweisen zu müssen. Und dass genau diese beiden Organisationen, die GI und die TU Darmstadt dabei involviert waren und komplett versagt haben.
Von der TU Darmstadt kam ein komplett falsches und nachweislich vorsätzlich falsch angefertigtes – auf gut deutsch: bewusst gelogenes – Sachverständigengutachten, und zudem die Aussage der TU Darmstadt, über keinen Professor zu verfügen, der genug Sachkunde in Kryptographie habe, um als Sachverständiger aufzutreten, obwohl man gleichzeitig behauptete, dass die Themen eigentlich sehr einfach wären. Da hat man also zu sicherheitstechnischen und kryptographischen Fragen zugunsten von Kollegen bewusst ein Gericht angelogen, und ein Nachweis gegenüber dem Gericht war nicht möglich. Kryptographisch richtige Aussagen waren wertlos, weil man mangels seriöser Gutachter deren Richtigkeit vor Gericht nicht beweisen konnte. Das Rektorat der TU Darmstadt hat seinen Professoren dnach sogar untersagt, sich dazu zu äußern.
Auch die GI – die immerhin für sich in Anspruch nimmt, die höchste wissenschaftliche Instanz in der deutschen Informatik zu sein – war nicht bereit, Sachverständige zu stellen. Man sagte mir zwar, dass mein Standpunkt fachlich völlig richtig und der gegnerische lächerlich falsch sei, aber man werde eben unter keinen Umständen gegen Kollegen aussagen.
Kryptographische Sicherheit der zweiten Sorte, also die, die davon abhängt, dass man einen Richter davon überzeugen kann, war also – wie sich ja gezeigt hat – schon in den letzten 15 Jahren wertlos und nicht »sicher«, weil nicht beweisbar. Denn der Beweis hängt nicht von der Mathematik dahinter, sondern von der Verfügbarkeit eines seriösen Gutachters ab, und der war nachweislich nicht zu finden. Von der angeblichen Beweiskraft der Kryptographie blieb nichts übrig. Einfach wertlos. Vor Gericht nicht beweisbar, weil es keinen seriösen Gutachter gab, und nicht mal fachlich-mathematisch beweisbar, weil keiner zuhören wollte und man die Korruption als Maxime gewählt hatte.
Und ausgerechnet diese beiden Organisationen, die TUD und die GI, die damals ganz bewusst und vorsätzlich gelogen und den sicherheitstechnischen Nachweis aus korrupter Kollegialität vor Gericht vereitelt haben, stellen sich nun vor Publikum und werben für Sicherheit, die 20 oder 30 Jahre lang halten soll, indem man dann Sachverständige vor Gericht holt.
Es kommt noch ein anderes Problem hinzu. Ich hatte damals, zwischen 2000 und ca. 2005 schon das Problem, dass viele der Professoren, die sich als Krypto- und Sicherheitsexperten ausgaben, tatsächlich inkompetent waren. Ein Professor, der sich als Kryptoexperte ausgab und eine dicke Rechnung stellte, konnte eine Blockchiffre nicht von einer Betriebsart unterscheiden, konnte die strittigen Papers nicht mal lesen und gab schließlich zu, dass er im Hörsaal nur Folien vorliest, die ihm jemand anderes geschrieben hat, ohne sie selbst zu verstehen. »Vorlesung« im Wortsinn eben, als ob man die Putzfrau vorlesen lassen würde. Und den hatte das Gericht selbst als Sachverständigen ausgesucht, weil er sich auf seiner Webseite als Experte ausgab. Und ein anderes Problem war, dass die wichtigen Stellen für Sicherheitsprofessuren per Frauenquote von Frauen besetzt worden waren, die sich als völlig inkompetent herausstellten. Und das ist keine Einschätzung von mir. Mir liegen schriftliche Erklärungen der Damen vor, die beide als Professorinnen des Fachgebiets IT-Sicherheit und Kryptographie auftreten und auch prüfen, dass sie das Fach nicht genug beherrschen, um sich als Sachverständige oder Prüfer dazu zu äußern. Da bestand ganz konkret und belegbar das Problem, dass Kryptographie nicht mehr nachweisbar war, weil die einschlägigen Stellen per Frauenquote von Inkompetenten besetzt wurden, die dann, als es darauf ankam, komplett versagten.
Und das Problem ist heute ja schon weit schlimmer und wird in Zukunft immer stärker werden. Der aktuelle Zeitgeist und die aktuelle Politik drücken ja gerade mit Gewalt Leute in die Professuren, die nicht nur vollständig inkompetent sind, sondern die explizit und erklärtermaßen Informatik und mathematisch oder beweistechnisch orientierte Fachbereiche aus ideologischen Gründen grundsätzlich und rundheraus ablehnen und als falsch erklären. Es gibt immer mehr Professoren in der Informatik, die alles für männlich sozialisiert und deshalb für falsch halten, was auf harte Logik, eine Unterscheidung in richtig und falsch oder überhaupt auf Technik basiert, und die jederzeit ihre Machtposition als Professoren ausnutzen werden, um gemäß ihrer Ideologie alles für falsch zu erklären. Das ist keine Vermutung, denn das tun sie ja bereits. Es ist nicht abwegig oder weit hergeholt anzunehmen, dass sie als Gutachter das schreiben werden, was sie bisher schon ständig schreiben. Und das beruht oft darauf, einfach alles technische als falsch und geschlechtsstereotypisch abzulehnen. Unsere Universitäten verblöden zunehmend, und ob die in 20 oder 30 Jahren überhaupt noch wissen, was Kryptographie ist, und wie sie funktioniert, darf bezweifelt werden. Dass die Verblödung schon die Turing-Maschine zersetzt, habe ich ja kürzlich schon beschrieben. Als wäre die Wissenschaft als Organismus von Demenz befallen, die ein Gedächtnis- und Wissensareal nach dem anderen auslöscht. Schon jetzt gibt es Informatik-Fakultäten und jede Menge Informatik-Professoren, die schon nicht mehr das beherrschen, was zu meiner Zeit Vordiplomswissen war. Ob Kryptographie dann überhaupt noch als beweisfähig angesehen werden wird, hängt dann bestenfalls noch davon ab, was tagesaktuell gerade in der Wikipedia steht.
Wie also sollte da dieser Nachweis über Sachverständige überhaupt noch funktionieren?
Sogar beim Bundesverfassungsgericht hat sich ja nun schon gezeigt, dass man mit technischen oder kryptographischen Beweisen gar nichts mehr erreicht, weil auch dort die Richter schon so ideologisiert sind, dass alles manngemachte für falsch gehalten wird und es nur noch darauf ankommt, welchem Geschlecht und welcher Minderheit der Kläger angehört. Manche Menschengruppen bekommen da immer Recht, andere gar nicht mehr. Und da ging es konkret um Kryptographie und den Nachweis der Richtigkeit, der deshalb nicht mehr erbracht werden konnte, weil da niemand mehr zuhörte und keine Sachverständigen mehr aufzutreiben war.
Sicher, ab und zu gibt es auch noch funktionierende Gerichte, die in Technikfragen gut und richtig urteilen. Beweisfähigkeit und Sicherheit liegen aber nicht schon dann vor, wenn man vielleicht Gehör findet, sondern wenn man sich vorhersagbar und zuverlässig darauf verlassen kann.
Der Nachweis, dass Kryptographie vor Gericht nicht zuverlässig beweisbar ist, ist mehrfach erbracht. Und damit ist die Kryptographie, die von der Beweisbarkeit gegenüber dem Gericht abhängt, wertlos oder im Wert stark reduziert. Gerade auch wegen des Verhaltens von TUD und GI.
Dass aber nun ausgerechnet diese beiden, die TU Darmstadt und die Gesellschaft für Informatik, sich nun öffentlich hinstellen und für Kryptographie werben, weil die 20 bis 30 Jahre sicher sein und dazu auf den Aussagen von Sachverständigen gegenüber Gerichten beruhen soll, halte ich für weit daneben und für unvertretbar. Und für Augenwischerei.
Wie ich früher in meinen Kryptoeinführungen und -vorlesungen immer gesagt habe: Es gibt keine kryptographische Sicherheitsmethode, die ein Sicherheitsproblem terminal löst. Kryptographische Methoden sind immer nur Problemverlagerungen, und ein Sicherheitsentwurf besteht immer aus der Kette gelöster und neu erzeugter Probleme, mit der man dann irgendwann außerhalb der Kryptographie landet, etwa im Bereich organisatorischer Sicherheit oder eines übernommenen Sicherheitsrisikos. Und wenn in dieser Kette Sachverständige oder Richter vorkommen, sind erhebliche Zweifel angebracht.
Man sollte sich dabei auch mal vor Augen führen, welche unterschiedlichen Sicherheitsniveaus da angelegt werden. Wer Sicherheitsdienste erbringen oder Zertifikate für qualifizierte Signaturen ausgeben will, muss sich massiv durchleuchten, überwachen, zertifizieren lassen und Sachkunde nachweisen. Obwohl die Sicherheit im Ergebnis aber mindestens genauso, eher noch viel mehr, von Sachverständigen und Richtern abhängt, werden die gar nicht geprüft oder zertifiziert. Gerade an den deutschen Universitäten können inzwischen Leute ohne jedes Grundwissen Professoren werden und sich als Sachverständige aufspielen. Schon von mehreren der professoralen Krypto- und Security-Helden habe ich herausgefunden, dass sie einfach nur Hochstapler sind und sich selbst zum Experten ernannt haben. So läuft das an deutschen Hochschulen, und so läuft es dann auch an den Gerichten.
Und die Sicherheitskette ist nur so stark, wie ihr schwächstes Glied. Und das ist an der Stelle Null.
Bevor man für Sicherheit über 20 oder 30 Jahre wirbt und trötet, und das sogar normieren will, sollte man sich lieber mal drum kümmern, wie man jetzt zeitaktuell zu beweisbarer Sicherheit kommen könnte. Es ist unverständlich, wie eine Kryptographie 20 oder 30 Jahre lang sicher sein soll, die nicht mal jetzt in diesem Moment sicher ist.
32 Kommentare (RSS-Feed)
@Hank: Hatte ich hier im Blog schon mal beleuchtet.
In einer rein funkitonalen Sprache kannst Du Schlüssel und andere Daten nicht aus dem Speicher löschen und Rechte nicht ablegen.
P.S. Was gibt’s denn da für Sprachen, bei denen die Sicherheit von vorneherein “eingebacken” ist? Mir fällt da spontan nur das obskure “E” (e-lang.org) ein. Eine auf den ersten Blick sehr funktionelle Sprache übrigens.
@Hank: Leider noch nicht viele. Am ehesten derzeit noch die Skriptsprachen. Perl hat einige Funktionen, Ruby hat diese noch vertieft, etwa die systematische Ausrichtung auf Exceptions, das Abfangen von Zahlenüberläufen und Rechenfehlern, taint-Mechanismen, brauchbare gekapselte Datentypen, aber halt auch noch nicht richtig gut.
Sicherheit braucht Nebenwirkungen, um auf die Nebenwirkungen der realen Ausführung von Programmen, ob in einer funktionalen oder irgendeiner anderen Programmiersprache, eingehen zu können. Hat Hadmut hier schon ausführlich erläutert.
P vs NP Problem. (Leicht zu finden gegenüber leicht zu checken)
Eines der ungelösten Jahrtausend Probleme des Clay Instituts.
Soweit ich weiß, hängen damit und mit unsere immer noch andauernden Unkenntnis bzw nur Teilkenntnis der Primzahlstrukturen zusammen. Vielleicht heutzutage etwas zuviel verlangt von einigen Informatikprofessoren, hier mathematische Übersicht zu haben.
Von den Genderrassen-Gesinnungsprofessuren, die sich offenbar in alle Bereiche auswuchern, ganz zu schweigen.
Gutachten sind heutzutage meist politisch und Wissenschaft wird missbraucht und beliebig verbogen. U.a. auch frei nach dem Motto wenn man etwas nicht versteht, oder auch nicht verstehen will, läge es an der Erklärung oder am Erklärenden.
Kreationistisches verschieben von Realität hat Hochkonjunktur und Menschen glauben gern an etwas, dass ihre narzisstischen Eigennutz und Selbstbequemlichkeit befriedigt – Männer wie Frauen, wobei letztete eindeutig hier die Spitzenposition zu besetzen scheinen.
Im Prinzip stimme ich Dir voll zu, aber das Problem mit den Gutachtern bei dieser speziellen Frage wird sich wohl im konkret gesteckten Zeitrahmen nicht stellen, da hier schon alle Krähen, die sich ein Auge aushacken müssten schon auf derselben Seite sind.
Von daher ist auch der scheinbar willkürliche Zeitrahmen von 20-30 Jahren erklärbar: die erwarten halt einfach, dass sie zum großen Teil noch so lange leben und Einfluss auf den Nachwuchs haben…
Aber lustig zu lesen, wie man die Elfenbeintürme vorführen kann. Weiter so!
s/Seiteneffekt/Nebenwirkung
Sorry, das ist nur so eine Sache, die mich nervt…
Hatte ich denn irgendwo »Nebenwirkung« geschrieben?
@Hadmut: jetzt verrennst du dich aber. Gerichte und Gutachter sind in jedem Land der Welt korrupt, weil der Mensch nunmal vom Affen abstammt (salopp gesagt, nicht ganz korrekt). Das heißt aber nicht, dass wir das Konzept unabhängiger Gerichte und “fachkundiger” Gutachter einfach durch was anderes ersetzen könnten. Durch was denn? Private Unternehmen?
Fry
@Fry:
> jetzt verrennst du dich aber.
Wieso denn das? Darf man keine Beobachtungen und Feststellungen mehr treffen, nur weil deren Ergebnis negativ ausfällt?
> Gerichte und Gutachter sind in jedem Land der Welt korrupt, weil der Mensch nunmal vom Affen abstammt
Das mag ja sein. Dann kann man aber doch nicht trotzdem behaupten, eine Sicherheit zu konstruieren, die 20 bis 30 Jahre halten soll und die nur auf Gerichten und Gutachtern beruht.
@Hadmut, @Hank: Das Thema FP vs. IP vs. Sicherheit hat Hadmut schon öfters in seinem Blog angesprochen. Der Dreh und Angelpunkt seiner Argumentation ist (IIRC) dass man in reiner FP keine Möglichkeit hat, a) Speicherstellen zu überschreiben und b) das Laufzeitverhalten im Sinne des Wortes “Zeitverhalten” zu kontrollieren. Beides öffnet Seitenkanäle.
Ich muss da jetzt mal ein wenig ausholen, und Hadmut, bitte korrigiere mich, wenn ich da was falsch erkläre oder verstanden habe:
Gar nicht betrachten will ich jetzt b) also Seitenkanäle die sich durch das Zeitverhalten ergeben und Dinge wie DPA und Timing-Attacken ermöglichen; die lasse ich jetzt aber mal bewusst aussen vor, weil die Gegenmaßnahmen dazu nicht wirklich formal erfassbar sind; man muss da praktisch Messen und die Teile des Systems identifizieren, die tatsächlich Probleme machen; moderne optimierende Compiler, egal für welche Sprache und Out-of-Order-Execution-Architekturen machen das Problem für statische Analyse praktisch unfassbar. Da muss man mit Profiler und Oszilloskop ran.
Zu a) wenn man eine kryptographische Routine hat (oder ein komplettes Program) die einen geheimen Schlüssel verwendet, dann muss man verhindern, dass dieser Schlüssel kompromittiert wird. Nun sind aktuelle Rechnerarchitekturen aber derart gestaltet, dass wenn man Speicher anfordert, man dort erst mal das vorfindet, was dort vom letzten mal stehen geblieben ist. Durch geschicktes Ausnutzen von Speicherallokation, -deallokation und Race-Conditions kann man so erreichen, dass man so an bestimmte Daten eines bestimmten fremden Prozesses kommt. Daher findet man in Kryptosoftware oft Konstrukte der Form (stark vereinfacht):
(Anstatt Schlüssel darf man sich im Folgenden jedwede Information denken, die nicht in “fremde Hände” gelangen darf, also nicht unkontrolliert irgendwo hingeschrieben oder erlangbar sein soll)
allocate keymem;
load key into keymem;
decrypt message with key in keymem;
overwrite key with 0s;
free keymem;
Obiges Konstrukt ist aber immer noch angreifbar: Alle modernen OS sehen den Systemspeicher in erster Linie als einen Cache für I/O-Devices an (Linux z.B. deklariert praktisch den gesamten Speicher als I/O-Cache und sbrk/mmap(0, …), sprich Speicherallokationen von Prozessen werden aus dem I/O-Cache bedient, so als ob dahinter ein Blockdevice stünde). Das vereinfacht die Implementation von Swapping natürlich ungemein, bedeutet aber auch, dass sich der Inhalt von “keymem” plötzlich im Swapspeicher wiederfinden kann. Also muss man dem OS sagen, diesen Speicher nicht zu swappen. Dafür gibt’s in Linux die syscalls “mlock” und “madvise”. Damit wird obiges Konstrukt zu
allocate keymem;
lock keymem; <<<<<<<
load key into keymem;
decrypt message with key in keymem;
overwrite key with 0s;
free keymem;
Besser, aber immer noch nicht perfekt. Denn solange der Speicher am Ende nicht mit 0en überschrieben wurde kann der Schlüssel immer noch im Speicher eines anderen Prozesses landen falls der Kryptoprozess abstürzt/gekillt wird, bevor er die overwrite-Operation ausführen konnte. Also baut man noch eine Schicht drum rum, um diese Situation abzufangen.
Wenn man das erledigt hat, stellt man fest, dass man das ganze vielleicht in einem Program verwenden will, das multithreaded ist. Also braucht man eine Critical Section um das Ganze herum, die alle anderen nicht-krypto Threads anhält, während die Krypto läuft, weil sonst Fehler in den anderen Threads einen Seitenkanal aufmachen könnten usw. usf.
Letztlich kämpft man in der praktischen Kryptologie nicht nur mit der Mathematik, die schon für sich alleine recht verzwickt sein kann, sondern auch mit ganz praktischen "Ingenieurs"-problemen.
Hadmuts Kritik an der Lehre der reinen FP besteht nun darin, dass man mit reiner FP all diese unschönen Seiteneffekte nicht abbilden kann, weil reine FP nun mal per Definition seiteneffektfrei ist (Konstruktionen wie Monaden und Mutables mal aussen vor gelassen, mit denen man dann sowas doch wieder abbilden kann). So etwas wie am Ende der Operation den Speicher mit 0en überschreiben, damit der Schlüssel später nicht in fremden Händen landet lassen sich damit nicht umsetzen.
Und natürlich kann man ähnliche Überlegungen auch auf andere sicherheitstechnische Probleme anwenden.
Kurz gesagt, Hadmut vertritt die These, dass Seiteneffektfreiheit und praktische Sicherheit sich ausschließen. (@Hadmut: soweit richtig wiedergegeben?)
Und jetzt komme ich und sage: Irrelevant! Egal wieviel Aufwand ich treibe um über kontrollierte Ausnutzung von Seiteneffekten Seitenkanäle zu schließen, es wird immer irgend eine Situation auftauchen, die alle bisher getroffenen Maßnahmen komplett aushebeln. Das obige Beispiel der Schlüsselrückgewinnung und all die Gegenmaßnahmen, bis runter zu dem "lock", dass der Schlüssel nicht auf die Festplatte swapped wird, also die noch am einfachsten zu verstehende Maßnahme wird komplett ausgehebelt, sobald man das System in einer VM laufen lässt. Entweder weil man seine Systeme in Dampf aufgehen sehen will "Cloud Computing", oder weil man einen Hochverfügbarkeitscluster betreibt um gegen Hardwareausfälle gewappnet zu sein: Jederzeit kann von so einer VM ein Snapshot gefertigt werden, und wenn das in dem Moment passiert indem ein Schlüssel im Speicher rumliegt dann landet der dadurch doch wieder auf einem Massenspeicher und all die schönen Konstrukte die man sich ausgedacht hat sind Essig. Da hätte man genauso gut alles in FP programmieren können, der Effekt wäre der selbe. Aber es muss ja noch nicht mal ein Snapshot sein; es reicht wenn die VM im falschen Moment abstürzt (z.B. weil der Kernel des darin laufenden OS einen DoS 0-day hat, der ausgenutzt wurde, o.ä.) und der Watchdog das Ding abschießt und neu startet. Der Speicherinhalt der VM liegt effektiv im Speicher des VM-Hosts, und die neu startende VM sieht dann so im uninitialisierten Speicher die Daten die vom Vornutzer-Prozess dort hinterlassen wurden; geheime Daten inklusive.
Da kann man noch so viel drum herum programmieren wie man will, mit Software, also mlocks, Critical Sections, usw. bekommt das das Problem nicht in den Griff. Genausowenig wie man ordentlichen Speicherschutz nicht ohne eine echte Memory Management Unit auf Maschinenebene hinbekommt.
Was man wirklich braucht, zumindest für Schlüssel wäre das echt mal eine Innovation, wäre in den CPUs integrierter SRAM für wirklich geheime Daten, deren Inhalt bei Anspringen der üblichen Reset- und Exception-Vektoren sofort gelöscht wird (SRAM kann man im Gegensatz zu DRAM mit einem einzelnen Steuersignal im Bulk definiert löschen) und deren Zugriff an den Zustand des Prozess-Kontext gekoppelt ist, sodass nur der Prozess darauf zugreifen kann (durch Hardware reglementiert), für den eine entsprechende Zuordnung angelegt wurde. VMs müssten das entsprechend umsetzen, im Idealfall, indem die Funktion an diese Hardware des Host-Systems durchgereicht wird.
Gibt es einen solchen, direkt nutzbaren Security-Speicher, kann man sich auch das locken, die Critical Sections usw. sparen, weil man dann endlich mal Nägel mit Köpfen gemacht hat. Und für Hochsicherheitsanwendungen gibt es ja auch CPUs, die all das bieten. Natürlich hat diese Hardware dann auch oft Bugs, mit denen man dann doch an den Schlüssel kommt (der Münchner CCC kann da eine schöne Anekdote beisteuern, wie eines seiner Projekte einen derartigen Hardware-Bug in einer CPU von NXP aufgedeckt hat), aber letztlich wird man das Problem nicht auf der Ebene der angegriffenen Software lösen können, weil man die immer in eine Situation treiben kann, die nicht vorhergesehen wurde.
Nur wenn durch die Hardware (oder meinetwegen durch Mikrocode oder ähnlich Fundamentales) Werkzeuge bereitstehen, mit denen man sich effektiv gegen eine bestimmte Sache schützen kann, indem auf unterster Ebene keine undefinierten Zustände erlaubt sind (z.B. Speicher dessen Inhalt am Ende überschrieben werden soll, dann aber durch einen undefinierten Abbruch das Programm nicht mehr dazu kam) kommt man überhaupt in die Nähe davon, es als wirklich "SICHER" bezeichnen zu können.
Von daher sehe ich die ganze Argumentation "FP vs. Imperativ im Kontext von Sicherheitsbetrachtungen" als müßig an. Angenommen man hat "sichere" Hardware zur Verfügung, oder eine "abgesicherte" auf Systemebene geschriebene Softwareschicht für vertraulichen Speicher, dann könnte man diese z.B. (man nehme Haskell an) per FFI einbinden und ausschließlich durch einen an einen Typen bereitstellen, der an einen bestimmten Monaden oder Arrow gekoppelt ist und für den gilt, dass alle Operationen auf diesen Typen durch einleitende (auf gesichertem, vertraulichem Speicher initialisierend, etc.) und abschließende (mit 0en überschreibend, Inhalt vernichtend, etc.) Aktionen auf dem Monaden oder Arrow eingeschlossen werden müssen. Der daraus compilierte Code wird (vorausgesetzt Compiler und Runtime sind in dieser Hinsicht fehlerfrei) genauso sicher, oder unsicher sein, wie explizit, imperativ abgesicherter Code. Da aber ein statisch abgesicherter Typ, wie von mir vorgeschlagen alle Vor- und Nacharbeiten erzwingt werden so programmierte Anwendungen weniger Flüchtigkeitsfehler in dieser Hinsicht aufweisen.
Natürlich besteht Sicherheit aus weit mehr als nur diesem kleinen Aspekt der Seitenkanal-Problematik (ich habe mir das jetzt herausgegriffen, weil es mit noch am einfachsten zu verstehen ist, wenn man FP vs. IP diskutiert). Aber letztlich wird man immer irgend einen Weg finden alleine durch Software auf der Ebene des angegriffenen Programms abgesicherte Systeme anzugreifen, egal ob FP oder IP. Und wenn man auf niedrigerer Ebene die entsprechenden Werkzeuge anbietet (MMU, vertraulichen Speicher, etc.) kann man diese auch in FP sicher nutzbar machen.
@datenwolf:
> @Hadmut: soweit richtig wiedergegeben?
Fast, nicht ganz. Zu sehr eingeschränkt. Es ging nicht darum, FP der imperativen Programmierung gegenüberzustellen. Außerdem habe ich viele Einwände auf unterschiedlichen Ebenen, wovon die Sache mit den Seiteneffekten nur einer dieser Einwände ist.
Übrigens ist das mit dem Swappen zwar ein guter Gedankengang, aber leider nicht ganz Unix-Profi. Man kann nämlich Speicher auch so anfordern, dass er dann nicht rausgeswappt wird, was man im Sicherheitsbereich natürlich so machen sollte. (Ist allerdings auch nicht mehr so ganz auf dem Stand der Zeit, denn das lässt sich nicht durchhalten, weil inzwischen viele Rechner in hibernate-Zustände gehen können oder in virtuellen Maschinen laufen, wogegen sich Prozesse nicht ohne weiteres wehren können.)
Allerdings ist das Auslesen von Festplattensektoren sicherheitstechnisch etwas anderes als das Auslesen von Speicher. Für ersteres braucht man Root-Rechte (oder eben einen weiteren Exploit), während das Auslesen des Hauptspeichers bei einem Dämon schon über irgendeinen Pufferüberlauf oder eine Schlampigkeit laufen kann.
Davon abgesehen folge ich Dir bei Deiner irrelevanz-Argumentation gar nicht. Freilich gibt es immer einen Angriff, egal wieviel Aufwand man treibt. Daraus aber irrelevanz zu folgern ist grundfalsch, denn Sicherheit ist ja keine Ideologie, sondern eine Optimierung. Und das, was man vernünftig machen kann, sollte man tun. Nach Deiner Logik dürfte es auch keine Straßenverkehrsregeln, keine Bremsen und keine Sicherheitsgurte geben, denn egal wie man sich anstrengt, es wird immer irgendwo krachen.
Außerdem machst Du noch den logischen Fehler, dass Du die Sache mit dem Speicher nur auf die Maschinenebene und nicht auch auf die Programmebene beziehst. Denn selbst wenn man die physikalische Maschine und den Speicher außer Acht lässt und das nur aus dem FP-Modell heraus betrachtet, hast Du ein Sicherheitsproblem, weil es generell kein Löschen, sondern nur Vergessen gibt, und weil jede Operation sofort Kopien anlegt. Man hat im FP eigentlich keine Kontrolle darüber, wieviele Kopien eines Schlüssels selbst aus FP-Sicht da herumspuken. Selbst dann, wenn man innerhalb des regulären Programmlaufs bleibt, kann man Schlüssel nicht zuverlässig löschen. Man kann in der FP nicht programmieren, dass die Verbindung zur Gegenseite jetzt abgebaut und der Schlüssel gelöscht wird, damit man sie nicht mehr verwenden kann, denn das wären ja Seiteneffekte. Im Prinzip könnten da noch Kopien der Verbindungshandles und der Schlüssel im Programmlauf herumliegen, die man nicht eingesammelt bekommt.
Und dann gibt es eben noch ganz viele andere Argumente, etwa dass die Softwaretechnik da komplett versagt usw.
@datenwolf
Ich freu mich schon auf den hardware angriff:
Den SRAM speicher durch ein modul austauschen, dass alles was dort reinkommt kopiert und an den (meinen) drucker schickt
Klar, der Angriff ist sehr kompilitziert zum durchführen – aber ob das wirklich eine wesentlich höhere hürde ist als ein VM host system zu übernehmen..
@Alex: Wie eben erläutert betrifft es zwar auch, aber nicht nur den Zugriff auf das RAM. Auch der Programmlauf selbst kann zum Sicherheitsproblem werden, wenn es kein Löschen von Schlüsseln und anderen Daten gibt.
Hadmut,
kannst du etwas zur Kryptographiekompetenz von Prof. Hannes Federrath sagen? Ich erinnere mich dunkel, dass du über ihn schon mal was geschrieben hattest.
Hatte schon Veranstaltungen bei dem, schien mir kompetent, aber nachdem ich hier soviel über den Zustand der deutschen Forschung im Security- Bereich gelesen habe, frage ich mich, ob dir zu ihm auch was einfällt, bevor ich noch mehr bei ihm belege.
@infostudent:
> kannst du etwas zur Kryptographiekompetenz von Prof. Hannes Federrath sagen?
Nein. Mit dem hatte ich noch nichts zu tun. Mir fällt dazu jetzt zwar dumpf ein, dass ich mal einem Prof wegen des Verdachts nachgegangen bin, dass derjenige in einem seiner Paper über X-Pire! aus meinem Blog abgeschrieben hatte, weiß jetzt aber nicht mehr auswendig, ob der das war. Sonst fällt mir zu dem nichts ein.
@Hadmut:
> aber leider nicht ganz Unix-Profi. Man kann nämlich Speicher auch so anfordern, dass er dann nicht rausgeswappt wird, was man im Sicherheitsbereich natürlich so machen sollte.
Du meinst vermutlich das mmap-Flag “MAP_LOCK”, das aber leider von einigen Kerneln (teils versionsabhängig) ignoriert wird. mmap gefolgt von “mlock”, oder vor dem mmap ein “mlockall(MCL_FUTURE)” sind zuverlässiger. Und “malloc” sollte man meiden, weil da u.U. die libc eine Schicht dazwischen gebaut hat, die nach einem “free” Speicher wiederverwendet, anstatt dem OS zurückzugeben.
> und weil jede Operation sofort Kopien anlegt
Logisch gesehen ja. Praktisch gesehen versucht z.B. der GHC Kopieroperationen zu vermeiden wo es geht. Und wie gesagt, es ist in Haskell möglich per FFI Datentypen anzubieten, die nur innerhalb eines transaktionalen Monaden oder Arrows verwendet werden können und deren Implementierung auf Systemebene dafür sorgt, dass alle Kopien am Ende mit 0 überschrieben werden, bevor der Speicher freigegeben wird.
> Man kann in der FP nicht programmieren, dass die Verbindung zur Gegenseite jetzt abgebaut und der Schlüssel gelöscht wird, damit man sie nicht mehr verwenden kann, denn das wären ja Seiteneffekte.
Wenn man Monaden und Arrows als “rein” annimmt (zugegeben, daran scheiden sich die Geister), dann geht das durchaus. Man kann ohne weiteres mit Monaden und Arrows Transaktionen bauen und das per FFI auf Systemebene als exakt definierte Allokation, Verarbeitung, Überschreiben/Löschen und Deallokation implementieren. Gerade wenn man interaktive I/O macht oder ein Programm über ein Netzwerk mit einer Gegenstelle redet muss das Laufzeitverhalten vorhersehbar sein, in einer bestimmten Reihenfolge und mit definierten zeitlichen Rahmenbedingungen ablaufen (sonst läuft man in Timeouts u.ä.).
> Daraus aber irrelevanz zu folgern ist grundfalsch, denn Sicherheit ist ja keine Ideologie, sondern eine Optimierung.
Das habe ich so nicht gemeint. Worauf ich hinauswollte ist, dass man für jedes Paradigma immer irgend einen Hebel finden kann, über den man es brechen kann. Wenn man aber seine geistigen Kapazitäten darauf aufwendet die Paradigmen gegeneinander auszuspielen kommt man nicht wirklich weiter. Sich über Sicherheit Gedanken zu machen ist wichtig. Ich bin momentan im Medizintechnikbereich tätig und Sicherheit ist da die oberste Maxime (es ist übrigens grausam, was in dem Bereich auch an Unwissen unterwegs ist, unten schreibe ich noch eine Anekdote dazu).
Kurz gesagt, ich finde es irrelevant über die FP-Lastigkeit aktueller Informatik-Studiengänge zu lästern. Stattdessen fände ich es sinnvoller, sich damit zu beschäftigen, wie man die Herausforderungen, die Sicherheit erfordert auch in FP erfassen und bewältigen kann. z.B. in dem man Datentypen anbietet, die nur in Hochsicherheitsspeicher (der nur dem Programm(teil) zugänglich ist, der ihn angefordert hat) angelegt werden. Und wie man in der FP transaktionale Verkettungen von Aktionen dazu benutzen kann, Seitenkanäle zu stopfen.
> Im Prinzip könnten da noch Kopien der Verbindungshandles und der Schlüssel im Programmlauf herumliegen, die man nicht eingesammelt bekommt.
Rein theoretisch, in einer fehlerfreien (ja, ich weiß, gibt es nicht) Maschine wäre das kein Problem, da der von diesen Kopien belegte Speicher von keinem weiteren Programmteil mehr gesehen wird (klassisches Speicherleck) und man in FP ja eh nicht mit Pointern herumpfuschen kann. Praktisch wäre es so, dass die FFI-Seite von Sicherheitsdatentypen ihren Destruktor spätestens vor der Beendigung des Prozesses aufgerufen bekommt. Man könnte das sogar mit einem Kapsel-Prozess kombinieren, der sich per Debug-API an den Kryptoprozess ranklemmt und im Falle eines undefinierten Abbruchs (der in reiner FP ja eigentlich nicht passieren darf, aber dann kommt ein Quantum kosmische Strahlung…) und im Notfall aufräumt. Und hätte die verwendete Rechnerarchitektur Sicherheitsspeicher, der direkt von einem entsprechenden Datentypen abgebildet wird, wär’s eh kein Drama.
> während das Auslesen des Hauptspeichers bei einem Dämon schon über irgendeinen Pufferüberlauf oder eine Schlampigkeit laufen kann.
Und ein Theoretiker würde dem entgegenhalten, dass es in einem rein FP programmierten Daemon keine Pufferüberläufe gibt und Schlampigkeiten durch starke Typensystem verhindert werden.
Wie gesagt, auch mit FP kann man den sicheren Umgang mit Speicher abbilden, wenn man nur genug Phantasie mitbringt. Und meine Lieblingssprache diesbezüglich ist nun mal Haskell, nicht obwohl, sondern gerade weil diese “lazy” ist und Speicher herumgammeln lässt und die Probleme damit offen zu Tage treten.
Aber ganz praktisch gesehen sehe ich das Problem “vertrauliche Daten liegen im Speicher herum” nicht gerade als das drängenste aller Probleme an. Ja, darüber muss man sich Gedanken machen, aber die tatsächlichen Sicherheitsprobleme die einem begegnen und bei dem einem die Haare zu Berge stehen und noch viel schlimmer, das Schlangenöl das einem da verkauft wird sind viel trivialer. Und damit komme ich zu meiner Anekdote:
Als Physiker (spezialisiert auf Laser- und Kernphysik) arbeite ich in der Uni mit meinen Kollegen an der Weiterentwicklung ophtalmologischer (=Augenheilkunde) Diagnoseverfahren; für einen Laser-Physiker bietet sich das Auge an, da kann man gut mit Licht hinein. Für die Augenklinik haben wir einen Prototypen eines solchen Diagnosesystems gebaut das demnächst in die klinische Erprobung gehen soll. An uns selber dürfen wir es testen (macht sehr schöne Bilder), aber damit wir davor Patienten setzen dürfen muss es durch eine komplette Medizingeräte-Zertifizierung. Ich bin dabei für Signalverarbeitung und Software zuständig und bei einem Termin mit einem externen Berater kam es zu folgendem Gespräch (in Klammern meine Gedanken):
B: “Für die einzelnen Teile der Software muss sichergestellt werden, dass diese klar voneinander separiert sind also sich nicht gegenseitig negativ beeinflussen können”
Ich: “Wie sieht das üblicherweise in der Praxis aus.” (ich dachte da an Separation in Prozesse, in verifizierbare Container gekapselte IPC, Sandboxing, usw.
B: “Aufteilung in strikt voneinander getrennte Klassen, alle Membervariablen ‘private’ deklarieren und keine ‘friends’ verwenden.”
Ich: (Hä?!) “Und was genau soll das bringen, die teilen sich doch immer noch den gleichen Adressraum. Wenn da ein Out-of-Bounds-Fehler auftritt hilft das doch überhaupt nicht.” (wir haben für den Typen zu viel Geld bezahlt.)
B: “Dann packen sie es in verschiedene DLLs”
Ich: *ungläubiger Blick* (Ich will mein Geld zurück!)
Das ist die Ebene auf der momentan “Sicherheit” betrieben wird. Und solange das Wissen um solche Probleme, das ja eigentlich Grundwissen sein sollte, es aber leider nicht ist, bei den Leuten, die sich damit auskennen sollten verankert ist, sind Probleme der Art “wie bekomme ich meine Daten in FP vertraulich verarbeitet” interessante, aber derzeit uninteressante Nebenkriegsschauplätze. Das wahre Gemetzel findet ganz wo anders statt. Wenn ich an das Passwort von jemandem kommen will, dann rufe ich im Sekretariat an, tue so, als wär ich ein Techniker und frage den/die/das Sekretär/-In (ein bißchen Gender muss sein 😉 ) nach dem Code der auf dem Post-It unter der Tastatur oder am Bildschirm steht.
@Alex: Ich denke da an speziellen SRAM der direkt auf dem CPU-Die sitzt. Ein paar kiB bis MiB könnte man da schon unterbringen und den bekommt man nicht so ohne weiteres ausgetauscht. Da müsste man schon die komplette CPU austauschen. Aber sobald man ein System auf der Hardware-Ebene vor Angriffen schützen will steht man eh vor einem ganz anderen Problem.
“Letztlich kämpft man in der praktischen Kryptologie nicht nur mit der Mathematik, die schon für sich alleine recht verzwickt sein kann, sondern auch mit ganz praktischen “Ingenieurs”-problemen.”
Wie groß ist die Chance, dass in einem Unternehmen sowohl ein FP-Fan als auch ein Praktiker beide im selben Team angestellt sind und auch zusammenarbeiten können, ohne den Chef beim Verkaufen zu stören? Viel wahrscheinlicher ist es, dass sich alle drei Parteien in ihrer Opferrolle verkriechen. Das Bohren harter Bretter hat ausgedient.
Der Praktiker ist für die Fehler zuständig, der Theoretiker für die Ausreden ind der Chef für’s liebe Geld.
@datenwolf
OMFG,
ich hoffe ich habt den Typen feuern lassen, so einem am eigenem Auge herumlasern zu lassen ist nicht spaßig.
Hadmut gehört als “Merkelflüsterer” in die Bundesregierung! ;-P
Kryptologen und auch die Juristerei haben immer wieder den
Status von Magiern.
Reißt man den Protagonisten nämlich die Roben runter,
erkennt man, das die darunter verborgenden Zauberstäbe
auch nur Wasser verspritzen. 😉
@datenwolf,
mit welchen Protokoll kann man Papierkörbe kryptografisch sichern? 😉
B.
@Hadmut: Du hast erwähnt, dass du Kryptoeinsteiger-Vorlesungen gehalten hast. Gibt es dazu die Folien/Skripte noch irgendwo?
Was würdest du jemandem empfehlen, der sich hier weiterbilden will?
@M:
> Du hast erwähnt, dass du Kryptoeinsteiger-Vorlesungen gehalten hast. Gibt es dazu die Folien/Skripte noch irgendwo?
Nein, das Zeug hab ich nicht mehr. Das war damals sowieso fast alles noch handgeschrieben auf Plastikfolie und teils auch aus Institutsbeständen entnommen, teils direkt an die Tafel geschrieben.
Ist auch zu lange her, als dass ich das noch alles zusammenbringen würde.
Viele Probleme (Bugs / Crashes) gehen ja gerade auf Seiteneffekte zurück.
Daher sind diesbezüglich FP’s wesentlich besser, insbesondere, wenn sie auch noch mit einem brauchbaren Typsystem daherkommen.
Das Argument mit dem Löschen der zu sichernden (im Sinne von wieder zu löschenden) Daten ist allerdings sehr einsichtig.
Nur sind nicht alle funktionalen Sprachen auch ‘purely functional’, und manche bieten daher auch in-place-Modifikationen in speziellen Bereichen an. Ocaml hat zum Beispiel References und die Strings lassen sich auch in-place ändern.
Daß Scala und das drunter liegende Java nicht sehr vertrauen erweckend ist, sehe ich genauso.
Daß Perl bzgl. sicherer Programme brauchbare Sprache sei, halte ich für ein Gerücht. Nachdem ich mir OCaml rein gezogen hatte, war mir klar, was Perl für eine Grütze ist.
(Benutze ich hin und wieder trotzdem.)
Das Problem mit Überlauf von z.B. Integerwerten:
Das hat OCaml leider nicht. Aber einen eigenen Datentyp bzw. Modul dafür zu bauen ist sicherlich kein großer Aufwand. Das wunderbare Typsystem von OCaml macht das sehr einfach.
Das generelle FP-Bashing ist hier also nicht sinnvoll.
Das Argument bzgl. in-place-Modifikation bestätigt ja meine Entscheidung, mich für das undogmatische OCaml entschieden zu haben (statt z.B. das eher dogmatische ‘purely functional’ Haskell).
@hadmut: “Und dann gibt es eben noch ganz viele andere Argumente, etwa dass die Softwaretechnik da komplett versagt usw.”
Ich kann nicht nachvollziehen, as Du damit meinst.
Erläutere das doch mal…
Eine Anmerkung zum Thema FP:
Hier wird davon ausgegangen, das Speicher ohne Überschreiben freigegeben wird. Das ist aber nur eine Form der Implementierung. Man kann unter Verlust von Verarbeitungsleistung natürlich bei der Garbage Collection, beim Freigeben und beim Ende des Programms den Speicher mit Nullen überschreiben.
Letztendlich ist ein von aussen zugängliches Verschlüsselungssystem niemals sicher vor “gestohlenen” Schlüsseln. Es kann schwieriger oder einfacher sein, aber dicht wird es nicht. Schwierig wäre z.B. wenn der Schlüssel direkt in den Algorithmus eincompiliert wird und die Anwendung dann das Programmteil lädt. Dann muß man den Schlüssel anhand des Assemblercodes ermitteln, was nach der Optimierung nicht mehr ganz trivial ist.
Weitere Anmerkung zur Sicherheit.
Die fehlende Schulung in Programmiersicherheit ist mir auch aufgefallen. Wer hat in der Uni schon mal von MISRA gehört ? Wir hatten da noch nicht mal ein Angebot, allerdings war die Unistandardsprache noch Modula-2, wo einige der in C üblichen Probleme ja gar nicht auftreten.
Man kann damit zumindest ein Bewußtsein für unsicher Konstruktionen schaffen. Damit sind ausdrücklich auch Konstruktionen gemeint, die üblicherweise fehlgenutzt oder mißbraucht werden. Auch bei nichtbestimmungsgemäßen Gebrauch sollten Softwaremodule nicht gleich zusammenfallen, wenn dem nicht andere Designziele, wie maximale Geschwindigkeit oder Platzsparsamkeit, entgegenstanden.
@.O: In Haskell gibt es auch “mutable” Datentypen. Ich habe übrigens auch mit OCaml angefangen funktional zu programmieren, bin dann aber bald bei Haskell gelandet (auch wenn ich die RT von OCaml ziemlich cool finde).
@DavidXanatos: Externe muss man nicht “feuern”. Abgesehen davon entwickelte der nichts, sondern wurde für die zertifizierende Dokumentation eines bereits existierenden Systems hinzugezogen und um Dinge aufzuzeigen die zu ändern sind. Viel bedenkenswerter finde ich, dass anscheinend im Bereich der Medizintechnik die für die Zertifizierung zuständigen Leute nicht fallabhängig analysieren, sondern einfach nur einen Checklisten Cargo Cult betreiben. Aber keine Sorge, schon aus Eigeninteresse hat das System mehrere unabhängige, passive Sicherheitselemente. Ich setze mich jederzeit als Testperson vor das System.
Das ist nicht speziell auf kryütographie bezogen, aber generell Sicherheit von einigen Sprachen:
Sécurité et langage Java
http://www.ssi.gouv.fr/fr/anssi/publications/publications-scientifiques/autres-publications/securite-et-langage-java.html
LaFoSec : Sécurité et langages fonctionnels
http://www.ssi.gouv.fr/fr/anssi/publications/publications-scientifiques/autres-publications/lafosec-securite-et-langages-fonctionnels.html
@datenwolf: mutable datatypes sind rel. neu in Haskell. Als
ich es mir damals angeschaut hatte, war Haskell zwar schon recht
brauchbar, aber solche Datentypen gab es damals noch nicht. Da hat
sich einiges getan mittlerweile. Haskell ist schon ziemlich cool,
auf jeden Fall. Schau ich mir irgendwann auch nochmal genauer an…
mich haben damals die Monaden abgeschreckt… und nur mit Hugs zu
arbeiten (Empfehlung eines Fachbuch-Autoren), war für den Einstieg
zwar ganz brauchbar, aber richtige Anwendungen muß man schon
kompilieren. Da war mir die Einstigesschwelle zu groß,
insbesondere, weil Haskell damals noch Performance-Probleme hatte.
Bevor ich mir Haskell aber erneut und dann komplett rein ziehe,
muss ich erst mal mein OCaml-Wissen updaten. OCaml hat seit einer
Weile auch ‘first class modules’ und GADTs. Die muss ich mir erst
mal rein ziehen, dann mal schauen, was als nächstes kommt. @Hadmut:
“Softwaretechnik” die da versagen soll. ?! Bei den funktionalen
Sprachen (mit starkem Typsystem) kann man allerlei “Späßchen”
machen. Man kann Programme formal prüfen, wie z.B in der Mathematik
die vollständige Induktion, geht dann auch mit Programmen. Und
Rekursionen kann man da auch gut nutzen, ohne daß einem der Stack
um die Ohren fliegt… es gibt da allerlei Möglichkeiten, die in
imperativen Sprachen so nicht gehen. Fehlende Seiteneffekte erhöhen
die Programmsicherheit im Allgemeinen. Da man lokal variablen
generiert, die nur im jewiligen Environment und Unterenvironment
sichtbar sind, hat man automatisch Kapselung. Wer wirklich
Seiteneffekte mag – und zwar ganz prinzipiell-, schwört auf globale
Variablen in imperativen Sprachen. Am besten alle Variablen aller
Funktionen global machen. Dann hat man viel Spaß mit
Seiteneffekten. 😉 (Ja, klingt vielleicht polemisch, aber das war
die passende Antwort auf Deine FP-Polemik 😛 ) Hier noch ein paar
Links zu FP proofs: http://proval.lri.fr/itp-fun.en.html
http://de.wikipedia.org/wiki/Coq_%28Software%29 (Gibt noch weitere
Links, aber die Suchmaschinen schmeissen mir heute nur wenig
brauchbares raus… war schon mal besser, was man da so finden
konnte.)
Übrigens fände ich es eine Neuigkeit, wenn funktionale Sprchen tatsächlich so verbreitet unterrichtet werden, wie Hadmut es hier moniert.
Zum Beispiel habe ich mich doch schwer gewundert (eigentlich aufgeregt) darüber, daß man an eingen Unis, wo ich mal im Mathestudiengang geschaut habe, was die so für Kurse anbieten, daß da imperative Programmierung (Java-Dreck) und allerlei anderer Bullshit verlangt wird, obwohl dch funktionale Programmierung viel besser zur Mathematik passt, als der imperative Kram.
Aber man will als “moderne Uni” wohl immer nah am Markt sein, und da Meint man wohl mit Imperativer Programmierung, insbes. Java, gut aufgestellt zu sein.
Mich wundert also schon, wie Hadmut zu der Auffassung kommt, überall würden funktionale Programmiersprchen bevorzugt werden.
Eigentlich sollte man alle Programmierparadigmen in der Uni lernen, aber je nach Sudiengang diejenigen, die inhaltloch besser passen. Marktkonformität kann man dann ja in zusätzlichen Lerneinheiten noch nachziehen, als ausgebildeter Informatiker sollte man ohne weiteres auch weitere Sprachen sich aneignen können, wenn die Usbildung gut war und der Grips ausreicht.
Wo ist da der Konflikt zw. Sicherheit und funktionaler Programmierung? Wo braucht Sicherheit Nebenwirkungen? Gibt’s da ein Paper?