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

  • Thread starter Helmut Schellong
  • Start date
On Mon, 28 Mar 2022 20:23:42 +0200, Thomas Prufer wrote:
On Mon, 28 Mar 2022 15:28:20 +0200, Helmut Schellong <rip@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
 
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
 
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::eek:stringstream 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
 
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
 
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
 
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;
// [...]
}

.... oder:

std::string ComputeLicense(const std::string& SysId, int ExpireDays)
{
std::eek:stringstream 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
 
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 <rip@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.


--
Mit freundlichen Grüßen
Helmut Schellong var@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
 
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 <rip@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.


--
Mit freundlichen Grüßen
Helmut Schellong var@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
 
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.


--
Mit freundlichen Grüßen
Helmut Schellong var@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
 
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.


--
Mit freundlichen Grüßen
Helmut Schellong var@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
 
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
 
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
 
On 03/29/2022 14:42, Volker Bartheld wrote:
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;
// [...]
}

... oder:

std::string ComputeLicense(const std::string& SysId, int ExpireDays)
{
std::eek:stringstream 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

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


--
Mit freundlichen Grüßen
Helmut Schellong var@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
 
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?


--
Mit freundlichen Grüßen
Helmut Schellong var@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
 
On 03/29/2022 16:52, Reinhardt Behm wrote:
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.

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


--
Mit freundlichen Grüßen
Helmut Schellong var@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
 
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
 
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
 
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;
// [...]
}

.... oder:

std::string ComputeLicense(const std::string& SysId, int ExpireDays)
{
std::eek:stringstream 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)
{
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
 
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.


--
Mit freundlichen Grüßen
Helmut Schellong var@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
 
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.


--
Mit freundlichen Grüßen
Helmut Schellong var@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
 

Welcome to EDABoard.com

Sponsor

Back
Top