Život v .NETu

Jo, jeste doplneni : ja to neprezentoval jako zasadni problem, spise jako neduslednost, ktera pro jistotu neni ani zdokumentovana.

A tu neuplnou dokumentaci (ci neduslednou) MS vycitam stale.

Preci jenom RFC nestuduje kazdy....

Ten problem tam je. Pokud nebude uvazovat s ohledem na digitalni podpis ale na nove metody zpusobu ochrany digitalnich dat, tak tento koncept se zacina objevovat. Digitalni podpis, jak uz jsem psal, je vam v tomto ohledu na nic. PKCS#1 je standardni dokument kolem sifrovani, ale vubec to nic nema spolecneho s pristupnostim k implementaci. Jine frameworky toto umoznuji a jak jsem napsal, pouziti privatniho klice muze mit opodstatneni ve chvili, kdy napr. potrebujeme pouzit jak podpis tak zaroven sifrovat i obsah. Problem jen jen, ze k tomuto jiz nepouzijete RSA na sifrovani onech binarnich dat. Koncept je mnohem slozitejsi a neni pro jeden blog a prispevek do nej, napr. DRM tohle resi urcitou obfuskaci klicu v pameti + kombinace certikatu a digitalniho podpisu (opet je to zavisle na implementaci daneho vyrobce jako MS nebo Applet atd). Ale rozhodne model pouziti privatniho klice na sifrovani se prave v objevuje v pracich nekterych kryptologu a to prave u DRM modelu (ale zduraznuji, neni to jen privatni klic!!!).

Honzo, nesouhlasím tak úplně s tím, že omezovat funkčnost je v tomto případě špatně. Ano některí jiné frameworky toto umožňují (i ten, který jsem psal já), ale v případě CryptoAPI, které slouží jakožto šifrovací jádro operačního systému, k tomu jsou dle mého názoru dobré důvody.

Protože jakou funkčnost to vlastně omezujeme? Budoucí, experimentální nebo málo rozšířené proprietární způsoby formátování dat pro RSA jistě smysl explicitně přidávat nemá - ani to nejde, když je ještě neznáme. Pokud bychom tedy chtěli zpřístupnit opravdu všechny budoucí možnosti, je jen jediný způsob, jak to provést - umožnit přímo provádění m^e mod n a c^d mod n a starost o nějaký rozumný padding přesunout na aplikaci. Toto by se vám opravdu zamlouvalo? U veřejného klíče to nevadí (pokud je skutečně veřejný), ale u soukromého ano, protože pokud umožníme c^d mod n:

1. Dešifrováním zprávy "1" získáme soukromý klíč. To jde přímo proti filozofii CryptoAPI, která je založena mimo jiné na tom, že funguje jako černá skřínka schopná na vyžádání šifrovat/dešifrovat i bez možnosti získat soukromý klíč, pokud je označen jakožto neexportovatelný. CryptoAPI rozlišuje operace "podpis", "dešifrování" a "export soukromého klíče", které mohou podléhat jiné urovni zabezpečení (a vyžadovat souhlas uživatele), a pokud umožníme c^d mod n, už nejsme schopni tyto operace od sebe rozlišit. Pak stačí spustit něakou cizí aplikaci, která se tváří, že podpisuje data, ačkoliv ve skutečnosti nám krade soukromý klíč.

2. Mnozí naivní programátoři by si jistě vytvořili vlastní způsoby paddingu dat, které by nebyly vůbec bezpečné. Pokud by pak k šifrování používali klíče ze stávajících certifikátů, otevřela by se tím zadní vrátka i do slušných aplikací. Vždyť dokonce i původní standard PKCS #1 používal algoritmus, který nebyl příliš bezpečný a brzy byl nahrazen novým.

Pokud nějaké jiné použití RSA bude v budoucnu zcela zásadní, jistě bude jeho podpora do CryptoAPI i do .NETu přidána. A čekal bych, že když už si někdo implementuje vlastní DRM, tak ho nemožnost použít RSA z CryptoAPI nepálí - funkci ModPow implementovánu jistě má, protože ani tu CryptoAPI přímo nenabízí, a RSA vlastně o ničem jiném než o několika voláních ModPow není (když odhlédnu od generování klíčů, ale to CryptoApi zas umí).