Permanent secret identity

Tyler Durden camera_lumina at hotmail.com
Thu Jun 28 02:59:11 PDT 2007


Roy Silvernail wrote...

>I'd think the method of choice would be to intermediate the update
>process.  If updates can be done with an encrypted blob in an email, you
>can use the remailer networks and Tor to break the connection between
>"you" and "268" so Mallory only knows that someone with the right keys is
>updating 268.  Even if direct connections are necessary, a Tor session
>should help by making sure that updates to 268 always come from different
>IPs. Even if it's only a describable set of exit nodes, all Mallory knows
>is that 268 is Tor-literate.

Well, there's still the problem of private information on the server being 
leaked to the publically-accessible side. In other words, let's say I want 
to store my income on the server and then release it to certain other users 
in exchange for a payment. Of course, I could store such private information 
on my own machine, but this is problematic for several reasons (including 
the fact that I may want some of this information to be automatically 
released to anyone willing to pay the $ for it, meaaning I don't want to 
have to initiate a Tor session every few seconds).

But I definitely don't want a user to be able to extract private info 
without paying for it, and perhaps there's some info I never want released 
publically.

Now, having my admin not know who I am (or which reputation belongs to me) 
is even better, and hopefully would be solved via the same mechanism.

-TD




>From: "Roy M. Silvernail" <roy at rant-central.com>
>Reply-To: roy at rant-central.com
>To: "Tyler Durden" <camera_lumina at hotmail.com>
>CC: cypherpunks at jfet.org
>Subject: Re: Permanent secret identity
>Date: Wed, 27 Jun 2007 13:19:41 -0400 (EDT)
>
>On Wed, June 27, 2007 10:49, Tyler Durden wrote:
>
> > Let's assume that I always initiate a session from the same IP address,
> > and
> > that the identity is encrypted. What I don't want is for anyone to see
> > that
> > "I" always access identity No. 268.
>
>If we can also assume that you perform this update over a secure
>connection, then (also assuming the secure protocol used is intact) no one
>outside of the identity server can see the contents of the session.  The
>update protocol should also perform basic protective steps, such as making
>all traffic of uniform size, using good-quality randomness for padding and
>the like.
>
> > Is this even necessary? Am I in effect protecting against someone taking 
>a
> > core dump of the server, or are the issues more significant than this?
>
>Essentially, you *can't* prevent Mallory the Evil Admin from doing 'sudo
>cat /dev/kmem > chump_dump.img'.  So you need to tune your threat model
>accordingly.  You face two attack surfaces: your connection to the
>identity server (which is probably defendable) and the server itself
>(which, if we posit local hardware access by Mallory and Co., is toast and
>he already knows you are Number 268).
>
>I'd think the method of choice would be to intermediate the update
>process.  If updates can be done with an encrypted blob in an email, you
>can use the remailer networks and Tor to break the connection between
>"you" and "268" so Mallory only knows that someone with the right keys is
>updating 268.  Even if direct connections are necessary, a Tor session
>should help by making sure that updates to 268 always come from different
>IPs. Even if it's only a describable set of exit nodes, all Mallory knows
>is that 268 is Tor-literate.
>
>But overall, if you don't trust the admin crew, how do you trust the
>server itself?  And should you even be placing your credentials in its
>care in the first place?
>--
>Roy M. Silvernail is roy at rant-central.com, and you're not
>"Antelope Freeway, one sixty-fourth of a mile." - TFT
>CRM114->procmail->/dev/null->bliss
>http://www.rant-central.com
>

_________________________________________________________________
Who's that on the Red Carpet? Play & win glamorous prizes. 
http://club.live.com/red_carpet_reveal.aspx?icid=REDCARPET_hotmailtextlink3





More information about the cypherpunks-legacy mailing list