[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
