Hangkártyából random entrópia forrás kinyerése hogy?

Kipróbáltam az ffmpeg-el úgy is, hogy csövön kapja a mikrofonból nyers pcm-ben a bemenetet a flac-ot pedig fájlba menti. Menet közben is belehallgattam a flac fájlba, ekkor a lejátszó programok nem jelzik hogy milyen hosszú a média, csak miután végzett az ffmpeg. Kipróbáltam úgy is, hogy a bemenetet csövön kapja a flac kimenetet pedig másik csőbe írja amit másik processz dolgoz fel, egy az egybe fájlba kiírtam a cső tartalmát, ez esetben nem jelzi előre a tartalom hosszát a lejátszó. Szerintem ez normális, mert a fejléc ekkor nem tartalmazza a hosszt, az ffmpeg nem seek-elhet vissza a fejléchez ha csőbe ír.

Nekem ez lenne a kézenfekvő, hogy az ffmpeg-en csöveken keresztül menne input + output és nem tárolni, csak addig még az algortimus feldolgozza mint entrópiaforrást. Azt írtam múltkor hogy az eredeti nyers pcm inputot csonkítanám a randomgenerátorom számára. Viszont ahogy nézem technikailag kényelmesebb lenne a flac stream bájtjait randomizáltan csonkítani ezt enkriptálni stb.

Jól látom, hogy ez is van olyan biztonságos matematikailag, technikailag?

"Ezt nem teljesen értem. Miért kéne bármit is eldobálni?"

Azért kell eldobálni, mert C*n bájt jön tömörítetlenül a nyers pcm-ben a hangkártyából. Amit vesztességmentesen flac-ba tömörítve n darab bájt lesz belőle. Azt felételezzük, hogy a Kolmogorov-komplexitása legalább n/4 bájt. Ezért a 3/4-ét el kell dobálni így vagy úgy. Ha egy az egybe ráeresztem az AES-t akkor nem dobál el belőle semmit.

Így már értem mire gondolsz, eresszek rá hash függvényt.

Viszont gondolj bele az implenetáció szempontjából.

Van egy gyerekfolyamatom ami az ffmpeg, ennek bemenete és kimenete be van kötve a fő folyamatba. A fő folyamat olvassa a hangkártya inputot amit névtelen csövön küld az ffmpeg gyerekfolyamatnak. A fő folyamat külön szálba olvas , külön szálba ír. Ha nem veszem külön szálba akkor instant holtpont alakul ki, befagy az egész.

Jóval egyszerűbb magára a tömörített flac stream-re ráereszteni a hash függvényt mint azt visszakövetni hogy melyik bájt offsettől melyik bájt offsetig a tömörítetlen pcm-ből a tömörített flac hogy alakul pontosan és a szerint skálázni hogy mekkora darabonként számítson rá hash-t. Gondolom ez így is jó.

Még ha egyszerűsítek már kész is van. Az egyszerűsítés az ,hogy előbb utóbb összegyűlik mindenképpen n darab bájt a flac streamre akkor is ha az abszolút csendet (csupa nulla pcm-et) enkódolom, csak nem mindegy mennyi idő alatt. Ha timeout alatt gyűlt össze n bájt akkor a random generátorom kiad annyi random bájtot az sha3_512 aktuális kimeneti állapotát, ha timeout-ot túllépte akkor csak az sha3_512 állapotát updateli azzal az adattal. Így végülis az az információ mint entrópiát nem dobtam ki, hogy x ideig volt abszolút csend ha volt ilyen (miután timeout felé kerülünk).

Pszeudo kódba ( a _ jelek szóközöket helyettesítenek, így nem gyomlálja ki a gyk a behúzásokat):

hashobj = create_sha3_512()

t1 = now()

while puffer = flac.read(n): Értékadás és feltételvizsgálat egyszerre

__t2 = now()

__hashobj.update(puffer)

__if (t2-t1 < timeout) and puffer.length == n:

____randomgen_output(hashobj.digest)

__t1 = t2

Köszönöm a megerősítést, technikailag így praktikusabb. Végülis így kész. A többi része az már eleve adott. (A nyers random bájtokból előállítva random egész tól-ig tartományban, random lebegőpontos, listából random kiválasztás, random keverés ... stb. dolgot értek a többi alatt.)

Még néhány gondolat :

Újra átgondolva az AES-es dolgot, az AES használható hash függvénynek is CBC módban. Triviális úgy ha az AES blokkméret egész számú többszöröse adatra kell. Mindig az enkriptált adat utolsó blokkját tekintem a hash értéknek. Bár ez bonyolítás lenne, mivel natívan az AES a blokméretének egész számú többszörösére számítandó

egyébként 16 bájt a blokkmérete az AES-nek, ha nem oszható vele akkor erre vannak praktikák, ha pedig így használnám mint itt hogy menet közben is kellenek az aktuális hash állapotok és ha nem osztható 16-al akkor ott már igen csak érteni kell matematikailag is.

Érdemes alábecsülni a Kolmogorov-komplexitásnak. Itt megjegyzem, hogy valójában nem tudom, hogy tényleg kell e maximális tömörítés (compression_level 12-es paraméter, default 5), mert a konstans faktor amit ráhagyok az alábecsülés miatt úgy is lecsonkítja a nyers random kimenetet. A level 5-ös tömörítés nem ad 2x nagyobb kimenetet mint a maximális azaz a level 12-es, legalábbis amiket teszteltem. Ha pedig tévedek és 2x nagyobb, akkor a hasítófüggvénnyel generált streamet 2x ritkábbra skálázom. Felőlem maradhat a level 12-es, nem muszáj ezzel spórolni (mármint cpu időt spórolna, de elbírja a gép bőven így is).

Triviálisan azért kell alábecsülni mint a Kolmogorov-komplexitása, mert ha pontosan nem tudjuk meghatározni akkor becsüljünk alá inkább mint felé. Ami talán kevésbé triviális, a törés miatt. Az sha2_512-nek nem brahiból a tovább fejlesztése az sha3_512. Mint kriptográfiai hash függvény az md5-ről tudom, hogy viszonylag egyszerű ütközést találni rá. Így azért is kell alábecsülni ezt a komlexitást, mert ha a jövőben törést találnak az alkalmazott hash függvényre akkor is megállja a helyét. A törés alatt nem csak a triviális eseteket értem, hanem már azt az esetet is ahol n darab bit ismeretében a következő bit előre kitalálásának valószínűsége több mint 50%.

Még eszembe jutott megjegyzés amiről el is feletkeztem.

Valójában nincs olyan algoritmus ami garantáltan legrosszabb esetben is 2x vagy 4x, de írhatom úgy is c konstansszor rosszabbul tömörítene mint a Kolmogorov-komplexitása. A c konstans lehet például egy milliárd is akár.

Csak gondoljunk a minden évben megrendezett function party-ra. Ott 64 kilóbájtba zenét, animációt "belepréselnek". A top hang, videó tömörítők meg se közelítik azt. Az informatikai mester munka. Megnéznék olyan általános célú képtömörítőt ami vesztességmentesen csak egy képkockáját legfeljebb akkorába betömörít mint az egész demó, zenével mozgóképpel tokkal vonóval együtt. Igaz az fordítva van, ott a kódot írnak ami elindításkor a beleírt algoritmusok generálják a zenét meg az animációt, a kódon addig csiszolnak az animáció és zene változtatásával ha kell, hogy beleférjen.

Viszont ha nem kell kreatív pl zenének lenni, könnyen csinálok tetszőlegesen rövidebb kódból hangot (ahol maga a kód a hangnak a egy tömörített változata tulajdonképpen), mint ahányszor nagyobb fájlt csinál belőle a flac tömörítő. Sőt mondok még jobbat, maga a hang digitális képe informatikailag egy adatszerkezet. Végtelen (számított) adatszerkezetet könnyen lehet csinálni, így végtelen hosszú hanganyagot véges kódból. Végtelenszer rövidebb a kód mint amit a flac csinálna belőle.

Ha pedig nem generátoros trükk akkor csak valószínűsíthetjük hogy túl messze nem jár a flac tömörített mérete az adott hanganyag Kolmogorov-komplexitásától.