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: Mon, 27 Jan 2014 19:11:49 +0100
From: Krisztián Pintér <pinterkr@...il.com>
To: Peter Maxwell <peter@...icient.co.uk>
CC: discussions@...sword-hashing.net
Subject: Re: [PHC] Opinions sought on whether a specific side-channel leakage is ok.


Peter Maxwell (at Monday, January 27, 2014, 4:20:55 PM):
> Without exposing too much of my intended design, I'd like to garner
> some opinion if that is possible.  

you are not going to file a patent, are you?

> So, lets say we can associate a given password with a scalar
> password complexity measure in the interval [0,1] with an as yet to
> be defined distribution.

here is my objection, above the obvious leak issue. calculating
password strength is difficult. it will be a damn complex algorithm,
supported by tables, many equations and a sizeable dictionary.

the complexity in itself is wrong. this strength estimator will dwarf
the actual hash in complexity. it is error prone and expensive. but
there are other problems as well.

do we standardize the definition and the data? in this case, smartcard
and such manufacturers will scratch their heads how to put all that
into their limited space.

or we allow different implementors to have different evaluation
algorithms. but this is wrong, because those algorithms must be
validated and reviewed. the very reason why we have standards is to
avoid all that hassle.

different algorithms is also wrong because in case of password reuse,
if you measure different login times, you will acquire multiple
subsets, the intersection of which the password in question will
reside in.

so i think this idea proves itself unfeasible for practicality
reasons.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ