Autorství: vlastní review a podpůrné experimenty připravili AI agenti Codex v rámci projektu podle zadání správce. Nejde o nezávislý audit třetí strany. Původ a meze doloženého autorství přiložených textů popisuje provenance.
Datum: 14. 9. 2026. Posuzovaný commit: 9e95c989c0ea85cbe08dbcf63865e17cec71095f. Specifikace: IAM.md, hlavička m=670625, iam-core 1.0. Obsah IAM.md je shodný s tagem iam-core-1.0 na commitu fdbfe854b81943491511dfb6426185745fcd7fce; pozdější změny se týkají README a úvodní stránky.
Zkoumán je text protokolu, jeho algoritmus a sliby v README/indexu. Posuzovaný strom repozitáře obsahuje čtyři soubory a neposkytuje referenční implementaci ani konformní testovací sadu. Nejde tedy o audit nasazeného produktu. Specifikaci toto review nemění.
Doporučení: zachovat základní model, opravit jeho normativní rozpory a doplnit přesný konformní profil. Samotné obhájení současného textu nestačí; potřeba přidat nové grafové operace nebo měnit prostor identit z tohoto review nevyplývá. První audit zachytil několik skutečných mezer, ale také přecenil některé nálezy a obsahuje ověřitelné faktické chyby.
P1 zde znamená nutnost vyřešit problém před silným příslibem přenositelnosti či bezpečnosti implementací. P2 označuje provozní riziko, důležitou nejasnost nebo zavádějící bezpečnostní vysvětlení. P3 je redakční oprava. Záměrná vlastnost modelu nemusí být chyba, ani když má nepříjemné důsledky.
Je nutné odlišovat tři otázky:
IAM výslovně slibuje první vlastnost. Druhou přenechává runtime. Příklady, kde změna m nebo ukotvené množiny změní výsledek, samy o sobě determinismus nevyvracejí. Podobně chyba při zpracování neplatného vstupu není automaticky důkazem útoku proti hostiteli, který správně provádí admission.
Odkazy IAM:L níže uvádějí řádky pevně posuzované verze IAM.md. Zdrojový první audit je uložen beze změny v first-audit.md.
IAM:77–84, 110, 317–332 a 428–436 určují velikosti a použití Ed25519, ale ne úplná pravidla přijímání klíčů a hraničních podpisů. Potřebujeme přesný algoritmus dekódování, kanonicity a ověření, doplněný negativními vektory. RFC 8032 §5.1.7 připouští dvě ověřovací rovnice; pojmenování algoritmu tedy není úplný interoperabilní profil. RFC 8032
Současně je třeba opravit rozsah kritiky RFC v prvním auditu: RFC 8032 již vyžaduje S < L a pravidla kanonického dekódování bodů. Ne všechny odlišnosti knihoven uvedené v auditu jsou volností, kterou RFC dovoluje.
Návrh prvního auditu „ZIP-215, nebo striktní varianta“ je nedokončený bezpečnostní návrh: vedle shody ověřovačů musí IAM vymezit přípustné identitní klíče. Konkrétní reprodukce slabého klíče je v N1 níže. ZIP-215
IAM:92–110 neuvádí argument version ani hodnoty volitelného tajemství a přidružených dat. Doplnit explicitně profil Argon2id v1.3, version = 0x13, secret = empty, associated data = empty. RFC 9106 definuje verzi 0x13; text IAM by měl tento algoritmus výslovně normativně převzít, místo spoléhání na výchozí nastavení knihovny. RFC 9106 §3.1
Část auditu o chybějících syrových bajtech hesla je chybná: IAM:93 už říká inc_bytes = bytes of incantation (ASCII, exact) a 97 je předává do password. Rozdíl výstupu verzí 0x10/0x13 jsme samostatně neměřili; doložena je neúplnost argumentů ve specifikaci a moderní kandidátní vektor ověřený proti RFC.
V auditovaném stromu repozitáře nejsou. Je potřeba pokrýt KDF, reprezentaci klíče, pečeť, přesné podepisované bajty, id, podpis, celý bootstrap a také očekávané výsledky vyhodnocení grafu v hraničních situacích. Pouhé pozitivní kryptografické vektory nestačí.
Absence testů není sama důkazem matematické nedeterminističnosti. Je zásadní mezerou v možnosti ověřit konformitu. Zde vytvořené kontrolní skripty jsou podklady auditu, nikoli již schválená normativní příloha.
IAM:37–39 a 150–157 používá 32bitový otisk jako vizuální pomůcku a výslovně zakazuje používat jej jako identifikátor. Pro hledání otisku shodného s jedním pevným cílem je při rovnoměrném rozdělení očekávaná práce přibližně 2^32 kandidátů. Tvrzení „hodiny na jedné GPU“ audit nedokládá a tento audit je nepotvrzuje. Neprokázali jsme prolomení běžného Ed25519 klíče ani nutnost provádět při hledání pečeti IAM KDF.
Šest slov dává 48 bitů a zachová první čtyři slova při stejném výpočtu. To je kompatibilita prefixu; není to automaticky kompatibilita se specifikací, která definuje čtyři slova. Lze samostatně navrhnout delší zobrazovací formu. Nejdříve určit, zda pečeť slouží k rozpoznávání známé identity, nebo jako jediný prostředek autentizace nového klíče. Z neurčitého „short public key suffix“ také nelze odvodit konkrétní počet bezpečnostních bitů.
m — částečně potvrzeno, navržená oprava nestačíIAM:387 má horní časovou mez, 427 pouze nezápornost a 442–446 monotónnost uvnitř řetězce. Pořadí ovlivňuje okamžik kontroly členství. Specifikace to však výslovně vysvětluje v 729–737, včetně příkladu, kdy Bobův ACCEPT předběhne jeho vlastní přijetí a neprojde. Nový běžný člen s m=0 tedy nepředběhne libovolně všechny a současně nezíská platnou autoritu. Bootstrap členové jsou naproti tomu přítomní už z fáze 0.
Zavádějící zůstávají obecné formulace v 674 a 727, které zlehčují vliv pořadí na výsledek. Dolní mez času bootstrapu by zabránila některým záznamům před založením, ale ne zpětnému datování mezi přijetím a odvoláním. Příklad N6 ukazuje rozdíl konečného členství, i když všechny časy dolní mez splňují. Přidání meze mění dosud přijímané vstupy; nelze je vydávat za čistou redakční opravu.
IAM:450–454 a 620–635 skutečně mohou zablokovat LEAVE závislý na větvi forku. Rozštěpení od začátku řetězce může v daném ukotvení připravit bootstrap člena o všechny další strukturální akce. Není to ale absolutně trvalé napříč všemi ukotveními: 454 výslovně dovoluje zvolit množinu bez jedné větve. Dřívější platný prefix řetězce také není automaticky zpětně zneplatněn.
U běžného člena nemusí stačit jediný rodičův REVOKE: při více rodičích zůstávají jiné linie. Samotné zjištění hlavy před podpisem neřeší dva současné signatáře. Runtime potřebuje koordinaci zápisu pro každé (tree, context, actor) a pravidla publikace. Totožný kanonický obsah již má totožné id a admission jej deduplikuje (388); slučování různých záznamů se stejným zamýšleným účinkem by bylo novou sémantikou.
IAM:385–389 neudává limity velikosti, počtu ani doby držení. Strukturální validita ještě nevyžaduje členství, takže proud záznamů podepsaných útočníkovým vlastním klíčem může zatěžovat karanténu pro známý strom. U budoucího m je text dokonce silnější než MAY: říká, že záznamy jsou v karanténě drženy.
Doplnit požadavek na omezené prostředky a definovanou politiku odkládání/vyřazování. Konkrétní kvóty mohou zůstat runtime podle IAM:920. Nejde o změnu grafových pravidel ani důkaz, že každý konformní hostitel musí ukládat neomezeně.
KDF v IAM:92–110 neobsahuje komunitu. Pozorovatel záznamů různých stromů může spojit výskyty stejného klíče. To samo neodhaluje jméno člověka, nezpřístupňuje soukromé grafy a vzhledem k jednostrannému ACCEPT ani nedokazuje souhlas držitele s účastí.
Popsat hranici soukromí. Člověk může již dnes vytvořit více oddělených identit; protokol nedokazuje „jeden člověk, jeden klíč“. Per-tree odvození je možná jiná konstrukce identity, nikoli nutná oprava determinismu. IAM navíc nepředepisuje veřejné publikování každého grafu.
IAM:114 již výslovně vyžaduje novou verzi a nový prefix soli při změně parametrů. IAM:229–242 popisuje obnovu novou identitou a opětovným přijetím. Původní audit tedy přehání tvrzení, že cesta ven není uvedena.
Dává smysl doplnit životní cyklus a náklady hromadné migrace. Z toho ale neplyne, že nyní máme měnit p, paměť nebo prefix. I zdánlivá oprava p=1 na p=4 by změnila odvozené klíče.
IAM:466–479 zakazuje přidání hrany uzavírající aktuální cyklus. Věta auditu „Bob už nikdy nemůže přijmout Alici“ je příliš silná: po odebrání původní cesty to může být možné, pokud Bob zůstává platným členem jinou linií či axiomaticky.
Členství jako nejmenší pevný bod dosažitelnosti by umělo pracovat i s cykly bez samovolného členství izolované komponenty. To je jiná legitimní konstrukce. Nejde o důvod automaticky odstranit DAG pravidlo; jeho změna rozšíří množinu platných ACCEPTů a změní model linií. Volbu je vhodné vysvětlit podle zamýšleného významu ručení.
IAM:477, 522 a 681 trvalost v jednom vyhodnocení popisují jednoznačně. Jiná ukotvená množina nemusí mazat či přepisovat uložené záznamy; mění, které jsou autoritativní. Specifikace neslibuje, že ukotvení vždy jen narůstá.
Skutečná chyba textu je vedlejší věta v 521, podle níž může bývalého axiomatického člena znovu přijmout jiný platný člen. Bez výslovného omezení na jiné ukotvení odporuje state.departed. Návrat jako nová podepsaná událost by byl rozšířením protokolu, nikoli opravou dnešního algoritmu.
IAM:276–307 nepřenáší jméno ani nick a nepodepisuje jejich vazbu na klíč. V 307 ale výslovně umisťuje runtime metadata do vnějšího wrapperu. Runtime tedy může rozlišovat stejná zobrazovaná jména, jak požaduje 53; nemůže tvrdit, že jejich pravost zajišťuje samotný podpis IAM záznamu.
README:4–6, 17 a 30–34 a index:5 slibují širší model atributů a obecných claims, než poskytují tři operace jádra. Doporučení je srovnat úvod s aktuálním rozsahem. Zjištění nevyžaduje přidávat atributový typ záznamu.
p=1 — potvrzená faktická chyba, P2IAM:116 tvrdí, že p=4 vyžaduje čtyři 64MiB buffery. U Argon2 je parametr paměti celkový a rozděluje se mezi lanes. Profil s pamětí 65536 KiB tudíž neznamená 4 × 64 MiB. To je jistější a podstatnější oprava než spekulace prvního auditu o obráceném bezpečnostním vlivu paralelismu. RFC 9106 §3.1 a §3.2
Opravit vysvětlení, zachovat odvození. Bez přesného modelu útoku či měření netvrdit, že p=1 je obecně bezpečnější nebo přesně o určitou míru slabší.
prev a abort — potvrzeno s přesnějším mechanismemIAM:397 a 536 stanoví předpodmínku uzavřenosti. Záznam s chybějícím předchůdcem se ale podle 585–586 vůbec nestane ready: k odmítnutí v kroku 2 ani nedojde. Doslovný algoritmus tiše vrátí částečný stav.
Jde o vadný vstup, který porušuje požadavky na ukotvenou množinu, nikoli o protipříklad determinismu nad platnými vstupy. Přesto je vhodné přidat skutečný preflight s chybou a sjednotit kontrakt funkce. Oslabení uzavřenosti na SHOULD by změnilo význam kotvy a není rovnocennou malou opravou.
Zkratka není rozvedena ani doplněna odkazem, ale IAM:13 její roli popisuje jako runtime vrstvu nad IAM. Tvrzení, že není vůbec nikde vysvětlen, je příliš silné. Jedna úvodní věta a odkaz stačí.
Ve wordlistu nejsou obě slova ani jednoho z deseti uváděných párů. Je v něm například yew, ale ne you; isle, ale ne aisle; peak, ale ne peek. Totéž platí pro zbylých sedm dvojic. Volný přepis hlasu může vyprodukovat slovo mimo seznam, ale to není kolize dvou platných kódových slov.
tor je skutečně prefixem torch. Specifikace však definuje vizuální pečeť a nestanovuje formát bez oddělovačů. Tento audit neprovádí úplný fonetický průzkum všech přízvuků. První audit každopádně nedává doložený důvod měnit kanonický seznam.
LEAVE deaktivuje hrany; nemaže rozšířené kopie záznamů. IAM zároveň nepředepisuje veřejnou distribuci ani konkrétní retenci. Klíč a vztahy mohou být osobními údaji, pokud se vztahují k identifikované či identifikovatelné fyzické osobě. Výmaz podle čl. 17 má podmínky i výjimky. Provozovatel potřebuje vlastní posouzení účelu, publikace, identifikovatelnosti a retence; z textu jádra nelze vyslovit obecný verdikt o souladu. GDPR, čl. 4, čl. 17 a bod odůvodnění 26
V auditovaných souborech není citované marketingové tvrzení „není co uniknout“. Případnou externí jednostránku tento audit neposuzuje.
IAM:428 říká „valid … public keys“, ale nevymezuje platnost bodů. IAM:425 činí klíč osobního stromu implicitním kořenem. Samotné volání knihovní funkce Ed25519 verify tedy není dostatečná definice kontroly identity.
Reprodukce na Node v24.14.0, OpenSSL 3.5.5:
actor = tree = 01 00 … 00 (32 bajtů, neutrální bod)
R = 01 00 … 00 (32 bajtů)
S = 00 00 … 00 (32 bajtů)
Tento syntetický podpis knihovna přijala nad doménově odděleným osobním ACCEPT záznamem i nad jeho změněnou verzí. Skript pro něj nemá žádný soukromý seed. Kontrolní běžný klíč naproti tomu ověří svůj podpis a změněnou zprávu odmítne. Skript zároveň ověřuje standardní vektor RFC 8032.
Dopad: profil musí vyloučit nevhodné identitní klíče, ne pouze sjednotit výsledek ověřování podpisů. Veřejný klíč je třeba kontrolovat při bootstrapu, v actor/target a u implicitního osobního kořene podle jedněch pravidel. Neutrální bod a další případy podgrup musí mít explicitní výsledek. Pouhá interoperabilita podle ZIP-215 bezpečnost této vrstvy neřeší.
Toto není padělání podpisu některého běžného klíče vytvořeného IAM KDF a nedokazuje převzetí existující identity. Reprodukce neprohlašuje lokální kryptografickou knihovnu za konformního IAM hostitele. Podklad: crypto_checks.mjs, klíč weakPublicKey ve výsledném JSON; ZIP-215.
| Situace | Požadavek textu | Algoritmus / následek | Doporučení |
|---|---|---|---|
| Bootstrap v kotvě | IAM:954 říká, že anchored set MUST obsahovat bootstrap. | IAM:542–553 jej zakazuje a přikazuje ABORT. | Opravit souhrn podle již podrobně definovaného rozdělení known_trees / anchored_set. |
Chybějící prev |
IAM:397 a 536 vyžadují uzavřenost. | IAM:585–586 orphan nezařadí; funkce může vrátit částečný stav. | Výslovně validovat uzavřenost před průchodem. |
| Neznámý komunitní strom mimo vyhodnocovaný scope | IAM:399 požaduje ABORT při každém takovém záznamu v kotvě. | IAM:547–549 jej vyfiltruje; 569 kontroluje jen požadovaný strom. | Rozhodnout globální či scoped validaci a psát ji konzistentně. |
První řádek je přímý rozpor normativních vět. Další dva se týkají odmítání vadných vstupů. Reprodukce jsou missing_prev_never_reaches_step_2 a unrelated_unknown_tree_is_filtered v graph_counterexamples.json.
Neplatný sourozenec v detekci forku. IAM:438 vylučuje strukturálně vadný záznam z vyhodnocení. Scan v 628–631 ale čte všechny záznamy non_bootstrap. Platný LEAVE tak může označit za fork pouhá položka se stejným actor/prev a vadným podpisem. Po odfiltrování vadné položky LEAVE projde. Tento vadný vstup by korektní admission nepřijala; jde o rozpor obranného vyhodnocování, nikoli doložený útok bez klíče na správný hostitel.
Podepsaný, ale časově neplatný sourozenec. Admission nekontroluje monotónnost. Po platném r0(m=10) může mít řetězec LEAVE(m=12, prev=r0) a další podepsaný záznam m=9, prev=r0. Druhý je odmítnut v kroku 3, ale přesto zlomí první při scanu forku. To může být správně zamýšlený důkaz dvojího podpisu; musí to být napsáno. Nelze bez rozhodnutí požadovat, aby se všechny neaplikovatelné záznamy z detekce odstranily.
Dítě odmítnutého předchůdce. Řetězec r1(m=10) → r2(m=5) → r3(m=6) aplikuje r1, odmítne r2 a může aplikovat r3. Algoritmus uvolňuje děti před odmítnutím a porovnává m jen s bezprostředním prev. Dosud nikde nevyžaduje, aby byl předchůdce sémanticky aplikován. Vzniká aplikovaný podposloupnostní čas 10 → 6. Označit tento výsledek za dovolený, nebo změnit pravidla; samotný audit si nesmí chybějící požadavek domyslet.
Všechny tři případy mají samostatné reprodukce. Doporučení: přesně odlišit „ověřený podpis“, „strukturálně platný“, „platný článek řetězce“, „zpracovaný“ a „aplikovaný“ záznam; pro každou kategorii určit účast ve fork scanu a uvolňování dětí.
IAM:77 zavádí 32bajtový veřejný klíč s 64znakovým hex zápisem; IAM:152 potom píše pouze SHA-512(public_key). Přirozené čtení je hash syrových 32 bajtů, ale chybí explicitní dekódování či příklad.
Pro standardní veřejný klíč d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a:
| Vstup SHA-512 | Výsledná čtyřslovná pečeť |
|---|---|
| Syrových 32 bajtů | bison apex mint apex |
| ASCII 64znakového hex zápisu | horn finch rune spring |
Doplnit public_key_bytes = hex_decode(public_key_hex) a použít jej ve vzorci. Tento příklad prokazuje důsledek záměny reprezentací, ne existenci dvou již ověřených konformních implementací. Reprodukce: sealEncoding v kryptografických kontrolách.
IAM:274 správně přebírá JCS a I-JSON a zakazuje duplicitní názvy. Chybí však přímé rozhodnutí, zda se odmítají neznámá pole v record, jaký je rozsah m a zda vstupní bajty musejí již být kanonické, nebo se před ověřením kanonizuje přijatý objekt. Zahrnutí dodatečného pole do JCS změní id; jeho tiché odhození není bezpečný nevyřčený předpoklad.
JCS už určuje číselný model. Proto netvrdím, že libovolná serializace velkých Python integerů je konformní JCS. Kontrola ukazuje, že Node parsuje lexém 9007199254740993 jako 9007199254740992; omezení m na bezpečná nezáporná celá čísla a určení okamžiku validace odstraní praktické pasti. Varianty 1, 1.0, 1e0 a -0 mají mít testované očekávání. RFC 8785 §3.1–3.2, RFC 7493 §2.2
Stejně tak 88 znaků base64 nestačí k ověření kanonicity. Skript mění nepoužité pad bity a běžný dekodér vrátí stejných 64 bajtů. RFC požaduje nulové bity od kodéru, zatímco odmítnutí dekodérem připouští; IAM by měl jeho výsledek zafixovat. To je upřesnění přísného příjmu, nikoli nález změny podepsaného obsahu. RFC 4648 §3.5
Doporučená příloha: přesná povinná pole a jejich typy, politika neznámých polí a wrapperu, číselná doména, kanonizace vstupu, striktní hex/base64 a deduplikace podle id. Již definované JCS se nemá nahrazovat vlastním formátem.
Pro axiomatickou A:
m=1 A ACCEPT B
m=2 B ACCEPT C
m=3 A REVOKE B
m=5 A ACCEPT B
Po m=3 zůstává v state.edges aktivní B→C, pouze není dosažitelná z kořene. Po m=5 se bez nového přijetí vrátí B i C. To odpovídá hranově lokálnímu REVOKE v IAM:497–499, 646 a 708–713. Není to samo chyba; je to významná vlastnost, která má být v příkladech obnovy.
Pokud B místo m=2 podepíše svůj ACCEPT v m=4, je tehdy nečlenem a záznam neprojde. Po závěrečném re-ACCEPT se vrátí pouze B. Obě varianty splňují navrhovanou mez bootstrapu m=0. Zpětné datování tedy může ovlivnit konečný výsledek. Jde o rozdílné podepsané vstupy, nikoli porušení determinismu.
Důležitý implementační detail: kontrola cyklu musí zohlednit i nedosažitelné, ale stále aktivní hrany. Pokud po REVOKE B přijme A přímo C, pak C→B uzavře cyklus s latentní B→C. Kontrolovat jen aktuálně přítomné vrcholy by bylo chybné.
Reprodukce: reaccept_revives_descendants, timestamp_changes_eventual_membership a cycle_check_includes_unreachable_active_edges.
Genesis není implicitní člen, ale ACCEPT jej výslovně nezakazuje. IAM:483, 577 a 683 tvrdí, že genesis není/nikdy není uzlem. Žádná podmínka ACCEPT v 474–479 však nebrání A přijmout veřejný klíč genesis G. Algoritmus vytvoří A→G. Už to vyvrací absolutní formulaci.
Model dále dovolí G→C s prev="", pokud tajemství G přežilo. Zde je další nejasnost: 306 a 879 hovoří o předchozích záznamech a genesis řetězci včetně bootstrapu, který ale v anchored set být nesmí. Nejde tedy o jistý útok na každou konformní implementaci; chybí jednoznačný režim dalších genesis záznamů. Samotný uniklý genesis klíč stále neumí změnit existující bootstrap ani získat členství bez dalšího ACCEPT. Závěr prvního auditu o jeho vždy inertním úniku je přesto neúplný.
Axiomatický člen může mít běžnou příchozí hranu. Pro bootstrap členy A a B projde A→B a později REVOKE této hrany. B zůstane členem díky axiomatickému statusu. Vysvětlení v IAM:501, že taková hrana nemůže existovat a REVOKE proto nemůže být platný, je chybné. Správné je, že odebrání hrany neodebere axiom. Není potřeba zakazovat tuto hranu jen kvůli opravě zdůvodnění.
Také upravit větu o re-ACCEPT po LEAVE v IAM:521 podle bodu 11. Reprodukce: genesis_can_become_member a axiomatic_member_can_have_parent_edge.
| Místo | Co upřesnit a proč |
|---|---|
| IAM:237–238, obnova po kompromitaci | REVOKE jedním rodičem odebere jen jeho hranu. Nemusí zrušit všechny aktuálně platné cesty členství kompromitované identity. Obnova musí pracovat se všemi zbývajícími cestami / autoritativní kotvou. |
| IAM:246–250, více bootstrap kořenů | Více nezávislých kořenů může pomoci přežít odchod či ztrátu některých linií. Neomezuje však autoritu jednoho kompromitovaného kořene; není tu quorum a každý může sám ACCEPTovat. Současné zdůvodnění dostupnost a kompromitaci zaměňuje. |
| IAM:487 a 958, phantom members | Jednostranně přijatý existující cizí klíč může mít držitele schopného podepisovat a LEAVE. Neschopnost podepisovat nelze odvodit ze samotného přijetí bez souhlasu. Hrana dokládá tvrzení přijímajícího, ne souhlas přijímaného. |
| IAM:211–215, root versus device | V osobním grafu lze ověřit actor == tree: podpis přijatým device klíčem odlišným od kořenového klíče nemůže měnit majitelův osobní graf. Z veřejného community záznamu ale nelze dokázat způsob vytvoření klíče ani jeho použití na jiném zařízení. Přijatý klíč má autoritu podle členství; lokální zákaz použití device klíče je jiný druh požadavku. |
| IAM:223, účinek odvolání zařízení | Doručení a admission jsou nutné, ale samotné nezaručují účinek při vyhodnocení. REVOKE musí být zahrnut v použitém ukotvení a projít pravidly. Text by měl tento další krok výslovně uvést. |
| IAM:843, velikost ověření tree id | Konstantní velikost má výsledný hash. Hashování proměnlivě velkého seznamu vyžaduje čtení jeho obsahu; úplné ověření bootstrapu navíc kontroluje podpis každého záznamu. Není to konstantní výpočet v počtu členů. |
| IAM:863–873, zkrácený bootstrap checklist | Šest uvedených kroků nevyjmenovává všechny podmínky z 819–829, například neprázdnost a jedinečnost targetů. Odkázat výslovně na všechny Bootstrap constraints; nesugerovat, že zkrácený seznam je úplným přijímacím algoritmem. |
| IAM:63, incantation bez horní meze | Okrajová technická nepřesnost: Argon2 omezuje vstupní heslo na 2^32−1 bajtů. Sladit doslovný kontrakt; nejde o praktickou slabinu běžné passphrase. RFC 9106 §3.1 |
| index:14, README:30–34 | Veřejný příslib stejného výsledku má uvést stejné (known_trees, anchored_set, tree, context) a shodný profil jádra. Shodné pozorované nebo admitted záznamy samy nezaručují společný stav. |
\0 musí znamenat jeden bajt 00; JSON může obsahovat escapovaný NUL, nikoli neescapovaný kontrolní bajt v kanonickém JSON textu. Nejde tedy o chybějící doménovou separaci. Přesné bajty prefixů jsou v kontrolním JSON.tree == actor; více rodičů a lokální REVOKE mají vyhodnotitelnou sémantiku.| Kontrola | Ověřený výsledek |
|---|---|
| Wordlist | 256 slov, všechna unikátní, malé ASCII, délky 3–7, správné ordinální řazení, unikátní první čtyři znaky. |
| Prefix celého slova | Jediný zjištěný vztah je tor → torch. |
| Deset homofonních párů z prvního auditu | Ani jeden pár není v seznamu zastoupen oběma slovy. |
Epocha 28928160 minut Unixu |
2025-01-01 00:00 UTC. |
Hlavička m=670625 |
2026-04-11 17:05 UTC. |
| Náhodná 32bitová kolize při 77 000 identitách | Pravděpodobnost přibližně 0,498535; údaj „approximately 77000“ ve specifikaci je v pořádku. |
| První celé n s pravděpodobností kolize > 50 % | 77 164, za předpokladu nezávislých rovnoměrných otisků. |
Přesný konečný součin dává při n=77163 pravděpodobnost 0.499999890517348355… a při 77164 hodnotu 0.500008873474793442…. První audit uvádí „přesně 77162“, což není přesný práh. Asymptotický vzorec sqrt(2 · 2^32 · ln 2) dává 77162.743235…. Tato malá chyba auditu nijak nezvyšuje bezpečnostní sílu 32bitové pečeti.
Opravit rozpor bootstrap/anchor, nepravdivé paměťové zdůvodnění p, formulace o axiomatických hranách, trvalém LEAVE, phantom členství, obnově po kompromitaci, více kořenech a záběru README. Sjednotit chybové předpodmínky algoritmu. U posledního bodu výslovně popsat, že se mění zpracování vadných vstupů.
Vybrat kryptografický profil včetně přípustnosti klíčů, explicitní Argon2id parametry, bajtový vstup pečeti, vstupní schéma a přesnou sémantiku vadných článků řetězce. Vytvořit pozitivní i negativní vektory včetně bootstrapu a výsledného stavu. Kandidátní výsledky ověřit nejméně dvěma nezávislými implementacemi, ne dvěma obaly téže knihovny.
Podstatná sada stavových příkladů: více rodičů, REVOKE jedné hrany, obnova potomků, LEAVE kořene i běžného člena, zákaz návratu ve stejné kotvě, fork a zachování prefixu, stejná minuta mezi aktéry, latentní cyklus, neznámý strom, chybějící prev a bootstrap omylem v kotvě.
Jeden vzorový profil ukotvení by projektu pomohl: kdo kotvu vydává, jak se ověřuje její úplnost, jak se přijímá nová revize, jak se komunikuje výběr větve při forku a jak se zobrazuje historie. Součástí má být koordinace podepisování a omezení karantény. Tento profil řeší provozní shodu a obnovu; neopravuje údajnou chybu čisté funkce jen tím, že přidává politiku.
| Návrh | Kompatibilita / rozhodnutí |
|---|---|
| Redakční errata | Mohou být dokumentovým patch vydáním, pokud nemění rozhodnutí o dříve jednoznačně platných záznamech. |
| Explicitní Ed25519/klíčový profil a rozhodnutí v nejasných případech | Mohou odmítnout záznamy dříve přijaté některými implementacemi. Nutná kompatibilitní tabulka; samotné označení 1.0.1 shodu nezajistí. |
| Změna Argon2 parametrů/prefixu | Nový prostor identit podle IAM:114. Nyní pro ni audit nedává nutný důvod. |
| Šestislovná pečeť | Kompatibilita čtyřslovného prefixu je možná. Náhrada kanonické pečeti mění její formát; případnou rozšířenou zobrazovací formu specifikovat zvlášť. |
Dolní mez m |
Mění přípustné záznamy a neřeší obecně zpětné datování. Rozhodnout podle modelu času, ne jako kosmetickou opravu. |
| Návrat po LEAVE, povolení cyklů, odstranění zakladatele, per-tree identita | Změny stavové či identitní sémantiky. Nevyplývá z auditu, že jsou všechny potřebné. |
Nedoporučuji předem slíbit číslo 1.0.1. Nejprve určit konkrétní rozdíl pravidel a množin přijímaných záznamů. Repozitář nedokládá, které profily a identity již používají případné externí implementace. Nové číslo bez migračního a konformního vymezení tento problém neřeší.
Z kořene repozitáře:
python reviews/2026-09-14/text_checks.py
python reviews/2026-09-14/graph_counterexamples.py
node reviews/2026-09-14/crypto_checks.mjs
| Soubor | Co ověřuje |
|---|---|
text_checks.py / .json |
Wordlist, uvedené dvojice, epocha, hlavička, pravděpodobnost kolize; hraniční součin i pomocí 50místného Decimal. |
graph_counterexamples.py / .json |
Symbolický model relevantních kroků algoritmu, 12 případů s úspěšnými asercemi. Používá symbolické klíče/id; neověřuje podpisy, JCS, bootstrap ani skutečnou admission pipeline. Srovnávací přepínače ukazují explicitní alternativy, netvrdí, že jsou již normativní. |
crypto_checks.mjs / .json |
Skutečné lokální Ed25519 ověřování, standardní kontrolní vektor, syntetický slabý klíč, reprezentace pečeti, base64 a čísla. Pokud prostředí podporuje Argon2, ověří RFC 9106 §5.3 a vytvoří kandidátní IAM KDF vektor. |
Kryptografický pomocný kanonizátor je omezený na ASCII a bezpečná celá čísla použitých fixture; není to obecná implementace JCS. Všechny zveřejněné seedy a incantation v kontrolách jsou veřejná testovací data. Není provedeno srovnání více produkčních IAM implementací, benchmark GPU, úplný kryptografický důkaz, penetrační test provozu ani právní posudek. Grafový model nezaměňovat za hotový konformní engine.
Audit poskytuje dostatečné podklady k rozhodnutí o konkrétních opravách. Zachovat malé jádro je obhajitelné; ponechat rozporné normativní věty a implicitní kryptografický profil obhajitelné není.