Hangkártyából random entrópia forrás kinyerése hogy?
Legyen egy monó hangcsatorna 44100 Hz mintavételezésű 16 bit bitmélységű integer input forrás. Ennél a konstrukciónál az elméleti maximális true randomgenerátor forrás 44100*16 bit/sec ami kb 689 kilobit/sec. Ehhez az kéne hogy inputnak a teljes spkretumon egyenletes eloszlással olyan intenzitással ahol a határértékét elérte az input ami éppen még torzításmentes.
Gyakorlatban ennél messze kevesebb valódi értékes entrópiaforrás. Valamifajta egyszerűsítését keresem a Kolmogorov-komplexitásának, hiszen az kvázi kiszámíthatatlanul nehéz feladat. Az se baj ha 2x lassabb entrópiaforrást nyerek ki belőle mint amennyi a Kolmogorov-komplexitása, vagy c-szer rosszabbat, ha c az nem túl nagy. Persze ha van jobb közelítése eme komplexitás számításához és így entrópiaforrás generálásához akkor legyen az, ha értelmes számítási kapacitáson belül marad.
Például ha inputnak csupa zéró bájt jön, dehát abszolút csend van az inputon akkor az én követelményem szerint egy rossz randomgenerátor ha az ontja magából az inputból számított randomot.
Az input függvényében a randomgenerátor úgy számítandó ebből, hogy vesztességes titkosítást hajtok végre rajta. Például AES titkosítást CBC módban, a kulcsot és az inicializálási vektort valahogy előállítom, ez lehet más forrásból is, vagy más forrásból belekeverve a hangrátya inputával ötvözve például a /dev/random-ból. Majd (az AES-ben 16 bájt a blokkméret) , 64 blokkonként csak 1 blokkot küldök a generátor outputjára. Persze még mást is belekeverhetek az inputba, az aktuális pontos időt, az aktuális cpu hőmérségletet, az aktuális cpu interrupt számot stb. Ezek már csak plusz részletkérdések. A lényeg azon van a kérdésben hogy csupán a hangkártya bementetéből hogy nyerhető ki az entrópiaforrás, a csuppa zéró hang input értéket csak példának mondtam hogy triviális hogy akkor blokkolni kell a generátoromnak, míg kacifántosabb helyzetben a kimenti sebességet növelni/csökkenteni az input függvényében.
Most néztem vissza válaszolt e valaki. Olvasom, kimaradt 2 szó ebből:
"Ehhez az kéne hogy inputnak a teljes spkretumon egyenletes eloszlással olyan intenzitással ahol a határértékét elérte az input ami éppen még torzításmentes."
Javítva:
Ehhez az kéne hogy inputnak a teljes spkretumon egyenletes eloszlással fehér zaj olyan intenzitással ahol a határértékét elérte az input ami éppen még torzításmentes.
Természetesen itt a kvantummechanika garantálná, hogy elvileg se előre jósolható. Mondjuk a hangkártyának is tudnia kéne fogadni, meg ez esetben valami nem hang jel lenne átalakítva arra hogy a hangkártya inputjára legyen kötve. Viszont én nem ilyen esetről beszélek, az input a külvilágból vett real time hang lenne, sima hétköznapi eszköz tudja kezelni olyan esetre érdekel a kérdés.
válasza:Véletlenszám generátor a cél, forrásnak a hangkártya bemenet, értelem szerűen mikrofonnal.
Alapvetően kétfelé lehet csoportosítani a véletlenszám generátorokat.
Egyik esetben van egy kezdeti seed inicializálási érték aminek ismeretében végig számítható az egész randomizált sorozat (álvéletlen).
Másik esetben is van kezdeti seed inicializálási érték, de folyamatosan tápláljuk bemenettel.
Ez a másik eset érdekel. Ennél a felhasználásnál az alacsony zajú mikrofon a rosszabb, hiszen a zajtól lesz jobban sztochasztikus.
válasza:Akkor ne mikrofont köss a bemenetre, hanem egy erősítő kaszkádot - melynek az erősítése olyan nagy, hogy az első fokozat saját termikus zaját kierősíti a hangkártya bemenetének a teljes dinamikatartományára.
Néhány mezei tranzisztorból összehozható a dolog, és dőlni fog a teljesen determinálhatatlan, tehát igazi véletlen-jel! A jel spektrumát persze érdemes ellenőrizni, hogy nem okoz e problémát valamilyen periodikus összetevő, pl. hálózati brumfesz, stb..
Köszi a tippet.
Legyen konrétum, ne csak általánosságban írjam : monó 44100 Hz 16 bitmélység, a teljes ábrázolható tartományt első megközelítésben az kell hogy lefedje a hangkártya dinamikatartománya és ne legyen torzítás, az erősítőből pedig minden ezzel kvantálással ábrázolható frekvenciatartományban kapja a jelet. Numerikusan a hanggörbe maximuma 32767, minimuma -32768, ezen túl nem nyúlhat, de akkor torzít ha túl akarna nyúlni. Ha pedig nem éri el a tartomány tetejét és az alját, akkor nem használja ki a teljes sávszélességet, így legalábbis nyesen (raw-ba) nem jó (amit említettél periodikus összetevőket arról nem is beszélve).
Természetesen nem nyersen venném forrásnak, hanem kriptográfiai függvényen menne át ami lenne a randomgenerátor kimenete. Ennek a skálázása érdekelne, igazából erre vonatkozik a kérdés.Amit írtál és erre vonatkozik a szerint a periodikus összetevőt ellenőrizni kell. Minél több a periodikus összetevő annál lassabbnak kell lennie a randomgenerátor kimenetének.
16 bites bitmélységről beszélek, nem tudom mennyire jó -32768 -től 32767-ig kihajtani a hangkártyát, felére csökkentve jelerősséget le is felezhetem a tartományt, így a hangkártya bementi bitmélysége 15 értékes bit lesz 16 bit helyett.
A félreértések elkerülése végett matematikailag érdekel a kérdés, ennek egy esete amit írtál erősítő kaszkádot. Mondjuk praktikus ötlet.
Gyári célhardver randomgenerátor lenne, ha nem érdekelnének a részletek.
válasza:Nem kell újra feltalálni a spanyol viaszt periodikus összetevők ellenőrzésével meg anyám kínjával. A jeled komplexitásának elég jó mérőszáma az audió tömöríthetőségi rátája, aminek az optimalizálásába bőven elég mérnök-órát ölt már az emberiség. Ez ugyan felső korlát, miközben te a kiszámíthatatlan alsót keresed. Ilyenkor van az, hogy megtippeled vagy utánaolvasol, hogy mennyivel lehet a valós komplexitás a mai legjobb enkóderek szintje alatt, és ráhagyással azt az értéket használod.
Fogod a jeledet, átküldöd FLAC-on legnagyobb blokkmérettel (65535 minta - több mint 1 másodperc) legnagyobb tömörítéssel (sima ügy realtime-ban is), a kimenet méretéből kivonsz egy overhead konstanst* és elosztod mondjuk még néggyel. Ezek után viszonylag bátran kijelentheted, hogy ennek a blokknak az entrópiája legalább ennyi, és generálod belőle a véletlenedet eszerinti rátával.
*overhead konstans: megnézed, hogy egy ismert alacsony entrópiájú jelre, pl tiszta szinuszhullámra mekkora outputot produkál, hogy az output blokkok inputfüggetlen fix részét ne számold és ne tekintsd entrópiának, csak az afeletti tartalmat.
Ha a mikrofonodon nem jön érdemi jel, csak hálózati zümmögés, akkor a tömörítés-kivonás-osztás után nulla közeli értéket kapsz, és tudod, hogy a generátorodat arányosan be kell lassítanod.
Jó ötlet ez a flac. Miért kell akkora blokkméret?
Hibába adok meg az ffmpeg-nek akármilyen blokkméretet akkor is marad a 4608, ha megnézem a generált flac fájlt exiftool-al : ffmpeg -f s16le -ar 44.1k -ac 1 -i input.pcm -blocksize 65535 output.flac .
"a kimenet méretéből kivonsz egy overhead konstanst* és elosztod mondjuk még néggyel"
Ezt pedig úgy gondoltam, hogy felbontom a csonkítási műveletet enkritálás előtti és utáni csonkításra. A csonkítás segéd véletlenszám generátorral eldobál random kiválaszott bájtokat amit megkap az AES, az AES kimenetét is csonkítom random bájtokat eldobva belőle, így áll elő a randomgenerátorom nyers bájtjai. Például 4-el elosztva : felét kidobja randomeldobáló segédfüggvény az így megmaradt pcm bájtokat enkriptálja az AES, az AES enkriptált bájtjainak a felét is eldja az eldobó segédfüggvény.
Bocsi most nézem, sok féle módon próbáltam, többnyire nevesített és névtelen csöveken keresztül, de ez részletkérdés, amit beírtam ide kihagytam egy kapcsolót az ffmpeg-nek a "-compression_level 12" a legerősebb flac tömörítés miatt. Akkor is valamiért marad a blokkméret, nem tudom hogy lehet befolyásolni, bár ez inkább informatikai kérdés már.
Ide vonatkozó sorok az exiftool-ból:
MIME Type : audio/flac
Block Size Min : 4608
Block Size Max : 4608
Frame Size Min : 4049
Frame Size Max : 6153
Sample Rate : 44100
Channels : 1
Bits Per Sample : 16
Viszont ami matematikai kérdés, miért kellene nekem 65535 méretű blokk?
válasza:Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!