Šifrování a podpisy RSA vysvětleny od začátku

Jednou větou: RSA je kryptografie s veřejným klíčem — kdokoli vám může zašifrovat zprávu veřejným klíčem nebo ověřit vaše podpisy, ale dešifrovat nebo podepsat může jen soukromý klíč — a její bezpečnost spočívá na tom, že rozklad čísla o 2048 bitech na dvě prvočísla je nad možnosti jakéhokoli existujícího počítače.

Co RSA ve skutečnosti počítá

Dvě prvočísla a zadní vrátka. Klíč RSA začíná dvěma velkými náhodnými prvočísly p a q; jejich součin n (modul, odtud „klíč 2048bitový“) se zveřejní ve veřejném klíči spolu s exponentem e (téměř vždy 65537). Soukromý klíč je dvojice d, modulární inverze k e − vypočtená z p a q — plus zkratky odvozené z prvočísel, které operace se soukromým klíčem zrychlí 4×.

Šifrování a podepisování je tatáž exponenciace. Zašifrování bloku zprávy m znamená výpočet m^e mod n; dešifrování je c^d mod n. Podepsání předformátovaného bloku soukromým exponentem a ověření veřejným je tatáž operace v opačném směru. Vše ostatní na této stránce — OAEP, PSS, PKCS#1 — je o bezpečném formátování toho bloku, aby se nikdy nevystavila nechráněná exponenciace.

Proč je to pomalé. Jedna operace RSA na klíči 2048bitovém stojí řádově milionkrát více procesorového času než zašifrování jednoho bloku AES. Proto TLS používá RSA (nebo ECC) jen k dohodě na náhodném klíči AES a poté přepne. Stejné pravidlo platí pro cokoli, co vytvoříte: RSA pro klíč, AES pro data.

Velikost klíče. Délka modulu je ovladač bezpečnosti: 1024bitový je podle politiky prolomený (faktorizace je na dosah státům), 2048bitový ≈ 112bitová symetrická síla, 3072bitový ≈ 128bitová, 15360bitový by odpovídal 256bitovému symetrickému klíči. Poznámka k postkvantovému světu: Shorův algoritmus úplně prolomí RSA na velkém kvantovém počítači — další důvod udržovat životnost klíčů konečnou.

OAEP: jediná výplň šifrování, kterou byste měli používat

Problém syrového RSA. Učebnicové RSA (m^e mod n na syrové zprávě) je deterministické a plastické: stejné zprávy se zašifrují stejně, útočník může vynásobit šifrotext zašifrovanou dvojkou, aby se otevřený text zdvojnásobil, a krátké zprávy padají metodou meet-in-the-middle. Nikdy se nesmí používat přímo.

Co dělá OAEP. OAEP (PKCS#1 v2, RFC 8017) před exponenciací mísí zprávu s náhodným semenem přes Feistelovu síť založenou na hashi. Výsledek: šifrování je randomizované (stejný otevřený text dá pokaždé jiný šifrotext — spusťte vzorek OAEP dvakrát a porovnejte), při dešifrování se pozná manipulace a zpráva se musí vejít do modulu s místem na hash — limit k−2·hashLen−2 uvedený výše v tabulce.

Popisek. Volitelný veřejný řetězec svázaný do výplně. Obě strany musí zadat totožný popisek, jinak dešifrování selže — jako AAD u AES-GCM vám umožňuje svázat šifrotext s kontextem (název souboru, identifikátor algoritmu). Prázdný je normální.

Výplň PKCS#1 v1.5 pro šifrování je záměrně vynechána. Výplň z roku 1993 nemá integritu a prozrazuje informace skrze chování chyb při dešifrování (útok Bleichenbacherova z roku 1998 promění orákulum výplně v úplné dešifrování za několik milionů vytvořených šifrotextů; stále láme skutečné systémy jako ROBOT z roku 2017). WebCrypto ji odmítá implementovat; tak i tato stránka.

PSS vs podpisy PKCS#1 v1.5

Podepsání = hash, pak výplň, pak exponenciace. Obě schémata zahešují zprávu (zde SHA-256/384/512), formátují otisk do bloku a aplikují soukromý exponent. Ověření znovu naformátuje blok veřejným klíčem a porovná jej. Rozdíl je ve formátování:

Schéma	Obsah bloku	Vlastnosti
RSASSA-PKCS1-v1_5	otisk + hlavička digest-info, deterministický	Každý podpis téže zprávy je bajt po bajtu totožný (zkontrolujte samotest: jeho vektor v1.5 je pevný). Univerzální podpora zpětné kompatibility: certifikáty X.509, JWT RS*, TLS před 1.3. Žádný známý padělek, pokud je ověřování správně implementováno.
RSA-PSS	otisk + náhodná sůl o délce hashe, maskování MGF1	Randomizovaný — každý podpis se liší. Dokazatelně bezpečný v modelu náhodného orákula; vyžadován v certifikátech TLS 1.3 a novějších protokolech. Ověřovatel musí znát délku soli (tato stránka používá délku hashe, běžný výchozí).

Kterou zvolit. Nové návrhy: PSS. Interoperabilita se stávajícími certifikáty, JWT (RS256) nebo staršími protějšky: v1.5. Obě jsou bezpečné jako schémata podpisů — příběh katastrofy v1.5 se týká *šifrovací* výplně, což je jiná konstrukce navzdory podobnému názvu.

PKCS#1 vs PKCS#8 vs SPKI: proč má týž klíč čtyři PEMy

PEM je jen base64 obalený DER. Soubor PEM je štítek plus base64 struktury DER (binární ASN.1). Štítek říká, o jakou strukturu jde — a v tom spočívá celý rozdíl mezi čtyřmi formáty, které tato stránka generuje:

Štítek PEM	struktura DER	Obsahuje
-----BEGIN PUBLIC KEY-----	SubjectPublicKeyInfo (SPKI)	OID algoritmu + veřejný klíč (n, e). Výchozí „veřejný klíč“ všude.
-----BEGIN RSA PUBLIC KEY-----	PKCS#1 RSAPublicKey	Holý (n, e). Starý OpenSSL a některé vestavěné zásobníky.
-----BEGIN PRIVATE KEY-----	PKCS#8 PrivateKeyInfo	OID algoritmu + soukromý klíč. Kontejner nezávislý na algoritmu, moderní výchozí volba.
-----BEGIN RSA PRIVATE KEY-----	PKCS#1 RSAPrivateKey	n, e, d, p, q, …. Klasický výstup OpenSSL `genrsa`.

Týž klíč, jiné obaly. Všechny čtyři boxy výše po generování obsahují týž pár klíčů — veřejný SPKI a veřejný PKCS#1 obsahují totožné n, e; soukromý PKCS#8 a soukromý PKCS#1 obsahují totožné soukromé hodnoty. Tato stránka mezi nimi převádí bez ztrát v prohlížeči (její samotest převody zpětně ověřuje). Záměna formátů je nejčastější příčinou chyby „neplatný klíč“ při vkládání klíčů mezi nástroji.

Šifrované PEMy (-----BEGIN ENCRYPTED PRIVATE KEY-----) jsou PKCS#8 s vrstvou šifrování založeného na heslu. Tato stránka je nepřijímá — nejprve je dešifrujte offline (openssl pkcs8 -in enc.pem -out plain.pem).

Časté chyby

Šifrování velkých objemů dat pomocí RSA. Kromě tvrdého limitu velikosti OAEP je to absurdně pomalé. Vzor je: vygenerujte náhodný klíč AES, zašifrujte klíč AES pomocí RSA-OAEP, data zašifrujte pomocí AES-GCM a odešlete obě části.
Posílání soukromého klíče, protože „je to jen test“. Ukázkové klíče vložené do vektorů této stránky jsou zveřejněny záměrně — mohou podepisovat jen zkušební data. Vaše klíče takové nejsou.
Ověřování soukromým klíčem. Obvykle to matematicky „funguje“ a některé nástroje to dovolují, ale distribuce soukromého klíče ověřovatelům maří celý model. Ověřujte veřejným klíčem (tato stránka to vynucuje).
Porovnávání podpisů bajt po bajtu při kontrole kódu. PSS (a OAEP) jsou randomizované: dva správné běhy dají různé výstupy. Porovnávejte ověřením, ne rovností — jen podpisy v1.5 jsou deterministické.
Klíče 1024bitové „protože jsou rychlejší“. Jsou také na dosah dobře financované faktorizaci. Argument o rychlosti zanikl s hybridním šifrováním: RSA běží jednou na relaci, ne na bajt.
Pevná délka soli pro PSS jinou než délka hashe. Ověřovatel musí souhlasit; délka hashe (volba této stránky a OpenSSL -sigopt rsa_pss_saltlen:32) je interoperabilní výchozí hodnota.

Časté dotazy

Proč mi dešifrování selhalo s „špatný klíč, špatný hash nebo poškozený šifrotext“? Dešifrování OAEP selže, když: nejde o odpovídající soukromý klíč, hash se liší od strany šifrování, popisek se liší, nebo se změnil bajt šifrotextu. Chyba je záměrně stejná pro všechny případy — prozradit, která kontrola selhala, je samo o sobě únikem orákula výplně.

Mohu získat veřejný klíč ze soukromého? Ano — soukromé formáty obsahují také n a e. Tato stránka je po generování zobrazí obě; OpenSSL to dělá příkazem openssl pkey -in priv.pem -pubout.

Proč 65537 jako exponent? Je prvočíslo, má jen dva bity jedna (rychlá exponenciace) a je dost velký, aby se vyhnul útokům s nízkým exponentem, které zasáhnou e=3. Je standardní volbou od 90. let; „podivný“ exponent obvykle znamená slabý nebo nestandardní klíč.

Je RSA mrtvé kvůli kvantovým počítačům? Zatím ne — neexistuje stroj, který by dokázal spustit Shorův algoritmus na modulu 2048bitovém. Data, která musí zůstat tajná až do 30. let a dále, se ale již migrují; hybridní schémata PQC jsou inženýrskou odpovědí.

A co openssl rsautl? Je zastaralým předchůdcem pkeyutl. Jako výchozí používá výplň šifrování v1.5 — další důvod, proč byl vyřazen.

Šifrování a dešifrování RSA