[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110509153907.GA30220@openwall.com>
Date: Mon, 9 May 2011 19:39:07 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com
Subject: alternative approach
Hi,
Initially, I proposed that we try to design a hashing method that could
be implemented near-optimally on all of: CPU (including SIMD), GPU, and
FPGA (and ASIC) - perhaps with different locally-configurable parameter
values, though. It would also require a configurable amount of memory.
I am not giving up on that idea, however:
It alone assumes that an attacker will always have the most suitable
hardware anyway. While we definitely must not rely on an attacker
having no access to specialized hardware, we may also want to consider
that in practice many attackers will in fact happen to be limited in the
kinds of hardware available to them. Someone may readily have only
their own gaming computer, someone else may readily have a GPU farm, and
yet another person may control a botnet built of typical end-user PCs
(most of them without decent GPUs and proper drivers), etc. Thus,
having to get the most suitable hardware would be extra cost to them.
Here's an alternative approach that we could consider:
Include several components in our hashing method - e.g., we may have a
component well-suited for CPU (maybe no SIMD?) and FPGA/ASIC, but not
for GPU (bcrypt is close to being such a thing), we may have a component
well-suited for all of these, and we may have a component that requires
FPGA/ASIC for efficient implementation. The relative weights of these
(iteration counts) may be configurable (and encoded along with the
hashes) depending on what kinds of hardware we have (or expect to have)
in servers at a particular site. By configuring the GPU-unfriendly
component to have significant weight, we make life harder (costs higher
or success rate lower) for that gamer with a graphics card and for that
attacker who readily has a GPU farm. By also using a CPU and GPU
unfriendly component, we make the botnet less effective.
The near-optimal on all hashing method becomes just a special case of
the above, then - just configure the specialized components to have very
low weight (or even zero).
A major drawback is complexity. Another drawback is that we might end
up using many ciphers/hashes, which might make it difficult to get this
solution accepted in places that care about or have to use certified
crypto only, or to obtain due government certification for products
implementing the hashing method. On the other hand, we may specifically
design the components using ciphers that would be acceptable in
different places - e.g., use SHA-2 or AES in one component and GOST in
another - then the unacceptable cipher could be disabled for use in
specific organizations or for product certification by setting the
corresponding component's weight to zero. (Of course, doing so goes
against security...)
Overall, the number of criteria affecting our design decisions becomes
rather large, which is unfortunate.
I'd appreciate any comments.
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.
