Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.