[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110514004043.GA18828@openwall.com>
Date: Sat, 14 May 2011 04:40:43 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com
Subject: Re: alternative approach
Yuri -
On Thu, May 12, 2011 at 08:48:35PM -0300, Yuri Gonzaga wrote:
> I am following all this discussion and trying to understand as much as I
> can.
Great.
> By now, I like the way this is taking to a specified method and the fact we
> can let GPU approaches omitted once I don't know anything about it.
I don't think I had ever proposed us implementing a GPU-specific
component this summer. What I did propose initially was to design a
hashing method that could be implemented near-optimally on all common
kinds of hardware, including CPU, GPU (theoretically), and FPGA/ASIC,
with possible use of GPUs in servers in mind. However, we're trying to
see if an "alternative approach" with a component optimized specifically
for FPGAs makes more sense currently. It probably does, because
attackers who readily have GPUs are more numerous than those who readily
have FPGAs, whereas servers have neither (it's an add-on board either
way). And, yes, we need to consider our experience, too.
> What do you mean to a "non-crypto" component?
Did you mean "by", not "to"? If so, I mean that we call it "non-crypto"
and show that the cryptographic strength of our hashing method does not
depend on this component.
> Thank you for letting me participate and have any word in design decisions.
> I will read all these emails again and see if I can do anymore comment.
You're welcome, and thanks for your comments. If anything is unclear to
you, please feel free to ask.
Alexander
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.
