Először is egy fontos dolog, amelyre külön felhívjuk a figyelmet:
I. Mindig győződj meg arról, hogy a legfrisebb verziójú klienst használod. Elég gyakori az upgrade, és lehet, hogy az általad tapasztalt problémát a mostani verzióban már megszüntették.
A fenti a hivatalos duma, a valóság viszont az, hogy többeknek tele lett a töke a legutóbbi DES verseny (DES-III) közeledtével előállt irtózatos tempójú kliens frissítés során megjelent újabb és újabb verziók újabb és újabb hibáival, melyek közül némelyik olyan alapvető volt, hogy a teljes működést lehetetlenné tette. Szóval nem kell észnélkül frissíteni, tessék figyelni a listán a tapasztalatokra!
II. A DES-II projekt kliensei (v2.7xxxx) nem tudják használni a korábbi verziójú kliensek buffer file-jait (buff-in, buff-out). Sajnos a kliens semmiféle üzenetet nem küld ezzel kapcsolatban, ezért legyél abszolút biztos abban, hogy letörölted a korábbi formátumú buffereket, mielőtt belekezdenél a v2.7xxxx kliensekkel való munkába.
Multithreaded, azaz többszálú futtatásra alkalmas. Ez gyakorlatilag azt jelenti, hogy a kliens képes egy külön szálon a hálózati kommunikációt folytatni, míg a törő 'szál' teljes erőből tud a kulcsokon dolgozni. Ilyen kliens nélkül a kulcstörésnek meg kell állnia arra az időre, míg a kulcsszerverrel, vagy 'personal proxy'-val kapcsolatba kerül. Tehát akkor is élvezheted az MT kliens előnyét, ha csak egy processzor van a gépedben, azaz csak akkot használj NON-MT klienst, ha az MT valamiért nem akar működni. Linux esetén a 2.0 verzió feletti kernelek esetén lehetőség van az MT kliens futtatására (írd be az "uname -r" parancsot a kernel verziószámának kiderítéséhez, ha esetleg nem tudnád azt). A Solaris rendszer részére szintén létezik MT és NON-MT kliens, de a szerzőnek sajnos nincs biztos információja az MT kliens futtatásához szükséges pontos rendszerkövetelményekről. Próbálkozz!
1.2 A kliensem klasszul töri egész nap a blokkokat, de nagyon leesik a sebesség éjszaka, vagy ha hosszabb ideig eltávozom a gép mellől!
Valószínűleg a képernyővédő 'program' üti ki a klienst és veszi el az időt a kulcstörés elől. A képernyővédő magasabb prioritással fut, mint a kliensnek akár a legmagasabb prioritási értéke, így a megoldás az lehet, hogy olyan képernyővédőt választasz, amely nagyon kevés processzor-időt zabál (pl a 'blank', azaz üres fedőnevű), vagy egyáltalán nem használsz.
Néhány böngésző (vajon melyek azok? :-) arról ismert, hogy zabálja a processzoridőt, különösen akkor, ha animált képek vannak a megjelenített oldalakon.
Egy másik oka lehet a lassulásnak, hogy az újabb gépek egy bizonyos idő után "alvó üzemmódba" (sleep mode) lépnek, amikor is a legtöbb komponens energiaellátása megszűnik [vagy csak lecsökken? (powers most components down)]. Ennek kiiktatási lehetőségeiről a gép dokumentációjában keresd a választ.
1.3 Hallottam valamiféle 'exitfile'-ról. Mi fán terem ez, és hogyan működ?
Alapértelmezés szerint a kliens a 'munka könyvtárban' (working directory) rendszeresen ellenőrzi az 'exitrc5.now' meglétét. Ha megtalálja, akkor nagyon szépen kilövi saját magát ("shuts itself down gracefully"), azaz megállíthatod a klienst ennek a file-nak a létrehozásával. A file tartalma teljesen közömbös, a kliens csak a meglétét ellenőrzi. Figyelem! a kliens nem törli ezt a file-t kilépéskor, szóval ne felejtsd el kidobni/átnevezni te magad, mielőtt legközelebb újraindítod a törést, különben hamarost leáll.
1.4 Már órák/napok óta töröm a blokkokat, de az email címem nem látszik a statisztikákban!
1.5 Segít-e valamit, ha megváltoztatom a 'randomprefix' paraméter értékét a kliens INI file-jában?
NEM!! Semmilyen körülmények között se változtasd meg ezt az értéket. Ezt a kliens változtatja meg menet közben, amennyiben a szükség úgy diktálja. Ez a paraméter úgy lett tervezve, hogy maximalizálja a véletlen-blokk generálás hatékonyságát az egész projekt élettartama alatt. Ha megváltoztatod, akkor lehet, hogy a saját idődet (vagy akár a többiek idejét is) pazarlod duplán generált véletlen-blokkok feltörögetésével.
1.6 Használhatom-e több gépen ugyanazt az email címet?
IGEN!! Teljesen nyugodtan add meg minden gépen ugyanazt a címet, ez az adat csak azért kell, hogy a beküldött blokkok csatolhatóak legyenek "valakihez". Ha több gép használja ugyanazt a címet (azaz azonosítót), akkor a statisztikákban a címed mellett összegezve fogod látni a beküldött eredményt, gépekre bontva nem.
Az ablak, amelybe ez a kliens a log-output-ot irja, 32K méretben limitált. Miután a buffer betelt, valóban úgy tűnhet, mintha a kliens lefagyna, pedig valójában csak a GUI ablak teszi ezt, a kliens tovább dolgozik. Ez a probléma már megoldott a legutóbbi (?) verziókban, így ha ezzel a jelenséggel találkozol, akkor gyorsan töltsd le a legfrisebb verziót.
2.2 Mintha a Win32 GUI és az NT-Service kliens nem állítaná helyre a 'checkpoint' file-ját indításkor!
A régebbi nem-command-line kliensekben valóban megtalálható ez a hiba, amely azonban a v2.6403.335 verzió óta már ki van küszöbölve.
2.3 Nekem úgy tűnik, hogy a Win32 GUI kliens elveszít blokkokat, ha reboot-olom a gépemet, még akkor is, ha helyesen shutdown-olok!
Bizonyos okokból a Win32 kliensek nem képesek fogadni a rendszer shutdown parancsát, mint egy kilépésre utasító szignált, ezért nem tudnak helyesen leállni, nem írják vissza az éppen törés alatt álló blokkokat az 'in-buffer'-be. A jelenlegi megoldás erre a problémára a 'checkpoint' file létrehozása és "használata", amely a konfigurálás egyik utolsó menüpontjában tehető meg.
2.4 Miért lassabb a Win32 GUI kliens, mint a 'command line' verzió?
A FAQ eredeti szerzője szerint: "Nem tudom", valamint hozzáteszi, hogy áltlánosságban elfogadható az a kijelentés, hogy egy grafikus felhasználói felülettel (GUI) rendelkező kliens lassabb, mint neki megfelelő nem-grafikus (CLI) kliens (legalábbis a win32 világban)
2.5 Miképp érhetem el, hogy a Win32 kliens elinduljon, mielőtt a felhasználó belépne (login)?
Indítsd el a REGEDIT programot. Menj el a registry-tree-n a következő könyvtárig: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices és itt add meg a következő új string értéket: "bovwin32". A string-et editáld úgy, hogy az értéke a kliens teljes útvonala (full path) legyen (pl. "c:\rc5des\rc5des.exe"). A 'command line' helyére beírhatod bármelyik opciót, amelyet a kliensre alkalmazni akarsz (pl. -hide). Legtöbb esetben (?) a '-install' opcióval futtatott kliens hasonló eredményre vezet, de ezesetben az előbb említett string hozzáadódik a 'Run' bigyóhoz IS (bocs, de az itt szereplő ["Run" key] szópárnak jelen esetben foggalmam sincs, hogy mi felelhet meg!), amely ugyanazon a szinten található a Registry-ben, mint az előbb említett "RunServices". A FAQ eredeti szerzője nem biztos abban, hogy mi előnye lehet ezen második string érték megadásának. (hát még én :-)
2.6 Mi a különbség a Win32-hidden kliens és a 'command line' kliens '-hide' kapcsolóval történő futtatása között?
A command-line (karakteres, vagy parancssoros vezérlésű) kliens a '-hide' opcióval röviden (tájékoztató jelleggel) megjelenít egy DOS-ablakot az indulásakor, míg a 'hidden' (azaz rejtett) kliens nem teszi ezt.
Igen, kifejezetten ezen szempont figyelembevételével tervezték meg.
3.2 Kezelheti-e több 'Personal proxy' ugyanazt az egy 'buff-out/in' file-t?
NEM!! A 'Personal proxy' buffer file-jai a proxy memóriájában tárolt egységek. Ha több proxy osztozna egyetlen buffer készleten, akkor a buffer file-ok teljes egészében felülíródnának az éppen legutolsó által és ez 'disk flush'-hoz(??) vezetne
3.3 Hivatkozhat-e egyszerre több kliens is ugyanarra a 'checkpoint' file/ra?
NEM!! A kliensek szónélkül felülírnák ezt a közös file-t a meglévő tartalmától függetlenül.
3.4 Használhatom-e a korábbi (v2.64xxx) kliensek buffer file-jait a jelenlegi legfrisebb (v2.7xxxx) kliensekkel?
NEM!! A friss kliensek (v2.7xxxx) nem tudják használni a korábbi verziójú kliensek buffer file-jait (buff-in, buff-out). Sajnos a kliens semmiféle üzenetet nem küld ezzel kapcsolatban, ezért legyél abszolút biztos abban, hogy letörölted a korábbi formátumú buffereket, mielőtt belekezdenél a v2.7xxxx kliensekkel való munkába. Ha ezt nem teszed meg, akkor esetleg nagyon-nehezen-diagnosztizálható problémákkal találkozhatsz.
3.5 Ha az 'input buffer' értékét magasabbra állítom, mint az 'output buffer' (például 10:5), akkor ez jelenheti-e azt, hogy az első néhány blokk örökre ott marad a buffer "alján"?
Igen; kivéve, ha a kliens nem képes valamiért új blokkokkal feltöltekezni. Az input buffer számológéptudományi :-) terminológiával élve: LIFO (Last-In-First-Out), azaz a blokkok fordított sorrendben használódnak fel, mint ahogy bekerültek a bufferbe. Emiatt senkinek ne fájjon a feje, de méginkább ne tegyen ilyesmit, mert sok ezren fognak szívni, ha valaki ilyen módon 'eldugja' pont azt a bizonyos kulcsot. Tehát lehetőleg a buffer in-out értéke legyen azonos.
3.6 Asszem néhány blokkot véletlenül többször is elküldtem a szervernek. Megzavarja-e ez a statisztikákat?
Nem kell parázni! Az első személy, aki lejelent egy elkészült blokkot, megkapja az ezért járó 1 kreditet. Senki, még ugyanaz a személy sem kaphat mégegyszer pontot ugyanazért a blokkért.
3.7 Mi történik, ha véletlenül letörlöm az 'input buffer'-emet, vagy egyéb módon "elvesztek" néhány olyan blokkot, amelyen éppen dolgoztam?
A kiadott kulcsok "szavatossága" minimum 90 nap, ennyi idő elteltével viszont már elképzelhető, hogy a master-keyserver elkezdi kiosztani azokat a kulcsokat, amelyeket már egyszer kiadott, de nem kapott vissza. Más szavakkal élve az "elveszett" kulcsok 're-fognak-inkarnálódni' :-)
3.8 Úgy gondolom, hogy talán túl sok blokkot kértem le a szervertől. Van-e valamilyen mód az érintetlen blokkok visszaküldésére?
Jelenleg nem, de az előző kérdés/válasz pár alapján nem is kell ezzel foglalkozni.
"Konkrétan? Nem tudjuk. Soha nem tudtuk még pontosan megmondani, hogy mit jelentenek a számok a 'network error' üzenet végén. Általánosságban annyit lehet kijelenteni, hogy a kliensnek vmi problémája van a kulcsszerverrel való kommunikálás terén (vagy a 'personal proxy'-val). Az egyetlen tanács: le kell ellenőrizni minden hálózati kommunikációval és kulcsszerverrel kapcsolatos beállítást az INI file-ban." (szó szerinti idézet az eredeti FAQ-ból)
4.2 Nem sikerül a kliensemnek a tűzfalon keresztül kommunikálnia, pedig minden konfigurációs beállításom helyes!
Néhány ember sikeresen oldotta meg a tűzfallal kapcsolatos problémáit azzal, hogy EGYETLEN konkrét kulcsszervert definiált, szemben az általánosan javasolt és használt 'round-robin' (na ezt vajon hogyan mondják magyarul?) DNS címekkel. Ilyen 'round-robin', vagy másképp nevezve 'alias' DNS például az rc5europroxy.distributed.net cím, amely valójában több, az európai területen elhelyezkedő kulcsszerver közös fedőneve (ilyen megtalálható több kontinensen), és amely a blokkokat automatikusan forgalmazza a tényleges kulcsszerver gépek között annak megfelelően, hogy éppen melyik érhető el optimálisan éppen.
Konkrét kulcsszerver információkkal a Bovine PROXY oldalain ismerkedhetsz meg (http://www.distributed.net/rc5/proxyinfo.html). Manuális DNS-entry piszkálás megtehető a Web-en keresztül a következő címen: http://ds1.internic.net/cool/dns.html
4.3 Miért kapok állandóan 'network error' üzenetet az Alpha Linux klienssel?
Sajna a nevezett klienseknek mindig is problémái voltak a DNS nevek meghatározásával, így az egyetlen megoldás az, ha definiálunk EGYETLEN konkrét kulcsszervert a lehetőségek közül (lásd a fennti címet!). Ez a probláma már a legelső DESII kliensekben is (v2.7001.x) megvolt és jelenleg is él, így a Bovine programozói szeretettel várnak bármiféle építő jellegű ötletet ezzel kapcsolatban.
4.4 Hogyan oldható meg a kliens/proxy kommunikálása kifelé egy Microsoft proxy szerveren keresztül?
Az egyik résztvevő megoldása itt látható:
A hálózati beálításokat a következőképpen add meg (CLI kliens):9) Network Communication mode ==> 4 10) Preferred KeyServer Proxy ==> alde.com (bármely konkrét kulcsszervernek működnie kellene, de az alde.com tökéletesnek bizonyult az adott esetben, szemben a 'rc5proxy.distributed.net'-tel, amely nem volt használható) 12) Local HTTP/SOCKS proxy address ==> [a TE MSProxy szervered IP címe] 13) HTTP/SOCKS4 proxy port ==> általában 80, nézd meg az Internet Explorer beállítását, ha nem vagy biztos a dologban (View, Options, Connection)
Ezután add meg a te NT domain login és password értékeidet a konfig 15. pontjában. Az MS Proxy szerver az NT domain biztonsági rendszerét használja minden belépéshez (login) és hozzáféréshez (access restrictions)
Igen. Fordítva viszont nem megy a dolog: a jelenlegi kliensek nem tudnak együttműködni a korábbi 'Personal proxy'-kkal.
5.2 Cserélgethetem-e a 'personal proxy'-m buffer file-jait a kliensem buffer file-jaival?
NEM!! A két formátum nem kompatibilis.
A DES blokk minden egyes kulcsának törése mellett megteszi ugyanezt a kulcs komplementerével (kiegészítőjével; logikai NOT) is. Ez azt jelenti, hogy a DES törés 2x annyi ideig tart, mint ugyanannyi kulcsot tartalmazó RC5 blokk feltörése. Ennek a megoldásnak az az oka, hogy sokkal hatékonyabb a kulcsnak és komplementerének 'egy időben' történő vizsgálata, mint a két kulcsot külön-külön alkalommal sorra venni
6.2 Mi ez az egész macera itt a DES blokkok méretével (2^28/29/30/31)?
Hát ami a terminológiából logikusan következik, édesem! Azaz egy 2^28-as blokk azt jelenti, hogy abban ennyi kulcs van. Figyelembe veendő azonban, hogy egy ekkora blokk teljes átvizsgálásához valójában a DES kliens 2^29 kulcsot számol át (lásd az előző kérdést). Az RC5 blokkok mind 2^28 méretűek, a DES estében ez azért többféle, hogy - feltételezhetően(?) - a gyorsabb klienseknek ne kelljen annyi blokkot 'bufferelni', mint amennyit egyébként kellene, produkálván a megnövekedett sebességet (az RC5 töréshez képest).
6.3 A log file-ban lévő blokkonkénti kulcsszám hibás. A 2^28-as blokk mérete 268436456, nem pedig 536870912, mint azt a log mutatja.
Ez nem hiba, lásd az 6.1 és 6.2 kérdéseket!
6.4 Mi a helyzet a 2^32 méretű DES blokkokkal?
A kettős Rc5/DES kliensek első verzióiban megengedett volt a 2^32 méretű blokkok kérése a kulcsszerverektől, sajna azonban egy hibát találtak, amely megakadályozza ezen blokkok tökéletes ellenőrzését. A 2.7001.384 verziójú és későbbi kliensek már úgy vannak kódolva, hogy nem megengedett számukra az ilyen méretű blokkok igénylése, de az ini file-ban nyugodtan beállítható a kívánt érték 28 és 31 közé.
6.5 Hogyan történik az átváltás a DES és RC5 projektek között a kliensben?
Ha a kliens konfig file-jában a DES-ben való részvétel engedélyezve van (contestdes=1), akkor az indításkor a DES blokkok letöltésével próbálkozik először. Ha ez nem megy akkor RC5 blokkokat próbál meg leszedni. Ha ez sem jön össze, akkor véletlenszerűen generál RC5 blokkokat, de soha nem generál véletlenszerű DES blokkokat.
6.6 Miért csak egy DES processzt látok futni a multiprocesszoros rendszeremen?
A jelenlegi DES mag nem 'multithread-safe', azaz nem tuti a többszálú működése. A többszálúság úgy érhető el jelenleg, hogy a kliensnek több példánya indítandó el. A fejlesztők dolgoznak azon, hogy ez a kolátozottság a jövőbeni verziókban már ne legyen benne.
6.7 Eléggé egyforma DES törési sebességek adódnak függetlenül a kiválasztott CPU típustól. Ennek mi az oka?
Az Intel x86-architektúrájú chip-ek választéka csak az RC5 projektre vonatkozik (ne felejtsd el, hogy a jelenlegi kliensek RC5/DES kliensek egyben!), mindössze egyetlen DES mag van az összes ilyen chip-re, nincs választék, ez a funkció majd az RC5-64-re visszatérve használandó.
6.8 Ha a DES verseny blokkmérete változó, akkor a statisztikai oldalakon mi alapján láthatók az eredmények?
A legegyszerűbben a következőképp képzelhető ez el: a stat oladalak a 2^28 méretű blokkok alapján számolnak, azaz ha beküldesz egy ilyen (2^28) méretűt, akkor 1 blokkot számolnak el (igen, akkor is, ha - mint azt korábban az 1.2-ben olvashattad - valójában 2^29 kulcsot törtél meg). Egy 2^29, vagy 2^30 méretű blokkért 2, vagy 4 blokk jegyződik fel a neved mellé.