[cryptography] Mixing multiple password hashing: Crypto Blasphemy or Useful approach?

Fabio Pietrosanti (naif) - lists lists at infosecurity.ch
Sun Mar 15 07:22:21 EDT 2015


Hi all,

i've been brainstorming on the different way to apply a KDF in a "strong
enough way" and i see that each approach has it's advantage and
disadvantages in terms of speed, in terms of FPGA/ASIC protection, in
terms of crypto primitives being used.

I'm wondering if it's smart or stupid to think/apply a password-hashing
system that apply multiple password-hashing schema based on different
cryptographic primitives in sequence, as a way to force the attacker
willing to FPGA/ASICize the bruteforcing process, to need to implement
multiple cracking infrastructure.

I don't have the cryptographic knowledge to design something on my own,
but i'm asking if "this approach" make sense.

Let's assume something like that, assuming that could take 10-20s on a
modern computer:

step0: 3s of scrypt
step1: 10.000 round of SHA256
step2: 10.000 round of SHA512
step3: 10.000 round of Whirpool (even if broken)
step4: 10.000 round of Blake2
step5  10.000 round of Keccak (SHA3)
step7: 10.000 round of HKDF (In WebCrypto API)
step6: 10.000 round of PKDF2 (in WebCrypto API)

Each single hashing algorithm and KDF functions provide a specific set
of protection against specific set of attacks.

An adversary that want to build ASIC or FPGA cluster, would really
require to build many specialized clusters rather than one very focused
cracking-cluster (ie: to attack SHA256).

A "Meta KDF" function like that could bring much more complexity on the
attacker side by requiring the attacker to employ multiple attack
vectors to attack the cryptosystem.

The approach previously described, from a real world attack scenario
perspective, does make sense as a "on steroid key-stretching" approach?


-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20150315/d07f2cd3/attachment.html>


More information about the cryptography mailing list