Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #369476 > unrolled thread

Echter Zufall mit iTSC-counter

Started byHelmut Schellong <var@schellong.biz>
First post2026-09-19 01:59 +0200
Last post2026-10-04 15:01 +0200
Articles 20 on this page of 91 — 16 participants

Back to article view | Back to de.sci.electronics

Contents

  Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-19 01:59 +0200
    Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-09-19 04:32 +0200
      Re: Echter Zufall mit iTSC-counter Stefan Wiens <s.wi@gmx.net> - 2026-09-19 08:31 +0200
        Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-09-21 18:43 +0200
          Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-21 20:26 +0200
            Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-09-21 20:33 +0200
              Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-21 21:49 +0200
                Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-09-21 21:56 +0200
                  Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-21 22:07 +0200
                    Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-09-22 01:35 +0200
                      Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-22 14:35 +0200
                        Re: Echter Zufall mit iTSC-counter Marte Schwarz <marte.schwarz@gmx.de> - 2026-09-22 17:00 +0200
                          Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-22 18:04 +0200
                          Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-23 23:22 +0200
                            Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-24 20:51 +0200
                              Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-25 15:37 +0200
                                Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-25 23:13 +0200
                                  Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Leo Baumann <ib@leobaumann.de> - 2026-09-26 04:20 +0200
                                    Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-26 15:49 +0200
                                      Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-26 17:06 +0200
                                        Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Andreas Fecht <forum@aftec.de> - 2026-09-26 19:14 +0200
                                        Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Christian Weisgerber <naddy@mips.inka.de> - 2026-09-26 16:38 +0000
                                          Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-27 02:07 +0200
                                            Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-27 12:47 +0200
                                      Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Stefan Wiens <s.wi@gmx.net> - 2026-09-27 13:50 +0200
                                        Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-27 20:24 +0200
                                          Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-27 21:02 +0200
                                          Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-28 20:42 +0200
                                  Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Leo Baumann <ib@leobaumann.de> - 2026-09-26 04:54 +0200
                                    Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-26 16:22 +0200
                                      Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Leo Baumann <ib@leobaumann.de> - 2026-09-26 16:29 +0200
                                        Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Helmut Schellong <var@schellong.biz> - 2026-09-26 16:35 +0200
                                          Re: Echter Zufall mit iTSC-counter - Bericht und Beweis Leo Baumann <ib@leobaumann.de> - 2026-09-26 16:38 +0200
                Re: Echter Zufall mit iTSC-counter Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-22 10:11 +0200
                  Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-22 15:04 +0200
                    Re: Echter Zufall mit iTSC-counter Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-22 17:59 +0200
                      Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-22 19:38 +0200
            Re: Echter Zufall mit iTSC-counter Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-21 21:31 +0200
              Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-22 15:22 +0200
                Re: Echter Zufall mit iTSC-counter Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-22 17:25 +0200
                  Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-22 18:32 +0200
                    Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-09-22 18:41 +0200
                      Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-22 19:48 +0200
                        Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-09-22 19:53 +0200
                          Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-22 22:52 +0200
                Re: Echter Zufall mit iTSC-counter Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-24 09:49 +0200
                  Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-24 12:57 +0200
                  Re: Echter Zufall mit iTSC-counter Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> - 2026-09-25 01:52 +0200
                    Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-25 14:58 +0200
                    Re: Echter Zufall mit iTSC-counter Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-26 09:24 +0200
        Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-09-21 20:01 +0200
      Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-19 13:54 +0200
        Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-09-19 16:03 +0200
          Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-19 20:41 +0200
            Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-09-19 22:02 +0200
            Re: Echter Zufall mit RDRAND Leo Baumann <ib@leobaumann.de> - 2026-09-20 03:29 +0200
              Re: Echter Zufall mit RDRAND Helmut Schellong <var@schellong.biz> - 2026-09-20 11:52 +0200
              Re: Echter Zufall mit RDRAND Leo Baumann <ib@leobaumann.de> - 2026-09-20 17:59 +0200
              Re: Echter Zufall mit RDRAND Michael Schwingen <news-1513678000@discworld.dascon.de> - 2026-09-21 19:01 +0000
                Re: Echter Zufall mit RDRAND Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-24 09:16 +0200
            Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-20 12:06 +0200
              Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-20 21:45 +0200
                Re: Echter Zufall mit iTSC-counter Marte Schwarz <marte.schwarz@gmx.de> - 2026-09-20 22:38 +0200
                  Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-20 23:03 +0200
                    Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-21 21:10 +0200
                      Re: Echter Zufall mit iTSC-counter Stefan Wiens <s.wi@gmx.net> - 2026-09-21 21:18 +0200
                Re: Echter Zufall mit iTSC-counter Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-21 12:02 +0200
                  Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-21 12:57 +0200
    Re: Echter Zufall mit iTSC-counter Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-19 08:59 +0200
      Re: Echter Zufall mit iTSC-counter Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-19 09:53 +0200
        Re: Echter Zufall mit iTSC-counter Eric Bruecklmeier <u@5i7.de> - 2026-09-19 13:45 +0200
          Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-19 14:36 +0200
          Re: Echter Zufall mit iTSC-counter Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-20 09:37 +0200
      Re: Echter Zufall mit iTSC-counter Peter Thoms <dl6lat@darc.de> - 2026-09-19 12:13 +0200
      Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-19 14:11 +0200
    Re: Echter Zufall mit iTSC-counter Ralph Aichinger <ra@h5.or.at> - 2026-09-19 08:26 +0000
      Re: Echter Zufall mit iTSC-counter Bernd Laengerich <Bernd.Laengerich@web.de> - 2026-09-19 12:00 +0200
      Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-19 14:33 +0200
        Re: Echter Zufall mit iTSC-counter Andreas Fecht <forum@aftec.de> - 2026-09-19 20:42 +0200
    Re: Echter Zufall mit iTSC-counter Arno Welzel <usenet@arnowelzel.de> - 2026-09-26 13:12 +0200
      Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-26 16:19 +0200
        Re: Echter Zufall mit iTSC-counter Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-26 17:47 +0200
          Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-09-26 18:39 +0200
        Re: Echter Zufall mit iTSC-counter Arno Welzel <usenet@arnowelzel.de> - 2026-10-03 22:59 +0200
          Re: Echter Zufall mit iTSC-counter Leo Baumann <ib@leobaumann.de> - 2026-10-03 23:08 +0200
          Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-10-04 01:09 +0200
            Re: Echter Zufall mit iTSC-counter Arno Welzel <usenet@arnowelzel.de> - 2026-10-04 02:57 +0200
              Re: Echter Zufall mit iTSC-counter Stefan Wiens <s.wi@gmx.net> - 2026-10-04 03:25 +0200
              Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-10-04 12:02 +0200
                Re: Echter Zufall mit iTSC-counter Helmut Schellong <var@schellong.biz> - 2026-10-04 12:07 +0200
                  Re: Echter Zufall mit iTSC-counter Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-04 15:01 +0200

Page 1 of 5  [1] 2 3 4 5  Next page →

#369476 — Echter Zufall mit iTSC-counter

FromHelmut Schellong <var@schellong.biz>
Date2026-09-19 01:59 +0200
SubjectEchter Zufall mit iTSC-counter
Message-ID<118kj9q$gqv2$1@solani.org>
Mittels einer Assembler-Funktion rdtsc(), die ich schon lange besitze, habe
ich nun einen Generator für echte Zufallszahlen entwickelt.

http://www.schellong.de/htm/randtsc.c.html

Ausgabe:
===========================================================================
         00000276457408345376
         00000276457428358754
         00000276457431266902
         00000276457435366459
         00000276457448473547
         00000276457451206089
         00000276457454226781
         00000276457457223742
         00000276457460060553
         00000276457474314196
         00000276457477764702
         00000276457485946076
         00000276457489986581
         00000276457500216563
         00000276457560363833
         00000276457566068760
         00000276457571709045
         00000276457594841516
         00000276457618375542
         00000276457628372033
         00000276457634496509
         00000276457641473652
         00000276457662760413
         00000276457667772505
===========================================================================

In Prozessoren amd64 befindet sich ein 64-bit-Counter, der von einer Taktfrequenz
im Giga-Hertz-Bereich angetrieben wird.
Der verändert sich durch die Zeitdauer von nur einem Funktionsaufruf bereits
um Millionen in seinem Zählerstand.

Mindestens die 4/5 Ziffern von rechts können als random verwendet werden.
Oft sind bereits 1- bis 2-stellige Zahlen in geringerer Anzahl nützlich.

Das Kommando nimmt ein Argument entgegen:  Die Anzahl von ausgegebenen Zahlen.
Voreingestellt ist die Anzahl 8.


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [next] | [standalone]

#369478

FromLeo Baumann <ib@leobaumann.de>
Date2026-09-19 04:32 +0200
Message-ID<118ks8h$elv8$1@solani.org>
In reply to#369476
Am 19.09.2026 um 01:59 schrieb Helmut Schellong:
> Mittels einer Assembler-Funktion rdtsc(), die ich schon lange besitze, habe
> ich nun einen Generator für echte Zufallszahlen entwickelt.
> 
> http://www.schellong.de/htm/randtsc.c.html
> 
> Ausgabe:
> ===========================================================================
>          00000276457408345376
>          00000276457428358754
>          00000276457431266902
>          00000276457435366459
>          00000276457448473547
>          00000276457451206089
>          00000276457454226781
>          00000276457457223742
>          00000276457460060553
>          00000276457474314196
>          00000276457477764702
>          00000276457485946076
>          00000276457489986581
>          00000276457500216563
>          00000276457560363833
>          00000276457566068760
>          00000276457571709045
>          00000276457594841516
>          00000276457618375542
>          00000276457628372033
>          00000276457634496509
>          00000276457641473652
>          00000276457662760413
>          00000276457667772505
> ===========================================================================
> 
> In Prozessoren amd64 befindet sich ein 64-bit-Counter, der von einer 
> Taktfrequenz
> im Giga-Hertz-Bereich angetrieben wird.
> Der verändert sich durch die Zeitdauer von nur einem Funktionsaufruf 
> bereits
> um Millionen in seinem Zählerstand.
> 
> Mindestens die 4/5 Ziffern von rechts können als random verwendet werden.
> Oft sind bereits 1- bis 2-stellige Zahlen in geringerer Anzahl nützlich.
> 
> Das Kommando nimmt ein Argument entgegen:  Die Anzahl von ausgegebenen 
> Zahlen.
> Voreingestellt ist die Anzahl 8.

Kompliziert!
Warum benutzt Du keinen Maschinenbefehl?

retry_loop:
	RDRAND rax
	JNC retry_loop

RDRAND grift auf den internen, hardwarebasierten Zufallszahlengenerator 
zurück, der echtes thermisches Rauschen als Quelle benutzt.

:)

-- 
Public Webspace von Ingenieurbüro Baumann:
https://hidrive.ionos.com/share/sc0px3oy7x

[toc] | [prev] | [next] | [standalone]

#369479

FromStefan Wiens <s.wi@gmx.net>
Date2026-09-19 08:31 +0200
Message-ID<874iflsqhd.fsf@s-bot.de>
In reply to#369478
Leo Baumann <ib@leobaumann.de> writes:

> Am 19.09.2026 um 01:59 schrieb Helmut Schellong:
>> Mittels einer Assembler-Funktion rdtsc(), die ich schon lange besitze, habe
>> ich nun einen Generator für echte Zufallszahlen entwickelt.
>> http://www.schellong.de/htm/randtsc.c.html
>> Ausgabe:
>> ===========================================================================
>>          00000276457408345376
>>          00000276457428358754
>>          00000276457431266902
>>          00000276457435366459
>>          00000276457448473547
>>          00000276457451206089
>>          00000276457454226781
>>          00000276457457223742
>>          00000276457460060553
>>          00000276457474314196
>>          00000276457477764702
>>          00000276457485946076
>>          00000276457489986581
>>          00000276457500216563
>>          00000276457560363833
>>          00000276457566068760
>>          00000276457571709045
>>          00000276457594841516
>>          00000276457618375542
>>          00000276457628372033
>>          00000276457634496509
>>          00000276457641473652
>>          00000276457662760413
>>          00000276457667772505
>> ===========================================================================
>> In Prozessoren amd64 befindet sich ein 64-bit-Counter, der von einer
>> Taktfrequenz
>> im Giga-Hertz-Bereich angetrieben wird.
>> Der verändert sich durch die Zeitdauer von nur einem Funktionsaufruf
>> bereits
>> um Millionen in seinem Zählerstand.
>> Mindestens die 4/5 Ziffern von rechts können als random verwendet
>> werden.
>> Oft sind bereits 1- bis 2-stellige Zahlen in geringerer Anzahl nützlich.
>> Das Kommando nimmt ein Argument entgegen:  Die Anzahl von
>> ausgegebenen Zahlen.
>> Voreingestellt ist die Anzahl 8.
>
> Kompliziert!
> Warum benutzt Du keinen Maschinenbefehl?
>
> retry_loop:
> 	RDRAND rax
> 	JNC retry_loop
>
> RDRAND grift auf den internen, hardwarebasierten
> Zufallszahlengenerator zurück, der echtes thermisches Rauschen als
> Quelle benutzt.

Etwas mehr Mühe sollte man sich schon machen:

<https://www.intel.com/content/www/us/en/developer/articles/guide/intel-digital-random-number-generator-drng-software-implementation-guide.html>

-- 
Stefan

[toc] | [prev] | [next] | [standalone]

#369513

FromLeo Baumann <ib@leobaumann.de>
Date2026-09-21 18:43 +0200
Message-ID<118rmr7$4mf6$1@solani.org>
In reply to#369479
Am 19.09.2026 um 08:31 schrieb Stefan Wiens:
>> RDRAND grift auf den internen, hardwarebasierten
>> Zufallszahlengenerator zurück, der echtes thermisches Rauschen als
>> Quelle benutzt.
> 
> Etwas mehr Mühe sollte man sich schon machen:
> 
> <https://www.intel.com/content/www/us/en/developer/articles/guide/intel-digital-random-number-generator-drng-software-implementation-guide.html>
> 
BTW, der Server-Prozessor vom Online-Assembler 'myCompiler' beherrscht 
den Assemblerbefehl rdseed nicht...

section .text
global _start

_start:
     ; Schritt 1: Prüfen, ob RDSEED unterstützt wird
     mov eax, 7          ; Funktion 7 (Erweiterte Features)
     xor ecx, ecx        ; Subfunktion 0
     cpuid               ; CPU-Informationen abfragen

     ; Das Ergebnis für RDSEED steht im Register EBX an Bit-Position 18
     shr ebx, 18         ; Verschiebe Bit 18 an die erste Stelle (Bit 0)
     and ebx, 1          ; Maskiere alle anderen Bits aus (nur noch 0 
oder 1)

     cmp ebx, 1          ; Unterstützt die CPU RDSEED?
     je .rdseed_ok       ; Wenn ja, springe zu Erfolg

     ; --- FALLBACK / FEHLER ---
     ; Wenn RDSEED NICHT unterstützt wird, beendet sich das Programm mit 
Code 100
     mov rdi, 100
     jmp .exit

.rdseed_ok:
     ; --- ERFOLG ---
     ; Wenn RDSEED unterstützt wird, beendet sich das Programm mit Code 0
     xor rdi, rdi

.exit:
     mov rax, 60         ; Systemaufruf-Nummer für sys_exit
     syscall             ; Programm beenden

... wird mit exit code 100 beendet.

Grüße
-- 
Public Webspace von Ingenieurbüro Baumann:
https://hidrive.ionos.com/share/sc0px3oy7x

[toc] | [prev] | [next] | [standalone]

#369515

FromHelmut Schellong <var@schellong.biz>
Date2026-09-21 20:26 +0200
Message-ID<118rsru$2psp$1@solani.org>
In reply to#369513
Leo Baumann wrote on 21.09.2026 18:43:
> Am 19.09.2026 um 08:31 schrieb Stefan Wiens:
>>> RDRAND grift auf den internen, hardwarebasierten
>>> Zufallszahlengenerator zurück, der echtes thermisches Rauschen als
>>> Quelle benutzt.
>>
>> Etwas mehr Mühe sollte man sich schon machen:
>>
>> <https://www.intel.com/content/www/us/en/developer/articles/guide/intel-digital-random-number-generator-drng-software-implementation-guide.html> 
>>
>>
> BTW, der Server-Prozessor vom Online-Assembler 'myCompiler' beherrscht den Assemblerbefehl rdseed nicht...
Die Instruktion rdtsc speichert ihren 64-bit-Wert in die beiden 32-bit-Register edx und eax.
Das ist generell portabler!
Deshalb verzichtete ich bisher auf rdrand und andere.


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [prev] | [next] | [standalone]

#369516

FromLeo Baumann <ib@leobaumann.de>
Date2026-09-21 20:33 +0200
Message-ID<118rtau$4rpv$1@solani.org>
In reply to#369515
Am 21.09.2026 um 20:26 schrieb Helmut Schellong:
> Leo Baumann wrote on 21.09.2026 18:43:
>> Am 19.09.2026 um 08:31 schrieb Stefan Wiens:
>>>> RDRAND grift auf den internen, hardwarebasierten
>>>> Zufallszahlengenerator zurück, der echtes thermisches Rauschen als
>>>> Quelle benutzt.
>>>
>>> Etwas mehr Mühe sollte man sich schon machen:
>>>
>>> <https://www.intel.com/content/www/us/en/developer/articles/guide/ 
>>> intel-digital-random-number-generator-drng-software-implementation- 
>>> guide.html>
>>>
>> BTW, der Server-Prozessor vom Online-Assembler 'myCompiler' beherrscht 
>> den Assemblerbefehl rdseed nicht...
> Die Instruktion rdtsc speichert ihren 64-bit-Wert in die beiden 32-bit- 
> Register edx und eax.
> Das ist generell portabler!
> Deshalb verzichtete ich bisher auf rdrand und andere.

Was aus rdtsc abgeloeitet wird ist kein echter Zufall!

Pseudozufall!

Nicht geeignet für Kryptographie, leicht manipulierbar und vorhersehbar!

Also Mist!

-- 
Public Webspace von Ingenieurbüro Baumann:
https://hidrive.ionos.com/share/sc0px3oy7x

[toc] | [prev] | [next] | [standalone]

#369520

FromHelmut Schellong <var@schellong.biz>
Date2026-09-21 21:49 +0200
Message-ID<118s1ov$2t65$1@solani.org>
In reply to#369516
Leo Baumann wrote on 21.09.2026 20:33:
> Am 21.09.2026 um 20:26 schrieb Helmut Schellong:
>> Leo Baumann wrote on 21.09.2026 18:43:
>>> Am 19.09.2026 um 08:31 schrieb Stefan Wiens:
>>>>> RDRAND grift auf den internen, hardwarebasierten
>>>>> Zufallszahlengenerator zurück, der echtes thermisches Rauschen als
>>>>> Quelle benutzt.
>>>>
>>>> Etwas mehr Mühe sollte man sich schon machen:
>>>>
>>>> <https://www.intel.com/content/www/us/en/developer/articles/guide/ 
>>>> intel-digital-random-number-generator-drng-software-implementation- guide.html>
>>>>
>>> BTW, der Server-Prozessor vom Online-Assembler 'myCompiler' beherrscht den Assemblerbefehl rdseed nicht...
>> Die Instruktion rdtsc speichert ihren 64-bit-Wert in die beiden 32-bit- Register edx und eax.
>> Das ist generell portabler!
>> Deshalb verzichtete ich bisher auf rdrand und andere.
> 
> Was aus rdtsc abgeloeitet wird ist kein echter Zufall!
> 
> Pseudozufall!

Nein.

> Nicht geeignet für Kryptographie, leicht manipulierbar und vorhersehbar!

Und nochmals Nein.

> Also Mist!

Keineswegs.

Der _unabhängige_ TSC-Counter zählt innerhalb von 0,322 ns um 1 hoch, bei mir.
Das bedeutet, daß er von der Wirkung der gesamten Hardware (bis ins feinste Detail)
des Computers hochgezählt wird.
Bereits eine einzige der zeitlich kürzesten Instruktionen läßt ihn hochzählen!
Fast jede Aktion in meinem TSC-Programm läßt ihn millionenfach hochzählen!

Alles ist dabei unvorhersehbar, weil von der Hardware bestimmt.


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [prev] | [next] | [standalone]

#369521

FromLeo Baumann <ib@leobaumann.de>
Date2026-09-21 21:56 +0200
Message-ID<118s25u$4v9f$1@solani.org>
In reply to#369520
Am 21.09.2026 um 21:49 schrieb Helmut Schellong:
> Leo Baumann wrote on 21.09.2026 20:33:
>> Am 21.09.2026 um 20:26 schrieb Helmut Schellong:
>>> Leo Baumann wrote on 21.09.2026 18:43:
>>>> Am 19.09.2026 um 08:31 schrieb Stefan Wiens:
>>>>>> RDRAND grift auf den internen, hardwarebasierten
>>>>>> Zufallszahlengenerator zurück, der echtes thermisches Rauschen als
>>>>>> Quelle benutzt.
>>>>>
>>>>> Etwas mehr Mühe sollte man sich schon machen:
>>>>>
>>>>> <https://www.intel.com/content/www/us/en/developer/articles/guide/ 
>>>>> intel-digital-random-number-generator-drng-software-implementation- 
>>>>> guide.html>
>>>>>
>>>> BTW, der Server-Prozessor vom Online-Assembler 'myCompiler' 
>>>> beherrscht den Assemblerbefehl rdseed nicht...
>>> Die Instruktion rdtsc speichert ihren 64-bit-Wert in die beiden 32- 
>>> bit- Register edx und eax.
>>> Das ist generell portabler!
>>> Deshalb verzichtete ich bisher auf rdrand und andere.
>>
>> Was aus rdtsc abgeloeitet wird ist kein echter Zufall!
>>
>> Pseudozufall!
> 
> Nein.
> 
>> Nicht geeignet für Kryptographie, leicht manipulierbar und vorhersehbar!
> 
> Und nochmals Nein.
> 
>> Also Mist!
> 
> Keineswegs.
> 
> Der _unabhängige_ TSC-Counter zählt innerhalb von 0,322 ns um 1 hoch, 
> bei mir.
> Das bedeutet, daß er von der Wirkung der gesamten Hardware (bis ins 
> feinste Detail)
> des Computers hochgezählt wird.
> Bereits eine einzige der zeitlich kürzesten Instruktionen läßt ihn 
> hochzählen!
> Fast jede Aktion in meinem TSC-Programm läßt ihn millionenfach hochzählen!
> 
> Alles ist dabei unvorhersehbar, weil von der Hardware bestimmt.

Chuck Schellong, Du hast einen Standesdünkel - Du hast kein Diplom - 
gehe erstmal neu studieren bevor Du uns mit Deinem Schwachsinn beschäftigst!


-- 
Public Webspace von Ingenieurbüro Baumann:
https://hidrive.ionos.com/share/sc0px3oy7x

[toc] | [prev] | [next] | [standalone]

#369522

FromHelmut Schellong <var@schellong.biz>
Date2026-09-21 22:07 +0200
Message-ID<118s2pp$2u1a$1@solani.org>
In reply to#369521
Leo Baumann wrote on 21.09.2026 21:56:
> Am 21.09.2026 um 21:49 schrieb Helmut Schellong:
>> Leo Baumann wrote on 21.09.2026 20:33:
>>> Am 21.09.2026 um 20:26 schrieb Helmut Schellong:
>>>> Leo Baumann wrote on 21.09.2026 18:43:
>>>>> Am 19.09.2026 um 08:31 schrieb Stefan Wiens:
>>>>>>> RDRAND grift auf den internen, hardwarebasierten
>>>>>>> Zufallszahlengenerator zurück, der echtes thermisches Rauschen als
>>>>>>> Quelle benutzt.
>>>>>>
>>>>>> Etwas mehr Mühe sollte man sich schon machen:
>>>>>>
>>>>>> <https://www.intel.com/content/www/us/en/developer/articles/guide/ 
>>>>>> intel-digital-random-number-generator-drng-software-implementation- guide.html>
>>>>>>
>>>>> BTW, der Server-Prozessor vom Online-Assembler 'myCompiler' beherrscht den Assemblerbefehl rdseed nicht...
>>>> Die Instruktion rdtsc speichert ihren 64-bit-Wert in die beiden 32- bit- Register edx und eax.
>>>> Das ist generell portabler!
>>>> Deshalb verzichtete ich bisher auf rdrand und andere.
>>>
>>> Was aus rdtsc abgeloeitet wird ist kein echter Zufall!
>>>
>>> Pseudozufall!
>>
>> Nein.
>>
>>> Nicht geeignet für Kryptographie, leicht manipulierbar und vorhersehbar!
>>
>> Und nochmals Nein.
>>
>>> Also Mist!
>>
>> Keineswegs.
>>
>> Der _unabhängige_ TSC-Counter zählt innerhalb von 0,322 ns um 1 hoch, bei mir.
>> Das bedeutet, daß er von der Wirkung der gesamten Hardware (bis ins feinste Detail)
>> des Computers hochgezählt wird.
>> Bereits eine einzige der zeitlich kürzesten Instruktionen läßt ihn hochzählen!
>> Fast jede Aktion in meinem TSC-Programm läßt ihn millionenfach hochzählen!
>>
>> Alles ist dabei unvorhersehbar, weil von der Hardware bestimmt.
> 
> Chuck Schellong, Du hast einen Standesdünkel - Du hast kein Diplom - gehe erstmal neu studieren bevor Du uns mit Deinem Schwachsinn 
> beschäftigst!

Die Realität ist von meinem abgebrochenen Studium nicht abhängig!
Die physikalischen Vorgänge laufen trotz Deiner falschen Behauptungen faktisch ab.
Nichts dagegen machen Du kannst.


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [prev] | [next] | [standalone]

#369524

FromLeo Baumann <ib@leobaumann.de>
Date2026-09-22 01:35 +0200
Message-ID<118sf0g$587h$1@solani.org>
In reply to#369522
Am 21.09.2026 um 22:07 schrieb Helmut Schellong:
> Die Realität ist von meinem abgebrochenen Studium nicht abhängig!
> Die physikalischen Vorgänge laufen trotz Deiner falschen Behauptungen 
> faktisch ab.
> Nichts dagegen machen Du kannst.

Ein iTSC (Invariant Time Stamp Counter) eines Prozessors liefert keine 
echten, physikalisch unvorhersehbaren Zufallszahlen, sondern dient als 
hochpräziser Takt- und Zyklenzähler.Technische EinordnungFunktionsweise: 
Der Befehl RDTSC (Read Time Stamp Counter) liest die Anzahl der 
vergangenen CPU-Taktzyklen seit dem Systemstart aus. Ein Invariant TSC 
läuft unabhängig von Turbo-Modi oder Energiespar-Taktungen mit einer 
konstanten, nominalen Frequenz weiter.Kein echter Zufall: Der Zähler 
erhöht sich deterministisch mit jeder Schwingung. Er ist daher per se 
nicht zufällig oder kryptografisch sicher.Verwendung als Seed: Man kann 
den iTSC-Wert jedoch als Startwert (Seed) für einen 
Pseudozufallszahlengenerator (PRNG) verwenden, um bei jedem 
Programmstart eine andere Zahlenfolge zu erzeugen. Für echten Zufall 
oder sicherheitsrelevante Anwendungen (Kryptografie) ist er ungeeignet, 
da Timing-Muster und Startzeitpunkte oft erraten oder rekonstruiert 
werden können. Moderne CPUs bieten stattdessen dedizierte 
Hardware-Befehle wie RDRAND oder RDSEED, die auf echtem thermischen 
Rauschen basieren.


-- 
Public Webspace von Ingenieurbüro Baumann:
https://hidrive.ionos.com/share/sc0px3oy7x

[toc] | [prev] | [next] | [standalone]

#369526

FromHelmut Schellong <var@schellong.biz>
Date2026-09-22 14:35 +0200
Message-ID<118tsn4$6al2$1@solani.org>
In reply to#369524
Leo Baumann wrote on 22.09.2026 01:35:
> Am 21.09.2026 um 22:07 schrieb Helmut Schellong:
>> Die Realität ist von meinem abgebrochenen Studium nicht abhängig!
>> Die physikalischen Vorgänge laufen trotz Deiner falschen Behauptungen faktisch ab.
>> Nichts dagegen machen Du kannst.
> 
> Ein iTSC (Invariant Time Stamp Counter) eines Prozessors liefert keine echten, physikalisch unvorhersehbaren Zufallszahlen, sondern 
> dient als hochpräziser Takt- und Zyklenzähler.Technische EinordnungFunktionsweise: Der Befehl RDTSC (Read Time Stamp Counter) liest 
> die Anzahl der vergangenen CPU-Taktzyklen seit dem Systemstart aus. Ein Invariant TSC läuft unabhängig von Turbo-Modi oder 
> Energiespar-Taktungen mit einer konstanten, nominalen Frequenz weiter.Kein echter Zufall: Der Zähler erhöht sich deterministisch mit 
> jeder Schwingung. Er ist daher per se nicht zufällig oder kryptografisch sicher.Verwendung als Seed: Man kann den iTSC-Wert jedoch 
> als Startwert (Seed) für einen Pseudozufallszahlengenerator (PRNG) verwenden, um bei jedem Programmstart eine andere Zahlenfolge zu 
> erzeugen. Für echten Zufall oder sicherheitsrelevante Anwendungen (Kryptografie) ist er ungeeignet, da Timing-Muster und 
> Startzeitpunkte oft erraten oder rekonstruiert werden können. Moderne CPUs bieten stattdessen dedizierte Hardware-Befehle wie RDRAND 
> oder RDSEED, die auf echtem thermischen Rauschen basieren.

Du hast eine falsche Blickweise zum Thema.

In den 1980er Jahren wurden Lotto-Generatoren angeboten.
Einer hatte einen 10-MHz-Counter, der von 1..49 in der Runde zählte.
Aktiviert wurde er durch Tippen auf einen mechanischen Taster mit Prellverhalten.
Der Counter brauchte 4,9 us für 49 Zählschritte.
Das sind 204 Durchläufe von 1..49 innerhalb einer Millisekunde.
Das waren einwandfreie echte Zufallszahlen.

Genau so ist es mit dem TSC-Counter.
Nur, daß dieser noch viel schneller und damit besser ist.

         00000012826.999.777875  0000001282619.7777875
         00000012826.002.334064  0000000000000.0056189
         00000012826.110.556288  0000000000000.9922224
         00000012826.112.553612  0000000000000.8897324
         00000012826.118.228152  0000000000000.1174540
         00000012826.224.555136  0000000000000.0026984
         00000012826.331.775996  0000000000000.2220860
         00000012826.661.999492  0000000000003.7723496
         00000012826.772.222973  0000000000001.3323481
         00000012826.777.339184  0000000000000.8816211
         00000012826.885.883678  0000000000000.3344494
         00000012826.993.442291  0000000000000.6658613
         00000012826.117.992449  0000000000002.2250158
         00000012826.224.225269  0000000000000.8832820
         00000012826.660.222797  0000000000003.8897528
         00000012826.667.119339  0000000000000.3396542
         00000012826.778.996913  0000000000001.8877574
         00000012826.779.002629  0000000000000.6605716
         00000012826.882.331363  0000000000000.5528734
         00000012826.887.774230  0000000000000.6642867
         00000012826.993.880379  0000000000000.8806149
         00000012826.999.113577  0000000000000.4433198
         00000012826.222.552009  0000000000002.4438432
         00000012826.558.667423  0000000000003.1115414
         00000012826.667.221655  0000000000000.5554232

Rechts sind die Differenzen zum jeweiligen Vorgänger-Wert dargestellt.
    *** Warum sind die Differenzen so stark unterschiedlich, und derartig hoch? ***
Die Werte gehen von 56189 bis 38897528.
Zusätzlich sind die Differenzwerte gut durchgemischt, ohne erkennbare Tendenz.
Kein Differenzwert kommt mehr als einmal vor, auch nicht bei viel mehr Zeilen.

time writes to the standard error stream,  (in  seconds):
.     the  total  time  elapsed, the time used to execute the utility process and
.     the time consumed by system overhead.
.     0.68 real	     0.00 user	    0.22 sys
.     0.67 real	     0.00 user	    0.21 sys

Der Aufruf 'tsc= rdtsc()' steht doch im Quelltext ganz oben in der Schleife.
Vor und nach dem Aufruf werden doch viele Instruktionen ausgeführt, die jeweils
einen Zeitbedarf haben.
Wobei eine Instruktion einen Bedarf von z.B. 9..38 Takten haben kann - praktisch unvorhersehbar.
Dabei schwankt die Taktfrequenz des Prozessors von z.B. 800..4700 MHz - nicht voraus berechenbar.
Der TSC hingegen wird mit einer Festfrequenz von 3100 MHz (bei mir) getaktet.
Auch das mehrstufige Cache-System hat unvorhersehbare Zeitvorteile.
Jegliche Benutzung von Geräten (Bildschirm, Festplatten, etc.) hat einen jeweiligen Zeitbedarf.
Hinzu kommen die vielen nicht voraus kalkulierbaren Zeitbedarfe des Betriebssystems.

Während all dieser Zeitbedarfe kann der TSC nicht gelesen werden, denn der Standort
ist eben _nicht_ der Aufruf 'tsc= rdtsc()', sondern man steht halt woanders im Verarbeitungsablauf.
Und während all dieser Zeitbedarfe zählt der TSC superschnell hoch!
Beim nächstmöglichen Lesen des TSC gibt dieser eben einen unvorhersehbaren Wert zurück!
Der Start des Kommandos 'randtsc' ist ebenso zu einem zufälligen Zeitpunkt, aus Sicht des TSC.

Alle _gelesenen_ Werte des TSC sind folglich überhaupt nicht deterministisch, sondern echter Zufall.
Es ist gar nicht möglich, _jeden_ Zählerstand des TSC nacheinander per Instruktion 'rdtsc' zu lesen!


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [prev] | [next] | [standalone]

#369529

FromMarte Schwarz <marte.schwarz@gmx.de>
Date2026-09-22 17:00 +0200
Message-ID<118u56h$73r4$1@gwaiyur.mb-net.net>
In reply to#369526
Hi Helmut,
>>> Die physikalischen Vorgänge laufen trotz Deiner falschen Behauptungen 
>>> faktisch ab.

>> Ein iTSC (Invariant Time Stamp Counter) eines Prozessors liefert keine 
>> echten, physikalisch unvorhersehbaren Zufallszahlen, sondern dient als 
>> hochpräziser Takt- und Zyklenzähler.Technische 

> Du hast eine falsche Blickweise zum Thema.

An Selbstbewußtsein fehlt es Dir nicht, ich würde es Überheblichkeit nennen.

> In den 1980er Jahren wurden Lotto-Generatoren angeboten.
> Einer hatte einen 10-MHz-Counter, der von 1..49 in der Runde zählte.
> Aktiviert wurde er durch Tippen auf einen mechanischen Taster mit 
> Prellverhalten.

Genau: Prellvorgänge und in erster Linie die manuelle Betätigung, die 
wenigstens eine Unabhängigkeit vom Zähler vorzuweisen hat. und nicht 
zwei recht deterministische Taktgeneratoren miteinander vergleicht.

> Das waren einwandfreie echte Zufallszahlen.

Es geht deutlich besser

> Genau so ist es mit dem TSC-Counter.

Nicht wirklich, wie Du doch mit dem NIST-Test selbst festgestellt hattest.

> Zusätzlich sind die Differenzwerte gut durchgemischt, ohne erkennbare 
> Tendenz.

Dein erster Blick hat mit Wissenschaft nicht viel zu tun.

> Alle _gelesenen_ Werte des TSC sind folglich überhaupt nicht 
> deterministisch, sondern echter Zufall.

Sie sind zwar sehr komplex aber nicht zufällig, weil nach einem festen 
Programmablauf ermittelt. Warum nicht einfach den Zufallsgenerator 
nehmen, der da ist und wirklich Zufall liefert?

Marte

[toc] | [prev] | [next] | [standalone]

#369530

FromHelmut Schellong <var@schellong.biz>
Date2026-09-22 18:04 +0200
Message-ID<118u8tg$6keq$1@solani.org>
In reply to#369529
Marte Schwarz wrote on 22.09.2026 17:00:
> Hi Helmut,
>>>> Die physikalischen Vorgänge laufen trotz Deiner falschen Behauptungen faktisch ab.
> 
>>> Ein iTSC (Invariant Time Stamp Counter) eines Prozessors liefert keine echten, physikalisch unvorhersehbaren Zufallszahlen, 
>>> sondern dient als hochpräziser Takt- und Zyklenzähler.Technische 
> 
>> Du hast eine falsche Blickweise zum Thema.
> 
> An Selbstbewußtsein fehlt es Dir nicht, ich würde es Überheblichkeit nennen.

Der Leo hat hier definitiv eine falsche Sichtweise.
Er hat den TSC völlig isoliert betrachtet - und das geht hier gar nicht.
Ich habe es doch selbst dauernd berichtet, und an Leo gepostet.

>> In den 1980er Jahren wurden Lotto-Generatoren angeboten.
>> Einer hatte einen 10-MHz-Counter, der von 1..49 in der Runde zählte.
>> Aktiviert wurde er durch Tippen auf einen mechanischen Taster mit Prellverhalten.
> 
> Genau: Prellvorgänge und in erster Linie die manuelle Betätigung, die wenigstens eine Unabhängigkeit vom Zähler vorzuweisen hat. und 
> nicht zwei recht deterministische Taktgeneratoren miteinander vergleicht.
> 
>> Das waren einwandfreie echte Zufallszahlen.
> 
> Es geht deutlich besser

Mehr Aufwand bringt in der Regel bessere Ergebnisse.
Diese Lotto-Dinger waren ja für 5 DM machbar.

>> Genau so ist es mit dem TSC-Counter.
> 
> Nicht wirklich, wie Du doch mit dem NIST-Test selbst festgestellt hattest.

Wahrscheinlich doch.
Ich habe festgestellt, daß die Ausgabe auf stdout starke Verzögerungen bewirkt.
Diese wirken sehr positiv.
Bei der binären Ausgabe von 10000000 Byte jedoch unterblieb die Ausgabe auf stdout.
Dadurch bekam ich schlechte Daten.

>> Zusätzlich sind die Differenzwerte gut durchgemischt, ohne erkennbare Tendenz.
> 
> Dein erster Blick hat mit Wissenschaft nicht viel zu tun.

Richtig, aber meine visuelle Beobachtung war bisher stets korrekt, mein Leben lang.
Was ich sah, sah wirklich gut aus, bisher.

>> Alle _gelesenen_ Werte des TSC sind folglich überhaupt nicht deterministisch, sondern echter Zufall.
> 
> Sie sind zwar sehr komplex aber nicht zufällig, weil nach einem festen Programmablauf ermittelt. Warum nicht einfach den 
> Zufallsgenerator nehmen, der da ist und wirklich Zufall liefert?

Sie sind letztlich nicht nach einem festen Programmablauf ermittelt.
Von Bedeutung sind alle Verzögerungen im Programm, besonders die mit Außenwirkung.
Bei jedem Stopp im Programm läuft der TSC weiter.
Und wenn diese Stopps Zufallsaspekte haben, ist auch der nächste Wert des TSC zufällig.

Ich habe bisher mehrfach angedeutet, daß ich noch nicht fertig bin mit der Arbeit an randtsc.
Bevor ich 10 GB Daten als One-Time-Pad konkret verwende, werde ich noch prüfen und forschen müssen.
Voraussetzung für weitere Schritte ist mindestens der aktuelle Stand meiner Software.

Die weiteren Sonder-Instruktionen werde ich beizeiten ausprobieren.
Für geringere Mengen von echten Zufallszahlen, reicht mein Programm bereits aus.
Kann sein, daß ich rdrand für die 10 GB verwende.


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [prev] | [next] | [standalone]

#369541 — Echter Zufall mit iTSC-counter - Bericht und Beweis

FromHelmut Schellong <var@schellong.biz>
Date2026-09-23 23:22 +0200
SubjectEchter Zufall mit iTSC-counter - Bericht und Beweis
Message-ID<1191ful$8u69$1@solani.org>
In reply to#369529
Marte Schwarz wrote on 22.09.2026 17:00:
> Hi Helmut,
[...]
>> Genau so ist es mit dem TSC-Counter.
> 
> Nicht wirklich, wie Du doch mit dem NIST-Test selbst festgestellt hattest.
> 
>> Zusätzlich sind die Differenzwerte gut durchgemischt, ohne erkennbare Tendenz.
> 
> Dein erster Blick hat mit Wissenschaft nicht viel zu tun.
> 
>> Alle _gelesenen_ Werte des TSC sind folglich überhaupt nicht deterministisch, sondern echter Zufall.
> 
> Sie sind zwar sehr komplex aber nicht zufällig, weil nach einem festen Programmablauf ermittelt. Warum nicht einfach den 
> Zufallsgenerator nehmen, der da ist und wirklich Zufall liefert?

         00000244649.228.223995  0000000000000.9991530    0
         00000244649.334.888921  0000000000000.6664926    0
         00000244649.441.669632  0000000000000.8880711    0
         00000244649.550.339620  0000000000000.7769988    0
         00000244649.773.773325  0000000000002.4433705    0
         00000244649.116.116388  0000000000004.5543063    0
         00000244649.223.996783  0000000000000.0080395    0
         00000244649.229.775718  0000000000000.5578935    0
         00000244649.335.995524  0000000000000.9919806    0
         00000244649.440.889443  0000000000000.1193919    0
         00000244649.446.332036  0000000000000.1142593    0
         00000244649.551.889356  0000000000000.1157320    0
         00000244649.556.000457  0000000000000.1111101    0
         00000244649.779.221161  0000000000002.3320704    0
         00000244649.117.002791  0000000000003.6681630    0
         00000244649.225.778122  0000000000000.6675331    0
         00000244649.228.991041  0000000000000.6612919    0


	00000244873.998.557226  0000000000000.1165404    0
	00000244873.998.660252  0000000000000.0003026    0
	00000244873.998.661627  0000000000000.0001375    0
	00000244873.998.662729  0000000000000.0001102    0
	00000244873.998.663826  0000000000000.0001097    0
	00000244873.998.664956  0000000000000.0001130    0
	00000244873.998.666131  0000000000000.0001175    0
	00000244873.998.667240  0000000000000.0001109    0
	00000244873.998.668429  0000000000000.0001189    0
	00000244873.998.993645  0000000000000.0025216    0
	00000244873.998.995495  0000000000000.0001850    0
	00000244873.998.997015  0000000000000.0001520    0
	00000244873.998.998267  0000000000000.0001252    0
	00000244873.998.999577  0000000000000.0001310    0
	00000244873.998.000895  0000000000000.0001318    0
	00000244873.998.002231  0000000000000.0001336    0
	00000244873.998.003340  0000000000000.0001109    0
	00000244873.998.004495  0000000000000.0001155    0
	00000244873.998.112878  0000000000000.0008383    0

Beide Ausgaben erfolgten mit abgeschaltetem Rückkopplungs-Delay-Mechanismus (die 0 rechts).
Beim oberen Block wurde zum Bildschirm ausgegeben (stdout).
Beim unteren Block wurde stdout in eine Datei umgelenkt (randtsc 50 > dez.txt).

         00000244649.779.221161  0000000000002.3320704    0      zum Bildschirm (tty)
	00000244873.998.004495  0000000000000.0001155    0      zu einer Datei

Die miese Qualität unten lag bei den Daten für den NIST-Test vor.
Die hohe Qualität _oben_ sieht man bereits an den Sprüngen in der Spalte .###.,
während diese Spalte _unten_ konstant bleibt.
Der Unterschied ist absolut gewaltig!
Oben Sprünge von bis über 4 Mio Counts, unten im Mittel über 1000 (vierstellig).
Tausend Counts Differenz brauchen etwa 300 ns Zeit - viel zu wenig bei höheren Ansprüchen.

	00000261815.662.002367  0000000000000.4484495   15
	00000261815.665.995276  0000000000000.7792909   15
	00000261815.770.337576  0000000000000.7742300   16
	00000261815.779.442823  0000000000000.8805247   16

Ich habe einen Regler implementiert, der automatisch die Ausgabequalität optimiert.
Dies sieht man vorstehend rechts an der wechselnden Bit-Anzahl der Delay-Maske.
Das ist notwendig, weil die unterliegende ultra-komplexe Hardware ständig changiert.

All dies stellt einen Beweis dafür dar, daß das Programm Stopps erfährt, während
derer der TSC superschnell weiter hochzählt, während das Programm eben steht,
oder selbst mit Absicht eine zusätzliche zufällige Verzögerung erzeugt.

Die permanenten 2-stelligen zweifachen Schnaps-Zahlen in den Ausgaben sind für mich bisher unerklärlich!
An der Umwandlung (itoa) liegt es nicht.


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [prev] | [next] | [standalone]

#369546 — Re: Echter Zufall mit iTSC-counter - Bericht und Beweis

FromHelmut Schellong <var@schellong.biz>
Date2026-09-24 20:51 +0200
SubjectRe: Echter Zufall mit iTSC-counter - Bericht und Beweis
Message-ID<1193rff$870n$1@solani.org>
In reply to#369541
Helmut Schellong wrote on 23.09.2026 23:22:
> Marte Schwarz wrote on 22.09.2026 17:00:
>> Hi Helmut,
> [...]
> 
>      00000261815.662.002367  0000000000000.4484495   15
>      00000261815.665.995276  0000000000000.7792909   15
>      00000261815.770.337576  0000000000000.7742300   16
>      00000261815.779.442823  0000000000000.8805247   16
> 
> Ich habe einen Regler implementiert, der automatisch die Ausgabequalität optimiert.
> Dies sieht man vorstehend rechts an der wechselnden Bit-Anzahl der Delay-Maske.
> Das ist notwendig, weil die unterliegende ultra-komplexe Hardware ständig changiert.
> 
> All dies stellt einen Beweis dafür dar, daß das Programm Stopps erfährt, während
> derer der TSC superschnell weiter hochzählt, während das Programm eben steht,
> oder selbst mit Absicht eine zusätzliche zufällige Verzögerung erzeugt.
> 
> Die permanenten 2-stelligen zweifachen Schnaps-Zahlen in den Ausgaben sind für mich bisher unerklärlich!
> An der Umwandlung (itoa) liegt es nicht.

Den Fehler mit den Doppel-Ziffern konnte ich beseitigen.
Es waren jedoch 4 Fehler!
Der wirkliche Fehler vom Anfang war:  p[0] statt korrekt p[1].
Es wurde eine scheinbare Fehlerbeseitigung vorgenommen, die auch wirkte.
Jedoch hatte diese Fehler (die Doppel-Ziffern) ausgelöst.
Nach Beseitigung waren die Abtrennungen zu kurz.
Es mußten die Längenparameter wieder um 1 erhöht werden.
Sapperlot!

Ich kann nun den 2. NIST-Test vorbereiten.

	00000321986.456.736185  0000000000000.1639033   14
	00000321986.458.626168  0000000000000.1889983   15

	00000321986.689.231825  0000000000000.1040963   15
	00000321986.701.295687  0000000000001.2063862   16

	00000321987.013.889792  0000000000000.8290776   16
	00000321987.036.286965  0000000000002.2397173   17

	00000321987.846.877553  0000000000000.8379973   17
	00000321987.852.010022  0000000000000.5132469   16

	00000321988.354.294006  0000000000001.9533759   16
	00000321988.372.168060  0000000000001.7874054   15

	00000321988.551.729840  0000000000001.2675890   15
	00000321988.561.463922  0000000000000.9734082   16

Wegen Fehler-Beseitigung.
Die Doppel-Ziffern sind weg, und die Differenz paßt wieder zum TSC-Wert.


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [prev] | [next] | [standalone]

#369557 — Re: Echter Zufall mit iTSC-counter - Bericht und Beweis

FromHelmut Schellong <var@schellong.biz>
Date2026-09-25 15:37 +0200
SubjectRe: Echter Zufall mit iTSC-counter - Bericht und Beweis
Message-ID<1195te7$9ice$1@solani.org>
In reply to#369546
Helmut Schellong wrote on 24.09.2026 20:51:
> Helmut Schellong wrote on 23.09.2026 23:22:
>> Marte Schwarz wrote on 22.09.2026 17:00:
>>> Hi Helmut,
>> [...]

>> Die permanenten 2-stelligen zweifachen Schnaps-Zahlen in den Ausgaben sind für mich bisher unerklärlich!
>> An der Umwandlung (itoa) liegt es nicht.
> 
> Den Fehler mit den Doppel-Ziffern konnte ich beseitigen.
> ...
> Ich kann nun den 2. NIST-Test vorbereiten.

Der zweite NIST-Test hat für meine TSC-Zufallszahlen ein super-gutes Ergebnis gebracht!
Das beste Ergebnis, das ich bisher bei diesem Test sah.
Der p_value hat außerordentlich hohe Werte angenommen.
Ich sah nicht selten 0,999 und ähnlich hoch - von 0,01...<1,0 gilt ein Test als bestanden.

Es hat allerdings mehr als 1 Stunde gedauert, bis 1 MB Prüfdaten geschrieben waren.
Ich muß folglich den übergroßen Hub der Werte von Lesen zu Lesen (Delay) reduzieren.

Ich habe damit eine neue Art der Erzeugung von echten Zufallszahlen erfunden.
Jedenfalls nach meiner Kenntnis.

http://www.schellong.de/txt/nist.txt

________________________________________________________________________________

		FILE = /ram/zdat		ALPHA = 0.0100
________________________________________________________________________________

		BITSREAD = 1000000 0s = 499156 1s = 500844
		BITSREAD = 1000000 0s = 500387 1s = 499613
		BITSREAD = 1000000 0s = 500163 1s = 499837
		BITSREAD = 1000000 0s = 500338 1s = 499662
		BITSREAD = 1000000 0s = 499963 1s = 500037
------------------------------------------------------------------------------
RESULTS FOR THE UNIFORMITY OF P-VALUES AND THE PROPORTION OF PASSING SEQUENCES
------------------------------------------------------------------------------
    generator is </ram/zdat>
------------------------------------------------------------------------------
  C1  C2  C3  C4  C5  C6  C7  C8  C9 C10  P-VALUE  PROPORTION  STATISTICAL TEST
------------------------------------------------------------------------------
   1   0   0   0   2   0   0   1   0   1     ----       5/5       Frequency
   0   0   1   0   2   0   1   1   0   0     ----       5/5       BlockFrequency
   0   2   0   1   0   0   1   1   0   0     ----       5/5       CumulativeSums
   0   2   0   1   1   1   0   0   0   0     ----       5/5       CumulativeSums
   1   0   0   0   0   0   1   1   2   0     ----       5/5       Runs
   0   0   0   1   0   0   0   1   3   0     ----       5/5       LongestRun
   1   0   0   1   1   0   0   1   1   0     ----       5/5       Rank
   0   0   1   0   1   0   1   1   0   1     ----       5/5       FFT
   1   0   0   1   1   1   0   1   0   0     ----       5/5       NonOverlappingTemplate
   0   0   3   0   0   2   0   0   0   0     ----       5/5       NonOverlappingTemplate
   0   0   1   0   1   1   0   0   1   1     ----       5/5       NonOverlappingTemplate
... ...


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [prev] | [next] | [standalone]

#369562 — Re: Echter Zufall mit iTSC-counter - Bericht und Beweis

FromHelmut Schellong <var@schellong.biz>
Date2026-09-25 23:13 +0200
SubjectRe: Echter Zufall mit iTSC-counter - Bericht und Beweis
Message-ID<1196o6a$cq76$1@solani.org>
In reply to#369557
Helmut Schellong wrote on 25.09.2026 15:37:
> Helmut Schellong wrote on 24.09.2026 20:51:
>> Helmut Schellong wrote on 23.09.2026 23:22:
>>> Marte Schwarz wrote on 22.09.2026 17:00:
>>>> Hi Helmut,
>>> [...]
>> 
>> Ich kann nun den 2. NIST-Test vorbereiten.
> 
> Der zweite NIST-Test hat für meine TSC-Zufallszahlen ein super-gutes Ergebnis gebracht!
> Das beste Ergebnis, das ich bisher bei diesem Test sah.
> Der p_value hat außerordentlich hohe Werte angenommen.
> Ich sah nicht selten 0,999 und ähnlich hoch - von 0,01...<1,0 gilt ein Test als bestanden.
> 
> Es hat allerdings mehr als 1 Stunde gedauert, bis 1 MB Prüfdaten geschrieben waren.
> Ich muß folglich den übergroßen Hub der Werte von Lesen zu Lesen (Delay) reduzieren.
> 
> Ich habe damit eine neue Art der Erzeugung von echten Zufallszahlen erfunden.
> Jedenfalls nach meiner Kenntnis.
> 
> http://www.schellong.de/txt/nist1.txt
. http://www.schellong.de/txt/nist3.txt

Ich konnte den Zeitbedarf des Kommandos 'randtsc' von etwa 1,5 h auf 50 s/MB senken.
Das sind etwa 1,7 GB pro Tag, bei einem CPU-Kern.
Die Qualität konnte ich durch Verringern der Bitbreite halten - immer noch 0 NIST-Fehler.
Der Mittelwert der p_values ist im Überblick geringer.
Der übergroße Hub zuvor hatte durchaus eine positive Wirkung auf die Qualität.

Das Projekt ist nun vorläufig beendet.
Ich kann das Kommando nun normal nutzen.


Es sind wirklich echte Zufallszahlen!
Die erste vom Kommando gelesene Zahl ist sowieso eine echte Zufallszahl.
Diese echte Zufallszahl bestimmt hauptsächlich die Dauer der Kommando-Verzögerung.
Folglich ist die nächste gelesene Zahl erneut eine echte Zufallszahl, usw.

Zudem beaufschlagt die gesamte Hardware+Software des Computers dem Kommando Verzögerungen.
Diese addieren sich zu der internen Verzögerung des Kommandos, und sie können größer sein
als die interne Verzögerung des Kommandos.
Es sind entsprechende Veränderungen an den ausgegebenen Differenzen und der geregelten
Bitbreite erkennbar und eindeutig zuzuordnen.

Das Kommando ist nicht deterministisch in Bezug auf die gelesenen TSC-Werte.
Ich kann jeglichen Ausgabe-Strom nicht gezielt wiederholen, alle längeren sind
tendenziell einzigartig.


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [prev] | [next] | [standalone]

#369564 — Re: Echter Zufall mit iTSC-counter - Bericht und Beweis

FromLeo Baumann <ib@leobaumann.de>
Date2026-09-26 04:20 +0200
SubjectRe: Echter Zufall mit iTSC-counter - Bericht und Beweis
Message-ID<1197a6f$d604$1@solani.org>
In reply to#369562
Am 25.09.2026 um 23:13 schrieb Helmut Schellong:
> Ich konnte den Zeitbedarf des Kommandos 'randtsc' von etwa 1,5 h auf 50 
> s/MB senken.
> Das sind etwa 1,7 GB pro Tag, bei einem CPU-Kern.
> Die Qualität konnte ich durch Verringern der Bitbreite halten - immer 
> noch 0 NIST-Fehler.
> Der Mittelwert der p_values ist im Überblick geringer.
> Der übergroße Hub zuvor hatte durchaus eine positive Wirkung auf die 
> Qualität.
> 
> Das Projekt ist nun vorläufig beendet.
> Ich kann das Kommando nun normal nutzen.
> 
> 
> Es sind wirklich echte Zufallszahlen!
> Die erste vom Kommando gelesene Zahl ist sowieso eine echte Zufallszahl.
> Diese echte Zufallszahl bestimmt hauptsächlich die Dauer der Kommando- 
> Verzögerung.
> Folglich ist die nächste gelesene Zahl erneut eine echte Zufallszahl, usw.
> 
> Zudem beaufschlagt die gesamte Hardware+Software des Computers dem 
> Kommando Verzögerungen.
> Diese addieren sich zu der internen Verzögerung des Kommandos, und sie 
> können größer sein
> als die interne Verzögerung des Kommandos.
> Es sind entsprechende Veränderungen an den ausgegebenen Differenzen und 
> der geregelten
> Bitbreite erkennbar und eindeutig zuzuordnen.
> 
> Das Kommando ist nicht deterministisch in Bezug auf die gelesenen TSC- 
> Werte.
> Ich kann jeglichen Ausgabe-Strom nicht gezielt wiederholen, alle 
> längeren sind
> tendenziell einzigartig.

Für welchen Einsatzbereich planst du diesen Zufallsgenerator?Für ein 
Spiel oder eine Simulation (wo Performance wichtig ist und Algorithmen 
wie Xorshift oder Mersenne-Twister perfekt sind)?

Für ein Sicherheitsprojekt / Kryptografie (wo PRNGs mit RDTSC-Seed tabu 
sind und man stattdessen RDRAND oder Betriebssystem-Entropie wie 
/dev/urandom nutzen muss)?

:)
-- 
Public Webspace von Ingenieurbüro Baumann:
https://hidrive.ionos.com/share/sc0px3oy7x

[toc] | [prev] | [next] | [standalone]

#369575 — Re: Echter Zufall mit iTSC-counter - Bericht und Beweis

FromHelmut Schellong <var@schellong.biz>
Date2026-09-26 15:49 +0200
SubjectRe: Echter Zufall mit iTSC-counter - Bericht und Beweis
Message-ID<1198ig0$bca7$1@solani.org>
In reply to#369564
Leo Baumann wrote on 26.09.2026 04:20:
> Am 25.09.2026 um 23:13 schrieb Helmut Schellong:
>> Ich konnte den Zeitbedarf des Kommandos 'randtsc' von etwa 1,5 h auf 50 s/MB senken.
>> Das sind etwa 1,7 GB pro Tag, bei einem CPU-Kern.
>> Die Qualität konnte ich durch Verringern der Bitbreite halten - immer noch 0 NIST-Fehler.
>> Der Mittelwert der p_values ist im Überblick geringer.
>> Der übergroße Hub zuvor hatte durchaus eine positive Wirkung auf die Qualität.
>>
>> Das Projekt ist nun vorläufig beendet.
>> Ich kann das Kommando nun normal nutzen.
>>
>>
>> Es sind wirklich echte Zufallszahlen!
>> Die erste vom Kommando gelesene Zahl ist sowieso eine echte Zufallszahl.
>> Diese echte Zufallszahl bestimmt hauptsächlich die Dauer der Kommando- Verzögerung.
>> Folglich ist die nächste gelesene Zahl erneut eine echte Zufallszahl, usw.
>>
>> Zudem beaufschlagt die gesamte Hardware+Software des Computers dem Kommando Verzögerungen.
>> Diese addieren sich zu der internen Verzögerung des Kommandos, und sie können größer sein
>> als die interne Verzögerung des Kommandos.
>> Es sind entsprechende Veränderungen an den ausgegebenen Differenzen und der geregelten
>> Bitbreite erkennbar und eindeutig zuzuordnen.
>>
>> Das Kommando ist nicht deterministisch in Bezug auf die gelesenen TSC- Werte.
>> Ich kann jeglichen Ausgabe-Strom nicht gezielt wiederholen, alle längeren sind
>> tendenziell einzigartig.
> 
> Für welchen Einsatzbereich planst du diesen Zufallsgenerator?Für ein Spiel oder eine Simulation (wo Performance wichtig ist und 
> Algorithmen wie Xorshift oder Mersenne-Twister perfekt sind)?
> 
> Für ein Sicherheitsprojekt / Kryptografie (wo PRNGs mit RDTSC-Seed tabu sind und man stattdessen RDRAND oder Betriebssystem-Entropie 
> wie /dev/urandom nutzen muss)?

Ich verfolge damit das Konzept 'One-Time-Pad'.
Ich muß dann nicht meine Archiv-Dateien (bis 6 GB) mehrfach mit PRNGs
verschlüsseln, sondern verwende ein 10 GB großes Pad, mit dem ich
meine Archive per XOR verknüpfe:  v = a xor p

In dem Pad befinden sich echte Zufallszahlen höchster Qualität.
Ich brauche dann immer nur das fertige Pad mit wechselnden Offsets, keinen Generator mehr.
Die Verschlüsselung läuft dann rasend schnell.

Shannon:
Das Verschlüsselungsverfahren ist perfekt sicher, genau dann, wenn die Wahrscheinlichkeitsverteilung
auf dem Schlüsselraum die Gleichverteilung ist und wenn für jeden Klartext und jedes Chiffrat
genau ein Schlüssel existiert.


-- 
Mit freundlichen Grüßen
Helmut Schellong

[toc] | [prev] | [next] | [standalone]

#369582 — Re: Echter Zufall mit iTSC-counter - Bericht und Beweis

FromAlexander Schreiber <als@usenet.thangorodrim.de>
Date2026-09-26 17:06 +0200
SubjectRe: Echter Zufall mit iTSC-counter - Bericht und Beweis
Message-ID<slrn11bfnqu.3b7om.als@mordor.angband.thangorodrim.de>
In reply to#369575
Helmut Schellong <var@schellong.biz> wrote:
> Leo Baumann wrote on 26.09.2026 04:20:
>> Am 25.09.2026 um 23:13 schrieb Helmut Schellong:
>>> Ich konnte den Zeitbedarf des Kommandos 'randtsc' von etwa 1,5 h auf 50 s/MB senken.
>>> Das sind etwa 1,7 GB pro Tag, bei einem CPU-Kern.
>>> Die Qualität konnte ich durch Verringern der Bitbreite halten - immer noch 0 NIST-Fehler.
>>> Der Mittelwert der p_values ist im Überblick geringer.
>>> Der übergroße Hub zuvor hatte durchaus eine positive Wirkung auf die Qualität.
>>>
>>> Das Projekt ist nun vorläufig beendet.
>>> Ich kann das Kommando nun normal nutzen.
>>>
>>>
>>> Es sind wirklich echte Zufallszahlen!
>>> Die erste vom Kommando gelesene Zahl ist sowieso eine echte Zufallszahl.
>>> Diese echte Zufallszahl bestimmt hauptsächlich die Dauer der Kommando- Verzögerung.
>>> Folglich ist die nächste gelesene Zahl erneut eine echte Zufallszahl, usw.
>>>
>>> Zudem beaufschlagt die gesamte Hardware+Software des Computers dem Kommando Verzögerungen.
>>> Diese addieren sich zu der internen Verzögerung des Kommandos, und sie können größer sein
>>> als die interne Verzögerung des Kommandos.
>>> Es sind entsprechende Veränderungen an den ausgegebenen Differenzen und der geregelten
>>> Bitbreite erkennbar und eindeutig zuzuordnen.
>>>
>>> Das Kommando ist nicht deterministisch in Bezug auf die gelesenen TSC- Werte.
>>> Ich kann jeglichen Ausgabe-Strom nicht gezielt wiederholen, alle längeren sind
>>> tendenziell einzigartig.
>> 
>> Für welchen Einsatzbereich planst du diesen Zufallsgenerator?Für ein Spiel oder eine Simulation (wo Performance wichtig ist und 
>> Algorithmen wie Xorshift oder Mersenne-Twister perfekt sind)?
>> 
>> Für ein Sicherheitsprojekt / Kryptografie (wo PRNGs mit RDTSC-Seed tabu sind und man stattdessen RDRAND oder Betriebssystem-Entropie 
>> wie /dev/urandom nutzen muss)?
>
> Ich verfolge damit das Konzept 'One-Time-Pad'.
> Ich muß dann nicht meine Archiv-Dateien (bis 6 GB) mehrfach mit PRNGs
> verschlüsseln, sondern verwende ein 10 GB großes Pad, mit dem ich
> meine Archive per XOR verknüpfe:  v = a xor p

Reinster Sündenfall, also. Um John von Neumann zu zitieren:
  Anyone who considers arithmetical methods of producing random numbers is,
  of course, in a state of sin.                         -- John von Neumann

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 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | de.sci.electronics

csiph-web