[clug] A Question About Password Handling and Authentication Mechanisms
Tony Lewis
tony at lewistribe.com
Tue Nov 25 23:32:23 MST 2014
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
More information about the linux
mailing list