Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

SHA-1 Cracking On A Budget

Zonk posted more than 6 years ago | from the putting-the-pieces-together dept.

92

cloude-pottier writes "An enterprising individual went on eBay and found boards with more than half a dozen Virtex II Pro FPGAs, nursed them back to life and build a SHA-1 cracker with two of the boards. This is an excellent example of recycling, as these were originally a part of a Thompson Grass Valley HDTV broadcast system. As a part of the project, the creator wrote tools designed to graph the relationships between components. He also used JTAG to make reverse engineering the organization of the FPGAs on the board more apparent. More details can be seen on the actual project page."

cancel ×

92 comments

Sorry! There are no comments related to the filter you selected.

Frgnnn psmmmmt (0, Offtopic)

Helen Keller (842669) | more than 6 years ago | (#20432471)

Mneh!

crack this (-1, Troll)

Anonymous Coward | more than 6 years ago | (#20432481)

(_l_)

Re:crack this (-1, Troll)

JonathanR (852748) | more than 6 years ago | (#20432491)

(_/\_)

For the uninitiated... (5, Informative)

MollyB (162595) | more than 6 years ago | (#20432487)

If this story is hard to understand (was for me), then a comment following TFA might be useful, if you don't/didn't read that far:

5. FPGA - field programmable gate arrays are sort of like reconfigurable circuitry - they can be programmed to perform complex computations in one giant "step", rather than as a sequence of instructions (how a general purpose cpu like the pentium operates).

This makes them fairly pointless for general computing, but when you need to crunch a bunch of numbers in the same way over and over, they can REALLY outperform a general cpu. Usually these are used to manipulate audio / video data streams in real time (the original purpose for the FPGAs used in this project) - but recently people have started using them to brute-force try to crack an encryption scheme. Where a general purpose cpu might take upwards of 40 clock cycles to check one possible answer, each of the FPGAs in this system can check at least one answer PER clock cycle.

This guy pulled a bunch of FPGA systems out of some (defective?) HDTV video processing systems - reverse engineered exactly how everything was wired together, reprogrammed the FPGAs to do SHA-1 hash cracking rather than HDTV video processing, and added some usb control circuitry so the system could take commands from / return results to a pc.

One could use this same board setup to do any sort of massively parallel data processing, but right now the system isn't wired up to really feed large amounts of data into / out of the system in real time. He can get away with that as hash cracking results are fairly small and infrequent, so the limited means he has for getting "answers" out of the system isn't too much of a problem.

Posted at 4:39AM on Sep 1st 2007 by smilr
HTH.

Re:For the uninitiated... (1, Interesting)

Anonymous Coward | more than 6 years ago | (#20432753)

Yeah, except that for "general computing" they are not at all "fairly pointless". Also, the explanation seem to want to indicate that an FPGA can more or less only be programmed to perform number crunching, which is as off-track from the truth as can possibly be.

A more proper description of an FPGA would be "electronics simulator", as you can with an FPGA "program" resistors, caps, transistors, logic gates etc. with these, thus "program" an IC of your choice, or, for example, a Z80 or M68K core with accompanying graphics chips, sound, USB facilities, networking and more, and create an entire computer-on-a-chip. Just an example out of many.

Re:For the uninitiated... (3, Funny)

Poromenos1 (830658) | more than 6 years ago | (#20433667)

How about if you write an FPGA simulator program and simulate an FPGA simulating a CPU running your program? Will the universe implode?

Are the moderators retarded? (0)

Anonymous Coward | more than 6 years ago | (#20434967)

"+4, Interesting"? This is obviously a joke. And a pretty terrible one at that.

Sheesh.

Re:For the uninitiated... (1)

ndevice (304743) | more than 6 years ago | (#20435211)

it would give new meaning to "turtles all the way down"

Re:For the uninitiated... (0)

Anonymous Coward | more than 6 years ago | (#20435317)

Yes, "all the way down" would be three of them.

It's mainly logic, not analogue parts (5, Informative)

Space cowboy (13680) | more than 6 years ago | (#20433879)

There are some FPGA's that can control their output impedance on pins, but an FPGA is really for digital electronics - you're using 4-way look-up tables to emulate arbitrary 4-input logic-gates for the most (99.99%) part. I've seen genetic-algorithms produce capacitance-based designs where unconnected circuits affect each other due to analogue effects, but not humans. We tend to stick to the straight and narrow...

An FPGA really is conceptually very simple, and they're not hard to "program" either... Contrived example:

Verilog design to add/subtract 2 numbers (you'd never do this, but...)

module addsub (a, b, addnsub, result);
        input [7:0] a;
        input [7:0] b;
        input addnsub;
        output [8:0] result;
        reg [8:0] result;
 
        always @(a or b or addnsub)
        begin
            if (addnsub)
                result = a + b;
            else
                result = a - b;
        end
    endmodule
Compare that to a K&R "C" routine to do the same thing...

void addsub(a, b, addnsub, result)
short a;
short b;
unsigned char addnsub;
short *result;
 
{
    if (addnsub)
        *result = a + b;
    else
        *result = a - b;
}
In both cases, of course, you'd just use the 'if...else...' part, but I wanted to show more language structure...

The key thing to remember is that in C, all things happen serially, unless you arrange otherwise with threading libraries. In Verilog, any block beginning with 'always @' happens in parallel with every other 'always @' block. Once you've mentally-mapped the concept of vast numbers of threads to the way hardware works, any competent multi-threaded programmer can become a competent hardware engineer.

Of course, there's "guru stuff" in there as well (as much as you want, trust me :-), you don't get world-beating overnight, but it's relatively easy to get the 80% solution, and that might be just fine. Eking out the last 20% is where it gets hard, as you have to understand the internal structure of the LUTs, and how they interact with the carry-chain, what the LUT->LUT delay can be useful for etc. None of this is at all relevant unless you're missing your timing on a critical circuit (eg: you need 133MHz so your DDR2 SDRAM can work, but the synthesis tools (equivalent to a compiler) only deliver 125 MHz for your design).

The 'always@' part is the hint of just where the power lies. *Everything* can happen in parallel, so you can build pipelines (like CPU's are pipelined today) into your logic, thus reducing the time taken per step (while taking multiple steps), thus increasing your clock rate. The benefit of course is that although the *first* result comes out in the same time, every clock thereafter, you'll also get a result.

I wrote a JPEG decoder a couple of years or so ago, running at ~130MHz. That doesn't sound much, but that comes to ~65 MPixels/second because of the pipelining. Looking at the SSE-optimised intel libraries, a CMYK422->CMYK baseline decode (which is what the FPGA was doing) takes 371 clocks/pixel. The intel chip I was comparing to was a 3.6GHz P4, meaning it could do ~9.7 Mpixels/second. For motion-jpeg that's the difference between decoding SD frames (for the P4) and decoding HD frames (for the FPGA)...

So, FPGAs tend to run slowly (relative to today's CPUs) but can exploit parallelism in ways CPUs just can't, but of course for serial processing, you can't beat a traditional CPU. FPGA's are also far more flexible... I'm currently designing an FPGA-based VMEbus card for an Atari TT I bought on Ebay (I lusted after one when I was young, what can I say? :-) that will drive a 1280x1024 VGA display and provide ethernet/USB....

Anyway, they're cool, they're not hard to get working, and they're cheap. I really don't understand why they're not more popular...

Simon

FPGA question... (2, Interesting)

Endymion (12816) | more than 6 years ago | (#20434593)

hmm... you seem to know a lot about FPGAs, so I'll ask you something I've been wondering for a while...

Coming from a traditional software end of things, I'm used to seeing "accelerating co-processors" available to do useful tasks much faster than the main CPU. I'm thinking not only the FPU (when it was a separate chip), but things like a modern GPU and such. Many of these have been slowly integrated back into the CPU as time has gone on, the FPU being the best example, so now it's something you can just call on with a special instruction.

From my understanding, FPGAs are mainly all generic logic blocks, arranged in fancy ways, and therefor are rather "generic" like the general CPU - you have to implement any fancy processing yourself.

My question is has anybody thought about putting fancy co-processing hardware local to the FPGA? I'm thinking some built-in FFT units and such that you could just include anywhere in your pipeline would be really useful, and might help that "timing critical" areas by having some common "higher level" functions computed in full hardware (ASIC?) speed.

Like, as a programmer, it sounds like it'd be cool to be able to buy an FPGA with built-in FFT, CRC/MD5/etc, maybe part of some encryption routines, etc to work with as common things that need to be accelerated.

Is this sane? Does it already exist and I just don't know about it? Is it totally incompatible with how FPGAs work?

Re:FPGA question... (3, Interesting)

Radicode (898701) | more than 6 years ago | (#20434681)

There are many libraries you can put on your FPGA. Some are open source, some costs A LOT. It's similar to a dll or a jar: you have an interface you bind to and you program your stuff around it. You can get modules to process FFTs, encryption, ethernet, VGA, sound, video, pretty much anything you can imagine. You can even use a CPU library to have a gereal cpu like your x86 and execute assembler instructions. You can even turn an FPGA into an old defunct cpu to repair an old electronic hardware. Amazing stuff!

Radicode

Re:FPGA question... (1)

Endymion (12816) | more than 6 years ago | (#20434721)

That all sounds wonderful... (and does make me want to try some FPGA programming - it sounds really cool) ...but that sounds like it's still implemented in the main programmable logic gates of the FPGA (that is, in "software"), like how a .so/.dll is great on a normal CPU, but is still just part of your program running.

I'm more thinking of a specific hardware piece, like an FPU co-processor. Something not re-programmable, but theoretically much faster for that specific task. It wouldn't make sense for a lot of things, but I'm thinking specific common number-crunching like checksums/FFT/etc that lots of people do could maybe work.

Re:FPGA question... (0)

Anonymous Coward | more than 6 years ago | (#20435379)

I think including stuff like an FFT DSP on an FPGA would kind of defeat the purpose of the FPGA. You can already get FFT DSP's, and can connect them to your custom FPGA. I'm not too familiar with the FPGA market, but I would imagine there are libraries for interfacing with the DSP available, at least if the DSP is popular.

Re:FPGA question... (0)

Anonymous Coward | more than 6 years ago | (#20438279)

Doesn't sound like folks really want to answer your question ;-)
To put it succinctly, yes, it has been thought of. The common parliance for what you are describing is a "hard macro", or a predefined piece of specific hardware laid out by the manufacturer. As you suggest, these can indeed be much faster than the general-purpose LUT-based architecture of an FPGA (and lower power, smaller die area, etc..). Currently, the kinds of things that are commonly included as hard macros are CPU cores (Xilinx, for example, will sell you a Virtex with an embedded PowerPC core), largish (18x18) multipliers, and many things to do with I/O (DDR controllers, very fast SerDes, etc..). Typically, the reason the particular things you describe (e.g. FFT) are not included as hard macros are because they would benefit a narrow slice of the customer base (i.e. those who wish to do the very specific implementation of the FFT (and there are *many*)) for a relatively large area overhead. This may end up being faster (higher clock speed) than the general-purpose fabric, but in many cases, this doesn't buy you much. If you're looking for sustained throughput, you're going to need to feed these monsters new data sets to FFT as fast as they can process them, and dispose of the "answers" just as quickly. If your general-purpose fabric cannot do this (due to the lower clock speed), what have you bought yourself? Again, there are wrinkles to this (your algorithm might be able to use 2 or more parallel data sources and sinks to provide and get rid of data faster, your data may be very bursty, etc..), but in general hard macros are most useful when very specific timing is absolutely critical (i.e. you're conforming to an I/O standard to talk to an external part), or when the critical path is so long for a *common operation* that obtaining a reasonable clock speed is unreasonable (e.g. wide single-cycle multipliers).

Hope this helps..

Re:FPGA question... (1)

Radicode (898701) | more than 6 years ago | (#20445879)

I understand what you mean. I think they have some processors like that. I'm thinking about that PCI card addon to process physics in games. I still think an FPGA is best for this job because once programmed, everything is actually "hard-wired"... it's not "software", so it's still almost as fast as a real circuit.

Radicode

Re:FPGA question... (3, Interesting)

Space cowboy (13680) | more than 6 years ago | (#20434781)

Well, common FPGA's are basically look-up tables surrounded by a sea of interconnect logic. The designer specifies the function of each LUT, and the connections between them using a language such as Verilog or VHDL. They're not "generic logic", they're defineable logic. Example: On a CPU, you have the 'add x,y' instruction - that's a chunk of logic on-chip. On an FPGA, that chunk of logic doesn't exist until you write a design that needs it.

You can buy (though I think they're very expensive) "IP cores", which are pre-packaged modules ready to plug-in-and-go. There are some free ones available as well. You may have to do more work to get the free ones to work [grin].

There are also built-in hard cores on modern FPGA's. You never used to be able to synthesize the statement "a = b * c;" in a verilog design, for example. Now that FPGA's have hardware multiplier blocks in them, it synthesises to a bunch of wires connecting up the LUTs to the built-in hardware. For the more-complex examples you suggest, it's best to implement them in logic, because an FFT (of a particular radix, input format (complex or real), and output requirements) is a very specific piece of hardware, and not generally useful to most customers.

You get multipliers, blocks of fast dual-port RAM, even entire processors (PPC) embedded into the FPGA fabric these days. Of course, you pay more for things like embedded CPUs... Funnily enough, a CPU is one of the easier things to write for an FPGA IMHO. You'll never get the speed of the FPGA fabric to match the hard-CPU core though...

To do what you're talking about though, you'd need a way to interface the FPGA to the PC - there's a freely available PCI core, so you'd then just need a card which had a PCI interface (there's one from Enterpoint [enterpoint.co.uk] for ~$150... Then you just need to link the PCI core to your own cores (FFT, whatever) and write software to offload any FFT's to your co-processor. Xilinx offer the "Embedded Development Kit" to make this easier (you have to pay for this, the other tools are free to download). I don't know if anyone has made the freely-available PCI core into an EDK module though...

Simon.

Simon

Re:FPGA question... (1)

Endymion (12816) | more than 6 years ago | (#20434811)

ok, thanks for the explanation...

It sounds like my idea is happening, but at a much lower level than I was thinking (like the multiply example you gave). I guess I'm still thinking of things at the wrong level (software, high level functions), when it's much more basic things that need to be accelerated.

The dual-port RAM interface makes a lot of sense - it'd be a lot nicer than trying to do it yourself with general purpose pins, I'd think.

Re:FPGA question... (1)

SrJsignal (753163) | more than 6 years ago | (#20435119)

Simon, While it's obvious you somewhat know what you're talking about, a LOT of your information is pretty dated. I use both super expensive top-of-the-line fpgas and middle of the road fpgas on a daily basis, so I'll just throw up a few "modern" corrections. With Xilinx (which is *strictly* the brand I use) you get MASSIVE amounts of IP cores that are configurable / synthesizable / simulatable. Granted this comes with their tools license, but you have to have one of those for any of the decently large fpga's anyway. The main things that you have to pay for are the newer IO interfaces like: 10GigE, PCIE, Infiniband. Almost all fpgas these days have some forms of specific logic (multipliers, etc) that helps with cleaner implementation of all kinds of math, the newest v4 and v5 chips have "DSP" chunks in them that make them approach true DSP chips in some ways. The EDK is strictly for developing for either the powerpc chips imbedded in the fpga, or for use on a "soft cpu" core, it sounds like you're mixing it up with using fpgas "embedded" in a pc, which is very common, and we do lots of that. The PCI interface is way simpler than writing the driver for the computer to interface with your card (in my opinion) I've had to modify the one that we use a lot, and that's not much fun. FPGAs are very common in generation 1 consumer electronics as well, typically they do that so they can work the bugs out in systems that are shippable, later they'll spin an asic to achieve even lower costs. For the stuff I work on, we never need large quantity so we always ship with fpgas. -SrJ

Re:FPGA question... (1)

Space cowboy (13680) | more than 6 years ago | (#20435431)

No, I'm aware of what you say, I just can't afford *any* of the commercial IP cores. I enquired about the cost of a JPEG core once, and was basically laughed at.

I'm coming from a different perspective, that's all. FPGA's are a hobby for me, nothing more. I can afford to spend a few hundred dollars on a kit board, but I'd never drop a few grand on a core... I'd either do it myself or make do without. I'll use webpack exclusively for development (since they dropped the in-between option, Foundation is far too expensive). I think the most I ever spent was $400 on an FX12 board, which I linked up to an HD video source.

As for the hard cores, I'm aware that pretty much all the modern FPGAs come with multipliers, but for hobbyists like me, a spartan-2 can be just as useful because it has 5v-tolerant i/o. You don't need to insert quickswitch chips, though I've just found out about SN74LVCC4245ADW chips, which may make life easier :)

I've just ordered a 3A kit from Xilinx, it's going to form the basis of my EDK-based VME/VGA/Ethernet board for my just-purchased TT. I was going to mention the DSP blocks (though some of that is marketing, IMHO... and I know what the EDK is for [grin]. There's just only so much I'm prepared to type on a /. post, so perhaps I wasn't clear...

Simon.

Re:FPGA question... (1)

petermgreen (876956) | more than 6 years ago | (#20443655)

There are also built-in hard cores on modern FPGA's. You never used to be able to synthesize the statement "a = b * c;" in a verilog design, for example. Now that FPGA's have hardware multiplier blocks in them, it synthesises to a bunch of wires connecting up the LUTs to the built-in hardware.
quartus 3 at least can synthisize a = b * c on a chip without a hardware multiplier, it takes a lot of logic cells though.

Re:It's mainly logic, not analogue parts (1)

MrAnnoyanceToYou (654053) | more than 6 years ago | (#20434879)

"He no longer has to worry about trying to be the baddest motherfucker in the world. The position is taken. The crowning touch, the one thing that really puts true world-class badmotherfuckerdom totally out of reach, of course, is the hydrogen bomb."

For some reason this passage comes to mind. I can now just learn to blow glass better; computers are never going to be my bag.

Re:It's mainly logic, not analogue parts (0)

Anonymous Coward | more than 6 years ago | (#20438287)

Its an awesome book. I'm reading now. :)

(Snow Crash by Neal Stephenson for anyone who doesn't know).

Re:It's mainly logic, not analogue parts (1)

InvalidError (771317) | more than 6 years ago | (#20435017)

4-input LUTs are on their way out, the migration towards LUT6 and beyond has begun in the current high-end FPGA families (Virtex5, Stratix II/III) and will most likely enter the volume-oriented ones (Spartan, Cyclone, etc.) soon. Single-LUT 4:1 muxes alone can enable drastic improvements in many designs.

As for FPGAs being cheap, all things are relative. There are ASICs out there for nearly any common application imaginable and these are often well under $50 and are usually designed by people who have extensively studied the specific problem the ASIC is intended to solve. Building an FPGA-based equivalent might cost $50 for the device itself but will most likely require extra external components like RAM or flash and will cost many times that much in R&D and potential patent problems.

FPGAs are great for prototyping, implementing glue logic and low-volume production. We are not seeing many FPGAs in stuff we buy because we buy mass-produced goods for which it is worth taking FPGA designs and re-spinning them into ASICs. Besides, most low-cost FPGAs do not support encrypted bitstreams so anyone could reverse-engineer the firmware and produce clones - not a problem with an ASIC respin.

Re:It's mainly logic, not analogue parts (1)

Space cowboy (13680) | more than 6 years ago | (#20435453)

As I mentioned above to a different poster, I think we're playing in different ballparks. The cheapest (and pretty-much useless for anything other than playing around on) V5 dev-kit I know of is ~$1000. That's an order of magnitude more than the cheapest S3A or S3E kits. 4-luts may be on their way out at the very high end, but they're definitely still around in the sort of things us mere mortals can buy/use.

Simon.

Re:It's mainly logic, not analogue parts (1)

InvalidError (771317) | more than 6 years ago | (#20437349)

All things are relative. IMO, the only thing that exists in FPGAs is a cheapest/smallest/slowest device that will fit a design with the required safety margins and futureproofing headrom. Most of the places I worked at where we used FPGAs were sold to Virtex: XC2V6000, XC2VP70, XC4FX100, XC4LX200 - since they were mostly doing ASIC prototyping, they preferred to spend $2000 extra up-front than have to re-do their $10000 prototype boards because they underestimated the final design's gate count or had to include unexpected extras - such was the case for the project that used XC2V6000s. A supersized hardware simulator is not all lost anyhow since it cuts synthesis time and provides headroom for extra on-chip debugging/monitoring instrumentation.

Agreed, this is certainly on a totally different scale from most sane people's hobby projects.

With the still relatively young V5 slowly replacing the V4, Xilinx will need a new family to break into the 45nm market. Since it is too soon to replace V5 and the S3 is a somewhat old and odd V2P-V4 hybrid, it is about time for a new generation to join the Spartan family. I am expecting to see the S4 family materialize before this time next year, borrowing most of the V5's major architectural changes (LUT6 and PLLs, among other things) with some left-overs from the V2P/V4 (18kbits non-ECC BRAMs with *working* FIFO16s) and other borrowed tweaks from the future V6 (stuff like planned PLL/DCM and IOB improvements). Once that happens, everybody will be able to benefit from LUT6 and PLLs on a budget.

Still, I wouldn't say LUT6 is a "very-high-end" item... but stepping into the "Realm of Virtex" does come at a price.

Re:It's mainly logic, not analogue parts (1)

freeplatypus (846535) | more than 6 years ago | (#20436163)

I know this will not be an accurate information, but anyway...
I saw, how one of modern Ericsson phones had some very small/cheap FPGA soldered in and it was used for overcoming a design error of some ASIC. So, yes, in fact we are usign CPLDs/FPGAs on daily basis ;)

Re:It's mainly logic, not analogue parts (1)

InvalidError (771317) | more than 6 years ago | (#20438007)

The argument was not about using FPGAs in consumer-level devices or not because we, as you said, actually do.

It is just that in consumer electronics, CPLDs and FPGAs are usually there to replace glue-logic and complement the microcontroller/embedded processor's capabilities... like working around bugs. One example of FPGA in consumer equipment is early Radeon SLI: the 'master' board used a Xilinx FPGA to receive pixel data from the slave board and combine it with data from the master to produce the final image sent to VGA/DVI. Matrox's Dual/TripleHead2Go also uses an FPGA to split display data among their 2-3 output ports... or at least they used to - last I heard they were still debating about whether or not they should spin it into an ASIC product.

When FPGAs are used as the core element of consumer devices, it either means the manufacturer is not expecting sales to be sufficient for an ASIC version to break even or that it is testing the market to see if the risk of going ASIC is worth it. Another example is Gigabytes' SATA RAM-drive: another Xilinx Spartan3-based consumer device.

Spartan3 FPGAs can be had for less than $30, which is great for low-volume production of consumer devices. If you look at my three examples, you can see that all three products fit in consumer-level niche markets likely to fall in the sub-million units category. One million units is often where the ASIC becomes cheaper than FPGA - though the bar is slowly rising as FPGAs become cheaper, larger and faster, thereby increasing the breadth of commercially and functionally viable FPGA applications. For intermediate production volumes, Xilinx's EasyPath and structured ASICs/mask-programmable gate arrays provide lower cost and lower risk alternatives to custom ASIC.

On the Virtex side, you are more likely to see those in low-volume ($5k per unit) professional equipment since the smallest and slowest devices are over $200.

In any case, for designers and their customers, having more implementation avenues to fit each price, risk and volume bracket is always a good thing.

Re:It's mainly logic, not analogue parts (0)

Anonymous Coward | more than 6 years ago | (#20435911)

Nice post; if this were Fark I'd sponsor you for TF. :)

Re:It's mainly logic, not analogue parts (1)

kramulous (977841) | more than 6 years ago | (#20436503)

Wow! I know it's a hobby, which means that sometimes the documentation side of things is generally the first thing to go, but I'd really like to read up on some of the stuff you've been up to.

Re:It's mainly logic, not analogue parts (1)

Space cowboy (13680) | more than 6 years ago | (#20456339)

Documentation ? You want documentation ? ? ?

Well, I have circuit diagrams for old projects, (I think - only because I don't tend to 'trash' stuff), and I tend to comment my source-code a lot.... That's about as far as it goes... Perhaps I'll try and put some stuff on my blog in future...

Cheers,

Simon

Re:It's mainly logic, not analogue parts (1)

fmadero (1150849) | more than 6 years ago | (#20438347)

When you mean by "hardware engineer", do you mean a computer, electrical engineer or both? Is a formal education nessary to learn alot of whats going on in this project? In computer science we really don't get into the hardware too much as an undergrad so this project is fasinating.

-frank

Re:It's mainly logic, not analogue parts (1)

Space cowboy (13680) | more than 6 years ago | (#20456297)

I don't think there's any *need* for a formal education (I'm a physicist by degrees, but have spent my whole career as a coder). If you were planning on making a career in this area though, then just like any other area, having a provable education would help a lot, otherwise you show experience (I've done this, and this, and this, and...). You should probably ask real hardware engineers for their opinion too - I'm just an amateur. Personally, it's just a hobby - I'm not planning to change my career any time soon :-)

As for the term 'hardware engineer', all I meant was to distinguish the creation of software from that of hardware - you still need programming skills, the end result is different though.

Cheers,
      Simon

Benchmarks? (0)

Anonymous Coward | more than 6 years ago | (#20432499)

I'm guessing it's still not practical to search the entire sha1 keyspace, even with a bunch of these things. That begs the question, why not a widely used digest with a known collision weakness (ie md5)?

Cool project though.

Re:Benchmarks? (4, Informative)

Cheesey (70139) | more than 6 years ago | (#20432553)

Seems to me that it searches all possible 64-bit words that could be given to SHA-1. It cleverly reorders the search so that the Hamming distance of each block is at most 2 bits from the previous block, which allows Virtex block RAM resources to be used as part of the hash hardware. FPGA engineers often only use block RAMs for caches, FIFOs and scratchpads, so it is interesting to see them being used as part of the pipeline in this way despite the two-port limitation.

So it doesn't search all possible inputs to SHA-1, but maybe you could use it in this situation:

SHA-1(salt, password) = hash
Given hash and salt, you can find password by a brute force search on this hardware (assuming password is less than 9 characters in length). This could be useful for obtaining user passwords from /etc/shadow when something like md5crypt is in use, although md5crypt might well be designed to defeat/slow down this type of attack, for example by using multiple rounds of hashing (as done by the older DES-based crypt program).

Re:Benchmarks? (1)

Tony Hoyle (11698) | more than 6 years ago | (#20432959)

If you can read /etc/shadow you're root.. which means you aren't gaining anything by it.

In the old days when passwords were in /etc/passwd then it was a valid attack. Now much less so.

Re:Benchmarks? (0)

Anonymous Coward | more than 6 years ago | (#20433265)

It's still useful. The /etc/shadow (or some moral equivalent on other systems) could be set world readable by mistake.

And since many people use the same password on different hosts, gaining root on one and cracking the passwords on it would give you access to those hosts as well.

Re:Benchmarks? (3, Interesting)

eli pabst (948845) | more than 6 years ago | (#20433369)

If you can read /etc/shadow you're root.. which means you aren't gaining anything by it.
There are still arbitrary file disclosure vulnerabilities which *only* allow you to view files, not gain access to the server itself. If you pull the password hashes, you can then bruteforce the passwords and gain full root access to the system. Plus it would give you access to any *other* machines on the network which the admin used the same root password. Just rooting a single box wouldn't give you access to any other machines (assuming that didn't share the same initial vuln).

Re:Benchmarks? (1)

petermgreen (876956) | more than 6 years ago | (#20443783)

mind you if you have the box rooted it's not too hard to put a sniffer in place to get the actual passwords as users login.

Re:Benchmarks? (1)

eli pabst (948845) | more than 6 years ago | (#20444741)

That's assuming the user logs in on a regular basis. On a server that isn't a given. If you pull the password hashes, you can bruteforce all of the users passwords generally in under a week on a 1Ghz processor. With this tool it sounds like you could do it significantly faster. I'd probably use both approaches if I was trying to compromise a network.

Re:Benchmarks? (1)

jZnat (793348) | more than 6 years ago | (#20433811)

You might be in the shadow group, and there might be a server application that is in said group in order to read /etc/shadow, so if you can exploit that service to gain access to the contents of the shadow file, you can then try to root the machine after cracking root's (or someone with sudo I guess) password.

Re:Benchmarks? (2, Informative)

BlueParrot (965239) | more than 6 years ago | (#20434039)

You might be in the shadow group, and there might be a server application that is in said group in order to read /etc/shadow, so if you can exploit that service to gain access to the contents of the shadow file, you can then try to root the machine after cracking root's (or someone with sudo I guess) password.


http://www.bash.org/?701504 [bash.org]

Re:Benchmarks? (1)

piojo (995934) | more than 6 years ago | (#20436045)

If you can read /etc/shadow you're root.. which means you aren't gaining anything by it.
Perhaps I don't trust my sysadmin not to try to get my password as a prank (but don't think he's malicious enough to configure/change the login scripts to log the password).

Yes, I'm a student, and no, I'm not paying for access to said system. And yes, I use that password in other places.

How fast is that? (2, Informative)

tcdk (173945) | more than 6 years ago | (#20432555)

NSA@home is a fast FPGA-based SHA-1 and MD5 bruteforce cracker. It is capable of searching the full 8-character keyspace (from a 64-character set) in about a day in the current configuration for 800 hashes concurrently.


Anybody, have an idea how fast that is compared to modern a CPU?

IIRC, the last time I did anything like this it took my 2200+ AMD about 24 hours to do a 6-character keyspace (from 64-character set) - with MD5.

Re:How fast is that? (1)

owlstead (636356) | more than 6 years ago | (#20432575)

"NSA@home is a fast FPGA-based SHA-1 and MD5 bruteforce cracker. It is capable of searching the full 8-character keyspace (from a 64-character set) in about a day in the current configuration for 800 hashes concurrently."

So your 2200+ AMD is beaten to little pieces by this monster.

Source, well, you had to click a single link to their homepage [unaligned.org] . That'll learn you to post early. Or not, since I supplied you the answer anyway.

Re:How fast is that? (1)

tcdk (173945) | more than 6 years ago | (#20432615)

I actually quoted that myself...

I was wondering how it compared with the latest and greatest like x64 with SSE3/4 or a Cell processor...

(that'll learn you to actually read the post you are replying to. Or not)

Re:How fast is that? (2, Informative)

owlstead (636356) | more than 6 years ago | (#20432779)

Arg! Whoops, sorry about that. Read the post, but thought you were quoting the summary.

I've wondered about Cell performance myself for a while, but I haven't got the time to go out of the way to do some measurements. For SSE3/4: I would call it highly unlikely that we would see anything like the performance they are posting: 2 ^ 12 performance difference for MD5 alone is quite a lot. Maybe SSE5 might speedup SHA-2 as well. Anyway, you might want to add the T2 (Rock processor) from Sun to that list, it has 8 crypto hardware accelerators on board. My 1.2 GHz C7 with hardware accelerator is probably way to slow to get anything near the performance, but I'll test it anyway. MD5 is much faster than SHA-1, which in turn is much faster than SHA-2, so you would want to use SHA-2 anyway, as a stop-gap measure.

Re:How fast is that? (1)

kayditty (641006) | more than 6 years ago | (#20438065)

It is very fast compared to modern (conventional -- I am unsure about Cell) processors. You might get some 100 Million MD5 h/s with raw, unsalted MD5 on the latest and greatest quad core Xeon, using MDCrack. Check their performance page here: http://c3rb3r.openwall.net/mdcrack/ln.html#perform ance [openwall.net]

At that rate, it would take 32 days and 14 hours to brute force 8 chars a-zA-Z0-9._ for a single given hash. This setup is capable of doing this 800 times concurrently in a single day, if I read correctly.

Re:How fast is that? (1)

kayditty (641006) | more than 6 years ago | (#20438085)

Yeah. That sounded a bit off. Evidently, it does 800 concurrent hashes at 4Mh/s, instead of doing 800 different hashes at the normal rate. It would be much more interesting if it were doing one hash at 3.258 billion h/s.

Re:How fast is that? (0)

Anonymous Coward | more than 6 years ago | (#20438349)

It actually does 1-800 hashes concurrently at 3Gk/s.

Re:How fast is that? (1)

DaleGlass (1068434) | more than 6 years ago | (#20432955)

Anybody, have an idea how fast that is compared to modern a CPU?

IIRC, the last time I did anything like this it took my 2200+ AMD about 24 hours to do a 6-character keyspace (from 64-character set) - with MD5.

You should compare against VIA hardware. Their CPUs are crap for general usage, but the crypto acceleration is really good:
http://www.logix.cz/michal/devel/padlock/bench.xp [logix.cz]

Page doesn't seem to include MD5/SHA1 though, but you can compare that to AES on your box.

Re:How fast is that? (1)

jerkychew (80913) | more than 6 years ago | (#20434317)

Anybody, have an idea how fast that is compared to modern a CPU?

IIRC, the last time I did anything like this it took my 2200+ AMD about 24 hours to do a 6-character keyspace (from 64-character set) - with MD5.


From one of the comments (I assume c/s is Cracks per second?):

8. I made some lazy calculations for SHA1 just for fun:

The FPGA bruteforcer is capable of 3.257.812.230 c/s.
My Athlon64 3400+ is is capable of 1.915.000 c/s.

Impressive Oo

Posted at 9:47AM on Sep 1st 2007 by miknix

Re:How fast is that? (1)

gratemyl (1074573) | more than 6 years ago | (#20435089)

c/s is likely to mean "combinations per second" - at least that would have been my guess and it makes more sense as well.

SHA-cracker? (5, Informative)

owlstead (636356) | more than 6 years ago | (#20432559)

That's nice, his own SHA-1 cracker. But, even with advanced cryptographic attacks, SHA-1 is still in the order of 2^63. Not something you would like to try with just a few FPGA's. What is meant here is a cracker to find out which plain text, with limited entropy, is used to create a certain hash value. A SHA-1-based password cracker would therefore be a better name, I suppose.

It seems from here [unaligned.org] that it searches a 64 ^ 8 = (2 ^ 6) ^ 8 = 2 ^ 48 keyspace in 24 hours. No small feat, it should therefore do about 3,257,812,230 hashes in a second. It does 800 concurrently, which makes for 4 million a second per SHA-1 unit. Ouch, that's really fast.

Note that this could be done with any hash or symmetric algorithm, as long as it can be implemented on FPGA. So the moral of the story: use very long password (or even better, pass phrases), or make sure that they won't be able to acquire the hash.

Re:SHA-cracker? (1)

MichaelSmith (789609) | more than 6 years ago | (#20432607)

That's nice, his own SHA-1 cracker.

Its a bit like if you built your own cruise missile. Telling the whole world about it might not be the smartest thing to do.

Re:SHA-cracker? (2, Funny)

LarsG (31008) | more than 6 years ago | (#20432761)

Telling the whole world about it might not be the smartest thing to do.

EFF [cryptome.org] seems to think it is the smartest thing to do.

Re:SHA-cracker? (1, Interesting)

Anonymous Coward | more than 6 years ago | (#20433139)

Not really, guys have been reprogramming FPGA for cracking and Crypto work for a long time now. I remember back in the day when they cracked the system first used for DirectTV it was done with a system close to this, Now you can get FTA recievers that recieve all of DirecTV programming for free and you have to update your firmware once every 2-3 months when they change the hash key. The guys releasing the firmwares crack the new key in a matter of 1 hour by using such a setup.

Works great, and that is what FPGA's were designed for number crunching. Unlike what the summary says, video and audio processing were an afterthought.

Re:SHA-cracker? (2, Informative)

Rythie (972757) | more than 6 years ago | (#20432831)

By comparison my Althon 64 3200+ does about 883,000 16byte hashes a second

$ openssl speed sha1
Doing sha1 for 3s on 16 size blocks: 2586683 sha1's in 2.93s
Doing sha1 for 3s on 64 size blocks: 2063294 sha1's in 2.90s
Doing sha1 for 3s on 256 size blocks: 1199179 sha1's in 2.75s
Doing sha1 for 3s on 1024 size blocks: 479901 sha1's in 2.84s
Doing sha1 for 3s on 8192 size blocks: 71496 sha1's in 2.87s
OpenSSL 0.9.8c 05 Sep 2006
built on: Tue Mar 6 08:16:57 UTC 2007
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DMD5_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha1 14125.23k 45534.76k 111632.66k 173034.73k 204074.99k

Re:SHA-cracker? (0)

Anonymous Coward | more than 6 years ago | (#20432899)

Time to move up to 10char password , I guess...

Re:SHA-cracker? (3, Insightful)

archen (447353) | more than 6 years ago | (#20433163)

Perhaps this gets brought up each time, but what are we supposed to use for password encryption anyway? MD5 seems to be inadequate. SHA-1 is also waning. I switched to Blowfish on all my FreeBSD servers partially because of MD5 problems, but also because it's not a common format to come across for anyone figuring they'd just have MD5 hashes to try - I understand however that blowfish was not intended for this purpose.

But it seems like MD5 and SHA are getting weaker by the day with computational power on the rise. Right now I'm setting up an email server (dovecot/postfix) and the strongest hash schemes are of course MD5 and SHA. That's all that almost all email clients support anyway. But it doesn't seem like anyone has a replacement, nor is anyone moving towards anything else, and I haven't seen any real talk about it. I know there was talk about a new hash algorithm contenst similar to the one that took place for AES, but honestly we need the new hashing algorithm out TODAY so we can start to see the extremely slow vendor support start to creep in.

Re:SHA-cracker? (2, Informative)

owlstead (636356) | more than 6 years ago | (#20433319)

Don't forget that PKCS#5 v2.0 uses an iteration count and a salt. This means that the algorithm is not applied just once, but 1000 times (or more, 1000 is the minimum). This would mean a slowdown of 1000 on these kind of crackers *if* they implement the iteration count. A salt would make it hard to use a default configuration like this one found on internet as well.

As said, the hash algorithm itself does not matter too much. The problem with all these schemes is that the amount of entropy in the passwords is simply too small. Creating an SSL channel before authentication and sending a (hashed?) password would do for mail services I suppose. That way there is no way to do the off-line cracking; they'll have to attack the server directly.

Re:SHA-cracker? (1)

GoRK (10018) | more than 6 years ago | (#20433335)

I use SHA-512 with 8 bit salts. For the near future it seems like the best way to deal with password storage.

Re:SHA-cracker? (1)

jZnat (793348) | more than 6 years ago | (#20433847)

Just like the contest to create the AES encryption standard, there is an ongoing one (or happening soon) for cryptographic hashing algorithms. You can probably expect a good one with good vendor support within a couple years or so. Note that if you are using hashes in a typical cryptographic environment (signing a message by encrypting the hash of the message with your private key so that others can verify via your public key), I don't believe this would be a problem. Also, this is only effective in any sense on a very small scale, so outside of hashing passwords, this is kinda useless at the moment.

Re:SHA-cracker? (1)

m50d (797211) | more than 6 years ago | (#20434011)

For an older, well-supported one that hasn't yet shown cracks the way MD5 and SHA1 have, try RIPEMD160. If your system supports more modern ones, Whirlpool is looking good, though it isn't so mature yet.

Re:SHA-cracker? (0)

Anonymous Coward | more than 6 years ago | (#20435831)

Perhaps this gets brought up each time, but what are we supposed to use for password encryption anyway?
Personally I use ROT-13. Yeah, I know what you're thinking, but I make sure I encrypt everything twice for extra security.

Re:SHA-cracker? (1)

kayditty (641006) | more than 6 years ago | (#20438153)

We do not encrypt passwords (well, not usually). We hash them. There is nothing wrong with Blowfish crypt. It is very, very secure. Much more secure than either salted MD5 or SHA-1. However, there is really nothing wrong with using either MD5 or SHA-1 in the short term (so long as you are using a proper salt!). They will do fine. The eight character password, though, has been antiquated for about five years now. You should have switched to 10-15 characters some time ago. Really, even 15 characters is walking a thin line now.

But perhaps you would like to read more about Blowfish crypt:

http://www.usenix.org/events/usenix99/provos/provo s_html/node5.html [usenix.org]

Re:SHA-cracker? (2, Interesting)

cancerward (103910) | more than 6 years ago | (#20439173)

No-one has cracked Ken Thompson's UNIX password [google.com] yet, and he is a co-inventor of the algorithm...

Re:SHA-cracker? (1)

tengwar (600847) | more than 6 years ago | (#20445881)

No, no-one has reported cracking it. Bear in mind that Ken is capable of hiding [cmu.edu] stuff below the source code of the OS, Ken could have set it up so that when a program outputs this particular string, Unix takes some predetermined action such as calling in the black helicopters.

On a more serious level, but for the same reason, there is no reason to think that this entry in the password file corresponds to a valid Unix password, since if that system was based on his code, he login will bypass normal authentication completely.

If you don't understand what I'm talking about - have a look at the paper. It's a classic, and well worth a read. Wikipedia has a summary [wikipedia.org] .

Re:SHA-cracker? (1)

cancerward (103910) | more than 6 years ago | (#20448503)

I know about the "Reflections on Trusting Trust" paper. I'm not sure he ever implemented it; he just implied he knew how to. It pays to be paranoid! In the paper UNIX Password Security - Ten Years Later [springerlink.com] the authors wrote "Over the past 10 years, improvements in hardware and software have increased the crypts/second/dollar ratio by five orders of magnitude." That was about 20 years ago, so if no-one has reported cracking ken's password in the meantime, I think the original UNIX password algorithm has stood up well.

Re:SHA-cracker? (1)

wild_berry (448019) | more than 6 years ago | (#20450299)

Password encryption is data storage. Like your hard disks, use something that's big enough for today and remember to upgrade it when the encryption method doesn't have sufficient space to protect you any more.

Re:SHA-cracker? (1)

Cerebus (10185) | more than 6 years ago | (#20434589)

There's three ways to attack a hash: attack collision resistance, attack pre-image resistance, and attacking the plaintext.

Collision resistance means it should be difficult to find two texts that have the same hash value. The upper bound for these attacks is 2^(n/2), where n is the length of the hash. For SHA-1, that upper bound it 2^80. Because of some more sophisticated attacks, 2^63 is now the current best for a collision attack.

Pre-image resistance means given a hash it should be impossible to find a text that hashes to that value. The upper bound for pre-image attacks is (2^n)/2, where n is the length of the hash. For SHA-1, this is 2^159, and AFAIK hasn't been reduced any.

The plaintext attack is as you describe; totally dependent on length of the text and the size of the character set.

Note that a 10 character password with a 64 character set would take 4096 days with the same device.

Re:SHA-cracker? (1)

kayditty (641006) | more than 6 years ago | (#20438119)

A better alternative is using a hash function with an adjustable cost [usenix.org] (and good salting function with a large salt space), or you could just stop using passwords all together.

Maybe I'm Not As Big A Nerd As I Thought... (2, Interesting)

kaos07 (1113443) | more than 6 years ago | (#20432643)

But I have no idea what that summary or TFA are about.

Re:Maybe I'm Not As Big A Nerd As I Thought... (4, Funny)

lindseyp (988332) | more than 6 years ago | (#20432801)

What? You mean TFA didn't have the right TLA's or FLA's or maybe FPGA's are just not your COT and SHA-1 is no BFD to you but to URG it's a BFD.

what?

Re:Maybe I'm Not As Big A Nerd As I Thought... (0)

Anonymous Coward | more than 6 years ago | (#20432825)

STFU?

Re:Maybe I'm Not As Big A Nerd As I Thought... (1)

Daimanta (1140543) | more than 6 years ago | (#20433081)

More like OMGWTFBBQ!

Re:Maybe I'm Not As Big A Nerd As I Thought... (0)

Anonymous Coward | more than 6 years ago | (#20432861)

Likewise.

Can someone explain how this sort of machine could be used, practically speaking, to break e.g. an email encrypted with PGP, or /etc/shadow?

Re:Maybe I'm Not As Big A Nerd As I Thought... (1)

SplatMan_DK (1035528) | more than 6 years ago | (#20436615)

Can someone explain how this sort of machine could be used, practically speaking, to break e.g. an email encrypted with PGP, or /etc/shadow?
It probably can't, really. But it is useful for two things:

1.) It can be used to crack passwords/passkeys encrypted in this manner. It makes it possible for the owner of the device to obtain the actual password/passkey if he can get a hold of the hashed version. This may be useful in cracking networks or security barriers.

2.) It can display to the world, just how cheat it is to build a device which can reverse hashed data. If he can get his hands on this device for small money, imagine how many FPGAs the CIA or NSA could cramp into one of their facilities?

Knowledge is power.

:-)

- Jesper

I recognise that pattern! (1)

6Yankee (597075) | more than 6 years ago | (#20432961)

Cool diagram. [unaligned.org]

I used to draw patterns like that while suffering through triple Maths - draw a circle, mark off every 10 degrees (or 5 if it looked like being really boring today), then join every point to every other point. Mindless, yet strangely satisfying.

And what kind of nerd site doesn't let you use a degree symbol?

Re:I recognise that pattern! (1)

Torvaun (1040898) | more than 6 years ago | (#20433725)

What kind of nerd doesn't just say pi/18 radians instead on 10 degrees?

Re:I recognise that pattern! (1)

6Yankee (597075) | more than 6 years ago | (#20434525)

What kind of nerd site doesn't let you use a pi symbol? :)

Princeton Engine (2, Interesting)

SuseLover (996311) | more than 6 years ago | (#20433021)

For the record the company is Thomson and that is a peice of equipment known as the Princeton Engine used by the IC developers to quickly verify their software/algorythms. It was lying around in our computer room (known as the Princeton Engine room) for years. Its replacement is from Cadence and is called Palladium and has the power of several hundred of those old fpga boards.

Re:Princeton Engine (1)

natersoz (239301) | more than 6 years ago | (#20433061)

Wow, is that a blast from the past... Qbert, Proscan, Widescreen. I was there baby when the Princeton Engine was the bomb.

Re:Princeton Engine (0)

Anonymous Coward | more than 6 years ago | (#20433305)

That's not the case. Read the article (what am I hoping for, really?).

This is essentially a password cracker (1)

Paul Crowley (837) | more than 6 years ago | (#20433165)

He's not looking for collisions - he's looking for preimages of a given hash. Since he can't search a large enough space to find a preimage of an arbitrary hash, the most useful application of this sort of thing is password cracking - given the hash of someone's password, search the space of plausible passwords until you find one that matches the hash (taking salt into account as appropriate). Fun but not too advanced.

Shame - what I was really hoping to read was that he'd implemented the latest collision-finding attacks on SHA-1 on FPGAs. It won't be long before we have our first real-live SHA-1 collison, and it'll be interesting to see whether it's done with special hardware like this, general purpose processors, or perhaps something curious like PS3s or video hardware.

Re:This is essentially a password cracker (1)

jrwr00 (1035020) | more than 6 years ago | (#20433329)

Video HW does seems like it would be able to handle the weirdness of SHA-1 Cracking

Re:This is essentially a password cracker (0)

Anonymous Coward | more than 6 years ago | (#20435491)

I don't know about that. Video hardware tends to use approximations to floating point calculations internally. That is to say, you get less than floating point precision out of them. But hash cracking requires "infinite precision" -- integer arithmetic. (Compare: 1 + 1 = 2, but 1.0 + 1.0 need not be 2.0).

Re:This is essentially a password cracker (0)

Anonymous Coward | more than 6 years ago | (#20435993)

Shame - what I was really hoping to read was that he'd implemented the latest collision-finding attacks on SHA-1 on FPGAs.
That's what I thought too. But if that's the case, then he better off waiting a little bit. Improved attacks on SHA-1 are coming out pretty soon.

Password Cracker, not SHA-1 Cracker (1)

jon_anderson_ca (705052) | more than 6 years ago | (#20434031)

This doesn't find hash collisions (much less pre-images), so it's not an attack on SHA-1. It's an exhaustive search over a subset of ASCII (64 characters) for the purpose of cracking short (8-character) passwords.

This is John the Ripper in hardware, just not as clever.

Cracking Sha.... (1)

Heembo (916647) | more than 6 years ago | (#20435305)

So is this being used to create huge rainbow tables? How many characters out can you go? I saw someone selling rainbow tables for SHA-1 out to 15 characters at DefCon on 2 DVD's for like 10$...

15 Virtex-II Pro FPGAs (1)

mako1138 (837520) | more than 6 years ago | (#20435743)

The boards contain 15 Virtex-II Pro (XC2VP20) FPGAs in 3 identical sets of 5 (here called "channels"). Each channel also owns a Spartan-II (XC2S50) FPGA that was originally used as a control chip, and a DSP (ADSP21160M) which probably calculated transform parameters. There is also a shared XC2S50 chip, which is not used in this application, just like the DSPs. The clock distribution tree unfortunately contains 2 domains, which means the 39MHz channel clock had to be distributed from chip to chip, using internal Virtex-II DCMs to clean it up.

To control the boards, an USB boardlet has been built and the Spartan-II chips programmed to share the USB interface using a ring protocol. Spartan-II chips translate USB-carried command packets into bus transactions (16-bit address, 18-bit data) and the bus read data into USB packets again. They also service SHA1 breaker IRQs to minimize the number of results that had to be merged into one - there is a buffer for 1024 18-bit reads in each Spartan-II.

This is a really neat project. These FPGAs aren't the latest and greatest, but when you've got 15 of them, parallelism is your friend.

Outside of my job, I've had some ideas for FPGA projects, but the (mostly) BGA packages result in very expensive multilayer boards; too expensive for hobbyist purposes. You'd also have to contract out the BGA assembly, and depending on the FPGA chosen, spend a lot on the FPGA itself. (The smaller FPGAs are available in hand-solderable flat-packs, but the logic densities are typically insufficient. At least we can get small FPGAs from Digikey for $10 and up.) An obvious workaround is to buy a dev board, but they're still relatively expensive, and you've got IO hardwired to the various peripherals they stick on the dev board.

This SHA-1 project cleverly reuses hardware that someone else devoted a lot of time and money to. /me wonders where he can get hardware like this on the cheap...
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>