Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #369613 > unrolled thread
| Started by | Helmut Schellong <var@schellong.biz> |
|---|---|
| First post | 2026-09-29 13:06 +0200 |
| Last post | 2026-09-29 18:46 +0200 |
| Articles | 8 on this page of 88 — 14 participants |
Back to article view | Back to de.sci.electronics
random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 13:06 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 15:45 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 18:37 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 21:33 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 22:41 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 22:51 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 00:26 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 02:05 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 10:45 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 10:57 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:33 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-30 15:31 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 16:25 +0200
Re: random_rdtsc und random_rdrand Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-30 17:17 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-04 02:45 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 11:58 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 01:31 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-30 01:23 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 10:19 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 05:16 +0200
Re: random_rdtsc und random_rdrand Marte Schwarz <marte.schwarz@gmx.de> - 2026-09-30 08:01 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 08:11 +0200
Re: random_rdtsc und random_rdrand Andreas Fecht <forum@aftec.de> - 2026-09-30 09:49 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 09:55 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:23 +0200
Re: random_rdtsc und random_rdrand Michael Schwingen <news-1513678000@discworld.dascon.de> - 2026-09-30 14:48 +0000
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 17:17 +0200
Re: random_rdtsc und random_rdrand Bernd Laengerich <Bernd.Laengerich@web.de> - 2026-09-30 09:59 +0200
Re: random_rdtsc und random_rdrand Eric Bruecklmeier <u@5i7.de> - 2026-09-30 09:13 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:07 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 11:03 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 16:58 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 17:33 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 18:34 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 18:12 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 18:25 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 19:16 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 18:45 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 19:25 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 20:10 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 20:49 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 20:55 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-30 20:55 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-30 23:32 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-01 00:50 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-01 18:35 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-01 18:58 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 06:29 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 16:02 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 16:11 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 22:00 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 22:02 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 22:09 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 22:20 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 23:11 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-02 23:51 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 11:57 +0200
Re: random_rdtsc und random_rdrand Marte Schwarz <marte.schwarz@gmx.de> - 2026-10-03 11:30 +0200
Re: random_rdtsc und random_rdrand Heinz Schmitz <sch@example.invalid> - 2026-10-03 16:59 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 17:29 +0200
Re: random_rdtsc und random_rdrand Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-10-03 13:33 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-02 16:19 +0200
Re: random_rdtsc und random_rdrand Christian Weisgerber <naddy@mips.inka.de> - 2026-10-02 19:24 +0000
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-02 22:04 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-03 14:49 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-03 15:21 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 17:26 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-03 17:35 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 00:48 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-04 00:52 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 01:33 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-04 02:04 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 11:48 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-04 11:56 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-04 03:41 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-04 03:50 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 12:20 +0200
Re: random_rdtsc und random_rdrand Stefan Wiens <s.wi@gmx.net> - 2026-10-04 12:46 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 17:39 +0200
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 01:33 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-03 17:12 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-10-03 17:47 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-04 00:59 +0200
Re: random_rdtsc und random_rdrand Kai-Martin Knaak <kaimartin@invalid.invalid> - 2026-10-04 22:49 +0000
Re: random_rdtsc und random_rdrand Arno Welzel <usenet@arnowelzel.de> - 2026-10-05 01:36 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-10-02 21:49 +0200
Re: random_rdtsc und random_rdrand Leo Baumann <ib@leobaumann.de> - 2026-09-29 15:52 +0200
Re: random_rdtsc und random_rdrand Helmut Schellong <var@schellong.biz> - 2026-09-29 18:46 +0200
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-03 17:12 +0200 |
| Message-ID | <119r5vp$rbne$1@solani.org> |
| In reply to | #369686 |
Stefan Wiens wrote on 03.10.2026 14:49: > Stefan "Ingrid" Wiens <s.wi@gmx.net> writes: > >> Christian Weisgerber <naddy@mips.inka.de> writes: >> >>> On 2026-10-02, Stefan Wiens <s.wi@gmx.net> wrote: >>> >>>> Was ist zufällig an der Zeit seit dem Reset? >>> >>> Erstmal wäre zu prüfen, _ob_ das Ergebnis schwankt, dann kann man ggfs. >>> fragen _warum_. >>> >>> Ich habe vor einigen Jahren mal geschaut, was für einen initialen >>> TSC-Wert ein x86-BIOS-Bootloader ausliest, und die unteren Bits >>> haben tatsächlich wild gewechselt. Warum auch immer. Ein bisschen >>> Entropie scheint da schon drinzustecken. >> >> Der volle 64-Bit-Wertebereich nach dem Reset >> wird wohl kaum je erreicht, denn irgendwann steht >> ein Reboot an. >> >> Wieviel Entropie in den niedrigen Bits steckt, >> ist ebenso unklar. >> >> Und evtl. kann der TSC von einem anderen Core >> belauscht werden, das reduziert zwar nicht >> die Zufälligkeit, aber die kryptographische >> Sicherheit. > > So wie das aussieht, wird im Linux-Kernel > dem Ergebnis von rdtsc keinerlei Entropie > gutgeschrieben, es gibt wohl Ausnahmefälle > nach dem Booten, wo evtl. ein Bit > gutgeschrieben wird. Das ist irrelevant, weil hier _erneut_ eine völlig isolierte Betrachtung des TSC vorgenommen wird. Das ist schlicht dumm. > Das ist ein riesiger Unterschied zu der > naiven Implementierung, die hier vorgestellt > wurde. Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! Die NIST-Tests weisen 21-, 13- und 2-, 20-mal das Vorkommen des Worts FAILURE aus. Der Reihe nach für 'rdrand', 'rdseed', 'randtsc langsam', 'randtsc schnell'. Der Reihe nach: http://www.schellong.de/txt/nist4.txt http://www.schellong.de/txt/nist6.txt http://www.schellong.de/txt/nist1.txt http://www.schellong.de/txt/nist5.txt Der NIST-Test 800-22 mit 188 Tests ist relevant und beweiskräftig. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-10-03 17:47 +0200 |
| Message-ID | <119r831$rde6$1@solani.org> |
| In reply to | #369689 |
Am 03.10.2026 um 17:12 schrieb Helmut Schellong: > Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten > Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) liefert keine kryptografisch sicheren Zufallszahlen, weil es sich dabei um eine deterministische Zeitmessung und nicht um eine echte Entropiequelle handelt. Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im Prozessor basieren, misst RDTSC lediglich die Anzahl der CPU-Taktzyklen seit dem letzten Reset. -- Public Webspace von Ingenieurbüro Baumann: https://hidrive.ionos.com/share/sc0px3oy7x
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-04 00:59 +0200 |
| Message-ID | <119s1bv$rvja$1@solani.org> |
| In reply to | #369693 |
Leo Baumann wrote on 03.10.2026 17:47: > Am 03.10.2026 um 17:12 schrieb Helmut Schellong: >> Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten >> Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! > > random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) liefert keine kryptografisch sicheren Zufallszahlen, weil es sich > dabei um eine deterministische Zeitmessung und nicht um eine echte Entropiequelle handelt. Der NIST-Test bestätigt jedoch die kryptographische Sicherheit. Genau dafür ist er gemacht! > Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im Prozessor basieren, misst RDTSC lediglich die Anzahl der > CPU-Taktzyklen seit dem letzten Reset. Nein, das ist wiederholt komplett falsch. Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des 'randtsc' nicht gäbe. Du verhältst Dich mittlerweile ausgeprägt borniert. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Kai-Martin Knaak <kaimartin@invalid.invalid> |
|---|---|
| Date | 2026-10-04 22:49 +0000 |
| Message-ID | <119ul56$sk73$1@gwaiyur.mb-net.net> |
| In reply to | #369701 |
On Sun, 4 Oct 2026 00:59:25 +0200, Helmut Schellong wrote: > Leo Baumann wrote on 03.10.2026 17:47: >> Am 03.10.2026 um 17:12 schrieb Helmut Schellong: >>> Diese angeblich naive Implementation (randtsc) hat sich den >>> hochgelobten Instruktionen 'rdrand' und 'rdseed' als _überlegen_ >>> herausgestellt! >> >> random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) >> liefert keine kryptografisch sicheren Zufallszahlen, weil es sich dabei >> um eine deterministische Zeitmessung und nicht um eine echte >> Entropiequelle handelt. > > Der NIST-Test bestätigt jedoch die kryptographische Sicherheit. > Genau dafür ist er gemacht! > >> Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im >> Prozessor basieren, misst RDTSC lediglich die Anzahl der CPU-Taktzyklen >> seit dem letzten Reset. > > Nein, das ist wiederholt komplett falsch. > Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des > 'randtsc' nicht gäbe. Das ist legitim, weil kein Algorithmus die Entropie des Ergebnisses von RDTSC vermehren kann. Das ist ähnlich fundamental wie in der Physik die Tatsache, dass keine Vorrichtung den Impuls oder die Energie eines geschlossenen Systems verändern kann. > Du verhältst Dich mittlerweile ausgeprägt borniert. Ja, alles Geisterfahrer hier... ---<)kaimartin(>---
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2026-10-05 01:36 +0200 |
| Message-ID | <119unt6$c2op$5@dont-email.me> |
| In reply to | #369701 |
Helmut Schellong, 2026-10-04 00:59: > Leo Baumann wrote on 03.10.2026 17:47: >> Am 03.10.2026 um 17:12 schrieb Helmut Schellong: >>> Diese angeblich naive Implementation (randtsc) hat sich den hochgelobten >>> Instruktionen 'rdrand' und 'rdseed' als _überlegen_ herausgestellt! >> >> random_rdtsc (bzw. das Auslesen des Time-Stamp Counters via RDTSC) liefert keine kryptografisch sicheren Zufallszahlen, weil es sich >> dabei um eine deterministische Zeitmessung und nicht um eine echte Entropiequelle handelt. > > Der NIST-Test bestätigt jedoch die kryptographische Sicherheit. > Genau dafür ist er gemacht! > >> Während RDRAND und RDSEED auf physikalischen Zufallsgeneratoren im Prozessor basieren, misst RDTSC lediglich die Anzahl der >> CPU-Taktzyklen seit dem letzten Reset. > > Nein, das ist wiederholt komplett falsch. > Es betrachtet den TSC erneut isoliert, als ob es den Algorithmus des 'randtsc' nicht gäbe. Den gibt es ja auch nicht. Den Quelltext zeigst Du nicht, weil den hier angeblich niemand versteht. Das ist einfach nur lächerlich. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-10-02 21:49 +0200 |
| Message-ID | <119p1rp$psm8$1@solani.org> |
| In reply to | #369673 |
Stefan Wiens wrote on 02.10.2026 16:19: > Helmut Schellong <var@schellong.biz> writes: > >> Leo Baumann wrote on 02.10.2026 06:29: >>> Am 01.10.2026 um 18:35 schrieb Helmut Schellong: >>>> Das Zauberwort in der Beschreibung oben ist 'Steuerungszwecke'. >>>> >>>> . sleep( D_bitmask & tsc ); >>> Die Anweisung erzeugt keine Entropie! >> >> Doch, weil die Werte vom TSC zufällig sind und weil die Wirkungen >> der unterlegten externen HW+SW permanent wirken. > > Was ist zufällig an der Zeit seit dem Reset? Es kommt auf das konkrete Lesen des Zählerstandes des TSC an! Das ist das Zufällige! Aus altem Posting: 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. Der TSC inkrementiert etwa 3000-mal innerhalb einer Mikrosekunde. Niemand kann innerhalb von Piko-Sekunden eine mechanische Taste drücken. Beispielsweise die Enter-Taste, um das Kommando aufzurufen. In der Zeit vor Beginn des Taste-Drückens hat der TSC zudem viel mehr gezählt, als während des Taste-Drückens. Die erste gelesene Zahl vom TSC ist doch zufällig - zufälliger geht es nicht so einfach - RDRAND ist graduell zufälliger. Die Prellzeit einer Taste liegt bei vielleicht 20 ms. Mein TSC zählt währenddessen 62111801 Schritte hoch. > Aber du hast auch belegt, dass du mit echten > Zufallszahlen nichts sinnvolles anfangen kannst, > wenn du sie mehrfach verwendest. Du hast nun den OTP-Gedanken hervorgeholt. Es gibt für echte Zufallszahlen mehrere Anwendungsfälle. Beispielsweise, wenn man 16 kleine Zahlen für ein kleines Array braucht, um ein Einschleifen, eine Zusammenführung optimal zu gestalten. Beispielsweise können die beiden großen Arrays (2x256x32bit) im Algorithmus Dragon echte Zufallszahlen enthalten. Die Verwendungsart isoliert sie nach außen. Für große OTP-Dateien hatte ich eine Verwendung von Offsets überlegt. Bei meiner Erfahrung kann ich das im Detail so gestalten, daß es kaum möglich ist, erfolgreich dagegen zu agieren: Und zwar Offsets im _gesamten_ Raum des OTP verteilt. Der Byte-Strom wird im Kreis herum, und vorwärts oder rückwärts abgetastet. Es gibt hier noch weitere einfache Möglichkeiten, um Verwirrung zu stiften! -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Leo Baumann <ib@leobaumann.de> |
|---|---|
| Date | 2026-09-29 15:52 +0200 |
| Message-ID | <119gfrl$gvoq$1@solani.org> |
| In reply to | #369613 |
Am 29.09.2026 um 13:06 schrieb Helmut Schellong: > Das ist allerdings eine Abwägung auf sehr hohem Level. Der RDTSC-Befehl (Read Time-Stamp Counter) misst lediglich die vergangen CPU-Taktzyklen seit dem Systemstart. Er ist aus zwei Hauptgründen weder ein echter noch ein kryptografisch sicherer Zufallszahlengenerator: Er besitzt keine physikalische Zufallsquelle (Entropie) und seine Werte sind für Angreifer vorhersehbar. :) -- 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-29 18:46 +0200 |
| Message-ID | <119gq0v$h7r4$1@solani.org> |
| In reply to | #369615 |
Leo Baumann wrote on 29.09.2026 15:52: > Am 29.09.2026 um 13:06 schrieb Helmut Schellong: >> Das ist allerdings eine Abwägung auf sehr hohem Level. > > Der RDTSC-Befehl (Read Time-Stamp Counter) misst lediglich die vergangen CPU-Taktzyklen seit dem Systemstart. Er ist aus zwei > Hauptgründen weder ein echter noch ein kryptografisch sicherer Zufallszahlengenerator: Er besitzt keine physikalische Zufallsquelle > (Entropie) und seine Werte sind für Angreifer vorhersehbar. Vorstehende Aussage ist nur zutreffend, wenn die verarbeitende Software von jemandem entwickelt wurde, der es halt nicht kann. Der noch nicht einmal die einfachen Grundlagen für einen Erfolg versteht, obwohl diese erklärt wurden. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | de.sci.electronics
csiph-web