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:

A kamera mozog. Kézben tartva elkerülhetetlen valamekkora mozgás.
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.
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á:

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.
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.
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:

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.
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.

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ó:

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.
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.
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:

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.
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).
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:

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.
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.
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.