paper comment

[dmolnar <dmolnar@hcs.harvard.edu>]

Hi guys,

Congratulations on the paper. I'd like to echo Zooko's comment that it's
impressively complete and well-written.

one thing so far, probably others to come:

* I am worried that specifying BEAR will bring up concerns about the
security of BEAR, instead of focusing on the nice properties of BEAR that
defeat tagging attacks. I notice that Nick brought up this issue in
http://archives.seul.org/mixminion/dev/Apr-2002/msg00007.html
but I don't see where it was responded to (please feel free to point me
back at the archives).

I would prefer to see BEAR replaced by an abstract primitive with the
properties required and then BEAR brought up as an example of such a
primitive at the beginning. That way you can plan for a Type 3.5 remailer
should BEAR ever be catastrophically broken. You can also leave it as an
open problem to create such a primitive; maybe it'll interest a
cryptographer or two. Failing a complete replacement, which is probably a
big deal to do at this stage, maybe just do it where you introduce BEAR.

(Right now in the copy I have, it says "we use BEAR. and by the way BEAR
has these properties." I'm suggesting say "we need these properties. oh
and BEAR has them." )

Just for my own understanding, BEAR is attractive because

	* it is variable length
	* it is an AONT
	* it respects length
	* encryption and decryption are the same operation
	* anything else?

In any case, you should acknowledge the critique of BEAR Nick mentioned
earlier:
http://citeseer.nj.nec.com/124166.html

to avoid it being mentioned to you by reviewers. and maybe talk about
briefly if BEAR should fail what plan B is. It seems to me that one naive
way to work around the issue by padding everything to a maximum length and
then using OAEP-AONT + AES -- you would keep the tagging resistance, but
lose the variable length and the same operation for encryption and
decryption.

-David