I don't think "escrow" is the salient feature of what Adam is hinting at, or at least it's now what I'm focussing on here. Rather, I think the really intriguing thing is using _logical_ names for remailers, and not necessarily tying them to specific accounts, specific account owners, or specific sites. ("Call by name," if you will.) This could make remailers more persistent. (A downside is that having remailers in flux is sometimes a good thing, as it discourages users from using the same old chain. But this is a nit.) At 10:54 AM -0500 10/23/96, Adam Shostack wrote:
Would it make remailers more reliable to use a netescrow system, so that if a remailer goes offline, the others can request its keys, and continue moving its messages?
To me, reliability is as large a problem as UI. If the next Mixmaster is going to do direct IP transport, reliability could increase as a problem.
This seems like a very good idea. I have an idea for transitioning from the current "physical site name" approach remailers are using, to perhaps a "logical site name," where logical names (like "AliceRemailer") would be aliased or mapped (through a collectively-maintained, or Raph Levien-maintained (:-}) list of logical-to-physical site names. Thus, if the physical site or physical account name which maintained the "AliceRemailer" remailer and keypair were to vanish or have the account yanked, another site/account could "inherit" the keypair (by suitable arrangements) and the persistence of the site AliceRemailer would be ensured. But I have some questions about possible implementations. Suppose a remailer is named "Alice@foo.bar," or "Alice" for short. Alice has a key, AliceKey. Now imagine that the Alice remailer goes down, for whatever reason. Alice (the person or owner) can "authorize the release of AliceKey" to another remailer of her choosing (or by prior arrangement, as a fallback remailer). So, Bob takes over Alice's traffic. However, some questions for this scenario: -- users will have "Alice@foo.bar" in their scripts, or chains, or whatever. So, having Bob have AliceKey is not ipso facto very useful. If users have to respecify a site name, they might as well just switch to the BobPublicKey, for example. -- on the other hand, if a "logical name" could be used, where users see a name like "AliceRemailer" instead of "Alice@foo.bar," then a remapping of AliceRemailer to whatever site is still up and handling her private key could provide a seamless transtion. (This might require an address mapping table to be either publically accessible, even to remailer scripts. But this seems doable. Even if "Joe Sixpack" doesn't keep current on the mappings, the much smaller number of remailer operators can certainly keep current on the mappings. So all Joe Sixpack has to do is arrange the chain, e.g., (Alice (Emilio (Susan (Freda (etc....)))) The remailers then pass the messages on to the physical site matching the logical site. And to be clear, the user, Joe Sixpack, of course has to have the public keys of each of the remailers he plans to use.) I don't see that this would create new security problems, as the private keys for a logical remailer are only passed on to another site if and when the remailer owner _wants_ to. (This is back to the familiar theme that the owner of a private key can pretty do what he wants, including passing it on to others.) There are a lot of issues occurring to me now on this, but I think the basic idea is sound. --Tim May "The government announcement is disastrous," said Jim Bidzos,.."We warned IBM that the National Security Agency would try to twist their technology." [NYT, 1996-10-02] We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."