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@rant-central.com> Reply-To: roy@rant-central.com To: "Tyler Durden" <camera_lumina@hotmail.com> CC: cypherpunks@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@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