phc-discussions - Re: [PHC] Opinions sought on whether a specific side-channel leakage is ok.

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]

Message-ID: <361131380.20140127191149@gmail.com>
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.