Re: [freehaven-dev] sketching accountability requirements/solutionsin FH

[dmolnar@belegost.mit.edu]

On Sun, 19 Nov 2000 dmolnar@belegost.mit.edu 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
   pressing stuff...

-David