[clug] A Question About Password Handling and Authentication Mechanisms

[Tony Lewis]

On 26/11/2014 1:57 PM, jm wrote:
> There is an area of crypto where it is possible to carry out
> calculations on encrypted data such that the "person" making the
> calculation is unable to recover the initial data. ie, it's possible to
> encrypt to numbers and have a third party add those numbers without
> being able to find out what those numbers are. Roughly,
>
> if E() is encrypt, a and b are numbers, '+' is the appropriate addition
> method it's possible to do,
>
>      E(a) + E(b) = E(a + b)
>
> which is what got me thinking down this path in the first place.

I know not of what you speak, but am curious if anyone knows any more 
about this.

>
> Now my notation is a little wonky as i don't know what the correct
> notation is, so let me describe what I'm thinking in hopefully a better
> way. I'll do this as dot points so you can highlight any problems in my
> logic,
>
> * I said hash, but simple mean a one way function not necessarily a
> standard hash like sha1.

That's the definition of a hash function: a one way transformation that 
is collision-resistant (and other stuff)

>
> * The functions Hserver(), Hclient(), Verifier(), are not  the same
> function.
Why?
>
> * If project this into one dimension graphically I'm thinking something
> like this, (Looks a lot better when I scribed it on a bit of paper)
>
>             |              |
> |
> |
> server: password--> Hserver(password)------->
> Verifier(Hserver(password), challenge)->|
> client:  password----------------------> Hclient(password,challenge)
> ------------->|
>
> * Each application of a function moves you further to the right with no
> way back.
>
> * Reading your email more closely the second time. Your right
> Hclient(password,challenge) == Verifier(Hserver(password), challange),
> so given a stolen hash Hserver(password) and the challenge it's possible
> to calculate the response.
>
> * What about
>      Hclient(password,challenge) != Verifier(Hserver(password), challenge)
>
>    instead either make these a propablistic match and do multiple rounds
> (similar to a zero knowledge protocol if I remember correctly)
>    or  introduce a Compare() function that takes the response from the
> client and the Verifier() function to give a boolean value of equivalence?
>
> So, assuming that such functions exist is there a hole in my logic? And,
> if my logic is correct are such function known to exist? And/or, is
> anyone researching this?

I'm a little lost, but I think your argument is self-fulfilling.  If 
such functions exist, then there is no hole in your logic. Otherwise, 
there is.  I don't know of any.

And I'm at a loss as to figure out what problem you're trying to solve 
that existing password authentication schemes don't solve for you.

>
> Finally, thanks for taking the time to wade through this.

Not sure I helped this time.

Tony