# SeedSigner képi entrópia. Hogyan lesz egy fényképből seed phrase

**Cikk:** SeedSigner image entropy, how a photograph becomes a seed phrase
**Szerző:** SeedSigner vezető fejlesztő (kdmukai, AI-asszisztált elemzés, nem független audit, nem tanúsítvány)
**Dátum:** 2026-08-12 (revision a13c64a9)
**Verzió:** SeedSigner 0.8.7 (commit e0a80d4b)
**Forrás:** https://kdmukai-bot.github.io/seedsigner-ai-analysis/image-entropy/

## Bevezetés és a rövid összefoglaló

A SeedSigner 0.8.7-es release-hez kapcsolódó AI-asszisztált elemzés azt vizsgálja, hogyan alakul a kamerával készített fénykép seed phrase-ö, és hogy a végeredmény valóban elég entrópiát hordoz-e egy 24 szavas Bitcoin seedhez. A mérés 42 capture runon, 4 fizikai eszközön (Pi Zero alapú SeedSigner), a release byte-azonos működését produkáló instrumentált buildokkel készült, és minden szám a release-be SHA-256-ba kerülő pontos byte-okból lett számítva, a nyers felvételek (~470 MB) letölthetők.

A legfontosabb üzenet: **egy normálisan megvilágított jelenet ezerszeres nagyságrenddel több entrópiát ad, mint amennyi egy seed phrase-höz kell.** Polc vagy üres fal, mérve 563-774 ezer és 1,5 millió bit közötti unpredictabilityt produkált a 256 bites 24 szavas seed küszöbhöz képest, minden tesztelt eszközön, a legszigorúbb becsléssel is. Ha viszont a lencse teljesen fénymentes (face-down az asztalon, táskába rejtve, stb.), az entrópia összeomlik: **a négy eszközből háromon minden mért final image a 256 bites küszöb alá esik.** A 2021-es bevezetés óta minden release-t ellenőriztek, és az eredmények mindegyikre érvényesek.

## A megvalósítás: négy input a SHA-256 láncba

SeedSigner a seed entrópiát egy futó SHA-256 lánccal építi a `tools_views.py` fájlban, négy inputot fűzve össze sorrendben: (1) CPU serial number (L151–158), (2) `time.time()` (L161), (3) élő preview frame-ek, egy 50-es Rolling Window (L165–167), és (4) a teljes felbontású final image (L170).

Az első két input gyakorlatilag nem járul hozzá az entrópiához. A SeedSigner OS-ének nincs valós idejű órája és nincs hálózata, tehát a rendszeróra minden bootnál nulláról indul, a `time.time()` a bekapcsolás óta eltört törtszekundumokat adja vissza, aminek unpredictabilityje a gombnyomás sub-second időzítésére és a felhasználó reakcióidejére korlátozódik. A CPU serial egy fix, eszköz-specifikus érték, nem titkos. A kód saját commentje "modest entropy"-nak nevezi, jogosan. A biztonság a 3-as és 4-es inputra épül.

Ezek nyers mennyisége nem kicsi: az 50 preview frame (240×240 RGBA, 1 382 400 bit/db) és a final image (480×480 RGB JPEG-decoded, 5 529 600 bit) összesen **74 649 600 bit** a láncba. Egy 24 szavas seed **256 bit**. Ezek a legolvashatóbb számok a dokumentumban, de semmi sem garantálja, hogy ezek a bitek valóban értékes entrópiát hordoznak, egy frame csak konténer, és hogy mennyi unpredictabilityt tart, a kamera irányától és a szenzor állapotától függ.

**Fontos distinkció: a "margin" nem "score".** A SHA-256 mindig 256 bitet ad, függetlenül a bemenettől. Ha legalább 256 bit unpredictability ment bele, minden ezen felüli részextraneous, a seed nem lesz nehezebben támadható tőle. A 256 egy küszöb, nem cél, és egy nagy margin nem jelent arányosan erősebb seedet. Aki ilyen seedet támad, az a 256 bitet támadja, nem egy többmillió bites fényképet. A margin a vékony végnél számít, nem a vastag végnél, ezért fókuszál ez az elemzés a fényhiányos állapotokra.

## Két fénykép soha nem egyforma

A képi entrópiával szembeni legkézenfekvőbb aggály: mi van, ha ugyanazt fotózod le kétszer, és ugyanazt a seedet kapod? Két fotó a **teljességében** soha nem azonos, nem pixelenként, hanem frame-ként. Három dolog hajtja:

1. **A kamera mozog.** Kézben tartva elkerülhetetlen valamekkora mozgás.
2. **A fény maga véletlenszerűen érkezik.** A fény diszkrét fotonokban jön, és hogy egy adott fotoszitába egy expozíció alatt hány foton esik, az frame-enként friss kvantumstatisztikai húzás, ez a photon shot noise, a jel természetes variációja, nem a kamera adja. Megvilágított jelenetben ez a domináns frame-to-frame változás forrása: egy tökéletes szenzor egy tökéletesen stabil jelenetet fotózva sem készítené ugyanazt a fotót kétszer.
3. **A szenzor saját zajt ad.** Minden read hozzáad zajt a szilícium hőjéből és a readout elektronikából. Megvilágított jelenetben ez kisebb hozzájárulás, de a padló az, ami megmarad, amikor a fény eltűnik.

A képkülönbség és a SHA-256 kapcsolata: ha egy pixelt egy lépéssel megváltoztatunk, a hash teljesen más lesz, és a seed is teljesen más. Egy majdnem-azonos fotó egy támadónak semmit sem ér, csak byte-for-byte egyezés számít. A SeedSigner release-ek nem mentik a capture-öket: a preview frame-ek és a final image csak memóriában léteznek, a SHA-256 láncon áthaladnak, és eltűnnek; a microSD-re semmi sem íródik, és az eszközön utólag nincs mit visszaolvasni.

Egy konkrét demonstráció: két egymás utáni felvétel egy megvilágított könyvespolcról, a készülék asztalon pihent, semmi sem mozdult el, 0,64 mp választja el őket. Szemre ugyanaz a kép. Az adatokban **a frame színértékeinek 80,82%-a** különbözik. A kivonás (két kép különbsége ×40-es erősítéssel) a polc széleit rajzolja újra variációban, a fényes régiók adják a legnagyobb eltérést, az árnyékos hézagok csendesek. Ez magának a fénynek a véletlensége, láthatóvá téve.

A mérési eredmények a könyvespolcos baseline-on: **563 774 bit unpredictability** egy final image-ban (a legszigorúbb standardizált padlóval, 2202×-e a 24 szavas seed küszöbnek), **80,82%** színérték-különbség két egymás utáni capture között, **98,89%**-a a frame byte-pozícióinak legalább egyszer változott a tíz capture-es sorozatban, és **0** ismétlődő final image 420 capture-ben, minden sorozatban (megvilágított, halvány és sötét). Ez utóbbi szám felel meg az aggályra: minden final fotó különbözött minden másiktól, a legkedvezőbb körülmények között is, ahol a repeat ésszerűen előfordulhatott volna.

A módszer nem új: a Cloudflare 2017 óta termel véletlenszámot a LavaRanddel (kamera, lávalámpák fala), az első ilyen rendszer a Silicon Graphicsé volt 1997-ben. Ezek a rendszerek szándékosan kiszámíthatatlan folyamatra irányítanak kamerát; a következő szekció azt méri, hogy egyáltalán számít-e a téma.

## Az üres jelenet: könyvespolc vs. üres fal

A könyvespolc "forgalmas" jelenet, élek, szöveg, textúra, szín. Az elterjedt tanács képi entrópiához ehhez hasonlót fotózni, és az aggodalom az ellentétes eset: mi van, ha nincs semmi, amit nézni? Az üres fal gyenge seedet ad? Közvetlenül mérték. Egy üres fehér fal, ablakfény által megvilágítva, mozdulatlan Pi Zero: a lehető legunalmasabb capture, ami ebből a feature-ből kijön, nincs jelenet-részlet, nincs kamera-mozgás, nincs mesterséges fény. Ezek a pontos byte-ok, amiket az instrumentált v0.8.7 build a láncába táplált.

A két leghasonlóbb capture (a 45 lehetséges párosítás közül, a tíz capture-es run frames 03 és 06) **77,69%**-ban tér el színértékben, és a különbség-kivonás ×40-es erősítéssel sűrű per-pixel variációt mutat az egész frame-en. A fal kivonódik, és ami marad, az a fény véletlenszerűsége.

A számok: **684 759 bit** unpredictability az álló üres fal final image-ban, **2675×**-e a seed küszöbnek. A 20-ból 20 preview frame distinct az álló run-ban, a kézremegés nem ez, amire az entrópia épül. ±21% a különbség az üres fal és a könyvespolc között ugyanazon az eszközön, összehasonlítható mindkét becslési módszer alatt (a sorrend becslésenként flip-el).

**Az üres jelenet nem degenerált jelenet.** Az üres fal kissé a könyvespolc fölé mért ugyanannál az egységnél, eredmény, ami visszafelé olvas, amíg meg nem nézzük, hol van az egyes jelenetek fénye. A fal featureless, de mindenhol fényes: minden fotosite mélyen a photon régióban ül, minden frame-ben saját friss véletlen húzást gyűjtve. A frame byte-pozícióinak 99,999%-a legalább egyszer változott a tíz capture-en át. A könyvespolc nagy része árnyékban van, ahol ugyanez a mechanizmus fordítva működik: kevesebb beérkező foton = kevesebb friss variáció, és a forgalmas jelenet sötét foltjai szinte semmit sem keresnek.

**A "üres fal" aggály két dolgot kever össze:** egy featureless jelenetet és egy fényéheztetett szenzort. A mérések tisztán szétválasztják: mindent az dönt el, hogy a fény eléri-e egyáltalán a szenzort, nem az, hogy a fény miről verődik vissza.

## Amikor nem ér fény a szenzorhoz, a tervezési hiba

Minden fent megvilágított jelenetben történt. Ez a szekció azt vizsgálja, hogy ugyanaz a hardver és ugyanaz a kód mit csinál, amikor nem ér fény a szenzorhoz, és itt talált az elemzés olyasmit, amit a projektnek javítania kell.

A bottom line tisztán: **ebben az állapotban az entrópia összeomlik.** A legszigorúbb padló alatt a négy egységből háromon minden mért fényblokkolt final image a 24 szavas seed 256 bites küszöbe alá esik, és azokban a run-okban, ahol a preview réteg semmit sem tartott, az egész lánc is azzal együtt esik. A negyedik egység sötét capture-i a küszöb felett maradtak, és a legjobb magyarázat, amit az adat kínál: a tágas enclosure-be visszaszivárgott némi fény, baleset, nem tervezett padló.

"Dark" alatt nem dim szoba értendő: a lencse teljesen vagy hatékonyan blokkolva volt. Ez nem halvány szoba; a halványodás külön lett mérve, egy szoba lépcsőzetes halványításával az átlagos fénytől a sötétségig: az entrópia vékonyodik a jelenet halványodásával és omlik össze, ahogy a feketeséghez közelít.

Az útvonal, ami számít, a hétköznapi: **face-down az asztalon átlagos árnyékban, nincs tömítés, nincs enclosure, nincs szándék.** A szándékosan tervezett fénytömítések is ki lettek próbálva; a sima asztal alacsonyabb számokat produkált, mint bármelyikük.

A final image, ami marad: a face-down capture ×60-as erősítésben egy lapos zöld mezőt mutat, nem az entrópiát. A zöld csatorna szinte minden pixelnél pontosan 1-nél ül, egy konstans pedestal, amit az erősítés wash-á alakít; a zöld csatorna azért emelkedik először, mert a szenzor kétszer annyi zöld fotoszitával rendelkezik. Az információ a ritka variációban van a pedestal tetején, és alig maradt belőle valami. A run két leghasonlóbb capture-jének kivonása: **a frame 691 200 értékéből 105 különbözik (0,0152%)**, és a run final image-a **64 bit** a legszigorúbb padló alatt, **a 24 szavas seed szükségletének negyede**. Mellette, a megvilágított könyvespolc ×12-es erősítésben (egy ötöd akkora erősítés): több mint félmillió bit 64 ellen, ugyanazon a padlón.

A session-to-session szórás óriási egy névlegesen változatlan beállítás alatt: ugyanaz az asztalpozíció percekkel korábban **5774 bit**-et is produkált, semmi sem mozdult, a light test ezt a run-t "kontaminált" nak jelöli szórt fény miatt, és ez maga a lecke: egy észrevehetetlen szivárgás több százszorosára lendítheti a számot session-ök között. Ezek pontok egy széles eloszlásból, nem korlát. De megállapítják az elérhető állapotot: **a készüléket lencsével lefelé egy átlagos asztalra helyezni a final fotót messze a 24 szavas seed küszöbe alá nyomhatja, szándék és felszerelés nélkül.**

A safety net (preview layer), aminek tartania kellett volna: egy final image 256 alatt az, amire a preview layer létezik, akár 50 további frame, mind külön expozíció, a final elé láncolva. A capture-ök azt rögzítik, amit ez a réteg ténylegesen tartott, és a lencse blokkolásával a válasz: **majdnem semmi, és néha pontosan semmi.**

A mechanizmus: nem érkező jel mellett a preview path a frame-et nullára kvantálja. Amikor ez megtörténik, a window egy slotja tiszta feketét tartalmaz, minden érték azonos, és egy támadó kiszámíthatja ezt a frame-et és annak lánc-hozzájárulását a panel méreteiből. Egy olyan értéket hash-elni, amit a támadó már ismer, nulla unpredictabilityt ad, akárhányszor hash-eljük is. A mért sötét window-okban az 50-ből **45-50 slot tartotta ezt a konstanst vagy egy ismétlést.**

A négy táblán a helyzet a következő: három tábla auto-exposure a gain ceiling-jén stabilizálódott blackout alatt, és ezek közül kettőnél minden mért session tartott legalább néhány live frame-et; egy tábla 10%-kal a ceiling alatt stabilizálódott, és **soha nem produkált live frame-et**. Az egyik táblán a hatból hat lencseblokkolt run-ban mind az 50 slot az ismert konstans volt, és a preview layer pontosan nullát járult hozzá. A seed kizárólag a final image-ra támaszkodott, és a legvékonyabb run **~36 bit** a szükséges 256 bit ellen, a legszigorúbb padló alatt. Még az optimista most-common-value becslés is csak **389**, egy **1,52× margin**.

Három finding élesíti ezt az anekdotából tervezési problémává:

1. **A failure common-cause.** Mindkét réteg ugyanazt a jelenetet nézi ugyanazon az auto-exposure-on. A fény-éheztetés, ami a final image-et vékonyítja, ugyanaz a fény-éheztetés, ami a preview window-t omlasztja össze, és ami a túlélő live frame-eket is vékonyítja (a legrosszabb live-frame pár 469 bit, és ez az optimista becslés). **A rétegek nem independent módon buknak el, tehát a rétegek számolása nem biztonság-számolás.**

2. **Melyik réteg megy el először, egységenkénti baleset.** Ugyanaz a blackout állapot alatt az auto-exposure három egységen a gain ceiling-jén, egyen 10%-kal alatta stabilizálódott, stabilan, minden rögzített session-ben. Minden ceiling-nél lévő egység, amelynek window-át mérték, produkált legalább néhány live frame-et; a ceiling alatti egység soha. A korreláció egyhangú, de pontosan az: korreláció négy egységen; semmi a kódban nem kontrollálja vagy figyeli, hogy a készülék a kés-Éél melyik oldalán ül.

3. **Van egy második útvonal is ugyanarra az állapotra.** A gomb preview alatt tartása a kódot visszatérésre készteti, mielőtt bármilyen frame-et appendelne, determinisztikusan, minden mért próbálkozáson: **nulla preview frame, bármilyen megvilágítás mellett.** Ez a quirk a v0.7.0-ban került be egy nem kapcsolódó crash fix-szel. A blokkolt lencse és a tartott gomb egymástól independent, balesetszerű, és mindkettő a négy-bemenetes láncot egyetlen értelmes bemenetre redukálja.

Amit a review screen mutat, ebben a blokkolt-lencse állapotban, **nem mond semmit a capture-ről**: a tesztekben a kijelző egyszerűen nem követi a mérést, tiszta fekete képernyők jöttek a legmagasabb mérésű sötét capture-ökből, halvány noisy képek a legalacsonyabbakból. **A screen nem megbízható jelzője a capture entrópiájának.**

Amit ténylegesen javítana (a projekt számára, nem a felhasználó számára): append-elni a frame-et a gomb ellenőrzése előtt, hogy a tartott gomb ne hagyhassa ki a window-t; ellenőrizni, hogy a window frame-jei distinct-ek (ez minden mért repeated-frame hibát elkap); és ellenőrizni, hogy a fény ténylegesen eléri a szenzort, mert a dim-ladder adatok azt mutatják, hogy distinct frame-ek is hordozhatnak szinte semmit. Több frame appendelése önmagában nem javítás: lencseblokkolás mellett az append-elt frame-ek az ismert konstansok. A gomb-kezelési fél upstream PR #990-ként lett beküldve, a distinct-frames fél pedig PR #991-ként, ami teljes pool-t igényel a final capture előtt. **Mindkettő merged upstream, a 0.8.7 tag után**, tehát a következő release-ben érkeznek.

Scope, mindkét irányban őszintén kimondva: ez egy valódi tervezési finding, nem törés. Egyetlen specifikus seed sem volt demonstráltan visszanyerhető, és a szóban forgó állapot (face-down árnyékban vagy tartott gomb) olyasmi, amit egy átlagos capture-nek nincs oka meglátogatni. De a legszigorúbb standardizált padló alatt a mért final image-ek nem érik el a küszöböt, és a csak rájuk támaszkodó láncok sem, **a marginok per-unit balesetektől és session-to-session szerencsétől függően, százszoros vagy nagyobb faktorral.** A design redundancia-érve nem tart ott, és semmi az eszközön nem veszi észre. A sötétség nem szerencsére bízandó állapot; ez egy detektálandó és visszautasítandó állapot.

## Mit kell tenned (a felhasználó)

Három szabály:

1. **Capture in a lit scene.** Bármilyen megvilágított jelenet működik. Az üres fal ugyanolyan jól mért, mint a könyvespolc, és minden megvilágított capture minden eszközön ezerszeresen tisztította a küszöböt. Nem számít, hogy mit fotózol; számít, hogy meg van világítva. **Ne capture-ölj fény-éheztetett szenzorral:** face-down, lencse letakarva, táskába vagy megvilágítatlan helyre irányítva. Semmi a képernyőn nem fog figyelmeztetni. Ha a preview-n lévő jelenet halványnak vagy majdnem feketének tűnik, ne használd seedhez. Az egyetlen megvilágítás-kivétel: ne irányítsd közvetlenül erős fényforrásba, a szaturált szenzor mindenhol maximumot olvas, és a frame-to-frame variáció trunk-álódik. Átlagosan jól megvilágított jelenetek, ablakokkal együtt, nem probléma.

2. **Tap the button, do not hold it.** A tartott gomb a preview réteget teljesen kihagyja: a preview-n, a capture-ön és az accept screen-eken egyetlen gesture-rel halad át, és egy frame sem láncolódik. Az upstream fix, seedsigner PR #990, merged és a következő release-ben érkezik. Addig is, amíg nem futtatod a release-t, ami tartalmazza, a habit a fix. Egy tap megadja a design-nak az 50 frame-et, amire épült. A window 3,5-6 másodperc alatt telik meg az élő preview alatt (táblánként), tehát az irányításra szánt pár másodperc már ezt a munkát végzi. A preview hosszabb nyitva tartása nem ad több frame-et, csak frissebbeket.

A következő release érvényesíti, amit ez a habit helyettesít. A merged változtatások a capture screen-et zárva tartják, amíg 50 distinct, nem üres preview frame össze nem gyűlik, és counter-t mutatnak a telítődésig (PR #991), tehát a tartott gomb sem a window-ot nem hagyhatja ki, sem a capture-t nem indíthatja el a kitöltés pillanatában. A fenti lit-scene utasítás nem érintett: egyetlen release sem ellenőrzi még, hogy mennyi fény érte el a szenzort.

3. **Watch the preview, and know what watching buys you.** A watchozás megerősíti, hogy a kamera él és fényt lát. Egy élő preview követi a kézmozgást; egy halott, disconnected vagy lefedett kamera feketét vagy fagyott képet mutat. Ez az ellenőrzés valódi és érdemes elvégezni. **A screen mondja meg, hogy a kamera működik. A jelenet dönti el, hogy mit gyűjt.**

## Mit kell megbíznod

A mérések azt mondják, hogy a kameraút bőséges entrópiát szolgáltat fényben, és mindenütt tisztította a küszöböt, ahol mérték. Nem mondhatják, hogy a te konkrét seeded is ezt tette, és egyetlen mérés sem mondhatja. A kép-entrópia más bizalmi relációban ül, mint a SeedSigner seed-előállításnak többi módja, és a különbség strukturális, nem kód-minőségi.

Három lépés, és csak kettő transzfer-álható:

1. **Verify the process.** Olvasd el a kódot és állapítsd meg, mit csinál a bájtokkal. Ez a két dokumentum: a lánc kompozíciója, a release történet, és a mérések arról, amit a kód ténylegesen a SHA-256-ba táplál.

2. **Verify you are running that code.** A source review nemmit sem mond a microSD-n lévő binárisról. A release image-ek reprodukálhatóak a v0.7.0 óta a projekt saját állítása szerint, és a build procedúra külön dokumentált, tehát az erős forma a forrásból build-elni és megerősíteni, hogy byte-for-byte a projekt által publikált image-et kapod. A gyengébb forma a publikált manifest hash és a PGP aláírás ellenőrzése. Ez többet számít, mint amennyire hangzik: a projekt saját README-je kimondja, hogy a release image-eket egy személy készíti és írja alá, aki az aláíró kulcsok egyetlen birtokosa. A reprodukálható build-ek pontosan azért léteznek, hogy a bizalom ne ott végződjön. **Ennek a lépésnek a kihagyása az 1-es lépést dekoratívvá teszi.**

3. **Choose the scene and watch the capture.** Az utolsó kontroll a láncban egy személy által végrehajtott, és a 4. szekció után a scope-ja tiszta: a watchozás megerősíti, hogy a kamera él, és a megvilágított jelenet választása az, ami ténylegesen biztosítja az entrópiát. Az ellenőrzött kód, az ellenőrzötten futó kód, még nem hozhatja meg helyetted ezt a választást.

Az 1-es és 2-es lépés egyszer történik, és ugyanaz mindenkinek. A 3-as lépés az egyetlen per-capture kontroll, és csak te végezheted el valaha.

**Miért nem exportálható az input.** Az obvious fix az lenne, hogy a készülék kiírja a hash-elt bájtokat, hogy valaki máshol ellenőrizhesse őket. Tekintsük át, mi kellene hozzá. Az entrópia inputok óriásiak: 691 200 byte a final image, plusz ötven preview frame 230 400 byte-onként, nagyjából 12 MB összesen. A SeedSigner egyetlen adatcsatornái a bejövő kamera és a kimenő képernyő, és egy QR kód néhány kilobyte-ot visz; a 12 MB felfelé négyezer QR kód. Az egyetlen praktikus csatorna a microSD kártya lenne.

És ez az image data a te titkod. Ez az, amiből a seed származik, tehát a birtoklása effektíve a seed birtoklása. A SeedSigner úgy van építve, hogy soha ne írjon titkot tartós tárolóra. A review-ált release-en az entrópia inputok RAM-ban maradnak és felszabadulnak, amint a seed származtatva van.

A kép-entrópia rendkívüli mennyiségű unpredictabilityt tesz a seedbe. Az ára, hogy csak a folyamatot ellenőrizheted, nem az egyedi outcome-okat. A dice ezen a ponton különbözik, és ez az egyetlen különbség, ami itt számít: a dobások elég kicsik ahhoz, hogy papírra írhatók legyenek, tehát egy egyedi dice eredmény örökre külsőleg ellenőrizhető marad, míg a kamera adata sehol nem létezik a hash-elő eszközön kívül. Ami a kép entrópiát nem teszi gyengébbé a dice-nél: egy megvilágított capture a láncba nagyságrendekkel több unpredictabilityt táplál, mint egy dice session. De amint egy kamera seed generálódik, **senki nem mehet vissza és erősíthet meg semmit róla**, amiért a fenti process verification az egész, amit fel lehet kínálni.

## Hogyan ellenőrizheted ezt az elemzést

Minden itt idézett szám a nyers kamera frame-ekből lett számítva, amik e dokumentum mellett publikáltak, nagyjából 470 MB 42 capture run-on, 4 fizikai eszközön, pontosan úgy, ahogy a készülék a SHA-256-nak adta őket. Semmi nem múlik olyan számon, amit bizalommal kell elhinni.

A "NIST tesztek" kérdés rendszeresen felmerül. Két különböző dokumentum van mögötte, és másképp válaszolnak:

- **SP 800-22**, a statisztikai tesztcsomag, amit általában értenek, a generátor outputját teszteli, és itt nem segít egyik irányban sem: minden, amit a SeedSigner csinál, SHA-256-ban végződik, aminek outputja átmegy ezeken a teszteken, függetlenül attól, hogy a bemenet milyen gyenge volt, míg egy nyers fénykép elbukik rajtuk, függetlenül attól, hogy milyen erős volt, mert a fényképeknek van struktúrája. A NIST maga van dokumentálva, hogy a suite nem az entrópiásforrások értékelésére való.

- **SP 800-90B**, az entrópiásforrás-standard, az ami alkalmazható, és az estimator suite a NIST saját referencia tool-jával futott le minden final-image capture sorozaton. Az eredmények azok, amiket a fenti számok már tükröznek: a megvilágított jelenetek a küszöböt nagyjából **kétezer**-szeresen tisztítják a legszigorúbb standardizált padlón, és a fény-éheztet capture-ek alá esnek a négy eszközből háromon. A teljes módszer, a per-sorozat eredmények, és ami a standard teljes validációs rezsimjéből nem teljesült (restart testing, dokumentált fizikai zaj modell, runtime health tesztek; ez az elemzés nem állít 90B validációt), a companion document-ben van.

A working a companion documentben van (data and methodology): a kanonikus számok a mögöttük lévő estimator-ral, minden dark run preview-window struktúrája, hogyan készültek az instrumentált build-ek és hogyan voltak provenance-locked a release-hez, minden 2021-es release egyenként ellenőrizve, minden felvetett aggály az elbírálásával és az elbírálás leggyengébb pontjával, ami nem volt ellenőrizve, és a parancsok, amik minden számot újraszámolnak a publikált frame-ekből.

AI-first megközelítést alkalmaz: sűrű, deklaratív, és claim-ről claim-re halad, nem érvelést. Ez a struktúra teszi olcsóvá az ellenőrzést, és egy modellt ráirányítani a leggyorsabb út a válaszhoz. Tökéletesen olvasható akkor is, ha inkább magad mennél végig rajta.

A javításokat és challenge-eket szívesen fogadják, különösen a mérésekre. Nincs publikált külső review erről az útról, amiről tudnak: nincs független mérés és nincs harmadik fél reprodukciója ezeknek a számoknak. A nyers capture-ek pontosan azért szállítódnak, hogy ez változhasson. **A munkák, amik ellentmondanak ezeknek a számoknak, hasznosabbak, mint amik megerősítik őket.** Válaszoláskor hivatkozz a review-ált revisionre: a reporting guidance elmagyarázza, mit kell rögzíteni és miért számít, ha ezeket a dokumentumokat revideálják.

**Scope disclosure:** AI-asszisztált elemzés a SeedSigner vezető fejlesztőjétől. Nem független audit, nem tanúsítvány, és nem a SeedSigner projekt hivatalos publikációja. Scope: csak kép-entrópia. Nem egész-termék audit. Módszerek, adatok és provenancia: data and methodology.

## Összegzés

A SeedSigner 0.8.7 kép-entrópiája **megfelelő entrópiaforrás**, de csak akkor, ha a felhasználó betart három szabályt. A 42 capture run, 4 fizikai eszköz, ~470 MB publikált nyers adat alapján a legszigorúbb NIST SP 800-90B padló alatt egy megvilágított jelenet (akár egy üres fehér fal) 563-684 ezer bit unpredictabilityt ad, ami 2202-2675-szöröse a 24 szavas seed 256 bites küszöbének. A fény a kulcs, nem a jelenet részletessége. A teljes SHA-256 lánc négy inputból épül: CPU serial + time.time() (mindkettő nével) + akár 50 preview frame (1,38 M bit/db) + final image (5,5 M bit) — az utolsó kettő hordozza a teljes entrópiát. A photon shot noise (kvantumstatisztikai fotonbeérhelyezés) a domináns frame-to-frame változás forrása megvilágított jelenetben; Cloudflare LavaRand 2017 óta, SGI 1997 óta termel hasonló random forrásból.

A **sötét állapotban az entrópia összeomlik**: 4 eszközből 3-on minden lencseblokkolt final image a 256 bites küszöb alá esik (64, 113, 9, 20, 52, 118 bit), és a preview layer is ugyanazon a fény-éheztetésen bukik el — common-cause failure, ahol a "redundáns rétegek" nem independent módon buknak. A preview window 45-50 slotja az 50-ből konstans fekete képpé kvantálódik (az attacker kiszámíthatja a panel méreteiből), és egy táblán mind az 50 slot ismert konstans a 6/6 sötét run-ban. Két út vezet egy-láncú állapothoz: (1) blokkolt lencse (probabilistic, per-unit), (2) tartott gomb preview alatt (deterministic, v0.7.0 quirk, minden fényviszony mellett). A kórhárom finding: common-cause, per-unit knife-edge, és a második úti kiindulópont.

Az **upstream fix-ek már mergelve vannak** a 0.8.7 utáni release-hez: PR #990 (append frame a gomb ellenőrzése előtt) + PR #991 (50 distinct, nem üres preview frame előfeltétel + counter). A 0.8.7-et használóknak három utasítást kell betartaniuk: (1) capture in a lit scene (preview-n dim vagy fekete → ne használd), (2) tap the button, do not hold it (a tartott gomb kihagyja a preview-t), (3) watch the preview (a screen mondja meg, hogy a kamera él, de nem mondja meg, hogy mit gyűjtött — ez utóbbit nem is tudja mondani). A review screen **nem megbízható jelzője a capture entrópiájának**: tiszta fekete screenek jöttek a legmagasabb sötét mérésekből, halvány noisy képek a legalacsonyabbakból.

A **bizalmi lánc három lépcsős**: (1) process verification (forráskód review + reprodukálható build v0.7.0 óta + PGP manifest hash), (2) build verification (release image byte-for-byte reprodukálása), (3) capture SOP (lit scene + tap not hold + watch preview). Az 1-2. lépés egyszeri, mindenki számára közös; a 3. lépés az egyetlen per-capture kontroll, és csak a felhasználó végezheti el. A camera-data nem perzisztálódik (privacy-feature, szándékos), tehát a seed utólag nem ellenőrizhető — ez a kép-entrópia sajátos trade-offja a dice rolls-hoz képest, ahol az outcome papíron örökre ellenőrizhető marad.

## A legfontosabb tanulságok a saját rendszerünkre

A Bitcoin self-custody kontextusban ez az elemzés három kulcsfontosságú tanulságot hordoz:

1. **A reprodukálható, független audit hiánya a kép-entrópiánál strukturális.** A Coldcard 2026.07-es exploit óta (lásd a `bitcoin-wallet-security.md` topic bejegyzést) a wallet security alapeleme a független audit és a multi-source entropy. A SeedSigner kép-entrópiája sajátosan nem auditálható utólag: a capture-ök nem perzisztálódnak (szándékosan, ez a privacy-feature), tehát a seedre vonatkozó claim csak a **folyamat** ellenőrzésére szűkül, nem az egyedi outcome-okra. Ez a dice rolls-hoz képest más bizalmi reláció, és a self-custody gyakorlóknak tudniuk kell róla. A review screen nem megbízható jelző, csak a fényforrás valósága és a fény valódi elérése a szenzorig.

2. **A "common-cause failure" tanulság.** A 2026.07-es Coldcard exploit is common-cause volt (a PRNG mintavételezési hibája egyetlen komponensben), és a SeedSigner kép-entrópiája is az: a fény-éheztetés egyszerre omlasztja össze a final image-et és a preview window-t, mert ugyanaz az auto-exposure nézi mindkettőt. **A security-design-ban a "redundáns rétegek" száma nem safety-szám, ha a rétegek ugyanazon a fizikai/mechanikus úton mennek.** A Coldcardnál a megoldás multi-source entropy pool volt (lásd Jade 7-source); a SeedSignernél a fény-független ellenőrzés kellene (PR #991 részben megoldja, de a light-level check még ajánlás).

3. **A merge-elt upstream PR-ek (#990, #991) már downstream patch-ben vannak.** A 0.8.7 review-ált release-ben a tartott gomb és a repeated-frames window-ok problémája **nem javított**, ezek a következő release-ben érkeznek. Aki ma használ SeedSignert 0.8.7-tel, annak a **"tap, don't hold"** habit az egyetlen védelme a button-skip ellen, és a **"lit scene, watch the preview"** a fény-éheztetés ellen. A saját rendszerünkben ez azt jelenti, hogy a wallet-setup SOP-nak tartalmaznia kell ezt a két utasítást, amíg a javított release el nem érhető.

## Forrás

- Elemzés: https://kdmukai-bot.github.io/seedsigner-ai-analysis/image-entropy/
- Companion document (data and methodology, gépi-first): https://kdmukai-bot.github.io/seedsigner-ai-analysis/image-entropy/evidence.html
- SeedSigner projekt: https://github.com/SeedSigner/seedsigner
- SeedSigner PR #990 (button-handling fix, merged): https://github.com/SeedSigner/seedsigner/pull/990
- SeedSigner PR #991 (distinct-frames check, merged): https://github.com/SeedSigner/seedsigner/pull/991
- Cloudflare LavaRand: https://www.cloudflare.com/learning/ssl/lavarand/
- Sanguinetti et al. 2014. Quantum random number generation on a mobile phone
- Captured code: `tools_views.py` L151-L174 (a lánc összetétele)

## Kapcsolódó külső

- **Coldcard 2026.07 exploit**, ugyanaz a multi-source entropy tanulság, másik perspektívából (PRNG hiba vs. camera-kvantálás common-cause).
- **Blockstream Jade**, "7-source entropy pool" (HW CRNG + radio noise + env sensors + camera + CPU counters + user input + companion app), explicit anti-Coldcard marketing: "one weak source can't collapse the pool".
- **SP 800-90B**. NIST entropy-source standard, az SP 800-22-től eltérően valóban alkalmazható az entrópiásforrásokra.
- **LavaRand** (Cloudflare, 2017–) és az SGI eredeti 1997-es rendszere, a "kamera mint kvantum RNG" termék-példája.

## Kapcsolódó belső

- flat tanulmány-gyűjtemény. Ez a cikk a `seedsigner__2026_08_image_entropy.md` néven kerül (flat struktúra, a `seedsigner_` prefix-szel).
- több UGMF epizód foglalkozik a SeedSigner 0.8.x release-ek funkcióival (22 nyelv, BPQR, BBQR PSBT).
- topic, az az air-gap self-custody filozófiája és a kamera-alapú entrópia privacy-trade-offjai.
- topic, a Coldcard exploit tanulságai és a multi-source entropy elv (lásd Jade és BitKey).

## Hogyan kapcsolódik a saját rendszerünkhöz

A Bitcoin self-custody biztonsági lánc kontextusában ez az elemzés három konkrét kapcsolódási pontot ad:

1. **A self-custody SOP-nak tartalmaznia kell a "tap, don't hold" és "lit scene" utasításokat**, amíg a SeedSigner következő release-e (PR #990 + #991) el nem érhető. A wiki `bitcoin-wallet-security.md` topic jelenlegi bejegyzései (Coldcard exploit, Jade 7-source) kiegészítendők egy SeedSigner-specifikus szekcióval: "SeedSigner 0.8.7 image entropy — használati szabályok". Ez a kanonikus magyar nyelvű referencia a téma wiki-be kerülésekor.

2. **A "common-cause failure" tanulság átvihető minden entrópiaforrás-tervezésre.** A Coldcard 2026.07-es exploit és a SeedSigner kép-entrópiája analóg módon bukott el: mindkettőnél egyetlen fizikai úton (TRNG mintavételezés vs. fény-bemenet) keresztül mentek a "független" entrópiás rétegek. A wiki `bitcoin-wallet-security.md` topic-ban ez a két case study összekapcsolható egy "Common-cause failure patterns in entropy sources" szekcióban, a saját wallet-setup SOP-nk a multi-source entropy-t preferálja, de ennek a "source-ok valóban függetlenek-e" ellenőrzésével együtt.

3. **A "nem-exportálható input" trade-off tudatosítandó.** A SeedSigner kép-entrópiája szándékosan nem perzisztálja a capture-öket, ez a privacy-feature. De emiatt a seed utólag nem ellenőrizhető, és ez a trade-off más self-custody eszközökre is érvényes (pl. ahol a seed a képernyőn megjelenítve egyszer látható, de a forrás-input nem reprodukálható). A saját rendszerünkben a wallet-setup SOP-nak tartalmaznia kell egy "ellenőrzési lánc" részt: (1) build ellenőrzés reprodukálható build-ről, (2) forrás-kód review, (3) capture SOP betartása, és a "capture SOP" az, ami a fenti #1 és #2 utasításokat jelenti. A capture-ek visszamenőleges ellenőrizhetetlensége miatt a "trust but verify" elv itt a **folyamat**-ellenőrzésre szűkül, nem az egyedi outcome-ra.

A gyakorlati implikáció a saját rendszerünkre: a SeedSigner 0.8.7 használóknak (és a következő release-t megelőzően mindenkinek) a **három szabályt** (lit scene, tap don't hold, watch the preview) szó szerint kell követniük, és a wallet-setup SOP-ba ezt canonical utasításként kell beépíteni. A wiki `bitcoin-wallet-security.md` topic-ban ez egy "SeedSigner 0.8.7 — image entropy használati szabályok" sub-szekcióként jelenik meg, a Coldcard exploit és a Jade 7-source entropy bejegyzésekkel egy szinten.