V
Volker Bartheld
Guest
On Mon, 28 Mar 2022 20:23:42 +0200, Thomas Prufer wrote:
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.
double pow(double x, double y) { return 1; }
TEST(Math, TestPow) { EXPECT_DOUBLE_EQ(pow(1, 2), 1); }
Läuft!
Hinreichend vs. notwendig. Mittelstufenmathematik.
>> Keiner der oben gelisteten Algorithmen wurde bisher \'geknackt\'.
Aber vielleicht bald Deine schwache Implementierung.
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.
Tscha.
Genau. Und zwar in Kursivschrift, mit Ausrufezeichen!
Genau. Und zwar in Kursivschrift, ohne Ausrufezeichen diesmal.
Was ist denn die kryptografische Qualität?
Hmmmm. Vielleicht mal zum Thema \"Padding\" schlau machen und warum man
dafür gerne irgendwelche Zufallszahlen benutzt [1].
Hachja. Was solls. Wieder eine halbe Stunde Zeit verschwendet.
Volker
[1] https://www.di-mgt.com.au/cryptopad.html
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