Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #369613 > unrolled thread
| Started by | Helmut Schellong <var@schellong.biz> |
|---|---|
| First post | 2026-09-29 13:06 +0200 |
| Last post | 2026-09-29 18:46 +0200 |
| Articles | 20 on this page of 104 — 14 participants |
Back to article view | Back to de.sci.electronics
random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 13:06 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 15:45 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 18:37 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 21:33 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 22:41 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 22:51 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 00:26 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 02:05 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 10:45 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 10:57 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:33 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-30 15:31 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 16:25 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-30 17:17 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-04 02:45 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 11:58 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 01:31 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 12:46 +0200
Re: random_rdtsc und random_rdrand Heinz Schmitz <sch@example.invalid> - 2026-10-05 13:17 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 14:18 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-05 14:57 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 15:47 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 18:44 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-30 01:23 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 10:19 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 05:16 +0200
Re: random_rdtsc und random_rdrand Marte Schwarz <marte.schwarz@gmx.de> - 2026-09-30 08:01 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 08:11 +0200
Re: random_rdtsc und random_rdrand Andreas Fecht <forum@aftec.de> - 2026-09-30 09:49 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 09:55 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:23 +0200
Re: random_rdtsc und random_rdrand Michael Schwingen <news-1513678000@discworld.dascon.de> - 2026-09-30 14:48 +0000
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 17:17 +0200
Re: random_rdtsc und random_rdrand Bernd Laengerich <Bernd.Laengerich@web.de> - 2026-09-30 09:59 +0200
Re: random_rdtsc und random_rdrand Eric Bruecklmeier <u@5i7.de> - 2026-09-30 09:13 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:07 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:03 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 16:58 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 17:33 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 18:34 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 18:12 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 18:25 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 19:16 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 18:45 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 19:25 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 20:10 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 20:49 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 20:55 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 20:55 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 23:32 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-01 00:50 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-01 18:35 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-01 18:58 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 06:29 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 16:02 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 16:11 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 22:00 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 22:02 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 22:09 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 22:20 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 23:11 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 23:51 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 11:57 +0200
Re: random_rdtsc und random_rdrand Marte Schwarz <marte.schwarz@gmx.de> - 2026-10-03 11:30 +0200
Re: random_rdtsc und random_rdrand Heinz Schmitz <sch@example.invalid> - 2026-10-03 16:59 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 17:29 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-03 13:33 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-02 16:19 +0200
Re: random_rdtsc und random_rdrand Christian Weisgerber <naddy@mips.inka.de> - 2026-10-02 19:24 +0000
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-02 22:04 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-03 14:49 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-03 15:21 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 17:26 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-03 17:35 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 00:48 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-04 00:52 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 01:33 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-04 02:04 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 11:48 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-04 11:56 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-04 03:41 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-04 03:50 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 12:20 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-04 12:46 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 17:39 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 01:33 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 12:48 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 17:12 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-03 17:47 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 00:59 +0200
Re: random_rdtsc und random_rdrand Kai-Martin Knaak <kaimartin@invalid.invalid> - 2026-10-04 22:49 +0000
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 12:32 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 01:36 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 12:52 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 13:24 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 14:30 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 15:50 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-05 18:51 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-05 19:39 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-05 21:40 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-05 14:58 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 21:49 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 15:52 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 18:46 +0200
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-10-04 03:41 +0200 |
| Message-ID | <87qzi6jljv.fsf@s-bot.de> |
| In reply to | #369699 |
Helmut Schellong <var@schellong.biz> writes: > Leo Baumann wrote on 03.10.2026 17:35: >> Am 03.10.2026 um 17:26 schrieb Helmut Schellong: >>>> Alle gelesenen TSC-Werte danach nicht. >>> >>> Doch, weil echt zufällige Verzögerungen durch das Programm randtsc.exe zu ebenso >>> echt zufälligen gelesenen Zahlen führen. >>> >>> Siehe den NIST-Test, der ein solches Lesen des TSC als überlegen gegenüber >>> den Instruktionen 'rdrand' und 'rdseed' erklärt. >> Der NIST-Test bestätigt *nicht* die Unvorhersehbarkeit und >> kryptografische Sicherheit und genau diese beiden sind bei >> random_rdtsc *nicht* gegeben. > > Der NIST-Test bestätigt sehr wohl die kryptographische Sicherheit. > Dafür ist er gemacht! > Er bestätigt _nicht_ die Unvorhersehbarkeit. > > Der Algorithmus des 'randtsc' bestätigt allerdings die Unvorhersehbarkeit, weil nur > ein kleiner Teil der Bits des TSC zur Nutzung verwendet werden. > Es kann auch nur das eine Bit ganz rechts verwendet werden, wenn man will (LSB). > Eines von 64. > Dieses Programm ist eine wahre Bit-Frickel-Stube. Wenn du einfach willkürlich Bits wegwirfst, geht auch der letzte Rest an Zufall abhanden. Weshalb sollte das LSB zufälliger sein als das vorletzte? Hast du dir mal angeschaut, wieviel Mühe im Linux-Kernel darauf verwendet wird, den kleinsten Rest an Entropie in den Pool hineinzumixen? (ChaCha20) Ich bezweifle, dass deine naive Implementation besser ist. Wenn auch nicht mehr brandaktuell: <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN_V5_14.pdf?__blob=publicationFile&v=2> -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-10-04 03:50 +0200 |
| Message-ID | <87jynyjl1j.fsf@s-bot.de> |
| In reply to | #369710 |
"Ingrid" Stefan Wiens <s.wi@gmx.net> writes: > Helmut Schellong <var@schellong.biz> writes: > >> Leo Baumann wrote on 03.10.2026 17:35: >>> Am 03.10.2026 um 17:26 schrieb Helmut Schellong: >>>>> Alle gelesenen TSC-Werte danach nicht. >>>> >>>> Doch, weil echt zufällige Verzögerungen durch das Programm randtsc.exe zu ebenso >>>> echt zufälligen gelesenen Zahlen führen. >>>> >>>> Siehe den NIST-Test, der ein solches Lesen des TSC als überlegen gegenüber >>>> den Instruktionen 'rdrand' und 'rdseed' erklärt. >>> Der NIST-Test bestätigt *nicht* die Unvorhersehbarkeit und >>> kryptografische Sicherheit und genau diese beiden sind bei >>> random_rdtsc *nicht* gegeben. >> >> Der NIST-Test bestätigt sehr wohl die kryptographische Sicherheit. >> Dafür ist er gemacht! >> Er bestätigt _nicht_ die Unvorhersehbarkeit. >> >> Der Algorithmus des 'randtsc' bestätigt allerdings die Unvorhersehbarkeit, weil nur >> ein kleiner Teil der Bits des TSC zur Nutzung verwendet werden. >> Es kann auch nur das eine Bit ganz rechts verwendet werden, wenn man will (LSB). >> Eines von 64. >> Dieses Programm ist eine wahre Bit-Frickel-Stube. > > Wenn du einfach willkürlich Bits wegwirfst, > geht auch der letzte Rest an Zufall abhanden. > > Weshalb sollte das LSB zufälliger sein als > das vorletzte? > > Hast du dir mal angeschaut, wieviel Mühe > im Linux-Kernel darauf verwendet wird, > den kleinsten Rest an Entropie in den > Pool hineinzumixen? (ChaCha20) > > Ich bezweifle, dass deine naive > Implementation besser ist. > > Wenn auch nicht mehr brandaktuell: > > <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN_V5_14.pdf?__blob=publicationFile&v=2> Der Linux-Kernel berücksichtigt z. T. auch höhere Ableitungen der Werte, und eine Quelle, die zu vorhersagbar ist, wird evtl. nicht weiter verwendet. Und das zur Laufzeit. Ähnlich läuft es ja auch bei rdrand, aber intransparent. -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-04 12:20 +0200 |
| Message-ID | <119t98e$sqh4$1@solani.org> |
| In reply to | #369710 |
Stefan Wiens wrote on 04.10.2026 03:41: > Helmut Schellong <var@schellong.biz> writes: > >> Leo Baumann wrote on 03.10.2026 17:35: >>> Am 03.10.2026 um 17:26 schrieb Helmut Schellong: >>>>> Alle gelesenen TSC-Werte danach nicht. >>>> >>>> Doch, weil echt zufällige Verzögerungen durch das Programm randtsc.exe zu ebenso >>>> echt zufälligen gelesenen Zahlen führen. >>>> >>>> Siehe den NIST-Test, der ein solches Lesen des TSC als überlegen gegenüber >>>> den Instruktionen 'rdrand' und 'rdseed' erklärt. >>> Der NIST-Test bestätigt *nicht* die Unvorhersehbarkeit und >>> kryptografische Sicherheit und genau diese beiden sind bei >>> random_rdtsc *nicht* gegeben. >> >> Der NIST-Test bestätigt sehr wohl die kryptographische Sicherheit. >> Dafür ist er gemacht! >> Er bestätigt _nicht_ die Unvorhersehbarkeit. >> >> Der Algorithmus des 'randtsc' bestätigt allerdings die Unvorhersehbarkeit, weil nur >> ein kleiner Teil der Bits des TSC zur Nutzung verwendet werden. >> Es kann auch nur das eine Bit ganz rechts verwendet werden, wenn man will (LSB). >> Eines von 64. >> Dieses Programm ist eine wahre Bit-Frickel-Stube. > > Wenn du einfach willkürlich Bits wegwirfst, > geht auch der letzte Rest an Zufall abhanden. Blödsinn, ich werfe nur Bits weg, die quasi Konstanten sind. Du siehst das einfach diametral falsch herum. Was soll ich mit Bits, die sich nur alle paar Stunden ändern? > Weshalb sollte das LSB zufälliger sein als > das vorletzte? Weil sich das LSB am schnellsten ändert. Noch nie einen mechanischen Zähler mit Radwalzen angeschaut? Von rechts nach links kommen da die Überträge. Das rechte Rad dreht sich am schnellsten. > Hast du dir mal angeschaut, wieviel Mühe > im Linux-Kernel darauf verwendet wird, > den kleinsten Rest an Entropie in den > Pool hineinzumixen? (ChaCha20) > > Ich bezweifle, dass deine naive > Implementation besser ist. Der NIST-Test bescheidet das aber so (besser als rdrand), mehrfach bisher. > Wenn auch nicht mehr brandaktuell: > > <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN_V5_14.pdf?__blob=publicationFile&v=2> -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-10-04 12:46 +0200 |
| Message-ID | <87ece5kazt.fsf@s-bot.de> |
| In reply to | #369720 |
Helmut Schellong <var@schellong.biz> writes: > Stefan Wiens wrote on 04.10.2026 03:41: >> Helmut Schellong <var@schellong.biz> writes: >> >>> Leo Baumann wrote on 03.10.2026 17:35: >>>> Am 03.10.2026 um 17:26 schrieb Helmut Schellong: >>>>>> Alle gelesenen TSC-Werte danach nicht. >>>>> >>>>> Doch, weil echt zufällige Verzögerungen durch das Programm randtsc.exe zu ebenso >>>>> echt zufälligen gelesenen Zahlen führen. >>>>> >>>>> Siehe den NIST-Test, der ein solches Lesen des TSC als überlegen gegenüber >>>>> den Instruktionen 'rdrand' und 'rdseed' erklärt. >>>> Der NIST-Test bestätigt *nicht* die Unvorhersehbarkeit und >>>> kryptografische Sicherheit und genau diese beiden sind bei >>>> random_rdtsc *nicht* gegeben. >>> >>> Der NIST-Test bestätigt sehr wohl die kryptographische Sicherheit. >>> Dafür ist er gemacht! >>> Er bestätigt _nicht_ die Unvorhersehbarkeit. >>> >>> Der Algorithmus des 'randtsc' bestätigt allerdings die Unvorhersehbarkeit, weil nur >>> ein kleiner Teil der Bits des TSC zur Nutzung verwendet werden. >>> Es kann auch nur das eine Bit ganz rechts verwendet werden, wenn man will (LSB). >>> Eines von 64. >>> Dieses Programm ist eine wahre Bit-Frickel-Stube. >> Wenn du einfach willkürlich Bits wegwirfst, >> geht auch der letzte Rest an Zufall abhanden. > > Blödsinn, ich werfe nur Bits weg, die quasi Konstanten sind. > Du siehst das einfach diametral falsch herum. > Was soll ich mit Bits, die sich nur alle paar Stunden ändern? > >> Weshalb sollte das LSB zufälliger sein als >> das vorletzte? > > Weil sich das LSB am schnellsten ändert. > Noch nie einen mechanischen Zähler mit Radwalzen angeschaut? > Von rechts nach links kommen da die Überträge. > Das rechte Rad dreht sich am schnellsten. > >> Hast du dir mal angeschaut, wieviel Mühe >> im Linux-Kernel darauf verwendet wird, >> den kleinsten Rest an Entropie in den >> Pool hineinzumixen? (ChaCha20) >> Ich bezweifle, dass deine naive >> Implementation besser ist. > > Der NIST-Test bescheidet das aber so (besser als rdrand), mehrfach bisher. Gleichverteilung bedeutet nicht Unvorhersagbarkeit. Da muss man z. B. auch auf Seitenkanalattacken achten. Pi ist vielleicht gar nicht so zufällig: Es gibr gar nicht so weit hinten eine Folge 99999. Und man kann jede Nachkommastelle berechnen ohne Kenntnis der Vorgänger: <https://de.wikipedia.org/wiki/Bailey-Borwein-Plouffe-Formel> -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-04 17:39 +0200 |
| Message-ID | <119true$qejj$1@solani.org> |
| In reply to | #369723 |
Stefan Wiens wrote on 04.10.2026 12:46: > Helmut Schellong <var@schellong.biz> writes: > >> Stefan Wiens wrote on 04.10.2026 03:41: >>> Helmut Schellong <var@schellong.biz> writes: >>> >>>> Leo Baumann wrote on 03.10.2026 17:35: >>>>> Am 03.10.2026 um 17:26 schrieb Helmut Schellong: >>>>>>> Alle gelesenen TSC-Werte danach nicht. >>>>>> >>>>>> Doch, weil echt zufällige Verzögerungen durch das Programm randtsc.exe zu ebenso >>>>>> echt zufälligen gelesenen Zahlen führen. >>>>>> >>>>>> Siehe den NIST-Test, der ein solches Lesen des TSC als überlegen gegenüber >>>>>> den Instruktionen 'rdrand' und 'rdseed' erklärt. >>>>> Der NIST-Test bestätigt *nicht* die Unvorhersehbarkeit und >>>>> kryptografische Sicherheit und genau diese beiden sind bei >>>>> random_rdtsc *nicht* gegeben. >>>> >>>> Der NIST-Test bestätigt sehr wohl die kryptographische Sicherheit. >>>> Dafür ist er gemacht! >>>> Er bestätigt _nicht_ die Unvorhersehbarkeit. >>>> >>>> Der Algorithmus des 'randtsc' bestätigt allerdings die Unvorhersehbarkeit, weil nur >>>> ein kleiner Teil der Bits des TSC zur Nutzung verwendet werden. >>>> Es kann auch nur das eine Bit ganz rechts verwendet werden, wenn man will (LSB). >>>> Eines von 64. >>>> Dieses Programm ist eine wahre Bit-Frickel-Stube. >>> Wenn du einfach willkürlich Bits wegwirfst, >>> geht auch der letzte Rest an Zufall abhanden. >> >> Blödsinn, ich werfe nur Bits weg, die quasi Konstanten sind. >> Du siehst das einfach diametral falsch herum. >> Was soll ich mit Bits, die sich nur alle paar Stunden ändern? >> >>> Weshalb sollte das LSB zufälliger sein als >>> das vorletzte? >> >> Weil sich das LSB am schnellsten ändert. >> Noch nie einen mechanischen Zähler mit Radwalzen angeschaut? >> Von rechts nach links kommen da die Überträge. >> Das rechte Rad dreht sich am schnellsten. >> >>> Hast du dir mal angeschaut, wieviel Mühe >>> im Linux-Kernel darauf verwendet wird, >>> den kleinsten Rest an Entropie in den >>> Pool hineinzumixen? (ChaCha20) >>> Ich bezweifle, dass deine naive >>> Implementation besser ist. >> >> Der NIST-Test bescheidet das aber so (besser als rdrand), mehrfach bisher. > > Gleichverteilung bedeutet nicht Unvorhersagbarkeit. > Da muss man z. B. auch auf Seitenkanalattacken achten. Richtig. Gleichverteilung ist der _erste_ der grundlegend verschiedenen 15 mathematischen Tests der NIST-Test-Suite. Insgesamt sind es 188 Tests pro Bitstrom. Das ist an der Abschlußtabelle zu sehen. Ich konfiguriere meist 5 Bitströme. Der NIST-Test: . http://www.schellong.de/pdf/NIST800-22r1a.pdf ist dafür entwickelt worden, um Bitströme für eine Eignung für kryptographische Anwendungen bewerten zu können. In der Abschlußtabelle des Tests sollte kein Stern * vor einen Test gesetzt worden sein. Dann ist der Test bestanden. . randtsc . BITSREAD = 1000000 0s = 499928 1s = 500072 . BITSREAD = 1000000 0s = 500154 1s = 499846 . BITSREAD = 1000000 0s = 500107 1s = 499893 . BITSREAD = 1000000 0s = 500010 1s = 499990 . BITSREAD = 1000000 0s = 500165 1s = 499835 . rdseed . BITSREAD = 1000000 0s = 501060 1s = 498940 . BITSREAD = 1000000 0s = 500800 1s = 499200 . BITSREAD = 1000000 0s = 498688 1s = 501312 . BITSREAD = 1000000 0s = 500219 1s = 499781 . BITSREAD = 1000000 0s = 499747 1s = 500253 Die hohe Güte der Zahlen des 'randtsc' ist allein vorstehend erkennbar. > Pi ist vielleicht gar nicht so zufällig: > Es gibr gar nicht so weit hinten eine Folge > 99999. Und man kann jede Nachkommastelle > berechnen ohne Kenntnis der Vorgänger: > <https://de.wikipedia.org/wiki/Bailey-Borwein-Plouffe-Formel> Das geht wohl wegen des Zusammenhangs von Durchmesser und Umfang. PI repräsentiert ja diesen Zusammenhang. Ich wäre wegen 99999 nicht beunruhigt. Bei echten Zufallszahlen ist 99999 genau so wahrscheinlich wie auch 12345, 54321, 55334, 88888, 00000, ... -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2026-10-05 01:33 +0200 |
| Message-ID | <119unov$c2op$4@dont-email.me> |
| In reply to | #369720 |
Helmut Schellong, 2026-10-04 12:20: > Stefan Wiens wrote on 04.10.2026 03:41: [...] >> Weshalb sollte das LSB zufälliger sein als >> das vorletzte? > > Weil sich das LSB am schnellsten ändert. > Noch nie einen mechanischen Zähler mit Radwalzen angeschaut? > Von rechts nach links kommen da die Überträge. > Das rechte Rad dreht sich am schnellsten. Und ebenso vorhersehbar, wie alle anderen. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-05 12:48 +0200 |
| Message-ID | <119vv94$uphc$2@solani.org> |
| In reply to | #369740 |
Arno Welzel wrote on 05.10.2026 01:33: > Helmut Schellong, 2026-10-04 12:20: > >> Stefan Wiens wrote on 04.10.2026 03:41: > > [...] > >>> Weshalb sollte das LSB zufälliger sein als >>> das vorletzte? >> >> Weil sich das LSB am schnellsten ändert. >> Noch nie einen mechanischen Zähler mit Radwalzen angeschaut? >> Von rechts nach links kommen da die Überträge. >> Das rechte Rad dreht sich am schnellsten. > > Und ebenso vorhersehbar, wie alle anderen. Isoliert betrachtet, ja. Im Zusammenhang mit anderen Algorithmen, nein. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-03 17:12 +0200 |
| Message-ID | <119r5vp$rbne$1@solani.org> |
| In reply to | #369686 |
Stefan Wiens wrote on 03.10.2026 14:49: > Stefan "Ingrid" Wiens <s.wi@gmx.net> writes: > >> Christian Weisgerber <naddy@mips.inka.de> writes: >> >>> On 2026-10-02, Stefan Wiens <s.wi@gmx.net> wrote: >>> >>>> Was ist zufällig an der Zeit seit dem Reset? >>> >>> Erstmal wäre zu prüfen, _ob_ das Ergebnis schwankt, dann kann man ggfs. >>> fragen _warum_. >>> >>> Ich habe vor einigen Jahren mal geschaut, was für einen initialen >>> TSC-Wert ein x86-BIOS-Bootloader ausliest, und die unteren Bits >>> haben tatsächlich wild gewechselt. Warum auch immer. Ein bisschen >>> Entropie scheint da schon drinzustecken. >> >> Der volle 64-Bit-Wertebereich nach dem Reset >> wird wohl kaum je erreicht, denn irgendwann steht >> ein Reboot an. >> >> Wieviel Entropie in den niedrigen Bits steckt, >> ist ebenso unklar. >> >> Und evtl. kann der TSC von einem anderen Core >> belauscht werden, das reduziert zwar nicht >> die Zufälligkeit, aber die kryptographische >> Sicherheit. > > So wie das aussieht, wird im Linux-Kernel > dem Ergebnis von rdtsc keinerlei Entropie > gutgeschrieben, es gibt wohl Ausnahmefälle > nach dem Booten, wo evtl. ein Bit > gutgeschrieben wird. Das ist irrelevant, weil hier _erneut_ eine völlig isolierte Betrachtung des TSC vorgenommen wird. Das ist schlicht dumm. > Das ist ein riesiger Unterschied zu der > naiven Implementierung, die hier vorgestellt > wurde. Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! Die NIST-Tests weisen 21-, 13- und 2-, 20-mal das Vorkommen des Worts FAILURE aus. Der Reihe nach für 'rdrand', 'rdseed', 'randtsc langsam', 'randtsc schnell'. Der Reihe nach: http://www.schellong.de/txt/nist4.txt http://www.schellong.de/txt/nist6.txt http://www.schellong.de/txt/nist1.txt http://www.schellong.de/txt/nist5.txt Der NIST-Test 800-22 mit 188 Tests ist relevant und beweiskräftig. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-10-03 17:47 +0200 |
| Message-ID | <119r831$rde6$1@solani.org> |
| In reply to | #369689 |
Am 03.10.2026 um 17:12 schrieb Helmut Schellong: > Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten > Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) liefert keine kryptografisch sicheren Zufallszahlen, weil es sich dabei um eine deterministische Zeitmessung und nicht um eine echte Entropiequelle handelt. Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im Prozessor basieren, misst RDTSC lediglich die Anzahl der CPU-Taktzyklen seit dem letzten Reset. -- Public Webspace von Ingenieurbüro Baumann: https://hidrive.ionos.com/share/sc0px3oy7x
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-04 00:59 +0200 |
| Message-ID | <119s1bv$rvja$1@solani.org> |
| In reply to | #369693 |
Leo Baumann wrote on 03.10.2026 17:47: > Am 03.10.2026 um 17:12 schrieb Helmut Schellong: >> Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten >> Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! > > random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) liefert keine kryptografisch sicheren Zufallszahlen, weil es sich > dabei um eine deterministische Zeitmessung und nicht um eine echte Entropiequelle handelt. Der NIST-Test bestätigt jedoch die kryptographische Sicherheit. Genau dafür ist er gemacht! > Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im Prozessor basieren, misst RDTSC lediglich die Anzahl der > CPU-Taktzyklen seit dem letzten Reset. Nein, das ist wiederholt komplett falsch. Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des 'randtsc' nicht gäbe. Du verhältst Dich mittlerweile ausgeprägt borniert. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Kai-Martin Knaak <kaimartin@invalid.invalid> |
|---|---|
| Date | 2026-10-04 22:49 +0000 |
| Message-ID | <119ul56$sk73$1@gwaiyur.mb-net.net> |
| In reply to | #369701 |
On Sun, 4 Oct 2026 00:59:25 +0200, Helmut Schellong wrote: > Leo Baumann wrote on 03.10.2026 17:47: >> Am 03.10.2026 um 17:12 schrieb Helmut Schellong: >>> Diese angeblich naive Implementation (randtsc) hat sich den >>> hochgelobten Instruktionen 'rdrand' und 'rdseed' als _überlegen_ >>> herausgestellt! >> >> random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) >> liefert keine kryptografisch sicheren Zufallszahlen, weil es sich dabei >> um eine deterministische Zeitmessung und nicht um eine echte >> Entropiequelle handelt. > > Der NIST-Test bestätigt jedoch die kryptographische Sicherheit. > Genau dafür ist er gemacht! > >> Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im >> Prozessor basieren, misst RDTSC lediglich die Anzahl der CPU-Taktzyklen >> seit dem letzten Reset. > > Nein, das ist wiederholt komplett falsch. > Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des > 'randtsc' nicht gäbe. Das ist legitim, weil kein Algorithmus die Entropie des Ergebnisses von RDTSC vermehren kann. Das ist ähnlich fundamental wie in der Physik die Tatsache, dass keine Vorrichtung den Impuls oder die Energie eines geschlossenen Systems verändern kann. > Du verhältst Dich mittlerweile ausgeprägt borniert. Ja, alles Geisterfahrer hier... ---<)kaimartin(>---
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-05 12:32 +0200 |
| Message-ID | <119vubs$uoup$1@solani.org> |
| In reply to | #369736 |
Kai-Martin Knaak wrote on 05.10.2026 00:49: > On Sun, 4 Oct 2026 00:59:25 +0200, Helmut Schellong wrote: > >> Leo Baumann wrote on 03.10.2026 17:47: >>> Am 03.10.2026 um 17:12 schrieb Helmut Schellong: >>>> Diese angeblich naive Implementation (randtsc) hat sich den >>>> hochgelobten Instruktionen 'rdrand' und 'rdseed' als _überlegen_ >>>> herausgestellt! >>> >>> random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) >>> liefert keine kryptografisch sicheren Zufallszahlen, weil es sich dabei >>> um eine deterministische Zeitmessung und nicht um eine echte >>> Entropiequelle handelt. >> >> Der NIST-Test bestätigt jedoch die kryptographische Sicherheit. >> Genau dafür ist er gemacht! >> >>> Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im >>> Prozessor basieren, misst RDTSC lediglich die Anzahl der CPU-Taktzyklen >>> seit dem letzten Reset. >> >> Nein, das ist wiederholt komplett falsch. >> Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des >> 'randtsc' nicht gäbe. > > Das ist legitim, weil kein Algorithmus die Entropie des Ergebnisses von > RDTSC vermehren kann. Das ist richtig, aber abermals wird hier der TSC isoliert betrachtet. Ein Algorithmus wie 'randtsc' kann die Entropie seiner Ausgabe erhöhen. Diese Ausgabe basiert auf einem sehr kleinen Teil der Werte des TSC. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2026-10-05 01:36 +0200 |
| Message-ID | <119unt6$c2op$5@dont-email.me> |
| In reply to | #369701 |
Helmut Schellong, 2026-10-04 00:59: > Leo Baumann wrote on 03.10.2026 17:47: >> Am 03.10.2026 um 17:12 schrieb Helmut Schellong: >>> Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten >>> Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! >> >> random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) liefert keine kryptografisch sicheren Zufallszahlen, weil es sich >> dabei um eine deterministische Zeitmessung und nicht um eine echte Entropiequelle handelt. > > Der NIST-Test bestätigt jedoch die kryptographische Sicherheit. > Genau dafür ist er gemacht! > >> Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im Prozessor basieren, misst RDTSC lediglich die Anzahl der >> CPU-Taktzyklen seit dem letzten Reset. > > Nein, das ist wiederholt komplett falsch. > Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des 'randtsc' nicht gäbe. Den gibt es ja auch nicht. Den Quelltext zeigst Du nicht, weil den hier angeblich niemand versteht. Das ist einfach nur lächerlich. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-05 12:52 +0200 |
| Message-ID | <119vvg7$uphc$3@solani.org> |
| In reply to | #369741 |
Arno Welzel wrote on 05.10.2026 01:36: > Helmut Schellong, 2026-10-04 00:59: > >> Leo Baumann wrote on 03.10.2026 17:47: >>> Am 03.10.2026 um 17:12 schrieb Helmut Schellong: >>>> Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten >>>> Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! >>> >>> random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) liefert keine kryptografisch sicheren Zufallszahlen, weil es sich >>> dabei um eine deterministische Zeitmessung und nicht um eine echte Entropiequelle handelt. >> >> Der NIST-Test bestätigt jedoch die kryptographische Sicherheit. >> Genau dafür ist er gemacht! >> >>> Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im Prozessor basieren, misst RDTSC lediglich die Anzahl der >>> CPU-Taktzyklen seit dem letzten Reset. >> >> Nein, das ist wiederholt komplett falsch. >> Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des 'randtsc' nicht gäbe. > > Den gibt es ja auch nicht. Den Quelltext zeigst Du nicht, weil den hier > angeblich niemand versteht. Das ist einfach nur lächerlich. Die Ausgabe der randtsc.exe beweist das aber per NIST-Tests. Das reicht mir. Hier in der NG wurde festgehalten, daß mein Quellcode unlesbar sei. Reicht das nun? -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2026-10-05 13:24 +0200 |
| Message-ID | <11a01dn$skcv$3@dont-email.me> |
| In reply to | #369752 |
Helmut Schellong, 2026-10-05 12:52: > Arno Welzel wrote on 05.10.2026 01:36: >> Helmut Schellong, 2026-10-04 00:59: >> >>> Leo Baumann wrote on 03.10.2026 17:47: >>>> Am 03.10.2026 um 17:12 schrieb Helmut Schellong: >>>>> Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten >>>>> Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! >>>> >>>> random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) liefert keine kryptografisch sicheren Zufallszahlen, weil es sich >>>> dabei um eine deterministische Zeitmessung und nicht um eine echte Entropiequelle handelt. >>> >>> Der NIST-Test bestätigt jedoch die kryptographische Sicherheit. >>> Genau dafür ist er gemacht! >>> >>>> Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im Prozessor basieren, misst RDTSC lediglich die Anzahl der >>>> CPU-Taktzyklen seit dem letzten Reset. >>> >>> Nein, das ist wiederholt komplett falsch. >>> Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des 'randtsc' nicht gäbe. >> >> Den gibt es ja auch nicht. Den Quelltext zeigst Du nicht, weil den hier >> angeblich niemand versteht. Das ist einfach nur lächerlich. > > Die Ausgabe der randtsc.exe beweist das aber per NIST-Tests. > Das reicht mir. > > Hier in der NG wurde festgehalten, daß mein Quellcode unlesbar sei. Ich habe den Quellcode noch nie gesehen. > Reicht das nun? Nein. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-05 14:30 +0200 |
| Message-ID | <11a058j$utvq$2@solani.org> |
| In reply to | #369758 |
Arno Welzel wrote on 05.10.2026 13:24: > Helmut Schellong, 2026-10-05 12:52: > >> Arno Welzel wrote on 05.10.2026 01:36: >>> Helmut Schellong, 2026-10-04 00:59: >>> >>>> Leo Baumann wrote on 03.10.2026 17:47: >>>>> Am 03.10.2026 um 17:12 schrieb Helmut Schellong: >>>>>> Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten >>>>>> Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! >>>>> >>>>> random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) liefert keine kryptografisch sicheren Zufallszahlen, weil es sich >>>>> dabei um eine deterministische Zeitmessung und nicht um eine echte Entropiequelle handelt. >>>> >>>> Der NIST-Test bestätigt jedoch die kryptographische Sicherheit. >>>> Genau dafür ist er gemacht! >>>> >>>>> Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im Prozessor basieren, misst RDTSC lediglich die Anzahl der >>>>> CPU-Taktzyklen seit dem letzten Reset. >>>> >>>> Nein, das ist wiederholt komplett falsch. >>>> Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des 'randtsc' nicht gäbe. >>> >>> Den gibt es ja auch nicht. Den Quelltext zeigst Du nicht, weil den hier >>> angeblich niemand versteht. Das ist einfach nur lächerlich. >> >> Die Ausgabe der randtsc.exe beweist das aber per NIST-Tests. >> Das reicht mir. >> >> Hier in der NG wurde festgehalten, daß mein Quellcode unlesbar sei. > > Ich habe den Quellcode noch nie gesehen. > >> Reicht das nun? > > Nein. Warum sollte ich Quellcode posten, der unlesbar ist? -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2026-10-05 15:50 +0200 |
| Message-ID | <11a09ud$1029r$2@dont-email.me> |
| In reply to | #369764 |
Helmut Schellong, 2026-10-05 14:30: [...]> Warum sollte ich Quellcode posten, der unlesbar ist? Weil es gängige Praxis ist, dass der Quellcode für sicherheitsrelevante Software öffentlich oder mindestens auf Anfrage zugänglich ist. Aber da Du "bish" ja auch als Firmengeheimnis betrachtest, kannst Du es auch einfach sein lassen, hier generell über irgendwas von Dir zu berichten. Das erspart Dir dann auch lästige Nachfragen. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-05 18:51 +0200 |
| Message-ID | <11a0kgu$vapj$1@solani.org> |
| In reply to | #369774 |
Arno Welzel wrote on 05.10.2026 15:50: > Helmut Schellong, 2026-10-05 14:30: > > [...]> Warum sollte ich Quellcode posten, der unlesbar ist? > > Weil es gängige Praxis ist, dass der Quellcode für sicherheitsrelevante > Software öffentlich oder mindestens auf Anfrage zugänglich ist. Sicherheitsrelevanz zieht hier nicht, da die Ausgabe untersucht werden konnte. Der NIST-Test ist hier ausdrücklich relevant, weil er die Eignung für kryptographische Anwendungen bescheidet. Hab ich das bereits paar Mal genannt, oder so ähnlich? > Aber da Du "bish" ja auch als Firmengeheimnis betrachtest, kannst Du es > auch einfach sein lassen, hier generell über irgendwas von Dir zu > berichten. Das erspart Dir dann auch lästige Nachfragen. Es gibt Gründe dafür, warum ich das als Privatgeheimnis einstufe. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-10-05 19:39 +0200 |
| Message-ID | <8733ukjbsu.fsf@s-bot.de> |
| In reply to | #369781 |
Helmut Schellong <var@schellong.biz> writes: > Arno Welzel wrote on 05.10.2026 15:50: >> Helmut Schellong, 2026-10-05 14:30: >> [...]> Warum sollte ich Quellcode posten, der unlesbar ist? >> Weil es gängige Praxis ist, dass der Quellcode für >> sicherheitsrelevante >> Software öffentlich oder mindestens auf Anfrage zugänglich ist. > > Sicherheitsrelevanz zieht hier nicht, da die Ausgabe untersucht werden konnte. > Der NIST-Test ist hier ausdrücklich relevant, weil er die Eignung für > kryptographische Anwendungen bescheidet. > Hab ich das bereits paar Mal genannt, oder so ähnlich? ,----[ <https://csrc.nist.gov/news/2022/decision-to-revise-nist-sp-800-22-rev-1a> ] | | Decision to Revise NIST SP 800-22 Rev. 1a | April 19, 2022 | | In August 2021, NIST's Crypto Publication Review Board initiated a | review process for NIST Special Publication (SP) 800-22 Rev. 1a, A | Statistical Test Suite for Random and Pseudorandom Number Generators | for Cryptographic Applications. | | In January 2022, NIST proposed revising SP 800-22 Rev. 1a, in response | to the public comments received. Later, NIST received additional | comments on the proposed decision. | | NIST has decided to revise SP 800-22 Rev. 1a, to | | 1. clarify the purpose and use of the statistical test suite, | in particular rejecting its use for assessing cryptographic random ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | number generators; ^^^^^^^^^^^^^^^^^ `---- Dieser Test ist ungeeignet dafür, die Brauchbarkeit eines selbstgestrickten Zufallsgenerators zu "beweisen". Der ist nur dafür geeignet, grobe Implementationsfehler in anderweitig für gut befundenen Algorithmen aufzuzeigen. Deiner dürfte wohl kaum in die Klasse fallen. -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-10-05 21:40 +0200 |
| Message-ID | <slrn11c7v8o.drc.als@mordor.angband.thangorodrim.de> |
| In reply to | #369786 |
Stefan Wiens <s.wi@gmx.net> wrote:
> Helmut Schellong <var@schellong.biz> writes:
>
>> Arno Welzel wrote on 05.10.2026 15:50:
>>> Helmut Schellong, 2026-10-05 14:30:
>>> [...]> Warum sollte ich Quellcode posten, der unlesbar ist?
>>> Weil es gängige Praxis ist, dass der Quellcode für
>>> sicherheitsrelevante
>>> Software öffentlich oder mindestens auf Anfrage zugänglich ist.
>>
>> Sicherheitsrelevanz zieht hier nicht, da die Ausgabe untersucht werden konnte.
>> Der NIST-Test ist hier ausdrücklich relevant, weil er die Eignung für
>> kryptographische Anwendungen bescheidet.
>> Hab ich das bereits paar Mal genannt, oder so ähnlich?
>
> ,----[ <https://csrc.nist.gov/news/2022/decision-to-revise-nist-sp-800-22-rev-1a> ]
>|
>| Decision to Revise NIST SP 800-22 Rev. 1a
>| April 19, 2022
>|
>| In August 2021, NIST's Crypto Publication Review Board initiated a
>| review process for NIST Special Publication (SP) 800-22 Rev. 1a, A
>| Statistical Test Suite for Random and Pseudorandom Number Generators
>| for Cryptographic Applications.
>
>|
>| In January 2022, NIST proposed revising SP 800-22 Rev. 1a, in response
>| to the public comments received. Later, NIST received additional
>| comments on the proposed decision.
>
>|
>| NIST has decided to revise SP 800-22 Rev. 1a, to
>|
>| 1. clarify the purpose and use of the statistical test suite,
>| in particular rejecting its use for assessing cryptographic random
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>| number generators;
> ^^^^^^^^^^^^^^^^^
> `----
>
> Dieser Test ist ungeeignet dafür, die Brauchbarkeit eines
> selbstgestrickten Zufallsgenerators zu "beweisen".
>
> Der ist nur dafür geeignet, grobe Implementationsfehler
> in anderweitig für gut befundenen Algorithmen aufzuzeigen.
> Deiner dürfte wohl kaum in die Klasse fallen.
Also jetzt stör doch den Meister Schellong hier nicht bei seinen
überragenden Ideen indem Du einfach nervige Fakten anschleppst,
das ist ja unfair, sowas.
SCNR,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | de.sci.electronics
csiph-web