Date: Sat, 2 Feb 2013 17:56:01 +0100 From: CodesInChaos <codesinchaos@...il.com> To: crypt-dev@...ts.openwall.com Subject: A couple of thoughts on password hashing A couple of quick thoughts on creating new password hashes: * Use realistic cost metrics for the attacker i.e. based cost of the hardware * For Key derivation in disk encryption, state level attackers with custom hardware are an important consideration For login hashes we probably care more about less sophisticated attackers with GPUs and perhaps FPGA. * Time-memory trade-offs seem to increase flexibility without benefiting attackers. It's trade-offs involving parallelism that are problematic * Should be usable as both KDF and to verify logins with minor changes * I'd use a three part construction: 1. `Extract` Takes salt and password, returns a uniform constant size binary value 2. `Stretch` Expensive and CPU/PC favouring. Takes and returns a constant size binary value 3. `Expand` Returns arbitrary sized, named bitstrings Step 1 and 3 should mirror the semantics of HKDF. See http://tools.ietf.org/html/draft-krawczyk-hkdf-01 HKDF is a nice design and it seems difficult to do much better than it for these steps. A minor downside is the limited output size. If you use a custom hashfunction for the `Stetch` part, using the same for the other steps seems useful, but I'd still try to match the semantics closely. When used for login verification, use a specific name, such as "verifylogin" for the `Expand` step * When used as KDF, deriving long or multiple strings should call the expensive function only once (unlike PBKDF2) PBKDF2's performance characteristics when extracting more than the natural output size are surprising, and can decrease security. * AES-OFB is a sequential stream cipher and quite fast on modern CPUs. AES block size might be too small for some other uses though. * The way CPU caches work and the latency of accessing RAM or different caches might play a major role for designing the algorithm. Perhaps some kind of non-blocking prefetches could be useful. But I'm not sure if those exist or how they work. * Is it possible to construct a competitive function that only uses standard primitives, such as AES and SHA-2? * Specify a character encoding for the password for better interoperability. * Should be UTF-8 without BOM * Include non ASCII characters in test vectors * Include characters from astral planes (codepoint >2^16) in test vectors (tests UITF-16/UCS-2 related bugs) * Specify a unicode normalization form? * Specify a string format and algorithm identifier for use in `crypt` * Perhaps specify a way to include an additional secret key(per website secret). I think encrypting the hash with it is better than including it as a kind of salt, since it allows upgrading the hashes when you change the key. * Is it useful to specify a construction at a security level above 128 bits? Content of type "text/html" skipped
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.