Vlákno názorů k článku
Google a Cloudflare chtějí postkvantové šifrování do certifikátů TLS
od Carpo - Podpora ML-DSA je v OpenSSL už dávno a...
-
Podpora ML-DSA je v OpenSSL už dávno a certifikáty ML-DSA vytvořit jdou. Takové certifikáty lze přidat i do serveru Apache nebo Nginx. CA s ML-DSA lze přidat i jako CA v systému (min. ve Windows). Hlavní problém v používání je ten, že s ML-DSA neumí prohlížeče (Firefox, Chrome...), takže v prvé řadě je potřeba dostat podporu ML-DSA do prohlížečů.
2. 3. 2026, 11:20 editováno autorem komentáře
-
FíkZlatý podporovatelAno, ale tyto certifikáty budou velké a budou zpomalovat "internet", takže by si stejně lidi podporu vypnuli. Nový typ certifikátů bude mít podobnou velikost jako starý a tento problém nenastane.
-
Ty certifikáty budou velké tak jak tak a podobnou velikost jako EC certifikáty určitě mít nebudou. To zmenšování řeší komunikaci mezi serverem a klientem, kde by nebylo potřeba předávat více podpisů a více veřejných klíčů a řeší se to proto, protože je ta ML-DSA komunikace znatelně větší.
Já to nepsal z hlediska globálního, spíš jako možnost, kdo by chtěl ML-DSA zkoušet, dnes to na webu vyzkoušet nemůže, protože ML-DSA certifikáty neumí prohlížeče. A jaksi nemá cenu řešit jiné problémy s ML-DSA, když ML-DSA ještě neumí ani prohlížeče, já vidím nepodporu v prohlížečích jako hlavní problém s použitím ML-DSA, minimálně aspoň na experimentování s ML-DSA.
Co se týče globálního nasazení tak krom zmenšování přenosu bych očekával řešit možnost vytváření hybridních certifikátů něco ve smyslu jak je teď už běžně používaný hybrid na výměnu klíčů X25519 + ML-KEM, jako aby to tam mělo prověřený klasický algoritmus a i PQC algoritmus, který ale není tak úplně prověřený.2. 3. 2026, 13:18 editováno autorem komentáře
-
FíkZlatý podporovatel
"Ty certifikáty budou velké tak jak tak a podobnou velikost jako EC certifikáty určitě mít nebudou."
Tak to jste právě nepochopil. Váš ML-DSA má obřích 15 kB, kdežto ten nový MTC jen 700 B, což už je skoro 512 B jako u EC. Přičemž bezpečnost MTC je stejná jako ML-DSA.
-
FíkZlatý podporovatel
No 5kB je hezký na vlastní certifikát. Ale ty skutečné certifikáty poskytují několik klíčů a podpisů v řetězci, který vede až k Root CA. Takže je několikanásobně delší. Asi 3x -:4x?
MTC možná zkouší s EC, ale cílem je tam mít nakinec ML-DSA, aby to bylo kvantově odolné.
-
Fík:
Dyť ty v tom máš úplný guláš a myslím, že ses nikdy nedíval co v certifikátu je. Umím udělat self-signed certifikát, certifikát podepsaný pomocí Root CA, klidně i certifikát, ten podepsaný zprostředkující CA a ten podepsaný Root CA. Pokud uděláš certifikát, který má nad sebou zprostředkující CA a Root CA, tak je prakticky stejně velký, klidně si to vyzkoušej, návod mám na to tu:
https://krakatoa.endora.site/openssl/https-na-web-serveru.php
Rozhodně není několikanásobně větší jak píšeš.
To několikanásobně větší možná v určitých případech platí pro handshake při komunikaci mezi klientem a serverem, obvykle Root CA je v systému nebo v prohlížeči a zprostředkující obvykle taky, já třeba ze serveru na klienta posílám jen serverový sertifikát, i když má nad sebou řetězec. Takže několikanásobně větší to může být, když se musí posílat ten řetězec.
Jasně, že cílem je tam mít ML-DSA, ale pokud tam bude ML-DSA, tak ta velikost rozhodně nebude jak mi tu píšeš 700 B.2. 3. 2026, 20:14 editováno autorem komentáře
-
Fullchain se posílá naprosto standardně, certifikáty zprostředkující autority totiž v systému nebývají a web browsery jen podporují AIA fetching (tedy automatické "dotáhnutí" intermediate z webu CA), aby fungovaly i s těmito "broken" servery. Posílat jen leaf určitě není správně, zkus si na takový server namířit třeba cURL (který AIA fetching neumí) nebo holé Python requests. Zhavarují ti na neznámém issuerovi, pokud nepošleš i intermediate (nebo si ho teda ručně nenahardcodíš do systému, ale to je extrémní antipattern a LE ti všude píše, že se to nemá dělat).
3. 3. 2026, 09:02 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatelFullchain se posílá naprosto standardně
Jen upřesním, že se standardně posílá celý řetězec s výjimkou kořenové autority. Kořenovou autoritu stejně musí protistrana znát, když jí důvěřuje, takže je zbytečné ten certifikát posílat.Zprostředkující autority ve spoustě systémů jsou. Z toho pak vznikají ty zábavné situace, kdy „líný“ server posílá jenom svůj certifikát, „líný“ klient má jenom kořenovou autoritu – a v jiném systému to funguje, protože tam na jedné nebo druhé straně ta vydávající autorita je.
-
lukastesar:
Ano, zprostředkující certifikát (nebo certifikáty) se posílají naprosto standardně.
Ano, posílat jen leaf není správné.
No a, že cURL zhavaruje? Přidá se zprostředkující certifikát do parametru.
Jo, nemá se to dělat, ale já mám server jedině na localhostu a tam to při zkoušení snad dělat smím :-)4. 3. 2026, 09:42 editováno autorem komentáře
-
FíkZlatý podporovatel
Špatně jsem se vyjádřil, certifikát na disku není větší, ale hlavička při handshake je, protože se prověřuje celý řetěz certifikátů až k Root CA a uživatel má pomalý "internety".
700 B píší na Arstechica, ale možná to mají blbě a je to jen ten MT. Nebo je ten jeden ML-DSA v Root CA a nemusí se teda tahat v hlavičce? Cloudflare už dřív zjistil, že handshake s hlavičkou větší než 10 kB je problém. No a ten ML-DSA normální certifikát s celým řetězem bude mít hlavičku 14-17 kB:
https://blog.cloudflare.com/sizing-up-post-quantum-signatures/
-
Fík:
Je to Merkle Tree Certificates, ne Merkel Tree Certificates :-)
Tu se píše:
https://blog.cloudflare.com/bootstrap-mtc/
že je potřeba:
1 signature, 1 public key, and 1 Merkle tree inclusion proof
V příkladu je tam uveden algoritmus ECDSA-P256 a je tam uvedeno i to, že to není PQC algoritmus a že by byl nahrazen ML-DSA-44 = bude to větší.
A asi je potřeba ujasnit terminologii:
1) certitikát = je jeden certifikát, např. serverový, zprostředkující, root
2) soubor s certifikátem (serverový) nebo certifikáty (serverový a zprostředkující), kterým se nastavuje server, např. v případě Apache se zadává pomocí SSLCertificateFile
3) handshake, tedy to, co se posílá mezi serverem a klientem při navazování spojení4. 3. 2026, 10:08 editováno autorem komentáře
-
FíkZlatý podporovatel
Tak to vypadá, že 700B handshake je pro ten MTC s ECDSA. Pak s tím ML-DSA mi vyjde asi 4kB, což je míň, než těch 10kB, kde se objevuje problém. Proto se to dělá.
-
FíkZlatý podporovatel
A jestli to chápu dobře, tak ty MTC jsou již experimentálně podporovány v Chrome. Teď spíš řeší, jak je bez problémů zařadit do Root CA.
-
OK, tak mi napiš jak vytvořit nebo stáhnout testovací MTC s ML-DSA (CA certifikát a veřejný klíč, serverový certifikát a veřejný klíč) a jak tu experimentální podporu MTC (ML-DSA) v Chrome zapnout, dokud nevyzkouším, neuvěřím, zatím nevěřím. A mezi Root CA v systému/prohlížeči si ten certifikát přidám sám.
Ještě poznámka, veřejný klíč ML-DSA-44 má 1312 B, ne 1320 B .-)2. 3. 2026, 16:34 editováno autorem komentáře
-
FíkZlatý podporovatel
Našel jsem na tom blogu Cloudflare toto: "... For their part, Chrome is implementing MTC support in their own TLS stack and will stand up infrastructure to disseminate landmarks to their users..."
-
Fík:
Takže se MTC řeší na experimentální úrovni a když bych si to teď chtěl vyzkoušet, tak to nemůžu... Navíc jsme pod článkem, kde se řeší ML-DSA, takže rovnou MTC s ML-DSA... Tak dej vědět až bude možnost si to vyzkoušet :-)
Já tu mám totiž nachystané na server obyčejné ML-DSA certifikáty už skoro rok a skoro rok čekám na podporu ML-DSA v prohlížečích a furt nic... je hezké, že někde experimentují...2. 3. 2026, 21:14 editováno autorem komentáře
ČLÁNKY DO MAILU