Oskar wrote: > Hal, if you have time I would still appreciate some comments on the > announcement proposal: > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/docs/announcement.txt?rev=1.1&content-type=text/plain&cvsroot=freenet
I need to think about it some more, but I did see one possible attack. Alice and Bob1 can collude to control some portion of her initial key value (the x in the protocol), perhaps 20 bits or so. Luckily the fix is easy. They start off by observing the protocol properly. Alice picks x0 and Bob1 picks x1. Note that Bob2 sees hash(x1 + hash(x0)). The protocol proceeds normally until Alice gets back all the x values. Now she cheats. Instead of sending x0, x1, ... xN, she will change x0 and x1. (The protocol as written says to send only x1..xN but I assume that it should also include x0, since otherwise the Bobs can't verify the forward hash from the commit phase.) Since Bob1 is colluding she can change x0, but she is constrained by Bob2's knowledge of hash(x1 + hash(x0)). Essentially this forces her to keep x1 + hash(x0) as what it actually was. However this allows considerable latitude. She can change x0 to anything and from this equation derive a corresponding x1. Given that the final key will be the xor of all the x's, Alice can try different x0 values, find the corresponding x1 that will satisfy Bob2 and all the later Bobs, and then xor these with the other x values to get her key x. If she has time to try a million x0's, she can find an x with about 20 bits set the way she wants them to be. She then proceeds with the protocol using the new x0 and x1 values she has derived, and no one will notice except Bob1, who is in on it. In this way she can get her key to be approximately what she desires, forcing about 20 bits, and controlling her initial key space to that degree. This could be enough to give her a good chance of being asked to hold some target document for which she may have malicious intentions. Actually there's a really easy fix for this. You just use concatenation rather than addition for the hash chaining. That is, instead of doing CommitValue = hash(xi + CommitValue) as now, instead do CommitValue = hash(xi || CommitValue) where || is concatenation. Hash functions like SHA can take any size buffer as input, so there is no difficulty in giving it a 320 bit input in this case (assuming the xi values are 160 bits). Given that the hash is one-way, this effectively commits to the 320 bit input and therefore it commits to both xi and the old CommitValue. In this way the final CommitValue is a true commitment to all the xi values, which is what you want. I'll let you know if I have any other comments - Hal _______________________________________________ Devl mailing list Devl at freenetproject.org http://www.uprizer.com/mailman/listinfo/devl
