Antonov 225 - größtes Flugzeug der Welt, mit 640 t Startgewicht - Zerstört!

[Helmut Schellong]

http://www.schellong.de/img/div/an225_landebahn.jpg
http://www.schellong.de/img/div/an225_zerstoert.jpg

https://youtu.be/XDRfGOQ_iTU >40 min
https://youtu.be/FpdbtohYkcc >20 min

Ein schönes und tolles Flugzeug - ein technisches Glanzstück, trotz der alten Elektrik/Elektronik.
Es gab nur EIN Exemplar.
Ein Neubau würde etwa 4-5 Mrd. kosten!


--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm

[Marc Haber]

Helmut Schellong <r...@schellong.biz> wrote:
>Ein schönes und tolles Flugzeug - ein technisches Glanzstück, trotz der alten Elektrik/Elektronik.
>Es gab nur EIN Exemplar.

News von vorletzter Woche, und wo ist der Bezug zu de.sci.electronics?

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Heinz Schmitz]

Helmut Schellong wrote:

>http://www.schellong.de/img/div/an225_landebahn.jpg
>http://www.schellong.de/img/div/an225_zerstoert.jpg
>
>https://youtu.be/XDRfGOQ_iTU >40 min
>https://youtu.be/FpdbtohYkcc >20 min
>
>Ein schönes und tolles Flugzeug - ein technisches Glanzstück, trotz der alten Elektrik/Elektronik.
>Es gab nur EIN Exemplar.
>Ein Neubau würde etwa 4-5 Mrd. kosten!

Deshalb wäre es nun nicht mehr möglich, Riccarda Lang aus
dem Land zu transportieren. Putin will uns wirklich vernichten.

Grüße,
H.

[Helmut Schellong]

Die sollte noch in jungen Jahren ihr Gewicht auf unter 80 kg bringen.
Andernfalls könnte sie im Alter von z.B. 48 an multiplem Organversagen
sterben oder durch überhöhtes Eigengewicht ersticken.

[Arno Welzel]

Helmut Schellong:

> On 03/07/2022 14:47, Heinz Schmitz wrote:
>> Helmut Schellong wrote:
>>
>>> http://www.schellong.de/img/div/an225_landebahn.jpg
>>> http://www.schellong.de/img/div/an225_zerstoert.jpg
>>>
>>> https://youtu.be/XDRfGOQ_iTU >40 min
>>> https://youtu.be/FpdbtohYkcc >20 min
>>>
>>> Ein schönes und tolles Flugzeug - ein technisches Glanzstück, trotz der alten Elektrik/Elektronik.
>>> Es gab nur EIN Exemplar.
>>> Ein Neubau würde etwa 4-5 Mrd. kosten!
>>
>> Deshalb wäre es nun nicht mehr möglich, Riccarda Lang aus
>> dem Land zu transportieren. Putin will uns wirklich vernichten.
>>
>>
> Die sollte noch in jungen Jahren ihr Gewicht auf unter 80 kg bringen.
> Andernfalls könnte sie im Alter von z.B. 48 an multiplem Organversagen
> sterben oder durch überhöhtes Eigengewicht ersticken.

Wenn das irgendwie "lustig" sein soll - ist es nicht.

Ihr qualifiziert euch mit solchen Äußerungen als echte Arschlöcher.


--
Arno Welzel
https://arnowelzel.de

[Heinz Schmitz]

Karl Davis wrote:

>Die Äußerungen sind absolut geschmacklos, ja.

Wären sie ernst gemeint, ja, dann würde ich Dir zustimmen.

Andrerseits ist das, was Riccarda Lang ständig ablässt,
durchaus ernst gemeint :-).

Grüße,
H.

[Arno Welzel]

Karl Davis:

> Die Äußerungen sind absolut geschmacklos, ja. Aber:

>
> Arno Welzel <use...@arnowelzel.de> wrote:
>> Ihr qualifiziert euch mit solchen Äußerungen als echte Arschlöcher.
>

> Ich wäre vorsichtig mit so einer Aussage - wenn man nur etwas sucht,
> kannst Du dich dort einreihen.

Ja? Wo denn? Wann habe ich mich denn jemals über dicke Frauen oder
generell über Menschen aufgrund ihres Aussehens, Hautfarbe etc. lustig
gemacht?

[Arno Welzel]

Heinz Schmitz:

> Karl Davis wrote:
>
>> Die Äußerungen sind absolut geschmacklos, ja.
>
> Wären sie ernst gemeint, ja, dann würde ich Dir zustimmen.

Natürlich war das von Dir genau genau so gemeint, Dich über das Gewicht
von Riccard Lang zu belustigen! Da gibt es nicht zu beschönigen.

[Helmut Schellong]

On 03/08/2022 01:09, Arno Welzel wrote:
> Helmut Schellong:
>
[...]

>>>> Ein schönes und tolles Flugzeug - ein technisches Glanzstück, trotz der alten Elektrik/Elektronik.
>>>> Es gab nur EIN Exemplar.
>>>> Ein Neubau würde etwa 4-5 Mrd. kosten!
>>>
>>> Deshalb wäre es nun nicht mehr möglich, Riccarda Lang aus
>>> dem Land zu transportieren. Putin will uns wirklich vernichten.
>>>
>>>
>> Die sollte noch in jungen Jahren ihr Gewicht auf unter 80 kg bringen.
>> Andernfalls könnte sie im Alter von z.B. 48 an multiplem Organversagen
>> sterben oder durch überhöhtes Eigengewicht ersticken.
>
> Wenn das irgendwie "lustig" sein soll - ist es nicht.
>
> Ihr qualifiziert euch mit solchen Äußerungen als echte Arschlöcher.
>
>

Du kannst nicht richtig Deutsch.
Mein Absatz ist vollkommen sachlich und besorgt formuliert - von Erfahrung getrieben.

[Heinz Schmitz]

Das Thema "Ex-Ratsherr Heinz Schmitz ist jedes Mittel recht"
und auch andere Themen der FDP-Fraktion in Brühl waren sicher
auch durchaus ernst gemeint. :-)

Auszug:
"Herr Schmitz ... überschreitet unserer Auffassung nun endgültig die
Grenzen des demokratischen Anstands."

Grüße,
H.

[Arno Welzel]

Helmut Schellong:

> On 03/08/2022 01:09, Arno Welzel wrote:
>> Helmut Schellong:
>>
> [...]
>>>>> Ein schönes und tolles Flugzeug - ein technisches Glanzstück, trotz der alten Elektrik/Elektronik.
>>>>> Es gab nur EIN Exemplar.
>>>>> Ein Neubau würde etwa 4-5 Mrd. kosten!
>>>>
>>>> Deshalb wäre es nun nicht mehr möglich, Riccarda Lang aus
>>>> dem Land zu transportieren. Putin will uns wirklich vernichten.
>>>>
>>>>
>>> Die sollte noch in jungen Jahren ihr Gewicht auf unter 80 kg bringen.
>>> Andernfalls könnte sie im Alter von z.B. 48 an multiplem Organversagen
>>> sterben oder durch überhöhtes Eigengewicht ersticken.
>>
>> Wenn das irgendwie "lustig" sein soll - ist es nicht.
>>
>> Ihr qualifiziert euch mit solchen Äußerungen als echte Arschlöcher.
>>
>>
> Du kannst nicht richtig Deutsch.
> Mein Absatz ist vollkommen sachlich und besorgt formuliert - von Erfahrung getrieben.

Kann sein, dass Du persönlich Menschen kennst, die wegen Übergewicht an
multiplem Organversagen gestorben sind - das weiß ich nicht.

Über den Gesundheitszustand von Riccard Lang und die Ursachen ihrer
Erscheinung hast Du aber keine Ahnung und daher ist auch jeder Mutmaßung
dazu, welche Auswirkungen ihr persönliches Gewicht hat, komplett fehl am
Platz. Ebenso ist "unter 80 kG bringen" ohne weitere Angaben zur
Körpergröße etc. völlig unsinnig.

[Helmut Schellong]

On 03/10/2022 18:11, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 03/08/2022 01:09, Arno Welzel wrote:
>>> Helmut Schellong:
>>>
>> [...]
>>>>>> Ein schönes und tolles Flugzeug - ein technisches Glanzstück, trotz der alten Elektrik/Elektronik.
>>>>>> Es gab nur EIN Exemplar.
>>>>>> Ein Neubau würde etwa 4-5 Mrd. kosten!
>>>>>
>>>>> Deshalb wäre es nun nicht mehr möglich, Riccarda Lang aus
>>>>> dem Land zu transportieren. Putin will uns wirklich vernichten.
>>>>>
>>>>>
>>>> Die sollte noch in jungen Jahren ihr Gewicht auf unter 80 kg bringen.
>>>> Andernfalls könnte sie im Alter von z.B. 48 an multiplem Organversagen
>>>> sterben oder durch überhöhtes Eigengewicht ersticken.
>>>
>>> Wenn das irgendwie "lustig" sein soll - ist es nicht.
>>>
>>> Ihr qualifiziert euch mit solchen Äußerungen als echte Arschlöcher.
>>>
>>>
>> Du kannst nicht richtig Deutsch.
>> Mein Absatz ist vollkommen sachlich und besorgt formuliert - von Erfahrung getrieben.
>
> Kann sein, dass Du persönlich Menschen kennst, die wegen Übergewicht an
> multiplem Organversagen gestorben sind - das weiß ich nicht.

Ich kenne aus einer REHA-Klinik und einem Sole-Bad superdicke Menschen, mit einem
Bauchumfang von etwa 2,5 m.
Desweiteren sah ich mehrere TV-Dokumentationen zum Thema.

Wieso muß ich "persönlich" Menschen kennen, die an "multiplem Organversagen" starben?
Es reicht vollkommen aus, wenn mir gesagt wird, daß dies eine wahrscheinliche Todesursache ist.

> Über den Gesundheitszustand von Riccard Lang und die Ursachen ihrer
> Erscheinung hast Du aber keine Ahnung und daher ist auch jeder Mutmaßung
> dazu, welche Auswirkungen ihr persönliches Gewicht hat, komplett fehl am
> Platz. Ebenso ist "unter 80 kG bringen" ohne weitere Angaben zur
> Körpergröße etc. völlig unsinnig.
>
>

Ich bin sicher, daß mir jeder Arzt bestätigen würde, daß es für jemanden wie Ricarda Lang
eine rettende Maßnahme wäre, das Körpergewicht auf unter 80 kg zu senken.

Sie ist noch ein Twen, durchschnittlich groß und dürfte 110..130 kg wiegen.
Deine Einschränkungen sind folglich irrelevant.
Sie hat Adipositas Grad III oder II.
Das ist _garantiert_ sehr ungesund und stark lebensverkürzend.

[Heinz Schmitz]

Arno Welzel wrote:

>Über den Gesundheitszustand von Riccard Lang und die Ursachen ihrer
>Erscheinung hast Du aber keine Ahnung und daher ist auch jeder Mutmaßung
>dazu, welche Auswirkungen ihr persönliches Gewicht hat, komplett fehl am
>Platz. Ebenso ist "unter 80 kG bringen" ohne weitere Angaben zur
>Körpergröße etc. völlig unsinnig.

So wie sie auftritt, ist sie körperlich noch gesund, sonst würde sie
das nicht durchhalten - die Grünen sind äusserst anstrengend.
Ich würde eher den geistigen Zustand infrage stellen. Das erfordert
dann auch kaum Mutmassung.

Grüße,
H.

[Arno Welzel]

Helmut Schellong:

> On 03/10/2022 18:11, Arno Welzel wrote:
>> Helmut Schellong:
>>
>>> On 03/08/2022 01:09, Arno Welzel wrote:
>>>> Helmut Schellong:
[...]

>>>>> Die sollte noch in jungen Jahren ihr Gewicht auf unter 80 kg bringen.
>>>>> Andernfalls könnte sie im Alter von z.B. 48 an multiplem Organversagen
>>>>> sterben oder durch überhöhtes Eigengewicht ersticken.
>>>>
>>>> Wenn das irgendwie "lustig" sein soll - ist es nicht.
>>>>
>>>> Ihr qualifiziert euch mit solchen Äußerungen als echte Arschlöcher.
>>>>
>>>>
>>> Du kannst nicht richtig Deutsch.
>>> Mein Absatz ist vollkommen sachlich und besorgt formuliert - von Erfahrung getrieben.
>>
>> Kann sein, dass Du persönlich Menschen kennst, die wegen Übergewicht an
>> multiplem Organversagen gestorben sind - das weiß ich nicht.
>
> Ich kenne aus einer REHA-Klinik und einem Sole-Bad superdicke Menschen, mit einem
> Bauchumfang von etwa 2,5 m.
> Desweiteren sah ich mehrere TV-Dokumentationen zum Thema.
>
> Wieso muß ich "persönlich" Menschen kennen, die an "multiplem Organversagen" starben?

Deswegen, Zitat von Dir:

"Mein Absatz ist vollkommen sachlich und besorgt formuliert - von
Erfahrung getrieben"

Also welche Erfahrung hast Du damit?

> Es reicht vollkommen aus, wenn mir gesagt wird, daß dies eine wahrscheinliche Todesursache ist.

Ach so - Du hast also gar keine Erfahrung damit. Dachte ich mir.

>> Über den Gesundheitszustand von Riccard Lang und die Ursachen ihrer
>> Erscheinung hast Du aber keine Ahnung und daher ist auch jeder Mutmaßung
>> dazu, welche Auswirkungen ihr persönliches Gewicht hat, komplett fehl am
>> Platz. Ebenso ist "unter 80 kG bringen" ohne weitere Angaben zur
>> Körpergröße etc. völlig unsinnig.
>>
>>
> Ich bin sicher, daß mir jeder Arzt bestätigen würde, daß es für jemanden wie Ricarda Lang
> eine rettende Maßnahme wäre, das Körpergewicht auf unter 80 kg zu senken.

Rettung wovor? Dass Ricarda Lang akute Gesundheitsprobleme hat, ist
nicht bekannt.

> Sie ist noch ein Twen, durchschnittlich groß und dürfte 110..130 kg wiegen.

Mit 28 ist man aber nicht mehr lange "Twen".

Und woher beziehst Du die Weisheit zum Gewicht? Rein vom äußerlichen
Anschein?

> Deine Einschränkungen sind folglich irrelevant.
> Sie hat Adipositas Grad III oder II.
> Das ist _garantiert_ sehr ungesund und stark lebensverkürzend.

Dann schreibe Sie doch persönlich an und teile ihr deine wertvollen
Tipps mit, wenn Du Dir solche Sorgen um sie machst. Ich bin gespannt,
was Sie dazu sagt.

[Rupert Haselbeck]

Arno Welzel schrieb:

> Dann schreibe Sie doch persönlich an und teile ihr deine wertvollen
> Tipps mit, wenn Du Dir solche Sorgen um sie machst. Ich bin gespannt,
> was Sie dazu sagt.

Dasselbe könntest auch du dir zu Herzen nehmen. Schreib all das, was
deine gute Seele an Helmuts Bemerkung noch immer auszusetzen hat, doch
einfach per Email. Allzuviel von dieser Art gutmenschenhaften Getues
wirkt irgendwann nur noch peinlich.

MfG
Rupert

[Arno Welzel]

Rupert Haselbeck:

Meine Anmerkungen sind nicht nur an Helmut adressiert. Ich finde es
generell ätzend, wenn man dicke Menschen wahlweise lächerlich macht -
wie etwa der "lustige" Hinweis, dass von Heinz Schmitz man wohl eine
An225 braucht, um Ricarda Lang zu transportieren - oder wie der
vermeintlich "besorgte" Kommentar von Helmut Schellong, dass sie ihre
Gesndheit gefärdet und irgendwann an multiplen Organversagen oder
Erstickung sterben könnte.

Wenn dann noch in der Diskussion klar wird, dass Helmut davon redet,
dass er "von Erfahrung getrieben" schreibt, aber tatsächlich gar keine
Erfahrung hat, auf die er sich stützt, dürfen das die Mitleser ruhig
auch wissen.

[Helmut Schellong]

Die Mitleser schütteln über Dich den Kopf!

Ich schrieb vor Tagen (03/10/2022 23:03):
|Ich kenne aus einer REHA-Klinik und einem Sole-Bad superdicke Menschen, mit einem
|Bauchumfang von etwa 2,5 m.
|Desweiteren sah ich mehrere TV-Dokumentationen zum Thema.

Was bedeutet dieser mein Text wohl?
Das ist schlicht meine Erfahrung zum Thema!
Und zwar wesentlich mehr Erfahrung als der Durchschnittsbürger zum Thema hat!
Was sonst soll denn mein obiger Text bedeuten?

https://de.wikipedia.org/wiki/Israel_Kamakawiwo%CA%BBole

Dieser hawaiianische Sänger (bis 343 kg) starb mit 38 Jahren an Atemnot.

Sehr hohes Übergewicht ist ganz ohne Zweifel stark lebensverkürzend.
Insbesondere sinkt die /gesunde Lebenszeit/ noch viel mehr.

[Hanno Foest]

On 13.03.22 22:15, Helmut Schellong wrote:

>> Wenn dann noch in der Diskussion klar wird, dass Helmut davon redet,
>> dass er "von Erfahrung getrieben" schreibt, aber tatsächlich gar keine
>> Erfahrung hat, auf die er sich stützt, dürfen das die Mitleser ruhig
>> auch wissen.
>>
> Die Mitleser schütteln über Dich den Kopf!
>
> Ich schrieb vor Tagen (03/10/2022 23:03):
> |Ich kenne aus einer REHA-Klinik und einem Sole-Bad superdicke Menschen,
> mit einem
> |Bauchumfang von etwa 2,5 m.
> |Desweiteren sah ich mehrere TV-Dokumentationen zum Thema.
>
> Was bedeutet dieser mein Text wohl?

Daß du irgendwo mal was gesehen hast, und dir jetzt einbildest, Ahnung
zu haben.

Hanno

--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

[Helmut Schellong]

On 03/14/2022 02:28, Hanno Foest wrote:
> On 13.03.22 22:15, Helmut Schellong wrote:
>
>>> Wenn dann noch in der Diskussion klar wird, dass Helmut davon redet,
>>> dass er "von Erfahrung getrieben" schreibt, aber tatsächlich gar keine
>>> Erfahrung hat, auf die er sich stützt, dürfen das die Mitleser ruhig
>>> auch wissen.
>>>
>> Die Mitleser schütteln über Dich den Kopf!
>>
>> Ich schrieb vor Tagen (03/10/2022 23:03):
>> |Ich kenne aus einer REHA-Klinik und einem Sole-Bad superdicke Menschen, mit einem
>> |Bauchumfang von etwa 2,5 m.
>> |Desweiteren sah ich mehrere TV-Dokumentationen zum Thema.
>>
>> Was bedeutet dieser mein Text wohl?
>
> Daß du irgendwo mal was gesehen hast, und dir jetzt einbildest, Ahnung zu haben.
>

> Wer das dem Text entnimmt, hat massive Probleme mit der Semantik der deutschen Sprache.
Das trifft auf einige hiesige Akteure zu.
Ist ein probates Mittel - so wie im Ukraine-Krieg.

[Hanno Foest]

Am 14.03.22 um 13:15 schrieb Helmut Schellong:

> On 03/14/2022 02:28, Hanno Foest wrote:
>> On 13.03.22 22:15, Helmut Schellong wrote:

[...]

>>> Was bedeutet dieser mein Text wohl?
>>
>> Daß du irgendwo mal was gesehen hast, und dir jetzt einbildest, Ahnung
>> zu haben.
>>
>> Wer das dem Text entnimmt, hat massive Probleme mit der Semantik der
>> deutschen Sprache.

Der letzte Satz ist nicht von mir. Informiere dich, wie man im Usenet
korrekt zitiert.

Hnano

[Arno Welzel]

Helmut Schellong:

> On 03/13/2022 15:18, Arno Welzel wrote:

[...]

>> Wenn dann noch in der Diskussion klar wird, dass Helmut davon redet,
>> dass er "von Erfahrung getrieben" schreibt, aber tatsächlich gar keine
>> Erfahrung hat, auf die er sich stützt, dürfen das die Mitleser ruhig
>> auch wissen.
>>
> Die Mitleser schütteln über Dich den Kopf!
>
> Ich schrieb vor Tagen (03/10/2022 23:03):
> |Ich kenne aus einer REHA-Klinik und einem Sole-Bad superdicke Menschen, mit einem
> |Bauchumfang von etwa 2,5 m.
> |Desweiteren sah ich mehrere TV-Dokumentationen zum Thema.

Ach so - das ist also deine "Erfahrung" dazu - Du kennst dicke Menschen
und Du hast TV-Dokumentationen gesehen.

Das macht Dich natürlich sofort unheimlich kompetent dazu, über Ricarda
Lang ein Urteil abzugeben... nicht.

> Was bedeutet dieser mein Text wohl?
> Das ist schlicht meine Erfahrung zum Thema!

Ja - die ist sehr überschaubar. Dicke Menschen hat wohl jeder schon mal
gesehen, auch sehr dicke Menschen. Und TV-Dokumentationen sehen kann
jeder. Das ist keine "Erfahrung".

> Und zwar wesentlich mehr Erfahrung als der Durchschnittsbürger zum Thema hat!
> Was sonst soll denn mein obiger Text bedeuten?

Dass Du mal irgendwann was gehört und gesehen hast, mehr nicht.

> https://de.wikipedia.org/wiki/Israel_Kamakawiwo%CA%BBole
>
> Dieser hawaiianische Sänger (bis 343 kg) starb mit 38 Jahren an Atemnot.

Ja, bei so einem *massiven* Übergewicht ist das nicht so überraschend.

Und? Was hat das mit Ricarda Lang zu tun, außer, dass sie ebenfalls
nicht schlank ist?

> Sehr hohes Übergewicht ist ganz ohne Zweifel stark lebensverkürzend.
> Insbesondere sinkt die /gesunde Lebenszeit/ noch viel mehr.

Dennoch steht Dir kein Urteil darüber zu, was Ricarda Lang persönlich
tun sollte oder nicht. Du bist weder ihr Arzt noch persönlich mit ihr
bekannt.

[Reinhardt Behm]

On Mon, 14 Mar 2022 15:01:30 +0100, Arno Welzel wrote:


> Ja - die ist sehr überschaubar. Dicke Menschen hat wohl jeder schon mal
> gesehen, auch sehr dicke Menschen. Und TV-Dokumentationen sehen kann
> jeder. Das ist keine "Erfahrung".

Ist sein angeblicher Ing-Titel von der Youtube-University?


--
Reinhardt

[Alfred Gemsa]

Am 14.03.2022 um 15:01 schrieb Arno Welzel:

> Dennoch steht Dir kein Urteil darüber zu, was Ricarda Lang persönlich
> tun sollte oder nicht. Du bist weder ihr Arzt noch persönlich mit ihr
> bekannt.

Lass ihn doch, Ricarda ist dick, er ist doof.

Aber Ricarda könnte abnehmen!

Alfred.

[Helmut Schellong]

On 03/14/2022 15:01, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 03/13/2022 15:18, Arno Welzel wrote:
> [...]
>>> Wenn dann noch in der Diskussion klar wird, dass Helmut davon redet,
>>> dass er "von Erfahrung getrieben" schreibt, aber tatsächlich gar keine
>>> Erfahrung hat, auf die er sich stützt, dürfen das die Mitleser ruhig
>>> auch wissen.
>>>
>> Die Mitleser schütteln über Dich den Kopf!
>>
>> Ich schrieb vor Tagen (03/10/2022 23:03):
>> |Ich kenne aus einer REHA-Klinik und einem Sole-Bad superdicke Menschen, mit einem
>> |Bauchumfang von etwa 2,5 m.
>> |Desweiteren sah ich mehrere TV-Dokumentationen zum Thema.
>
> Ach so - das ist also deine "Erfahrung" dazu - Du kennst dicke Menschen
> und Du hast TV-Dokumentationen gesehen.
>
> Das macht Dich natürlich sofort unheimlich kompetent dazu, über Ricarda
> Lang ein Urteil abzugeben... nicht.

Schon wieder der Beweis, daß Du semantisch Deutsch nicht richtig verstehst.

Ja, ich habe super-dicke Menschen kennen gelernt!
Ich habe viele Informationen von denen erfahren! --> Erfahrung

# kennen:
# Etwas, jemanden, sich kennen. Über etwas, jemanden durch eigene Wahrnehmung
# und Erfahrung Bescheid wissen.

#erfahren:
#Von etwas Kenntnis erhalten, etwas zu wissen bekommen.
#Erfahrung:
#Bestimmte Kenntnisse oder Einsichten, zu denen jemand durch meist wiederholte Wahrnehmung gelangt ist.
#Etwas in Erfahrung bringen (= etwas durch Nachforschungen erfahren).

#Das weiß ich aus eigener, persönlicher Erfahrung.
Dies ist nicht notwendig - habe ich auch nicht behauptet.

>> Was bedeutet dieser mein Text wohl?
>> Das ist schlicht meine Erfahrung zum Thema!
>
> Ja - die ist sehr überschaubar. Dicke Menschen hat wohl jeder schon mal
> gesehen, auch sehr dicke Menschen. Und TV-Dokumentationen sehen kann
> jeder. Das ist keine "Erfahrung".

Doch, ist es sehr wohl.
Allein einen super-dicken Menschen zu sehen (Wahrnehmung) ist bereits eine Erfahrung.
Und mehrere TV-Dokumentationen, die viele Informationen von Fachärzten geben, erst recht.

Du und die anderen, die behaupten, ich sei doof, seid doof - ich hingegen bin nicht doof.
Ich bin fast immer der Wissende.

>> Und zwar wesentlich mehr Erfahrung als der Durchschnittsbürger zum Thema hat!
>> Was sonst soll denn mein obiger Text bedeuten?
>
> Dass Du mal irgendwann was gehört und gesehen hast, mehr nicht.

Eine haltlose Behauptung, die zudem mangelndes Verständnis deutscher Sprache beweist.

>> https://de.wikipedia.org/wiki/Israel_Kamakawiwo%CA%BBole
>>
>> Dieser hawaiianische Sänger (bis 343 kg) starb mit 38 Jahren an Atemnot.
>
> Ja, bei so einem *massiven* Übergewicht ist das nicht so überraschend.

Ich sprach von sehr großem Übergewicht, von super-dick, Adipositas Grad III oder II.

https://img.welt.de/img/gesundheit/mobile133702065/4221620757-ci23x11-w1136/Dicke-2.jpg

> Und? Was hat das mit Ricarda Lang zu tun, außer, dass sie ebenfalls
> nicht schlank ist?

Was soll diese Formulierung 'nicht schlank'? Willst Du etwas wegreden?
Ricarda Lang ist definitiv super-dick.

Außerdem kann sie ihr Gewicht noch fast beliebig steigern.
Deshalb riet ich dazu, jetzt in noch jungen Jahren ihr Gewicht auf unter 80 kg zu bringen.

>> Sehr hohes Übergewicht ist ganz ohne Zweifel stark lebensverkürzend.
>> Insbesondere sinkt die /gesunde Lebenszeit/ noch viel mehr.
>
> Dennoch steht Dir kein Urteil darüber zu, was Ricarda Lang persönlich
> tun sollte oder nicht. Du bist weder ihr Arzt noch persönlich mit ihr
> bekannt.
>

Doch.
Ich darf beliebig fremden Personen (dringend) zu etwas raten.
Auch Dir, falls Du ein Gewicht von 180 kg nennen würdest.

[Arno Welzel]

Helmut Schellong:

[...]

> Und mehrere TV-Dokumentationen, die viele Informationen von Fachärzten geben, erst recht.
>
> Du und die anderen, die behaupten, ich sei doof, seid doof - ich hingegen bin nicht doof.
> Ich bin fast immer der Wissende.

Ja, das ist dein größter Fehler - Du glaubst alles zu wissen.

[...]

>> tun sollte oder nicht. Du bist weder ihr Arzt noch persönlich mit ihr
>> bekannt.
>>
> Doch.

Nein.

> Ich darf beliebig fremden Personen (dringend) zu etwas raten.
> Auch Dir, falls Du ein Gewicht von 180 kg nennen würdest.

Dann würde ich mir verbitten, mir irgendwelche Ratschläge zu meinem
Körper geben.

[Helmut Schellong]

On 03/25/2022 17:10, Arno Welzel wrote:
> Helmut Schellong:
>
> [...]
>> Und mehrere TV-Dokumentationen, die viele Informationen von Fachärzten geben, erst recht.
>>
>> Du und die anderen, die behaupten, ich sei doof, seid doof - ich hingegen bin nicht doof.
>> Ich bin fast immer der Wissende.
>
> Ja, das ist dein größter Fehler - Du glaubst alles zu wissen.

Falsch.
Ich beteilige mich nur, wenn ich sicher weiß, daß ich zum Thema recht viel weiß.

> [...]
>>> tun sollte oder nicht. Du bist weder ihr Arzt noch persönlich mit ihr
>>> bekannt.
>>>
>> Doch.
>
> Nein.

Doch.

>> Ich darf beliebig fremden Personen (dringend) zu etwas raten.
>> Auch Dir, falls Du ein Gewicht von 180 kg nennen würdest.
>
> Dann würde ich mir verbitten, mir irgendwelche Ratschläge zu meinem
> Körper geben.
>
>

Das würde Dir nichts nützen.
Ich dürfte gegen Deinen Willen sachliche Hinweise geben, nachdem Du selbst
ein Gewicht von 180 kg als Dein Gewicht veröffentlicht haben würdest.

[Hanno Foest]

On 25.03.22 17:42, Helmut Schellong wrote:

>> Ja, das ist dein größter Fehler - Du glaubst alles zu wissen.
>
> Falsch.
> Ich beteilige mich nur, wenn ich sicher weiß, daß ich zum Thema recht
> viel weiß.

Ich weiß sehr sicher, daß du zu fast allen Themen hier dummes Zeug erzählst.

Hanno

[Marcel Mueller]

Am 07.03.22 um 16:08 schrieb Helmut Schellong:

> Die sollte noch in jungen Jahren ihr Gewicht auf unter 80 kg bringen.

Wo ist der Bus?
... mit den Leuten, die das interessiert.

Bitte einfach lassen.


Marcel

[Helmut Schellong]

On 03/25/2022 17:57, Hanno Foest wrote:
> On 25.03.22 17:42, Helmut Schellong wrote:
>
>>> Ja, das ist dein größter Fehler - Du glaubst alles zu wissen.
>>
>> Falsch.
>> Ich beteilige mich nur, wenn ich sicher weiß, daß ich zum Thema recht viel weiß.
>
> Ich weiß sehr sicher, daß du zu fast allen Themen hier dummes Zeug erzählst.
>
>

Eine Aufzählung wäre mal interessant.
Ich beweise oft meine Aussagen.
Insbesondere deshalb wäre eine Aufzählung aufschlußreich.
Ohne Aufzählung ist es einfach nur eine leere Behauptung.

[Helmut Schellong]

Das nützte nichts, weil ich diese Person nicht ins Spiel brachte.

[Hanno Foest]

On 25.03.22 18:35, Helmut Schellong wrote:

>> Ich weiß sehr sicher, daß du zu fast allen Themen hier dummes Zeug
>> erzählst.
>
> Eine Aufzählung wäre mal interessant.

Wozu?

> Ich beweise oft meine Aussagen.

Ich hab schon häufiger bewiesen, daß du Unsinn redest. Hast du aber
nicht verstanden.

[Helmut Schellong]

On 03/25/2022 20:49, Hanno Foest wrote:
> On 25.03.22 18:35, Helmut Schellong wrote:
>
>>> Ich weiß sehr sicher, daß du zu fast allen Themen hier dummes Zeug erzählst.
>>
>> Eine Aufzählung wäre mal interessant.
>
> Wozu?
>
>> Ich beweise oft meine Aussagen.
>
> Ich hab schon häufiger bewiesen, daß du Unsinn redest. Hast du aber nicht verstanden.
>
>

Erneut eine Behauptung.

[Hanno Foest]

On 25.03.22 21:08, Helmut Schellong wrote:

>>>> Ich weiß sehr sicher, daß du zu fast allen Themen hier dummes Zeug
>>>> erzählst.
>>>
>>> Eine Aufzählung wäre mal interessant.
>>
>> Wozu?
>>
>>> Ich beweise oft meine Aussagen.
>>
>> Ich hab schon häufiger bewiesen, daß du Unsinn redest. Hast du aber
>> nicht verstanden.
>
> Erneut eine Behauptung.

Wie deine Behauptung, daß du irgendwas von dem verstanden hast, wozu du
deinen Senf gibst.

[Rupert Haselbeck]

Arno Welzel schrieb:

> Helmut Schellong:
>
> [...]
>> Und mehrere TV-Dokumentationen, die viele Informationen von Fachärzten geben, erst recht.
>>
>> Du und die anderen, die behaupten, ich sei doof, seid doof - ich hingegen bin nicht doof.
>> Ich bin fast immer der Wissende.
>
> Ja, das ist dein größter Fehler - Du glaubst alles zu wissen.

Ja. Und der Kasper merkt es noch nicht mal, wenn man ihn mit der Nase
drauf stößt

>> Ich darf beliebig fremden Personen (dringend) zu etwas raten.
>> Auch Dir, falls Du ein Gewicht von 180 kg nennen würdest.
>
> Dann würde ich mir verbitten, mir irgendwelche Ratschläge zu meinem
> Körper geben.

Wenn du das wirklich meinen solltest, dann bist du im Usenet schlicht
falsch. Man kann sich die Antworten nicht aussuchen, welche man erhält
und man hat auch keinen Anspruch auf wohlgefällige Antworten.
In der Tat ist die geäußerte Ansicht bezüglich erheblich übergewichtiger
Menschen ja nicht wirklich von der Hand zu weisen, dass es nämlich eher
nicht gesundheitsförderlich sein könnte, wenn man allzu fett (oder
politisch korrekt "übergewichtig" oder "fettleibig"?) ist. Die
medizinische Wissenschaft scheint da durchaus ähnliches gerne und teils
auch recht vehement zu behaupten. Und das gilt dann halt auch dann, wenn
man es nicht so gerne hören mag und sogar dann, wenn man sich gar selber
angesprochen fühlen könnte. Kein Grund zur Aufregung also in diesem Punkt

MfG
Rupert

[Heinz Schmitz]

Korrekt wäre gewesen "Bitte einfach nicht lesen."

Grüße,
H.

[Helmut Schellong]

On 03/25/2022 22:30, Hanno Foest wrote:
> On 25.03.22 21:08, Helmut Schellong wrote:
>
>>>>> Ich weiß sehr sicher, daß du zu fast allen Themen hier dummes Zeug erzählst.
>>>>
>>>> Eine Aufzählung wäre mal interessant.
>>>
>>> Wozu?
>>>
>>>> Ich beweise oft meine Aussagen.
>>>
>>> Ich hab schon häufiger bewiesen, daß du Unsinn redest. Hast du aber nicht verstanden.
>>
>> Erneut eine Behauptung.
>
> Wie deine Behauptung, daß du irgendwas von dem verstanden hast, wozu du deinen Senf gibst.
>
>

Neuestes Thema:
---------------
Ich habe die kryptographischen Algorithmen Rabbit, Spritz,
sha2_256, sha2_512, sha3_256, sha3_512 (Keccak) konkret implementiert.

Dies kann mit Hilfe von http://www.schellong.de/htm/bishmnk.htm kontrolliert werden.
(Auch: Find in this page...; bish -c "coder -C")

Ein konkretes Arbeitsskript: http://www.schellong.de/htm/rabbit.bish.html

Folglich muß ich zwingend irgendwas davon verstehen.


Es scheint hier große Langeweile zu herrschen, angesichts dessen, daß
ich Beweise zum x-ten Mal posten soll/muß.

--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz

[Helmut Schellong]

On 03/26/2022 00:00, Rupert Haselbeck wrote:
> Arno Welzel schrieb:
>> Helmut Schellong:
>>
>> [...]
>>> Und mehrere TV-Dokumentationen, die viele Informationen von Fachärzten geben, erst recht.
>>>
>>> Du und die anderen, die behaupten, ich sei doof, seid doof - ich hingegen bin nicht doof.
>>> Ich bin fast immer der Wissende.
>>
>> Ja, das ist dein größter Fehler - Du glaubst alles zu wissen.
>
> Ja. Und der Kasper merkt es noch nicht mal, wenn man ihn mit der Nase drauf stößt

Nach Art von Trump, Putin, Lawrow, ...

[Hanno Foest]

On 26.03.22 14:16, Helmut Schellong wrote:

>>>> Ich hab schon häufiger bewiesen, daß du Unsinn redest. Hast du aber
>>>> nicht verstanden.
>>>
>>> Erneut eine Behauptung.
>>
>> Wie deine Behauptung, daß du irgendwas von dem verstanden hast, wozu
>> du deinen Senf gibst.
>
> Neuestes Thema:
> ---------------
> Ich habe die kryptographischen Algorithmen Rabbit, Spritz,
> sha2_256, sha2_512, sha3_256, sha3_512 (Keccak) konkret implementiert.

Exzellentes Beispiel.

https://security.stackexchange.com/questions/209652/why-is-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be

> Folglich muß ich zwingend irgendwas davon verstehen.

Du hast belegt, daß du zu dumm bist, die Problematik deines Treibens zu
verstehen. Begründung siehe Link. Es ist klar, daß du es auch diesmal
wieder nicht verstehen wirst, also spar dir die Antwort.

[Helmut Schellong]

On 03/26/2022 23:59, Hanno Foest wrote:
> On 26.03.22 14:16, Helmut Schellong wrote:
>
>>>>> Ich hab schon häufiger bewiesen, daß du Unsinn redest. Hast du aber nicht verstanden.
>>>>
>>>> Erneut eine Behauptung.
>>>
>>> Wie deine Behauptung, daß du irgendwas von dem verstanden hast, wozu du deinen Senf gibst.
>>
>> Neuestes Thema:
>> ---------------
>> Ich habe die kryptographischen Algorithmen Rabbit, Spritz,
>> sha2_256, sha2_512, sha3_256, sha3_512 (Keccak) konkret implementiert.
>
> Exzellentes Beispiel.
>
> https://security.stackexchange.com/questions/209652/why-is-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be
>
>> Folglich muß ich zwingend irgendwas davon verstehen.
>
> Du hast belegt, daß du zu dumm bist, die Problematik deines Treibens zu verstehen. Begründung siehe Link. Es ist klar, daß du es auch diesmal wieder nicht verstehen wirst, also spar dir die Antwort.
>
>

Ich habe belegt, daß ich vom Thema mehr verstehe als (fast) alle hier.
Das Folgende muß ich schreiben, um die Leserschaft hier vor dem unzutreffenden
Inhalt unter dem Link zu warnen.

Was unter dem Link geschrieben steht, ist absurder Quatsch - bis auf die erste Aussage.

Man sollte tatsächlich nicht selbst einen kryptographischen Algorithmus ENTWICKELN!
Falls man diesen produktiv einsetzen will.
Das können berufliche Kryptologen viel besser - vor allen Dingen die abschließenden
Untersuchungen zur Qualität des Algo.

Hingegen ist gegen eine Implementation eines Kern-Algorithmus' streng nach Vorschrift
des NIST oder eines RFC# nichts einzuwenden.
Vorausgesetzt, es werden Testvektoren geprüft.

406] /sbin/sha256 bsh.c
SHA256 (bsh.c) = 9b67d7cc5ec0f3cd79950f19c4be6735b1d3f061c0489fcef5e5cecfb499c6ff
407] bish -c "sha256 bsh.c"
SHA2-256 (bsh.c) = 9b67d7cc5ec0f3cd79950f19c4be6735b1d3f061c0489fcef5e5cecfb499c6ff
409] bish -c "sha256 -3 bsh.c"
SHA3-256 (bsh.c) = 06c1372d07fcf498cf73cc6f8981687808858977dda8f148cd63df6b3d76a694
410]

Wenn die Resultate exakt gleich sind, ist es 100% in Ordnung.
Es gibt auch eine Krypto-Seite im Netz, die nnn Algorithmen mit ihren korrekten Ausgaben beschreibt.
Ebenso 100% korrekt ist meine Implementation des Rabbit gemäß RFC4503 mit Prüfung der Testvektoren, die
darin im Anhang A enthalten sind.

Die Schreiber unter dem Link wollen offenbar 'ein wenig angeben' und sich besonders wissend darstellen.
Und ich bin schlicht ein professioneller Programmierer - einer der besten.

[Volker Bartheld]

On Sat, 26 Mar 2022 23:59:18 +0100, Hanno Foest wrote:
> On 26.03.22 14:16, Helmut Schellong wrote:
>> Ich habe die kryptographischen Algorithmen Rabbit, Spritz,
>> sha2_256, sha2_512, sha3_256, sha3_512 (Keccak) konkret implementiert.
> Exzellentes Beispiel.
> https://security.stackexchange.com/questions/209652/why-is-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be

Ein erfreulich fundierter, präziser und informativer Artikel auf
Stackexchange. Chapeau. Genau das ist das Problem mit NIHS-Designs und
NIHS-Implementierungen. Sogar NIHS-Usecases sind ein Problem, wie wir
seit der NIST-Affäre mit dem Dual_EC-DRBG wissen. Dort waren
ausgerechnet in einer Referenzimplementierung schwache Startwerte
empfohlen worden, die die Sicherheit eines speziellen
Zufallszahlengenerators kompromittierten [1]. Manch einer sprach von
der "NSA-Backdoor".

>> Folglich muß ich zwingend irgendwas davon verstehen.
> Du hast belegt, daß du zu dumm bist, die Problematik deines Treibens zu
> verstehen. Begründung siehe Link. Es ist klar, daß du es auch diesmal
> wieder nicht verstehen wirst, also spar dir die Antwort.

Davon ist leider auszugehen. Ich finde es erschreckend mit welchem
eklatanten Mangel an Demut, Selbstreflektion, Einsichtsfähigkeit und
Lernvermögen Schellong in seinen Aussagen permanent rüberkommt.
Hoffentlich ist er ein Trollbot oder zumindest komplett vollkommen
irrelevant in seinem Wirken, sonst wäre er eine Gefahr. In diesem
Lichte müßte man auch unbesehen von seinem Buch [2] abraten, denn die
o. g. Defizite sind so dermaßen gravierend und umfassend, daß sie auch
auf jegliche andere wissenschaftliche Bereiche durchschlagen.

Ich trage das Thema für mich nun zu Grabe, die peinliche Diskussion über
dicke Menschen bedarf ebenfalls keiner weiteren Fortsetzung.

Volker

[1] https://www.schneier.com/essays/archives/2007/11/did_nsa_put_a_secret.html
[2] https://www.amazon.de/dp/3642544363

[Helmut Schellong]

Aha.

> Ich trage das Thema für mich nun zu Grabe, die peinliche Diskussion über
> dicke Menschen bedarf ebenfalls keiner weiteren Fortsetzung.
>
>

Du bist ein saublöder, stupider, phantasieloser Ignorant, der zudem
nicht richtig in Deutsch formulieren kann.
Man muß nach Luft schnappen, wenn Dein vorstehender Blödsinn gelesen wird.
Du stellst plattestmögliche Behauptungen auf.

Meine Implementationen sind allesamt als 100% korrekt geprüft.
Diesen Punkt - den ich ja beschrieb - hast Du geflissentlich ignoriert.

Eklatanter Mangel an Demut, Selbstreflexion, Einsichtsfähigkeit und
Lernvermögen ist folglich nicht zuzuordnen.
Das paßt nicht, angesichts meiner bewiesenermaßen fehlerlosen Implementationen.


Der Inhalt unter dem Link ist an den Haaren herbeigezogener Bullshit.
Es ist Zeitverschwendung, ihn ganz genau durchzuarbeiten.

Meine kryptographischen Algorithmen befinden sich in einer binären Executable.
Angewendet werden die Algorithmen nur auf lokaler Festplatte.
Es gibt da keinerlei Berührung mit 'side-channel', Server, Password.

|Cryptographic code looks very different from "regular" code.
Das ist vollkommen falsch - einfach Unsinn!

|public void TestEncryptDecryptSuccess()
Keinerlei Berührung mit so etwas!
Idiotische 'kranke' Parameterwerte kommen bei mir nie vor!

|Implementation Errors
Gibt es bewiesenermaßen nicht bei mir!

|Heartbleed, ...
Kinderkram!

=========================================================================
RFC 4503 Rabbit Encryption May 2006


Appendix A: Test Vectors

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

A.1. Testing without IV Setup

key = [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
S[0] = [B1 57 54 F0 36 A5 D6 EC F5 6B 45 26 1C 4A F7 02]
S[1] = [88 E8 D8 15 C5 9C 0C 39 7B 69 6C 47 89 C6 8A A7]
S[2] = [F4 16 A1 C3 70 0C D4 51 DA 68 D1 88 16 73 D6 96]

key = [91 28 13 29 2E 3D 36 FE 3B FC 62 F1 DC 51 C3 AC]
S[0] = [3D 2D F3 C8 3E F6 27 A1 E9 7F C3 84 87 E2 51 9C]
S[1] = [F5 76 CD 61 F4 40 5B 88 96 BF 53 AA 85 54 FC 19]
S[2] = [E5 54 74 73 FB DB 43 50 8A E5 3B 20 20 4D 4C 5E]
=========================================================================

Was ist an der Verwendung vorstehenden Textes nicht zu verstehen?

[Rupert Haselbeck]

Helmut Schellong schrieb:

> Rupert Haselbeck wrote:
>> Arno Welzel schrieb:
>>> Helmut Schellong:
>>> [...]

>>>> Du und die anderen, die behaupten, ich sei doof, seid doof - ich
>>>> hingegen bin nicht doof.
>>>> Ich bin fast immer der Wissende.
>>>
>>> Ja, das ist dein größter Fehler - Du glaubst alles zu wissen.
>>
>> Ja. Und der Kasper merkt es noch nicht mal, wenn man ihn mit der Nase
>> drauf stößt
>
> Nach Art von Trump, Putin, Lawrow, ...

Das ist natürlich auch wieder grandioser Unsinn. Jeder der Genannten ist
dir intellektuell grenzenlos überlegen (was freilich nicht weiter schwer
ist).
Nur weil jemand derart kriminell handelt wie vor allem Putin das seit
vielen Jahren, seit er an der Macht ist, tut, kann man ihn nicht als
wenig intelligent ansehen. Ganz im Gegenteil bedarf es zumeist eines
hohen Maßes an Intelligenz und Wissen, um derlei Positionen zu
erreichen. Überhebliche Studienabbrecher schaffen das eher nicht,
scheiterst du doch bereits an Dingen, welche eigentlich ja Basiswissen sind

MfG
Rupert

[Helmut Schellong]

Na, wieder mal geblubbert?!

Habe ich irgend etwas zu Intelligenz dieser drei Personen gesagt?
Nein.
Mein Studium hatte ich abgebrochen, nachdem ich etwa 5 Jahre
in der Industrie als hochbezahlter Entwicklungsingenieur arbeitete.

--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz

[Hanno Foest]

On 27.03.22 11:47, Rupert Haselbeck wrote:

> Nur weil jemand derart kriminell handelt wie vor allem Putin das seit
> vielen Jahren, seit er an der Macht ist, tut, kann man ihn nicht als
> wenig intelligent ansehen. Ganz im Gegenteil bedarf es zumeist eines
> hohen Maßes an Intelligenz und Wissen, um derlei Positionen zu
> erreichen. Überhebliche Studienabbrecher schaffen das eher nicht,

Im Falle Deutschlands reichte allerdings ein Maler aus Österreich ohne
Schulabschluß.

[Hanno Foest]

On 27.03.22 04:25, Helmut Schellong wrote:

>> Du hast belegt, daß du zu dumm bist, die Problematik deines Treibens
>> zu verstehen. Begründung siehe Link. Es ist klar, daß du es auch
>> diesmal wieder nicht verstehen wirst, also spar dir die Antwort.
>
> Ich habe belegt, daß ich vom Thema mehr verstehe als (fast) alle hier.

qed

[Axel Berger]

Hanno Foest wrote:
> https://security.stackexchange.com/questions/209652/why-is-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be

Danke, sehr lehrreich und wußte ich (fast) alles vorher nicht. Eine
Einschränkung möchte ich aber doch anbringen:

Die heutigen Angreifer haben keinerlei Interesse an mir. Sie wollen mit
hoher Effizienz Millionen wenn nicht Milliarden von Datensätzen
abgreifen. Alles, das bei mir aus der Reihe fällt, hilft, auch wenn es
einen Menschen keine fünf Minuten kostet.

Primitivbeispiel: Wenn meine Adressliste nicht in Google-Contacts liegt
sondern in einer unverschlüsselten Textdatei, wird Google die nicht
finden und nicht lesen. (Und sonst auch keiner, der nicht gezielt
Interesse an mir hätte.) Zur Strafe funktionieren dann viele recht
nützliche Dienste nicht.


--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

[Rupert Haselbeck]

Hanno Foest schrieb:

> Rupert Haselbeck wrote:
>> Nur weil jemand derart kriminell handelt wie vor allem Putin das seit
>> vielen Jahren, seit er an der Macht ist, tut, kann man ihn nicht als
>> wenig intelligent ansehen. Ganz im Gegenteil bedarf es zumeist eines
>> hohen Maßes an Intelligenz und Wissen, um derlei Positionen zu
>> erreichen. Überhebliche Studienabbrecher schaffen das eher nicht,
>
> Im Falle Deutschlands reichte allerdings ein Maler aus Österreich ohne
> Schulabschluß.

ACK. Daher schrieb ich ja "zumeist"...
Helmut fehlen aber offensichtlich auch all jene Fähigkeiten, welche
jenen österreichischen Maler in die Lage versetzten, das zu tun, was er
denn schließlich tat.

MfG
Rupert

[Hanno Foest]

On 27.03.22 13:56, Axel Berger wrote:

>> https://security.stackexchange.com/questions/209652/why-is-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be
>
> Danke, sehr lehrreich und wußte ich (fast) alles vorher nicht. Eine
> Einschränkung möchte ich aber doch anbringen:
>
> Die heutigen Angreifer haben keinerlei Interesse an mir.

Das ist gut möglich - es gibt viele Bedrohungsszenarien, die man
diskutieren könnte, aber so lange man sich nicht gerade technisch
versierte Feinde gemacht hat, ist man als individuelles Ziel in der Tat
eher uninteressant.

Das hilft dir aber nicht unbedingt, denn wenn ein automatisierter
Angriff z.B. eines deiner Passwörter herausfindet, kann man mit dem
entsprechenden Account trotzdem unangenehmen Unfug anstellen. Auch wenn
der Angreifer (Bot, Skript...) gegen dich persönlich gar nichts hat,
weil du für ihn nur ein anonymes, mglw. lohnendes, Ziel, wegen der
dahintersteckenden Ressourcen, bist.

[Andreas Neumann]

Axel Berger wrote:

> Die heutigen Angreifer haben keinerlei Interesse an mir. Sie wollen mit
> hoher Effizienz Millionen wenn nicht Milliarden von Datensätzen
> abgreifen.

Rede Dir das nur weiter ein.
Meine persönliche Erfahrung spricht gegenteiliges.

[Helmut Schellong]

Zufall - oder gar nicht klar.

[Volker Bartheld]

On Sun, 27 Mar 2022 14:57:41 +0200, Hanno Foest wrote:
> On 27.03.22 13:56, Axel Berger wrote:
>>> https://security.stackexchange.com/questions/209652/why-is-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be

>> Die heutigen Angreifer haben keinerlei Interesse an mir.

Den heutigen Angreifer nehmen Menschen wie Dich nicht als Individuen
wahr. Für die bist Du eine IP-Adresse hinter einem potentiell
kompromittierbaren Router, an einem PC mit kaputtem IT-Stack, wo man
automatisiert Ransomware plazieren und Dich um Bitcoins erpressen kann.

Vielleicht bis Du auch naiv genug, Deine Paßwortdatei c:\Users\Axel
Berger\Documents\passwords.txt zu nennen und C$ ist ein Defaultshare
von C:\, Adminpaßwort logischerweise Axel|Berger. Das Interesse gilt z.
B. Deinen Kreditkartendaten, die man mit einer RegEx-Suche im
Handumdrehen findet. Dann ist Deine digitale Identität am Arsch (aber
sowas von!) und Du brauchst Wochen, bis Du die Zahnpasta wieder so
halbwegs in die Tube zurückpipettiert hast.

Derweil klimpert ein weiterer Euro in meiner Kasse, auf der steht:
"Warum sollte ausgerechnet *ich* gehackt werden?".

> Das hilft dir aber nicht unbedingt, denn wenn ein automatisierter
> Angriff z.B. eines deiner Passwörter herausfindet

Oder ein Freund eines Freundes eines für Hacker interessanteren
Bekannten, der vielleicht auf Phishing hereingefallen ist und Dich in
seinem auf Facebook exportierten Android-Adreßbuchs hatte.

> kann man mit dem entsprechenden Account trotzdem unangenehmen Unfug
> anstellen. Auch wenn der Angreifer (Bot, Skript...) gegen dich
> persönlich gar nichts hat, weil du für ihn nur ein anonymes, mglw.
> lohnendes, Ziel, wegen der dahintersteckenden Ressourcen, bist.

Warum gibt es Phishing? Wegen Menschen, die glauben, Angreifer hätten
kein Interesse an ihnen. Mailschnipsel:

===================================================================
Von: "bitcoin.de" <info@*********-tiefbau.de>
Gesendet: 27. Februar 2022 19:52:47 MEZ
An: "glen.*******" <glen.*******@************.de>
Betreff: Ihr Konto wird deaktiviert - Russland Sanktionen

Hallo Herr **** *********,

Durch das aktuelle Vorgehen der russischen Regierung und den damit
einhergehenden Sanktionen der Europäischen Union, sind alle
Finanzdienstleister in der EU dazu verpflichtet sicherzustellen, dass
alle ihre Kunden sich an die neuen Sanktionen halten.

Deswegen ist eine Verifikation ihrer Daten notwendig. Bitte beachten
Sie, dass es zu Verlängerten Ladezeiten kommen kann.

Bei ausbleibender Identifikation bis zum 01.03.2022, sind wir nach EU
Recht dazu verpflichtet, Ihr Konto zu schließen und Ihr Guthaben
einzufrieren.

Weiter zur Website

Mit freundlichen Grüßen
Ihr Team von bitcoin.de
===================================================================

Ja, haha. Schon klar. Wir klicken da nicht drauf. Aber Deine Sekretärin?
Dein Vater? Der Freund eines Freundes? Eltern des Klasskameraden vom
Kind? Und schon steigt die Party.

Volker

[Volker Bartheld]

On Sun, 27 Mar 2022 14:57:41 +0200, Hanno Foest wrote:

> On 27.03.22 13:56, Axel Berger wrote:
>>> https://security.stackexchange.com/questions/209652/why-is-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be

>> Die heutigen Angreifer haben keinerlei Interesse an mir.

Die heutigen Angreifer nehmen Menschen wie Dich nicht als Individuen

wahr. Für die bist Du eine IP-Adresse hinter einem potentiell
kompromittierbaren Router, an einem PC mit kaputtem IT-Stack, wo man
automatisiert Ransomware plazieren und Dich um Bitcoins erpressen kann.

Vielleicht bis Du auch naiv genug, Deine Paßwortdatei c:\Users\Axel
Berger\Documents\passwords.txt zu nennen und C$ ist ein Defaultshare
von C:\, Adminpaßwort logischerweise Axel|Berger. Das Interesse gilt z.
B. Deinen Kreditkartendaten, die man mit einer RegEx-Suche im
Handumdrehen findet. Dann ist Deine digitale Identität am Arsch (aber
sowas von!) und Du brauchst Wochen, bis Du die Zahnpasta wieder so
halbwegs in die Tube zurückpipettiert hast.

Derweil klimpert ein weiterer Euro in meiner Kasse, auf der steht:
"Warum sollte ausgerechnet *ich* gehackt werden?".

> Das hilft dir aber nicht unbedingt, denn wenn ein automatisierter

> Angriff z.B. eines deiner Passwörter herausfindet

Oder ein Freund eines Freundes eines für Hacker interessanteren
Bekannten, der vielleicht auf Phishing hereingefallen ist und Dich in
seinem auf Facebook exportierten Android-Adreßbuchs hatte.

> kann man mit dem entsprechenden Account trotzdem unangenehmen Unfug
> anstellen. Auch wenn der Angreifer (Bot, Skript...) gegen dich
> persönlich gar nichts hat, weil du für ihn nur ein anonymes, mglw.
> lohnendes, Ziel, wegen der dahintersteckenden Ressourcen, bist.

[Helmut Schellong]

On 03/27/2022 22:21, Volker Bartheld wrote:
> On Sun, 27 Mar 2022 14:57:41 +0200, Hanno Foest wrote:
>> On 27.03.22 13:56, Axel Berger wrote:
>>>> https://security.stackexchange.com/questions/209652/why-is-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be
>>> Die heutigen Angreifer haben keinerlei Interesse an mir.
>
> Die heutigen Angreifer nehmen Menschen wie Dich nicht als Individuen
> wahr. Für die bist Du eine IP-Adresse hinter einem potentiell
> kompromittierbaren Router, an einem PC mit kaputtem IT-Stack, wo man
> automatisiert Ransomware plazieren und Dich um Bitcoins erpressen kann.

Die (dynamische) WAN-Adresse, auf die es ankommt, ist _vor_ dem Router.

[...]

> Warum gibt es Phishing? Wegen Menschen, die glauben, Angreifer hätten
> kein Interesse an ihnen. Mailschnipsel:
>

> [...]

>
> Ja, haha. Schon klar. Wir klicken da nicht drauf. Aber Deine Sekretärin?
> Dein Vater? Der Freund eines Freundes? Eltern des Klasskameraden vom
> Kind? Und schon steigt die Party.
>
>

Ein bloßes Draufklicken wird da nicht reichen.

[Thomas Prufer]

On Sun, 27 Mar 2022 11:39:49 +0200, Helmut Schellong <r...@schellong.biz> wrote:

>Meine Implementationen sind allesamt als 100% korrekt geprüft.
>Diesen Punkt - den ich ja beschrieb - hast Du geflissentlich ignoriert.
>

...

>Das paßt nicht, angesichts meiner bewiesenermaßen fehlerlosen Implementationen.

...

>|Implementation Errors
> Gibt es bewiesenermaßen nicht bei mir!

Einen Beweis einer fehlerlosen Implementation eines nichttrivialen Algorithmus
zu behaupten ist gewagt. Dazu kommt noch die Unterscheidung von Algorithmus und
implementiertem Algorithmus bzw. Code.

Das einige Testdaten in einem ausführbaren Programm die erwarteten Ausgangsdaten
korrekt erzeugen ist dazu *nicht* ausreichend -- das ist trivial beweisbar.

Wie gewagt die Aussagen "100% korrekt" und "bewiesenermaßen fehlerfrei" sind,
mögen die hier kommentieren die mehr von theoretischer Informatik verstehen als
ich. Geht aber in die Richtung eines funktionierenden perpetuum mobile...


Thomas Prufer

[Helmut Schellong]

Es ist _ganz generell_ richtig, was Du schreibst.
Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht.

Diese hatte ich aufgelistet:
|Die Kern-Algorithmen sind nicht selbst entwickelt.
|Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
|sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
|Diese Algorithmen sind alle kryptographisch.

In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
ist auch meist eine Testprozedur durch die Entwickler angegeben.
Diese habe ich jeweils durchgeführt!
Mit jeweils demjenigen Ergebnis, das Korrektheit beweist!
Hatte ich mehrfach gepostet - und wurde jeweils ignoriert.
Korrekter und beweiskräftiger geht es nicht!

Desweiteren ist abhängig vom Algorithmus meist ein einziger Test tatsächlich beweiskräftig.
Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.
Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines jeden Algorithmus, diesen
zu 'knacken' oder Schwächen zu entdecken.
Alle obigen sha-Algorithmen liefern einen hash-Wert, der einzigartig für den jeweiligen Input ist!
Es gab bisher weltweit _nie_ zwei gleiche Hashes für unterschiedlichen Input!
Genau deshalb ist ein einziges korrektes Testergebnis ein /Beweis für eine korrekte Implementation/!

Wenn ein Testverfahren angegeben ist, werden oft mehrere verschiedene Test-Inputs angegeben, um
wirklich _jeden Zweifel_ auszuräumen.
Ich habe stets alle diese Tests durchgeführt - mit übereinstimmendem Ergebnis.

Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte Länge, innerhalb
derer (sogar) die kryptographische Qualität gesichert ist.
Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich --> deterministisch.
Andernfalls könnte nicht verschlüsselt und entschlüsselt werden!
Deshalb ist auch hier eine übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis
für eine korrekte Implementation.
Die Wahrscheinlichkeit für eine fehlerhafte Implementation hier wäre so gering, daß deren
Kehrwert wohl größer wäre, als es Atome im Universum gibt.

[Thomas Prufer]

On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <r...@schellong.biz> wrote:

>Es ist _ganz generell_ richtig, was Du schreibst.
>Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht.
>
>Diese hatte ich aufgelistet:
> |Die Kern-Algorithmen sind nicht selbst entwickelt.
> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
> |Diese Algorithmen sind alle kryptographisch.
>
>In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>ist auch meist eine Testprozedur durch die Entwickler angegeben.
>Diese habe ich jeweils durchgeführt!
>Mit jeweils demjenigen Ergebnis, das Korrektheit beweist!
>Hatte ich mehrfach gepostet - und wurde jeweils ignoriert.
>Korrekter und beweiskräftiger geht es nicht!

Das wurde ignoriert weil es kein Beweis ist...

>Desweiteren ist abhängig vom Algorithmus meist ein einziger Test tatsächlich beweiskräftig.

Das ist ein Indiz für Korrektheit, vielleicht, aber kein Beweis.

>Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.
>Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines jeden Algorithmus, diesen
>zu 'knacken' oder Schwächen zu entdecken.
>Alle obigen sha-Algorithmen liefern einen hash-Wert, der einzigartig für den jeweiligen Input ist!
>Es gab bisher weltweit _nie_ zwei gleiche Hashes für unterschiedlichen Input!

Bei MD5 war das ähnlich -- bis es halt nimmer wahr war, und Kollisionen in
Sekunden gefunden wurden. Das Zeigen *einer* solchen Kollision war ein Beweis,
aber: andersrum gilt nicht.

>Genau deshalb ist ein einziges korrektes Testergebnis ein /Beweis für eine korrekte Implementation/!

Also ist der triviale und offensichtlich falsche Algorithmus:

if <Testvektor> then return <test result>

bewiesenermaßen korrekt? ("reductio ad absurdum")

>Wenn ein Testverfahren angegeben ist, werden oft mehrere verschiedene Test-Inputs angegeben, um
>wirklich _jeden Zweifel_ auszuräumen.
>Ich habe stets alle diese Tests durchgeführt - mit übereinstimmendem Ergebnis.

Also ist der triviale und offensichtlich falsche Algorithmus:

if <Testvektor1> then return <test result1>
else if <Testvektor2> then return <test result2>
usw.
bewiesenermaßen korrekt?

>Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte Länge, innerhalb
>derer (sogar) die kryptographische Qualität gesichert ist.
>Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich --> deterministisch.
>Andernfalls könnte nicht verschlüsselt und entschlüsselt werden!
>Deshalb ist auch hier eine übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis
>für eine korrekte Implementation.

äh, nein, sorry.


Thomas Prufer

[Helmut Schellong]

On 03/28/2022 20:23, Thomas Prufer wrote:
> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <r...@schellong.biz> wrote:
>
>> Es ist _ganz generell_ richtig, was Du schreibst.
>> Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht.
>>
>> Diese hatte ich aufgelistet:
>> |Die Kern-Algorithmen sind nicht selbst entwickelt.
>> |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
>> |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
>> |Diese Algorithmen sind alle kryptographisch.
>>
>> In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>> ist auch meist eine Testprozedur durch die Entwickler angegeben.
>> Diese habe ich jeweils durchgeführt!
>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist!
>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert.
>> Korrekter und beweiskräftiger geht es nicht!
>
> Das wurde ignoriert weil es kein Beweis ist...

Beweis für was?
Diese Aussage wiederum beweist die Inkompetenz derer, die das ignorierten.
Warum?
Es geht um den Beweis einer korrekten Implementation!
Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung ergaben.
Es ist dann der Beweis erbracht, daß die vorgenommene Implementation
werte-mäßig identisch mit der Referenz-Implementation der Algorithmus-Entwickler ist.

"This is a set of test vectors for conformance testing,"

Hatte ich bereits gepostet.

"Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben.
Reicht das nicht?
Falls nicht - was reicht denn dann?

Wir befinden uns nun im Bereich der Haarspalterei, des Unsinns, des Irrsinns.

>> Desweiteren ist abhängig vom Algorithmus meist ein einziger Test tatsächlich beweiskräftig.
>
> Das ist ein Indiz für Korrektheit, vielleicht, aber kein Beweis.

"kein Beweis" für was?

Ein Hash-Algorithmus generiert einen Hash-Wert.
Dieser hat z.B. einen Wertebereich von 2^512 - also endlich.
Bei 2^512+1 verschiedenen Byte-Folgen als Input müssen also zwangsläufig
mindestens 2 gleiche Hash-Werte ausgegeben werden - gemäß Definition.

Komischerweise gab es jedoch über Jahrzehnte hinweg weltweit kein Doppel bisher!
Das liegt einfach daran, daß der Zahlenbereich 2^512 bisher nicht ausgeschöpft werden konnte.
Und daran, daß es bisher kein unprovoziertes Doppel gab.

Ein vorgekommenes Doppel wäre gleichbedeutend mit einem 'geknackten' Algorithmus.
Meist wird erst dann ein verbesserter Algorithmus entwickelt.
Allerdings wurde SHA3 entwickelt, obwohl an SHA2 noch keine Schwächen entdeckt worden sind.
An Rabbit wurden ebenfalls noch keine Schwächen entdeckt.

Ein absoluter Beweis ist im Kontext der Fund von zwei oder mehr gleichen Ausgabewerten.
Dabei sind Zeitpunkt, Umfang und Werte unbekannt und nicht kalkulierbar.

>> Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.
>> Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines jeden Algorithmus, diesen
>> zu 'knacken' oder Schwächen zu entdecken.
>> Alle obigen sha-Algorithmen liefern einen hash-Wert, der einzigartig für den jeweiligen Input ist!
>> Es gab bisher weltweit _nie_ zwei gleiche Hashes für unterschiedlichen Input!
>
> Bei MD5 war das ähnlich -- bis es halt nimmer wahr war, und Kollisionen in
> Sekunden gefunden wurden. Das Zeigen *einer* solchen Kollision war ein Beweis,
> aber: andersrum gilt nicht.

MD5 ist uralt, von 1991.
SHA2 hat bisher keine Doppel gezeigt.
SHA3 erst recht nicht.

RC4 (1987) ist schon lange korrumpiert, Nachfolger Spritz (2014) bisher nicht.

>> Genau deshalb ist ein einziges korrektes Testergebnis ein /Beweis für eine korrekte Implementation/!
>
> Also ist der triviale und offensichtlich falsche Algorithmus:
>
> if <Testvektor> then return <test result>
>
> bewiesenermaßen korrekt? ("reductio ad absurdum")

Ich schrieb oben:
|Es geht um den Beweis einer korrekten Implementation!
|Der ist gegeben, wenn die vorgeschriebenen Tests Übereinstimmung ergaben.
|Es ist dann der Beweis erbracht, daß die vorgenommene Implementation
|werte-mäßig identisch mit der Referenz-Implementation der Algorithmus-Entwickler ist.

Wenn die Entwickler sagen, daß die von ihnen ausgearbeiteten Tests
die Konformität mit ihrer Referenz beweisen, dann ist das so - und Punkt.
Man braucht darüber nicht weiter diskutieren.

>> Wenn ein Testverfahren angegeben ist, werden oft mehrere verschiedene Test-Inputs angegeben, um
>> wirklich _jeden Zweifel_ auszuräumen.
>> Ich habe stets alle diese Tests durchgeführt - mit übereinstimmendem Ergebnis.
>
> Also ist der triviale und offensichtlich falsche Algorithmus:
>
> if <Testvektor1> then return <test result1>
> else if <Testvektor2> then return <test result2>
> usw.
> bewiesenermaßen korrekt?

Irrelevant.
Andernfalls hätten die Entwickler diesen vorstehenden Algorithmus angegeben...

>> Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte Länge, innerhalb
>> derer (sogar) die kryptographische Qualität gesichert ist.
>> Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich --> deterministisch.
>> Andernfalls könnte nicht verschlüsselt und entschlüsselt werden!
>> Deshalb ist auch hier eine übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis
>> für eine korrekte Implementation.
>
> äh, nein, sorry.
>
>
>

Selbstverständlich wäre das ein Beweis für die Konformität einer Implementation.
Warum?
Die inhärente Sicherheit dieser Algorithmen ist viel geringer als die Wahrscheinlichkeit,
daß eine Ausgabe mit 256 Byte Länge (2048 Bit) rein zufällig Gleichheit aufweist.

[Josef Moellers]

On 28.03.22 22:29, Helmut Schellong wrote:
> On 03/28/2022 20:23, Thomas Prufer wrote:
>> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong
>> <r...@schellong.biz> wrote:
>>
>>> Es ist _ganz generell_ richtig, was Du schreibst.
>>> Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen,
>>> um die es hier geht.
>>>
>>> Diese hatte ich aufgelistet:
>>>     |Die Kern-Algorithmen sind nicht selbst entwickelt.
>>>     |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
>>>     |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
>>>     |Diese Algorithmen sind alle kryptographisch.
>>>
>>> In der Implementierungsvorschrift der jeweiligen Entwickler der
>>> Algorithmen
>>> ist auch meist eine Testprozedur durch die Entwickler angegeben.
>>> Diese habe ich jeweils durchgeführt!
>>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist!
>>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert.
>>> Korrekter und beweiskräftiger geht es nicht!
>>
>> Das wurde ignoriert weil es kein Beweis ist...
>
> Beweis für was?

"das Korrektheit beweist!"

Es ist allgemein bekannt, daß man mit einem Test NIEMALS die KORREKTHEIT
sondern nur die UNKORREKTHEIT beweisen kann, nämlich wenn der Test fehl
schlägt.
Du kannst so lange Testen, wie Du willst, Du kannst 100% Testabdeckung
erreichen, aber Du wirst dadurch niemals beweisen können, daß der Test
nicht bei der nächsten Iteration fehl schlägt.
Der *Beweis* der Korrektheit eines Algorithmus oder seiner
Implementation (im Folgenden "der Code") ist eine nicht-triviale, in der
Regel mathematische Tätigkeit.

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

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

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

> "This is a set of test vectors for conformance testing,"
> Hatte ich bereits gepostet.


> "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben.
> Reicht das nicht?
> Falls nicht - was reicht denn dann?

Ein mathematischer Beweis, daß der Code korrekt ist, also nicht der
Nchweis, daß der Code bei der Eingabe einer (endlichen) Menge von
Eingabeparametern die erwarteten Ergebnisse liefert, sondern daß der
Code bei der Eingeba *aller erlaubten* Eingabeparametern die erwarteten
Ergebnisse liefern wird.
Dazu empfehle ich "The Science of Programming" von David Gries. Ist
schon gut abgehangen, aber imho immer noch gut.

> Wir befinden uns nun im Bereich der Haarspalterei, des Unsinns, des
> Irrsinns.

Nein, wir befinden uns hier im Bereich der Hybris.

Es ist extrem gefährlich zu behaupten, ein Code sei "bewiesenermaßen
korrekt, weil er gewisse Tests erfolgreich durchlaufen hat",
insbesondere wenn es sich um sicherheitsrelevanten Code handelt.

Ich stelle mir gerade vor, wie das ist, wenn eine Brücke als
"bewiesenermaßen korrekt gebaut" ist und für den allgemeinen Verkehr
freigegeben wird, weil man nach dem Bau ein paar LKW darüber hat fahren
lassen.

Josef

[Thomas Prufer]

On Tue, 29 Mar 2022 09:39:36 +0200, Josef Moellers
<josef.m...@invalid.invalid> wrote:

(...)

Merci, dann kann ich mir das zu schreiben ja sparen...

>> Also ist der triviale und offensichtlich falsche Algorithmus:
>>
>> if <Testvektor1> then return <test result1>
>> else if <Testvektor2> then return <test result2>
>> usw.
>> bewiesenermaßen korrekt?
>
>Irrelevant.
>Andernfalls hätten die Entwickler diesen vorstehenden Algorithmus angegeben...

offenbart Lücken...


Thomas Prufer

[Volker Bartheld]

On Mon, 28 Mar 2022 20:23:42 +0200, Thomas Prufer wrote:
> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <r...@schellong.biz> wrote:

>> Es ist _ganz generell_ richtig, was Du schreibst. In der

>> Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>> ist auch meist eine Testprozedur durch die Entwickler angegeben.

Die natürlich Seitenkanalangriffe einschließt. Die Implementierung des
Dual_EC-DRBG mit falschen Startwerten absolviert natürlich ebenfalls
alle Tests erfolgreich. Und wenn ich mir https://cryptopp.com/ so
ansehe, dann fällt mir auf der Einstiegsseite gleich ein Typo "ECDSA,
Determinsitic ECDSA (RFC 6979)" auf, da werden sich die Buben im
--------^
Laufzeitverhalten ihrer Unittests garantiert keinen Bruch gehoben haben.
Und jetzt kommt irgendwer daher, der mal ein C-Buch geschrieben hat und
präsentiert mir einen neuartigen Zufallszahlengenerator, der als Quelle
nur die PID nebst time() verwendet.

>> Diese habe ich jeweils durchgeführt! Mit jeweils demjenigen Ergebnis,
>> das Korrektheit beweist! Hatte ich mehrfach gepostet - und wurde
>> jeweils ignoriert. Korrekter und beweiskräftiger geht es nicht!

double pow(double x, double y) { return 1; }
TEST(Math, TestPow) { EXPECT_DOUBLE_EQ(pow(1, 2), 1); }

Läuft!

> Das wurde ignoriert weil es kein Beweis ist...
>> Desweiteren ist abhängig vom Algorithmus meist ein einziger Test
>> tatsächlich beweiskräftig.
> Das ist ein Indiz für Korrektheit, vielleicht, aber kein Beweis.

Hinreichend vs. notwendig. Mittelstufenmathematik.

>> Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.

Aber vielleicht bald Deine schwache Implementierung.

>> Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines
>> jeden Algorithmus, diesen zu 'knacken' oder Schwächen zu entdecken.

Jup. Alle Supercomputer dieser Welt sind mit nichts anderem beschäftigt,
als Herrn Schellong nachzuweisen, was für Böcke er mit seiner
bish-Shell geschossen hat, die - zumindest in der Windows-Version noch
nicht einmal digital signiert ist. Klar.

>> Alle obigen sha-Algorithmen liefern einen hash-Wert, der einzigartig
>> für den jeweiligen Input ist! Es gab bisher weltweit _nie_ zwei
>> gleiche Hashes für unterschiedlichen Input!
> Bei MD5 war das ähnlich -- bis es halt nimmer wahr war, und
> Kollisionen in Sekunden gefunden wurden.

Tscha.

>> Genau deshalb ist ein einziges korrektes Testergebnis ein /Beweis für
>> eine korrekte Implementation/!
> Also ist der triviale und offensichtlich falsche Algorithmus:
> if <Testvektor> then return <test result>
> bewiesenermaßen korrekt? ("reductio ad absurdum")

Genau. Und zwar in Kursivschrift, mit Ausrufezeichen!

>> Wenn ein Testverfahren angegeben ist, werden oft mehrere verschiedene
>> Test-Inputs angegeben, um wirklich _jeden Zweifel_ auszuräumen. Ich
>> habe stets alle diese Tests durchgeführt - mit übereinstimmendem
>> Ergebnis.
> Also ist der triviale und offensichtlich falsche Algorithmus:
> if <Testvektor1> then return <test result1>
> else if <Testvektor2> then return <test result2>
> usw. bewiesenermaßen korrekt?

Genau. Und zwar in Kursivschrift, ohne Ausrufezeichen diesmal.

>> Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte
>> Länge, innerhalb derer (sogar) die kryptographische Qualität
>> gesichert ist.

Was ist denn die kryptografische Qualität?

>> Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich
>> --> deterministisch. Andernfalls könnte nicht verschlüsselt und
>> entschlüsselt werden!

Hmmmm. Vielleicht mal zum Thema "Padding" schlau machen und warum man
dafür gerne irgendwelche Zufallszahlen benutzt [1].

>> Deshalb ist auch hier eine
>> übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis für
>> eine korrekte Implementation.
> äh, nein, sorry.

Hachja. Was solls. Wieder eine halbe Stunde Zeit verschwendet.

Volker

[1] https://www.di-mgt.com.au/cryptopad.html

[Bernd Laengerich]

Am 28.03.2022 um 20:23 schrieb Thomas Prufer:

> Also ist der triviale und offensichtlich falsche Algorithmus:
>
> if <Testvektor> then return <test result>
>
> bewiesenermaßen korrekt? ("reductio ad absurdum")

Das wäre bei test driven development ein fast korrekter Zwischenschritt, der
aber alsbald einer besseren Implementierung weichen müsste...

> if <Testvektor1> then return <test result1>
> else if <Testvektor2> then return <test result2>
> usw.

...nämlich evtl. solcher. Aber auch das wäre nicht das Endstadium der
Entwicklung. Bei Kryptographie erst wenn Experten dauerhaft keine
Schwachstellen finden konnten.

Bernd

[Volker Bartheld]

On Tue, 29 Mar 2022 11:21:22 +0200, Bernd Laengerich wrote:
> Am 28.03.2022 um 20:23 schrieb Thomas Prufer:
>> Also ist der triviale und offensichtlich falsche Algorithmus:
>> if <Testvektor> then return <test result>
>> bewiesenermaßen korrekt? ("reductio ad absurdum")
> Das wäre bei test driven development ein fast korrekter Zwischenschritt, der
> aber alsbald einer besseren Implementierung weichen müsste...
>> if <Testvektor1> then return <test result1>
>> else if <Testvektor2> then return <test result2>
>> usw.
> ...nämlich evtl. solcher. Aber auch das wäre nicht das Endstadium der
> Entwicklung.

Deswegen hat man ja hoffentlich eine QA-Abteilung und trennt Entwicklung
von (Integrations-/End-to-End)Tests, die sich durchaus gut bezahlter
Experten...

> Bei Kryptographie erst wenn Experten dauerhaft keine
> Schwachstellen finden konnten.

... bedienen darf. Nennt man dann "Peer-Review" usw.

Sobald ein Code Closed Source ist und da aus "Geheimhaltungsgründen"
niemand - d. h. auch nicht unter Geheimhaltungsvereinbarung - drübersehen
darf, beginnt es schwer nach Fisch zu riechen. Das soll übrigens nicht
heißen, daß Open Source zwingend besser ist, denn unter den Freiwilligen
muß sich erstmal jemand finden, der die Zeit, Lust und Kompetenz auf/für
so eine Begutachtung hat.

Speziell bei kryptografischen Fragestellungen ist "Security by Obscurity"
eine Falle, in die von NIHS und dem Dunning-Kruger-Effekt Herausgeforderte
immer gerne tappen.

Da findet man dann in der Hall of Shame Perlen wie...

bool CheckLicense(const License& lic)
{
// [...]
if(lic.password="MyTopSecretPassword") return true;
// [...]
}

... oder:

std::string ComputeLicense(const std::string& SysId, int ExpireDays)
{
std::ostringstream o;
o << SysId << ExpireDays << "Magic";
MyMD5::MD5Hash md5(o.str());
return md5.str();
}

, vielleicht auch (in einer C++ Wrapper-DLL):

_declspec (dllexport) int __cdecl MyLicense::getExpireDays(char* feature)
{
int days = MyLicense::ExpireDays(feature, m_License);
switch(days)
{
-1: return -1;
eFOREVER: return INT_MAX;
default: return days;
}
}

. Was kann da schon groß schiefgehen?

Ich würde Helmuts Erzeugnisse schon aus dem Grund nicht benutzen, aus dem
man auch merkwürdige Anhänge in E-Mails Unbekannter nicht öffnet oder gar
ausführt bzw. einen gefundenen USB-Stick daheim in den Rechner dübelt. Und
wenn ich mir das Copyright auf http://www.schellong.de/lizenz.htm ansehe,
vermute ich im Quellcode bestimmt nichts als Bleeding-Edge-Technologie.

Volker

[Reinhardt Behm]

On Mon, 28 Mar 2022 22:29:01 +0200, Helmut Schellong wrote:


> "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben.
> Reicht das nicht?

Doch, ist ein hinreichender Beweis für deine Inkompetenz und
Selbstüberschätzung.


--
Reinhardt

[Reinhardt Behm]

On Tue, 29 Mar 2022 09:39:36 +0200, Josef Moellers wrote:


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

Es ist bestenfalls der Beweis, dass nicht genau ein Fehler im Code ist.
Mehr können als einer können trotzdem drin sein.


--
Reinhardt

[Volker Bartheld]

On Tue, 29 Mar 2022 11:21:22 +0200, Bernd Laengerich wrote:

> Am 28.03.2022 um 20:23 schrieb Thomas Prufer:
>> Also ist der triviale und offensichtlich falsche Algorithmus:
>> if <Testvektor> then return <test result>
>> bewiesenermaßen korrekt? ("reductio ad absurdum")
> Das wäre bei test driven development ein fast korrekter Zwischenschritt, der
> aber alsbald einer besseren Implementierung weichen müsste...
>> if <Testvektor1> then return <test result1>
>> else if <Testvektor2> then return <test result2>
>> usw.
> ...nämlich evtl. solcher. Aber auch das wäre nicht das Endstadium der
> Entwicklung.

Deswegen hat man ja hoffentlich eine QA-Abteilung und trennt Entwicklung
von (Integrations-/End-to-End)Tests, die sich durchaus gut bezahlter
Experten...

> Bei Kryptographie erst wenn Experten dauerhaft keine
> Schwachstellen finden konnten.

... bedienen dürfen. Nennt man dann "Peer-Review" usw.

Sobald ein Code closed Source ist und da aus "Geheimhaltungsgründen"

niemand - d. h. auch nicht unter Geheimhaltungsvereinbarung - drübersehen
darf, beginnt es schwer nach Fisch zu riechen. Das soll übrigens nicht

heißen, daß open Source zwingend besser ist, denn unter den Freiwilligen

muß sich erstmal jemand finden, der die Zeit, Lust und Kompetenz auf/für
so eine Begutachtung hat.

Speziell bei kryptografischen Fragestellungen ist "Security by Obscurity"
eine Falle, in die von NIHS und dem Dunning-Kruger-Effekt Herausgeforderte
immer gerne tappen.

Da findet man dann in der Hall of Shame Perlen wie...

bool CheckLicense(const License& lic)
{
// [...]

if(lic.password=="MyTopSecretPassword") return true;

[Helmut Schellong]

On 03/29/2022 09:39, Josef Moellers wrote:
>
> On 28.03.22 22:29, Helmut Schellong wrote:
>> On 03/28/2022 20:23, Thomas Prufer wrote:
>>> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <r...@schellong.biz> wrote:
>>>
>>>> Es ist _ganz generell_ richtig, was Du schreibst.
>>>> Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht.
>>>>
>>>> Diese hatte ich aufgelistet:
>>>>     |Die Kern-Algorithmen sind nicht selbst entwickelt.
>>>>     |Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
>>>>     |sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
>>>>     |Diese Algorithmen sind alle kryptographisch.
>>>>
>>>> In der Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>>>> ist auch meist eine Testprozedur durch die Entwickler angegeben.
>>>> Diese habe ich jeweils durchgeführt!
>>>> Mit jeweils demjenigen Ergebnis, das Korrektheit beweist!
>>>> Hatte ich mehrfach gepostet - und wurde jeweils ignoriert.
>>>> Korrekter und beweiskräftiger geht es nicht!
>>>
>>> Das wurde ignoriert weil es kein Beweis ist...
>>
>> Beweis für was?
>
> "das Korrektheit beweist!"
>
> Es ist allgemein bekannt, daß man mit einem Test NIEMALS die KORREKTHEIT sondern nur die UNKORREKTHEIT beweisen kann, nämlich wenn der Test fehl schlägt.
> Du kannst so lange Testen, wie Du willst, Du kannst 100% Testabdeckung erreichen, aber Du wirst dadurch niemals beweisen können, daß der Test nicht bei der nächsten Iteration fehl schlägt.
> Der *Beweis* der Korrektheit eines Algorithmus oder seiner Implementation (im Folgenden "der Code") ist eine nicht-triviale, in der Regel mathematische Tätigkeit.

Es gibt tatsächlich Tests, die eine Korrektheit nicht beweisen können.
Das gilt jedoch nicht für kryptographische Algorithmen, die hier aufgelistet sind.

>> 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?
'conformance' heißt 'Übereinstimmung'.
Wenn Test-Vektoren Übereinstimmung erzielen, ist eine Implementation korrekt.
Deren Korrektheit ist durch eine Übereinstimmung _bewiesen_.
Das sagen die Entwickler aus!
Und Punkt.

>> 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.
Die Entwickler kennen ihre Entwicklung in dieser Hinsicht ganz genau.
Schließlich sind die Algorithmen deterministisch.

|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.
|The correctness of the code on different platforms is verified by generating and comparing test vectors.

>> 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.
Ich habe meine nämlich mehrfach bewiesen, anhand der Entwickler-Testprozeduren.

>> "This is a set of test vectors for conformance testing,"
>> Hatte ich bereits gepostet.
>
>
>> "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben.
>> Reicht das nicht?
>> Falls nicht - was reicht denn dann?
>
> Ein mathematischer Beweis, daß der Code korrekt ist, also nicht der Nchweis, daß der Code bei der Eingabe einer (endlichen) Menge von Eingabeparametern die erwarteten Ergebnisse liefert, sondern daß der Code bei der Eingeba *aller erlaubten* Eingabeparametern die erwarteten Ergebnisse liefern wird.
> Dazu empfehle ich "The Science of Programming" von David Gries. Ist schon gut abgehangen, aber imho immer noch gut.

Ich beherrsche etwa 20 Programmiersprachen mehr oder weniger gut - ein weiteres Buch brauche ich nicht.
Ich habe u.a. die Bücher von Knuth.

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

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

> Es ist extrem gefährlich zu behaupten, ein Code sei "bewiesenermaßen korrekt, weil er gewisse Tests erfolgreich durchlaufen hat", insbesondere wenn es sich um sicherheitsrelevanten Code handelt.

Alle genannten Algorithmen wurden und werden weltweit millionenfach korrekt implementiert
und konkret hunderte-millionenfach in sicherheitsfordernder Umgebung verwendet.

MD5 und RC4 werden trotz Korrumpierung vor vielen Jahren weiterhin verwendet.

> Ich stelle mir gerade vor, wie das ist, wenn eine Brücke als "bewiesenermaßen korrekt gebaut" ist und für den allgemeinen Verkehr freigegeben wird, weil man nach dem Bau ein paar LKW darüber hat fahren lassen.
>
>

So wird das seit vielleicht 150 Jahren weltweit getan.
Dies funktioniert auch, wenn nicht Jahrzehnte lang Warnungen von Experten ignoriert werden.
Extrem selten haben Brücken überraschend versagt (Windresonanz).

|Ein Prüfbericht stellt klar: Am Unglück in Genua (2018) war nicht das Wetter schuld.
|An einem entscheidenden Träger wurde seit 1993 keine Wartung vorgenommen (Bau 1967).
|Selbst Warnungen des Bauplaners waren ignoriert worden (~1985).
|Der Bericht von vier Universitätsprofessoren, die von der Untersuchungsrichterin Angela Nutini
|mit der Prüfung der Einsturzursachen beauftragt wurden, lese sich "wie ein Urteil",

Es ist sogar verwunderlich, daß es _erst_ 2018 zum Unglück kam.


Du willst die Kenntnisse der Entwickler und Gepflogenheiten im Bereich
der kryptographischen Cipher offensichtlich nicht anerkennen.

[Helmut Schellong]

On 03/29/2022 09:57, Volker Bartheld wrote:
> On Mon, 28 Mar 2022 20:23:42 +0200, Thomas Prufer wrote:
>> On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <r...@schellong.biz> wrote:
>>> Es ist _ganz generell_ richtig, was Du schreibst. In der
>>> Implementierungsvorschrift der jeweiligen Entwickler der Algorithmen
>>> ist auch meist eine Testprozedur durch die Entwickler angegeben.

Ich schrieb:

|Es ist _ganz generell_ richtig, was Du schreibst.

|Du ignorierst jedoch die konkrete Praxis mit genau den Algorithmen, um die es hier geht.
|Diese hatte ich aufgelistet:

> Die natürlich Seitenkanalangriffe einschließt. Die Implementierung des
> Dual_EC-DRBG mit falschen Startwerten absolviert natürlich ebenfalls
> alle Tests erfolgreich. Und wenn ich mir https://cryptopp.com/ so
> ansehe, dann fällt mir auf der Einstiegsseite gleich ein Typo "ECDSA,
> Determinsitic ECDSA (RFC 6979)" auf, da werden sich die Buben im
> --------^
> Laufzeitverhalten ihrer Unittests garantiert keinen Bruch gehoben haben.

Dieser Algorithmus ist doch seit vielen Jahren korrumpiert; hat mich nie interessiert.

Außerdem geht um eine korrekte Implementation gemäß einer Referenz-Implementation.

Desweiteren habe ich zu beinahe allen Algorithmen mehrere Quellen.
Beispielsweise RFC + PDF1 + PDF2.
Bei diesen Algorithmen habe ich daher garantiert keine falschen Konstanten implementiert.
Das wäre auch wegen der weltweiten Verbreitung längst aufgefallen.

Falsche Konstanten würden bei meinen Algorithmen zu abweichenden Ausgaben führen.
Aufgrund der Verwendung der Konstanten im Code.

Ein Tipp-Fehler im Plain-Text ist kein Nachweis für schlampige Arbeit im Pseudo-Code.

Deine Begründungen sind folglich irrelevant.

> Und jetzt kommt irgendwer daher, der mal ein C-Buch geschrieben hat und
> präsentiert mir einen neuartigen Zufallszahlengenerator, der als Quelle
> nur die PID nebst time() verwendet.

Alles falsch.
Ich habe drei Editionen eines C-Buches geschrieben.
Ich beherrsche etwa 20 Programmiersprachen mehr oder weniger gut.
Es ist kein neuartiger Zufallszahlengenerator - ich habe ihn aus dem Netz.

03/24/2022 14:44
-----------------------------------------------------------------
[C-Code]
Der seed ist nicht durch ein Argument beeinflußbar.
Er basiert auf den Eingaben:
Prozeß-ID zufällig, unique
Zeit dauerhaft aufsteigend, in Sekunden
Array[Zeit] ungerade Zahlen <128 'wv[]'
Stack-Speicherinhalt buf[256], nicht vorhersagbar
-----------------------------------------------------------------

Wie kommt es, daß nun zum zweiten Mal behauptet wird, ich hätte
nur PID und time() als Eingabe verwendet?

http://www.schellong.de/htm/rand.htm#Seed
Im vorstehenden Code sind neben [C-Code] auch diese 4 Eingabequellen
angegeben und im Text beschrieben.
Auch den Link habe ich nicht zum ersten Mal angegeben.

>>> Diese habe ich jeweils durchgeführt! Mit jeweils demjenigen Ergebnis,
>>> das Korrektheit beweist! Hatte ich mehrfach gepostet - und wurde
>>> jeweils ignoriert. Korrekter und beweiskräftiger geht es nicht!
>
> double pow(double x, double y) { return 1; }
> TEST(Math, TestPow) { EXPECT_DOUBLE_EQ(pow(1, 2), 1); }
>
> Läuft!

Irrelevant - und Quatsch.

>> Das wurde ignoriert weil es kein Beweis ist...
>>> Desweiteren ist abhängig vom Algorithmus meist ein einziger Test
>>> tatsächlich beweiskräftig.
>> Das ist ein Indiz für Korrektheit, vielleicht, aber kein Beweis.
>
> Hinreichend vs. notwendig. Mittelstufenmathematik.

Irrelevant + Quatsch.
Es geht hier um die von den Entwicklern angegebenen beweiskräftigen Test-Prozeduren.

>>> Keiner der oben gelisteten Algorithmen wurde bisher 'geknackt'.
>
> Aber vielleicht bald Deine schwache Implementierung.

Wieso ist meine Implementierung schwach?
Die habe ich doch gar nicht gepostet!
Bist Du nun dem Schwachsinn verfallen?

>>> Supercomputer auf der ganzen Welt versuchen seit Erscheinen eines
>>> jeden Algorithmus, diesen zu 'knacken' oder Schwächen zu entdecken.
>
> Jup. Alle Supercomputer dieser Welt sind mit nichts anderem beschäftigt,
> als Herrn Schellong nachzuweisen, was für Böcke er mit seiner
> bish-Shell geschossen hat, die - zumindest in der Windows-Version noch
> nicht einmal digital signiert ist. Klar.

Das ist dummer, falscher und irrelevanter Quatsch, den Du da geschrieben hast.

>>> Alle obigen sha-Algorithmen liefern einen hash-Wert, der einzigartig
>>> für den jeweiligen Input ist! Es gab bisher weltweit _nie_ zwei
>>> gleiche Hashes für unterschiedlichen Input!
>> Bei MD5 war das ähnlich -- bis es halt nimmer wahr war, und
>> Kollisionen in Sekunden gefunden wurden.
>
> Tscha.

Schwachsinnige und irrelevante Bemerkung.

Alle obigen sha-Algorithmen liefern einen hash-Wert, der einzigartig
für den jeweiligen Input ist! Es gab bisher weltweit _nie_ zwei
gleiche Hashes für unterschiedlichen Input!

Was mit MD5 passierte, ist irrelevant - weil anderer und älterer Algorithmus.

>>> Genau deshalb ist ein einziges korrektes Testergebnis ein /Beweis für
>>> eine korrekte Implementation/!
>> Also ist der triviale und offensichtlich falsche Algorithmus:
>> if <Testvektor> then return <test result>
>> bewiesenermaßen korrekt? ("reductio ad absurdum")
>
> Genau. Und zwar in Kursivschrift, mit Ausrufezeichen!

Erneut irrelevanter Schwachsinn.

>>> Wenn ein Testverfahren angegeben ist, werden oft mehrere verschiedene
>>> Test-Inputs angegeben, um wirklich _jeden Zweifel_ auszuräumen. Ich
>>> habe stets alle diese Tests durchgeführt - mit übereinstimmendem
>>> Ergebnis.
>> Also ist der triviale und offensichtlich falsche Algorithmus:
>> if <Testvektor1> then return <test result1>
>> else if <Testvektor2> then return <test result2>
>> usw. bewiesenermaßen korrekt?
>
> Genau. Und zwar in Kursivschrift, ohne Ausrufezeichen diesmal.

Erneut irrelevanter Schwachsinn.

>>> Alle obigen Algorithmen liefern eine Sequenz mit mindestens 2^64 Byte
>>> Länge, innerhalb derer (sogar) die kryptographische Qualität
>>> gesichert ist.
>
> Was ist denn die kryptografische Qualität?

Das will ich hier nicht beantworten, weil viel zu aufwendig
angesichts des Schwachsinns, der hier verbreitet wird.

>>> Bei gleichem Input ist auch diese lange Sequenz jedesmal genau gleich
>>> --> deterministisch. Andernfalls könnte nicht verschlüsselt und
>>> entschlüsselt werden!
>
> Hmmmm. Vielleicht mal zum Thema "Padding" schlau machen und warum man
> dafür gerne irgendwelche Zufallszahlen benutzt [1].

Irrelevanter Quatsch.

>>> Deshalb ist auch hier eine
>>> übereinstimmende Testausgabe von z.B. 256 Byte Länge ein Beweis für
>>> eine korrekte Implementation.
>> äh, nein, sorry.
>
> Hachja. Was solls. Wieder eine halbe Stunde Zeit verschwendet.
>
>

Die Entwickler haben das in ihren Dokumentationen geschrieben (von mir gepostet).
So ist das eben - Widerspruch ist da schlicht albern.

[Helmut Schellong]

Schwachsinniger Kommentar.

Wie geht es denn korrekter und beweiskräftiger?
Das weiß nämlich niemand von Euch blinden Hetzern.

[Helmut Schellong]

Das ist falsch - u.a. weil die Entwickler der Algorithmen etwas Gegenteiliges schreiben.

Diese ganze blinde Hetzerei und wildes Invert-Behaupten kennzeichnet diese NG als Ort
der Unerquicklichkeiten und Unwahrheiten.

[Reinhardt Behm]

On Tue, 29 Mar 2022 16:39:22 +0200, Helmut Schellong wrote:

> On 03/29/2022 14:35, Reinhardt Behm wrote:
>> On Tue, 29 Mar 2022 09:39:36 +0200, Josef Moellers wrote:
>>
>>
>>>> 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.
>>
>>
>> Es ist bestenfalls der Beweis, dass nicht genau ein Fehler im Code ist.
>> Mehr können als einer können trotzdem drin sein.
>>
>>
>>
> Das ist falsch - u.a. weil die Entwickler der Algorithmen etwas
> Gegenteiliges schreiben.
>
> Diese ganze blinde Hetzerei und wildes Invert-Behaupten kennzeichnet
> diese NG als Ort der Unerquicklichkeiten und Unwahrheiten.

Unerquicklich für dich, weil wir nicht in Bewunderung für den größten
Programmierer alöler Zeiten erstarren.
Dein Pech, dass es hier Leute gibt, die dir halt haushoch überlegen ind
und dein Geprotze durchschauen. Versuchs doch irgendwo im Kindergarten.



--
Reinhardt

[Reinhardt Behm]

On Tue, 29 Mar 2022 16:34:06 +0200, Helmut Schellong wrote:

> On 03/29/2022 14:32, Reinhardt Behm wrote:
>> On Mon, 28 Mar 2022 22:29:01 +0200, Helmut Schellong wrote:
>>
>>
>>> "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben.
>>> Reicht das nicht?
>>
>> Doch, ist ein hinreichender Beweis für deine Inkompetenz und
>> Selbstüberschätzung.
>>
>>
>>
> Schwachsinniger Kommentar.
>
> Wie geht es denn korrekter und beweiskräftiger? Das weiß nämlich niemand
> von Euch blinden Hetzern.

Im vor dir zitierten Text der Entwickler steht, dass die Testvektoren zur
_Verifikation_ des Codes dienen. Du kennst noch nicht mal den Unterschied
zwischen Verifikation und Korrektheitsbeweis. Zum Glück schreibst du
keine sicherheitskritische Software. In solchen Bereichen würde man dich
zum Teufel jagen.



--
Reinhardt

[Helmut Schellong]

Es sind nicht meine Erzeugnisse!
Ganz zu Anfang und später schrieb ich, daß ich diese Algorithmen nicht selbst entwickelt habe.
Keinen davon.
Jetzt schreibe ich das erneut.
Was ist so schwer daran zu verstehen?

Und so etwas wie die vorstehenden Code-Beispiele würde ich niemals übernehmen!

> man auch merkwürdige Anhänge in E-Mails Unbekannter nicht öffnet oder gar
> ausführt bzw. einen gefundenen USB-Stick daheim in den Rechner dübelt. Und
> wenn ich mir das Copyright auf http://www.schellong.de/lizenz.htm ansehe,
> vermute ich im Quellcode bestimmt nichts als Bleeding-Edge-Technologie.
>
>

Man kann von der lizenz.htm nicht auf die Qualität des Quellcodes schließen.
Das ist massiv unprofessionell - Einfach horrender Quatsch!

Viel wichtiger sind http://www.schellong.de/txt/version.txt http://www.schellong.de/htm/bishmnk.htm

[Helmut Schellong]

On 03/29/2022 16:49, Reinhardt Behm wrote:
> On Tue, 29 Mar 2022 16:39:22 +0200, Helmut Schellong wrote:
>
>> On 03/29/2022 14:35, Reinhardt Behm wrote:
>>> On Tue, 29 Mar 2022 09:39:36 +0200, Josef Moellers wrote:
>>>
>>>
>>>>> 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.
>>>
>>>
>>> Es ist bestenfalls der Beweis, dass nicht genau ein Fehler im Code ist.
>>> Mehr können als einer können trotzdem drin sein.
>>>
>>>
>>>
>> Das ist falsch - u.a. weil die Entwickler der Algorithmen etwas
>> Gegenteiliges schreiben.
>>
>> Diese ganze blinde Hetzerei und wildes Invert-Behaupten kennzeichnet
>> diese NG als Ort der Unerquicklichkeiten und Unwahrheiten.
>
> Unerquicklich für dich, weil wir nicht in Bewunderung für den größten
> Programmierer alöler Zeiten erstarren.

Das ist massiv unlogisch!
Denn ich schrieb mehrmals, daß ich keinen der Algorithmen selbst entwickelt habe.
Wie kann ich denn da Bewunderung erwarten?! Wofür denn?

Du hast folglich erneut eine wilde Behauptung aufgestellt.
Schrieb ich doch vor Deiner vorstehenden Antwort.

> Dein Pech, dass es hier Leute gibt, die dir halt haushoch überlegen ind
> und dein Geprotze durchschauen. Versuchs doch irgendwo im Kindergarten.
>
>

Welches Geprotze?
Was ist an meinen Inhalten im Kontext Geprotze?
Ich habe lediglich von anderen Entwicklern entwickelte Algorithmen hier aufgelistet.
Mehr ist da nicht!
Also schon wieder eine wilde Behauptung.
Eine falsche Behauptung nach der anderen.

03/23/2022 21:39
===================================================================

Die Kern-Algorithmen sind nicht selbst entwickelt.
Ich habe u.a. die Algorithmen Rabbit, Spritz, sha2_256, sha2_512,
sha3_256, sha3_512 (Keccak) in meine Shell bish implementiert.
Diese Algorithmen sind alle kryptographisch.

===================================================================

Geprotze?

[Helmut Schellong]

Falsch.
Du stellst zum x-ten Mal falsche Behauptungen auf.
Etwas Korrektes zur Abwechslung scheint Dich nicht zu befriedigen.
Ich habe in der Industrie 15 Jahre lang sicherheitskritische Software entwickelt.
Beispielsweise für ukrainische und russische Atomkraftwerke.
Man hat mir beste Arbeitszeugnisse ausgestellt.

|This is a set of test vectors for conformance testing,

|The correctness of the code on different platforms is verified by generating and comparing test vectors.

Auch Englisch kannst Du offenbar nicht richtig.
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.

Was hat Scholz kürzlich (sinngemäß) gesagt?:
"Laß es einfach sein!"

[Hanno Foest]

Am 29.03.22 um 17:33 schrieb Helmut Schellong:

> Ich habe in der Industrie 15 Jahre lang sicherheitskritische Software
> entwickelt.
> Beispielsweise für ukrainische und russische Atomkraftwerke.

Tschernobyl...

> Man hat mir beste Arbeitszeugnisse ausgestellt.

Insbesondere die Realität.

> |This is a set of test vectors for conformance testing,
> |The correctness of the code on different platforms is verified by
> generating and comparing test vectors.
>
> Auch Englisch kannst Du offenbar nicht richtig.
> 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.

Das ist scheissegal was da steht, du kannst zB. nicht zeigen, daß es bei
deiner Implementierung keine Seitenkanäle gibt, da evtl. noch nicht mal
bekannt ist, welche das in Zukunft sein könnten.

Hanno

--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

[Volker Bartheld]

On Tue, 29 Mar 2022 14:49:19 -0000 (UTC), Reinhardt Behm wrote:
> On Tue, 29 Mar 2022 16:39:22 +0200, Helmut Schellong wrote:
>> Diese ganze blinde Hetzerei und wildes Invert-Behaupten kennzeichnet
>> diese NG als Ort der Unerquicklichkeiten und Unwahrheiten.

Herr Schellong möge bitte einfach weggehen, so er es nicht vertragen
kann, daß ihm Menschen wegen seiner unerträglich peinlichen und
penetrant vorgetragenen methodischen Schwächen, Irrationalität,
Ignoranz, Selbstüberschätzung, Überheblichkeit und Erkenntnisresistenz
den Spiegel vorhalten. Dieser Ort der Unerquicklichkeiten und
Unwahrheiten wäre ein Besserer.

> Unerquicklich für dich, weil wir nicht in Bewunderung für den größten

> Programmierer aller Zeiten erstarren. Dein Pech, dass es hier Leute
> gibt, die dir halt haushoch überlegen und dein Geprotze durchschauen.

> Versuchs doch irgendwo im Kindergarten.

Da wird er wohl auch intellektuelle Eigentore schießen. Zwecklos. Solche
Gestalten gibts wohl in jedem unmoderierten Forum. Ich hoffe, die
Angelegenheit möge sich auf ganz biologische Weise lösen. Bis dahin
hilft das Killfile.

Volker

[Volker Bartheld]

On Tue, 29 Mar 2022 11:21:22 +0200, Bernd Laengerich wrote:

> Am 28.03.2022 um 20:23 schrieb Thomas Prufer:
>> Also ist der triviale und offensichtlich falsche Algorithmus:
>> if <Testvektor> then return <test result>
>> bewiesenermaßen korrekt? ("reductio ad absurdum")
> Das wäre bei test driven development ein fast korrekter Zwischenschritt, der
> aber alsbald einer besseren Implementierung weichen müsste...
>> if <Testvektor1> then return <test result1>
>> else if <Testvektor2> then return <test result2>
>> usw.
> ...nämlich evtl. solcher. Aber auch das wäre nicht das Endstadium der
> Entwicklung.

Deswegen hat man ja hoffentlich eine QA-Abteilung und trennt Entwicklung
von (Integrations-/End-to-End)Tests, die sich durchaus gut bezahlter
Experten...

> Bei Kryptographie erst wenn Experten dauerhaft keine
> Schwachstellen finden konnten.

case -1: return -1;
case eFOREVER: return INT_MAX;

default: return days;
}
}

. Was kann da schon groß schiefgehen?

Ich würde Helmuts Erzeugnisse schon aus dem Grund nicht benutzen, aus

dem man auch merkwürdige Anhänge in E-Mails Unbekannter nicht öffnet

oder gar ausführt bzw. einen gefundenen USB-Stick daheim in den Rechner
dübelt. Und wenn ich mir das Copyright auf
http://www.schellong.de/lizenz.htm ansehe, vermute ich im Quellcode
bestimmt nichts als Bleeding-Edge-Technologie.

Volker

[Helmut Schellong]

On 03/29/2022 17:58, Hanno Foest wrote:
> Am 29.03.22 um 17:33 schrieb Helmut Schellong:
>
>> Ich habe in der Industrie 15 Jahre lang sicherheitskritische Software entwickelt.
>> Beispielsweise für ukrainische und russische Atomkraftwerke.
>
> Tschernobyl...

Quatsch, das Unglück war 1986, ich war in der betreffenden Firma ab 2000.
Die Software wurde ab etwa 2003 entwickelt, mit kyrillischen Displays.

>> Man hat mir beste Arbeitszeugnisse ausgestellt.
>
> Insbesondere die Realität.

Von 1968 bis 1979.
Von 1984 bis 2016.

>> |This is a set of test vectors for conformance testing,
>> |The correctness of the code on different platforms is verified by generating and comparing test vectors.
>>
>> Auch Englisch kannst Du offenbar nicht richtig.
>> 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.
>
> Das ist scheissegal was da steht,

Nein, es ist gar nicht egal, was da steht.
Jemand Anderer hat nämlich darüber gelogen oder war nicht in der Lage, richtig zu verstehen.

du kannst zB. nicht zeigen, daß es bei deiner Implementierung keine Seitenkanäle gibt,
da evtl. noch nicht mal bekannt ist, welche das in Zukunft sein könnten.
>
>

Ich habe bereits gepostet, daß ich alle diese Algorithmen
nur von und zu lokaler Festplatte benutze.
Die dämlichen Seitenkanäle können folglich keinen Effekt haben.

Die dämlichen Seitenkanäle können wohl auch grundlegend im Zusammenhang
mit diesen Algorithmen keinen Effekt haben.
Das ist eine ins Leere laufende Behauptung.

[Helmut Schellong]

On 03/29/2022 18:11, Volker Bartheld wrote:
> On Tue, 29 Mar 2022 14:49:19 -0000 (UTC), Reinhardt Behm wrote:
>> On Tue, 29 Mar 2022 16:39:22 +0200, Helmut Schellong wrote:
>>> Diese ganze blinde Hetzerei und wildes Invert-Behaupten kennzeichnet
>>> diese NG als Ort der Unerquicklichkeiten und Unwahrheiten.
>
> Herr Schellong möge bitte einfach weggehen, so er es nicht vertragen
> kann, daß ihm Menschen wegen seiner unerträglich peinlichen und
> penetrant vorgetragenen methodischen Schwächen, Irrationalität,
> Ignoranz, Selbstüberschätzung, Überheblichkeit und Erkenntnisresistenz
> den Spiegel vorhalten. Dieser Ort der Unerquicklichkeiten und
> Unwahrheiten wäre ein Besserer.

Kommt nicht in Frage.

>> Unerquicklich für dich, weil wir nicht in Bewunderung für den größten
>> Programmierer aller Zeiten erstarren. Dein Pech, dass es hier Leute
>> gibt, die dir halt haushoch überlegen und dein Geprotze durchschauen.
>> Versuchs doch irgendwo im Kindergarten.
>
> Da wird er wohl auch intellektuelle Eigentore schießen. Zwecklos. Solche
> Gestalten gibts wohl in jedem unmoderierten Forum. Ich hoffe, die
> Angelegenheit möge sich auf ganz biologische Weise lösen. Bis dahin
> hilft das Killfile.
>
>

Falsch gedacht.
Irgendwann wird mein Klon weitermachen.
Es müssen doch schließlich Reaktionen auf die Falschaussagen hier erfolgen.

Und im Kindergarten wird man mich nicht nehmen.

[Josef Moellers]

Nein. Es gibt keinen Test, der die Korrektheit eines Codes (d.h.
Algorithmus UND Implementation) *beweisen* kann!
Das ist allgemein bekannt und ich möchte mal behaupten, dessen sind sich
die Entwickler des Codes auch bewußt.

>
>>> 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:
https://www.techtarget.com/searchsoftwarequality/definition/conformance-testing
Da steht nix von "correctness" sondern nur "meets a defined set of
standards".
Auch der Wikipedia-Artikel
https://en.wikipedia.org/wiki/Conformance_testing sprint nicht von
"correctness" sondern nur von "performs according to its specified
standards.".

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.

> 'conformance' heißt 'Übereinstimmung'.
> Wenn Test-Vektoren Übereinstimmung erzielen, ist eine Implementation
> korrekt.

Übereinstimmung womit?

> Deren Korrektheit ist durch eine Übereinstimmung _bewiesen_.
> Das sagen die Entwickler aus!
> Und Punkt.

Tja, dann glaube das bitte weiter.

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

> Die Entwickler kennen ihre Entwicklung in dieser Hinsicht ganz genau.
> Schließlich sind die Algorithmen deterministisch.

*Jeder* auf einem Computer implementierter Algorithmus ist
deterministisch. 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.

> |We, the designers of Rabbit, hereby state that no hidden weaknesses have
> |been inserted by us in the Rabbit algorithm.

Das beruhigt ungemein.

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

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

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

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.

>>> "This is a set of test vectors for conformance testing,"
>>> Hatte ich bereits gepostet.
>>
>>
>>> "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben.
>>> Reicht das nicht?
>>> Falls nicht - was reicht denn dann?
>>
>> Ein mathematischer Beweis, daß der Code korrekt ist, also nicht der
>> Nchweis, daß der Code bei der Eingabe einer (endlichen) Menge von
>> Eingabeparametern die erwarteten Ergebnisse liefert, sondern daß der
>> Code bei der Eingeba *aller erlaubten* Eingabeparametern die
>> erwarteten Ergebnisse liefern wird.
>> Dazu empfehle ich "The Science of Programming" von David Gries. Ist
>> schon gut abgehangen, aber imho immer noch gut.
>
> Ich beherrsche etwa 20 Programmiersprachen mehr oder weniger gut - ein
> weiteres Buch brauche ich nicht.

Ja, dann erübrigt sich ja die Debatte mit Dir, oh Du weiser Mann.

Zwanzig Programmiersprachen ... wow! Ich erstarre in Ehrfurcht.

Ich habe 1981 angefangen zu arbeiten (damals bei der Nixdorf Computer
AG) und die Computerei ist mein Hobby. Wie viele Programmiersprachen ich
kenne ... ich habe sie nie gezählt.
Das ist ja auch völlig irrelevant! Und wenn Du 100 Programmiersprachen
könntest, so hast Du immer noch nicht begriffen, was ich sagen will: Daß
man mit Testen nie und nimmer die Korrektheit eines Codes beweisen kann.

Siehe hierzu auch
https://de.wikipedia.org/wiki/Korrektheit_(Informatik)

Oder die Folien hier:
https://pi4.informatik.uni-mannheim.de/pi4.data/content/courses/2005-ws/pi1/slides/pi1-5b-2006-02-02.pdf
"Testen nur das Vertrauen in die Korrektheit eines Programms erhöhen,
nicht aber die Korrektheit beweisen."

Oder die Folien hier:
https://www.mathematik.uni-marburg.de/~gumm/Lehre/WS07/PraktischeInformatikI/Folien/14_Korrektheit.pdf
"Durch Testen kann man nur Anwesenheit von
Fehlern feststellen, nicht aber ihre
Abwesenheit (E. Dijkstra)"

Dijstra's Essay "On the reliability of programs" kannst Du übrigens hier
nachlesen:
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html

Ich zitiere mal (sinngemäß) einen Herrn Schellong: "Willst Du dem
widersprechen?"

Dijstra's These wird übrigens hier diskutiert:
https://blog.liw.fi/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing/
Und auch dort steht "Tests don’t tell you that code works in cases that
aren’t tested. Tests tell you code works in the cases that are tested.
If you want it to work in some other case, you add a test, or expand an
existing test to cover the case you’re interested in."

> Ich habe u.a. die Bücher von Knuth.

Ja, die sind gut.
Was sagt Knuth denn zum Testen?
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.

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

>> Es ist extrem gefährlich zu behaupten, ein Code sei "bewiesenermaßen
>> korrekt, weil er gewisse Tests erfolgreich durchlaufen hat",
>> insbesondere wenn es sich um sicherheitsrelevanten Code handelt.
>
> Alle genannten Algorithmen wurden und werden weltweit millionenfach
> korrekt implementiert
> und konkret hunderte-millionenfach in sicherheitsfordernder Umgebung
> verwendet.

Ich sage ja nicht, daß sie fehlerhaft SIND, ich behaupte nur, daß man
durch Testen niemals eine Korrektheit BEWEISen kann.
Das ist in der Informatik allgemein bekannt und akzeptiert.
Daß man trotzdem testet hat sicherlich damit zu tun, daß der
mathematisch-logische KorrektheitsBEWEIS eines nicht-trivialen Stücks
Code selber in besonderem Maße nicht-trivial ist und keiner sich die
Arbeit machen will. Ich habe mkich während meine Studiums mit "weakest
precondition"s und "postcondition"s 'rumschlagen dürfen. Es hat KEINEN
Spaß gemacht ...

> MD5 und RC4 werden trotz Korrumpierung vor vielen Jahren weiterhin
> verwendet.

Wie gesagt: Ich behaupt nicht, daß sie fehlerhaft SIND.

>> Ich stelle mir gerade vor, wie das ist, wenn eine Brücke als
>> "bewiesenermaßen korrekt gebaut" ist und für den allgemeinen Verkehr
>> freigegeben wird, weil man nach dem Bau ein paar LKW darüber hat
>> fahren lassen.
>>
>>
>
> So wird das seit vielleicht 150 Jahren weltweit getan.

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.

[...]

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

Josef

[Hanno Foest]

On 29.03.22 19:04, Helmut Schellong wrote:

>> Das ist scheissegal was da steht,
>
> Nein, es ist gar nicht egal, was da steht.

Doch, da du eh nicht fähig bist, es richtig zu verstehen.

>  du kannst zB. nicht zeigen, daß es bei deiner Implementierung keine
> Seitenkanäle gibt,
>  da evtl. noch nicht mal bekannt ist, welche das in Zukunft sein könnten.
>>
> Ich habe bereits gepostet, daß ich alle diese Algorithmen
> nur von und zu lokaler Festplatte benutze.

Ok, wenn praktisch niemand irgendwo deinen binären Sondermüll benutzt,
ist dessen Schadensreichweite natürlich begrenzt.

[Bernd Laengerich]

Am 29.03.2022 um 18:13 schrieb Volker Bartheld:

>> Bei Kryptographie erst wenn Experten dauerhaft keine
>> Schwachstellen finden konnten.
>
> ... bedienen dürfen. Nennt man dann "Peer-Review" usw.

Ja, aber gerade bei Kryptographie ist das Feld viel größer. Attacken werden
teils erst Jahre oder Jahrzehnte nach der Entwicklung, Implementierung und
Benutzung der Algorithmen gefunden, und nur zum Teil auf Grund schnellerer
Rechner. Ein Algorithmus ist in der Regel nicht per se "sicher" oder
"unsicher", im allgemeinen gibt es eine Abschätzung wie lange ein Algorithmus
sicher ist. Irgendwann sind die Rechner halt so schnell daß man vieles einfach
per brute force knacken kann, eine Abschätzung darüber wie lange das dauern
wird zeigt die sinnvolle Lebensdauer an. Und die kann sehr schnell gegen 0
sinken, wenn unerwartet Attacken entdeckt werden.

> Sobald ein Code closed Source ist und da aus "Geheimhaltungsgründen"
> niemand - d. h. auch nicht unter Geheimhaltungsvereinbarung -
> drübersehen darf, beginnt es schwer nach Fisch zu riechen. Das soll
> übrigens nicht heißen, daß open Source zwingend besser ist, denn unter
> den Freiwilligen muß sich erstmal jemand finden, der die Zeit, Lust und
> Kompetenz auf/für so eine Begutachtung hat.

Bei closed source stellt sich das Problem gar nicht, da ja keiner den Code
prüfen kann. "Beweis" der Sicherheit durch Aufstampfen, kennen wir. Davon hält
man genau eines: Abstand.

> bool CheckLicense(const License& lic)
> {
> // [...]
> if(lic.password=="MyTopSecretPassword") return true;
> // [...]
> }

Haha, erinnert mich ein wenig an den Pen-Tester, der nach Tagen
freudestrahlend zu mir kam und meinte, er hätte jetzt *DIE* Lücke im
disassemblierten Code gefunden (Hätte er gefragt, hätte er ja auch den Source
mit Kommentaren und Erklärung dazu bekommen, aber das war wohl
wissenschaftlicher Forschergeist). Da wäre ein Passwort im Klartext im Code!
Ja genau! Ich habe ihn dann etwas lapidar auf Kapitel x in Handbuch y
verwiesen, in dem genau beschrieben war, daß der keystore aus
implementatorischen Gründen ein Passwort verlangt, dieses daher im Programm ja
vorliegen muß und das feste Passwort "abc" wie folgt verwendet wird.
Er war ein bisschen geknickt, hatte er doch kurz davor genau dieses geforderte
Sicherheitshandbuch mit allen Algorithmen validiert.

Bernd

[Helmut Schellong]

Nein, diese Entwickler sagen das Gegenteil.
Habe ich gepostet - wurde beharrlich ignoriert.

|This is a set of test vectors for conformance testing,

|The correctness of the code on different platforms is verified by generating and comparing test vectors.

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

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.

|The correctness of the code on different platforms is verified by generating and comparing test vectors.

> https://www.techtarget.com/searchsoftwarequality/definition/conformance-testing
> Da steht nix von "correctness" sondern nur "meets a defined set of standards".

Irrelevant.

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

Diese Aussagen sind aus der Dokumentation der aufgelisteten kryptographischen Algorithmen.
Die von Dir gegebenen Dokumentationen sind _nicht_ aus dieser Menge - und daher irrelevant!

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

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

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

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

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

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

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

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

Ich habe etwa 100 Seiten nur zu Rabbit gelesen.
Und ich vertraue diesen Entwicklern - die haben mich überzeugt.

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

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

> 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

Es sind vier Entwickler.
Es kann notwendig sein, herauszufinden, welcher welche Texte erarbeitet hatte.

>>>> "This is a set of test vectors for conformance testing,"
>>>> Hatte ich bereits gepostet.
>>>
>>>
>>>> "Korrekter und beweiskräftiger geht es nicht!" schrieb ich oben.
>>>> Reicht das nicht?
>>>> Falls nicht - was reicht denn dann?
>>>
>>> Ein mathematischer Beweis, daß der Code korrekt ist, also nicht der Nchweis, daß der Code bei der Eingabe einer (endlichen) Menge von Eingabeparametern die erwarteten Ergebnisse liefert, sondern daß der Code bei der Eingeba *aller erlaubten* Eingabeparametern die erwarteten Ergebnisse liefern wird.
>>> Dazu empfehle ich "The Science of Programming" von David Gries. Ist schon gut abgehangen, aber imho immer noch gut.
>>
>> Ich beherrsche etwa 20 Programmiersprachen mehr oder weniger gut - ein weiteres Buch brauche ich nicht.
>
> Ja, dann erübrigt sich ja die Debatte mit Dir, oh Du weiser Mann.

Ich habe nirgendwo behauptet, daß ich weise bin.

> Zwanzig Programmiersprachen ... wow! Ich erstarre in Ehrfurcht.

Das ist eine Tatsache.
Allerdings - wie ich schrieb - mehr oder weniger gut.

> Ich habe 1981 angefangen zu arbeiten (damals bei der Nixdorf Computer AG) und die Computerei ist mein Hobby. Wie viele Programmiersprachen ich kenne ... ich habe sie nie gezählt.
> Das ist ja auch völlig irrelevant! Und wenn Du 100 Programmiersprachen könntest, so hast Du immer noch nicht begriffen, was ich sagen will: Daß man mit Testen nie und nimmer die Korrektheit eines Codes beweisen kann.

Es ist überhaupt nicht irrelevant, welche Programmiersprachen man kann!

> Siehe hierzu auch
> https://de.wikipedia.org/wiki/Korrektheit_(Informatik)
>
> Oder die Folien hier:
> https://pi4.informatik.uni-mannheim.de/pi4.data/content/courses/2005-ws/pi1/slides/pi1-5b-2006-02-02.pdf
> "Testen nur das Vertrauen in die Korrektheit eines Programms erhöhen,
> nicht aber die Korrektheit beweisen."
>
> Oder die Folien hier:
> https://www.mathematik.uni-marburg.de/~gumm/Lehre/WS07/PraktischeInformatikI/Folien/14_Korrektheit.pdf
> "Durch Testen kann man nur Anwesenheit von
> Fehlern feststellen, nicht aber ihre
> Abwesenheit (E. Dijkstra)"
>
> Dijstra's Essay "On the reliability of programs" kannst Du übrigens hier nachlesen:
> https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html
>
> Ich zitiere mal (sinngemäß) einen Herrn Schellong: "Willst Du dem widersprechen?"
>
> Dijstra's These wird übrigens hier diskutiert:
> https://blog.liw.fi/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing/
> Und auch dort steht "Tests don’t tell you that code works in cases that aren’t tested. Tests tell you code works in the cases that are tested. If you want it to work in some other case, you add a test, or expand an existing test to cover the case you’re interested in."

Das alles ist allerdings im Kontext irrelevant.

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

Wozu auch?, wenn ich spezifische, zum Algorithmus passende Testprozeduren habe!

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

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

>>> Es ist extrem gefährlich zu behaupten, ein Code sei "bewiesenermaßen korrekt, weil er gewisse Tests erfolgreich durchlaufen hat", insbesondere wenn es sich um sicherheitsrelevanten Code handelt.
>>
>> Alle genannten Algorithmen wurden und werden weltweit millionenfach korrekt implementiert
>> und konkret hunderte-millionenfach in sicherheitsfordernder Umgebung verwendet.
>
> Ich sage ja nicht, daß sie fehlerhaft SIND, ich behaupte nur, daß man durch Testen niemals eine Korrektheit BEWEISen kann.
> Das ist in der Informatik allgemein bekannt und akzeptiert.
> Daß man trotzdem testet hat sicherlich damit zu tun, daß der mathematisch-logische KorrektheitsBEWEIS eines nicht-trivialen Stücks Code selber in besonderem Maße nicht-trivial ist und keiner sich die Arbeit machen will. Ich habe mkich während meine Studiums mit "weakest precondition"s und "postcondition"s 'rumschlagen dürfen. Es hat KEINEN Spaß gemacht ...
>
>> MD5 und RC4 werden trotz Korrumpierung vor vielen Jahren weiterhin verwendet.
>
> Wie gesagt: Ich behaupt nicht, daß sie fehlerhaft SIND.
>
>>> Ich stelle mir gerade vor, wie das ist, wenn eine Brücke als "bewiesenermaßen korrekt gebaut" ist und für den allgemeinen Verkehr freigegeben wird, weil man nach dem Bau ein paar LKW darüber hat fahren lassen.
>>>
>>>
>>
>> So wird das seit vielleicht 150 Jahren weltweit getan.
>
> 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.

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

[Helmut Schellong]

On 03/29/2022 20:34, Hanno Foest wrote:
> On 29.03.22 19:04, Helmut Schellong wrote:
>
>>> Das ist scheissegal was da steht,
>>
>> Nein, es ist gar nicht egal, was da steht.
>
> Doch, da du eh nicht fähig bist, es richtig zu verstehen.

Das ist eine haltlose Behauptung.

>>   du kannst zB. nicht zeigen, daß es bei deiner Implementierung keine Seitenkanäle gibt,
>>   da evtl. noch nicht mal bekannt ist, welche das in Zukunft sein könnten.
>>>
>> Ich habe bereits gepostet, daß ich alle diese Algorithmen
>> nur von und zu lokaler Festplatte benutze.
>
> Ok, wenn praktisch niemand irgendwo deinen binären Sondermüll benutzt, ist dessen Schadensreichweite natürlich begrenzt.
>
>

Ja, so ist das.
Ich habe bisher mehrfach http://www.schellong.de/htm/rabbit.bish.html gepostet.
Darin ist erkennbar, wie genau ich mehrere Algorithmen benutze.

Ich benutze das Skript erfolgreich. Es funktioniert makellos.

[Helmut Schellong]

On 03/29/2022 23:35, Bernd Laengerich wrote:
> Am 29.03.2022 um 18:13 schrieb Volker Bartheld:
>
>>> Bei Kryptographie erst wenn Experten dauerhaft keine
>>> Schwachstellen finden konnten.
>>
>> ... bedienen dürfen. Nennt man dann "Peer-Review" usw.
>
> Ja, aber gerade bei Kryptographie ist das Feld viel größer. Attacken werden teils erst Jahre oder Jahrzehnte nach der Entwicklung, Implementierung und Benutzung der Algorithmen gefunden, und nur zum Teil auf Grund schnellerer Rechner. Ein Algorithmus ist in der Regel nicht per se "sicher" oder "unsicher", im allgemeinen gibt es eine Abschätzung wie lange ein  Algorithmus sicher ist. Irgendwann sind die Rechner halt so schnell daß man vieles einfach per brute force knacken kann, eine Abschätzung darüber wie lange das dauern wird zeigt die sinnvolle Lebensdauer an. Und die kann sehr schnell gegen 0 sinken, wenn unerwartet Attacken entdeckt werden.

Du beschreibst hier korrekt die (Zwangs-)Lage bei kryptographischen Algorithmen.

Unerwartete Attacken können aber auch dauerhaft ausbleiben.
Brute force liefert nicht garantiert ein Knacken.
Beispielsweise Rabbit hat seit 2003 _keine_ Schwäche offenbart.

>> Sobald ein Code closed Source ist und da aus "Geheimhaltungsgründen"
>> niemand - d. h. auch nicht unter Geheimhaltungsvereinbarung -
>> drübersehen darf, beginnt es schwer nach Fisch zu riechen. Das soll
>> übrigens nicht heißen, daß open Source zwingend besser ist, denn unter
>> den Freiwilligen muß sich erstmal jemand finden, der die Zeit, Lust und
>> Kompetenz auf/für so eine Begutachtung hat.
>
> Bei closed source stellt sich das Problem gar nicht, da ja keiner den Code prüfen kann. "Beweis" der Sicherheit durch Aufstampfen, kennen wir. Davon hält man genau eines: Abstand.
>
>> bool CheckLicense(const License& lic)
>> {
>>     // [...]
>>     if(lic.password=="MyTopSecretPassword") return true;
>>     // [...]
>> }
>
> Haha, erinnert mich ein wenig an den Pen-Tester, der nach Tagen freudestrahlend zu mir kam und meinte, er hätte jetzt *DIE* Lücke im disassemblierten Code gefunden (Hätte er gefragt, hätte er ja auch den Source mit Kommentaren und Erklärung dazu bekommen, aber das war wohl wissenschaftlicher Forschergeist). Da wäre ein Passwort im Klartext im Code! Ja genau! Ich habe ihn dann etwas lapidar auf Kapitel x in Handbuch y verwiesen, in dem genau beschrieben war, daß der keystore aus implementatorischen Gründen ein Passwort verlangt, dieses daher im Programm ja vorliegen muß und das feste Passwort "abc" wie folgt verwendet wird.
> Er war ein bisschen geknickt, hatte er doch kurz davor genau dieses geforderte Sicherheitshandbuch mit allen Algorithmen validiert.
>
>

Schwachsinns-Code.
Ich verschleiere solche Daten u.a. durch a='p', b='a', c='s', d='w';

411] strings /u/bin/bish
FreeBSD
FreeBSD
AWAVSPH
AWAVAUATSPI
ffffff.
...

[Josef Moellers]

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

>> https://www.techtarget.com/searchsoftwarequality/definition/conformance-testing
>>
>> Da steht nix von "correctness" sondern nur "meets a defined set of
>> standards".
>
> Irrelevant.

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

>> Siehe hierzu auch
>> https://de.wikipedia.org/wiki/Korrektheit_(Informatik)
>>
>> Oder die Folien hier:
>> https://pi4.informatik.uni-mannheim.de/pi4.data/content/courses/2005-ws/pi1/slides/pi1-5b-2006-02-02.pdf
>>
>> "Testen nur das Vertrauen in die Korrektheit eines Programms erhöhen,
>> nicht aber die Korrektheit beweisen."
>>
>> Oder die Folien hier:
>> https://www.mathematik.uni-marburg.de/~gumm/Lehre/WS07/PraktischeInformatikI/Folien/14_Korrektheit.pdf
>>
>> "Durch Testen kann man nur Anwesenheit von
>> Fehlern feststellen, nicht aber ihre
>> Abwesenheit (E. Dijkstra)"
>>
>> Dijstra's Essay "On the reliability of programs" kannst Du übrigens
>> hier nachlesen:
>> https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html
>>
>> Ich zitiere mal (sinngemäß) einen Herrn Schellong: "Willst Du dem
>> widersprechen?"
>>
>> Dijstra's These wird übrigens hier diskutiert:
>> https://blog.liw.fi/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing/
>>
>> Und auch dort steht "Tests don’t tell you that code works in cases
>> that aren’t tested. Tests tell you code works in the cases that are
>> tested. If you want it to work in some other case, you add a test, or
>> expand an existing test to cover the case you’re interested in."
>
> Das alles ist allerdings im Kontext irrelevant.

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

[Volker Bartheld]

On Tue, 29 Mar 2022 20:04:54 +0200, Josef Moellers wrote:
> On 29.03.22 15:14, Helmut Schellong wrote:
>>|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

Es geht hier konkret um die Überprüfung der grundlegenden Annahme, daß sich
die Implementierung auf den unterschiedlichen Compilern und Plattformen
weitestgehend (d. h. zumindst ohne funktionale Abweichungen) gleich
verhält. Typischerweise wimmelt es dort von expliziten oder impliziten
Preprozessoranweisungen wie...

#ifdef WIN
#include <foo>
#else
#include <bar>
#endif

, wir haben unterschiedliche Versionen der C++ Runtime, der STL, das ABI
unterscheidet sich, nicht einmal auf die Byteorder (LSB/MSB, Little/Big
Endian) oder die Breite (wieviele Bits hat der Typ "int" oder "long" auf
einer 32- vs. 64-Bit-Plattform, Windows vs. Linux, auf einem Arduino,
usw.) kann man sich nicht zwingend verlassen.

Die Hoffnung (ich wähle diesen Begriff mit voller Absicht) ist, daß
funktionsrelevante Abweichungen sich bereits in einer kleinen Untermenge
der Tests - z. B. mit Testvektoren - offenbaren.

Aber wem sage ich das.

>> 'conformance' heißt 'Übereinstimmung'.
>> Wenn Test-Vektoren Übereinstimmung erzielen, ist eine Implementation
>> korrekt.
> Übereinstimmung womit?

Wenn die Testvektoren Übereinstimmung erzielen, verhält sich das System für
diese Testvektoren wie erwartet. Es wurde hinreichend oft gezeigt, daß sich
Szenarien konstruieren lassen, die nur und genau für diese Testvektoren
funktionieren, für andere aber nicht. Das mag jetzt wie Theoriewichserei
klingen, ist aber für ein Verständnis dessen, was man da eigentlich testet,
fundamental wichtig.

De facto ist ein Test immer nur eine Stichprobe. Zumindest dann, wenn ich
unter "Test" nicht einen mathematischen Funktionsbeweis verstehe oder der
Code - so wie es bei der Entwicklung von Software für manche Steuergeräte
der Fall ist - automatisch von einem hoffentlich pefekten Compiler aus
einem hoffentlich perfekten Simulationsmodell erzeugt wurde. Dort gibt es
wieder ganz andere Probleme, deren Diskussion an dieser Stelle aber zu
weit führen würde.

>> Deren Korrektheit ist durch eine Übereinstimmung _bewiesen_.
>> Das sagen die Entwickler aus!
>> Und Punkt.
> Tja, dann glaube das bitte weiter.

Genau. Ist ohnehin irrelevant.

>>|We, the designers of Rabbit, hereby state that no hidden weaknesses have
>>|been inserted by us in the Rabbit algorithm.
> Das beruhigt ungemein.

Weil es eine Beteuerung ist, die zumindest Vorsatz ausschließt. Die Haftung
für Fahrlässigkeit wird üblicherweise in einem anderen Passus der
Lizenzvereinbarung verweigert. Aus gutem Grund.

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

Und wirst auf eine semantische Diskussion treffen, bei der es um die
Unterschiede zwischen "überprüfen" und "garantieren" geht. Bei der
allzweijährigen Hauptuntersuchung wird Dein Fahrzeug auf die
Verkehrssicherheit hin überprüft. Garantiert Dir der Sachverständige nach
Abschluß der Prüfung die Verkehrssicherheit? Nein.

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

Allein die Tatsache, daß _Entwickler_ ihr Produkt testen...

>> Ich beherrsche etwa 20 Programmiersprachen mehr oder weniger gut - ein
>> weiteres Buch brauche ich nicht.
> Ja, dann erübrigt sich ja die Debatte mit Dir, oh Du weiser Mann.
> Zwanzig Programmiersprachen ... wow! Ich erstarre in Ehrfurcht.

Mehr oder weniger gut. Vielleicht können wir das Thema nun zu Grabe tragen.
Einen großen Schaden wird unser Universalgenie wohl kaum anrichten können.

Volker

[Helmut Schellong]

Du und mindestens ein Anderer verstehen die Semantik der Sprache nicht richtig.

'verified' kann mit 'nachgewiesen' übersetzt werden.
Der Satzgegenstand ist die 'correctness of the code'.
Diese wird nachgewiesen durch Vergleich mit Test-Vektoren.
Wie oft muß ich das noch schreiben.

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

'verified' kann mit 'nachgewiesen' übersetzt werden.
to verify nachweisen
to verify sth. etw. beweisen

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

Ich habe mich in der Vergangenheit intensiv damit beschäftigt.
1978 kaufte ich den TI59 mit mehreren Programm-Modulen.
Da ist viel Mathematik und Statistik dabei.

Du betreibst wieder Haarspalterei.
Wenn man sich mit Zahlen wie 2^512 beschäftigt, sieht man, daß das dem Wert 10^154 entspricht.
Das ist weit jenseits von Yotta:Quadrillion:10^24.
(154 ~ 512/3,322)
Die Zahlen sind derart groß, daß sie sich der statistischen Anwendung in der normalen Praxis entziehen.
Ich kann nicht hier bei mir einen Rechner aufstellen und diesen 20 Jahre rechnen lassen.
Auch nicht 2 Jahre - wohl 2 Monate.

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

Diese Überlegungen sind unzutreffend im Zusammenhang mit den hier relevanten Algorithmen.
Diese Algorithmen arbeiten ausschließlich mit elementaren Integer-Operationen.
Es gibt da eine eins-zu-eins-Korrespondenz durch den ganzen Algorithmus hindurch.

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

Es kommt sehr darauf an, welche Worte und Sätze da genau kommuniziert werden.
Damit die Kommunikation nicht fehlgeleitet sein wird.

>> |The correctness of the code on different platforms is verified by generating and comparing test vectors.
>
> Wieder dieses Wörtchen *verified* und NICHT *proven* ...

Und wieder das Nichterkennen der Semantik der Sprache.

>>> https://www.techtarget.com/searchsoftwarequality/definition/conformance-testing
>>> Da steht nix von "correctness" sondern nur "meets a defined set of standards".
>>
>> Irrelevant.
>
> ... weil nicht zu Deiner Argumentation passend.

Nein, weil es sich wegbewegt vom Thema der kryptographischen Algorithmen.
Du willst aus dem Kontext-Thema ausbrechen, weil Dir die Aussagen der Entwickler (Wissenschaftler)
der Kontext-Algorithmen nicht passen, auf die ich mich beharrlich beziehe.

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

Und wieder das Nichterkennen der Semantik der Sprache.
Du fährst den Entwicklern der Algorithmen ständig über den Arsch.

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

Nein, Du hast erkannt, daß Du im Kontext nicht mehr wirksam argumentieren kannst
und willst deshalb aus dem Kontext ausbrechen.

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

Diese Allgemeinplätze sind im Kontext eben nicht anwendbar.
Das willst Du partout nicht erkennen.

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

Du hast absolut keine Ahnung von den konkret implementierten Algorithmen des Kontextes.
Deshalb kann bei Dir auch nicht/nie die richtige Erkenntnis kommen, solange Dir dies unbekannt ist.

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

Es wird in _allen_ Fällen garantiert so sein.
Du verstehst auch hier nicht die Semantik, die in der eins-zu-eins-Korrespondenz innerhalb der Algorithmen steckt.
Da sind Hopfen und Malz eben verloren.

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

Und wieder das Nichterkennen der Semantik der Sprache.
Das ist offenbar ein Tick von Dir.

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

Nein, 'verify' kann mit 'beweisen' gültig übersetzt werden.
Ich habe Aussagen der Entwickler zitiert.
Inwiefern verdrehe ich den Entwicklern dadurch die Worte im Mund?

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

Und wieder das Nichterkennen der Semantik der Sprache.
Das ist offenbar ein Tick von Dir.

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

Es geht um die Korrektheit einer Implementation nur der aufgeführten kryptographischen Algorithmen.

Das ist der Kontext!

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

Eventuell, wenn man die Dokumentationen der Entwickler nicht ausreichend kennt.

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

Nein, die Entwickler sagen das auch.
Du willst das jedoch nicht wahrhaben und spielst daher mit sprachlicher Semantik herum.
Du kennst einfach nicht die Natur der konkret implementierten Algorithmen.
Das macht es schwierig bis unmöglich, Eigenschaften zu erkennen.

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

Das ist nicht gewagt, sofern man die Algorithmen implementiert kennt.
Die Entwickler sprechen auch von einer eins-zu-eins-Korrespondenz, die die Algorithmen durchläuft.
Ich habe diese Korrespondenz längst identifiziert.
Ich - fast alle Anderen nicht.

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

Da die Entwickler das behaupten und ich ihnen dabei folge und deren Aussagen in der
Implementation erkannt habe, muß ich bei meinem Standpunkt bleiben.

[... ...]

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

|The correctness of the code on different platforms is verified by generating and comparing test vectors.

Da steht das Wort 'generating'.
Die generieren die Test-Vektoren mittels in deren Kreisen bekannter Software.
Diese Leute sind halt in jeder Hinsicht professionell!
Das habe ich schon vor langer Zeit erkannt.
Deshalb vertraue ich deren Arbeiten auch.

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

Ich habe 15 Jahre lang erfolgreich Software auch für Hochsicherheitsbereiche entwickelt.
Auf Anhieb korrekt.

Hast Du einen Tick hinsichtlich 'Hybris'?
Niemand, der etwas kann, darf sagen, daß er dies kann, sonst ist er an Hybris erkrankt?

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

Architekten haben im Beruf viel mit Statik-Berechnungen zu tun.
Die wissen z.B., daß in irgendeiner Wohnung keine Steinplatten anstelle von Teppichboden
gelegt werden dürfen.
Garantien gibt es da nicht, deshalb muß es Abschlußtests und zyklische Prüfungen geben.

Kräne werden z.B. mit der doppelten nominellen Belastung lang genug geprüft.
Autoreifen halten meist etwa 30 bar aus, bis sie platzen.

[Helmut Schellong]

On 03/30/2022 10:19, Volker Bartheld wrote:
> On Tue, 29 Mar 2022 20:04:54 +0200, Josef Moellers wrote:
>> On 29.03.22 15:14, Helmut Schellong wrote:

[... ...]

>
>> 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?
>
> Allein die Tatsache, daß _Entwickler_ ihr Produkt testen...

Ich finde es frappierend und unprofessionell, hartnäckig zu ignorieren, daß
die Entwickler der Kontext-Algorithmen all ihre jeweiligen Angaben NUR zu den
von ihnen entwickelten Algorithmen machen.
In diesem maximal engen Umfeld können sie auch Angaben machen (und garantieren),
die sie außerhalb dieses maximal engen Umfelds eben nicht garantieren könnten.

Diese Tatsache will man einfach nicht sehen und wahrhaben.
Es wird der globale Weltkontext präferiert, in dem freizügig alles in Frage
gestellt werden kann, um argumentativ weiterzukommen.
(Weil einfach keine oder nur beschränkte Kenntnisse zum Ziel vorhanden sind.)

> Mehr oder weniger gut. Vielleicht können wir das Thema nun zu Grabe tragen.
> Einen großen Schaden wird unser Universalgenie wohl kaum anrichten können.
>
>

Einen nennenswerten Schaden habe ich noch nie angerichtet.
Meine Entwicklungen hatten stets den Sollnutzen erbracht.

[Josef Moellers]

Ja, von mir aus, wenn's Dich glücklich macht.

Plonk.

[Thomas Prufer]

On Tue, 29 Mar 2022 15:14:21 +0200, Helmut Schellong <r...@schellong.biz> wrote:

>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.
>Die Entwickler kennen ihre Entwicklung in dieser Hinsicht ganz genau.
>Schließlich sind die Algorithmen deterministisch.

Das ist falsch, denn der Algorithmus

if Testverktor1 then return (Ergebnis-Testvektor1)
else
if Testverktor2 then return (Ergebnis-Testvektor2)
else ... usw usf.
else return(42)

erfüllt die Tests, ist aber augenscheinlich falsch, denn es liefert 42 für alle
nicht-Testvektoren.

Obiges ist ein *Beweis*, merke ich hier an...


Thomas Prufer

[Thomas Prufer]

On Wed, 30 Mar 2022 09:34:31 +0200, Josef Moellers
<josef.m...@invalid.invalid> wrote:

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

... so wie ich (und viele andere) nicht das beweisen anfangen, wenn wer ein
funktionierendes perpetuum mobile behauptet.

Thomas Prufer

[Helmut Schellong]

Ich sehe einen Syntax-Fehler...

[Hanno Foest]

Am 30.03.22 um 15:01 schrieb Thomas Prufer:

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

Das ist elementare Erkenntnistheorie. Du kannst ja auch die These "alle
Schwäne sind weiß" nicht durch Testen (Beobachtung beliebig vieler
weißer Schwäne) beweisen - sie ist immer noch falsch, sobald der erste
schwarze Schwan um die Ecke kommt.

> ... so wie ich (und viele andere) nicht das beweisen anfangen, wenn wer ein
> funktionierendes perpetuum mobile behauptet.

Das obendrein...

[Bernd Laengerich]

Am 30.03.2022 um 09:34 schrieb Josef Moellers:

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

Nun ja, nachdem ja herauskam daß RSA absichtlich Schwächen eingebaut hat um
eine Hintertür zu haben, wollte man wohl sagen, daß so etwas nicht absichtlich
eingebaut wurde. Versteckte, ungewollte Schwächen kann es dennoch geben.

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

Das Problem bei Kryptographie ist in der Regel halt eine Seitenkanalattacke,
die die mathematisch korrekte Arbeitsweise durch Nebeneffekte schwächt. Dazu
gehören Ablaufzeiten, Stromverbrauchsmessungen, Anzahl und Art von
Speicherzugriffen und dadurch bedingte EM-Abstrahlungen etc. Spezielle
Kryptoprozessoren sind seit langem erfunden und werden benutzt, sie verstecken
einiges davon durch stets gleichbleibenden Stromverbrauch, stets
gleichbleibend isochrone Speicherzugriffe etc.

Unsere Sicherheitssoftware läuft in einem HSM mit Kryptoprozessor. Aber wir
entwickeln die grundlegenden Kryptographiefunktionen nicht selber, da gibt es
fertige Module für Elliptic Curves, RSA, AES, DES etc. Was von uns kommt sind
die konkreten Nutzungen der Basisfunktionen und der ganze Glue-Layer
drumherum, wie Padding.
Zum Beispiel Umschlüsseln einer PIN wird mit 2 Anwendungsfunktionen gemacht:
1. Entschlüsseln des verschlüsselten PIN-Blockes und Neuverschlüsselung in ein
verschlüsseltes Zwischenergebnis, dieses bekommt die Anwendung. Das
Zwischenergebnis ist mit einem temporären Schlüssel verschlüsselt der nur in
dem konkreten HSM für begrenzte Zeit zur Verfügung steht.
2. Verschlüsseln eines verschlüsselten Zwischenergebnisses zu einem neuen
PIN-Block, die Anwendung bekommt als Ergebnis den neu verschlüsselten und ggf.
umgeformten PIN-Block.
Für diese beiden Funktionen alleine gibt es mehr als tausend Tests.
Das erstellte Softwaremodul muß für jede Version sicherheitsbegutachtet und
zertifiziert werden, man ist also bemüht fehlerarme Versionen zu erstellen,
sonst wird es teuer (OK, das ist das geringere Problem) und es dauert jedesmal
einige Zeit bis die Begutachtung durch ist (das kann größere Probleme machen).

Bernd

[Gerrit Heitsch]

On 3/30/22 18:10, Bernd Laengerich wrote:
>
> Das Problem bei Kryptographie ist in der Regel halt eine
> Seitenkanalattacke, die die mathematisch korrekte Arbeitsweise durch
> Nebeneffekte schwächt. Dazu gehören Ablaufzeiten,
> Stromverbrauchsmessungen, Anzahl und Art von Speicherzugriffen und
> dadurch bedingte EM-Abstrahlungen etc. Spezielle Kryptoprozessoren sind
> seit langem erfunden und werden benutzt, sie verstecken einiges davon
> durch stets gleichbleibenden Stromverbrauch, stets gleichbleibend
> isochrone Speicherzugriffe etc.

Bisher hat sich leider oft gezeigt, daß obige Behauptungen nur bedeuten,
daß man noch nicht genau genug gemessen hat. Mit Glitching hat man auch
schon einigen als sicher verkauften Chips Daten entlocken können.

Gerrit

[Enrik Berkhan]

Helmut Schellong <r...@schellong.biz> wrote:
>
> Ich sehe einen Syntax-Fehler...
>

Das ist, sagen wir mal, "interessant".

[Helmut Schellong]

On 03/30/2022 14:57, Thomas Prufer wrote:

Algorithmus:

y= 10*(x+1)+5; x=0..9999; (Referenz-Implementation)

Implementationsfehler:
10*(x+1)-5
10*(x+1)+4
11*(x+1)+5
10+(x+1)+5
10-(x+1)+5
9*(x+1)+5
10-(x+1)-5
10*(x+1)*5

Trotzdem reicht ein Test x=0 y=15 aus, um die Korrektheit
der Implementation zu beweisen.
Jeder beliebige einzelne Test reicht dazu aus!
Beispielsweise x=9975 y=99765 wird nur von einer korrekten Implementation generiert.

Die Entwickler eines Algorithmus werden fast immer in der Lage sein, ein einfaches
Testverfahren zum Beweis einer korrekten Implementation auszuarbeiten.
Sie kennen ihren Algorithmus!
In diesem Fall sind alle existierenden allgemeinen Regeln in der Informatik, die
einen Beweis durch Test ausschließen, ungültig im Kontext des betreffenden Algorithmus.

Auch zum Algorithmus Rabbit wurden Testdaten bereitgestellt, die aufgrund der
Eigenschaften des Algorithmus durch ihre Verwendung höchstwahrscheinlich einen Beweis
einer korrekten Implementierung feststellen können.

=============================================================================
Appendix A: Test Vectors

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

A.1. Testing without IV Setup

key = [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
S[0] = [B1 57 54 F0 36 A5 D6 EC F5 6B 45 26 1C 4A F7 02]
S[1] = [88 E8 D8 15 C5 9C 0C 39 7B 69 6C 47 89 C6 8A A7]
S[2] = [F4 16 A1 C3 70 0C D4 51 DA 68 D1 88 16 73 D6 96]

key = [91 28 13 29 2E 3D 36 FE 3B FC 62 F1 DC 51 C3 AC]
S[0] = [3D 2D F3 C8 3E F6 27 A1 E9 7F C3 84 87 E2 51 9C]
S[1] = [F5 76 CD 61 F4 40 5B 88 96 BF 53 AA 85 54 FC 19]
S[2] = [E5 54 74 73 FB DB 43 50 8A E5 3B 20 20 4D 4C 5E]

key = [83 95 74 15 87 E0 C7 33 E9 E9 AB 01 C0 9B 00 43]
S[0] = [0C B1 0D CD A0 41 CD AC 32 EB 5C FD 02 D0 60 9B]
S[1] = [95 FC 9F CA 0F 17 01 5A 7B 70 92 11 4C FF 3E AD]
S[2] = [96 49 E5 DE 8B FC 7F 3F 92 41 47 AD 3A 94 74 28]

A.2. Testing with IV Setup

mkey = [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
iv = [00 00 00 00 00 00 00 00]
S[0] = [C6 A7 27 5E F8 54 95 D8 7C CD 5D 37 67 05 B7 ED]
S[1] = [5F 29 A6 AC 04 F5 EF D4 7B 8F 29 32 70 DC 4A 8D]
S[2] = [2A DE 82 2B 29 DE 6C 1E E5 2B DB 8A 47 BF 8F 66]

iv = [C3 73 F5 75 C1 26 7E 59]
S[0] = [1F CD 4E B9 58 00 12 E2 E0 DC CC 92 22 01 7D 6D]
S[1] = [A7 5F 4E 10 D1 21 25 01 7B 24 99 FF ED 93 6F 2E]
S[2] = [EB C1 12 C3 93 E7 38 39 23 56 BD D0 12 02 9B A7]

iv = [A6 EB 56 1A D2 F4 17 27]
S[0] = [44 5A D8 C8 05 85 8D BF 70 B6 AF 23 A1 51 10 4D]
S[1] = [96 C8 F2 79 47 F4 2C 5B AE AE 67 C6 AC C3 5B 03]
S[2] = [9F CB FC 89 5F A7 1C 17 31 3D F0 34 F0 15 51 CB]

Appendix B: Debugging Vectors

The following set of vectors describes the inner state of Rabbit
during key and iv setup. It is meant mainly for debugging purposes.
Octet strings are written according to I2OSP conventions.

B.1. Testing Round Function and Key Setup

key = [91 28 13 29 2E ED 36 FE 3B FC 62 F1 DC 51 C3 AC]

Inner state after key expansion:
b = 0
X0 = 0xDC51C3AC, X1 = 0x13292E3D, X2 = 0x3BFC62F1, X3 = 0xC3AC9128,
X4 = 0x2E3D36FE, X5 = 0x62F1DC51, X6 = 0x91281329, X7 = 0x36FE3BFC,
C0 = 0x36FE2E3D, C1 = 0xDC5162F1, C2 = 0x13299128, C3 = 0x3BFC36FE,
C4 = 0xC3ACDC51, C5 = 0x2E3D1329, C6 = 0x62F13BFC, C7 = 0x9128C3AC

Inner state after first key setup iteration:
b = 1
X0 = 0xF2E8C8B1, X1 = 0x38E06FA7, X2 = 0x9A0D72C0, X3 = 0xF21F5334,
X4 = 0xCACDCCC3, X5 = 0x4B239CBE, X6 = 0x0565DCCC, X7 = 0xB1587C8D,
C0 = 0x8433018A, C1 = 0xAF9E97C4, C2 = 0x47FCDE5D, C3 = 0x89310A4B,
C4 = 0x96FA1124, C5 = 0x6310605E, C6 = 0xB0260F49, C7 = 0x6475F87F

Inner state after fourth key setup iteration:
b = 0
X0 = 0x1D059312, X1 = 0xBDDC3E45, X2 = 0xF440927D, X3 = 0x50CBB553,
X4 = 0x36709423, X5 = 0x0B6F0711, X6 = 0x3ADA3A7B, X7 = 0xEB9800C8,
C0 = 0x6BD17B74, C1 = 0x2986363E, C2 = 0xE676C5FC, C3 = 0x70CF8432,
C4 = 0x10E1AF9E, C5 = 0x018A47FD, C6 = 0x97C48931, C7 = 0xDE5D96F9

Inner state after final key setup xor:
b = 0
X0 = 0x1D059312, X1 = 0xBDDC3E45, X2 = 0xF440927D, X3 = 0x50CBB553,
X4 = 0x36709423, X5 = 0x0B6F0711, X6 = 0x3ADA3A7B, X7 = 0xEB9800C8,
C0 = 0x5DA1EF57, C1 = 0x22E9312F, C2 = 0xDCACFF87, C3 = 0x9B5784FA,
C4 = 0x0DE43C8C, C5 = 0xBC5679B8, C6 = 0x63841B4C, C7 = 0x8E9623AA

Inner state after generation of 48 bytes of output:
b = 1
X0 = 0xB5428566, X1 = 0xA2593617, X2 = 0xFF5578DE, X3 = 0x7293950F,
X4 = 0x145CE109, X5 = 0xC93875B0, X6 = 0xD34306E0, X7 = 0x43FEEF87,
C0 = 0x45406940, C1 = 0x9CD0CFA9, C2 = 0x7B26E725, C3 = 0x82F5FEE2,
C4 = 0x87CBDB06, C5 = 0x5AD06156, C6 = 0x4B229534, C7 = 0x087DC224

The 48 output bytes:
S[0] = [3D 2D F3 C8 3E F6 27 A1 E9 7F C3 84 87 E2 51 9C]
S[1] = [F5 76 CD 61 F4 40 5B 88 96 BF 53 AA 85 54 FC 19]
S[2] = [E5 54 74 73 FB DB 43 50 8A E5 3B 20 20 4D 4C 5E]

B.2. Testing the IV Setup

key = [91 28 13 29 2E ED 36 FE 3B FC 62 F1 DC 51 C3 AC]
iv = [C3 73 F5 75 C1 26 7E 59]

Inner state during key setup:
as above

Inner state after IV expansion:
b = 0
X0 = 0x1D059312, X1 = 0xBDDC3E45, X2 = 0xF440927D, X3 = 0x50CBB553,
X4 = 0x36709423, X5 = 0x0B6F0711, X6 = 0x3ADA3A7B, X7 = 0xEB9800C8,
C0 = 0x9C87910E, C1 = 0xE19AF009, C2 = 0x1FDF0AF2, C3 = 0x6E22FAA3,
C4 = 0xCCC242D5, C5 = 0x7F25B89E, C6 = 0xA0F7EE39, C7 = 0x7BE35DF3

Inner state after first IV setup iteration:
b = 1
X0 = 0xC4FF831A, X1 = 0xEF5CD094, X2 = 0xC5933855, X3 = 0xC05A5C03,
X4 = 0x4A50522F, X5 = 0xDF487BE4, X6 = 0xA45FA013, X7 = 0x05531179,
C0 = 0xE9BC645B, C1 = 0xB4E824DC, C2 = 0x54B25827, C3 = 0xBB57CDF0,
C4 = 0xA00F77A8, C5 = 0xB3F905D3, C6 = 0xEE2CC186, C7 = 0x4F3092C6

Inner state after fourth IV setup iteration:
b = 1
X0 = 0x6274E424, X1 = 0xE14CE120, X2 = 0xDA8739D9, X3 = 0x65E0402D,
X4 = 0xD1281D10, X5 = 0xBD435BAA, X6 = 0x4E9E7A02, X7 = 0x9B467ABD,
C0 = 0xD15ADE44, C1 = 0x2ECFC356, C2 = 0xF32C3FC6, C3 = 0xA2F647D7,
C4 = 0x19F71622, C5 = 0x5272ED72, C6 = 0xD5CB3B6E, C7 = 0xC9183140
=============================================================================

[Helmut Schellong]

On 03/30/2022 18:10, Bernd Laengerich wrote:
> Am 30.03.2022 um 09:34 schrieb Josef Moellers:
>
>>>>> |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.
>
> Nun ja, nachdem ja herauskam daß RSA absichtlich Schwächen eingebaut hat um eine Hintertür zu haben, wollte man wohl sagen, daß so etwas nicht absichtlich eingebaut wurde. Versteckte, ungewollte Schwächen kann es dennoch geben.

Entdeckt wurden bisher (seit 2003) keine.

[Thomas Prufer]

On Wed, 30 Mar 2022 20:57:10 +0200, Helmut Schellong <r...@schellong.biz> wrote:

>Trotzdem reicht ein Test x=0 y=15 aus, um die Korrektheit
>der Implementation zu beweisen.
>Jeder beliebige einzelne Test reicht dazu aus!

Da feits vom Boa weg.

>Appendix A: Test Vectors
>
> This is a set of test vectors for conformance testing, given in octet
> form.

... and I don't really think your English is up to the fine distinction between
conformance testing and mathematical proof...

Thomas Prufer