Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #369476 > unrolled thread
| Started by | Helmut Schellong <var@schellong.biz> |
|---|---|
| First post | 2026-09-19 01:59 +0200 |
| Last post | 2026-10-04 12:07 +0200 |
| Articles | 20 on this page of 90 — 16 participants |
Back to article view | Back to de.sci.electronics
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
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Andreas Fecht <forum@aftec.de> |
|---|---|
| Date | 2026-09-26 19:14 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <1198ugq$blhc$1@solani.org> |
| In reply to | #369582 |
Am 26.09.2026 um 17:06 schrieb Alexander Schreiber: >> >> 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. Der gute Herr Neumann; ist ein sehr kluger Mensch gewesen im Gegensatz zu manch anderen hier... Unser Geisterfahrer will angeblich eine Datensicherung verschlüsselt auf einem fremden Rechner abspeichern. Manche nennen das Cloud. Das allerbeste ist, dass der Schlüssel bei dieser Methode genau so groß ist wie die Daten. Wo sichert man dann den Schlüssel? Unterm Teppich oder in einer anderen Cloud? Was will man da machen: Keine Ahnung von Datensicherungskonzepten, keine Ahnung von Zufallszahlen, keine Ahnung von seitenkanalunempfindlicher Kryptographie. Manch einer würde sagen: Die dumme Seite sehr stark in ihm ist. Gruß Andreas
[toc] | [prev] | [next] | [standalone]
| From | Christian Weisgerber <naddy@mips.inka.de> |
|---|---|
| Date | 2026-09-26 16:38 +0000 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <slrn11bft7s.2cmm.naddy@lorvorc.mips.inka.de> |
| In reply to | #369582 |
On 2026-09-26, Alexander Schreiber <als@usenet.thangorodrim.de> wrote: > 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 Ich hoffe, dass solche Grundsatzaussagen nicht davon ablenken, dass die Erzeugung von höchsten (kryptografischen) Ansprüchen genügenden Zufallszahlen auf modernen Betriebssystemen ein technisch gelöstes Problem ist. Das Betriebssystem - sammelt Zufälligkeit (Entropie) aus den verfügbaren Quellen, wie die zeitliche Streuung von Ein-/Ausgaben und Netzverkehr oder auch dafür gebauten Quellen wie RDSEED, die letztlich auf stochastische physikalische Prozesse zurückgreifen, - rührt (hash) das alles zusammen, - benutzt es periodisch als Saat für einen Pseudozufallszahlengenerator, wie eine Stromchiffre, der damit einen Zufallszahlenstrom erzeugt. Als Benutzer holt man sich Zufallszahlen über eine entsprechende API vom Betriebssystem bzw. aus der Laufzeitumgebung. Nein, auf den Gruppenkasper gehe ich nicht ein. -- Christian "naddy" Weisgerber naddy@mips.inka.de
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-27 02:07 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <1199mmv$eut8$1@solani.org> |
| In reply to | #369587 |
Christian Weisgerber wrote on 26.09.2026 18:38: > On 2026-09-26, Alexander Schreiber <als@usenet.thangorodrim.de> wrote: > >> 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 > > Ich hoffe, dass solche Grundsatzaussagen nicht davon ablenken, dass > die Erzeugung von höchsten (kryptografischen) Ansprüchen genügenden > Zufallszahlen auf modernen Betriebssystemen ein technisch gelöstes > Problem ist. > > Das Betriebssystem > - sammelt Zufälligkeit (Entropie) aus den verfügbaren Quellen, wie > die zeitliche Streuung von Ein-/Ausgaben und Netzverkehr oder auch > dafür gebauten Quellen wie RDSEED, die letztlich auf stochastische > physikalische Prozesse zurückgreifen, > - rührt (hash) das alles zusammen, > - benutzt es periodisch als Saat für einen Pseudozufallszahlengenerator, > wie eine Stromchiffre, der damit einen Zufallszahlenstrom erzeugt. > > Als Benutzer holt man sich Zufallszahlen über eine entsprechende > API vom Betriebssystem bzw. aus der Laufzeitumgebung. > > Nein, auf den Gruppenkasper gehe ich nicht ein. Das ist stets die beste Lösung. Die Grundsatzaussagen oben treffen auf mich auch gar nicht zu. . Mein Kommando 'randtsc' liest den TSC-Counter und nutzt dessen Werte . für Steuerungszwecke und zur Ausgabe zum Bildschirm und in eine Datei. Vorstehend die komplette Beschreibung der Kernfunktion meines Kommandos. . http://www.schellong.de/txt/nist1.txt Die Ausgabe meines Kommandos wurde von der NIST-Suite dennoch mit einer Bewertung bedacht, so gut, wie ich sie noch nie sah. Es liegt höchste kryptographische Qualität vor. Das ist real! Die Ausgabe des Kommandos ist nicht deterministisch, keine PRNG-Ausgabe und nicht wiederholbar. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-27 12:47 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <119as79$foq7$1@solani.org> |
| In reply to | #369588 |
Helmut Schellong wrote on 27.09.2026 02:07: > Christian Weisgerber wrote on 26.09.2026 18:38: >> On 2026-09-26, Alexander Schreiber <als@usenet.thangorodrim.de> wrote: >> >>> 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 >> >> Ich hoffe, dass solche Grundsatzaussagen nicht davon ablenken, dass >> die Erzeugung von höchsten (kryptografischen) Ansprüchen genügenden >> Zufallszahlen auf modernen Betriebssystemen ein technisch gelöstes >> Problem ist. >> >> Das Betriebssystem >> - sammelt Zufälligkeit (Entropie) aus den verfügbaren Quellen, wie >> die zeitliche Streuung von Ein-/Ausgaben und Netzverkehr oder auch >> dafür gebauten Quellen wie RDSEED, die letztlich auf stochastische >> physikalische Prozesse zurückgreifen, >> - rührt (hash) das alles zusammen, >> - benutzt es periodisch als Saat für einen Pseudozufallszahlengenerator, >> wie eine Stromchiffre, der damit einen Zufallszahlenstrom erzeugt. >> >> Als Benutzer holt man sich Zufallszahlen über eine entsprechende >> API vom Betriebssystem bzw. aus der Laufzeitumgebung. >> >> Nein, auf den Gruppenkasper gehe ich nicht ein. > > Das ist stets die beste Lösung. > > Die Grundsatzaussagen oben treffen auf mich auch gar nicht zu. > > . Mein Kommando 'randtsc' liest den TSC-Counter und nutzt dessen Werte > . für Steuerungszwecke und zur Ausgabe zum Bildschirm und in eine Datei. > > Vorstehend die komplette Beschreibung der Kernfunktion meines Kommandos. > > . http://www.schellong.de/txt/nist1.txt > > Die Ausgabe meines Kommandos wurde von der NIST-Suite dennoch mit einer > Bewertung bedacht, so gut, wie ich sie noch nie sah. > Es liegt höchste kryptographische Qualität vor. > Das ist real! > > Die Ausgabe des Kommandos ist nicht deterministisch, keine PRNG-Ausgabe > und nicht wiederholbar. Das Zauberwort in der Beschreibung oben ist 'Steuerungszwecke'. . sleep( Dbitmask & tsc ); Ich habe eine Verzögerungszeit programmiert, wie vorstehend symbolisch dargestellt. Das erste Lesen des TSC liefert auf jeden Fall einen echt zufälligen Zählerstand. Dieser Zählerstand wird benutzt, um eine Verzögerung mit zufälliger Länge zu bilden. Während dieser Verzögerung inkrementiert der TSC um einen zufälligen Betrag. Dieser Betrag kann einen maximalen Zahlenwert von etwa 100.000.000 haben. Das ist die maximale Differenz zwischen zwei nacheinander gelesenen Zählerständen. Zur binären Ausgabe verwertet werden allerdings wesentlich weniger Bits des TSC: . output( Wbitmask & tsc ); Der hier vorliegende Wertbereich wird folglich sehr oft komplett durchlaufen. Es wird berücksichtigt, daß sich das niederwertigste Bit am häufigsten ändert! Das ist eine vorliegende Unsymmetrie. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-09-27 13:50 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <87o6dincha.fsf@s-bot.de> |
| In reply to | #369575 |
Helmut Schellong <var@schellong.biz> writes: > 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. Irgendwie klingt das so, als sollte der "perfekte" OTP mit variablen Offsets mehrfach verwendet werden. Bei so einer Herangehensweise lässt sich oft schon aus zwei längeren Ciphertexts der Schlüssel regenerieren. -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-27 20:24 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <119bn0f$gdo2$1@solani.org> |
| In reply to | #369593 |
Stefan Wiens wrote on 27.09.2026 13:50:
> Helmut Schellong <var@schellong.biz> writes:
>
>> 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.
>
> Irgendwie klingt das so, als sollte der "perfekte"
> OTP mit variablen Offsets mehrfach verwendet werden.
Das ist im Moment eine Idee von mir, ja.
> Bei so einer Herangehensweise lässt sich oft schon
> aus zwei längeren Ciphertexts der Schlüssel
> regenerieren.
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbb
Bei solchen Offsets kann jedenfalls nichts passieren.
a und b haben ja ihren exklusiven o-Anteil.
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbb
rrrrrrrrrrrrrrrrrrrrrrrrrrrrr r = a ^ o
ssssssssssssssssssss s = b ^ o
Der vorstehende Fall müßte untersucht werden.
r und s sind die per o verschlüsselten a und b.
Der Angreifer verfügt nur über r und s.
Weiter untersuchen werde ich das per Skript.
Nur bei Schnittmenge dürfte ein Angriff Erfolg haben.
--
Mit freundlichen Grüßen
Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-27 21:02 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <119bp7a$gfeq$1@solani.org> |
| In reply to | #369594 |
Helmut Schellong wrote on 27.09.2026 20:24: > Stefan Wiens wrote on 27.09.2026 13:50: >> Helmut Schellong <var@schellong.biz> writes: >> >>> 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. >> >> Irgendwie klingt das so, als sollte der "perfekte" >> OTP mit variablen Offsets mehrfach verwendet werden. > > Das ist im Moment eine Idee von mir, ja. > >> Bei so einer Herangehensweise lässt sich oft schon >> aus zwei längeren Ciphertexts der Schlüssel >> regenerieren. > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > aaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbb > > Bei solchen Offsets kann jedenfalls nichts passieren. > a und b haben ja ihren exklusiven o-Anteil. > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > aaaaaaaaaaaaaaaaaaaaaaaaaaaaa > bbbbbbbbbbbbbbbbbbbb > rrrrrrrrrrrrrrrrrrrrrrrrrrrrr r = a ^ o > ssssssssssssssssssss s = b ^ o > > Der vorstehende Fall müßte untersucht werden. > r und s sind die per o verschlüsselten a und b. > Der Angreifer verfügt nur über r und s. > Weiter untersuchen werde ich das per Skript. > Nur bei Schnittmenge dürfte ein Angriff Erfolg haben. Es war mir klar, daß ich mit Offsets und Schnittmenge gegen 'one time' verstoße. Die mögliche Folge davon war mir bis dahin in ihrem Ausmaß noch nicht klar. Ich kann auch alle paar Monate neue Pads generieren. Die Untersuchung per Skript werde ich allerdings dennoch durchführen. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-28 20:42 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <119ecds$i9t6$1@solani.org> |
| In reply to | #369594 |
Helmut Schellong wrote on 27.09.2026 20:24:
> Stefan Wiens wrote on 27.09.2026 13:50:
>> Helmut Schellong <var@schellong.biz> writes:
>>
>>> 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.
>>
>> Irgendwie klingt das so, als sollte der "perfekte"
>> OTP mit variablen Offsets mehrfach verwendet werden.
>
> Das ist im Moment eine Idee von mir, ja.
>
>> Bei so einer Herangehensweise lässt sich oft schon
>> aus zwei längeren Ciphertexts der Schlüssel
>> regenerieren.
>
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbb
>
> Bei solchen Offsets kann jedenfalls nichts passieren.
> a und b haben ja ihren exklusiven o-Anteil.
>
> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> bbbbbbbbbbbbbbbbbbbb
> rrrrrrrrrrrrrrrrrrrrrrrrrrrrr r = a ^ o
> ssssssssssssssssssss s = b ^ o
>
> Der vorstehende Fall müßte untersucht werden.
> r und s sind die per o verschlüsselten a und b.
> Der Angreifer verfügt nur über r und s.
> Weiter untersuchen werde ich das per Skript.
> Nur bei Schnittmenge dürfte ein Angriff Erfolg haben.
Ich habe das nun per Skript etwas untersucht.
let "r==(va^vo) && s==(vb^vo)" && { echo $n: $vo $va $vb; let ++n; }
Der Ausdruck hat zur Folge, daß von knapp 17 Mio Schleifendurchläufen
genau 256 zu einer Ausgabe führen.
Alle möglichen OTP-Werte (o) 0..255 passen zu irgendeiner Kombination von a und b.
Der Informationsgehalt ist folglich Null.
Wahrscheinlich werde ich da nicht weiter untersuchen.
Aber ich halte erfolgreiche Angriffe für möglich, weil zwei durch ein und denselben
Pad verschlüsselte Dateien durch eine Schnittmenge prinzipiell eine Verknüpfung bilden.
--
Mit freundlichen Grüßen
Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-09-26 04:54 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <1197c5c$d7sk$1@solani.org> |
| In reply to | #369562 |
Am 25.09.2026 um 23:13 schrieb Helmut Schellong: [...] Es macht mir keinen Spaß auf kleine Leute herumzuhacken, aber Du bist ein Geisterfahrer, der gegen alle AI der Welt anfährt. :) -- Public Webspace von Ingenieurbüro Baumann: https://hidrive.ionos.com/share/sc0px3oy7x
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-26 16:22 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <1198ke0$bdk2$2@solani.org> |
| In reply to | #369565 |
Leo Baumann wrote on 26.09.2026 04:54: > Am 25.09.2026 um 23:13 schrieb Helmut Schellong: > [...] > > Es macht mir keinen Spaß auf kleine Leute herumzuhacken, aber Du bist ein Geisterfahrer, der gegen alle AI der Welt anfährt. Du bist ein Witzbold, der unverständliche Aussagen abliefert. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-09-26 16:29 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <1198ksi$be39$1@solani.org> |
| In reply to | #369578 |
Am 26.09.2026 um 16:22 schrieb Helmut Schellong: > Leo Baumann wrote on 26.09.2026 04:54: >> Am 25.09.2026 um 23:13 schrieb Helmut Schellong: >> [...] >> >> Es macht mir keinen Spaß auf kleine Leute herumzuhacken, aber Du bist >> ein Geisterfahrer, der gegen alle AI der Welt anfährt. > > Du bist ein Witzbold, der unverständliche Aussagen abliefert. Für ein Kryptografieprojekt sind PRNGs mit RDTSc-Seed tabu! :) -- Public Webspace von Ingenieurbüro Baumann: https://hidrive.ionos.com/share/sc0px3oy7x
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-26 16:35 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <1198l6v$be8h$1@solani.org> |
| In reply to | #369579 |
Leo Baumann wrote on 26.09.2026 16:29: > Am 26.09.2026 um 16:22 schrieb Helmut Schellong: >> Leo Baumann wrote on 26.09.2026 04:54: >>> Am 25.09.2026 um 23:13 schrieb Helmut Schellong: >>> [...] >>> >>> Es macht mir keinen Spaß auf kleine Leute herumzuhacken, aber Du bist ein Geisterfahrer, der gegen alle AI der Welt anfährt. >> >> Du bist ein Witzbold, der unverständliche Aussagen abliefert. > > Für ein Kryptografieprojekt sind PRNGs mit RDTSc-Seed tabu! Ich verwende allerdings keinen rdtsc-seed, auch keinen PRNG, sondern etwas gänzlich Anderes! -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-09-26 16:38 +0200 |
| Subject | Re: Echter Zufall mit iTSC-counter - Bericht und Beweis |
| Message-ID | <1198le5$bedh$1@solani.org> |
| In reply to | #369580 |
Am 26.09.2026 um 16:35 schrieb Helmut Schellong: >> Für ein Kryptografieprojekt sind PRNGs mit RDTSc-Seed tabu! > > Ich verwende allerdings keinen rdtsc-seed, auch keinen PRNG, sondern > etwas gänzlich Anderes! haha - einen rdtsc-seed! :) -- Public Webspace von Ingenieurbüro Baumann: https://hidrive.ionos.com/share/sc0px3oy7x
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-22 10:11 +0200 |
| Message-ID | <slrn11b4e1q.ufqf.als@mordor.angband.thangorodrim.de> |
| In reply to | #369520 |
Helmut Schellong <var@schellong.biz> wrote:
> 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.
Präzise Uhren alleine eignen sich nicht als Zufallsquellen.
>> Nicht geeignet für Kryptographie, leicht manipulierbar und vorhersehbar!
>
> Und nochmals Nein.
Beweis durch Aufstampfen mit dem Fuss, oder wie?
>> Also Mist!
>
> Keineswegs.
Tja ..
> 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!
Und Du verbreitest mal wieder Unfug. Der TSC zählt clock cycles seit
CPU reset. Je nach CPU-Variante wird entweder mit konstanter Frequenz
gezählt oder es wird mit der tatsächlichen aktuellen Core-Frequenz
gezählt, die durch power management variiert wird. Ja, das heisst das
je nach CPU-Variante verschiedene cores in derselben CPU andere
Zählerwerte haben.
Und auf hinreichend modernen CPUs läuft der TSC eh als iTSC (invariant
Time Stamp Counter), d.h. mit es wird mit konstanter Frequenz gezählt,
unabhängig von aktueller Prozessorfrequenz oder power management state.
Der iTSC ist damit im wesentlichen eine CPU-interne Präzisionsuhr und
wird auch so verwendet, sowohl vom Kernel als auch von Applikations-
software.
> Alles ist dabei unvorhersehbar, weil von der Hardware bestimmt.
Nein. Eine typische - und meist durchaus erwünschte - Eigenschaft einer
Uhr (und das ist der iTSC) ist die präzise Vorhersagbarkeit.
Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-22 15:04 +0200 |
| Message-ID | <118tucm$6bt0$1@solani.org> |
| In reply to | #369525 |
Alexander Schreiber wrote on 22.09.2026 10:11: > Helmut Schellong <var@schellong.biz> wrote: >> 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. > > Präzise Uhren alleine eignen sich nicht als Zufallsquellen. > >>> Nicht geeignet für Kryptographie, leicht manipulierbar und vorhersehbar! >> >> Und nochmals Nein. > > Beweis durch Aufstampfen mit dem Fuss, oder wie? > >>> Also Mist! >> >> Keineswegs. > > Tja .. > >> 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! Du hast eines (absichtlich) nicht bemerkt: Daß ich aus der Sicht eines laufenden Programms schrieb, welches den TSC wiederholt liest. Jeder Zeitbedarf in diesem Programm läßt quasi den TSC weiter hochzählen. Insofern ist Dein Beitrag in diesem Posting alberner Quatsch. > Und Du verbreitest mal wieder Unfug. Der TSC zählt clock cycles seit > CPU reset. Je nach CPU-Variante wird entweder mit konstanter Frequenz > gezählt oder es wird mit der tatsächlichen aktuellen Core-Frequenz > gezählt, die durch power management variiert wird. Ja, das heisst das > je nach CPU-Variante verschiedene cores in derselben CPU andere > Zählerwerte haben. Zum iTSC las ich, daß dieser ausschließlich mit der Nennfrequenz der CPU getaktet ist. > Und auf hinreichend modernen CPUs läuft der TSC eh als iTSC (invariant > Time Stamp Counter), d.h. mit es wird mit konstanter Frequenz gezählt, > unabhängig von aktueller Prozessorfrequenz oder power management state. > Der iTSC ist damit im wesentlichen eine CPU-interne Präzisionsuhr und > wird auch so verwendet, sowohl vom Kernel als auch von Applikations- > software. > >> Alles ist dabei unvorhersehbar, weil von der Hardware bestimmt. > > Nein. Eine typische - und meist durchaus erwünschte - Eigenschaft einer > Uhr (und das ist der iTSC) ist die präzise Vorhersagbarkeit. Ich schrieb aus der Sicht eines laufenden Programms, welches den TSC wiederholt liest. Jeder Zeitbedarf in diesem Programm läßt quasi den TSC weiter hochzählen. Ich habe den TSC schon vor nicht wenigen Jahren dafür benutzt, um die Laufzeit von zeitlich langen Instruktionen zu messen - also als Uhr. Die Instruktionen habe ich jeweils vielfach hintereinander wiederholt. Ich kenne (folglich) fast alle Aspekte in diesem Zusammenhang seit 'ewigen' Zeiten. Das kann von mir erwartet werden, als jemand, der seit 1985 als Entwicklungsingenieur für Elektronik und Programmierung arbeitete. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-22 17:59 +0200 |
| Message-ID | <slrn11b59ef.13fb7.als@mordor.angband.thangorodrim.de> |
| In reply to | #369527 |
Helmut Schellong <var@schellong.biz> wrote:
> Alexander Schreiber wrote on 22.09.2026 10:11:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> 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.
>>
>> Präzise Uhren alleine eignen sich nicht als Zufallsquellen.
>>
>>>> Nicht geeignet für Kryptographie, leicht manipulierbar und vorhersehbar!
>>>
>>> Und nochmals Nein.
>>
>> Beweis durch Aufstampfen mit dem Fuss, oder wie?
>>
>>>> Also Mist!
>>>
>>> Keineswegs.
>>
>> Tja ..
>>
>>> 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!
>
> Du hast eines (absichtlich) nicht bemerkt:
> Daß ich aus der Sicht eines laufenden Programms schrieb, welches den TSC wiederholt liest.
> Jeder Zeitbedarf in diesem Programm läßt quasi den TSC weiter hochzählen.
Du implizierst eine nicht vorhandene Kausalität. Der TSC läuft weiter, egal
ob das Programm "Zeitbedarf hat" oder nicht, er läuft auch weiter wenn das
Programm angehalten wurde - es gibt zwischen dem TSC Zustand und dem
Programm keine kausale Verbindung.
> Insofern ist Dein Beitrag in diesem Posting alberner Quatsch.
Für den Quatsch bist Du zuständig, da will ich Dir mal nicht reinpfuschen.
>> Und Du verbreitest mal wieder Unfug. Der TSC zählt clock cycles seit
>> CPU reset. Je nach CPU-Variante wird entweder mit konstanter Frequenz
>> gezählt oder es wird mit der tatsächlichen aktuellen Core-Frequenz
>> gezählt, die durch power management variiert wird. Ja, das heisst das
>> je nach CPU-Variante verschiedene cores in derselben CPU andere
>> Zählerwerte haben.
>
> Zum iTSC las ich, daß dieser ausschließlich mit der Nennfrequenz der CPU getaktet ist.
Implementationsdetail. Verlassen kann man sich darauf, das er mit konstanter
Frequenz hochzählt, unabhängig vom CPU Zustand (z.B. Frequenzanpassungen,
P,C,T-States,...).
>> Und auf hinreichend modernen CPUs läuft der TSC eh als iTSC (invariant
>> Time Stamp Counter), d.h. mit es wird mit konstanter Frequenz gezählt,
>> unabhängig von aktueller Prozessorfrequenz oder power management state.
>> Der iTSC ist damit im wesentlichen eine CPU-interne Präzisionsuhr und
>> wird auch so verwendet, sowohl vom Kernel als auch von Applikations-
>> software.
>>
>>> Alles ist dabei unvorhersehbar, weil von der Hardware bestimmt.
>>
>> Nein. Eine typische - und meist durchaus erwünschte - Eigenschaft einer
>> Uhr (und das ist der iTSC) ist die präzise Vorhersagbarkeit.
>
> Ich schrieb aus der Sicht eines laufenden Programms, welches den TSC wiederholt liest.
> Jeder Zeitbedarf in diesem Programm läßt quasi den TSC weiter hochzählen.
Nein, siehe oben.
> Ich habe den TSC schon vor nicht wenigen Jahren dafür benutzt, um die Laufzeit
> von zeitlich langen Instruktionen zu messen - also als Uhr.
> Die Instruktionen habe ich jeweils vielfach hintereinander wiederholt.
Das ist eine der Standardanwendungen für u.a. Microbenchmarks, ja.
Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-22 19:38 +0200 |
| Message-ID | <118uee2$6ord$1@solani.org> |
| In reply to | #369531 |
Alexander Schreiber wrote on 22.09.2026 17:59: > Helmut Schellong <var@schellong.biz> wrote: >> Alexander Schreiber wrote on 22.09.2026 10:11: >>> Helmut Schellong <var@schellong.biz> wrote: >>>> 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. >>> >>> Präzise Uhren alleine eignen sich nicht als Zufallsquellen. Richtig, in meinem Programm wirkt ja auch nicht der TSC alleine. Bei Weitem nicht. >>>>> Nicht geeignet für Kryptographie, leicht manipulierbar und vorhersehbar! >>>> >>>> Und nochmals Nein. >>> >>> Beweis durch Aufstampfen mit dem Fuss, oder wie? >>> >>>>> Also Mist! >>>> >>>> Keineswegs. >>> >>> Tja .. >>> >>>> 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! >> >> Du hast eines (absichtlich) nicht bemerkt: >> Daß ich aus der Sicht eines laufenden Programms schrieb, welches den TSC wiederholt liest. >> Jeder Zeitbedarf in diesem Programm läßt quasi den TSC weiter hochzählen. > > Du implizierst eine nicht vorhandene Kausalität. Der TSC läuft weiter, egal > ob das Programm "Zeitbedarf hat" oder nicht, er läuft auch weiter wenn das > Programm angehalten wurde - es gibt zwischen dem TSC Zustand und dem > Programm keine kausale Verbindung. Ja, genau richtig. Dennoch läßt das Programm aus seiner eigenen Sicht quasi den TSC weiter hochzählen. Weil das Programm schließlich selbst den nächsten Wert des TSC liest, der dann höher ist, nach jedem Stopp. Ich schrieb selbst mehrfach, seit Tagen, daß der TSC _unabhängig_ arbeitet. Wieso erklärst Du mir das immer wieder? Der TSC beginnt mit seinem Hochzählen, sobald die CPU ihren Reset nach PowerUp erledigt hat. >> Insofern ist Dein Beitrag in diesem Posting alberner Quatsch. > > Für den Quatsch bist Du zuständig, da will ich Dir mal nicht reinpfuschen. > >>> Und Du verbreitest mal wieder Unfug. Der TSC zählt clock cycles seit >>> CPU reset. Je nach CPU-Variante wird entweder mit konstanter Frequenz >>> gezählt oder es wird mit der tatsächlichen aktuellen Core-Frequenz >>> gezählt, die durch power management variiert wird. Ja, das heisst das >>> je nach CPU-Variante verschiedene cores in derselben CPU andere >>> Zählerwerte haben. >> >> Zum iTSC las ich, daß dieser ausschließlich mit der Nennfrequenz der CPU getaktet ist. > > Implementationsdetail. Verlassen kann man sich darauf, das er mit konstanter > Frequenz hochzählt, unabhängig vom CPU Zustand (z.B. Frequenzanpassungen, > P,C,T-States,...). > >>> Und auf hinreichend modernen CPUs läuft der TSC eh als iTSC (invariant >>> Time Stamp Counter), d.h. mit es wird mit konstanter Frequenz gezählt, >>> unabhängig von aktueller Prozessorfrequenz oder power management state. >>> Der iTSC ist damit im wesentlichen eine CPU-interne Präzisionsuhr und >>> wird auch so verwendet, sowohl vom Kernel als auch von Applikations- >>> software. >>> >>>> Alles ist dabei unvorhersehbar, weil von der Hardware bestimmt. >>> >>> Nein. Eine typische - und meist durchaus erwünschte - Eigenschaft einer >>> Uhr (und das ist der iTSC) ist die präzise Vorhersagbarkeit. >> >> Ich schrieb aus der Sicht eines laufenden Programms, welches den TSC wiederholt liest. >> Jeder Zeitbedarf in diesem Programm läßt quasi den TSC weiter hochzählen. > > Nein, siehe oben. Natürlich ist das so. Wenn im Programm ein Stopp kommt, dann bleibt das Programm stehen, aber der TSC tut dies nicht. Und je länger der Stopp ist, desto höher wird der nächste gelesene TSC-Wert. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-21 21:31 +0200 |
| Message-ID | <slrn11b31gn.ltko.als@mordor.angband.thangorodrim.de> |
| In reply to | #369515 |
Helmut Schellong <var@schellong.biz> wrote:
> 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.
Nur mit dem kleinen Detail das rdtsc den internen Time Stamp Counter
ausliest, mit der Konsequenz das ein so geseedeter PRNG zwar für
Würfelspielchen ausreicht, man damit aber keine kryptographisch
sicheren Zufallszahlen generieren kann.
Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-22 15:22 +0200 |
| Message-ID | <118tvem$6cq9$1@solani.org> |
| In reply to | #369523 |
Alexander Schreiber wrote on 21.09.2026 21:31: > Helmut Schellong <var@schellong.biz> wrote: >> 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. > > Nur mit dem kleinen Detail das rdtsc den internen Time Stamp Counter > ausliest, mit der Konsequenz das ein so geseedeter PRNG zwar für > Würfelspielchen ausreicht, man damit aber keine kryptographisch > sicheren Zufallszahlen generieren kann. Das kann so gesagt werden. Deshalb kann ich in meinem Kommando 'randtsc' die Anzahl Bits einstellen, die ich von LSB her jedem TSC-Wert entnehme. Weiterhin habe ich ein Delay programmiert, ebenso mit einstellbarer Anzahl Bits. Dieses Delay wird dem TSC-Wert selbst entnommen, ist also eine Rückkopplung. Bei Bits=0 ist diese Zusatz-Verzögerung ebenso 0. Es ist für mich ganz sicher, daß ich einen sogenannten One-Time-Pad mit _diesen_ Zahlenfolgen konstruieren kann. Meine visuelle Analyse reicht eigentlich schon für diese Aussage. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-22 17:25 +0200 |
| Message-ID | <slrn11b57eg.13fb7.als@mordor.angband.thangorodrim.de> |
| In reply to | #369528 |
Helmut Schellong <var@schellong.biz> wrote:
> Alexander Schreiber wrote on 21.09.2026 21:31:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> 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.
>>
>> Nur mit dem kleinen Detail das rdtsc den internen Time Stamp Counter
>> ausliest, mit der Konsequenz das ein so geseedeter PRNG zwar für
>> Würfelspielchen ausreicht, man damit aber keine kryptographisch
>> sicheren Zufallszahlen generieren kann.
>
> Das kann so gesagt werden.
> Deshalb kann ich in meinem Kommando 'randtsc' die Anzahl Bits einstellen, die ich
> von LSB her jedem TSC-Wert entnehme.
>
> Weiterhin habe ich ein Delay programmiert, ebenso mit einstellbarer Anzahl Bits.
> Dieses Delay wird dem TSC-Wert selbst entnommen, ist also eine Rückkopplung.
> Bei Bits=0 ist diese Zusatz-Verzögerung ebenso 0.
>
> Es ist für mich ganz sicher, daß ich einen sogenannten One-Time-Pad
> mit _diesen_ Zahlenfolgen konstruieren kann.
Rein technisch kann man ein One-Time-Pad auch mit einer Serie von lauter
Nullen konstruieren. Ist zwar für ernstzunehmende Verschlüsselung nicht
sinnvoll, aber man kann das so machen (Ok, sinnvoller Einsatz für sowas
wäre ein kurzer Test, um grobe Fehler in der Implementation zu finden).
> Meine visuelle Analyse reicht eigentlich schon für diese Aussage.
Erfahrene Kryptographen benutzen detaillierte stochastische Analysen
um die Qualität von Zufallszahlenserien zu ermitteln während unser
Helmut solcherlei Krücken nicht braucht und das mit einem kurzen Blick
einschätzen kann. Was sind wir immens beeindruckt.
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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | de.sci.electronics
csiph-web