[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Auth]My two cents

From: Jeremy Petzold
Subject: Re: [Auth]My two cents
Date: 16 Jul 2001 08:01:43 -0700

ok, what if we did it this way?

the user starts up the service for the first time, he enters his DATA onto a 
form that saves it on his computer. 

he registers with an auth server, but, instead of the auth server holding any 
personal data, the server just creates a Key.

the server then stores a copy of that ticket in an encrypted file and sends the 
same thing to the client.

when the client goeat to buy somthing or anything else that the client would 
like to do that requires any information, he sends the information along with 
his encrypted key.

the site then sends that key to the Auth server (which is specified in the data 
file sent) and the auth server validates the key and sends a reponce back to 
the site verifying that the key is correct.

this solves the problem of data storage being decentralised and not being 
collected by any one place as the DATA stays on the clients computer.

how is that?


On Mon, 16 July 2001, Myrddian wrote:

> > >>>>>
> > ONE master registrar is bad (too much power) Many registrars which can cross
> > sign their identities (and therefore their users one) is perfect.
> > <<<<<
> Yes very bad :)
> > What about two (or more) registrars that store half of the information
> > each?!
> > For example, take two registrars, and The user wants to
> > store his profile, given as an array of bytes p[i], with these registrars
> > without
> > trusting any of them. This can be done by taking an array of random numbers
> > r[i].
> > Registrar gets to store the array r[i], and registrar gets
> > to store the array r[i] XOR p[i]. Both registrars only see arrays of random
> > numbers. In order to recreate the original profile, the client has to
> > retrieve
> > r[i] from, and  r[i] XOR p[i] from, and XOR these two
> > arrays
> > with each other resulting in r[i]XOR r[i] XOR p[i] == p[i]. So this reduces
> > the
> > problem to the problem of reliably updating profile arrays at two registrars
> > which can be solved by storing two generations of profile arrays.
> > 
> > This model would consist of
> > - Registrars storing two versions of byte arrays for clients that
> > authenticate
> >   themselves via a user/password scheme which the end-user has to remember.
> > - A client computer module that accesses both registrars, retrieves the
> > profile
> >   string halfes, combines them into the real profile string, makes use of
> > it,
> >   updates it, and stores new versions with the registrars.
> > - A net of independent registrars all over the world would be needed that do
> >  not need to know about each other.
> > - Clients would choose two registrars that they have to remember.
> Having two core, registers defeats the de-centralized authorazation system 
> idea.
> We are trying to avoid that, but I see you have a point.
> Problems arise with it though
> 1) Data consistency (how should the data be updated More importantly how 
> frequently)
> 2) Failure, what happens if one of the servers goes down?
> 3) Making the user remember two distinc logins defeats the one login anywhere 
> idea.
>    (But this can be automated, however security?)
> Howeer your document is a good start on how we should solve this problem, I 
> think this also has been
> mentioned in another thread. We should focus this argument more on a specific 
> topic.
> -- 
> __________________________________________
> Myrddian <address@hidden(nospam)au>
> -------------------------------------------
> "I stayed up all night playing poker with tarot cards. I got a full house
>  and four people died". 
>                    -- Steven Wright 
> _______________________________________________
> Auth mailing list
> address@hidden


Find the best deals on the web at AltaVista Shopping!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]