[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Job for netescrow ? (was Secure anonymouse server protocol...
Adam and Matt put my casual remark under the grill:
Peter Allan <[email protected]> writes on cpunks:
> [Matt Blaze's Oblivious Key Escrow paper]
ftp://ftp.research.att.com/dist/mab/netescrow.ps
>
> This all hinges on a policy to be followed by archive holders defining
> the conditions under which they release their shares.
> This could be receipt of a signed request from the owner (remailer).
>
> Maybe the table relating nyms to reply addresses could be stored in
> netescrow style so that captured remailers reveal nothing. The problem
> of operator coercion is not addressed by this.
Adam:
> Just to clarify, if I understand correctly you are proposing a penet
> style system with the database held in `netescrow'.
Yes. What I had in mind resembled the split list scheme used at a church I
used to go to. UK tax law has concessions for regular giving (Covenants, in the jargon)
and the church needed to know that comittments were being met. At the same time it was
preferred not to know who was giving what. This was done by having 2 lists eg
Namelist: Mr J Smith = member 999
Cashlist: member 999 gives 1000 / month
If member 999 didn't give as planned, cashlist-holder could say to namelist-holder
"have a word with 999".
These were held by 2 people, trusted not to collude. Also I suppose committee
reshuffles shouldn't put one person straight into the other post.
My idea was to replicate this split list so that
addrlist: [email protected] = index97b6150200000564
nymlist: index97b6150200000564 = [email protected]
This would be altered for the remailer table as:
addlist: [email protected] = index97b6150200000564
addlist: [email protected] = index97b6150200400281
and these 2 mappings would be escrowed:
index97b6150200000564 -> index97b6150200400281
index97b6150200400281 -> index97b6150200000564
(Or just escrow the _keys_ for the latter, as Matt first thought.)
> However the aim is not to prevent others
> censoring your publically available writings, but to allow a second
> avenue of access only in the case of `mob cryptography'.
The aim is to prevent a seized remailer having its data read.
The "angry mob cryptanalysis" is a side issue.
> If the police are unsucessful (seems likely) does this offer the
> operator much solice in his jail time for contempt of court, to
> know that he has a vote of confidence in the moral correctness of
> his decision from a population of the net?
> Does it offer him any legal benefit? Are the share holders guilty
> of contempt also, does this lessen his guilt, and harshness of
> prosecution? (Remember that the share holders' identity and
> location are unknown to the operator...
> I'm not sure how useful this part is, unless the possibility of
> `mob cryptography' is the desired feature. I'd have thought an
> individual remailer operator would be more likely to fold than a
> group of anonymous crypto-anarchists.
I did say this didn't address operator coercion. The widespread
cross-jurisdiction aspects of netescrow will be important here.
Capture of hardware without scope for operator coercion would be
protected against - but is an easy problem anyway.
> 2. You could add the twist of an alternative duress key, that would
> stand a real chance of successfully nuking the database. More
> satisfying.
I was thinking of calling this the "shredder ticket" and giving it to
the sender (who can then distribute it to all remaining remailers without
needing to use the seized one). This would depend on him realising that
the remailer was (about to be) seized, and would have to be done before
the enemy rounded up the shares. [Incidentally I'm not that keen on
regarding the police as the enemy. My mention of "angry mob cryptanalysis"
in the event of a crime was to show that it was not the ideal vehicle for
crime. But then maybe I'm a statist pig.]
In any case it would be necessary to
> 3. Negative comment on the system: TLAs have a vested interest in
> themselves being most of the share holders. True of the ownership
> of the current remailers also of course.
>
The widespread cross-jurisdiction aspects of netescrow will be important here.
(Perhaps including compulsory cross-border secret reassembly. )
I was envisaging this being combined with Mixmaster. (I see from your
Eternity post that you'd run a netescrow scheme that way.) This gives
us "vertical integration" a sort of "of the remailers, by the remailers
and for the remailers". Careful design of message formats could make it
hard to tell the escrow mechanics from the traffic. To mount this collusion
attack the TLAs would have to be part of the scheme - helping to pass most
anonymous messages in order to trace some random ones, not necessarily those
they want to trace. (If there was nothing in it for them they wouldn't join.)
(Compare that to the current state quoted as near as I can remember from AC2
"It seems reasonable to assume that the NSA can break any message that it
intercepts, but not all messages")
It takes time to collect the shares and determine the next destination,
during this time the message is sat in a pool. (Is there scope for traffic
analysis in the fact that the average speed of messages will be lower
than that of shares ?)
With that in mind I was looking at the scope for cheating.
Cheating seems possible by:
1) Collusion (as mentioned)
2) Not releasing (valid) shares when requested
This can be caught by traps. The list of where the
shares went is usually destroyed, but need not be.
The shareholders are none the wiser, and when they get
known for not releasing shares the remailer excludes them
from future share issues.
3) Flooding attacks - storing rubbish in escrow servers who
are eventually forced to accept no more shares, or ditch
some existing ones. So far as I can see Matt's Netescrow
scheme has exactly this problem. Ecash payments might help.
If existing shares are ditched the reply-ability will not last
long. You might get a message you can reply to for 2 weeks, but
no later. Sender might resend periodically - a bit like following
up an unanswered snail mail.
> At the same time it would provide an argument against GAK, all
> legitimate (in the publics eyes, what other opinions count, this is a
> democracy isn't it) law enforcement needs met.
As in the last sentence or so of the OKE paper.
Matt:
> My original idea for OKE was as a way to backup long-term,
> slow-changing sensitive data without also introducing a single point
> of failure for either security or availability. The remailer model is
> a bit different, and I'm not sure it's a good fit, in particular
> because I haven't thought about the various new failure modes in this
> application. But let me think ``out loud.''
>
> So can this scheme be improved upon? Is there a better way to run a
> persistent-reply-address remailer? These are interesting, and I think
> largely open, questions.
-- Peter Allan [email protected]