lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 12 Dec 2014 08:10:27 -0800
From: "Dennis E. Hamilton" <dennis.hamilton@....org>
To: <discussions@...sword-hashing.net>
Subject: RE: [PHC] How important is salting really?



-----Original Message-----
From: epixoip [mailto:epixoip@...dshell.nl] 
Sent: Friday, December 12, 2014 03:13
To: discussions@...sword-hashing.net
Subject: Re: [PHC] How important is salting really?

[ ... ] In other words, an algorithm must not rely on solely upon salting. In other
other words, something like sha256(s.p) is insufficient.

<orcnote>

  I am having difficulty understanding the case where 

		H_i = hash(salt_i, pw_i*) 

  is necessary but not sufficient.

  It would help me to understand the use case better.

  Assume that everything above but pw_i* is known to
  the adversary.  The "hash" is a cryptographically
  adequate near-one-way transformation and whatever 
  the work factor and resource costs are, they are
  not too costly for the defender.  

  Now, for a corpus of (salt_i, H_i) pairs, salt_i 
  Are assured to be unique.  Assume salt_i and H_i 
  are of the same order (number of bits) and the
  salt_i are at least half cryptographically-
  random bits. 

  What are the search model and initial conditions
  such that cracking one pair for pw_i* makes 
  cracking a different pair easier to any practical 
  degree?  Put differently, what must N, the size
  of the corpus being attacked, be for the N-th
  crack to be twice as fast as the first, and how
  does that work out as an average cost per crack?

  I think this fits the password-hashing conditions,
  with regard to the presumption that all but the
  pw_i* are disclosed (and any other parameters
  are fixed for the given corpus).
</orcnote>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ