|
Message-ID: <BANLkTi=_Yj9MvX+UmrNyNwYAXwczh5eKLw@mail.gmail.com> Date: Mon, 30 May 2011 10:52:44 -0700 From: David Hulton <0x31337@...il.com> To: crypt-dev@...ts.openwall.com Subject: Re: alternative approach Alexander, On Sat, May 21, 2011 at 3:36 PM, Solar Designer <solar@...nwall.com> wrote: > OK. Did your DES speed numbers (such as 22 billion/second/chip) apply > to XC6VLX240T or to something else? This is important for us to know > such that we can compare DES against the alternatives we're considering. Yes, that's what's running on a single XC6LX240T. > However, DES is probably larger than my bflike thing, so we'd have fewer > cores. I'd appreciate it if you post some info on that - e.g., some > synthesis results (preferably directly comparable to what Yuri posted > for bflike) for one fully-pipelined DES core. Alternatively, I need the > number of fully-pipelined DES cores that you manage to fit in a > particular Xilinx chip. There must be some overhead to manage those > cores, though (feed them with inputs, process their outputs) - I'd > appreciate info on that as well (what percentage of the logic is spent > on that?) There is a little bit of overhead but not much, most of the space is taken up by the S-Boxes. We currently have 36 fully pipelined DES cores on our 22 billion/sec image. Each core runs at 600MHz. We could fit more cores if we ran it at a slower speed but that's the best for doing the high speed routing (and from what we've found is the best tradeoff for the current design we have). > Also, DES is more software-friendly (with bitslice implementations). > > Given the numbers Yuri posted, it appears that a XC6VLX240T would > outperform Core i7-2600 at bflike by a factor of 200. Isn't this 5x > better than the 40x we had for DES? This ignores the overhead, though. > But on the other hand, there's further room for improvement (add bit > permutations, which will slow down software). That would be great if we could get a better advantage than DES with this bflike algorithm. Was this verified by actually synthesizing something close to the proposed algorithm? > That's what we're trying to do, and we'd appreciate your help with it - > specifically, more info on your DES cores, and some advice on > generating and understanding a circuit diagram or the like. Sure thing. Do we currently have a basic implementation to work from? I think the best thing to do at this point is to synthesize and try tweaking to see which design is the most space/speed efficient. -David
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.