True random generátor használata hogyan?

Mire fel gondolkozzak logikátlanul?

"Egyszeri és megismételhetetlen, nekem ezt tanították."

Ha készítek egy videót az egyszeri és megismételhetetlen.

A videót digitálisan kódolva veszem a bitjeit. Az nem igaz, hogy a videóból n db bit ismeretében ugyan olyan találati eséllyel jósolható meg az n+1.-ik bit mintha egy true random sorozat lenne, hiszen a videónak van struktúrája. Vagyis egyfajta rend van a videó bitjei között. Ha a videót 7z-vel pl titkosítom vagy valami hasonlóval akkor a statisztikai tesztek véletlenszerűséget fognak mutatni, de akkor sem true random lesz. Akkor is benne van a struktúra mely (legalább elvileg) visszafejthető mely szintén jobb eséllyel előre jósolható n db bit ismeretében (ha n megfelelően nagy) mint egy valódi random. Márpedig true random előállításáról volt szó. Tulajdonképpen vesztességes titkosítást kell csinálni a videón. A hasítófüggvények tulajdonképpen vesztességes titkosítások, hiszen végtelen elemű az értelmezési tartományuk és véges az értékkészletük. Érvényes rájuk a lavinaeffektus, azaz az inputnak egyetlen bitjének megváltoztatása, teljesen más kimenetet ad. Akkor jó egy hash függvény ha nehéz probléma olyan különböző x és y-t találni hogy f(x)=f(y).

"Volt rejtjelzőként csak azt tudom mondani, hogy nagyon elszálltál. Világba, túl bonyolítod a dolgokat."

Jól megfogalmazott tudományosan alátámasztott válaszra vagyok kíváncsi. Tisztelem, hogy rejtjelező voltál, de a tekintélyelv egy érvelési hiba.

A kérdésem ide vonatkozó része egyébként elméleti jellegű, hogy mennyi videóból mennyi true random készíthető.

Köszönöm a válaszokat.

Érdekes az a Python-os megoldás, de sajna nem tudtam lefuttatni, ennek azaz oka hogy windows-on próbáltam amire nem találtam kompatibilis python modulokat amit felhasználsz.

@SimkoL

Hülye logikával történő random generátort próbáltam már csinálni, teszteltem melyen elbukott, de ez még évekkel ezelőtt volt. Erről letettem hogy csinálok ilyet.

E helyett arra gondoltam, hogy többek között az NSA által is felügyelt az NIST által kibocsátott szabványos kriptográfiai hasító függvényt/függvényeket használok. Az SHA algoritmuscsaládból jó választás az SHA3-512.

Ahogy eddig is mondtam darabokra szedem a videót és ráeresztem a darabokra a megfelelő hash függvényt.

Csak azt nem tudom hogy érdemes csinálni, hogy mekkora darabokat legkézenfekvőbb/optimális hash-elni.

Vehetem képkockánként is, de ehhez előtte dekódolni kell a videót. Lehet szőrözésnek tűnik, de a vesztességes tömörítés miatt nem egyenértékű az információtartalma a videónak, azzal szembe mintha tömörítetlen lenne vagy legalábbis veszettségmentes, meg egyes képkockák csak számítottak a vesztességes tömörítés miatt.

Vagy egyszerűen csak feldarabolom a videót, nem értelmezve a videoformátumot meg semmit csak simán mint egy bináris fájlt, de az továbbra is kérdés hogy mennyi inputból mennyi outputot gyártsak.

Abba igazat adok, hogy "de nem kell túl 'sózni' mert egy idő után visszaüthet". Viszont ott van a feltételes mód. Ha pl veszem a videót ráeresztek egy RSA titkosítást ezt randomizált hosszú jelszóval tömörítem 7z-be majd titkostom truecrypt-el majd kettévágom és egyenként lehash-alom sha3-512-vel majd a 2 hash-t összexor-olom (kizáró vagy) ekkor kaptam 512 bit randomot azaz 64 bitet. Ugyan ezt megcsinálom sok videóval ami csak erre készült egyszeri felhasználásra. Azt ne mondja senki hogy ezzel csökkentettem a biztonságot, vagy ha ezt mondja akkor az egy nagyon erős állítás melyhez nagyon erős bizonyíték kell, sőt a hash-ét lehash-elem meg azt is meg azt is 100 iterációba digitálisan alá is írom majd azt is le hash-elem úgy, hogy a digitális aláírást használom fel mint "sót". Ha valaki azt mondja hogy felesleges ez a sok lépés hiszen csak a számítási időt hosszabbítom meg feleslegesen akkor igaza van. Félreértések elkerülése végett nem áll szándékomba így csinálni, ez csak egy példa volt, hogy attól hogy valami túlbonyolított az nem kauzális összefüggés azzal, hogy attól gyengébb végeredményt ad.

"azaz 64 bitet"

*bájtot