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.