Zenerbrus som entropi för slump

Elektronikrelaterade (på komponentnivå) frågor och funderingar.
BJ
Inlägg: 5571
Blev medlem: 11 april 2007, 08:14:53
Ort: En_stad

Re: Zenerbrus som entropi för slump

Inlägg av BJ »

På tal om förutsägbarhet.
Hur blir det om man har flera bruskällor,
och låter den första få bestämma när man
ska läsa från den andra, och den andra
får bestämma när man ska läsa från den tredje, o.s.v. ...
Blir det lika förutsägbart då?
WhyNotOnMars
Inlägg: 84
Blev medlem: 24 december 2015, 11:35:17

Re: Zenerbrus som entropi för slump

Inlägg av WhyNotOnMars »

Om du har kapacitet för det är det bästa att helt enkelt göra en uppskattning av hur mycket entropi varje källa ger per sampling, sedan sampla dem tillräckligt många gånger så du har din önskade entropi med råge (gärna så mycket att varje källa separat skulle ge tillräckligt mycket), och köra det hela genom en kryptografisk hash-funktion som t ex SHA256.

En grej man inte får glömma är också att ju mer komplicerat eller "smart" du gör det, desto större risk att du gör något fel och förstör din dyrbara entropi. Praxis på "vanliga" datorer är därför att helt enkelt be operativsystemet om slumpade bytes och inte göra massa egna grejer för att försöka "förbättra" det hela.
xxargs
Inlägg: 9851
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: Zenerbrus som entropi för slump

Inlägg av xxargs »

Att köra igenom en hash i slutet är för att göra slumpvärdena 'vit' - dvs alla positioner inom talrymden är lika sannolika.

Vitt analog brus tagen med en ADC är gaussformad i sannolikhet i hur ofta det når olika spänningsvärden pga att det är energibegränsat och det är mycket större sannolikhet med ett lågt värde ofta än ett högt värde i talrymden. Det innebär inte att det är dålig Entropi för det då det är fortfarande ingen gissningsbar beroende av vad nästa värde är baserat på föregående värde samplet innan (så länge samplingstakten är långt under brusets bandbredd och lågpasspåverkan och fördröjningar (minnesverkan) i eventuella filter)

att köra en full SHA512-hash i en PIC är nog väldigt tungt om ens möjligt då de vill ha lite RAM-minne - det jag skulle prova är att göra en CRC8,CRC16 eller tom CRC32 på en sträng slumptal och se om dess checkvärden ut gör värdena tillräkligt 'vita' (rektangulära) med ett större antal sampel.

Ett sätt att kolla homogenitet på slumptal efter hash/CRC är tex att lägsta 16 bitarna adresserar Y-axeln och de högsta 16 bitarna X-axel och så plottar man prickar för positionerna av ett stort antal sampel - är det ett jämt fördelat 'brus' så är det bra, klumpar det sig och stora områden lämnas 'vita' eller att punkterna samlar sig i någon kant så är det mindre bra (Gaussisk brus kommer inte att fördela sig jämt i sådan plottning)

En god exempel bra fördelad 10000 sampel slumpvärden från linux Urandom är:
good_noise.png
och exempel på 10000 dåliga slumptal och sannolikt avsiktligt manipulerad slumpgenerator som används i SED-enheter (2.5" USB-diskar med kryptering från en viss stor tillverkare):
bad_noise.png

och här inser man om man skall försöka få fatt på kryperingsnyckeln för AES-chipern som används i disken så är det inom görbart område för den resursrike att prova fram det oavsett vilken kod som har genererats.

(bilderna tagna från PDF från https://eprint.iacr.org/2015/1002.pdf - och förövrigt skrämmande och intressant läsning hur olika nationella intressen desperat smyger in svagheter i krypterande lagring som säljs till konsument och företag så att det alltid finns mer än väg in för den som vet hur... eftersom det är så tydligt att på många sätt försöker säkra vägar in så kan man dra samma slutsats att motsvarande svagheter planterade finns all krypterande lagring - dvs våra SSD också och därmed är bitlocker bara (som använder cryptomaskinen inne i SSD) symbolisk skydd och inget hinder för den som verkligen vill in på olika nationsnivå organisationer.)
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
guckrum
Inlägg: 917
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: Zenerbrus som entropi för slump

Inlägg av guckrum »

Om man vill ha bra slumptal är det säkrast att vara konservativ och återanvända kända lösningar. Att hitta på egna grejer kan lätt leda till problem, speciellt om man inte vet hur man skall validera "kvaliteten" på den data som genereras. Men det är såklart kul att fundera ut olika lösningar och hitta deras begränsningar! (Lavalampor!)
Användarvisningsbild
swesysmgr
Inlägg: 10595
Blev medlem: 28 mars 2009, 06:56:43
Ort: Göteborg

Re: Zenerbrus som entropi för slump

Inlägg av swesysmgr »

xxargs skrev:
9 januari 2021, 15:03:36
(bilderna tagna från PDF från https://eprint.iacr.org/2015/1002.pdf - och förövrigt skrämmande och intressant läsning hur olika nationella intressen desperat smyger in svagheter i krypterande lagring som säljs till konsument och företag så att det alltid finns mer än väg in för den som vet hur... eftersom det är så tydligt att på många sätt försöker säkra vägar in så kan man dra samma slutsats att motsvarande svagheter planterade finns all krypterande lagring - dvs våra SSD också och därmed är bitlocker bara (som använder cryptomaskinen inne i SSD) symbolisk skydd och inget hinder för den som verkligen vill in på olika nationsnivå organisationer.)
"Now though, after a recent update to Windows 10, Microsoft will assume that connected SSDs don't actually encrypt anything.

In a Twitter post, SwiftOnSecurity described why the software giant has decided to no longer trust SSD manufacturers, saying:

“Microsoft gives up on SSD manufacturers: Windows will no longer trust drives that say they can encrypt themselves, BitLocker will default to CPU-accelerated AES encryption instead. This is after an exposé on broad issues with firmware-powered encryption. “"


https://www.techradar.com/news/microsof ... -bitlocker
guckrum
Inlägg: 917
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: Zenerbrus som entropi för slump

Inlägg av guckrum »

This is after an exposé on broad issues with firmware-powered encryption.
Precis, det är inte så lätt att få till. Såklart är MS mycket bättre än hårddiskleverantörerna:-)
E Kafeman
Inlägg: 2403
Blev medlem: 29 april 2012, 18:06:22

Re: Zenerbrus som entropi för slump

Inlägg av E Kafeman »

Precis. De har fått en så bra algoritm från några herrar i svart kostym.
BJ
Inlägg: 5571
Blev medlem: 11 april 2007, 08:14:53
Ort: En_stad

Re: Zenerbrus som entropi för slump

Inlägg av BJ »

Vad är en hash? :humm:
WhyNotOnMars
Inlägg: 84
Blev medlem: 24 december 2015, 11:35:17

Re: Zenerbrus som entropi för slump

Inlägg av WhyNotOnMars »

Jag tror nog Microsofts implementation är ungefär så bra den kan bli. Däremot försöker de precis som Apple och Google få en att ladda upp allting till molnet mha så kallade "dark patterns", dvs GUI-design som gör det nästintill omöjligt att hoppa över även om det rent tekniskt är "frivilligt".
guckrum
Inlägg: 917
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: Zenerbrus som entropi för slump

Inlägg av guckrum »

En hashfunktion är ungefär en funktion som tar in en godtycklig mängd data och genererar ett resultat som är begränsat i storlek. Ett exempel är en funktion som tar in en ASCII-sträng, exorar alla värdena och returnerar detta som ett tal mellan 0 och 127.
Hash-funktioner används i många olika applikationer där varje applikation kräver speciella egenskaper.
Användarvisningsbild
swesysmgr
Inlägg: 10595
Blev medlem: 28 mars 2009, 06:56:43
Ort: Göteborg

Re: Zenerbrus som entropi för slump

Inlägg av swesysmgr »

E Kafeman skrev:
9 januari 2021, 21:39:03
Precis. De har fått en så bra algoritm från några herrar i svart kostym.
AES under Windows är väl varken bättre eller sämre än AES under Linux?
guckrum
Inlägg: 917
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: Zenerbrus som entropi för slump

Inlägg av guckrum »

AES är knappast problemet (så vitt vi vet just nu), det är ju allting runtomkring som ställer till det, som generering och hantering av själva nyckeln exempelvis. Kan man norpa åt sig nyckeln spelar ju inte krypteringsalgoritmen någon som helst roll.
Palle500
Inlägg: 1770
Blev medlem: 6 juni 2015, 14:53:06

Zenerbrus som entropi för slump

Inlägg av Palle500 »

Man kan kalla en HASH för ett envägskrypto (utan kryptonycklar) som utifrån en given indata mängd ger en fast data mäng tex 128, 256, 512 bitar.
Om någon annan tar din data mängd tex texten i ett mail, worddokument och kör den igenom samma HASH algoritm tex SHA-256 så blir det samma bitvärde. Detta används för att kontrollera att ingen har ändrat i texten. Själva HASH:en överförs givetsvis säkert via tex RSA kryptering. Kallas för signering, samma som du gör om du har mobilt bankid och godkänner en betalning via de flesta Internet bankerna.brukar stå "härmed godkänner jag denna betalning på 200kr"
Edit
Minsta lilla ändring i en text ger ett helt annat HASH värde. Det är denna funktion som är viktig när en HASH algoritm tas fram att man inte skall kunna klura ut hur man får fram samma värde för olika texter, eller kunna få fram korta texter baklänges.
xxargs
Inlägg: 9851
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: Zenerbrus som entropi för slump

Inlägg av xxargs »

swesysmgr skrev:
9 januari 2021, 20:40:35
xxargs skrev:
9 januari 2021, 15:03:36
(bilderna tagna från PDF från https://eprint.iacr.org/2015/1002.pdf - och förövrigt skrämmande och intressant läsning hur olika nationella intressen desperat smyger in svagheter i krypterande lagring som säljs till konsument och företag så att det alltid finns mer än väg in för den som vet hur... eftersom det är så tydligt att på många sätt försöker säkra vägar in så kan man dra samma slutsats att motsvarande svagheter planterade finns all krypterande lagring - dvs våra SSD också och därmed är bitlocker bara (som använder cryptomaskinen inne i SSD) symbolisk skydd och inget hinder för den som verkligen vill in på olika nationsnivå organisationer.)
"Now though, after a recent update to Windows 10, Microsoft will assume that connected SSDs don't actually encrypt anything.

In a Twitter post, SwiftOnSecurity described why the software giant has decided to no longer trust SSD manufacturers, saying:

“Microsoft gives up on SSD manufacturers: Windows will no longer trust drives that say they can encrypt themselves, BitLocker will default to CPU-accelerated AES encryption instead. This is after an exposé on broad issues with firmware-powered encryption. “"


https://www.techradar.com/news/microsof ... -bitlocker
Kolla datumet - det var bara statement i en kort tid (för att rädda lite face) och blev inaktuellt igen när problemet ansågs löst med firmware-uppgradering för de stora SSD-tillverkarna - varför - MS versioner av sin kryptering var så plågsamt enormt långsamma att alla som provade (efter ganska mycket krångel med registerhack och kommandon i powershell om man skulle göra det på en befintlig bitlocker-volym) att omkryptera (jepp allt måste processas igen med uppackning och sedan kryptering igen) och de som provade det avrådde det skarpt om det inte var absolut nödvändig - vi prata om prestanda mindre än 1/4-del gentemot tex. Veracrypt och någon i en blogg konstaterade krasst att 'resevhjulskrypteringen' var inte tänkt för att användas mer i yttersta nödfall och som vanligt att MS inte ägnat ens 5 minuter på optimering för att göra det drägligt användbart) - det är också rätt lätt att kolla om SSD-kryptering används eller inte - kika på processorlasten när du skriver en stor fil snabbt mot lagringen - det kostar mycket CPU (även med HW-stöd) att kryptera om det inte görs i enheterna direkt.

Du kan utgå att 99.9% av bitlocker-användare idag använder SSD som kryptomotor via OPAL-API:t om man inte sitter på riktigt antika SSD:r

---

Som en kommentar till bilderna tidigare så är den nedre bilden en indikation att svårigheten ligger på 2^40 bit vilket med en modern högpresterande dator/GPU kan testars igenom samtliga alternativ på bara några timmar och då spelar det ingen roll med keystretching mm. eftersom det är värdet efter all hashning man går på och är själva nycken för AES-chipern. - därför är det så otroligt viktig att den ursprungliga nyckeln till AES kommer från högkvalikativa slumptalsgeneratorer som det inte är gjord någon tamper på (som Dual_EC_DRBG som NSA försökte tvinga ut med NIST som frontfigur och NIST fick sedan ta skiten när det blev för uppenbart och att det var tänkt att forceras att det skulle användas av alla inom Internet med tyngden av standardiceringsorganisation...[1]) och att den matas med högkvalikativ etropi (i form av saltvärden eller plockas ut på andra sätt ) många gånger under processen då en rng-algoritm i en program i en dator kan per definition inte vara slumpmässig (dvs. samma salt/startvärde in ger samma talström ut oavsett hur länge man räknar) - Entropin måste komma utifrån.

[1] Eftersom många tyckte att Dual_EC_DRBG luktade illa redan från början så obstruerade man i hemlighet redan från start och tex. opensource SSL/TLS som används över allt lyckades certifiera sin kodbas genom alla certifieringsprocess hos berörda myndigheter med Dual_EC_DRBG som då var ett krav för att över huvud taget kunna bli godkänd - men på något sätt så fungerade den inte om man försökte använda den i verklig drift, konstigt... - och som kommentar om detta sa man på Opensource-organisationerna bakom detta att "ingen har klagat och vi kommer inte att ta jobbet och kostnaden för att certifiera om det hela igen för att det skall fungera - enklare att låta bli att använda det helt!"
BJ
Inlägg: 5571
Blev medlem: 11 april 2007, 08:14:53
Ort: En_stad

Re: Zenerbrus som entropi för slump

Inlägg av BJ »

Okej.
Skriv svar