Ellenállni a GPU-s gyorsításnak

Szerző: David Perry

Érdekes változásokon ment keresztül a kriptoanalízis világa az elmúlt néhány év során. Az egyik legnagyobb változást az olyan általános célú GPU-platformok hajnala jelentette, mint amilyen például az OpenGL és a CUDA. Ezek segítségével ugyanis az ember olyan programokat is írhat, amelyek a gép CPU-ja helyett a grafikai processzorát veszik igénybe. És hogy ez miért is olyan jó? Ezt meglehetősen látványosan szemlélteti a “Mythbusters” Adam Savage-jének és Jamie Hynemanjának néhány évvel ezelőtti, a CPU-k és a GPU-k működési elve közti különbséget demonstráló videója.

A GPU alapelve tehát a szélsőségesen sokmagos feldolgozás. Míg a mai szabványos CPU-knak akár nyolc magjuk is lehet (bár a két- és négymagosak gyakoribbak), addig az otthoni gépem videókártyája ezernél is több maggal dolgozik. Persze a CPU magjai sokkal gyorsabbak és sokkal több különböző féle és fajta számítást tudnak elvégezni, míg a GPU magjai lassabbak és csak néhány alapvető számításra képesek. Azonban az olyan feladatokat, amelyek alapvetően egyszerű, csak épp egymás után nagyon sokszor elvégzendő számításokat igényelnek, a GPU-k mégis sokkal hatékonyabban tudják megoldani, mivel műveletek ezreit végezhetik el egyszerre, egy pillanat alatt. Ez pedig nagyban gyorsítja a feldolgozóképességüket – és így egyben számos kódolási és hashelési eljárást is tettek idejekorán elavulttá.

A Bitcoin alapját is adó SHA256-os kódolás például egy, a gyorsításra szélsőségesen érzékeny algoritmus. Míg egy jó CPU néhány millió SHA256-hasht számít ki egy másodperc alatt, addig egy jó GPU néhány százmilliót. Ez nagyrészt annak köszönhető, hogy az SHA256 egyszerű egész számos vagy bitwise műveletekkel dolgozik, amelyeket pedig a GPU-k rendkívül hatékonyan és minimális memóriahasználattal tudnak elvégezni. A gyorsítástűrő algoritmusok tárgyalásához ez a két legfontosabb alapfogalom.

Először is, az algoritmus instrukciókészlete igen egyszerű, az egyetlen, jól meghatározott célra tervezett grafikai processzorok pedig általaban kifejezetten erre specializált hardvereket használnak, így a grafikai szemszögből hasznosnak minősülő instrukciókat nyilván sokkal gyorsabban is kezelik, mint a kevésbé hasznosakat – az azonban már gyártónként eltérő, hogy hol milyen instrukciókat ítélnek már “elég fontosnak” a gyorsításhoz. Ezért is van az, hogy bitcoin-bányászat szempontjából az AMD kártyái sokkalta hatékonyabbak az nVidiáéinál: az AES256-hasheléshez használatos egyik instrukciót az AMD vonulata hatékonyabban kezeli, mint az egyéb területekre összpontosító nVidiák. Nagyon nehéz egy olyan instrukciókészletet összeállítani, ami világszerte mindenütt visszavetné a teljesítményt, mivel minden gyártó más-más területekre optimalizálja a termékeit; egyeseket, így például az nVidia Tesla vagy Fermi GPU-it már nem is hagyományos grafikai, hanem GPGPU-célokra tervezik. Mi több, ha egy algoritmus csak azért biztonságos, mert még nem áll rendelkezésre egy pont annak megfelelően optimalizált és gyorsított hardver, akkor az nagy valószínűséggel nem fogja túlélni már az első FPGA-s támadást sem (az FPGA egy amolyan “tiszta lap”-jellegű, igény és szükség szerint konfigurálható processzor – ami drágább ugyan a GPU-knál, de nem annyira, hogy teljesen figyelmen kívül lehessen hagyni).

Az SHA256 továbbá azért is igen sebezhető, mert nagyon kevés memóriát igényel. Rendszeresen dobálózunk persze a “memória” kifejezéssel, de a geekek körein kívül már csak nagyon kevesen vannak tisztában azzal, hogy memóriából és többféle létezik, amelyeknek szintén megvannak a maguk szakterületei. Általában, ha az ember “memóriáról” beszél, a DRAM-ra gondol: azokra a kedves, nagy kapacitású chipekre, amelyek a gépeink fő memóriáját alkotják, valamint az ezekhez hasonló tervezésű, a GPU-ink fő memóriáját alkotó testvéreikre. A DRAM azonban messze nem az egyetlen létező memóriatípus. A legtöbb CPU és GPU használ úgynevezett “on-die” (úgy is, mint “cache”, avagy gyorsítótár-)memóriát is; ezek alacsony kapacitású, a processzorral egy lapkán elhelyezett egységek, amelyeket a rendszer a legalacsonyabb szintű számításokhoz használ, és sokkal gyorsabbak a DRAM-nál. Az on-die és a DRAM kb. úgy viszonyul egymáshoz, mint az egy helyiségben tartózkodva beszélgetés a postai levelezéshez. Mivel azonban a processzor lapkáján csak kevés fizikai hely áll rendelkezésre, ezért az on-die memóriák kapacitása is erősen korlátozott. Hatványozottan igaz ez a sokmagos GPU-knál, ahol még kevesebb a hely a rengeteg mag között; míg egy jó GPU-nak is csak néhány tíz kilobájt gyorsítótár-memória áll rendelkezésére magonként, addig egy jó CPU akár néhány vagy több megabájt felett is rendelkezhet.

Ez utóbbi tényezőt használja ki a bCrypt és az sCrypt is, amely utóbbit a közelmúltban a Bitcoin-közösség is felhasználta olyan alternatív blokkláncokhoz, mint amilyen például a Tenebrix vagy a LiteCoin. Ezeknek épp az a deklarált célja, hogy ellenálljanak a GPU-s és FPGA-s gyorsításnak: direkt úgy tervezték őket, hogy az elvégzésükhez szükséges gyorsítótár-memória-szükségletet az átlagos CPU-cache-méret alatt és az átlagos GPU-cache-méret fölött tartsák, így semlegesítve a GPU-k szélsőségesen párhuzamos feladatvégzési lehetőségeinek előnyeit (azoknak a DRAM használatára kényszerítésével) és biztosítva az eljárás (valamelyest) CPU-barát jellegét. Gyakorlatilag azonban talán ésszerűbb lenne tovább fokozni a RAM-használatot (100+ MB), hogy a számítások mindig és mindenféleképpen a DRAM-ban maradjanak, és így még időigényesebbé váljanak. Ne feledjük, hogy bár a felhasználó szemszögéből igazán nem sok idő egy fél másodperc egyetlen hash kiszámítására, de egy támadó számára bizony már annál rémisztőbb időtartam, mivel neki elképzelhetetlenül sok hash-lehetőséget kell végigzongoráznia ahhoz, hogy akár csak egyetlen rést is találhasson a pajzson.

Persze mindent meg lehet kerülni valahogy, így ezt is: elég csak építeni egy olyan chipet, aminek egyszerre van sok magja és tekintélyes gyorsítótára is. Természetesen ez a lehetőség felmerült már a Bitcoin közösségének köreiben is, de arra jutottak, hogy egy ilyen rendszer megépítése rendkívül költséges lenne. Az sCrypt eredeti dokumentumai (vigyázat, PDF) szerint egy olyan ASIC kifejlesztésének költsége, amely egy év alatt (vagy még hamarabb) feltörhetne egy mindössze 10 karakteres random sCrypt jelszót, nagyjából 175.000.000.000.000 (175 ezermilliárd) dollárra tehető. Ehhez pedig már elég csak annyit hozzátenni, hogy az sCryptes Bitcoin-elágazások 10 ASCII-karakternél lényegesen nagyobb entrópiával dolgoznak.

Forrás: Coding In My Sleep

A lap szövege Creative Commons Nevezd meg! – Ne add el! – Így add tovább! 3.0 licenc alatt áll, felhasználni csak forrásmegjelöléssel, és ide mutató linkkel szabad.