Google předává knihovnu pro ověřování věku v telefonu alianci pod Linux Foundation Europe

Kdo má doložit na webu věk, obvykle ukáže celý doklad: se jménem, datem narození i číslem průkazu. Longfellow je knihovna, která to má nahradit jedinou větou – „tomuhle člověku je přes osmnáct“ – a nic dalšího neprozradit. Google ji 2. září předal Post-Quantum Cryptography Alliance, sdružení pod Linux Foundation Europe. Firma to zdůvodňuje tím, že správa nezávislá na jednom dodavateli je předpoklad k tomu, aby knihovnu někdo přijal jako základ digitální identity.

Důkaz, ze kterého se nic nevyčte

Důkaz s nulovou znalostí je postup, kterým jedna strana přesvědčí druhou, že nějaké tvrzení platí, a nevydá u toho nic navíc. Ověřovatel z něj zjistí, že podmínka je splněna, ale ne, z čeho to plyne. U dokladů to znamená přesně tu situaci z úvodu: obchod se dozví, že zákazník je plnoletý, ne jeho datum narození.

Longfellow tohle umí nad formáty, které už existují a které vydavatelé dokladů používají dnes: nad ISO mdoc, tedy mobilním řidičským průkazem, nad tokeny JWT a nad ověřitelnými pověřeními podle W3C. Jméno má po mostě u kanceláře Googlu v Cambridgi.

Doklady ani telefony se kvůli tomu nemění

Zajímavější než samotná myšlenka je to, jak se dá nasadit. Popisuje ji práce Anonymous credentials from ECDSA, kterou napsali Matteo Frigo a abhi shelat z Googlu a která vyšla v časopise Communications in Cryptology, ročník 3, číslo 1.

Starší schémata anonymních pověření, třeba BBS+, stojí na nových kryptografických stavebních prvcích. Vydavatel dokladů by kvůli nim musel přestavět svou infrastrukturu – a protože doklad bývá vázaný na bezpečnostní prvek konkrétního přístroje, měnil by se i hardware v telefonech. Autoři to uvádějí jako hlavní důvod, proč se anonymní pověření dosud nikde nerozšířila.

Autoři místo toho postavili důkaz nad podpisem ECDSA, tedy nad tím, čím jsou doklady podepsané teď. Jediným předpokladem, na kterém stojí složitost jejich systému důkazů, je podle práce hašovací funkce SHA-256. Google o knihovně proto mluví jako o kvantově bezpečné.

Cesta k tomu vedla přes překážku, na které jiné systémy důkazů ztroskotaly. Standardizovaná křivka P-256 pracuje nad tělesem, ve kterém rychlá číselně teoretická transformace nefunguje dobře, takže obvyklé zrychlení odpadá. Autoři to obešli tím, že celý systém postavili kolem protokolu sumcheck a argumentu Ligero, napsali si vlastní Reed-Solomonovo kódování pro potřebná tělesa a navrhli obvody přímo pro ECDSA.

Pár desítek milisekund, jedno vlákno

Naměřené hodnoty vede projekt ve vlastní dokumentaci, byť naposledy z 17. října 2025. Na počítači s čipem Apple M4 tehdy trvalo sestavení důkazu o jednom podpisu 16,7 milisekundy a jeho ověření 10,4 milisekundy. Celé předložení dokladu ve formátu mdoc odhaduje odborná práce na několik set milisekund na mobilních přístrojích.

V dokumentaci k tomu stojí věta, která prozradí, pro co je knihovna psaná: veškerý kód běží v jednom vlákně, protože se nemá spotřebovávat baterie uživatele. Kryptografii se obvykle měří propustnost na serveru, tady se počítá s telefonem v kapse.

Co našly cizí kontroly

Knihovnou prošly tři nezávislé posudky a dva z nich našly skutečnou chybu.

Společnost Trail of Bits označila dva nálezy jako závažné. První z nich vysvětlují autoři jako vědomé rozhodnutí: knihovna sama neověřuje otisk každého obvodu při každém volání, protože se počítá s tím, že si to ověřovatel udělá jednou při startu a obvody si podrží v paměti. Druhý byla vada – jedna kontrola v obvodu brala délku řetězce z hodnoty, kterou zná jen dokazující, místo z té, kterou vidí i ověřovatel.

David Cook ze sdružení ISRG pak popsal chybu v obvodu pro mdoc. Indexy do dat v kódování CBOR se neporovnávaly s délkou podepsané části dokladu, takže bajty za správným blokem SHA-256 zůstávaly nesvázané – a kdo důkaz sestavoval, mohl si za ně dosadit vlastní hodnoty polí dokladu. Oprava vyšla 17. října 2025 ve verzi 0.8.4. Třetí skupinu složenou ze čtyř akademiků sestavila firma Ligero; ta odvodila dvě věty, které bezpečnostní záruky protokolu popisují přesněji než jeho vlastní specifikace.

Komu teď knihovna patří

Post-Quantum Cryptography Alliance vznikla pod Linux Foundation 6. února 2024 a Google patří mezi její zakládající členy. Nezávislost na dodavateli tedy má své hranice: knihovna se stěhuje ke sdružení, u jehož vzniku firma stála, a Google výslovně píše, že ji bude dál vyvíjet a podporovat.

Na svém webu vede aliance zatím tři projekty – CBOMkit, Open Quantum Safe a PQ Code Package – a Longfellow mezi nimi 5. září nebyl. Zdrojový kód dál leží v repozitáři google/longfellow-zk pod licencí Apache 2.0, poslední označené vydání nese číslo 0.9 z 31. března 2026 a poslední změny přibyly 3. září. Popis protokolu prochází také standardizací: koncept draft-google-cfrg-libzk je v IETF ve druhé revizi z 22. července 2026 a má 51 stran.

V praxi knihovna nejede od včerejška. Google ji do peněženky v telefonu začal zabudovávat v dubnu 2025 spolu se slibem, že technologii otevře i ostatním peněženkám a službám; jako partnera tehdy jmenoval seznamku Bumble. Věkové rozmezí uživatele umí aplikacím sdělit i samotný Obchod Play, jenže tam ten údaj přichází od Googlu, ne z dokladu v přístroji. Kolik států doklad do telefonu vůbec vydává, je zase jiná otázka – z osmi amerických států, které se k tomu v roce 2021 přihlásily, ho nakonec nabízejí čtyři.

Kdo knihovnu spravuje, není u téhle techniky formalita. Ověřovatel na druhé straně musí věřit tomu, že obvod, který důkaz počítá, dělá přesně to, co má – a obě nalezené chyby byly právě v obvodu, ne v matematice pod ním.

Zdroje

• Google: Our latest Linux Foundation Europe donation will build a more private digital world (2. září 2026)
• Matteo Frigo, abhi shelat: Anonymous credentials from ECDSA, Communications in Cryptology 3(1)
• Longfellow: Reviews – posudky Trail of Bits, ISRG a panelu sestaveného firmou Ligero
• Longfellow: Benchmarks
• Repozitář google/longfellow-zk
• IETF: Longfellow ZK (draft-google-cfrg-libzk)
• Linux Foundation: Announcing the Post-Quantum Cryptography Alliance (6. února 2024)
• PQCA: Projects