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