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 83 — 13 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 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-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 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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-10-02 16:19 +0200 |
| Message-ID | <87v77kkx02.fsf@s-bot.de> |
| In reply to | #369671 |
Helmut Schellong <var@schellong.biz> writes: > Leo Baumann wrote on 02.10.2026 06:29: >> Am 01.10.2026 um 18:35 schrieb Helmut Schellong: >>> Das Zauberwort in der Beschreibung oben ist 'Steuerungszwecke'. >>> >>> . sleep( D_bitmask & tsc ); >> Die Anweisung erzeugt keine Entropie! > > Doch, weil die Werte vom TSC zufällig sind und weil die Wirkungen > der unterlegten externen HW+SW permanent wirken. Was ist zufällig an der Zeit seit dem Reset? Aber du hast auch belegt, dass du mit echten Zufallszahlen nichts sinnvolles anfangen kannst, wenn du sie mehrfach verwendest. -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Christian Weisgerber <naddy@mips.inka.de> |
|---|---|
| Date | 2026-10-02 19:24 +0000 |
| Message-ID | <slrn11c017r.2m5v.naddy@lorvorc.mips.inka.de> |
| In reply to | #369673 |
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. Hintergrund war, dass der OpenBSD-Bootloader schon Zufälligkeit einsammelt, um sie dem Kernel mit auf den Weg zu geben, falls verfügbar: - ein Block Zufallszahlen, der geschrieben wurde, als das System zum letzten Mal lief¹; - von der Firmware, UEFI bietet sowas; - auf x86 von RDSEED, RDRAND und auch RDTSC. ¹) Beim Booten über TFTP fragt er das auch vom TFTP-Server ab und der OpenBSD tftpd(8) liefert auf jede solche Abfrage einen frischen Block Zufallszahlen. -- Christian "naddy" Weisgerber naddy@mips.inka.de
[toc] | [prev] | [next] | [standalone]
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-10-02 22:04 +0200 |
| Message-ID | <87jynzlvty.fsf@s-bot.de> |
| In reply to | #369674 |
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. -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-10-03 14:49 +0200 |
| Message-ID | <878q4fkl66.fsf@s-bot.de> |
| In reply to | #369678 |
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 ein riesiger Unterschied zu der naiven Implementierung, die hier vorgestellt wurde. -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-10-03 15:21 +0200 |
| Message-ID | <119qvgr$r6sg$1@solani.org> |
| In reply to | #369686 |
Am 03.10.2026 um 14:49 schrieb Stefan Wiens: > Was ist zufällig an der Zeit seit dem Reset? Der erste gelesene TSC-Wert nach dem Einschalten des Computers (zufälliger Tastendruck im Raum-Zeit-Kontinuum) ist eine echte Zufallszahl. Alle gelesenen TSC-Werte danach nicht. -- 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-03 17:26 +0200 |
| Message-ID | <119r6re$rcdv$1@solani.org> |
| In reply to | #369687 |
Leo Baumann wrote on 03.10.2026 15:21: > Am 03.10.2026 um 14:49 schrieb Stefan Wiens: >> Was ist zufällig an der Zeit seit dem Reset? > > Der erste gelesene TSC-Wert nach dem Einschalten des Computers (zufälliger Tastendruck im Raum-Zeit-Kontinuum) ist eine echte > Zufallszahl. Das stimmt, reicht aber nicht aus. Jedes Starten durch eine Taste, eines den TSC lesenden Programms, liefert eine echte Zufallszahl. > 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. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-10-03 17:35 +0200 |
| Message-ID | <119r7cv$rclr$1@solani.org> |
| In reply to | #369690 |
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. -- 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:48 +0200 |
| Message-ID | <119s0n7$rv7e$1@solani.org> |
| In reply to | #369692 |
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. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-10-04 00:52 +0200 |
| Message-ID | <119s0vd$p5cp$1@solani.org> |
| In reply to | #369699 |
Am 04.10.2026 um 00:48 schrieb Helmut Schellong: > 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. Wie bereits mehrfach geschrieben kann der NIST-Test weder Unvorhersagbarkeit noch Entropie bestätigen! • Was der NIST-Test nicht kann: Er kann nicht erkennen, ob eine Zahlenfolge vorhersagbar ist. Wenn Sie beispielsweise die Nachkommastellen der Zahl Pi in Binärcode umwandeln und testen, wird diese Sequenz die NIST-Tests problemlos bestehen, obwohl sie absolut deterministisch und unelastisch vorhersagbar ist. • Kryptografische Sicherheit: Ein Generator ist erst dann sicher, wenn er sowohl den statistischen NIST-Test (SP 800-22) besteht als auch eine nachweisbar unvorhersagbare Entropiequelle (SP 800-90B) nutzt. NIST SP 800-90B: Diese Norm regelt die Anforderungen an die eigentliche Entropiequelle (z. B. Hardware-Rauschen), um echte physikalische Unvorhersagbarkeit mathematisch nachzuweisen. -- 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 01:33 +0200 |
| Message-ID | <119s3c0$s0uj$1@solani.org> |
| In reply to | #369700 |
Leo Baumann wrote on 04.10.2026 00:52: > Am 04.10.2026 um 00:48 schrieb Helmut Schellong: >> 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. > > Wie bereits mehrfach geschrieben kann der NIST-Test weder Unvorhersagbarkeit noch Entropie bestätigen! Richtig, ich selbst habe diese Fähigkeit dem NIST-Test abgesprochen. Sogar vorstehend in diesem Posting. Der NIST-Test bestätigt jedoch die informationstheoretische Entropie nach Shannon. > • Was der NIST-Test nicht kann: Er kann nicht erkennen, ob eine Zahlenfolge vorhersagbar ist. Wenn Sie beispielsweise die > Nachkommastellen der Zahl Pi in Binärcode umwandeln und testen, wird diese Sequenz die NIST-Tests problemlos bestehen, obwohl sie > absolut deterministisch und unelastisch vorhersagbar ist. Ja, das hatten wir bereits. > • Kryptografische Sicherheit: Ein Generator ist erst dann sicher, wenn er sowohl den statistischen NIST-Test (SP 800-22) besteht als > auch eine nachweisbar unvorhersagbare Entropiequelle (SP 800-90B) nutzt. Die vorstehende Formulierung paßt nicht. Echter Zufall liegt z.B. unzweifelhaft auch bei allen Lotto-Maschinen vor, die in der ARD und im ZDF gezeigt wurden. Auch ein Taster muß nicht prellen, um sicher zu sein, denn die menschliche körperliche Langsamkeit allein erzeugt bereits den echten Zufall. Es gibt hier verschrobene Vorstellungen. > NIST SP 800-90B: Diese Norm regelt die Anforderungen an die eigentliche Entropiequelle (z. B. Hardware-Rauschen), um echte > physikalische Unvorhersagbarkeit mathematisch nachzuweisen. Ist mir bekannt. Ich bin mit dem NIST stark verbunden seit längerer Zeit. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-10-04 02:04 +0200 |
| Message-ID | <119s56q$p7vo$1@solani.org> |
| In reply to | #369703 |
Am 04.10.2026 um 01:33 schrieb Helmut Schellong: > Der NIST-Test bestätigt jedoch die informationstheoretische Entropie > nach Shannon. Warum die Shannon-Entropie unzureichend ist 1. Sie ist ein statistischer Mittelwert: Die Shannon-Entropie erlaubt es, dass einzelne Sequenzen extrem vorhersagbar sind, solange die Quelle im Durchschnitt unvorhersagbar bleibt. Für eine echte Zufallszahl darf jedoch kein einziges Bit vorhersagbar sein. 2. Kein Schutz vor gezielten Raten (Brute-Force): Wenn ein Angreifer versucht, einen kryptografischen Schlüssel zu erraten, nutzt er die wahrscheinlichste Kombination zuerst. Die Shannon-Entropie gewichtet seltene Ereignisse sehr stark, was den Durchschnittswert künstlich hochtreibt. Ein Angreifer interessiert sich aber nur für die wahrscheinlichsten Werte. -- 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 11:48 +0200 |
| Message-ID | <119t7d8$sp5k$1@solani.org> |
| In reply to | #369704 |
Leo Baumann wrote on 04.10.2026 02:04: > Am 04.10.2026 um 01:33 schrieb Helmut Schellong: >> Der NIST-Test bestätigt jedoch die informationstheoretische Entropie nach Shannon. > > Warum die Shannon-Entropie unzureichend ist > > 1. Sie ist ein statistischer Mittelwert: Die Shannon-Entropie erlaubt es, dass einzelne Sequenzen extrem vorhersagbar sind, solange > die Quelle im Durchschnitt unvorhersagbar bleibt. Für eine echte Zufallszahl darf jedoch kein einziges Bit vorhersagbar sein. > > 2. Kein Schutz vor gezielten Raten (Brute-Force): Wenn ein Angreifer versucht, einen kryptografischen Schlüssel zu erraten, nutzt er > die wahrscheinlichste Kombination zuerst. Die Shannon-Entropie gewichtet seltene Ereignisse sehr stark, was den Durchschnittswert > künstlich hochtreibt. Ein Angreifer interessiert sich aber nur für die wahrscheinlichsten Werte. Die Shannon-Entropie sagt nichts über physikalische Erzeugung aus. Deshalb auch 'informationstheoretisch'. Shannon verlangt eine Gleichverteilung aller Zeichen in einem OTP. Dadurch ist der Informationsgehalt Null. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-10-04 11:56 +0200 |
| Message-ID | <119t7s7$pv26$1@solani.org> |
| In reply to | #369713 |
Am 04.10.2026 um 11:48 schrieb Helmut Schellong: > Leo Baumann wrote on 04.10.2026 02:04: >> Am 04.10.2026 um 01:33 schrieb Helmut Schellong: >>> Der NIST-Test bestätigt jedoch die informationstheoretische Entropie >>> nach Shannon. >> >> Warum die Shannon-Entropie unzureichend ist >> >> 1. Sie ist ein statistischer Mittelwert: Die Shannon-Entropie erlaubt >> es, dass einzelne Sequenzen extrem vorhersagbar sind, solange die >> Quelle im Durchschnitt unvorhersagbar bleibt. Für eine echte >> Zufallszahl darf jedoch kein einziges Bit vorhersagbar sein. >> >> 2. Kein Schutz vor gezielten Raten (Brute-Force): Wenn ein Angreifer >> versucht, einen kryptografischen Schlüssel zu erraten, nutzt er die >> wahrscheinlichste Kombination zuerst. Die Shannon-Entropie gewichtet >> seltene Ereignisse sehr stark, was den Durchschnittswert künstlich >> hochtreibt. Ein Angreifer interessiert sich aber nur für die >> wahrscheinlichsten Werte. > > Die Shannon-Entropie sagt nichts über physikalische Erzeugung aus. > Deshalb auch 'informationstheoretisch'. > Shannon verlangt eine Gleichverteilung aller Zeichen in einem OTP. > Dadurch ist der Informationsgehalt Null. Dank KI ist alles gesagt - für mich ist random_rdtsc gestorben! -- Public Webspace von Ingenieurbüro Baumann: https://hidrive.ionos.com/share/sc0px3oy7x
[toc] | [prev] | [next] | [standalone]
| 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-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]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | de.sci.electronics
csiph-web