Datové schránky přešly na SHA-2 (lupa.cz; 24.5.2010)

Od včerejšího dne používá informační systém datových schránek nové certifikáty, již na bázi SHA-2. Stihla se včas automatická distribuce nových kořenových certifikátů CA PostSignum do novějších verzí MS Windows, jak bylo uživatelům slibováno, nebo si musí nové kořenové certifikáty instalovat sami? Jaké další dopady má celý přechod?

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“.

systémová datová zpráva

 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.

sifrovaci funkce SHA-2

 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.

certifik8t s SHA-2

 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.

nový kořenový certifikát ve zprávě

 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).

             puvodni serverovy certifikat

             novy serverovy certifikat

 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:

   nespravne ulozeni certifikatu

 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:

             nespravna volba pruvodce

             spravna volba pruvodce

 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.

             puvodni el. znacka na zprave

             nova el. znacka na zprave

 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 odpolední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:

  el. znacka na ulozene zprave ve formatu ZFO

 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:

  rozdil mezi casovym razitkem a dodanim zpravy

 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.

URL| http://www.lupa.cz/clanky/datove-schranky-presly-na-sha-2/