Datové schránky přešly na SHA-2

Včerejší den, tedy 23. květen 2010, byl dalším milníkem v historii českého e-governmentu: k tomuto dni celý informační systém datových schránek (ISDS) přešel na používání nové hashovací funkce SHA-2. Což obnáší řadu změn, z nichž asi „nejviditelnější“ je výměna (serverového) certifikátu, používaného pro autentizaci serveru ISDS a zabezpečení spojení s tímto serverem, a certifikátu používaného pro podepisování jednotlivých datových zpráv, a také doručenek. Přesněji: jde o tzv. systémový certifikát, a s jeho pomocí se nevytváří elektronický podpis ale elektronická značka, jako strojová obdoba elektronického podpisu, který by jinak musel vytvářet člověk. Důležité ale je, že všechny tyto změny se poměrně významně týkají i uživatelů datových schránek.

Hromadně rozesílaná systémová datová zpráva

Uživatelé datových schránek byli o hlavních změnách informováni přímo skrze samotné datové schránky, formou datové zprávy obsahující jeden informační dokument ve formátu PDF („Přechod na SHA-2, informace pro uživatele“, v HTML podobě zde na datoveschranky­.info), a jeden soubor s příponou CER, obsahující nový kořenový certifikát té certifikační autority, jejíchž služeb systém datových schránek využívá (tj. CA PostSignum).

Tato zpráva byla zřejmě rozeslána do všech datových schránek, kterých je podle aktuálních odhadů cca 400 000. Při ceně 15 Kč (bez DPH) za každou zprávu by to představovalo cca 6 milionů Kč, což není nijak málo. Prý to ale resort vnitra, který je autorem této zprávy, nestálo nic – protože nešlo o běžnou  (zpoplatněnou) datovou zprávu, ale o nezpoplatněnou  „hromadnou systémovou datovou zprávu, iniciovanou správcem“ (jak je to nově definováno v jedné z příloh k Provoznímu řádu ISVS). Proto také tato zpráva dorazila ze schránky s ID „aaaaaaa“, a jejím odesilatelem byl sám „Informační systém datových schránek, ČR“.

Mimochodem, obdobnou systémovou datovou zprávu (nikoli ale již hromadnou, nýbrž cílenou) můžete dostat i v některých specifických situacích, jako například tehdy, když systém smaže vámi odeslanou datovou zprávu kvůli nalezení viru. Úplný výčet důvodů najdete v nejnovější a výrazně předělané verzi dokumentu „Webové služby rozhraní ISDS pro manipulaci s datovými zprávami“, který je přílohou nového Provozního řádu.

Pro mnoho uživatelů datových schránek přitom byla tato hromadně rozesílaná systémová datová zpráva tou úplně první, kterou do svých schránek dostali. Soudím tak podle řady ohlasů, zejména na Internetu. Jeden z nich přitom poukazoval na zajímavou skutečnost, že  skrze schránku prošel i certifikát ve formátu, který není obsažen ve výčtu povolených formátů (tedy alespoň v tom, který obsahuje stále platná vyhláška č. 194/2009 Sb.). Pravdou je, že tu se dosud nikdo nenamáhal aktualizovat, a tak se výčet přípustných formátů prozatím rozšiřuje pouze formou „legislativního výkladu“: když zákon něco požaduje či alespoň nevylučuje (zde konkrétně jde o externí el. podpisy), pak  z toho lze odvodit, že je možné to či ono (zde: používání formátů pro externí podpis) – aniž by byla provedena novela příslušných předpisů. No, v řadě případů to může být jediné řešení, schůdné v reálném čase. Ale stejně mne z této praktiky mrazí v zádech.

Instalace nového kořenového certifikátu

Na druhou stranu rozeslání nového kořenového certifikátu CA PostSignum skrze datové schránky bylo na místě  a lze jej ocenit – je to způsob distribuce tohoto certifikátu, který je stejně důvěryhodný, jako datové schránky jako takové.

Škoda jen, že celkový dojem kazí hned první věty přiloženého informačního materiálu (a celá tisková zpráva MV ČR), který prezentuje SHA-2 jako šifrovací funkci (a nikoli jako hashovací funkci, o kterou jde ve skutečnosti). To je „poněkud nepřesné“ (viz dále), a nevytváří to dobrý image pro toho, kdo má dbát na bezpečnost tak důležitého systému, jakým jsou datové schránky. Je to určité faux-pas, asi jako kdyby ministerstvo dopravy informovalo o přechodu z olovnatého na bezolovnatý benzín, a v souvislosti s tím hovořilo o diesel motorech.

Podstatnější je ale jiná věc: i onen informační dokument, který byl rozesílán skrze datové schránky (a stejně tak tisková zpráva MV ČR) informuje o tom, že alespoň uživatelé novějších verzí MS Windows si nemusí nový certifikát instalovat sami, ale že jim bude instalován sám, v rámci automatických updatů:

Naprostá většina uživatelů datových schránek připravovanou změnu bezprostředně nezaznamená. Společnost Microsoft by totiž v průběhu května 2010 měla uvolnit balíček Windows Update, který v sobě bude obsahovat SHA-2 kořenový certifikát certifikační autority PostSignum.

Uživatelé využívající moderní operační systémy Windows XP 2003, Windows Server 2003, Windows Vista, Windows 7 nebo Windows Server 2008, kteří mají zapnuty automatické aktualizace, si tak do svého počítače nebudou muset nic instalovat.

Obávám se ale, že toto se (zatím) nestihlo. Dotazem přímo u českého Microsoftu (na to, zda již došlo k distribuci ….) jsem získal pouze nic neříkající odpověď:

Postsignum bude zařazen mezi root certifikáty v květnu, tzn. bude automaticky distribuován počítačům s Vistou a W7.

Mohu-li tedy soudit alespoň podle svého počítače (W7 a se zapnutými aktualizacemi), tak k automatické distribuci certifikátů CA PostSignum zatím nedošlo, a je tedy třeba je instalovat ručně.

Přesněji: je nutné instalovat jeden kořenový certifikát – a to právě ten, který byl rozeslán skrze datové schránky, v příloze výše popisované systémové datové zprávy. Je to certifikát nové certifikační autority QCA 2, kterou CA PostSignum vytvořila k tomu, aby (skrze ni) vydávala nové certifikáty již na bázi hashovací funkce SHA-2. Původně měla být tato nová CA spuštěna již v lednu, ale to se nepodařilo, a skutečně spuštěna byla až počátkem března. Možná že  právě proto se nové kořenové certifikáty této CA ještě nestihly dostat do distribuce Microsoftu, slibované „již na květen“. V každém případě PostSignum po určitou dobu vydávala nové certifikáty, již na bázi SHA2, ale ještě „pod“ původní kvalifikovanou certifikační autoritou. To znamená, že jejich certifikační cesta končí (v kořeni) ještě původním kořenovým certifikátem CA PostSignum.

Příkladem může být můj vlastní kvalifikovaný certifikát, který vidíte na následujícím obrázku: byl vydán 15.1.2010 a ještě „pod“ původní QCA PostSignum.

Nový kořenový certifikát PostSignum Root  QCA2 byl vydán až 19.1.2010 (ano, „ten“, který byl distribuován skrze datové schránky), viz následující obrázek.

Co se změnilo a proč je třeba instalovat nový kořenový certifikát?

Uživatelé datových schránek nejspíše již mají na svých počítačích a ve svých browserech nainstalovaný původní kořenový certifikát CA PostSignum, a díky tomu jejich aplikace hodnotí  dosud používané certifikáty od PostSigna jako důvěryhodné. Jenže právě od včerejšího dne (23.5.2010) přešel informační systém datových schránek (ISDS) na používání nových certifikátů, vydaných již na bázi SHA-2.

Konkrétně jde i o (serverový, resp. systémový) certifikát, kterým se samotný ISDS autentizuje (ověřuje svou identitu), a který současně slouží pro zabezpečení spojení s ním (HTTPS). Tento certifikát musel být vyměněn již jen proto, že tomu dosavadnímu brzy (19.6.2010) končila jeho řádná platnost. Viz následující dva obrázky, na kterých vidíte původní serverový certifikát (vlevo) a certifikát nový (vpravo).

A jelikož jde o nový certifikát, vydaný již skrze novou certifikační autoritu (QCA2), je třeba používaným browserům dodat informaci o tom, že i jemu mohou důvěřovat. A jelikož se tato informace nestihla předat (alespoň na platformě MS Windows) automaticky, je nutné ji předat ručně – právě nainstalováním kořenového certifikátu nové PostSignum Root QCA2. Jinak znovu dojde k tomu, k čemu docházelo při spuštění datových schránek: že browsery uživatelům hlásily, že nemají podle čeho posoudit důvěryhodnost certifikátu, kterým se prezentují stránky ISDS (a před jejich návštěvou tak varovaly).

Zdůrazněme si hned, že tuto informaci je třeba dodat tomu browseru, který používáte, resp. všem browserům, které používáte. A každému se může dodávat jinak. Například Firefox používá své vlastní úložiště důvěryhodných certifikátů, a nikoli systémové úložiště, které naopak využívá Internet Explorer. Takže i kdyby proběhla automatická distribuce nového kořenového certifikátu skrze Update mechanismy v prostředí Windows (viz výše), stejně by se týkala jen systémového úložiště certifikátů, a tudíž jen Internet Exploreru a nikoli Firefoxu. I v tomto se tedy oficiální návod (a tisková zpráva MV ČR) bohužel mýlí.

Pokud potřebujete poradit, jak nový kořenový certifikát PostSignum Root QCA2 správně nainstalovat, pak vás mohu odkázat na své předchozí články, či na  podrobné návody přímo na informačním webu  datových schránek. Zde ale s jedním důležitým dodatkem: tyto návody neupozorňují na to, že právě novější MS Windows (osobně mám tuto zkušenost s Vistami a novými Windows 7) nezařazují kořenové certifikáty PostSignum do správného úložiště: pokud to necháte na příslušném průvodci, uloží  kořenový certifikát nesprávně mezi certifikáty „Zprostředkujících certifikačních autorit“ (a nikoli mezi certifikáty „Důvěryhodných kořenových certifikačních autorit“, kam správně patří), viz obrázek:

Rozdíl je opravdu zásadní: pokud si nový kořenový certifikát nainstalujete do nesprávné části (systémového) úložiště (v MS Windows), pak to bude stejné, jako kdybyste ho nenainstalovali vůbec: váš browser nebude mít od čeho (od jakého kořene) odvodit důvěryhodnost příslušných certifikátů, a tak je nebude moci považovat za důvěryhodné. Dávejte na to tedy pozor, a v okamžiku, kdy jste při instalaci certifikátů dotazováni na místo uložení, rozhodně nenechávejte výběr na průvodci, ale sami zvolte správné úložiště. Viz následující obrázek:

Stejně tak pamatujte na to, že XML Filler v prostředí MS Windows používá systémové úložiště tohoto operačního systému. Takže pokud používáte například Firefox (a v něm plug-in od XML Filleru), pak musíte instalovat nový kořenový certifikát do dvou úložišť.

Další změny

Přechod ISDS na SHA-2 samozřejmě neznamenal jen výměnu (serverového) certifikátu za nový. Další změnou je použití nového systémového certifikátu pro podepisování (správně: opatřování elektronickou značkou, alias: značkování) datových zpráv a jejich doručenek. Původnímu certifikátu totiž končila jeho řádná platnost již tento týden, 27.5.2010. Stejně tak dojde – ale prý až od června – k výměně certifikátu, na kterém jsou založena časová razítka (které ISDS získává od autority časových razítek CA PostSignum a přidává ke svým  datovým zprávám). Nový certifikát také bude mít delší platnost (na šest let) a bude každoročně obměňován. Alespoň tak to slibuje informační materiál k přechodu na SHA-2, který byl distribuován do datových schránek výše popisovanou systémovou datovou zprávou: 

Platnost certifikátu časového razítka byla v červnu 2009 stanovena na tři roky. Od června 2010 bude nasazen nový certifikát s platností šest let, který bude každoročně obnovován, takže platnost časového razítka na datové zprávě bude vždy nejméně pět let od data vystavení.

Ještě další změnou, navazující na právě popsané, je nutnost upgradu XML Filleru. Přesněji: oba mnou zkoušené browsery (Firefox a Internet Explorer), které do té doby s obsahem datové schránky dokázaly pracovat,  se včera nekompromisně dožadovaly upgradu příslušného plug-inu (pro zobrazení dodané zprávy). Tento upgrade se mi ale provést nepodařilo, vždy to skončilo chybou. Pomohlo až úplné přeinstalování celého XML Filleru jako takového (a ten si již sám aktualizovat plug-iny v obou browserech). 

Nový systémový certifikát pro značky … a co z něj vyplývá?

Abych vám zde mohl ukázat nový systémový certifikát, používaný v rámci ISDS pro podepisování (přesněji: značkování), snažil jsem, aby mi do redakční uzávěrky někdo poslal nějakou datovou zprávu. To se sice nepodařilo – ale nový certifikát vám stejně ukázat mohu. Zjistil jsem totiž jednu zajímavou věc, která docela změnila můj pohled a názor na fungování datových schránek.

Schválně se podívejte detailněji na následující dva obrázky. Vidíte na nich jednu a tu samou datovou zprávu (tu hromadně rozesílanou systémovou zprávu, jiná mi v datové schránce momentálně nezbyla). Na prvním obrázku  (vlevo) vidíte detaily její elektronické značky, včetně použitého certifikátu (toho s platností do 27.5.2010). Jde o obrázek, který jsem nasnímal  ještě před přechodem systému na SHA-2.

Na druhém obrázku pak vidíte úplně stejný obrázek, ale nasnímaný již po přechodu ISDS na SHA-2. Tedy včera, 23.5.2010 v od­poledních hodinách. Vše je stejné, zejména časové razítko je stále stejné (z 6.5.2010, 14:07:44). Co je naopak odlišné, je certifikát, na kterém je založen elektronický podpis (správně: elektronická značka) datové zprávy jako celku. Ano, jde již o nový certifikát, založený již na hashovací funkci SHA-2 a vydaný novou certifikační autoritou PostSignum QCA 2. Nutně tedy jde o jiný elektronický podpis (správně: elektronickou značku).

Jak je ale toto možné? Jak se mohl změnit elektronický podpis na datové zprávě, aniž by se změnilo  časové razítko (aniž by ztratilo platnost, resp. došlo k porušení integrity)? Jak se může časové razítko s datem 6.5.2010 vztahovat na datovou zprávu s podpisem (značkou), který vznikl až 23.5.2010? Jak může stvrzovat, že datová zpráva s tímto „novým“ podpisem z 23.5. existovala před 6.5.? Odpověď je jasná: nemůže.

Jediné možné vysvětlení je takové, že elektronická značka vzniká později než časové razítko. Tedy že nejprve bylo ke zprávě připojeno časové razítko, a teprve pak elektronický podpis (značka). Značka tedy nejspíše vzniká v okamžiku, kdy ISDS datovou zprávu „vydává“ (zatímco časové razítko vzniká již tehdy, když ISDS datovou zprávu přijímá a ukládá do datové schránky příjemce). To by ostatně odpovídalo i tomu, jak fungují relevantní služby rozhraní webových služeb, které umožňují stáhnout podepsanou datovou zprávu (SignedMessage Download). A koresponduje to i s tím, že „nová“ značka, vzniklá až po přidání časového razítka, je tou značkou (podpisem), která se ukládá do datové zprávy, pokud si ji sami uložíte někam na svůj disk (do formátu ZFO). Příklad (se stále stejnou systémovou zprávou) vidíte na následujícím obrázku:

Jakkoli to vše vypadá logicky a „zapadá do sebe“, má to jeden nesmírně významný důsledek: časové razítko na datové zprávě sice obsahuje určitý údaj o čase, ale ten není možné vztáhnout na elektronický podpis (značku) na zprávě jako takové. Jenže na tomto předpokladu je naopak postavena veškerá argumentace o dlouhodobé platnosti datové zprávy, předpokládající že časové razítko stvrzuje dobu vzniku podpisu (značky). Naposledy to zaznělo v informačním materiálu, který byl distribuován popisovanou systémovou datovou zprávou:

Co staré zprávy opatřené el. značkou Ministerstva vnitra založené na starém, expirovaném certifikátu — bude 602XML Filler oznamovat, že jsou podepsány podpisem založeným na neplatném certifikátu?

Ano bude, nicméně podle platné legislativy se považuje datová zpráva za pravou i v tomto případě, protože byla podepsána podpisem založeným na certifikátu, který byl platný v době podpisu. Zdali tomu tak skutečně je si můžete ověřit z časového razítka.

No, výše uvedený příklad jasně ukazuje, že toto ověření z časového razítka nevyplývá: razítko, přidané PŘED podpisem (značkou), a nikoli až PO něm, nedokládá, že podpis byl přidán před okamžikem, uvedeným na časovém razítku. Vlastně to naopak vylučuje.

Osobně mi přijde, že jde o dosti závažný (systémový) problém, který dále komplikuje praktické prokazování platnosti elektronických podpisů a značek.

Mimochodem, nemá někdo ze čtenářů ve své datové schránce nějakou zprávu z doby před 9.4.2010 8:33 (kdy byl vydán nový systémový certifikát pro vytváření el. značek), kterou by byl ochoten nově stáhnout a uložit (do ZFO formátu) a zveřejnit? Na takovéto zprávě by totiž bylo vše nejlépe vidět: její časové razítko by znělo na dobu před 9.4.2010, ale elektronická značka by byla založena na certifikátu, vytvořeném až 9.4.2010.

Navíc i u časového razítka může být zajímavou otázkou, co vlastně pokrývá. Protože občas se stává, že časový údaj na razítku předchází některým údajům v datové zprávě (konkrétně třeba údaji o dodání do datové schránky). Viz příklad na následujícím obrázku:

Co je hash a co dokládá časové razítko?

Na závěr si dovolím využít situace pro trochu osvěty, jak k významu časového razítka, tak i k rozdílu mezi šifrovací a hashovací funkcí.

Začneme-li u hashování  a šifrování, pak zásadním rozdílem mezi nimi je už požadavek na jejich „směrovost“: v případě hashování funkce kategoricky požadujeme, aby byla pouze jednosměrná a nikoli „vratná“. U šifrovací funkce naopak stejně kategoricky požadujeme, aby „vratná“ byla – aby se to, co jednou zašifrujeme, dalo zase dešifrovat. Ať již stejným klíčem (v případě symetrického šifrování), či „párovým“ klíčem (v případě asymetrického šifrování).

V případě hashování jde už z principu o něco jiného, než u šifrování: na vstupu máme „něco velkého“ (nějakou zprávu, apriorně neomezené velikosti), a skrze hashování z toho potřebujeme udělat „něco malého“, co má pevnou velikost a bude se nám s tím lépe dále zpracovávat. Česky se tomu říká také otisk, anglicky nejčastěji message digest, či jen zkráceně „hash“.

Elektronický podpis pak funguje tak, že z (libovolně velké) zprávy či dokumentu se udělá takovýto otisk pevné velikosti, který se následně  zašifruje soukromým klíčem podpisující osoby. Tím vzniká elektronický podpis, který se pak může vložit přímo do souboru se samotným dokumentem (v případě tzv. interních elektronických podpisů), nebo se k souboru s dokumentem přiloží jako samostatný soubor (v případě tzv. externích podpisů).

Podobně to funguje u časových razítek: zde je také nejprve vytvořen otisk (message digest, hash) celé zprávy či dokumentu, a ten je pak odeslán poskytovateli služby časových razítek. Tento poskytovatel přidá garantovaný údaj o čase a vše zašifruje svým soukromým klíčem. Výsledek, představující samotné časové razítko, vrátí žadateli zpět – a ten jej připojí (stejně jako elektronický podpis) k tomu dokumentu, ze kterého byl vytvořen onen otisk (hash).

Rozdíl mezi elektronickým podpisem a časovým razítkem je pak v tom, že časové razítko vypovídá pouze o tom, že příslušná zpráva či dokument (fakticky ale: jejich otisk) existovala ještě před okamžikem, kdy byl otisk zaslán k vytvoření časového razítka. Co časové razítko naopak neříká a nijak nestvrzuje, je od koho (odkud) požadavek na časové razítko přišel. Takže třeba časové razítko na datové zprávě stvrzuje pouze to, že příslušná data existovala před okamžikem na časovém razítku – ale už neříká nic o tom, že tato data prošla systémem datových schránek. Stejně tak dobře jste si mohli datovou zprávu sestavit sami (nebo si v ní jen něco  změnit), a pak sami požádat o přidání časového razítka.

To, že data prošla (jako datová zpráva) skrze systém datových schránek, stvrzuje až onen elektronický podpis (značka) ISDS – ale když tento podpis (značka) není „pokryt“ časovým razítkem, budeme mít časem problém prokazovat jeho platnost.

Mimochodem, tuto skutečnost (že časové razítko „nepokrývá“ značku na datové zprávě) by mohl kompenzovat nově připravovaný „institucionální archiv“ a s ním spojená možnost ověřit si (podle otisků, uchovávaných v ISDS), zda konkrétní datová zpráva prošla či neprošla skrze datové schránky. Dosud to bylo prezentováno spíše jako řešení problému s ověřováním datových zpráv v delším časovém horizontu. Ale co když jde  spíše o kompenzaci právě popsaného problému, v podstatně kratším časovém horizontu?

SHA-1 pracuje s otisky velikosti 160 bitů

Vraťme se ale zpět k hashovacím funkcím a otiskům a připomeňme si, že  v rámci elektronického podpisu je fakticky „fixován“ (šifrován soukromým klíčem) pouze otisk. Takže celá původní zpráva (dokument), velikosti třeba i v řádu megabytů, se nejprve „smrskne“ na onen otisk – který má v případě dosud používané hashovaní funkce SHA-1 velikost 160 bitů – a teprve z tohoto otisku je vytvořen samotný elektronický podpis. Snad není těžké si uvědomit, že pokud by se někomu podařilo najít jiný dokument, který se „smrskne“ do přesně  stejných 160 bitů, že bude zle: stejný elektronický podpis by pak „seděl“ k oběma dokumentům.

To, že takovéto dokumenty se stejným otiskem (označované jako „kolizní“) existují, vyplývá již ze samotného faktu „smrskávání“ v rámci hashování: jakmile z „něčeho většího“ děláme „něco menšího“, nutně musí dojít k tomu, že se různé výchozí dokumenty  „smrsknou“ na stejný otisk. A pokud je hashovací funkce navržena správně, je toto smrskávání rovnoměrné, v tom smyslu že ke všem hodnotám otisku existuje stejný počet výchozích dokumentů. A pokud apriorně neomezíme velikost výchozího dokumentu, bude kolizních dokumentů (ke každé konkrétní hodnotě otisku) existovat nekonečně mnoho.

Aby samotná principiální existence kolizí nebyla překážkou používání elektronických podpisů, musí být zajištěno, že nalezení kolizních dokumentů bude obtížné (neúnosně složité). Přesněji musí být zajištěny tři základní požadavky:

• je-li znám otisk zprávy, je obtížné z něj odvodit zprávu odpovídající tomuto otisku,
• je-li znám otisk a zpráva, je obtížné najít jinou zprávu se stejným otiskem,
• je obtížné najít dvě zprávy, které mají stejný otisk.

Samotná hashovací funkce pak musí být navržena tak, aby toto zajišťovala. A jelikož je požadovaná obtížnost závislá na aktuálních možnostech výpočetní techniky, musí být hashovací funkce průběžně měněny (posilovány), včetně zvětšování samotných otisků. To se právě nyní děje, když se od hashovací funkce SHA-1 (s otiskem velikosti 160 bitů) přechází na složitější  hashovací funkce SHA-2. Ve skutečnosti jde dokonce o několik variant hashovacích funkcí SHA-2, které se liší i velikostí otisku: ten má 224, 256, 384 nebo 512 bitů.

Nynější přechod na hashovací funkci SHA-2 pak určitě není posledním svého druhu. Naopak, jde o jeden krok v rámci nikdy nekončícího procesu. Ostatně, ve svém dokumentu „Informace k přechodu k bezpečnějším kryptografickým algoritmům v oblasti elektronického podpisu“ to konstatuje i Ministerstvo vnitra, které jako dozorový orgán pro oblast elektronického podpisu celý přechod formálně iniciovalo:

S rozvojem kryptoanalytických metod a dostupností potřebné výpočetní techniky (síly) je nezbytné vzít na vědomí skutečnost, že u žádného algoritmu nelze předpokládat, jeho používání v horizontu desítek let. Například algoritmus MD5 (Message-Digest Algorithm) byl poprvé zpochybněn v roce 2004, prolomení algoritmu SHA-0 (Secure Hash Algorithm) bylo oznámeno v roce 2004, první indicie o prolomení algoritmu SHA-1 pocházejí z roku 2005. Nic nenasvědčuje tomu, že by se tento trend v blízké budoucnosti změnil a že nové a „silnější“ algoritmy by měly předpoklad výrazně delší doby životnosti. Předpokládá se, že hashovací funkce z rodiny SHA-2 budou bezpečné do roku 2015.