Hlavní navigace

Názor k článku Vlastimil Klíma: Zcela nový koncept hašovacích funkcí od Martin Hlaváč - Myslím, že Rijndaela v roli SBŠ sa asi...

Článek je starý, nové názory již nelze přidávat.

  • 17. 11. 2006 19:16

    Martin Hlaváč (neregistrovaný)
    Myslím, že Rijndaela v roli SBŠ sa asi vzdáme. Prečítal som si zhova Váš článok, zatiaľ bohužiaľ bez dokazov. Snáď sa k nim cez víkend konečne dostanem. Mám na Vás pár otázok:

    Veta 1 hovorí o _náhodnom_ výbere blokovej šifry E z BC(K,n). No ale odkiaľ takúto šifru zoberieme? Všetky, ktoré máme (a budeme mať), majú nejaký konkrétny predpis. Vadí nám to? (tá istá otázka sa vzťahuje k náhodnému orákulu vo Vete 3). Nemože nastať rovnaký problém ako u spojitých funkcií z R do R?: náhodne zvolená funkcia z takejto množiny nemá nikde deriváciu, ale musíme sa veľmi snažiť, aby sme nejakú explicitne našli. Nebude rovnaký problém s náhodným výberom blokovej šifry/orákula? (Tu máme ale výhodu, že BC(K,n) je konečná množina, aj keď obrovská.)

    Vo Vete 2 má symbol <---^$ (dolár nad šípkou) dva rozne významy. Náhodná voľba blokovej šifry je jasná, ale zápis "(M,M') <---^$ A" mi až taký jasný nie je. Znamená, že si útočník A náhodne volí správy M a M' a skúša, či majú rovnaký haš? To asi nie. Takto útočník nepostupuje. Nemalo by byť zápis "(M,M') <---^$ A" nahradený zápisom "(M,M') <--- A_E_E^-1" (bez dolára). Ak je moja interpretácia zápisu "(M,M') <---^$ A", tak nám v súčasnom znení veta hovorí, akú výhodu má najsilnejší útočník, ktorý si zvolí _náhodne_ dve správy a pozrie sa, či nemajú rovnaký haš. Sporné je to v tom, že najsilnejší útočník takto postupovať nebude a bude správy voliť rozumnejšie. (Opať je podobná otázka relevatná k Vete 4.)

    Každopádne si myslím, že značenie obsahujúce podtržítka zvádza k interpretácii dolného indexu, čo napr. pri A_E_E^-1 vedie k zmatenie čitateľa. Vy ste už s týmto značením zrastený :), ale aj tak by som navrhol preznačiť (ak nie je zaužívané z inej literatúry).

    V závere článku uvádzate parametre špeciálnej blokovej šifry DN, K=8192 a n=512. Na prvý pohľad sú to pekné okrúhle čísla, ale keď si uvedomíme, že jej uplatnenie by malo byť hlavne v SNMAC a do 8192 bitov kľúča sa bude sypať 512 bitov kontextu, ostáva nám nie až tak okrúhlych 7680 bitov. Myslím, že programátorom by sa omnoho ľahšie delilo hašovanú správu na bloky po 8 Kb. Mimochodom ma takého čísla (K, n) vedú k domnienke, že v DN nie sú rundové kľúče generované jeden po druhom, ale samotný kľúč je rozdelený na rundové kľúče (z čoho by vyplývalo, že rúnd je 16*L).

    Na záver mi predsa len stále nedá pokoj ten Rijndael :). A propos homogenita spracovávania bitov správy a kľúča ma napadla takáto myšlienka (opať Rijndael): namiesto multiplikatívnej inverzie v telese GF(2^8) v kroku SubBytes by sa v GF(2^8) navzájom vynásobili príslušné bajty "pretekajúceho" kontextu a kľuča. XOR kľúča na konci rundy by sa vynechal. Opať by to ale bolo na úkor efektivity, pretože by sme museli mať predpočítanú tabuľku o veľkosti 256^2 bajtov (vs. 256 bajtov u Rijndaela).