Het artikel beschrijft een specifieke eigenaardigheid of bug in AMD-processoren (mogelijk Zen2), waarbij de instructies rdrand en rdseed geen nul genereren wanneer er een 16-bit getal wordt gevraagd. Dit gedrag verschilt van Intel-processoren, die wel nullen produceren.
Belangrijke punten uit het artikel:
- Testapplicatie: Er is een Linux CLI-app ontwikkeld die dit gedrag visualiseert via grafieken, waarbij blijkt dat AMD-systemen geen nullen genereren in de 16-bit ruimte.
- Workaround: Het probleem kan worden omzeild door getallen te genereren naar 32-bit of 64-bit registers en deze vervolgens te gebruiken.
- Beveiliging: De auteur bespreekt de risico's van hardware-versnelde cryptografie en adviseert om
RDRAND altijd te mengen met andere bronnen voor maximale veiligheid.
- Benchmarks: Testen tonen grote verschillen in prestaties tussen verschillende CPU-generaties van zowel Intel als AMD.
- Technische werking: Er wordt ingegaan op de theoretische opbouw van een RNG, inclusief het gebruik van ruisgeneratoren en AES CSPRNG.
- Status: AMD is geïnformeerd en heeft de zaak geëscaleerd, maar er is nog geen definitieve verklaring of oplossing vanuit de fabrikant.
AMD's random number generator kan geen 0 genereren (+ app)
Ontdekking van het probleem
De testapplicatie
Om dit gedrag aan te tonen is een testapplicatie ontwikkeld die zoekt naar gegenereerde nullen en deze visualiseert in een grafiek. Deze applicatie dient tevens als showcase voor het besturen en renderen van data op willekeurige posities in een Linux CLI-console.
In de applicatie is het volgende waarneembaar:
- Op AMD-systemen: De eerste balk verandert waarschijnlijk nooit van kleur (groen, wat een eigen TSC-methode voor willekeurige getallen gebruikt) en de basis van de grafiek schaalt niet op vanuit 0.
- Op Intel-systemen: De grafiek schaalt de basis (minimum) wel voorbij 0.
De eerste balk in de grafiek rendert hoeveel nullen er worden gegenereerd door:
rdrand (rood)rdseed (blauw)- Een aangepaste TSC-techniek (groen)
De overige balken renderen de andere 65.535 getallen uit de 16-bit ruimte.
Opmerking: Voor het compileren en testen van de applicatie is de fastcall_v1 macro kit vereist.
Oplossing/Workaround
Om het probleem te omzeilen, kunnen de regels voor rdrand en rdseed worden gewijzigd zodat ze getallen genereren naar 32-bit of 64-bit registers, terwijl er voor de grafiekweergave nog steeds 16-bit data wordt verzameld.
Analyse van het gedrag
Er is discussie gevoerd over de vraag of de laagste 16 bits van een 32-bit of 64-bit output wel nul kunnen zijn. Het antwoord hierop is bevestigend: bij gebruik van 32-bit of 64-bit getallen kan het onderste gedeelte wel een nul outputten. Echter, een "echte" nul die precies past bij de gevraagde grootte (in dit geval 16-bit), gebeurt op AMD nooit.
Er wordt gespeculeerd dat dit een bewuste, zij het vreemde, keuze van AMD zou kunnen zijn, waarbij nul niet als een "willekeurig getal" wordt beschouwd.
Hardware-beveiliging en vertrouwen
De discussie breidde zich uit naar het gebruik van hardware-versnelde cryptografie. Enkele standpunten hierover:
- Er is een vuistregel die stelt dat men nooit hardware-versnelde cryptografie moet gebruiken.
- Voor vertrouwd hardware is hardware-versnelde cryptografie aanbevolen, terwijl men bij onbetrouwbaar hardware geen cryptografie moet uitvoeren, ongeacht of dit via software of hardware gebeurt.
- Voor maximale veiligheid met
RDRAND wordt aangeraden deze instructie nooit geïsoleerd te gebruiken, maar altijd te mengen met andere bronnen. Het toevoegen van niet-willekeurige data aan een reeds willekeurige seed kan de willekeurige bits verder mengen en kan niet leiden tot minder willekeurigheid.
- Er wordt opgemerkt dat "vertrouwd hardware" in strikte zin niet bestaat, tenzij men het hardware zelf heeft ontworpen en volledige controle heeft over het productieproces. Zelfs dan kunnen er kwetsbaarheden aanwezig zijn.
Benchmarks en technische implementatie
Prestaties per processor
Uit tests met een nieuwe update van de applicatie, waarbij ook benchmarks zijn toegevoegd, blijken de resultaten sterk te variëren per processor:
- Core i5 (2012): genereert 12,6 miljoen getallen per seconde (100% afhankelijk van de kloksnelheid).
- Core i7 7700 (2017): genereert "slechts" 750.000 getallen per seconde.
- AMD Ryzen 7: genereert ongeveer 2,6 miljoen getallen per seconde (volledig ongevoelig voor variaties in de kloksnelheid).
Dit suggereert dat de circuits voor de random number generator (RNG) sterk verschillen, zelfs tussen modellen van dezelfde fabrikant.
Theoretische werking van de RNG
Op basis van oudere Intel-documentatie werkt de interne constructie van RDRAND als volgt:
- Een astabiele ruisgenerator (één bit) voedt een geklokte sampler.
- Dit gaat naar een de-bias circuit en vervolgens naar een seriële shifter.
- Hierdoor wordt een interne 128-bit seed gecreëerd.
- Vanuit deze seed genereert een high-speed AES CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) in counter-modus de bits voor
RDRAND.
- De generator wordt periodiek opnieuw gevoed (reseeded) door de interne seed zodra er genoeg bits zijn verzameld.
- De
RDSEED-instructie geeft rauwe bits direct uit de interne seed.
Status van de communicatie met AMD
Er is contact opgenomen met AMD. De eerste reactie leek onvolledig of gegenereerd door AI, aangezien het antwoord sterk leek op resultaten van ChatGPT. Er is vervolgens een meer gedetailleerde reactie gestuurd, inclusief een codefragment dat het probleem illustreert. AMD heeft de zaak intern geëscaleerd, maar er is tot op heden geen definitieve oplossing of verklaring gecommuniceerd. In de tussentijd is bevestigd dat op twee verschillende AMD-systemen gedurende meerdere dagen geen enkele 0 is gegenereerd.
AMD's random number generator kan geen 0 genereren (+ app)
Ontdekking van het probleem
De testapplicatie
Om dit gedrag aan te tonen is een testapplicatie ontwikkeld die zoekt naar gegenereerde nullen en deze visualiseert in een grafiek. Deze applicatie dient tevens als showcase voor het besturen en renderen van data op willekeurige posities in een Linux CLI-console.
In de applicatie is het volgende waarneembaar:
- Op AMD-systemen: De eerste balk verandert waarschijnlijk nooit van kleur (groen, wat een eigen TSC-methode voor willekeurige getallen gebruikt) en de basis van de grafiek schaalt niet op vanuit 0.
- Op Intel-systemen: De grafiek schaalt de basis (minimum) wel voorbij 0.
De eerste balk in de grafiek rendert hoeveel nullen er worden gegenereerd door:
rdrand (rood)rdseed (blauw)- Een aangepaste TSC-techniek (groen)
De overige balken renderen de andere 65.535 getallen uit de 16-bit ruimte.
Opmerking: Voor het compileren en testen van de applicatie is de fastcall_v1 macro kit vereist.
Oplossing/Workaround
Om het probleem te omzeilen, kunnen de regels voor rdrand en rdseed worden gewijzigd zodat ze getallen genereren naar 32-bit of 64-bit registers, terwijl er voor de grafiekweergave nog steeds 16-bit data wordt verzameld.
Analyse van het gedrag
Er is discussie gevoerd over de vraag of de laagste 16 bits van een 32-bit of 64-bit output wel nul kunnen zijn. Het antwoord hierop is bevestigend: bij gebruik van 32-bit of 64-bit getallen kan het onderste gedeelte wel een nul outputten. Echter, een "echte" nul die precies past bij de gevraagde grootte (in dit geval 16-bit), gebeurt op AMD nooit.
Er wordt gespeculeerd dat dit een bewuste, zij het vreemde, keuze van AMD zou kunnen zijn, waarbij nul niet als een "willekeurig getal" wordt beschouwd.
Hardware-beveiliging en vertrouwen
De discussie breidde zich uit naar het gebruik van hardware-versnelde cryptografie. Enkele standpunten hierover:
- Er is een vuistregel die stelt dat men nooit hardware-versnelde cryptografie moet gebruiken.
- Voor vertrouwd hardware is hardware-versnelde cryptografie aanbevolen, terwijl men bij onbetrouwbaar hardware geen cryptografie moet uitvoeren, ongeacht of dit via software of hardware gebeurt.
- Voor maximale veiligheid met
RDRAND wordt aangeraden deze instructie nooit geïsoleerd te gebruiken, maar altijd te mengen met andere bronnen. Het toevoegen van niet-willekeurige data aan een reeds willekeurige seed kan de willekeurige bits verder mengen en kan niet leiden tot minder willekeurigheid.
- Er wordt opgemerkt dat "vertrouwd hardware" in strikte zin niet bestaat, tenzij men het hardware zelf heeft ontworpen en volledige controle heeft over het productieproces. Zelfs dan kunnen er kwetsbaarheden aanwezig zijn.
Benchmarks en technische implementatie
Prestaties per processor
Uit tests met een nieuwe update van de applicatie, waarbij ook benchmarks zijn toegevoegd, blijken de resultaten sterk te variëren per processor:
- Core i5 (2012): genereert 12,6 miljoen getallen per seconde (100% afhankelijk van de kloksnelheid).
- Core i7 7700 (2017): genereert "slechts" 750.000 getallen per seconde.
- AMD Ryzen 7: genereert ongeveer 2,6 miljoen getallen per seconde (volledig ongevoelig voor variaties in de kloksnelheid).
Dit suggereert dat de circuits voor de random number generator (RNG) sterk verschillen, zelfs tussen modellen van dezelfde fabrikant.
Theoretische werking van de RNG
Op basis van oudere Intel-documentatie werkt de interne constructie van RDRAND als volgt:
- Een astabiele ruisgenerator (één bit) voedt een geklokte sampler.
- Dit gaat naar een de-bias circuit en vervolgens naar een seriële shifter.
- Hierdoor wordt een interne 128-bit seed gecreëerd.
- Vanuit deze seed genereert een high-speed AES CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) in counter-modus de bits voor
RDRAND.
- De generator wordt periodiek opnieuw gevoed (reseeded) door de interne seed zodra er genoeg bits zijn verzameld.
- De
RDSEED-instructie geeft rauwe bits direct uit de interne seed.
Status van de communicatie met AMD
Er is contact opgenomen met AMD. De eerste reactie leek onvolledig of gegenereerd door AI, aangezien het antwoord sterk leek op resultaten van ChatGPT. Er is vervolgens een meer gedetailleerde reactie gestuurd, inclusief een codefragment dat het probleem illustreert. AMD heeft de zaak intern geëscaleerd, maar er is tot op heden geen definitieve oplossing of verklaring gecommuniceerd. In de tussentijd is bevestigd dat op twee verschillende AMD-systemen gedurende meerdere dagen geen enkele 0 is gegenereerd.
Groetjes,