Falk Dµebbert wrote:
> On Thu, 2 May 2024 00:51:56 +0200
> Helmut Schellong <var@schellong.biz> wrote:
>
>> AES und RABBIT verwenden beide Multiplikation zwecks Verwürfelung.
>> (a+b)^2 ^ (a+b)^2 >> 32
>> RABBIT verwendet vorstehende Operation mittendrin.
>
> Das Problem ist, dass Rabbit sowohl mit TMD- als auch Frequenzraum-
> Angriffen Schwächen zeigt, da man mit Teilprodukten große
> Schlüsselmengen angreifen und mit Cos^2-Transformationen auf halber
> Strecke die Entropieabnahme beobachten kann.
>
>> Zu beachten ist, daß die 32bit-Multiplikation ein Resultat mit 64 Bit
>> ergibt. Die beiden Hälften des Resultats werden xor-verknüpft.
>> Das ist eine sehr wirksame entkoppelnde Operation.
>>
>> RABBIT wird in Europa empfohlen und zeigte bisher keine Schwäche.
>> http://www.schellong.de/htm/rabbit_kern.c.html
>
> In der BSI TR-02102-1 (Europa) oder der NIST SP 800-131A (US von A) kann
> ich keine Empfehlung entdecken. Kannst Du die empfehlende Körperschaft
> benennen?

https://de.wikipedia.org/wiki/RC4#Sicherheit
https://de.wikipedia.org/wiki/Europ%C3%A4ische_Agentur_f%C3%BCr_Netz-_und_Informationssicherheit
https://www.heise.de/hintergrund/ENISA-Empfehlungen-zu-Krypto-Verfahren-2043356.html
https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report/@@download/fullReport

Eine RABBIT-Empfehlung des NIST halte ich für ausgeschlossen, auch für DRAGON.
Ich verbinde RABBIT mit Europa.

> Bislang kenne ich Rabbit nur als AES alternative
> um mit kleineren CPUs oder Mikrocontrollern ohne AES-Hardware
> effizient Data-at-Rest verschlüsseln zu können.

Ich las über AES, daß eine Implementation 500 Zeilen in C braucht.
Ob der inverse Teil darin enthalten ist, weiß ich nicht.
RABBIT hat jedenfalls nur 80 Zeilen, in meiner Implementation.

Ich habe RABBIT und DRAGON mit der 15-stufigen NIST-Testsuite getestet.
Keine Mängel wurden gefunden.

> Da aber alle aktuellen CPUs von Intel, ARM, Mediatek, VIA Qualcomm und
> AMD mit AES Hardware kommen, macht es keinen Sinn davon abzuweichen,
> solange das Betriebssystem und der Compiler die AES-NI-Schnittstellen
> auf dem Schirm haben.

Um wieviel die Instruktionen beschleunigen, ist mir unbekannt - 1,5 ?.
Ich müßte die in Assembler per Hand einbinden.

--
Mit freundlichen Grüßen
Helmut Schellong

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.

>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.

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.

--
----------------------------------------------------------------------------
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 <mh+usenetspam1118@zugschl.us> wrote:
> 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.

Bei der Sache mit xz neulich sogar eher umgekehrt ;)

/ralph
>

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.

> 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.

--
Mit freundlichen Grüßen
Helmut Schellong

Ralph Aichinger wrote:
> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> 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.
>
> Bei der Sache mit xz neulich sogar eher umgekehrt ;)

Das ist eigentlich irrelevant, weil die Qualität abhängig ist
von dem komprimierten Inhalt.

--
Mit freundlichen Grüßen
Helmut Schellong

Ralph Aichinger <ralph@pi.h5.or.at> wrote:
>Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> 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.
>
>Bei der Sache mit xz neulich sogar eher umgekehrt ;)

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?

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

Helmut Schellong <var@schellong.biz> wrote:
>Ich zweifle daran, daß ich unter FreeBSD solche Unterstützung habe.

Selbstverständlich nutzt FreeBSD seit vielen Jahren AES-NI.

>> 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.

Nein, es ist der Beweis dass die von der Testsuite durchgeführten
Tests funktionieren.

>Die Wahrscheinlichkeit für gute Algorithmus-Qualität ist aber sehr hoch, wenn
>die NIST-Testsuite makellos durchlaufen wird.

Das ist ein Trugschlus.

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 <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.

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

/ralph

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Ich zweifle daran, daß ich unter FreeBSD solche Unterstützung habe.
>
> Selbstverständlich nutzt FreeBSD seit vielen Jahren AES-NI.
>
>>> 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.
>
> Nein, es ist der Beweis dass die von der Testsuite durchgeführten
> Tests funktionieren.

Die übereinstimmenden Referenzausgaben beweisen die Korrektheit der Implementation:

//key=iv=0:
// ED B7 05 67 37 5D CD 7C D8 95 54 F8 5E 27 A7 C6
// 8D 4A DC 70 32 29 8F 7B D4 EF F5 04 AC A6 29 5F
// 66 8F BF 47 8A DB 2B E5 1E 6C DE 29 2B 82 DE 2A
//iv = [59 7E 26 C1 75 F5 73 C3]
//a.out -c 'set w:@128; rabbit $w 597e26c175f573c3 /dev/zero /dev/null'
// 6D 7D 01 22 92 CC DC E0 E2 12 00 58 B9 4E CD 1F
// 2E 6F 93 ED FF 99 24 7B 01 25 21 D1 10 4E 5F A7
// A7 9B 02 12 D0 BD 56 23 39 38 E7 93 C3 12 C1 EB
//a.out -c 'set w:@128; rabbit $w 597e26c175f573c2 /dev/zero /dev/null'
// B0 D0 2E D3 47 05 10 CB B8 BB 65 67 F5 68 6E 94
// C4 35 BA 0E 87 6C 73 94 C1 DB A1 E7 0F FA 5C 5C
// 99 28 F0 B9 07 29 1F EA DB 8A 55 07 9A 57 B2 C2

Dies Thema mit Referenzausgaben ist doch längst abgehakt.
Es kommt immer wieder neu hoch.

>> Die Wahrscheinlichkeit für gute Algorithmus-Qualität ist aber sehr hoch, wenn
>> die NIST-Testsuite makellos durchlaufen wird.
>
> Das ist ein Trugschlus.

Die Algorithmen sollen einen Ausgabestrom mit hochgradiger Zufälligkeit erzeugen.
Genau dies prüft die Testsuite mittels 15 mathematischen Verfahren.
Und dann kommst Du daher und behauptest, das sei ein Trugschluß.
Die Testsuite wäre ja komplett sinnlos, würde sie nicht bei guter Qualität
gute Qualität anzeigen.

Ich definiere gute Algorithmus-Qualität dadurch, daß der Ausgabestrom
eine hochgradige Zufälligkeit besitzt.
Schwächen bei Angriffen sind ein anderes Thema.
Schwächen bei Angriffen können nur durch einen anderen verbesserten Algorithmus beseitigt werden.

--
Mit freundlichen Grüßen
Helmut Schellong

Ralph Aichinger <ralph@pi.h5.or.at> wrote:
>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.

Das ist nichts neues. Aber natürlich kann so ein Agent auch einfach
einen Softwareentwickler bei einem closed-source-Softwarehaus bedrohen
und zum Einbau eines solchen Backdoors zwingen. Da haben wir dann gar
keine Chance mehr.

Stell Dir vor, jemand hätte beim Postgres-Performancetest ein
seltsames Zeitverhalten in einem kommerziellen closed source
ssh-Server festgestellt. Mit _der_ Beobachtung wäre er NIE auch nur am
First-Level-Support des Herstellers vorbeigekommen noch hätte ein
Entwickler des Herstellers die Erlaubnis bekommen dieser Sache näher
auf den Grund zu gehen.

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

Helmut Schellong <var@schellong.biz> wrote:
>Dies Thema mit Referenzausgaben ist doch längst abgehakt.
>Es kommt immer wieder neu hoch.

Ja, weil Du nicht kapierst dass es Fehler geben kann und gibt die von
einer Testsuite nicht gefunden werden.

>Die Algorithmen sollen einen Ausgabestrom mit hochgradiger Zufälligkeit erzeugen.
>Genau dies prüft die Testsuite mittels 15 mathematischen Verfahren.
>Und dann kommst Du daher und behauptest, das sei ein Trugschluß.

Weil es einer ist. Und das kapierst Du nicht.

--
----------------------------------------------------------------------------
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 <mh+usenetspam1118@zugschl.us> wrote:
> Stell Dir vor, jemand hätte beim Postgres-Performancetest ein
> seltsames Zeitverhalten in einem kommerziellen closed source
> ssh-Server festgestellt. Mit _der_ Beobachtung wäre er NIE auch nur am
> First-Level-Support des Herstellers vorbeigekommen noch hätte ein
> Entwickler des Herstellers die Erlaubnis bekommen dieser Sache näher
> auf den Grund zu gehen.

Natürlich nicht. Da wirst du ausgelacht, wenn dir ein paarhundert
Millisekunden mehr verdächtig vorkommen.

Und wie man bei diversen Anbietern ja sieht (Solarwinds anyone?) passiert
sowas ja auch und wird gemacht, und da ist die Motivation sowas zu
vertuschen noch mal um Größenordnungen höher, d.h. vermutlich passiert
da noch vieles was wir nicht mitkriegen.

/ralph

On Fri, 2024-05-03 at 10:25 +0200, Marc Haber wrote:
> Ralph Aichinger <ralph@pi.h5.or.at> wrote:
> > 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.

Ohne "h".

> Das ist nichts neues. Aber natürlich kann so ein Agent auch einfach
> einen Softwareentwickler bei einem closed-source-Softwarehaus bedrohen
> und zum Einbau eines solchen Backdoors zwingen. Da haben wir dann gar
> keine Chance mehr.

Zumal solche Softwarehäuser notorische Geheimniskrämer sind, nicht öffentlich
gewordene oder ihrer Ansicht nach "harmlose" Bugs oft monate- bis jahrelang
nicht fixen oder sowieso unter der Fuchtel von "Diensten" stehen.

Ja, die Linux xz/liblzma Utility Backdoor [1][2] war auch nicht gerade ein
Ruhmesblatt, aber solche Dinge passieren eben, wenn es keine Peer/Code Reviews
gibt und für ein eher undankbares Projekt nur ein einziger (freiwilliger)
Entwickler zuständig ist, auf dem die Community auch noch rumtrampelt.

Auf der anderen Seite:
https://www.axios.com/2024/04/26/microsoft-earnings-cybersecurity-hacks
https://www.wired.com/story/the-us-government-has-a-microsoft-problem/
https://arstechnica.com/security/2024/04/kremlin-backed-hackers-exploit-critical-windows-vulnerability-reported-by-the-nsa/
https://www.theregister.com/2024/04/21/microsoft_national_security_risk/
https://heise.de/-9689780
https://techcrunch.com/2024/04/09/microsoft-employees-exposed-internal-passwords-security-lapse/
https://www.bleepingcomputer.com/news/microsoft/microsoft-confirms-windows-server-issue-behind-domain-controller-crashes/
https://www.bleepingcomputer.com/news/microsoft/microsoft-again-bothers-chrome-users-with-bing-popup-ads-in-windows/
https://www.edps.europa.eu/press-publications/press-news/press-releases/2024/european-commissions-use-microsoft-365-infringes-data-protection-law-eu-institutions-and-bodies_en
https://www.golem.de/news/angriffsvolumen-erhoeht-microsoft-wird-die-hacker-in-seinen-systemen-nicht-los-2403-183025.html
https://www.heise.de/news/Russische-Angreifer-klauen-Quellcode-von-Microsoft-9650468.html
https://arstechnica.com/security/2024/03/hackers-exploited-windows-0-day-for-6-months-after-microsoft-knew-of-it/
https://www.pcmag.com/how-to/how-to-remove-most-annoying-ads-from-windows
https://www.bleepingcomputer.com/news/security/lazarus-hackers-exploited-windows-zero-day-to-gain-kernel-privileges/
https://infosec.exchange/@briankrebs/111931702735845171
https://www.bleepingcomputer.com/news/security/hackers-used-new-windows-defender-zero-day-to-drop-darkme-malware/
https://www.theverge.com/2023/11/22/23972220/microsoft-windows-hello-fingerprint-authentication-bypass-security-vulnerability
https://www.heise.de/news/Microsoft-krallt-sich-Zugangsdaten-Achtung-vorm-neuen-Outlook-9357691.html
https://www.heise.de/news/Microsoft-will-IT-Security-besser-machen-und-startet-Secure-Future-Initative-9352878.html
https://www.wiz.io/blog/38-terabytes-of-private-data-accidentally-exposed-by-microsoft-ai-researchers
https://www.tagesschau.de/investigativ/swr/microsoft-outlook-e-mails-sicherheitsluecke-hacker-100.html
https://msrc.microsoft.com/blog/2023/09/results-of-major-technical-investigations-for-storm-0558-key-acquisition/
https://www.heise.de/news/Microsoft-Security-Update-legt-deutsche-Exchange-Server-lahm-9239151.html
https://www.tenable.com/security/research/tra-2023-25
https://www.golem.de/news/links-oeffnen-microsoft-erzwingt-edge-browser-in-outlook-fuer-windows-2305-173877.html

.... Na also, ich weiß nicht so recht.

Volker

[1] https://linuxsecurity.com/news/security-vulnerabilities/linux-utility-backdoor
[2] https://linuxsecurity.com/news/security-vulnerabilities/xz-utils-linux-backdoor

Volker Bartheld <news2024@bartheld.net> wrote:
>> > Unterwanderungen nicht gefeiht sind.
>
> Ohne "h".

Jetzt weiß ich, was mich an dem Wort irritiert hat ;)

> Ja, die Linux xz/liblzma Utility Backdoor [1][2] war auch nicht gerade ein
> Ruhmesblatt, aber solche Dinge passieren eben, wenn es keine Peer/Code Reviews
> gibt und für ein eher undankbares Projekt nur ein einziger (freiwilliger)
> Entwickler zuständig ist, auf dem die Community auch noch rumtrampelt.

Ja, und bei kommerziellen dürfte es oft vorkommen, dass solche Vorfälle
einfach vertuscht werden. Dass Solarwinds nach dem Vorfall noch
genausoviele Kunden gehabt hat wir vorher, das ist nicht zu vermuten,
die Motivation ist hoch, sowas nicht publik zu machen, selbst wenn man
draufkommt. Und solche Backdoors in diversen
Fernwartungs/Softwareausroll-Tools hat es einige gebeben.

/ralph

Helmut Schellong schrieb:

> Die Algorithmen sollen einen Ausgabestrom mit hochgradiger Zufälligkeit
> erzeugen.

Nein, das sollen sie natürlich nicht! Sie sollen den Eingabedatenstrom
in einen Datenstrom verwandeln, der zwar zufällig aussieht, der Zeichen
gleichverteilt enthält, der aber natürlich auch noch immer den Inhalt
des Eingabedatenstroms enthält

> Genau dies prüft die Testsuite mittels 15 mathematischen Verfahren.
> Und dann kommst Du daher und behauptest, das sei ein Trugschluß.
> Die Testsuite wäre ja komplett sinnlos, würde sie nicht bei guter Qualität
> gute Qualität anzeigen.

Du kapierst wirklich nicht, was das Problem ist?!

> Ich definiere gute Algorithmus-Qualität dadurch, daß der Ausgabestrom
> eine hochgradige Zufälligkeit besitzt.

Das wäre allein bei einem Zufallszahlengenerator ein Ziel

> Schwächen bei Angriffen sind ein anderes Thema.
> Schwächen bei Angriffen können nur durch einen anderen verbesserten
> Algorithmus beseitigt werden.

Das ist natürlich auch falsch. Allzuoft entstehen Schwächen und Fehler
nicht durch eine Schwäche der jeweiligen Algorithmen sondern durch eine
fehlerhafte Umsetzung dieses Algorithmus in konkrete Software. Und es
nützt leider nicht das Geringste, wenn ein einfältiger Programmierer
sich über sein Werk freut, welches zwar durchaus mal dem naturgemäß
allzu begrenzten Prüfungsumfang einer Testsuite standzuhalten vermag,
aber daneben dann eben den ein oder anderen Schwachpunkt, das ein oder
andere offene Scheunentor aufweist, weil der Kasper von Programmierer in
all seiner Hybris nicht fähig ist, durch professionelle Gestaltung des
Entwicklungsprozesses Fehler zu vermeiden und weil er, anders als fähige
Programmierer, nicht einmal auf die naheliegende Idee kommt, sein
Produkt, jede einzelne Zeile seines Produkts einem Code-Review durch ein
paar unabhängige Dritte zu unterwerfen.

MfG
Rupert

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.
Das ist der absolute Beweis der Korrektheit der Implementation.

| 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].

> Idiotie manifestiert sich in vielerlei Hinsicht: Groteske Selbstüberschätzung,
> mangelnde Introspektion, Unfähigkeit zur logischen Schlußfolgerung, Schwächen
> bei Transfer, Genereralisierung und Abstraktion. Naive Gutgläubigkeit, fehlende
> Kritikfähigkeit, mangelnde Sorgfalt, Unfähigkeit zum methodischen bzw.
> wissenschaftlichen Vorgehen, NIHS/kategorische Ablehnung etablierter Standards,
> unsaubere, schlampige Ausdrucksweise und vieles mehr.
>
> Sollen wir für Chuck Schellong eine Liste anlegen?

Solche Auslassungen deuten auf Irrsinn Deinerseits hin.

--
Mit freundlichen Grüßen
Helmut Schellong

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Dies Thema mit Referenzausgaben ist doch längst abgehakt.
>> Es kommt immer wieder neu hoch.
>
> Ja, weil Du nicht kapierst dass es Fehler geben kann und gibt die von
> einer Testsuite nicht gefunden werden.

Das ist eine falsche Behauptung.

Ich habe die Testsuite wochenlang praktisch betrieben.
Folglich weiß ich genau, was die untersucht.
Und zwar wird _nur_ die Ausgabe des Algorithmus untersucht.
Es wird _nur_ der Grad von deren Zufälligkeit festgestellt.
Das ist die grundlegende Eigenschaft eines jeden kryptographischen Algorithmus.

Wenn eine Ausgabe zufällig ist, können z.B. Teile des Schlüssels nicht in der Ausgabe
enthalten sein, denn in diesem Fall wäre die Ausgabe nicht zufällig.

>> Die Algorithmen sollen einen Ausgabestrom mit hochgradiger Zufälligkeit erzeugen.
>> Genau dies prüft die Testsuite mittels 15 mathematischen Verfahren.
>> Und dann kommst Du daher und behauptest, das sei ein Trugschluß.
>
> Weil es einer ist. Und das kapierst Du nicht.

Ah ja, daß die Testsuite mittels 15 Tests ihre Eingabe testet, ist ein Trugschluß?

Ich habe nie behauptet, daß die Testsuite die Gesamtqualität eines Algorithmus
unter Einschluß aller Aspekte testet.
Du jedenfalls willst offenbar hartnäckig den Eindruck erwecken, ich hätte dies behauptet.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> wrote:
>Ich habe die Testsuite wochenlang praktisch betrieben.
>Folglich weiß ich genau, was die untersucht.
>Und zwar wird _nur_ die Ausgabe des Algorithmus untersucht.
>Es wird _nur_ der Grad von deren Zufälligkeit festgestellt.
>Das ist die grundlegende Eigenschaft eines jeden kryptographischen Algorithmus.

Das Durchlaufen einer Testsuite sagt Dir, dass es sich lohnt, mit dem
ernsthaften Test der Software anzufangen.

Bricht sie ab, brauchst du keine weitere Energie in richtige Tests zu
investieren.

Die Testsuite ist Schritt 1 von X eines Softwaretests.

--
----------------------------------------------------------------------------
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

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.
 
Idiotie manifestiert sich in vielerlei Hinsicht: Groteske Selbstüberschätzung,
mangelnde Introspektion, Unfähigkeit zur logischen Schlußfolgerung, Schwächen
bei Transfer, Genereralisierung und Abstraktion. Naive Gutgläubigkeit, fehlende
Kritikfähigkeit, mangelnde Sorgfalt, Unfähigkeit zum methodischen bzw.
wissenschaftlichen Vorgehen, NIHS/kategorische Ablehnung etablierter Standards,
unsaubere, schlampige Ausdrucksweise und vieles mehr.

Sollen wir für Chuck Schellong eine Liste anlegen?

Volker

On Fri, 3 May 2024 22:15:34 +0200, 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.

QED.

Thomas Prufer

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Ich habe die Testsuite wochenlang praktisch betrieben.
>> Folglich weiß ich genau, was die untersucht.
>> Und zwar wird _nur_ die Ausgabe des Algorithmus untersucht.
>> Es wird _nur_ der Grad von deren Zufälligkeit festgestellt.
>> Das ist die grundlegende Eigenschaft eines jeden kryptographischen Algorithmus.
>
> Das Durchlaufen einer Testsuite sagt Dir, dass es sich lohnt, mit dem
> ernsthaften Test der Software anzufangen.
>
> Bricht sie ab, brauchst du keine weitere Energie in richtige Tests zu
> investieren.
>
> Die Testsuite ist Schritt 1 von X eines Softwaretests.

Normalerweise teste ich nur, ob die Referenz-Ausgabe übereinstimmt.
Und keinerlei weitere Tests - weil die unnötiger Ballast wären.

Das reichte völlig zur Implementierung von RABBIT, DRAGON, SHA2-xxx, SHA3-xxx, SPRITZ, ...
Du tust seit Tagen so, als ob ich selbst kryptographische Algorithmen entwickelte.
Das wirkt mittlerweile albern, und läßt über Deinen Geisteszustand nachdenken.

--
Mit freundlichen Grüßen
Helmut Schellong

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.

--
----------------------------------------------------------------------------
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

Rupert Haselbeck wrote:
> Helmut Schellong schrieb:
>
>> Die Algorithmen sollen einen Ausgabestrom mit hochgradiger Zufälligkeit erzeugen.
>
> Nein, das sollen sie natürlich nicht! Sie sollen den Eingabedatenstrom in einen Datenstrom verwandeln, der zwar zufällig aussieht,
> der Zeichen gleichverteilt enthält, der aber natürlich auch noch immer den Inhalt des Eingabedatenstroms enthält

Diese Antwort ist einfach Unfug und zeugt von hochgradiger Inkompetenz zum Thema.

>> Genau dies prüft die Testsuite mittels 15 mathematischen Verfahren.
>> Und dann kommst Du daher und behauptest, das sei ein Trugschluß.
>> Die Testsuite wäre ja komplett sinnlos, würde sie nicht bei guter Qualität
>> gute Qualität anzeigen.
>
> Du kapierst wirklich nicht, was das Problem ist?!

Du bist es, der nur Behauptungen von sich gibt - wegen Inkompetenz und Hilflosigkeit.

>> Ich definiere gute Algorithmus-Qualität dadurch, daß der Ausgabestrom
>> eine hochgradige Zufälligkeit besitzt.
>
> Das wäre allein bei einem Zufallszahlengenerator ein Ziel

Nein, das ist eigentlich bei allen kryptographischen Algorithmen der Fall.
Also bei Verschlüsselungen, Zufallszahlen-Generatoren, Hash-Generatoren, ...

>> Schwächen bei Angriffen sind ein anderes Thema.
>> Schwächen bei Angriffen können nur durch einen anderen verbesserten Algorithmus beseitigt werden.
>
> Das ist natürlich auch falsch. Allzuoft entstehen Schwächen und Fehler nicht durch eine Schwäche der jeweiligen Algorithmen sondern
> durch eine fehlerhafte Umsetzung dieses Algorithmus in konkrete Software. Und es nützt leider nicht das Geringste, wenn ein
> einfältiger Programmierer sich über sein Werk freut, welches zwar durchaus mal dem naturgemäß allzu begrenzten Prüfungsumfang einer
> Testsuite standzuhalten vermag, aber daneben dann eben den ein oder anderen Schwachpunkt, das ein oder andere offene Scheunentor
> aufweist, weil der Kasper von Programmierer in all seiner Hybris nicht fähig ist, durch professionelle Gestaltung des
> Entwicklungsprozesses Fehler zu vermeiden und weil er, anders als fähige Programmierer, nicht einmal auf die naheliegende Idee
> kommt, sein Produkt, jede einzelne Zeile seines Produkts einem Code-Review durch ein paar unabhängige Dritte zu unterwerfen.

Das ist einfach pauschales, dummes Geschwalle, mangels echter Argumente, die hier mangels Kompetenz ausbleiben.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> wrote:
>Normalerweise teste ich nur, ob die Referenz-Ausgabe übereinstimmt.

Das ist fehlerhaftres Vorgehen.

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

Das ist ein Trugschlus.

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

Nein.

--
----------------------------------------------------------------------------
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

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.

Volker