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-next>] [day] [month] [year] [list]
Message-ID: <CA+aY-u5NoGxo9pS03axJMnGJBCXGNbfSbdaGAD1EfQAwRE0EZQ@mail.gmail.com>
Date: Mon, 27 Jan 2014 18:37:24 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: discussions@...sword-hashing.net
Subject: Fwd: [PHC] Opinions sought on whether a specific side-channel leakage
 is ok.

​(forwarded copy, hopefully Gmail will play ball this time and send it to
the list address... )​




On 27 January 2014 18:11, Krisztián Pintér <pinterkr@...il.com> wrote:

>
> 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?
>

Auch, no.  Just wanting to test the water with one daft suggestion at a
time.



>
> > 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.
>

I suspect I may have a few ideas on how to do this efficiently, but I
haven't looked at the research yet to see what the state of play is and
what others may have done already.



>
> 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.
>

​Actually, that might not be the case.  I wouldn't have suggested this
design unless I thought it possible to create a complexity measure with a
simple algorithm (and no, I haven't got that far, was wanting to see
whether the main idea was workable first).




>
> 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.
>

​Do we standardize parameters for other submissions?​




>
> 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.
>
>
​It can be standardised, although, yes, there are ancillary questions here.​




> so i think this idea proves itself unfeasible for practicality
> reasons.
>
>
​The objections you've highlighted here I had anticipated and *think* I
already have solutions for (the proof will be in the pudding though).  It
was more whether the side-channel was a deal-breaker for most people.

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ