[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: paper comment



Hello David,

On Tue, 7 May 2002, dmolnar wrote:

> 
> 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 am not sure where the reply is but I am happy to repeat it here. The 
attack on BEAR as presented on the paper you mention is really an attack 
on the key schedule. Ross divided the key into 2 parts and used one in the 
first round and the other in the third round. It is obvious that one only 
needs to know half the key to decrypt most of the message. By using the 
same key in both 1st and 3rd the problem is resolved.

> 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
> 

An additional property (the one we are really after) is:
- Modifying the ciphertext, without knowing the key will result in all the 
plaintext to be random after decryption. (Random from the point of view 
that there is no correlation between the change and any bit in the 
output).

> 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
> 

Geogre.