AMD's random number generator can't generate a 0?
Recorded: Sept. 22, 2026, 10:09 a.m.
| Original | Summarized |
flat assembler - AMD's random number generator can't generate a 0 (+ app) flat assemblerMessage board for the users of flat assembler. Home Search Log in to check your private messages Index Author Thread Jessé Joined: 03 May 2025 Jessé 11 May 2026, 05:13 You can help me figure out this by using my application to seek for any 0 number generated, and maybe post your results at this forum thread... I also must mention that this application is a very deep showcase on how to control and render data to the console screen at arbitrary positions, which I remember someone here was trying to achieve the same under Linux cli, and he asked for help on this subject before. Attached, I've provided that exact chart test application that showcases the AMD's RNG 0 problem: you'll probably, on an AMD host, never see the first bar change colors from green (which uses a TSC method I've created to generate random numbers), and also never see the base chart scale up from 0. On Intel processor, no problem, and the chart scale its base (minimum) beyond 0. The first bar renders how many zeroes are being generated by rdrand (red), rdseed (blue) and TSC-custom technique (green), as well as other bars render the other 65535 numbers from the 16-bit space. Note: it requires fastcall_v1 macro kit if anyone wants to compile and test it as is. Cheers! Description: Test application. To fix it, change rdrand and rdseed lines to generate either to 32-bit or 64-bit registers, while keeping 16-bit data to be gathered for the graph display (graph is still rendering 16-bit data). Filename: Filesize: Downloaded: _________________jesse6 11 May 2026, 05:13 Jessé Joined: 03 May 2025 Jessé 11 May 2026, 05:16 Description: Filesize: Viewed: 11 May 2026, 05:16 revolution Joined: 24 Aug 2004 revolution 11 May 2026, 05:28 11 May 2026, 05:28 Jessé Joined: 03 May 2025 Jessé 11 May 2026, 05:36 But a true zero (fitting the requested size), on AMD, never happens. 11 May 2026, 05:36 revolution Joined: 24 Aug 2004 revolution 11 May 2026, 05:41 Maybe some C?O person executed RDRAND, got zero, declared it was broken and made the engineers "fix" it. 11 May 2026, 05:41 Jessé Joined: 03 May 2025 Jessé 11 May 2026, 06:05 I'll probably will e-mail AMD about this, and if they answered, I'll be back here to share what they said. 11 May 2026, 06:05 sylware Joined: 23 Oct 2020 sylware 11 May 2026, 10:22 11 May 2026, 10:22 revolution Joined: 24 Aug 2004 revolution 11 May 2026, 11:36 For untrusted hardware: Don't do any crypto with it, software or hardware. For best security with RDRAND, it might be backdoored, it might not. IDK, but never use it in isolation, always mix it with other sources. It doesn't hurt to add non-random data into an already random seed. It isn't possible to un-random a random value with non-randomness, it just mixes up the random bits a bit more. If the application isn't for crypto then none of this matters, use RDRAND for anything. Go for it. 11 May 2026, 11:36 sylware Joined: 23 Oct 2020 sylware 11 May 2026, 12:31 11 May 2026, 12:31 macomics Joined: 26 Jan 2021 macomics 11 May 2026, 15:41 11 May 2026, 15:41 sylware Joined: 23 Oct 2020 sylware 12 May 2026, 11:17 We all know "trusted" hardware does not exist, it is a spectrum: "trusted" is actually some amount of "trust" decided based on some contexts and specifics. At the time, when I was wandering in information system security groups: all this 'security hardware' was rumored to have flaws: entropy/maths/bugs/etc which users cannot cleanly fix, or actually even fix. 12 May 2026, 11:17 alCoPaUL Joined: 20 Jun 2023 alCoPaUL 13 May 2026, 05:04 13 May 2026, 05:04 Jessé Joined: 03 May 2025 Jessé 15 May 2026, 10:38 How about Intel results, which seems normal (0s being generated at requested sizes)? 15 May 2026, 10:38 Jessé Joined: 03 May 2025 Jessé 15 May 2026, 11:00 So I reply again with a mode detailed reply, and also a snippet of the code that rises the problem. 15 May 2026, 11:00 alCoPaUL Joined: 20 Jun 2023 alCoPaUL 15 May 2026, 14:21 moreover, amd invented x86_64.. https://bitbucket.org/alcopavl/ia-64_quine/src/main/ https://bitbucket.org/alcopavl/x86x64/src/main/ https://github.com/alcopaul/beth_GviLLErMo_GIMO 15 May 2026, 14:21 AsmGuru62 Joined: 28 Jan 2004 AsmGuru62 15 May 2026, 15:39 Anyone did any testing? Like the famous "Big Crush" battery of tests? 15 May 2026, 15:39 sylware Joined: 23 Oct 2020 sylware 16 May 2026, 11:15 Heard about prime numbers farming too (mostly via crypto currency). But I only did scratch the surface here, maybe a fluke. 16 May 2026, 11:15 Jessé Joined: 03 May 2025 Jessé 23 May 2026, 17:43 Furthermore, I must say that I have not yet received any further feedback from AMD regarding the case. But they have already escalated my case internally with them, so I am still here waiting for a precise update from them, to share it here. And, since 9 days before posting here, until the present moment, not a single 0 came out of the 2 AMDs that I had access to! With the new update I made to my application to test this, it is now also possible to benchmark the random number generator, and it is also now possible to run the test on processors that do not have the 'rdseed' instruction. As for the benchmark, it is surprising how different the results are between different processors (e.g.: a Core i5 from 2012 generates 12.6 M numbers per second, while a Core i7 7700 from 2017 generates "only" 750 k numbers per second, and my AMD Ryzen 7 around 2.6 M numbers per second, and the AMD generator being completely inert to clock variation, and the Core i5 from 2012 100% dependent on the clock, as it seemed to me in the tests I did). Which leads me to realize that the random number generator circuit must have large differences, and probably completely different versions/revisions, even for models from the same manufacturer. So far, I also have not found decent information on how their RNG unit works. 23 May 2026, 17:43 revolution Joined: 24 Aug 2004 revolution 24 May 2026, 00:56 It had an astable noise generator (a single bit), feeding into a clocked sampler, then a de-bias circuit, into a serial shifter. That created an internal 128-bit seed. From the seed there was a high speed AES CSPRNG in counter mode that output the bits for RDRAND, and got reseeded periodically by the internal seed when it had enough bits accumulated. The RDSEED instruction would output some raw bits from the internal seed directly. The circuits may have changed since then, so maybe today they are totally different. Back then RDRAND could generate output at the full CPU clock rate, RDSEED was slower. There was discussion at the time about it not being "properly" random because of the PRNG in the pipeline, but no one could show any measurable problem. There are lots of places to hide a backdoor in there, and it would be extremely hard to detect without reverse engineering the silicon. 24 May 2026, 00:56 ttd3v Joined: 17 Sep 2026 ttd3v 19 Sep 2026, 00:37 Also, if you need it for non-cryptographic purposes I guess that thing is negligible. 19 Sep 2026, 00:37 Display posts from previous:
Jump to: Select a forum Official----------------AssemblyPeripheria General----------------MainTutorials and ExamplesDOSWindowsLinuxUnixMenuetOS Specific----------------MacroinstructionsOS ConstructionIDE DevelopmentProjects and IdeasNon-x86 architecturesHigh Level LanguagesProgramming Language DesignCompiler Internals Other----------------FeedbackHeapTest Area
< Last Forum Rules: You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum Main index Copyright © 1999-2026, Tomasz Grysztar. Also on GitHub, YouTube. Website powered by rwasa. |
A discussion thread initiated by Jessé on the flat assembler message board centers on a perceived bug in AMD processors concerning their random number generator (RNG) capabilities, specifically the inability to generate the number zero when using instructions like 'rdrand' or 'rdseed'. The core issue stems from testing assembly code used to render data charts, where the behavior differed significantly between AMD and Intel processors. While the same programs functioned correctly on Intel systems, the AMD implementations appeared to fail to generate a zero at specified sizes, leading to graphical anomalies, such as the chart base scale not adjusting from zero. To investigate this discrepancy, Jessé developed and shared a test application that showcased the problem. The application utilized custom methods to generate random numbers and displayed them graphically, revealing that on AMD hosts, the first bar often failed to change color from green and the chart scale did not appropriately set its minimum value to zero, unlike on Intel hardware. Jessé suggested a potential fix by modifying the application to use 32-bit or 64-bit registers for the RNG calls while retaining 16-bit data for the visual graph display, which allowed for zero generation in the lower portions of the larger numbers, though a true zero fitting the requested size remained elusive on AMD systems. The discussion expanded into the theoretical implications of this finding. Some participants speculated on whether this behavior implied that zero was intentionally excluded from the random number space by AMD, prompting questions about potential flaws or deliberate design choices in the hardware. The conversation touched upon the nature of "trusted hardware," with participants debating whether the hardware has inherent vulnerabilities or if the randomness is compromised by internal processes or backdoors. One contributor suggested that relying on hardware-accelerated cryptography, like RDRAND, requires caution, advocating for mixing it with other random sources since the output cannot be entirely un-randomized. Further analysis involved the underlying mechanism of the RNG itself. One participant outlined a potential internal structure for RNGs, suggesting an astable noise generator feeding a clocked sampler and de-bias circuit to produce an internal seed, which then feeds a Counter Mode Pseudo-Random Number Generator (CSPRNG) used for output, with instructions like RDSEED providing raw bits from the internal seed. This suggested that the specifics of the RNG unit might have evolved or differed between manufacturers. Jessé provided further empirical evidence, noting that multiple accesses to AMD hardware failed to produce a single zero when testing the issue, leading him to escalate the situation internally with AMD. Furthermore, Jessé observed significant performance variances across different x86-64 processors when benchmarking random number generation speeds. For instance, testing showed drastically different throughputs between older Intel and AMD processors, indicating fundamental differences in the underlying RNG circuit revisions, which manifested as dependencies on clock variations in the older designs versus the more stable results observed on AMD architectures. This disparity underscored the complexity of assessing the quality and consistency of random numbers generated by different hardware implementations. |