Nasa ibaba ang isang artikulo ko natagpuan kamakailan. Ito ang isa sa mga pinaka-kumpletong paglalarawan ng PIN Verification Value (PVV) pataga.
Akala ko Gusto magtiklop ito dito para sa aking mga lokal na sanggunian.
Bilang puna ay nagawa tungkol sa balarila na ginamit sa orihinal na teksto, mayroon akong naitama ang ilan sa mga malinaw na error habang pinapanatili ang konteksto ng orihinal na materyales.
http://69.46.26.132/ ~ biggold1/fastget2you/tutorial. php
--- Orihinal Text ----
Paunang salita
Naisip mo na kailanman ay magtaka kung ano ang mangyayari kung mawalan ng iyong credit card o debit card at ang isang tao na ito. Puwede ba ang taong ito ma-withdraw ng pera mula sa isang ATM hulaan, kahit paano, ang iyong PIN? Saka, kung ikaw ay isang tao na nag hahanap ng card mo subukang hulaan ang PIN at kunin ang pagkakataon na makakuha ng ilang madaling pera? Syempre ang sagot sa parehong katanungan ay dapat na "no". Ang trabaho ay hindi na pakikitungo sa pangalawang tanong, ito ay isang bagay na ito ng mga personal na etika. Dito ako subukin sa sagot na ang unang katanungan.
Lahat ng impormasyon na ginagamit para sa trabaho na ito ay pampubliko at maaaring matagpuan sa Internet. Ang natitira ay isang bagay ng matematika at programming, kaya kami ay matuto ng isang bagay at may mga ilang mga masaya. Ako isigaw walang secrets. Bukod dito, ang mga layunin (at pinal na konklusyon) ng trabaho na ito ay upang ipakita na ang PIN algorithm ay malakas pa rin sapat na upang magbigay ng sapat na seguridad. Namin ang lahat kung ang teknolohiya ay hindi ang mahina point.
Ito gumagana analyses ng isa sa mga pinaka-karaniwang PIN algorithm, VISA PVV, na ginagamit ng maraming mga ATM card (credit at debit cards) at sumusubok na malaman kung paano ay lumalaban sa PIN hulaan tuligsa. Sa pamamagitan ng "hulaan" hindi ko ibig sabihin ng pagpili ng isang random na PIN at sinusubukan ito sa isang ATM. Ito ay kilala din namin na sa pangkalahatan ay binibigyan ng tatlong magkakasunod na subok na ipasok ang mga karapatan ng PIN, kung mabibigo namin mapigil ang ATM card. Bilang VISA PIN ay apat na digit na mahaba madaling pagbatayan na ang mga pagkakataon para sa isang random na PIN hulaan ay 3 / 10000 = 0,0003, tila mababa ang sapat na upang maging ligtas; ito ay nangangahulugan na kailangan mo upang mawala ang iyong card ng higit pa sa tatlong libong beses ( o pagkawala ng higit pa sa tatlong libong mga kard ng sabay-sabay:) hanggang sa may makatwirang pagkakataon ng pagkawala ng pera.
Ano ko talagang meant sa pamamagitan ng "hulaan" ay paglabag ang PIN algorithm upang ang mga ibinigay na kahit anong card na maaari mong malaman agad ang mga kaugnay na PIN. Kaya ang dokumento na ito posibilidad na ang mga pag-aaral, pag-aaral ng algorithm at minumungkahi ng isang paraan para sa mga atake. Panghuli naming ibigay isang kasangkapan na nagpapatupad ng mga atake at kasalukuyang resulta tungkol sa tinatayang pagkakataon sa basagin ang sistema. Tandaan na habang ang ibang bangko seguridad kaugnay na algorithm (iba pang mga PIN format tulad ng IBM PIN o card pagpapatunay lagda tulad ng CVV o CVC) ay katulad sa VISA PIN, ang parehong analysis ay maaaring tapos na mapagtutubuan halos ang parehong resulta at pagpapalagay.
VISA PVV algorithm
Isa sa mga pinaka-karaniwang PIN algorithm ay ang VISA PIN Verification Value (PVV). Ang customer ay bibigyan ng isang PIN at ng magnetic maguhitan card. Naka-encode sa magnetic guhit ay isang apat na digit na numero, na tinatawag na PVV. Ang bilang na ito ay isang cryptographic pirma ng PIN at ng iba pang mga data na may kaugnayan sa card. Kapag ang isang gumagamit ay nagpasok ng kanyang PIN sa ATM mababasa ang magnetic maguhitan, encrypts at nagpapadala ng lahat ang impormasyon na ito sa isang central computer. May isang pagsubok PVV ay computed gamit ang mga customer na ipinasok PIN at ang card na impormasyon na may isang cryptographic algorithm. Ang paglilitis PVV ay inihambing sa PVV na naka-imbak sa card, kung ang mga ito ay tumutugma sa central computer bumalik sa ATM pahintulot para sa transaksyon. Tingnan sa mas maraming mga detalye.
Ang paglalarawan ng PVV algorithm ay matatagpuan sa loob ng dalawang dokumento na naka-link sa nakaraang pahina. Sa buod na ito ay binubuo ng encryption ng isang 8 byte (64 bit) string ng data, na tinatawag na Transformed Security Parameter (TSP), na may des algorithm (DEA) sa Electronic Code Book mode (ECB) gamit ang isang lihim na 64 bit key. Ang PVV ay nagmula sa output ng encryption proseso, na kung saan ay isang 8 byte string. Ang apat na numero ng PVV (mula sa kaliwa papunta sa kanan) ay tumutugma sa mga unang apat na mga decimal na numero (mula sa kaliwa papunta sa kanan) ng output mula des kapag isinaalang-alang bilang isang 16 na karakter hexadecimal (16 bit x 4 = 64 bit) string. Kung walang mga apat na decimal na numero sa pagitan ng mga 16 hexadecimal character pagkatapos ay ang PVV ay nakumpleto na kinuha (mula sa kaliwa papunta sa kanan) hindi decimal karakter at decimalizing mga ito sa pamamagitan ng paggamit ng conversion A-> 0, B-> 1, C-> 2, D -> 3, E-> 4, F-> 5. Narito ang isang halimbawa:
Output mula Des: 0FAB9CDEFFE7DCBA
PVV: 0975
Ang mga istratehiya ng pag-iwas sa decimalization ng laktaw character hanggang sa apat na mga decimal na numero ay matatagpuan (na ang mangyayari sa halos lahat ng mga oras na kami ay makikita sa ibaba) ay lubhang matalino dahil ito avoids isang mahalagang bias sa pamamahagi ng mga bilang na ito ay napatunayan na nakamamatay para sa ibang sistema, kahit na ang epekto sa sistemang ito ay marami na mas mababa. Tingnan din ang isang problema sa mga kaugnay na hindi nag-aaplay sa VISA PVV.
Ang TSP, makikita bilang 16 hexadecimal character (64 bit) string, ay binuo (mula sa kaliwa papunta sa kanan) sa 11 rightmost numero ng PAN (ang numero ng card) hindi kasama ang huling digit (check digit), isang digit na mula sa 1 hanggang 6 na na kung saan pinipili ang lihim encrypting susi at sa wakas sa apat na numero ng PIN. Narito ang isang halimbawa:
PAN: 1234 5678 9012 3445
Key selector: 1
PIN: 2468
TSP: 5678901234412468
Obviously ang problema ng mga paglabag VISA PIN ay binubuo sa paghahanap ang susi para sa mga lihim na encrypting Des. Ang pamamaraan na ito ay para sa gumawa ng isang malupit na puwersa ng mga paghahanap ang susi space. Tandaan na hindi ito ang tanging paraan, isa ay subukan upang makahanap ng kahinaan sa DEA, maraming tried, ngunit ito pa rin ang mga lumang pamantayan sa malawak na gamitin (ngayon ay papalitan ng AES at RSA, bagaman). Ito ay nagpapakita na ito ay sapat na upang malusog na astig lakas ay ang tanging paraan viable (may ilang mga mas mahusay na atake ngunit hindi praktikal sa aming kaso, para sa isang buod makita LASEC talaan at para sa marumi tingnan ang mga detalye ng Biham & Shamir 1990, Biham & Shamir 1991, Matsui 1993, Biham & Biryukov 1994 at Heys 2001).
Ang susi selector digit was tunay malamang nagpasimula upang masakop ang posibilidad ng isang susi sa kompromiso. Sa kaso na lamang sila sa mga isyu na may bagong card gamit ang ibang susi selector. Mas lumang cards ay maaaring substituted na may mga bago o lamang ang ATM ay maaari transparently sumulat ng isang bagong PVV (kaukulang sa bagong susi at mapanatili ang parehong PIN) sa susunod na pagkakataon ang mga customer na gumagamit ng kanyang card. Para sa iling ng seguridad ang lahat ng mga gumagamit ay dapat na hingin sa iyo na baguhin ang kanilang mga PINs, subalit ito ay nakakahiya para sa bangko upang ipaliwanag ang dahilan, kaya ang tunay malamang sila ay hindi makagawa ng ganoong kahilingan.
Inihahanda ang mga atake
Isang malupit na puwersa na atake ay binubuo sa encrypting isang TSP may kilala PVV gamit ng lahat ng posibleng encrypting keys at ihambing ang bawat makuha PVV sa kilala PVV. Kapag ang pagtutugma ay natagpuan namin ang isang kandidato key. Ngunit kung gaano karami ang mga key na namin na subukan? Tulad ng sinabi namin sa itaas ng mga susi ay 64 bit mahaba, ito ay nangangahulugan na namin na subukan ang 2 ^ 64 keys. Subalit ito ay hindi totoo. Talagang lamang 56 bits ay epektibo sa des keys dahil isa bit (ang hindi bababa sa makabuluhang) sa labas ng bawat octet ay kasaysayan reserved bilang isang checksum para sa iba; sa pagsasanay ng mga 8 bits (isa para sa bawat isa sa mga octet 8) ay winalang-bahala.
Kaya ang des space key ay binubuo ng 2 ^ 56 keys. Kung kami na subukan ang lahat ng mga ito ay mga susi namin mahanap ang isa at isa lamang tugma, nararapat sa ang bangko lihim susi? Tiyak na hindi. Kami ay makakuha ng maraming mga matching keys. Ito ay dahil ang PVV ay lamang ng isang maliit na bahagi (ang isang ika-apat na) ng des output. Bukod dito ang PVV ay degenerated dahil ang ilan ng mga numero (ang mga pagitan ng 0 at 5 pagkatapos ng huling, makikita mula sa kaliwa papunta sa kanan, numero sa pagitan ng 6 at 9) ay maaaring nanggaling mula sa isang decimal digit o mula sa isang decimalized hexadecimal digit ng des output. Kaya maraming mga key ay gumawa ng isang des output na magbubunga sa parehong matching PVV.
Pagkatapos ay kung ano ang maaari naming gawin upang hanapin ang tunay na susi sa gitna ng mga iba pang mga false positive keys? Lamang na kami ay sa encrypt ng pangalawang ibang TSP, na kilala din sa PVV, ngunit ang paggamit lamang ng mga kandidato susi na ibinigay ng isang positibong na tumutugma sa unang TSP-PVV pares. Gayunman ay walang garantiya na hindi kami makakuha muli ng maraming false positives kasama ang tunay na susi. Kung gayon, kami ay nangangailangan ng isang ikatlong TSP-PVV pares, ulitin ang proseso at iba pa.
Bago namin simulan ang aming mga atake na namin na malaman kung gaano karami ang TSP-PVV pares namin ang kailangan mo. Para sa mga na kami ay upang makalkula ang mga pagkakataon para sa isang random des output sa ani ng isang matching PVV sa pamamagitan lamang ng pagkakataon. Mayroong ilang mga paraan upang kalkulahin ang bilang na ito at dito ako ay gagamit ng isang simpleng diskarte madaling maunawaan ngunit kung saan ay nangangailangan ng ilang background sa matematika ng mga bagay na maaaring mangyari.
Ang isang bagay na maaaring mangyari maaari palaging makikita bilang ang ratio ng makabubuti mga kaso ng mga posibleng kaso. Sa aming mga problema sa bilang ng posibleng mga kaso ay ibinigay sa pamamagitan ng permutasyon ng 16 mga sangkap (ang 0 sa F hexadecimal digit) sa isang grupo ng 16 sa kanila (ang 16 hexadecimal na numero ng des output). Ito ay ibinigay sa pamamagitan ng 16 ^ 16 ~ 1,8 * 10 ^ 19 na ng kurso coincides sa 2 ^ 64 (iba't-ibang mga numero ng 64 bits). Sa hanay na ito ng mga numero ay maaaring ihiwalay sa limang kategorya:
Mga may hindi bababa sa apat na mga decimal na numero (0 hanggang 9) sa pagitan ng mga 16 hexadecimal numero (0 sa F) ng des output.
Mga may eksaktong lamang tatlong mga decimal na numero.
Mga may eksaktong lamang ng dalawang decimal na numero.
Mga may eksaktong isa lamang decimal digit.
Mga walang decimal na numero (ang lahat sa pagitan ng A at F).
Let's kalkulahin kung gaano karaming mga numero mahulog sa bawat kategorya. Kung namin label ang 16 hexadecimal numero ng des output bilang X1 sa X16 pagkatapos ay maaari naming label na ang unang apat na mga decimal na numero ng anumang naibigay na bilang ng mga unang kategorya bilang Xi, Xj, Xk at Xl. Ang bilang ng mga iba't-ibang mga kumbinasyon na may profile na ito ay ibinigay sa pamamagitan ng ang produkto 6 i-1 * 10 * 6j-i-1 * 10 * 6k-j-1 * 10 * 6 lk-1 * 10 * 1616-l na kung saan ang 6 ' s dumating mula sa bilang ng mga posibilidad para sa isang A to F digit, ang 10's nanggaling mula sa mga posibilidad para sa isang 0 hanggang 9 digit na, at ang 16 ay mula sa mga posibilidad para sa isang 0 sa F digit. Ngayon ang kabuuang numero sa unang kategorya ay lamang na ibinigay sa pamamagitan ng pagbubuo ng produktong ito sa ako, j, k, l mula sa 1 hanggang 16 ngunit may i <j <k <L. Kung ilang matematika trabaho makikita ninyo ang mga ito ay katumbas sa produkto ng 104 / 6 na may higit sa pagbubuo ako 4-16 ng (i-1) * (i-2) * (i-3) * 6i-4 * 16 16-i ~ 1,8 * 1019.
Analogously ang bilang ng mga kaso sa pangalawang kategorya ay ibinigay sa pamamagitan ng pagbubuo sa ako, j, k mula sa 1 hanggang 16 na may i <j <k ng produkto 6i-1 * 10 * 6j-i-1 * 10 * 6k-j -1 * 10 * 616-k na kung saan ikaw ay maaaring gumawa ito upang maging 16! / (3! * (16-13)!) * 103 * 6 13 = 16 * 15 * 14 / (3 * 2) * 103 * 613 = 56 * 104 * 613 ~ 7,3 * 1015. Katulad din para sa ikatlong kategorya na namin ang pagbubuo sa ako, j mula sa 1 hanggang 16 na may i <j ng 6 i-1 * 10 * 6j-i-1 * 10 * 616-j na katumbas sa 16! / (2! * (16-14)!) * 102 * 614 = 2 * 103 * 615 ~ 9,4 * 1014. Muli, para sa ika-apat na kategorya na namin ang pagbubuo higit ako mula sa 1 hanggang 16 ng 6i-1 * 10 * 616-i = 160 * 615 ~ 7.5 * 1013. At sa wakas ang halaga ng mga kaso sa ikalimang kategorya ay ibinigay sa pamamagitan ng permutasyon ng anim na mga sangkap (A sa F digit) sa isang grupo ng 16, iyon ay, 616 ~ 2,8 * 1012.
Umaasa ako na sinundan mo ang mga kalkulasyon ng hanggang sa puntong ito, ang mga matitigas na bahagi ay tapos na. Ngayon, bilang patunay na ang lahat ng bagay ay karapatan na maaari mong kabuuan ng bilang ng mga kaso sa 5 kategorya at makita ang mga ito ay katumbas ng kabuuang bilang ng posibleng mga kaso namin kinakalkula bago. Gawin ang mga operasyon ng paggamit ng 64 bit na numero o rounding (para sa mga floats) o overflow (para sa mga integers) error ay hindi nagpapahintulot sa inyo na makuha ang eksaktong resulta.
Hanggang sa ngayon kami ay kalkulahin ang bilang ng posibleng mga kaso sa bawat isa sa mga limang kategorya, ngunit kami ay interesado sa pagkuha ng bilang ng mga kaso sa halip na makabubuti. Ito ay tunay madali sa kunin ang huli mula sa dating bilang na ito ay lamang ng pag-aayos ng mga kombinasyon ng apat na decimal na numero (o ang mga kinakailangang hexadecimal digit kung walang mga apat na decimal na numero) ng PVV sa halip ng pagpapaalam sa kanila libre. Sa pagsasanay na ito ay nangangahulugan na sa pamamagitan ng pagpapaandar ng 10's sa mga formula sa itaas sa 1 at ang mga kinakailangang halaga ng 6's sa 1's kung walang mga apat na decimal na numero. Iyon ay, tayo may sa paghati-hatiin ang unang resulta sa pamamagitan ng 104, ang pangalawang ng isa sa pamamagitan ng 103 * 6, ang pangatlong isa sa pamamagitan ng 102 * 62, ang ika-apat na isa sa pamamagitan ng 10 * 63 at ang ikalima ng isa sa pamamagitan ng 64. Pagkatapos ay ang bilang ng mga kaso makabubuti sa limang kategorya ay humigit-kumulang sa 1.8 * 1015, 1.2 * 1012, 2.6 * 1011, 3.5 * 1010, 2.2 * 109 naaayon.
Ngayon namin na kumuha ng kung ano ay ang bagay na maaaring mangyari para sa isang des output upang tumugma sa isang PVV ng pagkakataon. Kami lang bang idagdag ang limang numero ng mainam na kaso at hatiin ito sa pamamagitan ng ang kabuuang bilang ng posibleng mga kaso. Kapag ginawa ito makuha namin na ang mga bagay na maaaring mangyari ay humigit-kumulang sa 0,0001 o isa sa labas ng sampung libong. Ito ba ay kakaiba na ito ng mabuti bilugan resulta? Hindi sa lahat, makatarungan may a tumingin at ang numero ng aming kinakalkula sa itaas. Ang unang kategorya dominates sa pamamagitan ng ilang mga order ng magnitude ang bilang ng mga napapanahon at posibleng kaso. Ito ay sa halip intuitive gaya ito tila malinaw na ito ay hindi tunay hindi pagkakaroon ng apat na decimal na numero (10 mga pagkakataon sa labas ng bawat digit na 16) sa mga 16 hexadecimal digit. Nakita natin noon na ang relasyon sa pagitan ng mga bilang ng posibleng mga kaso at sang-ayon sa unang kategorya ay isang dibisyon ng 10 ^ 4, na kung saan ang aming mga resulta p = 0,0001 ay mula.
Ang aming layunin para sa lahat ng mga kalkulasyon ay upang malaman kung gaano karami ang TSP-PVV pares na kailangan namin upang magsagawa ng isang matagumpay na taong malupit na puwersa na atake. Ngayon namin na kalkulahin ang inaasahang bilang ng mga false positives sa isang unang search: ito ay ang bilang ng mga pagsubok na beses ang mga pagkakataon para sa isang random na false positive, ibig sabihin t * p kung saan t = 2 ^ 56, ang laki ng mga susi space. Ang mga halaga sa humigit-kumulang sa 7.2 * 10 ^ 12, sa halip ng isang malaking numero. The expected number of false positives in the second search (restricted to the positive keys found in the first search) will be (t * p) * p, for a third search will be ((t * p) * p) * p and so on. Thus for n searches the expected number of false positives will be t * p^n.
We can obtain the number of searches required to expect just one false positive by expressing the equation t * p^n = 1 and solving for n. So n equals to the logarithm in base p of 1/t, which by properties of logarithms it yields n = log(1/t)/log(p) ~ 4.2. Since we cannot do a fractional search it is convenient to round up this number. Therefore what is the expected number of false positives if we perform five searches? It is t * p^5 ~ 0.0007 or approximately 1 out of 1400. Thus using five TSP- PVV pairs is safe to obtain the true secret key with no false positives.
The attack
Once we know we need five TSP- PVV pairs, how do we get them? Of course we need at least one card with known PIN , and due to the nature of the PVV algorithm , that’s the only thing we need. With other PIN systems, such as IBM, we would need five cards, however this is not necessary with VISA PVV algorithm . We just have to read the magnetic stripe and then change the PIN four times but reading the card after each change.
It is necessary to read the magnetic stripe of the card to get the PVV and the encrypting key selector. You can buy a commercial magnetic stripe reader or make one yourself following the instructions you can find in the previous page and links therein. Once you have a reader see this description of standard magnetic tracks to find out how to get the PVV from the data read. In that document the PVV field in tracks 1 and 2 is said to be five character long, but actually the true PVV consists of the last four digits. The first of the five digits is the key selector. I have only seen cards with a value of 1 in this digit, which is consistent with the standard and with the secret key never being compromised (and therefore they did not need to move to another key changing the selector).
I did a simple C program, getpvvkey.c, to perform the attack . It consists of a loop to try all possible keys to encrypt the first TSP, if the derived PVV matches the true PVV a new TSP is tried, and so on until there is a mismatch, in which case the key is discarded and a new one is tried, or the five derived PVVs match the corresponding true PVVs, in which case we can assume we got the bank secret key, however the loop goes on until it exhausts the key space. This is done to assure we find the true key because there is a chance (although very low) the first key found is a false positive.
It is expected the program would take a very long time to finish and to minimize the risks of a power cut, computer hang out, etc. it does checkpoints into the file getpvvkey.dat from time to time (the exact time depends on the speed of the computer, it’s around one hour for the fastest computers now in use). For the same reason if a positive key is found it is written on the file getpvvkey.key. The program only displays one message at the beginning, the starting position taken from the checkpoint file if any, after that nothing more is displayed.
The DES algorithm is a key point in the program, it is therefore very important to optimize its speed. I tested several implementations: libdes, SSLeay, openssl, cryptlib, nss, libgcrypt, catacomb, libtomcrypt, cryptopp, ufc-crypt. The DES functions of the first four are based on the same code by Eric Young and is the one which performed best (includes optimized C and x86 assembler code). Thus I chose libdes which was the original implementation and condensed all relevant code in the files encrypt.c (C version) and x86encrypt.s (x86 assembler version). The code is slightly modified to achieve some enhancements in a brute force attack : the initial permutation is a fixed common steep in each TSP encryption and therefore can be made just one time at the beginning. Another improvement is that I wrote a completely new setkey function (I called it nextkey) which is optimum for a brute force loop.
To get the program working you just have to type in the corresponding place five TSPs and their PVVs and then compile it. I have tested it only in UNIX platforms, using the makefile Makegetpvvkey to compile (use the command “make -f Makegetpvvkey”). It may compile on other systems but you may need to fix some things. Be sure that the definition of the type long64 corresponds to a 64 bit integer. In principle there is no dependence on the endianness of the processor. I have successfully compiled and run it on Pentium-Linux, Alpha-Tru64, Mips-Irix and Sparc-Solaris. If you do not have and do not want to install Linux (you don’t know what you are missing ;-) you still have the choice to run Linux on CD and use my program, see my page running Linux without installing it.
Once you have found the secret bank key if you want to find the PIN of an arbitrary card you just have to write a similar program (sorry I have not written it, I’m too lazy :) that would try all 10^4 PINs by generating the corresponding TSP, encrypting it with the (no longer) secret key, deriving the PVV and comparing it with the PVV in the magnetic stripe of the card . You will get one match for the true PIN . Only one match? Remember what we saw above, we have a chance of 0.0001 that a random encryption matches the PVV . We are trying 10000 PINs (and therefore TSPs) thus we expect 10000 * 0.0001 = 1 false positive on average.
This is a very interesting result, it means that, on average, each card has two valid PINs: the customer PIN and the expected false positive. I call it “false” but note that as long as it generates the true PVV it is a PIN as valid as the customer’s one. Furthermore, there is no way to know which is which, even for the ATM; only customer knows. Even if the false positive were not valid as PIN , you still have three trials at the ATM anyway, enough on average. Therefore the probability we calculated at the beginning of this document about random guessing of the PIN has to be corrected. Actually it is twice that value, ie, it is 0.0006 or one out of more than 1600, still safely low.
Results
It is important to optimize the compilation of the program and to run it in the fastest possible processor due to the long expected run time. I found that the compiler optimization flag -O gets the better performance, thought some improvement is achieved adding the -fomit-frame-pointer flag on Pentium-Linux, the -spike flag on Alpha-Tru64, the -IPA flag on Mips-Irix and the -fast flag on Sparc-Solaris. Special flags (-DDES_PTR -DDES_RISC1 -DDES_RISC2 -DDES_UNROLL -DASM) for the DES code have generally benefits as well. All these flags have already been tested and I chose the best combination for each processor (see makefile) but you can try to fine tune other flags.
According to my tests the best performance is achieved with the AMD Athlon 1600 MHz processor, exceeding 3.4 million keys per second. Interestingly it gets better results than Intel Pentium IV 1800 MHz and 2000 MHz (see figures below, click on them to enlarge). I believe this is due to some I/O saturation, surely cache or memory access , that the AMD processor (which has half the cache of the Pentium) or the motherboard in which it is running, manages to avoid. In the first figure below you can see that the DES breaking speed of all processors has more or less a linear relationship with the processor speed, except for the two Intel Pentium I mentioned before. This is logical, it means that for a double processor speed you’ll get double breaking speed, but watch out for saturation effects, in this case it is better the AMD Athlon 1600 MHz, which will be even cheaper than the Intel Pentium 1800 MHz or 2000 MHz.
In the second figure we can see in more detail what we would call intrinsic DES break power of the processor. I get this value simply dividing the break speed by the processor speed, that is, we get the number of DES keys tried per second and per MHz. This is a measure of the performance of the processor type independently of its speed. The results show that the best processor for this task is the AMD Athlon, then comes the Alpha and very close after it is the Intel Pentium (except for the higher speed ones which perform very poor due to the saturation effect). Next is the Mips processor and in the last place is the Sparc. Some Alpha and Mips processors are located at bottom of scale because they are early releases not including enhancements of late versions. Note that I included the performance of x86 processors for C and assembler code as there is a big difference . It seems that gcc is not a good generator of optimized machine code, but of course we don’t know whether a manual optimization of assembler code for the other processors (Alpha, Mips, Sparc) would boost their results compared to the native C compilers (I did not use gcc f
