Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Auch damals schon waren die Referenz-Ausgaben übereinstimmend.
>> Unmittelbar nach der Implementation, vor der Testsuite.
>> Das ist der absolute Beweis der Korrektheit der Implementation.
>
> Nein. Es ist der Beweis dass die Tests bestanden wurden. Tests sind
> aber niemals vollständig.

Die Entwickler der Algorithmen äußern, daß eine Übereinstimmung mit
den Test-Vektoren die Korrektheit der Implementation beweist.
Das ist ja bei deterministischen Algorithmen gar nicht anders möglich!

| This is a set of test vectors for conformance testing, given in octet
| form. For use with Rabbit, they have to be transformed into integers
| by the conversion primitives OS2IP and I2OSP, as described in [5].

Es muß nicht die gesamte Ausgabe von jeweils 2^68 Byte für jeden der 2^192 keys
auf Gleichheit geprüft werden!
Darauf willst Du offenbar hinaus.
Das ist aber Wahnsinn und völlig unnötig zugleich.

--
Mit freundlichen Grüßen
Helmut Schellong

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Normalerweise teste ich nur, ob die Referenz-Ausgabe übereinstimmt.
>
> Das ist fehlerhaftres Vorgehen.

Nein.
Was muß denn zwingend sonst noch getestet werden, was die Entwickler nicht bereits taten?

>> Und keinerlei weitere Tests - weil die unnötiger Ballast wären.
>
> Das ist ein Trugschlus.

Nein, ist es nicht.

>> Das reichte völlig zur Implementierung von RABBIT, DRAGON, SHA2-xxx, SHA3-xxx, SPRITZ, ...
>
> Nein.

Es reicht vollkommen aus.

Irgendwie spinnst Du Dir hier etwas gehörig zusammen!
Die Entwickler und weitere Kryptographen haben die Algorithmen innerhalb von Jahren
vielleicht 1000-fach stärker getestet, als wir oder fast der Rest der Welt das könnte.
DESHALB muß _ich_ keine weiteren Tests durchführen.
Du wischst die Erkenntnisse der Welt einfach hinweg.

--
Mit freundlichen Grüßen
Helmut Schellong

Volker Bartheld wrote:
> On Sat, 2024-05-04 at 08:19 +0200, Marc Haber wrote:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Auch damals schon waren die Referenz-Ausgaben übereinstimmend. [...]
>>> Das ist der absolute Beweis der Korrektheit der Implementation.
>> Nein. Es ist der Beweis dass die Tests bestanden wurden. Tests sind
>> aber niemals vollständig.
>
> Ich habe ein effizientes Programm zur Errechnung von Primzahlen erfunden. Ohne
> Durchprobieren!
>
> int Prim(int i)
> {
> static const int v[10] = { 2, 3, 5, 7, 11, 13, 17, 19, 23, 29 };
> return v[i%10];
> }
>
> Mein Unit-Test für i∈[0;9] war erfolgreich.

Du bist zum Thema ein inkompetenter Spinner.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> wrote:
>Die Entwickler und weitere Kryptographen haben die Algorithmen innerhalb von Jahren
>vielleicht 1000-fach stärker getestet, als wir oder fast der Rest der Welt das könnte.
>DESHALB muß _ich_ keine weiteren Tests durchführen.

Du hast den Algorithmus implementiert. Deine Implementierung kann
fehlerhaft sein. Und dabei bin ich noch nett zu Dir, sonst würde ich
sagen sie IST fehlerhaft.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Die Entwickler und weitere Kryptographen haben die Algorithmen innerhalb von Jahren
>> vielleicht 1000-fach stärker getestet, als wir oder fast der Rest der Welt das könnte.
>> DESHALB muß _ich_ keine weiteren Tests durchführen.
>
> Du hast den Algorithmus implementiert. Deine Implementierung kann
> fehlerhaft sein. Und dabei bin ich noch nett zu Dir, sonst würde ich
> sagen sie IST fehlerhaft.

Nein, meine Implementation _kann nicht_ fehlerhaft sein, weil die Referenz-Vektoren
der Referenz-Implementation identisch mit den Test-Vektoren meiner Implementation sind.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> wrote:
> Marc Haber wrote:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Um wieviel die Instruktionen beschleunigen, ist mir unbekannt - 1,5 ?.
>>
>> Du bist im Zweifel nicht alleine auf dem Rechner und solltest keine
>> allgemein nutzbaren Rechenwerke mit Dingen beschäftigen für die Du
>> Spezialhardware hast.
>
> Das ist ein Punkt, der auf mich nicht zutrifft.
>
>>> Ich müßte die in Assembler per Hand einbinden.
>>
>> Never roll your own crypto. Die zahlreich vorhandenen hochoptimierten
>> Standardbibliotheken machen das für Dich automatisch.
>
> Instruktionen statt Funktionen zu nutzen, hat nichts mit "Never roll your own crypto" zu tun.
> Ich zweifle daran, daß ich unter FreeBSD solche Unterstützung habe.

Die Wahrscheinlichkeit, dass FreeBSD Teile des CPU-Befehlssatzes
abschaltet halte ich für eher gering.
>
>> Und das Bestehen einer Testsuite ist Basisvoraussetzung, das taugt nur
>> zum Aussortieren einer untauglichen Implementierung. Dass die
>> Testsuite unfallfrei durchläuft ist nicht die Garantie dass Deine
>> Implementierung schwachstellenfrei ist.
>
> Ich habe bisher RABBIT, DRAGON und SPRITZ damit getestet - keine Eigenentwicklungen.
> Meine Implementationen generieren die Referenz-Ausgaben.
> Das ist der Beweis, daß diese korrekt sind, und zwar unerschütterlich.
> Das schrieb ich bereits zuvor.
>
> Die Wahrscheinlichkeit für gute Algorithmus-Qualität ist aber sehr hoch, wenn
> die NIST-Testsuite makellos durchlaufen wird.

Nein. Testsuite erfolgreich heisst nur: Keine der durch die Testsuite
abgedeckten offensichtlichen Fehler gefunden. Das ist eher eine der
unteren Qualitätsschwellen, gleich hinter "Oh, cool, es kompiliert!".

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Ralph Aichinger <ralph@pi.h5.or.at> wrote:
> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> Die Sache mit xz neulich wird in den Geschichtsbüchern stehen, das war
>> ein absolutes Ausnahme-Dings, das unsere Welt in einer Weise
>> erschüttert hat wie wir es bis heute noch nicht ahnen. Geht hier
>> jemand ernsthaft davon aus, dass der dahinter stehende, mit großem
>> Ressourcen- und Zeiteinsatz agierende Akteur alles auf dieses eine
>> Pferd gesetzt hat? Wer sagt, dass wir nicht schon fünf ähnliche
>> Backdoors in unseren Libraries haben?
>
> Natürlich nicht.
>
> Was über bleiben wird, ist die Erkenntniss, dass offene Projekte aller
> Art (und das können auch kommerzielle sein, nicht nur
> ein-Mann-nichtkommerzielle) durch ihre Offenheit vor derartigen
> Unterwanderungen nicht gefeiht sind.

Mit dem Unterschied, das man bei offenen Projekten zumindest die
_Chance_ hat, sowas zu entdecken und aufzurollen.

> Das wird unsere Welt eventuell weniger offen machen, eventuell werden
> wir andere Strategien finden.

Bei Closed Source muss man halt akzeptieren, dass man die Binaries
als trojanisiert betrachten muss, ohne mit akzeptablem Aufwand prüfen
zu können.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Alexander Schreiber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Marc Haber wrote:
>>> Helmut Schellong <var@schellong.biz> wrote:
>>>> Um wieviel die Instruktionen beschleunigen, ist mir unbekannt - 1,5 ?.
>>>
>>> Du bist im Zweifel nicht alleine auf dem Rechner und solltest keine
>>> allgemein nutzbaren Rechenwerke mit Dingen beschäftigen für die Du
>>> Spezialhardware hast.
>>
>> Das ist ein Punkt, der auf mich nicht zutrifft.
>>
>>>> Ich müßte die in Assembler per Hand einbinden.
>>>
>>> Never roll your own crypto. Die zahlreich vorhandenen hochoptimierten
>>> Standardbibliotheken machen das für Dich automatisch.
>>
>> Instruktionen statt Funktionen zu nutzen, hat nichts mit "Never roll your own crypto" zu tun.
>> Ich zweifle daran, daß ich unter FreeBSD solche Unterstützung habe.
>
> Die Wahrscheinlichkeit, dass FreeBSD Teile des CPU-Befehlssatzes
> abschaltet halte ich für eher gering.

Ich rede von "hochoptimierten Standardbibliotheken".
Siehe oben.
Die betreffenden Instruktionen wird FreeBSD nicht abschalten.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> wrote:
> Volker Bartheld wrote:
>> On Fri, 2024-05-03 at 20:49 +0200, Marc Haber wrote:
>>> Helmut Schellong <var@schellong.biz> wrote:
>>>> Ich habe die Testsuite wochenlang praktisch betrieben.
>>>> Folglich weiß ich genau, was die untersucht.
>>> Das Durchlaufen einer Testsuite sagt Dir, dass es sich lohnt, mit dem
>>> ernsthaften Test der Software anzufangen.
>>
>> Wir hatten das bereits, wird wohl ein-zwei Jahre her sein: Unit Tests wurden
>> bestanden -> Software ist fehlerfrei. Vergessen, ignoriert, nicht nachvollzogen.
>
> Das stimmt so nicht.
> Auch damals schon waren die Referenz-Ausgaben übereinstimmend.
> Unmittelbar nach der Implementation, vor der Testsuite.

Erfolgreicher Durchlauf der Testsuite heisst nur: Testsuite bestanden,
der Code ist vielleicht nicht vollkommen kaputt.

> Das ist der absolute Beweis der Korrektheit der Implementation.

*prust*

Das ist nichtmal der _Anfang_ eines solchen Beweises.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Helmut Schellong <var@schellong.biz> wrote:
>Marc Haber wrote:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Die Entwickler und weitere Kryptographen haben die Algorithmen innerhalb von Jahren
>>> vielleicht 1000-fach stärker getestet, als wir oder fast der Rest der Welt das könnte.
>>> DESHALB muß _ich_ keine weiteren Tests durchführen.
>>
>> Du hast den Algorithmus implementiert. Deine Implementierung kann
>> fehlerhaft sein. Und dabei bin ich noch nett zu Dir, sonst würde ich
>> sagen sie IST fehlerhaft.
>
>Nein, meine Implementation _kann nicht_ fehlerhaft sein, weil die Referenz-Vektoren
>der Referenz-Implementation identisch mit den Test-Vektoren meiner Implementation sind.

Humbug.
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Marc Haber wrote:
>>> Helmut Schellong <var@schellong.biz> wrote:
>>>> Die Entwickler und weitere Kryptographen haben die Algorithmen innerhalb von Jahren
>>>> vielleicht 1000-fach stärker getestet, als wir oder fast der Rest der Welt das könnte.
>>>> DESHALB muß _ich_ keine weiteren Tests durchführen.
>>>
>>> Du hast den Algorithmus implementiert. Deine Implementierung kann
>>> fehlerhaft sein. Und dabei bin ich noch nett zu Dir, sonst würde ich
>>> sagen sie IST fehlerhaft.
>>
>> Nein, meine Implementation _kann nicht_ fehlerhaft sein, weil die Referenz-Vektoren
>> der Referenz-Implementation identisch mit den Test-Vektoren meiner Implementation sind.
>
> Humbug.

Gubmuh.

--
Mit freundlichen Grüßen
Helmut Schellong

Alexander Schreiber schrieb:
>
> Mit dem Unterschied, das man bei offenen Projekten zumindest die
> _Chance_ hat, sowas zu entdecken und aufzurollen.
>
Die Chance ist epsilon. Die aktuelle Linux-Kernel-Version hat
40 Mio Zeilen in 100'000 Files. "Jeder kann das überprüfen"
ist wohl der grösste Witz der OSS-Anhänger. Niemand kann das
innerhalb seiner Lebensdauer überprüfen. Nichts gegen OSS,
aber man könnte solche Statements einfach auslassen, das
wäre ehrlicher.

--
mfg Rolf Bombach

Rolf Bombach <rolfnospambombach@invalid.invalid> wrote:
> Die Chance ist epsilon. Die aktuelle Linux-Kernel-Version hat
> 40 Mio Zeilen in 100'000 Files. "Jeder kann das überprüfen"
> ist wohl der grösste Witz der OSS-Anhänger. Niemand kann das
> innerhalb seiner Lebensdauer überprüfen. Nichts gegen OSS,
> aber man könnte solche Statements einfach auslassen, das
> wäre ehrlicher.

Und trotzdem hat Andres Freund das Backdoor in xzlib gefunden.

/ralph

Rolf Bombach <rolfnospambombach@invalid.invalid> wrote:
> Alexander Schreiber schrieb:
>>
>> Mit dem Unterschied, das man bei offenen Projekten zumindest die
>> _Chance_ hat, sowas zu entdecken und aufzurollen.
>>
> Die Chance ist epsilon. Die aktuelle Linux-Kernel-Version hat
> 40 Mio Zeilen in 100'000 Files. "Jeder kann das überprüfen"
> ist wohl der grösste Witz der OSS-Anhänger. Niemand kann das
> innerhalb seiner Lebensdauer überprüfen.

Als Einzelperson? Natürlich nicht. Und wenn man sich die Patches
auf lkml ansieht, dann werden immer wieder mal Bugs gefixt, die
teilweise durchaus sicherheitsrelevant sind.

> Nichts gegen OSS,
> aber man könnte solche Statements einfach auslassen, das
> wäre ehrlicher.

Der Spass mit xz ist aufgeflogen eben weil jemand etwas komisch fand
und angefangen hat zu graben - was durch vorhandene Quellen ermöglicht
wurde. Wenn das alles closed source Infrastruktur gewesen wäre, dann
wäre als allenfalls viel später im Rahmen der "wie zum Kuckuck sind
die Systeme aufgemacht worden" Analyse aufgefallen - vielleicht.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

On Sun, 2024-05-05 at 22:09 +0200, Rolf Bombach wrote:
> Alexander Schreiber schrieb:
> > Mit dem Unterschied, das man bei offenen Projekten zumindest die
> > _Chance_ hat, sowas zu entdecken und aufzurollen.
> Die Chance ist epsilon. Die aktuelle Linux-Kernel-Version hat
> 40 Mio Zeilen in 100'000 Files. "Jeder kann das überprüfen"
> ist wohl der grösste Witz der OSS-Anhänger.

Und deswegen machen bzw. glauben wir lieber proprietären Kram bzw. Closed
Source?

> Nichts gegen OSS, aber man könnte solche Statements einfach auslassen, das
> wäre ehrlicher.

Die Aussage "jeder kann das überprüfen" beinhaltet neben einem autistischen
Wunderkind, das die 40 Mio Zeilen in 100'000 Files auswendig kann auch die
Fälle, wo sich eine Gruppe von Fachexperten einzelne Fragmente des Kernels
vornimmt, gerne auch inkrementell, mit Computerunterstützung und einer Prise KI.

Volker

Rolf Bombach, 2024-05-05 22:09:

> Alexander Schreiber schrieb:
>>
>> Mit dem Unterschied, das man bei offenen Projekten zumindest die
>> _Chance_ hat, sowas zu entdecken und aufzurollen.
>>
> Die Chance ist epsilon. Die aktuelle Linux-Kernel-Version hat
> 40 Mio Zeilen in 100'000 Files. "Jeder kann das überprüfen"
> ist wohl der grösste Witz der OSS-Anhänger. Niemand kann das
> innerhalb seiner Lebensdauer überprüfen. Nichts gegen OSS,
> aber man könnte solche Statements einfach auslassen, das
> wäre ehrlicher.

Es geht auch nicht darum, dass *eine* Person das *alleine* tun kann,
sondern dass überhaupt die Möglichkeit besteht.

Bei Closed Source ist der Umfang des Codes nicht geringer, nur der Kreis
der Personen, die darauf Zugriff haben.

--
Arno Welzel
https://arnowelzel.de