Seufz ... Den Unterschied zwischen "verified" und "proven" ist Dir bekannt?
> |We, the designers of Rabbit, hereby state that no hidden weaknesses have
> |been inserted by us in the Rabbit algorithm.
> |The key expansion stage guarantees a one-to-one correspondence be-
> |tween the key, the state and the counter, which prevents key redun-
> |dancy. It also distributes the key bits in an optimal way to prepare
> |for the the system iteration.
>
> Hatte ich bereits gepostet.
>
> Es wird die Korrektheit einer Implementation nachgewiesen.
Nein, es wird *verifiziert*, nicht *bewiesen*.
> Und es wird ausgesagt, daß alle denkbaren Zwischenwerte bei den
> Testvektoren
> ebenfalls Übereinstimmen würden (one-to-one correspondence).
> Immer wieder lesen - vielleicht kommt's dann irgendwann.
"Würden" heißt nicht "sind". Testen heißt eine Stichprobe nehmen und
wenn Du Dich mal mit Statistik und Stichprobeln beschäftigst, wirst Du
feststellen, daß zu jeder Stichprobengröße ein "Vertrauensintervall" für
den mit Hilfe der Stichprobe bestimmten Wert gehört, also ein Bereich,
innerhalb dessen der Wert liegen wird.
Gehen wir hier davon aus, daß Du 100% Sicherheit haben willst, bekommst
Du mit einer Stichprobe eben nur einen Bereich *um* die 100% und da es
mehr als 100%ige Sicherheit nicht geben wird, eben einen Bereich
unterhalb der 100%.
> Auch folgende Übersetzung hatte ich bereits gepostet:
> o Zuerst steht da, daß Test-Vektoren zum Testen der Übereinstimmung
> nachfolgend vorhanden sind.
> o Der zweite Satz sagt aus, daß die Korrektheit des Codes auf
> unterschiedlichen Plattformen
> . nachgewiesen wird durch generieren und vergleichen von Test-Vektoren.
>
>>>>> Diese Aussage wiederum beweist die Inkompetenz derer, die das
>>>>> ignorierten.
>>>>> Warum?
>>>>> Es geht um den Beweis einer korrekten Implementation!
>>>>
>>>> Genau, und die kannst Du NIEMALS durch einen Test BEWEISEN.
>>>
>>> |This is a set of test vectors for conformance testing,
>>>
>>> Die Entwickler von kryptographischen Algorithmen haben das aber
>>> ausgesagt.
>>> Willst Du denen widersprechen?
>>
>> Nein, ich will ihnen nicht widersprechen, daß dies Test Vektoren für
>> das "conformance testing" sind. So ein Test *beweist* eben NICHT die
>> Korrektheit eines Codes sondern nur, daß dieser gewissen Standards
>> entspricht:
>
> Doch, entsprechende Aussagen der Entwickler postete ich oben in
> Wiederholung.
> Du widersprichst den Entwicklern wiederholt.
Nunja, schau'n 'mer mal. Unser Ältester hat mich auf die Webseite von
Mette Vesterager verwiesen, er ist da etwas flotter mit, so etwas im
akademischen Umfeld zu finden als ich. Ich habe Mette dann auch mal
angeschrieben, mal sehen, was sie dazu sagt.
> |The correctness of the code on different platforms is verified by
> generating and comparing test vectors.
Wieder dieses Wörtchen *verified* und NICHT *proven* ...
... weil nicht zu Deiner Argumentation passend.
>> Auch der Wikipedia-Artikel
>>
https://en.wikipedia.org/wiki/Conformance_testing sprint nicht von
>> "correctness" sondern nur von "performs according to its specified
>> standards.".
>
> Irrelevant.
> |The correctness of the code on different platforms is verified by
> generating and comparing test vectors.
*verified*
> Diese Aussagen sind aus der Dokumentation der aufgelisteten
> kryptographischen Algorithmen.
> Die von Dir gegebenen Dokumentationen sind _nicht_ aus dieser Menge -
> und daher irrelevant!
... weil Deiner Argumentation widersprechend.
Ganz einfach gesagt: es ist mir völlig wurscht, was die Entwickler
*behaupten*, wenn sie es denn überhaupt tun. Fakt ist, daß es in der
Informatik gar nicht mehr diskutiert wird, ob man mit Testen die
Korrektheit *beweisen* kann, es ist Konsens, daß dem NICHT so ist.
>> Wie gesagt/geschrieben: Man kann mit einem noch so guten Test nicht
>> die Korrektheit *beweisen". Man kann sein vertrauen darin durch immer
>> längeres Test immer weiter vergrößern, eine 100% Sicherheit gibt kein
>> Test!
>> Durch das hinzufügen von noch mehr Tests wirst Du Dich dem Ziel "100%
>> Korrektheit bewiesen" ständig asymptotisch annähern, es aber nie
>> erreichen.
>>
>> Im Wikipedia-Artikel zu "Software Testing" steht auch genau drin:
>> "understand the risks of software implementation." und weiter
>> "Software testing can provide objective, independent information about
>> the quality of software and risk of its failure to users or sponsors"
>> Da steht also eindeutig, daß es Risiken gibt (mir fällt kein anderes
>> Risiko ein als daß der Code Fehler enthält) und man kann durch Testen
>> diese *Risiken* erkennen und das Vertrauen erhöhen.
>
> Alles irrelevant.
> Es geht um die Korrektheit einer Implementation der aufgeführten
> kryptographischen Algorithmen.
... undd die kann man mit Testen NICHT *beweisen*.
Man kann die Korrektheit des Algorithmus mit mathematischen Methoden
beweisen und ich gehe stark davon aus, daß die Entwickler das getan
haben, sonst ist der ganze Rabbit Algorithmus für dir Tonne.
Danach will man sicherstellen, daß eine Implementation fehlerfrei ist
und, da man den mathematischen Beweis nicht nochmal und nochmal und
nochmal für jede Implementation machen will, setzt man auf Tests um das
zu *verifizieren*.
>>> 'conformance' heißt 'Übereinstimmung'.
>>> Wenn Test-Vektoren Übereinstimmung erzielen, ist eine Implementation
>>> korrekt.
>>
>> Übereinstimmung womit?
>
> Mit der Ausgabe des jeweiligen Algorithmus', mit der zugehörigen response.
... ausschließlich für die gegebenen Werte des "test vectors". Für
Werte, die NICHT in den "test vectors" sind, kann man das zwar annehmen,
und es wird in den allermeisten Fällen auch so sein, aber *beweisen* tut
es das nicht.
>>> Deren Korrektheit ist durch eine Übereinstimmung _bewiesen_.
>>> Das sagen die Entwickler aus!
>>> Und Punkt.
>>
>> Tja, dann glaube das bitte weiter.
>
> Ich habe allen Grund dazu:
> |The correctness of the code on different platforms is verified by
> generating and comparing test vectors.
*verified*, nicht *proven*.
>>>>> Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung
>>>>> ergaben.
>>>>
>>>> Nein, dadurch ist nur gegeben, daß der Code bei der Durchführung der
>>>> vorgegebenen Berechnungen die erwarteten Ergebnisse liefert. Es ist
>>>> dadurch niche bewiesen, daß der Code bei der Durchführung anderer
>>>> Berechnungen, z.B. wenn andere Eingabeparameter vorgegeben werden,
>>>> immer noch die erwarteten Ergebnisse liefert.
>>>
>>> Falsch.
>>> Die Entwickler haben geeignete Tests vorgegeben, um die Korrektheit
>>> beweisen zu können.
>>> Die Entwickler wissen, daß wenn alle Tests Übereinstimmung ergeben,
>>> auch alle weiteren
>>> denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden.
>>
>> Das heißt, sie können ganz genau angeben, wie viele Tests und mit
>> welchen Werten sie diese Tests durchführen müssen, um die Korrektheit
>> zu 100% zu beweisen?
>> Ich behaupte, daß ihnen bewußt ist, daß dies nicht möglich ist.
>
> |The correctness of the code on different platforms is verified by
> generating and comparing test vectors.
> Willst Du irgendwann solche Aussagen der Entwickler respektieren?
Du verdrehst ihnen die Worte im Mund und machst aus "verified" ein
"bewiesen".
>>> Die Entwickler kennen ihre Entwicklung in dieser Hinsicht ganz genau.
>>> Schließlich sind die Algorithmen deterministisch.
>>
>> *Jeder* auf einem Computer implementierter Algorithmus ist
>> deterministisch.
>
> Ja.
> Aber ich meine selbstverständlich, daß die Ausgabe-Sequenzen
> der kryptographischen Algorithmen deterministisch sind.
> Gleicher Key - gleiche Sequenz.
> Wurde bereits durchgekaut.
Ja, eben mathematisch-logisch nur für die Keys, die im "test vector"
sind, und NICHT für alle anderen Keys, die NICHT im "test vector" sind.
Daher "verified", nicht "proven".
>> Trotzdem kann man von vielen Algorithmen z.B. nicht einmal theoretisch
>> beweisen, daß sie jemals enden (Halteproblem). Ergo kann man dies und
>> auch das Gegenteil auch durch die besten Tests nicht beweisen.
>
> Irrelevant.
> Es geht um die Korrektheit einer Implementation nur der aufgeführten
> kryptographischen Algorithmen.
Wenn etwas *grundsätzlich* nicht funktioniert, kann es im Einzelfall
auch nicht funktionieren.
>>> |We, the designers of Rabbit, hereby state that no hidden weaknesses
>>> have
>>> |been inserted by us in the Rabbit algorithm.
>>
>> Das beruhigt ungemein.
>
> Du versuchst, die Entwickler lächerlich zu machen.
Sorry, aber der Satz fordert das ja geradezu heraus.
>>> |The key expansion stage guarantees a one-to-one correspondence be-
>>> |tween the key, the state and the counter, which prevents key redun-
>>> |dancy. It also distributes the key bits in an optimal way to prepare
>>> |for the the system iteration.
>>> |The correctness of the code on different platforms is verified by
>>> generating and comparing test vectors.
>>
>> Tja, das würde ich gerne mit ihnen diskutieren.
>> Ich finde gerade keine Email-Adresse, aber das bekomme ich hin!
>
> Vielleicht machtest Du Dich damit lächerlich.
Schau'n 'mer mal ... Mail ist 'raus. Jan (unser Sohn) sei Dank für den
Verweis auf Mettes Email-Adresse.
> Ich habe etwa 100 Seiten nur zu Rabbit gelesen.
> Und ich vertraue diesen Entwicklern - die haben mich überzeugt.
Ich zweifele ihren Code ja auch gar nicht an. Was ich anzweifele sind
Deine Behauptungen, man könne durch Testen die Korrektheit beweisen und
da sprechen ALLE dagegen, bis auf Du.
>>>>> Es ist dann der Beweis erbracht, daß die vorgenommene Implementation
>>>>> werte-mäßig identisch mit der Referenz-Implementation der
>>>>> Algorithmus-Entwickler ist.
>>>>
>>>> Nochmals: Nein, es dadurch nur der Beweis erbracht, daß der Code bei
>>>> den vom Entwickler vorgegebenen Eingabedaten die erwarteten
>>>> Ausgabedaten erzeugt. Nichts anderes.
>>>
>>> Erneut falsche Behauptung.
>>> Beweise zur Abwechslung doch mal Deine Behauptung.
>>
>> Wie bitte soll den durch das Testen mit von den Entwicklern
>> vorgegebenen Test-Vektoren bewiesen werden, daß Elemente, die NICHT in
>> den Test-Vektoren enthalten sind, auch die korrekten Ergebnisse liefern?
>
> Aufgrund des spezifischen Verhaltens des jeweiligen Algorithmus'.
> Diese Algorithmen können aufgrund ihres Aufbaus nicht anders.
Nunja, ich verstehe jetzt von kryptologischen Algorithmen nicht
sonderlich viel, aber daß sie interne an diversen Stellen die Daten der
"test vector"en kräftig durcheinander würfeln, sollte klar sein. Und
jetzt aus "mit dem Wert m kommt das Erwartete heraus" und "mit dem Wert
n kommt das Erwartete heraus" zu schließen, daß dann auch für alle Werte
zwischen m und n das Erwartete heraus kommt, ist eben ziemlich gewagt.
Wenn wir uns darauf einigen könnten, daß es nicht möglich ist, durch
Testen die Korrektheit eines Codes (d.h. Algorithmus UND Implementation)
zu *beweisen*, dann könnten wir diese Debatte beenden.
>>> Ich habe meine nämlich mehrfach bewiesen, anhand der
>>> Entwickler-Testprozeduren.
>>
>> Also hast nicht Du das bewiesen, sondern die Entwickler haben das
>> behauptet und Du hast das nur wiedergegeben.
>
> Ja, "anhand der Entwickler-Testprozeduren."
> Wenn ich die korrekt anwende, habe ich es mit Hilfe dieser Prozeduren
> bewiesen.
> Geht es nun mit Haarespalten weiter?
Nunja, Du hast eben die Entwickler Testprozeduren angewendet und es sind
die zu erwartenden Ergebnisse herausgekommen. Das ist eben kein
"Beweis", wie so ziemlich die gesamte Informatik-Welt weiß.
>> NB Unser Sohn ist Professor für Mathematik an der Universität in
>> Aarhus und ich habe ihn gerade mal (per Email) gefragt, ob er mir ggf
>> die Email-Adresse von Mette Vesterager, die ist am Center for
>> Subjectivity Research an der Uni Kopenhagen, besorgen kann. Mal
>> gucken, was daraus wird.
>
>
https://ku-dk.academia.edu/MetteVesterager
Ja, da war ich gestern abend auch, da fand ich aber auf Anhieb ihre
Email-Adresse nicht.
Von unserem Ältesten habe ich das hier:
https://cfs.ku.dk/staff/?pure=en/persons/307267
und da steht ihre Email-Adresse 'drin.
> Es sind vier Entwickler.
> Es kann notwendig sein, herauszufinden, welcher welche Texte erarbeitet
> hatte.
Ich hoffe, daß Mette Vesterager die Frage weiterleiten wird, wenn sie
sie nicht selber beantworten kann
Doch, wenn man Grundprinzipien der Informatik nicht kennt, kennt man sie
mit einer Srache nicht und mit 100 Sprachen auch nicht.
Nein, es sei denn, Du akzeptierst, daß ein Test NIEMALS die Korrektheit
eines Codes *beweisen* kann, sondern eine Implementation nur
*verifizieren* kann.
>>> Ich habe u.a. die Bücher von Knuth.
>>
>> Ja, die sind gut.
>> Was sagt Knuth denn zum Testen?
>
> Ich arbeite jetzt nicht diese Bücher durch...
Brauchst Du nicht, im "Fundamental Algorithms" Steht schon im ersten
Kapitel "Basic Concepts" ein Beweis und der besteht nicht aus einzelnen
Werten sondern ist ein mathematisch-logischer Beweis, daß der
Algorithmus (Euklids Algorithmus zur Berechnung des größten gemeinsamen
Teilers) korrekt ist. Bei meiner Softcover-Ausgabe von 1973 ab Seite 14.
> Wozu auch?, wenn ich spezifische, zum Algorithmus passende
> Testprozeduren habe!
Da ist noch was: hast Du schon mal darüber nachgedacht, daß die
Entwickler *selber* diese Test-Vektoren bestimmt haben? Und ist Dir
vielleicht mal der Gedanke gekommen, daß man als Entwickler einem
gewissen "Bias" unterworfen ist, da.h. man tendiert dazu, in eine
Richtung zu denken?
>>
http://www.informit.com/articles/article.aspx?p=1193856
>> "As to your real question, the idea of immediate compilation and "unit
>> tests" appeals to me only rarely, when I’m feeling my way in a totally
>> unknown environment and need feedback about what works and what doesn’t."
>> OK, es geht um "Unit Tests", aber auch das sind Tests und er lehnt sie
>> ab!
>>
>>> Ein mathematischer Beweis ist bei allen Algorithmen des Kontextes
>>> prinzipiell unmöglich.
>>> Fehler werden gegebenenfalls lange Zeit nach Veröffentlichung des
>>> Algo von untersuchenden Experten mitgeteilt.
>>>
>>> Die _Entwickler_ wissen, daß wenn alle Tests Übereinstimmung ergeben,
>>> auch alle weiteren
>>> denkbaren Test-Vektoren zwangsweise Übereinstimmung ergeben würden.
>>> (s.o.)
>>
>> Das wage ich zu bezweifeln. Schau'n 'mer mal, ob unser Ältester mir
>> die Adresse von Mette besorgen kann, dann frage ich sie.
>
> Es kann sein, daß sie als eine von vier Entwicklern nicht alle Fragen
> beantworten kann.
Schau'n 'mer mal. Ich hoffe ja, daß sie meine Frage weiterleiten wird,
wenn sie sie schon nicht selber beantworten kann.
>>>>> Wir befinden uns nun im Bereich der Haarspalterei, des Unsinns, des
>>>>> Irrsinns.
>>>>
>>>> Nein, wir befinden uns hier im Bereich der Hybris.
>>>
>>> Falsch.
>>> Ich bin ganz konkret praxisbezogen ziemlich kenntnisreich auf diesem
>>> Gebiet.
>>
>> Wie gesagt: Hybris.
>
> Nein, ich bin ziemlich kenntnisreich auf diesem Gebiet.
> Das bedeutet, daß ich deutlich mehr weiß, als die große Mehrheit.
> Ein Experte bin ich nicht für diese Algorithmen - allerdings für die
> Sprache C.
Irrelevant und überheblich ... eben Hybris. Und die ist insbesondere im
Bereicht der Sicherheit lebensgefährlich.
[...]
>> Nein, in erster Instanz werden Brücken *berechnet*. Die Statiker
>> *berechnen*, wie viel Beton und wie viel Armierung und sonstiges da
>> 'rein muß, damit eine Brücke mit einer bestimmten Spannweite eine
>> bestimmte Last aufnehmen kann. Am Ende wird, um das noch einmal zu
>> *verifizieren* ein Belastungstest gemacht. Aber wenn das nicht
>> *berechnet* ist, dann würde kein LKW-Fahrer darüber fahren wollen.
>
> Diese Berechnungen werden aber begutachtet und eventuell offiziell
> abgenommen.
> Das ist in "bewiesenermaßen korrekt gebaut" enthalten.
> Du willst wieder Haare spalten.
Nein, Du willst mir partout widersprechen. Genau das habe ich
geschrieben: Brücken werden nicht einfach so gebaut und dann mit LKW
getestet, sie werden berechnet, daß sie der Belastung stand halten, dann
werden sie gebaut und dann fährt man noch mal mit einer Kolonne LKW
'drüber um das zu ... *verifizieren*.
Leider ist "mein Statiker" (Schwiegerpapa) schon vor über 30 Jahren
verstorben, sonst hätte ich ihn gefragt, wie so etwas genau abläuft.
>> [...]
>>
>>> Du willst die Kenntnisse der Entwickler und Gepflogenheiten im Bereich
>>> der kryptographischen Cipher offensichtlich nicht anerkennen.
>>
>> Und Du willst die (Er)-Kenntnisse der theoretischen Informatik nicht
>> anerkennen.
>>
>>
>
> Nur, wenn enger zugehörige Erkenntnisse die allgemeinen Erkenntnisse
> überschreiben.
Ich sehe nicht, wie man die Erkenntis, daß Testen niemals die
Korrektheit eines Codes *beweisen* kann, überschreiben kann.
Insbesondere bei etwas so Komplexen wie Verschlüsselungsalgorithmen und
dem Bereich der Sicherheit.
Wie gesagt: ich gehe davon aus, daß die Entwickler die Korrektheit ihres
Algorithmus' mathematisch bewiesen haben und lediglich die Korrektheit
der Implementation mittels Tests *verifizieren*.
Josef