[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [freehaven-dev] sketching accountability requirements/solutionsin FH
On Sun, 19 Nov 2000 email@example.com wrote:
> 4. Output (B, C'_1, C'_2, .... C'_n) as the reply block.
By the way, one observation and one wish list item:
1) If we put the C'_i in the correct order (i.e. identify which one is
the public key for the third hop), then
1.1) we can successfully pay different hops different amounts
but only in the sense of "pay hop 5." If we want to pay
based on some other criterion, then we need to look at
what exactly is in that payment.
(For example, maybe you have a time bonus by encrypting cash
which has to be redeemed quickly, because its value decays
with time. Further add the restriction that hop i can't
redeem its cash until hop i+1 redeems its cash, and you may
have an incentive to pass along such messages quickly.
or to drop them on the floor if the chain is unreliable enough.)
1.2) a sender can encrypt a message M with the C_i's such that
only the last hop sees the unencrypted message. This is in
contrast to the current situation, where the message is passed
as-is attached to the reply block header B.
2) Jonathan Kelner noticed that if we can find a function which takes
a tuple of public keys, a tuple of hops, and a message,
F((E_1, E_2,E_3,..E_n), (HOP1, HOP2,...HOPn), M)
and outputs a new function
REPLY(M) := E_1( HOP2 E_2( HOP3 ... E_n(M))..)
where HOPi stands for the e-mail address of the ith hop
such that given REPLY(), it is
* infeasible to determine the E_i
* infeasible to determine the HOPi
then F can act as a secure reply block. The advantage of such an F
over the current reply block system is that it allows for M to be
encrypted with the keys of each of the hops. So an adversary who
has compromised hop k_1 and hop k_2 can't correlate any messages
(right now he can notice the same M appended to B).
This would also alleviate the problem we have with the blinded-key
construction where an adversary can take a key C'_i in isolation
and start trying to see if particular mix nodes respond to it. With
this, none of the public keys are accessible by themselves.
I do not know of a practical way to build such a F. There might be
a theoretical construction based on recent work in "CryptoComputing",
but I'd have to look at it for a while and right now there's more