[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
