[HARDWARE] Just Courious......
skoron at netor.gr
Fri Sep 17 21:06:54 EDT 1999
Grettings to all,
Taking into account an e-mail to the list from someone in d.net (sorry i don't
have the name) it seems that even if the board is build the chances of modifing
the clients to work with it are rather slim...
Its better, if there is enough interest to start planning a device for some other
competition or for...general use.
Anyway here are my thoughts on the subject on a rather large e-mail...
A disclaimer first....
My knowledge on crypto is rather 101 level (i work with mcu's and embeded apps)
so i am apologizing in advance for any mistakes.
For the last few months i have been playing around with the idea of using
microcontrollers in parallel to do crypto cracking.
I studied the "deep crack" and read several other papers i found on the subject
and decided to give it a try...
Since the RC5 contenst has started and it (correctly) seemed that there was no
much interest or resources from d.net to create "custom" clients, i decided to
start working for future "competitions" and namely CS.
I have implemented a rather anoptimized code for the CS for the 90s2343 AVR
device. This is an 8pin device with 2K program memory 64 bytes of ram and is In
Although my code is much faster (about 30% in clock cycles) than the
implementation on other mcu's the CS authors mention in their paper, the AVR
(overclocked from 10Mhz to 12Mhz) performace ment that i need it about 100.000 pcs
to get half of deep crack's keyrate so i "stopped" the efford... (The low keyrate
is due to the fact that CS requires as many cycles to set the encryption keys as
it requires to do the actual encryption. It was designed like this to make broute
force attacks more difficult)
One of the reasons i stopped was that i could not find any "test results" to
check against the performace of the AVR and see if it worth doing something and
that the number of AVR's required was out of my economics :-)
Then i started looking at FPGA's but it seemed that high gate count (which equals
high cost) and design complexity made rather difficult to implement an easy
re-programmable design using only FPGA's.
The solution for Do It Yourself ,low cost, re-programmable, easy to expand and
rather fast cracking machine seems to be a hybrid mcu+smaller FPGA.
New generation of FPGA's are In circuit programmable and are using a "common"
program language Jtag, which means that is rather easy to update them for other
After a short pause, i started again working on the subject and create the specs
and a protoype of parallel mcu cracker.
This idea/desing is rather simple in consept.
All commands/data comes from a "server" (PC) using a serial bus (Rs485). The
server talks to "node controllers" assigning packets of keys to try and checking
them from time to time for results. There can be up to 128 "node controllers" on a
single RS485 line (according to rs485 specs).
Its node controller can have up to 128 "Cracking engines" attached also through
Rs485. Its node controller splits the keys it has to try into packets and sends
them to the "cracking engines" who do the job. The node controller checks the
"cracking engines" from time to time for results and retrieves them.
A "cracking engine" can be anything, from a PC/Mac to a board full of mcu's, to a
board full of FPGA's. Eatch "cracking engine" has a controller whos job is to
communicate with the node controller and thus "hidding" the hardware details of
the cracking engine
The protocol is a request/reply protocol and since packets of keys are send (the
size of which can be set) there is little I/O delay.
The protocol works like this...
During power up server "pings" ND1...to ND128 to see how many are connected
Server sends a packet to ND 1 (Node Contoller 1)
ND Acks the packet
(Server continues sending packets to the rest of the ND's)
The ND1 "pings" CE1.. to CE128 (Cracking Engine1 to 128) to see how many are
ND1 sends packet to CE1
CE1 Acks the packet and starts...cracking
ND1 sends the rest of the packets
After a specified time interval ND1 checks CE1 for results.
If any results are found (the cracking engine checks the first 8 bytes of the
cipher string, if it finds a match it stores the key) the key(s) are send to ND1.
(ND1 keeps checking the rest of the CE's)
Server checks ND1 for results, retieves the key(s) that match and tries to see if
the whole cypher text matches
>From the above i have constructed only "Cracking engine".
It uses an AVR 90s8515 with 8K of external ram (in addition to the 2K of interal)
for storring found keys and program updates.
64 (12Mhz) 90s2343 are supposed to do the actual cracking and are connected to the
craking engine's controller through SPI interface, which is used also for
I have not implemented the CS algorithm, neither i finished the protocol, due to
summer and some other mishapps. I was about to put the whole thing on the
backburner when the list came back to life... :-)
Now regarding to cost, cracking speeds etc...
When Jasper Monstead said he implemented the RC5 on the AVR i asked him for more
info and told me that his code was doing approx 10kkeys. Assuming that he was
using a 12 mhz AVR, this on 64 card would translate to 640kkeys.
Cost of the card (hardware only)
64 pcs 90s2343 x 1,5$ = 96
64 pcs 12 Mhz resonators x 0,5$ = 32
1 pc 90s8515 x 5$ = 5
1 prototype board designed inhouse 30$ = 30
Development cost 0 (It was a interesting project to do :-)
Well does it worth it ? You have to tell me that as i don't have a clue what a
good key rate should be...
One last note.
If instead of the AVR we use the SCENIX mcu at 50Mhz (there is 100Mhz variant
also) since this is also a RISC with most instructions single cycle, the
price/performace ratio will be a bit better for the 50Mhz (50Mhz SCENIX approx 5$
per pcs at 100 pcs order) and much much better at 100Mhz... Any takers ?
Please understand that the above are ideas and hands on implementation of some of
the ideas so a final workign system might require modifications...
Ideas, congratulations :-) and critisism :-( are welcome
Matthew Smart wrote:
> I don't see much point in talking about money until
> someone has a design and a working, demonstrable prototype.
> Not to mention the support of the distributed.net code gurus
> for the software/network front end.
> > -----Original Message-----
> > From: owner-hardware at lists.distributed.net
> > [mailto:owner-hardware at lists.distributed.net]On Behalf Of mRgOBLIN
> > Sent: Friday, September 17, 1999 10:42 AM
> > To: hardware at lists.distributed.net
> > Subject: Re: [HARDWARE] Just Courious......
> > Luke Elliott wrote:
> > > Alright, well lets get a list of guys who would be willing to buy these
> > > things together, and pull together a fund for this guy to see
> > whether or not
> > > he could do it.
> > >
> > > I have one other friend who would be interested in getting a
> > ton, we are in
> > > a team together, and we want to crack a hell of a lot of code.
> > >
> > > Let me know,
> > > Luke
> > >
> > > ______________________________________________________
> > > Get Your Private, Free Email at http://www.hotmail.com
> > > --
> > > To unsubscribe, send 'unsubscribe hardware' to
> > majordomo at lists.distributed.net
> > Well I would be interested but I would like some performance per
> > Dollar specs
> > before I parted wif my <cough> hard earned cash <cough >
> > mRgOBLIN
> > --
> > To unsubscribe, send 'unsubscribe hardware' to
> > majordomo at lists.distributed.net
> To unsubscribe, send 'unsubscribe hardware' to majordomo at lists.distributed.net
For more info on AVR's, GPS, and GSM visit my web page
To unsubscribe, send 'unsubscribe hardware' to majordomo at lists.distributed.net
More information about the Hardware